自动测试：选择最好的实践（36~40）

第 36 条：不要过分依赖记录/回放工具

记录/回放直接创建的脚本有严重的局限和缺点：

• 硬编码的数值
• 非模块化的
• 缺乏可重用性的标准 应建立可复用的测试脚本的开发方针。

第 37 条：必要时自制开发一个测试工具

自制测试工具用于对一个程序或者系统的核心组件进行自动测试。

第 38 条：使用经过考验的测试脚本开发技术

在使用功能性测试工具开发测试脚本时，应考虑下面这些技术：
1， 数据驱动框架
数据驱动意味着数值是从电子数据表或者工具提供的数据池中读取，而不是硬编码写进测试过程脚本中。测试组确定各种测试过程使用的数据场景、数据元素、数值的名字或者数据变量名。把输入数据外置还能降低数据维护的工作量和增加灵活性。
2，模块化的脚本开发
把代码分成逻辑上的模块，每个模块完成一项独立的任务。
3，模块化的用户界面导航
在脚本中使用导航的方法，这样可以将来自应用程序的用户界面的影响最小化。
4，可重用的函数库
5，现成的库
6，版本控制

第 39 条：尽量使回归测试自动化

回归测试确定的是：在修改先前的错误或者想应用程序添加新功能时，是否引入了新的错误，这些错误影响以前运行正常的功能。
为了得到一个更有效的回归测试计划，须回答下列问题：

• 什么时候应该执行回归测试？
• 回归测试应该包含什么内容？ 回归测试应该集中在高风险的功能和执行最频繁的路径上。
• 如何优化和改进回归测试套件？
  • 运行回归测试集合
  • 如果回归测试集合运行成功，但错误再以后暴露出来，那么把确定这些错误的测试过程和其他相关场景加入到回归测试集合。
  • 重复这些步骤，用质量测量法不断优化回归测试脚本套件。 在迭代开发中，回归测试的开发也应该是渐进式的，并且在上一个迭代回归测试的基础上开发。基本的测试过程集合应该基于需求，回归测试用例应该能追溯到原始需求。
• 为什么需要自动回归测试？对于自动测试工具方面的投资来说，回归测试能够提供最大的投资回报。
• 如何分析回归测试的结果？ 当发现错误时，测试组必须确定最可能出现错误的其他功能部分是哪些。测试组还要确定相对产生较多错误报告的组件或功能。通过分析测试结果，我们还能确定特定的测试过程在发现错误方面是否有价值。

第 40 条：实现自动生成和冒烟测试

自动生成，每天自动生成最新和稳定的代码。
冒烟测试，是回归测试套件的精简版本。
典型的软件生成顺序是：
1，软件生成（编译）
2，冒烟测试
3，回归测试
如果中间发生错误中断，在错误改正后，生成序列重新启动。
要生成冒烟测试，首先必须确定应用程序的哪些部分是高层应用，然后针对系统的这些主要部分（最频繁的进本操作）开发自动测试过程。

本文章援引《Effective software testing》一书内容，为个人读后笔记，特此声明