上一篇文章“”介绍了持续测试实现框架中的实现基础（测试数据管理、DevOps工具链集成、服务虚拟化）和中间过程中的“基于风险的测试分析”。今天接着介绍实现框架中的其它内容以及持续测试成熟度模型。
持续测试实现框架（续）5. 有效的测试用例设计方法
下一步要做的就是确定在何处添加测试为最高业务风险的需求构建可接受的测试覆盖率，以及利用有效的测试设计方法设计测试用例，既要保证覆盖业务风险的效果，也要效率。
首先，二八原则在这里仍然有效：测试20%的需求覆盖80%的业务风险。那么，对业务风险最高的需求必须尽可能覆盖。
其次，关于测试设计方法，咱们熟悉等价类划分、边界值分析及各种组合方法（如Pairwise、正交实验等），而Tricentis公司特别推荐采用Linear Expansion（线性膨胀），可以用很少的测试用例覆盖更多的业务风险。
假设以下简单场景：一个车险计算器考虑15个不同输入属性（性别、年龄、车辆类型等），每个属性可以有2个不同的输入值（男/女、18-59/60+、汽车/卡车等），每个属性之间没有相互依赖条件。女性司机会获得5%的折扣；60+的司机会获得5%的折扣。
如果采用Linear Expansion方法：
首先，要定义一条“straight through”或者“happy path”测试用例，所有的输入属性都选择最重要的、有效等价类的值，覆盖包含最大风险属性值，例如，根据统计信息，男性汽车司机覆盖了最广泛的投保人群，那么这条测试用例应该选择：性别：男，车辆属性：卡车……。这条测试用例具有最高优先级，会作为冒烟测试或持续集成中BVT的测试用例集的一部分。
然后，为每一个属性设计一条测试用例。每个测试都有一个明确的目标：一个测试检查针对女性司机提供折扣的功能，一个测试针对60+的司机提供折扣的功能，等等。这些测试用例会作为自动化回归测试用例集的一部分。因为每条测试用例都有一个明确的目的，如果某一条测试用例执行失败，很容易能够定位到对应的软件代码。
你最终得到的测试用例数量为16条（针对15个属性分别设计一条测试用例+1个“straight through”测试用例）。各种测试设计方法对比如表1所示。
表1 各种测试设计方法对比
最后，在执行测试时，根据给定的测试执行时间和业务风险确定测试范围和优先级，目标是达到反馈速度和业务风险覆盖率之间的平衡（就这一点，依旧有挑战）。针对在线教育App测试用例执行情况的风险覆盖率如表2所示。
表2 在线教育App测试执行风险覆盖率
在每次迭代中需要更新对需求的风险评估。首先，在一个Sprint中创建一个用户故事列表，单独针对这些新的用户故事进行风险评估。通常情况下，任何一个新的功能特性的业务风险都比已有功能的风险要高。在所有新的用户故事被验证并通过后，再把这些新的需求合并到总的需求列表中，在整个回归测试范围内进行整体排序。
最终，基于风险覆盖率的测试报告如表3所示。
表3 在线教育App测试报告
从中我们可以得到以下结论：
我们从中可以直观的获得这些数字化的信息：风险覆盖距离目标的差距，失效的功能对业务的影响，特定需求的状态，软件版本是否满足发布条件。
6. 测试影响分析
在敏捷开发中持续构建的频率很高，全面的自动化回归测试往往需要花费几个小时甚至几天的时间才能完成，但是持续测试不允许这么长的反馈时间，这时就需要借助测试影响分析技术。
测试影响分析技术由慕尼黑技术大学（Technical University Munich spin-off-CQSE）首创，它通过以下两个原则迅速暴露自上一次测试运行以来添加/修改的代码中的缺陷：
7. 探索式测试
测试自动化适合反复检查增量应用的更改是否会破环现有功能（即回归测试），但在验证新的功能特性方面存在不足。采用探索式测试进行新功能的验证，可以在自动化测试之前快速的发现缺陷。探索式测试可以参考相关文献，这里只简单概括探索式测试在持续测试中的作用：
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： lzxmw777
