阿里研究员：软件测试中的18个难题（上）
极客时间编辑部
讲述：丁婵大小：6.59M时长：04:48
你好，欢迎收听极客视点。
对于软件测试来说，怎么样才算测够了？如何评价测试的有效性？那么多测试用例，以后怎么删？最近，阿里研究员郑子颖总结了 18 个软件测试难题，发文于公众号“阿里技术（ID：ali_tech）”，供你参考。
1. 测试充分度（Test Sufficiency）
如何回答“测够了吗？”代码覆盖率是衡量测试充分性的起点，但远远不是终点。要回答这个问题，至少还要考虑是否测了所有的场景、所有的状态、所有的状态转移路径、所有的事件序列、所有可能的配置、所有可能的数据等等。即便如此，我们可能还是无法 100% 确信测够了。
2. 测试有效性（Test Effectiveness）
如何评价一组测试用例的有效性？有效性和充分性是两个正交的属性，评价测试用例有效性可以通过正向的分析进行，例如，分析测试用例是否校验了所有在测试过程中 SUT 落库的数据。更具有通用性的做法是变异测试（Mutation Testing），即在被测代码里注入不同的“人造 Bug”，统计测试用例能感知到多少。目前变异测试已经有工程化、规模化的落地，后续可以关注如何防止钝化也就是“杀虫剂效应”，以及关注对配置、数据等进行更全面的注入。
3. 测试用例瘦身
跑测试用例的时候有很多时间是浪费掉的，浪费的形式包括：
冗余步骤：每个用例都要去做一些类似的数据准备，执行一些中间过程（这样才能推进到下一步）。
等价类：一个支付场景，在所有的币种、所有的支付渠道和卡组的排列组合都测一遍。如果不这么做，可能会漏掉某个特定商户在某个特定币种的特定逻辑。
此外，假如你有 N 个用例，删掉其中的 M 用例也不影响 N 的效果，那么如何识别是否存在这样的 M 用例也是个问题。
删除测试用例看似简单，其实非常难。从原理上来说，如果测试充分度和测试有效性的度量都做得非常好、度量成本非常低，那么是可以通过大量的尝试来删用例的。这是一种工程化的思路，也许还有其他的理论推导的思路。
4. 测试分层
很多团队都会纠结到底要不要做全链路回归、做到什么程度。这个问题的核心点就是：有没有一种可能，只要约定好系统间的边界，就可以做到在改动一个系统的代码后，不需要和上下游系统进行集成测试，按照边界约定验证好自己的代码就能确保没有任何回滚了。
很多人相信这是可能的，但是，既无法证明，也不敢在实操中完全不跑集成。
5. 减少分析遗漏
分析遗漏是很多故障的原因。很多时候，分析遗漏属于“我不知道‘我不知道’”。
6. 用例自动生成
用例自动生成中，有时候难点不是生成 test steps，而是怎么生成 test oracle。
7. 问题自动排查
对于比较初级的问题，自动排查方案有两个局限性。一是方案不够通用，二是比较依赖专家经验，主要是通过记录和重复人肉排查的步骤来实现。然而，每个问题都不同，排查步骤很有可能出现不工作的情况、
8. 缺陷自动修复
阿里的 Precfix、Facebook 的 SapFix 等技术是目前缺陷自动修复的知名做法。但总的来说，现有的技术方案，都有这样或那样的局限性和不足，这个领域还在相对早期阶段，后面的路还很长。
9. 测试数据准备
测试用例的一个重要设计原则是：测试用例之间不应该有依赖关系，一个测试用例的执行结果不应该受到其他测试用例执行结果（包括是否执行）的影响。基于这个原则，传统的最佳实践是确保每个测试用例都应该是自给自足的：一个用例需要触发的后台处理流程应该由这个用例自己来触发，一个测试用例需要的测试数据应该自己来准备，等等。但如果每个用例所需要用到的测试数据都是自己来从头准备的，执行效率就比较低。怎么既不违背“测试用例之间不应该有依赖关系”的大原则，又能减少测试数据的准备时间呢？
以上是软件测试中的其中 9 个难题，受篇幅所限，其余 9 个会在下文继续分享，欢迎持续关注。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论