脚本重构与舍弃

　　虽然测试脚本应该被良好地规划设计，但实际执行的时候可能会遇到一些问题，比如在识别公用特性组建时存在遗漏却未在评审环节被发现，抑或被测应用的代码重构甚至是流程再造同样会要求我们去做这些对应的测试脚本重构的工作。

　　我每天都会从SVN上checkout我们组17个工程的测试脚本，之前经常会发现某些系统一次性update十数个甚至数十个文件。这时候我会问一声为什么，初得到的答复都是由于系统页面发生变动，所以这部分测试脚本都需要同步修改。我的回复一律都是：重构，重新做公用组件抽取，立刻做，因为我们耗不起这个维护成本！几次之后，再遇到这种情况，得到的答复便基本上都是：因为XX的变更影响了一些模块的测试脚本，所以我重构了一下。这时候我的心里比较嗨皮，比较有成感了，因此我也乐于不断地给大家灌输这种从别处学来的理念，而测试脚本重构的动力也从单纯的前端页面变更驱动变得更加多样化。

　　伴随着测试脚本的开发，债务不可避免的在不断产生，如果不加以管控，终有我们都会由于对之无法负担而崩溃。所以我们如果真的重视自动化测试，我们需要不断地优化我们测试脚本的结构，让它始终停留在我们可以控制的范围之内。必要的时候我们可以放弃一些已经开发完成的但是优先级稍低的测试脚本，即便它们运行得很好。在负担能力满载的情况下，以放弃低优先级的部分为代价来换回我们对测试资产持续优化和维护的能力、换回我们对这种低端技术债务的负担能力，始终都比承担不可控甚至崩溃的风险要来得更加有价值。

　　方法之四：坚持定期脚本审查

　　在团队里面推广自动化测试应用，同样也会存在很多沟通和理解上的误差，加之不是所有人的技能都在一个层次上，所以大家可能对测试脚本开发的各种要求的理解上都会存在不同的误区。因此，测试脚本开发完成之后第一时间要进行审查，这是测试脚本有效性验证的第一道关，虽然这个活动将耗费不少时间。

　　测试脚本审查的手段分两种：工具检查和评审会议。一般建议在召开评审会议之前使用代码扫描工具如sonar或者checkstyle、 findbugs等，定义一些通用的规则去检查测试脚本书写和设计结构上的问题。使用工具的方法本文不介绍，完成这些基础不合规项的检查和修复之后则可以开始后续的测试有效性评审。测试有效性评审是个技术活也是个体力活，不仅需要很强大的业务知识支撑和对系统设计模式甚至架构的理解，同时也需要足够的时间和耐心来从事这项活动。接下来，简单说一些实际的检查点，通过这些检查点，我们将识别一段测试脚本是否能够达成测试目标，是否经济合理。

　　● 经过设计评审的每一个案例是否都已经完成开发，是否存在额外的新增覆盖，为什么；

　　● 预设的公用组件是否已经完全抽离实现，对于假设的被测应用修改，能否用简单、经济的测试脚本修改来支持同步；

　　● 测试数据的初始化和使用是否合理，是否会破坏测试环境中数据的健康度甚至带来环境故障；

　　● 测试的验证点是否足够，是否存在反向的验证方式（如，只检查是否有错误发生）；

　　● 测试脚本中是否存在多余的结构体，是否存在非预设的随机性分支；

　　● ……

　　子曰：脚本三月不复查，CI即便全蓝——虫子照样遍地爬！自动化的测试有效性本是需要通过维护去保持的，定期重新审查本是一种测试脚本的维护手段，是非常有必要的。而频率则需要结合团队对测试脚本维护的力度来看，复审的主要的方法与开发完成之后的初次审查是一样的，只是关注点会稍有不同。

　　两句废话做总结

　　自动化测试是达成目标的工具手段还是负担，关键在于它对我们产生了什么样的影响，要产生好的效用，必须保证其测试有效性。保证自动化测试有效性的手段很多，笔者目前的水平只能说到这里，但愿对入门者和彷徨者有所助益，高手和喷子们便一笑而过便可。