车险计算器2020_2020年软件测试趋势报道：彻底实现持续测试（下）

  

  上一篇文章“2020年软件测试趋势报道：彻底实现持续测试(中)”介绍了持续测试实现框架中的实现基础(测试数据管理、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测试报告 从中我们可以得到以下结论：

• 73%的业务风险已经被测试并且通过
• 4%的业务风险被测试但执行失败
• 16%的业务风险已经设计了测试用例但没有执行
• 7%的业务风险没有任何测试用例

  我们从中可以直观的获得这些数字化的信息：风险覆盖距离目标的差距，失效的功能对业务的影响，特定需求的状态，软件版本是否满足发布条件。

6. 测试影响分析

在敏捷开发中持续构建的频率很高，全面的自动化回归测试往往需要花费几个小时甚至几天的时间才能完成，但是持续测试不允许这么长的反馈时间，这时就需要借助测试影响分析技术。 测试影响分析技术由慕尼黑技术大学(Technical University Munich spin-off-CQSE)首创，它通过以下两个原则迅速暴露自上一次测试运行以来添加/修改的代码中的缺陷：

• 将回归测试用例关联到软件应用的代码，在选择回归测试的测试范围时，仅仅选择与最新一轮代码更改相关联的测试用例，而没必要浪费时间去执行代码没有修改的测试用例。
• 根据检测到缺陷的可能性对这些回归测试用例进行排序，优先执行那些最容易暴露缺陷的测试用例。研究表明，这种方法用1%的执行时间可以发现80%的错误构建，2%的执行时间发现90%的错误构建。换句话说，测试速度可以提高100倍，但仍然可以发现大多数问题，是优化持续测试的理想选择。

7. 探索式测试

测试自动化适合反复检查增量应用的更改是否会破环现有功能 (即回归测试) ，但在验证新的功能特性方面存在不足。采用探索式测试进行新功能的验证，可以在自动化测试之前快速的发现缺陷。探索式测试可以参考相关文献，这里只简单概括探索式测试在持续测试中的作用：

• 快速暴露缺陷，包括采用其它测试方式找不到的缺陷。充分利用了人类智慧，探索式测试可以覆盖更广和更深的测试范围，包括更多的测试场景，异常场景，用户体验。大家一般都有这样的体验，如果严格按照基于脚本的测试用例来执行测试，往往发现不了多少缺陷，往往需要做更多的扩展测试。
• 组织跨职能团队成员一起进行探索式测试，包括开发人员、产品负责人、业务分析师等等。来自不同专业领域的成员可以带来不同的专业人士。有了一个更大、更多样化的团队参与测试，不仅可以在更短的时间内完成更多的测试，而且还可以暴露出更广泛的问题，并降低了关键问题被忽视的风险。
• 在转化为自动化测试之前快速发现缺陷。如果使用探索性测试工具自动记录测试步骤，则发现的任何缺陷都很容易被复现。

8. 自动化测试提供快速反馈

      为什么敏捷化、DevOps让自动化测试势在必行？

• 软件越来越复杂，采用分布式架构，软件发布的速度非常快，开发时间很有限，手工测试的周期太长，如果不为每个“sprint”中的测试进行认真的设计并引入高水平的测试自动化，是不可能完成覆盖所有需要的测试范围的。
• 研发团队期待持续的、近实时的反馈。如果不能对最新的更改带来的影响提供快速反馈，加速交付会带来很大的业务风险。
• 优秀的企业比以往更加重视质量。企业虽然期望以比以往更快的速度交付更多的创新产品，但同时也认识到，轻视质量不可避免地会导致品牌流失和客户流失。在受监管的行业，质量不达标的后果更为严重。

       目前在很多组织中系统端到端的功能测试自动化水平很低，为了实现连续测试，端到端的功能测试自动化率需要超过 85% ，而且应该集中在 API 或消息级别，利用服务虚拟化来模拟所依赖的 API 和其他组件， UI 测试自动化将不再是自动化的焦点。

持续测试成熟度模型

基于上述实现框架，Tricentis公司提出了持续测试的成熟度模型，如表4所示。

表4 持续测试成熟度模型 I级： 在这个阶段，测试用例的数量是关键的度量指标。测试人员根据感觉来判断哪些需求需要设计更多的测试来覆盖；基本采用手工测试，或部分采用基于脚本的测试自动化方式，导致了很多测试结果的误报，因此测试脚本需要频繁的维护；测试人员需要手工准备和维护测试数据；需要等待测试依赖的第三方系统组件被部署到测试环境中才能进行测试。 期望的效率提升： 1.3X。 II级：已经采用基于业务风险的测试分析方法指导测试的分析、设计和执行，风险覆盖率成为测试用例设计和执行的关键指标；测试自动化仍然集中在UI测试自动化，但开始采用基于模型的测试自动化技术，这可以显著的降低误报率和维护成本；因为仍然没有综合的测试数据管理服务，测试数据基本在自动化测试执行时生成，自动化无法覆盖复杂的测试场景。 期望的效率提升： 3X。 III级：基于会话的探索式测试被采用；采用有效的测试用例设计方法保证测试用例覆盖业务风险的效果和效率，例如Linear Expansion。如果软件的功能可以通过API被访问，测试人员会采用API进行自动化测试；当API测试不适用或者效率不高时，采用基于模型的UI自动化测试；自动化测试在CI环境中和构建、部署等工具集成在一起使用。 期望的效率提升：6X 。 IV级：测试数据管理服务(TDM)为测试自动化提供测试数据；在被测系统所依赖的第三方系统组件不稳定或不可用的情况下服务虚拟化确保测试可以进行；TDM和服务虚拟化的引入让自动化测试能够覆盖更复杂的API测试和端到端的测试，并保证测试可以持续运行；测试作为持续交付流水线的一部分持续运行，为要发布的软件版本提供业务风险的即时反馈。 期望的效率提升：10X 。   V级 ：综合的测试自动化能力已经建立，并且得到更强大的服务虚拟化和测试数据服务的支持；组织建立了度量指标来监控和持续的改进软件测试流程的有效性。 期望的效率提升：20X。

彻底实现持续测试

Tricentis公司提出了一套可行的实施框架，尤其是通过量化需求和测试风险为软件测试的数字化转型提供了新的思路。不过，这个框架距离持续测试的理想状态还是有一定差距，而且很大程度上是贴合其推出的商业工具Tricentis Tosca提供的功能来介绍的，可以参考但不必完全照搬。 为了实现彻底的持续测试，未来可以从以下几个方向来思考如何完善： 对需求的业务风险的度量依赖人工评审获得，得到的结果比较主观，将来能不能利用AI、大数据等技术进行自动分析，实现更为彻底的数字化？ API的自动化 测试、测试数据管理服务、服务虚拟化技术和测试平台与DevOps工具链的集成这些手段并不能消除自动化测试的所有障碍，如何让自动化测试做得更快、更好？ 也许AI技术在将来可以给出更好的答案。 新功能探索式测试、回归测试自动化，能不能把二者融合起来，利用人工的探索式测试智能产生测试代码，让测试更具“持续性”？ 例如，任何新功能，先经过测试人员的探索式测试给AI提供训练数据，AI一边训练一边补全测试，并生成自动化测试脚本。 总之，彻底的持续测试需要通过AI技术辅助实现，相信这一天很快到来，也许就在眼前！ 参考

• 2020年软件测试趋势报道：无代码化的测试自动化
• 2020年软件测试趋势报道：彻底实现持续测试(上)
• 2020年软件测试趋势报道：彻底实现持续测试(中)

PS:《敏捷测试：以持续测试促进持续交付》抢先预览版发布。 敬请期待正式版本 (预计年底发布)， 涵盖了持续测试实现框架中所有实践的落地指南。