赞
踩
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较。在此过程中,为了节省人力、时间或硬件资源,提高测试效率,便引入了自动化测试的概念。测试自动化可以在已经存在的正式测试过程中自动化一些重复但必要的任务,或者添加额外的难于手工执行的测试。
自动化测试一般分三种:单元自动化测试,接口自动化测试,UI自动化测试。
其中单元自动化测试一般由研发人员自己进行测试,测试人员主要进行接口以及UI的自 动化测试,但是由于UI的需求变化比较频繁,所以接口测试是测试人员做的最多的
自动化测试框架设计的模式主要有4种:
(1)分布式。指的是测试需要在多台电脑上进行多线程或者多进程的测试,该模式主要针对测试用例比较大的情况常用的工具是grid;
(2)数据驱动的模式。指的是讲测试程序与测试所需要的数据分离,每次测试程序的时候直接调用所需要的数据;
(3)关键字驱动的模式,该模式主要从对谁做,怎么做,做什么三个要素进行衍生,每次只需要调用关键的函数就可以,即使不懂代码的人也能勾编写。现在很多的自动化测试工具例如KAMA即是如此,测试人员只需要了解测试功能的逻辑通过调用工具的内部函数就可以编写自动化测试脚本。
(4)混合型模式。指的是运用以上两种或以上的方法的一种模式。
主要具备以下优势:
(1)回归测试更方便可靠,可运行更多、更繁琐的测试,且快速高效;
(2)可执行一些手工测试执行相当困难或者做不到的测试,如大量的用户并发;
(3)可以更好的利用资源,具有一致性和可重复性的特点,自动化测试脚本完全可复用;
(4)提升了软件的可信度;
(5)可以多环境下测试等。
(1)永远不可能完全替代手工测试。自动化测试无法做到手工测试的覆盖率,不是每个测试用例都适合实行自动化。
(2)手工测试发现的bug远比自动化测试多。自动化测试几乎是无法发现新bug的,最大的用途是用来回归,确保曾经的bug没有在新的版本上重新出现。
(3)自动化测试工具比较死板,灵活性比较差。自动化测试的效果好坏,完全取决于测试工程师。
(4)成本投入大,风险高。对测试人员的技术要求高,对测试工具同样也高。
(5)测试用例需要根据版本迭代进行更新,有一定的维护成本
(6)自动化测试的产出价值往往在于长期的回归测试,短期内发挥的作用可能不明显。
(1)回归测试,重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费;
(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具;
(3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性;
(4)自动化工具能够确定测试用例的覆盖路径,确定测试用例集对程序逻辑流程和控制流程的覆盖。
(5)项目周期长,系统版本不断,并且需求不会频繁变更
(6)系统的测试对象基本可以正常识别,以及对无法识别的控件能否提供一个解决方案。
(7)系统中不存在大量的不可识别第三方控件。
(8)需要反复测试,如可靠性测试、回归测试等需要进行上千次的系统测试。
(1)项目周期短,需求频繁变更。即使是周期长的项目,如果经常需求变更,也不适合做自动化测试。
(2)软件版本没有稳定,主功能或大量功能有被重新更改的可能的情况下,也不适合做自动化测试。
(3)没有明确的项目进行自动化测试计划、措施和管理的情况。
(4)多数对象无法识别,以及脚本维护频繁和艰难的情况下,不建议测试自动化。
以上是自动化测试入门的相关基础知识,更多测试动态请关注博主
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。