在做自动化的时候，应该根据项目的类型和介入阶段，应用不同的自动化测试策略。最重要的就是打造适应当前项目的自动化框架，落后或者超前于项目都难以产生实际的作用，徐徐图之。这也是我一直认为把控自动化的必须是由项目的测试经理而非专职的自动化人员。下面说不同项目对于的不同自动化实施方式：
1、新项目：
新项目最重要的事就是一开始就写自动化验收测试。（前提a.选择技术平台和测试工具。b.建立一个简单的自动化构建。c.制定遵守INVEST原则的用户故事及考虑其验收条件）
然后严格遵守下面的流程：
客户、分析师和测试人员定义验收条件；
测试人员和开发人员一起基于验收条件实现验收的自动化；
开发人员编码来满足验收条件；
只要有自动化测试失败，无论是单元、组件还是验收，开发人员都应该把它定为最高优先级并修复。
这样做的优点是代码框架不会不支持验收测试。开发人员容易接受。这里面需要注意的重点：盲目书写差劲验收条件实现自动化测试是产生不易维护的验收测试套件的主要原因之一。这意味着从一开始，测试人员就应该参与需求写作的过程，确保一致性。从实例化需求的角度去做。
2、进行中的项目
引入自动化测试最好的方式是选择应用程序中最常见，最重要且高价值的用例为起点。把Happy Path的测试自动化，用于覆盖高价值的场景。
在做Happy Path的同时，应该让这些测试尽可能覆盖更多的选项。用更多数据来确保覆盖率。就是说虽然断言或者设计本身不涉及到过多的可能性，但在正常执行的时候尽量多填一些信息，去“碰”可能出现的问题。
另外，可以先注释掉因为需要频繁修改这块功能而频繁需要修复的自动化用例。只对功能稳定的部分做自动化。
3、遗留系统
如果没有自动化构建流程，最高优先级的事就是创建一个。
聚焦系统中高价值的功能，创建回归套件价值在于保护这些。
先创建一个保护已有功能的框架，逐渐为新增功能添加相应测试。
对遗留系统来说，这些覆盖核心功能的测试就是非常重要的冒烟测试。
可以写一些检查异常条件的测试。防御常见的失效模式。
切记，只写那些有价值的自动化测试。
回归策略：可以将应用程序分成两部分，一部分是实现系统功能的具体代码，另一部分则是在这些代码之下，为实现系统功能提供支撑的框架代码。绝大多数回归缺陷都是因为修改这些框架代码引起的。因此如果只是增加新功能，而不需要修改这个提供支持的框架代码时，为这部分代码写全面测试没有什么价值。
4、集成测试
可以做一个mock sever去模拟外部系统，不仅要列出外部系统所有可能的响应，还应该能模拟因远程服务不正确或者是基础设施问题而导致的极端行为。例如：拒绝网络连接、接受连接后短裤、接受连接后不回复、响应速度齐慢、返回大量非期望数据、回复无效数据、拒绝认证证书、发回异常，或者在当前应用程序状态下回复格式符合规则但无效的响应等。
5、测试流程
在每个迭代开始时，着急所有的项目干系人开会，在文本编辑器中用自然语言写验收条件，然后再写代码让这些条件可执行（另一种方法是为测试创建一种DSL，并用DSL写验收条件）让客户当场找出最简单的验收场景，用HappyPath覆盖。会议之后再增加更多数据来提高覆盖率。
尽早让开发理解验收测试的点，大大减少开发人员和测试人员之间的反馈循环。
对于缺陷列表，非常重要的一件事情就是将其可视化，要显示测试通过的数量、失败的数量以及被忽略掉的数量。
网友评论