阿里P8测试工程师：软件测试中的18个难题，搞明白去和面试官battle

对于软件测试来说，怎么样才算测够了?如何评价测试的有效性?那么多测试用例，以后怎么删?在软件测试中会遇到非常多的问题，阿里研究员、软件测试工程师郑子颖分享了18个他总结出的难题以及相关看法，希望对同学们有所启发。

对于软件测试来说，怎么样才算测够了?如何评价测试的有效性?那么多测试用例，以后怎么删?在软件测试中会遇到非常多的问题，阿里研究员郑子颖分享了18个他总结出的难题以及相关看法，希望对同学们有所启发。

十多年前我在上一家公司的时候看到过内部有个网站有一个Hard Problems in Test的列表，上面大概有三四十个问题的样子，是各个部门的测试同学提供的。但可惜后来那个list失传了，我很后悔自己当时没有保存一份。后来很多次我都想要找到那份list，因为上面列的那些问题指出了测试专业在自身专业性上的巨大发展空间。那份list上的问题让当时的我相信，软件测试这件事情本身的难度一点都不亚于软件开发，甚至可能更难一点。

如果今天要重建这么一份Hard Problems in Test列表，下面这些问题是我会加到这份列表上的[1]。

一 测试充分度(Test Sufficiency)

如何回答“测够了吗“(包括测新和测旧)。代码覆盖率是衡量测试充分性的起点，但远远不是终点。要回答”测够了吗“，至少还要考虑是否测了所有的场景、所有的状态、所有的状态转移路径、所有的事件序列、所有可能的配置、所有可能的数据等等等等。即便如此，我们可能还是无法100%确信我们已经测够了。可能我们最终只能做到非常趋近于测够了[2]。

二 测试有效性(Test Effectiveness)

如何评价一组测试用例的发现bug的能力。有效性(发现bug的能力)和充分性(测够了没有)是两个正交的属性。评价测试用例有效性可以通过正向的分析进行，例如，分析测试用例是否校验了所有在测试过程中SUT落库的数据。更具有通用性的做法是变异测试(Mutation Testing)，即在被测代码里注入不同的“人造bug”，统计多少能被测试用例感知到。目前变异测试我们已经有工程化规模化的落地了，后续的工作重点有：1)如何防止钝化(或曰“杀虫剂效应”)，2)不但对被测代码进行注入，还能对配置、数据等进行更全面的注入。

三 测试用例瘦身

以前广告行业有句话：我知道广告费有一半是浪费掉的，但不知道哪一半是浪费掉的[3]。

软件测试也有类似的困惑：那么多用例，要花那么多时间去跑，我知道这里面有很多时间是浪费掉的，但我不知道哪些时间是浪费掉的。浪费的形式包括：

• 冗余步骤：有些是浪费在一些重复的步骤上，每个用例都要去做一些类似的数据准备，每个用例都要去执行一些中间过程(这样才能推进到下一步)。
• 等价类：一个支付场景，我要不要在所有的国家、所有的币种、所有的商户、所有的支付渠道和卡组的排列组合都测一遍?这么测，代价太高。不这么测，我担心可能某个特定商户在某个特定国家有个特定逻辑我就漏掉了。对于具体的业务，还可以进行人肉分析。有没有更通用的、而且比较完备和可靠的等价类分析的技术手段?
• 我有N个用例，我猜这N个用例里面可能存在M个用例，即使删掉这M个用例，剩下的N-M个用例的效果和之前N个用例的效果一样。如何识别是否存在这样的M个用例、如果存在的话是哪M个。

我参加过内部一场质量线晋升到P9的评审，当时有个评委问了那位同学一个问题：“那么多测试用例，以后你怎么删”。这个问题看似简单，其实非常难。我觉得，从原理上来说，如果测试充分度和测试有效性的度量都做的非常好了、度量成本非常低了，我们是可以通