自动化测试方法改进方案

1、自动化测试方法改进方案一、前言自动化测试是测试领域中一个争议性比较大的区域，虽然它并不是一个新生的事物，但是至今仍没有一套比较完善的理论可以提供行之有效的方法，使之更好的为产品质量服务。各个研究机构和公司的专家提供了许多自动化测试的理论和模型，但是均没有形成通用理论，被大众广泛认可。 作者通过对安全产品进行自动化测试，从需求定义开始进行跟踪，涉及产品的设计与实现，对产品的接口、实现功能等进行自动化集成测试，采用测试代码和测试角本相结合的开发方式。作者总结了在工程中遇到的问题和实施中的成功之处，提出改进意见，对自动化测试人员具有较强的工程参考意义。 二、自动化测试简介 所谓自动化测试，就是充分利

2、用测试理论和相关的工具，对产品进行自动化的测试，减轻甚至摆脱某些人工测试的繁重劳动，能够形成统一的测试报告并发布。 自动化测试涉及面很广，可以涉及单元测试、集成测试、系统测试、压力测试等诸多方面，针对不同的测试有不同的处理方法和工具。 经过实践，业界对自动化测试形成了一定的统一观点： 自动化测试不能代替手工测试; 自动化测试进行的是常规测试和回归测试，测试集覆盖率和BUG发现率均不高(这两组数据没有定论，根据测试系统的不同，数据会有所不同，但均低于50%，甚至低于30%)。 三、测试中的“人” 人永远是软件开发领域中的重要因素，不同的人掌握着不同的角色。充分调用不同角色的主动性，可以有效的提高

3、自动化测试的效率。 1.领导支持 自动化测试是个系统工程，测试人员要制定合理完善的测试用例，需要得到需求、设计、开发等相关人员的配合。没有领导的鼎力支持，各方力量配合将会减弱，测试的实现目标将会大打折扣，测试工期也将无法保证。 因此从需求调研之初，就需要得到领导的大力支持，充分估计自动化测试所能达到的目标，制定良好的开发计划，如有可能，由项目经理直接进行领导，以期达到自动化测试的最优效果。 2.避免测试人员“挪作他用” 在许多公司，自动化测试均不是专职人员，经常是针对产品从研发、测试等部门抽调而来，因此他们原来都负担过别的工作。在自动化测试工作过程中，尽量不要由于其原工作问题，将自动化测试人员

4、调回，更不能因为自动化测试在前期开发过程中收效甚微，在开发工期有限的情况下，暂时裁减开发人员。由于自动化测试工作量很大，从理解需求、设计用例、用例实现、测试驱动的设计与开发，到用例调试、用例的最终应用要经历比较长的工期，经常性的人员调动会导致工作情绪的波动和工作进度的滞后。 四、文档工作 在项目管理中，文档是软件工程各阶段的产品和依据，自动化测试当然也不能例外。 1.测试文档要及时 自动化测试与其说是一种任务，更不如说是一个公司知识库的积累过程，测试代码绝不是自动化测试的最终目的。 因此在测试开发过程中，要随时书写自动化测试的配套文档，并要根据需求和设计的变化，即时更新。文档包含自动化测试的设

5、计、实现文档，测试集测试用例文档，测试驱动文档。测试文档的积累，也是对公司知识库的积累，减少将来进行同样开发的成本。 2.开发文档要完善 自动化测试的根本是文档，它依靠需求和设计文档来开发用例，而绝不是根据开发人员实际代码来进行的。因此在自动化测试开始工作之前，要准备好各种文档，包括需求、接口设计、数据库定义等，测试人员只有依据这些文档，才能制定合理的开发计划，开发出适合本系统的测试用例。 一定要避免由于工期等原因，产品的需求和设计文档跟不上，甚至编码前几天，需求设计才最终确定，在开发过程中也要避免频繁的更改需求和设计，其结果经常导致自动化测试人员开发测试用例“无依据”，常常要跟着开发人员跑，

6、而不是跟着文档跑，期间的沟通要花费了大量的时间与精力。同时已经存在的文档如果经常发生变化，如果通知不及时，也会导致开发成本的加大。 通过自动化测试，可以达到检查开发文档，促使开发流程规范化的作用。 3.自动化测试报告清晰 自动化测试之所以在业界一直得以推崇，就是因为测试的自动化、报告的自动化，倘若缺少一份有效的自动化测试报告，即使有再全面的测试用例，别人也会对工作感觉很茫然，缺乏到工作的全面了解。 测试报告中，除有明确的统计数据(包括测试用例数据、通过率等)，还需求提供测试的跟踪信息、测试用例失败的原因分析。特别是由断言失败导致的失败原因分析，应具有很好的原因说明，良好的可读性，对问题有很好的

7、描述与定位，可供自动测试人员、开发人员、设计人员和领导等多方人员阅读，对测试结果有很好的理解和定位。 自动化测试报告最好要做到妥善保存，利用测试报告可以跟踪项目进度，把握功能点的完成情况，同时也有利于BUG的回归查找。 五、方法的改进 在实施过程中，需要掌握不同的处理方法，应对处理各种实际问题，包括人员情绪。 1.沟通方式要完善 确认了自动化测试，就需要把自动化测试工作纳入到项目的统一安排之中，把自动化测试人员也做为需求、设计、开发的相关共利者，当发生改变时，要即时通知，以便修改测试用例，避免编码或设计已发生改变，而自动化测试还不知道，其结果将导致查找原因花费大量时间。 沟通也发生在人际关系的

8、处理上。为充分理解需求与设计，自动化测试人员不可避免的要找设计人员沟通产品设计，有时还可能是频繁的询问，遇到设计人员工作重或心情不好，就有可能导致沟通上的困难或不充分。因此沟通需要技巧，测试人员需要耐心与细心，与开发人员保持好的关系，同时要尽量把问题一次沟通清楚，避免沟通不清导致测试用例返工，由此导致工作量的浪费。 对于基于组件的自动化测试，需要开发人员对功能充分的理解，明白自己开发的功能必须依靠什么组件，模块运行必要的支持组件。开发人员理解不充分，就会浪费测试代码的调试时间，直接影响最终的部署。2.测试用例代码健壮性有待提高测试用例的代码应具有很好的健壮性，理想的测试用例代码本身不会引入错误

9、误报，断言错误时，只能是被测模块发生了失败。而在实际实施过程中，测试代码的健壮性很难保证，一方面由于测试用例代码编写人员本身编程水平不能保证，很可能产生代码上的BUG，另一方面由于需求和设计的变化，测试用例本身也要随时发生改变，测试用例更新不及时，就会导致被测模块的失败，因此及时沟通，及时更新用例代码，也是非常有必要。 3.避免测试驱动滞后 测试驱动是实现测试用例的根本，由于分工和涉足点不同，自动化测试人员只能完成很少一部分测试驱动，其它驱动由开发人员完成，测试人员只是负责定义驱动的输入输出接口。 但是开发人员有自己的任务，编写测试驱动势必增加其工作量，影响其原有工作的进行。为了自动化测试的正

10、常进行，必须要与开发组领导进行充分的沟通，合理安排开发人员工作量，在不影响原有工作的基础之上完成测试驱动。 测试驱动实现的滞后，将影响测试用例的调试和最终部署，影响整体流程。 4.多种自动化测试工具的引入 一种产品可能会包含各种功能组件，比如数据库、界面、通信等各种操作，因此要引入不同的自动化测试工具，完成不同功能点的测试。如界面操作的角本录入WinRunner、压力测试工具LoadRunner等，各种工具的引入，可以使自动化测试的测试用例覆盖率扩大，使自动化测试更加深入和全面。 5.自动化测试工作的必要性 这一点也是最难处理的。自动化测试由于缺少成型的理论指导，常常导致没有达到理想的效果，使领导和开发人员怀疑其工作的必要性，同时也可能成为软件项目管理中的“鸡肋”。 如何考虑这个问题呢?是否有必要设置自动化测试这一环节呢? 要处理这种心理落差，就需要在开始工作之前，领导及相关人员确立切实可行的目标，考虑清楚自动化测试测试用例的覆盖范围、BUG率等，不要过于乐观的考虑自动化测试的工