自动化测试有效性( 四 ) _测试

文章插图
图4：STAR测试框架中的Api样例
接下来就是被测对象的共有特性组件做抽取，仍以前端自动化测试脚本开发为例，我们可以参照被测应用本身的组件复用规律来提取测试脚本中的公用页面组件。例如，图3所涉及的保全操作流程中，至少包含保全申请发起、质检、核保这三个可公用的页面组件。假如最终需要测试的场景案例有8个，其中5个必须质检、4个必须人工核保，那么在这三个点上就可以节省14（8+5+4-3）个测试Api的维护和开发成本。
共有特性组件既不能设计的过于粗糙，从而造成在不同的自动化测试脚本中无法统一支持；又不能过度抽象，进而导致可读和可维护性变差。目标很简单：任意一处纯前端页面的改动，我们只需要修改一个测试Api；任意一个分支场景的规则改动，我们只需要修改一个测试案例脚本的数据和验证方法。
脚本重构与舍弃
虽然测试脚本应该被良好地规划设计，但实际执行的时候可能会遇到一些问题，比如在识别公用特性组建时存在遗漏却未在评审环节被发现，抑或被测应用的代码重构甚至是流程再造同样会要求我们去做这些对应的测试脚本重构的工作。
我每天都会从SVN上我们组17个工程的测试脚本，之前经常会发现某些系统一次性十数个甚至数十个文件。这时候我会问一声为什么，最初得到的答复都是由于系统页面发生变动，所以这部分测试脚本都需要同步修改。我的回复一律都是：重构，重新做公用组件抽取，立刻做，因为我们耗不起这个维护成本！几次之后，再遇到这种情况，得到的答复便基本上都是：因为XX的变更影响了一些模块的测试脚本，所以我重构了一下。这时候我的心里就比较嗨皮，比较有成就感了，因此我也乐于不断地给大家灌输这种从别处学来的理念，而测试脚本重构的动力也从单纯的前端页面变更驱动变得更加多样化。
伴随着测试脚本的开发，债务不可避免的在不断产生，如果不加以管控，终有一天我们都会由于对之无法负担而崩溃。所以我们如果真的重视自动化测试，我们就需要不断地优化我们测试脚本的结构，让它始终停留在我们可以控制的范围之内。必要的时候我们可以放弃一些已经开发完成的但是优先级稍低的测试脚本，即便它们运行得很好。在负担能力满载的情况下，以放弃低优先级的部分为代价来换回我们对测试资产持续优化和维护的能力、换回我们对这种低端技术债务的负担能力，始终都比承担不可控甚至崩溃的风险要来得更加有价值。
方法之四：坚持定期脚本审查
在团队里面推广自动化测试应用，同样也会存在很多沟通和理解上的误差，加之不是所有人的技能都在一个层次上，所以大家可能对测试脚本开发的各种要求的理解上都会存在不同的误区。因此，测试脚本开发完成之后第一时间要进行审查，这是测试脚本有效性验证的第一道关，虽然这个活动将耗费不少时间。
测试脚本审查的手段分两种：工具检查和评审会议。一般建议在召开评审会议之前使用代码扫描工具如sonar或者、等，定义一些通用的规则去检查测试脚本书写和设计结构上的问题。使用工具的方法本文不介绍，完成这些基础不合规项的检查和修复之后则可以开始后续的测试有效性评审。测试有效性评审是个技术活也是个体力活，不仅需要很强大的业务知识支撑和对系统设计模式甚至架构的理解，同时也需要足够的时间和耐心来从事这项活动。接下来，简单说一些实际的检查点，通过这些检查点，我们将识别一段测试脚本是否能够达成测试目标，是否经济合理。