聊聊自动化测试有效性(3)

　　以正交覆盖为例，我们需要把影响流程分支走向的因子罗列出来。一般理论认为，缺陷的产生绝大多数是因为2个因素组合产生的，所以我们先做一个正交强度为2的配对来确认最小的测试组合范围。然后将正交强度变为最大，得到一个最大的测试组合范围，重新审视强度为2时的子集之外的其他案例是否有必测的理由。注：正交强度最大的组合结果集并不是简单的笛卡尔乘积，因为组合条件之间可能存在一些逻辑限制;此外，鉴于篇幅有限，本文就不再罗列下表最终正交得出的测试组合结果。

　　图3：保险业务操作伪场景分析正交表样例

　　通过对前端业务操作流程的分析，可以建立完整的前端的测试用例库，当然，前端的自动化测试可能只会选择其中的一部分去做，如上文所述，自动化测试覆盖率也可以很轻易地度量出来。在设计评审过程中，流程设计完成者需要向评审人员展示各个业务流程的测试组合结果，并且解释通过怎样的组合方法得到这些结果;进一步阐述依据什么样的原则得出自动化测试范围的选择结果。

　　特性组件抽取

　　完成了对测试案例场景的界定，我们便已明确我们要在被测应用上做什么样的操作，接下来的工作就是一些通用的简易特性抽取。虽然很多人声称复用不是个好东西，但它在编写测试脚本中适度的使用，却也可以很好地减少测试脚本开发和维护成本。

　　第一层的特性抽取可以通过测试框架和工具来完成，简易的二次封装是保证测试书写低复杂度和保证测试脚本健壮性的好办法，就如同图中对click方法的简单封装一样。这件事情只需要一个像笔者一样略微熟悉测试工具和被测应用特性的测试工程师即可完成。所以这个活动的成本不会太高，而带来的效益却还是很不错的，至少可以给不熟悉测试工具的脚本开发者一段很长的学习缓冲期。

　　图4：STAR测试框架中的Api样例

　　接下来就是被测对象的共有特性组件做抽取，仍以前端自动化测试脚本开发为例，我们可以参照被测应用本身的组件复用规律来提取测试脚本中的公用页面组件。例如，图3所涉及的保全操作流程中，至少包含保全申请发起、质检、核保这三个可公用的页面组件。假如最终需要测试的场景案例有8个，其中5个必须质检、4个必须人工核保，那么在这三个点上就可以节省 14(8+5+4-3)个测试Api的维护和开发成本。

　　共有特性组件既不能设计的过于粗糙，从而造成在不同的自动化测试脚本中无法统一支持;又不能过度抽象，进而导致可读和可维护性变差。目标很简单：任意一处纯前端页面的改动，我们只需要修改一个测试Api;任意一个分支场景的规则改动，我们只需要修改一个测试案例脚本的数据和验证方法。

　　脚本重构与舍弃

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

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

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

原文转自：http://www.ltesting.net