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

自动化测试框架强大与否主要在于其适应性，所以与其说自动化测试框架是选择出来的，不如说它是被改造出来的。产品比较单一的小公司或者开发框架比较成熟的公司用一个工具、一个框架在一个测试平台下就可以解决一个公司的自动化测试实施的绝大多数问题，而大型企业的应用繁多复杂，很难由一个简单工具或者框架来解决。
自动化测试框架，没有自己DIY过的永远都不要相信不造轮子这种说法，因为只有在你做的时候，你才能够更深入地理解你的工具、框架和你的被测应用及其所依赖的开发框架的特征，才会产出更具适应性的测试框架和特征库。
方法之三：善用设计与重构
无论是前端自动化测试还是单元测试，脚本代码结构的重要性是个老生长谈，因为这关乎测试脚本代码的可读性、维护经济性等问题。由于我们的业务系统的测试案例主要是基于操作流程的业务场景，所以我简单说一下我们在这方面的做法与经验，而单个功能点特性的测试分析也基本与此类同，不再独占篇幅。
测试范围与设计
大型企业，尤其是金融行业的ERP应用，很多系统实际上都是规则零散、流程复杂，规则引擎应用得并不是很充分。这便是前文所提及的自动化测试分析设计时对输入条件分支和状态机组合的穷举和选择困难的问题的产生原因了。对于这种情况，我们可以借鉴两个基础的测试设计方法：正交覆盖和/All-Pairs，其基本原理和用法这里不再赘述。
以正交覆盖为例，我们需要把影响流程分支走向的因子罗列出来。一般理论认为，缺陷的产生绝大多数是因为2个因素组合产生的，所以我们先做一个正交强度为2的配对来确认最小的测试组合范围。然后将正交强度变为最大，得到一个最大的测试组合范围，重新审视强度为2时的子集之外的其他案例是否有必测的理由。注：正交强度最大的组合结果集并不是简单的笛卡尔乘积，因为组合条件之间可能存在一些逻辑限制；此外，鉴于篇幅有限，本文就不再罗列下表最终正交得出的测试组合结果。

文章插图
图3：保险业务操作伪场景分析正交表样例
通过对前端业务操作流程的分析，可以建立完整的前端的测试用例库，当然，前端的自动化测试可能只会选择其中的一部分去做，如上文所述，自动化测试覆盖率也可以很轻易地度量出来。在设计评审过程中，流程设计完成者需要向评审人员展示各个业务流程的测试组合结果，并且解释通过怎样的组合方法得到这些结果；进一步阐述依据什么样的原则得出自动化测试范围的选择结果。
特性组件抽取
完成了对测试案例场景的界定，我们便已明确我们要在被测应用上做什么样的操作，接下来的工作就是一些通用的简易特性抽取。虽然很多人声称复用不是个好东西，但它在编写测试脚本中适度的使用，却也可以很好地减少测试脚本开发和维护成本。
第一层的特性抽取可以通过测试框架和工具来完成，简易的二次封装是保证测试书写低复杂度和保证测试脚本健壮性的好办法，就如同图中对click方法的简单封装一样。这件事情只需要一个像笔者一样略微熟悉测试工具和被测应用特性的测试工程师即可完成。所以这个活动的成本不会太高，而带来的效益却还是很不错的，至少可以给不熟悉测试工具的脚本开发者一段很长的学习缓冲期。

文章插图