一、前言

自动化测试是测试领域中一个争议性比较大的区域，虽然它并不是一个新生的事物，但是至今仍没有一套比较完善的理论可以提供行之有效的方法，使之更好的为产品质量服务。各个研究机构和公司的专家提供了许多自动化测试的理论和模型，但是均没有形成通用理论，被大众广泛认可。

作者通过对安全产品进行自动化测试，从需求定义开始进行跟踪，涉及产品的设计与实现，对产品的接口、实现功能等进行自动化集成测试，采用测试代码和测试角本相结合的开发方式。作者总结了在工程中遇到的问题和实施中的成功之处，提出改进意见，对自动化测试人员具有较强的工程参考意义。

二、自动化测试简介

所谓自动化测试，就是充分利用测试理论和相关的工具，对产品进行自动化的测试，减轻甚至摆脱某些人工测试的繁重劳动，能够形成统一的测试报告并发布。

自动化测试涉及面很广，可以涉及单元测试、集成测试、系统测试、压力测试等诸多方面，针对不同的测试有不同的处理方法和工具。

经过实践，业界对自动化测试形成了一定的统一观点：

自动化测试不能代替手工测试；

自动化测试进行的是常规测试和回归测试，测试集覆盖率和BUG发现率均不高(这两组数据没有定论，根据测试系统的不同，数据会有所不同，但均低于50%，甚至低于30%)。

三、测试中的“人”

人永远是软件开发领域中的重要因素，不同的人掌握着不同的角色。充分调用不同角色的主动性，可以有效的提高自动化测试的效率。

1．领导支持

自动化测试是个系统工程，测试人员要制定合理完善的测试用例，需要得到需求、设计、开发等相关人员的配合。没有领导的鼎力支持，各方力量配合将会减弱，测试的实现目标将会大打折扣，测试工期也将无法保证。

因此从需求调研之初，就需要得到领导的大力支持，充分估计自动化测试所能达到的目标，制定良好的开发计划，如有可能，由项目经理直接进行领导，以期达到自动化测试的最优效果。

2．避免测试人员“挪作他用”

在许多公司，自动化测试均不是专职人员，经常是针对产品从研发、测试等部门抽调而来，因此他们原来都负担过别的工作。在自动化测试工作过程中，尽量不要由于其原工作问题，将自动化测试人员调回，更不能因为自动化测试在前期开发过程中收效甚微，在开发工期有限的情况下，暂时裁减开发人员。由于自动化测试工作量很大，从理解需求、设计用例、用例实现、测试驱动的设计与开发，到用例调试、用例的最终应用要经历比较长的工期，经常性的人员调动会导致工作情绪的波动和工作进度的滞后。

四、文档工作

在项目管理中，文档是软件工程各阶段的产品和依据，自动化测试当然也不能例外。

1．测试文档要及时

自动化测试与其说是一种任务，更不如说是一个公司知识库的积累过程，测试代码绝不是自动化测试的最终目的。

因此在测试开发过程中，要随时书写自动化测试的配套文档，并要根据需求和设计的变化，即时更新。文档包含自动化测试的设计、实现文档，测试集测试用例文档，测试驱动文档。测试文档的积累，也是对公司知识库的积累，减少将来进行同样开发的成本。

2．开发文档要完善

自动化测试的根本是文档，它依靠需求和设计文档来开发用例，而绝不是根据开发人员实际代码来进行的。因此在自动化测试开始工作之前，要准备好各种文档，包括需求、接口设计、数据库定义等，测试人员只有依据这些文档，才能制定合理的开发计划，开发出适合本系统的测试用例。

一定要避免由于工期等原因，产品的需求和设计文档跟不上，甚至编码前几天，需求设计才最终确定，在开发过程中也要避免频繁的更改需求和设计，其结果经常导致自动化测试人员开发测试用例“无依据”，常常要跟着开发人员跑，而不是跟着文档跑，期间的沟通要花费了大量的时间与精力。同时已经存在的文档如果经常发生变化，如果通知不及时，也会导致开发成本的加大。

通过自动化测试，可以达到检查开发文档，促使开发流程规范化的作用。

3．自动化测试报告清晰

自动化测试之所以在业界一直得以推崇，就是因为测试的自动化、报告的自动化，倘若缺少一份有效的自动化测试报告，即使有再全面的测试用例，别人也会对工作感觉很茫然，缺乏到工作的全面了解。

测试报告中，除有明确的统计数据(包括测试用例数据、通过率等)，还需求提供测试的跟踪信息、测试用例失败的原因分析。特别是由断言失败导致的失败原因分析，应具有很好的原因说明，良好的可读性，对问题有很好的描述与定位，可供自动测试人员、开发人员、设计人员和领导等多方人员阅读，对测试结果有很好的理解和定位。

自动化测试报告最好要做到妥善保存，利用测试报告可以跟踪项目进度，把握功能点的完成情况，同时也有利于BUG的回归查找。

五、方法的改进

在实施过程中，需要掌握不同的处理方法，应对处理各种实际问题，包括人员情绪。

1．沟通方式要完善

确认了自动化测试，就需要把自动化测试工作纳入到项目的统一安排之中，把自动化测试人员也做为需求、设计、开发的相关共利者，当发生改变时，要即时通知，以便修改测试用例，避免编码或设计已发生改变，而自动化测试还不知道，其结果将导致查找原因花费大量时间。

沟通也发生在人际关系的处理上。为充分理解需求与设计，自动化测试人员不可避免的要找设计人员沟通产品设计，有时还可能是频繁的询问，遇到设计人员工作重或心情不好，就有可能导致沟通上的困难或不充分。因此沟通需要技巧，测试人员需要耐心与细心，与开发人员保持好的关系，同时要尽量把问题一次沟通清楚，避免沟通不清导致测试用例返工，由此导致工作量的浪费。

对于基于组件的自动化测试，需要开发人员对功能充分的理解，明白自己开发的功能必须依靠什么组件，模块运行必要的支持组件。开发人员理解不充分，就会浪费测试代码的调试时间，直接影响最终的部署。

2．测试用例代码健壮性有待提高

测试用例的代码应具有很好的健壮性，理想的测试用例代码本身不会引入错误误报，断言错误时，只能是被测模块发生了失败。而在实际实施过程中，测试代码的健壮性很难保证，一方面由于测试用例代码编写人员本身编程水平不能保证，很可能产生代码上的BUG，另一方面由于需求和设计的变化，测试用例本身也要随时发生改变，测试用例更新不及时，就会导致被测模块的失败，因此及时沟通，及时更新用例代码，也是非常有必要。

3．避免测试驱动滞后

测试驱动是实现测试用例的根本，由于分工和涉足点不同，自动化测试人员只能完成很少一部分测试驱动，其它驱动由开发人员完成，测试人员只是负责定义驱动的输入输出接口。

但是开发人员有自己的任务，编写测试驱动势必增加其工作量，影响其原有工作的进行。为了自动化测试的正常进行，必须要与开发组领导进行充分的沟通，合理安排开发人员工作量，在不影响原有工作的基础之上完成测试驱动。

测试驱动实现的滞后，将影响测试用例的调试和最终部署，影响整体流程。

4．多种自动化测试工具的引入

一种产品可能会包含各种功能组件，比如数据库、界面、通信等各种操作，因此要引入不同的自动化测试工具，完成不同功能点的测试。如界面操作的角本录入WinRunner、压力测试工具LoadRunner等，各种工具的引入，可以使自动化测试的测试用例覆盖率扩大，使自动化测试更加深入和全面。

5．自动化测试工作的必要性

这一点也是最难处理的。自动化测试由于缺少成型的理论指导，常常导致没有达到理想的效果，使领导和开发人员怀疑其工作的必要性，同时也可能成为软件项目管理中的“鸡肋”。

如何考虑这个问题呢？是否有必要设置自动化测试这一环节呢？

要处理这种心理落差，就需要在开始工作之前，领导及相关人员确立切实可行的目标，考虑清楚自动化测试测试用例的覆盖范围、BUG率等，不要过于乐观的考虑自动化测试的工作成果。根据实际情况制定切实可靠的目标，使获得的回报更驱于理性。公司原有自动化测试的知识储备、自动化测试人力资源的部署、整体团队的配合等诸多因素都会影响工作的最终效果。

六、结束语

自动化测试是一片新鲜的土壤，虽然没有特别完善的理论，但是只要在实施的过程中把握好几条重要的原则，一定可以达到很好的效果。