自动化测试的理解

 

一篇写的不错的自动化测试的理解：

谈到自动化测试，一般就会提到测试工具。许多人觉得使用了一、两个测试工具就是实现了测试自动化，这种理解是不对的，至少是片面的。的确，测试工具的使用是自动化测试的一部分工作，但“用测试工具进行测试”不等于“自动化测试”。那什么是“自动化测试”？ 半自动化测试过程，算不算自动化测试？是否可以为“自动化测试”给出如下定义？

• 以自动化的方式完成测试？
• 测试过程的自动化?
• 将手工测试的过程变成了自动化测试的过程？
• 摆脱手工测试的各种途径和方法？

自动化测试是相对手工测试而存在的，所以自动化测试的真正含义可以理解为“一切可以由计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”。它包含了下列3层含义：

• “一切”，不仅仅指测试执行的工作——对被测试的对象进行验证，还包括测试的其它工作，如缺陷管理、测试管理、环境安装、设置和维护等。
• “可以”，意味着某些工作无法由系统自动完成，如脚本的开发、测试用例的设计，需要创造性，其工作需要手工处理。
• 即使由系统进行自动化测试，还少不了人的干预，包括事先安排自动化测试任务、测试结果分析、调试测试脚本等。

严格意义上，“自动化测试（Automated Testing）”不等于“测试自动化（Test Automation）”。自动化测试，模拟手工测试步骤，通过执行程序语言编制的测试脚本自动地测试软件，自动地实施软件的单元测试、功能测试、负载测试或性能测试等。自动化测试集中体现在实际测试执行（test execution）的过程，也就是由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。自动化测试，强调借助工具（不仅仅是工具，有时包括策略和工件）来完成测试的执行，也就是用工具来帮助或辅助测试，这个执行过程可能是全自动的，也可能是半自动的。

测试自动化的要求高得多，侧重说明将测试用自动化设计和实现的过程，即所有的测试工作都能有计算机系统自动完成，包括：

• 测试环境的搭建和设置，如上载安装包到服务器；
•  脚本自动生成，如根据UML状态图、时序图等生成可运行的测试脚本；
• 测试数据的自动产生，例如自动产生数据负载测试所需要的大量数据；
• 测试操作步骤的自动执行，包括测试执行过程的控制；
• 测试结果分析，实际输出和预期输出的自动对比分析；
• 测试流程的自动处理，即测试工作流的自动实现，包括测试计划复审和批准、测试任务安排和执行、缺陷生命周期等流程的自动化处理。
• 测试报告自动生成功能等。

这样，测试自动化意味着测试全过程的自动化和测试管理工作的完全自动化，是测试工程师所追求的一种理想境界，但是很难实现的。往往不能完全通过全自动化过程来完成一个完整的测试任务，自动化到不需要人工参与的程度是不现实的。虽然不能完全实现那种理想境界，但是我们每时每刻可以向这个方向去思考，优化每项工作，一切可以由计算机系统自动完成的测试任务都已经由计算机系统或工具来承担并自动执行。

在一般情况下，人们并不严格区分“自动化测试”和“测试自动化”，就是通过工具或程序来对软件进行测试，一般不需要大量的手工操作来完成测试，而只要很少的人工干预。自动化测试，理应从工作效率和产品质量的目的出发，而不是为了自动化而自动化，在某些时刻，也可能得不偿失，即投入过大，产出远远小于投入。脱离了目的，测试人员可能会变成自动化测试的奴隶。奢想做到百分之百地实现自动化测试，不仅不现实，所引起的代价可能会非常大，而且可能引起负面性，造成质量水平的降低。

最后，我们还不得不承认，自动化测试和手工测试往往交织在一起，相互补充，工具执行过程往往需要人工分析，手工测试时也可以借助工具处理某些数据、日志或显示某些信息。也就是说，不是试图用自动化测试来代替所有的手工测试，而应该在尊重手工测试的同时，尽量采用自动化测试，根据各自的特点充分发挥各自的优势，使手工测试和自动化测试实现完美结合。