方法之三：善用设计与重构

　　无论是前端自动化测试还是单元测试，脚本代码结构的重要性是个老生长谈，因为这关乎测试脚本代码的可读性、维护经济性等问题。由于我们的业务系统的测试案例主要是基于操作流程的业务场景，所以我简单说一下我们在这方面的做法与经验，而单个功能点特性的测试分析也基本与此类同，不再独占篇幅。

　　测试范围与设计

　　大型企业，尤其是金融行业的ERP应用，很多系统实际上都是规则零散、流程复杂，规则引擎应用得并不是很充分。这便是前文所提及的自动化测试分析设计时对输入条件分支和状态机组合的穷举和选择困难的问题的产生原因了。对于这种情况，我们可以借鉴两个基础的测试设计方法：正交覆盖和Pairwise/All-Pairs，其基本原理和用法这里不再赘述。

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

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

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

　　特性组件抽取

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

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

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

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

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