本节书摘来自华章计算机《Web测试囧事》一书中的第2章，第2.1节，作者 黄勇 雷辉 徐潇 杨雪敏，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

第2章

功能测试：测试覆盖篇

第1章我们已经介绍了在功能测试中最常出现的由于代码实现的技术手段所导致的问题，其实还有不少Bug是由于我们在测试过程中测试覆盖率不够造成的。

现在让我们来一起看看测试覆盖率不足会造成什么样的问题，以及如何有效地设计测试用例避免出现这些问题。

2.1　设计测试时对需求分析不透彻导致给予用户错误的折扣

网站最开始上线时就具备了类似“竞价排名”的功能——“优先显示”，可以帮助客户把自己的商品更靠前地显示给用户，增加商品的曝光率。这一功能分为4个级别：金牌用户（每年100 000元，1000件商品展示）、银牌用户（每年80 000元，600件商品展示）、铜牌用户（每年50 000元，300件商品展示）以及标准用户（单件商品收取200元展示费）。用户默认是标准用户，只有付费之后才能升级到不同的级别，而不同级别用户的商品，其展示方式和优先级也是不一样的：金牌用户的商品会显示在银牌用户的商品之前，银牌用户的商品会显示在铜牌用户的商品之前，依此类推；金牌用户的商品也会显示得更明显、更突出，其次是银牌用户的商品，再次是铜牌用户的商品，最后是标准用户的商品（见图2-1）。

上线之后不少用户反馈会员收费比较贵，业务方针对这一情况，决定当非标准用户次年续费的时候，给用户打75折。而且针对金牌用户这种大客户，当展示的商品超过1000件，可以享受8折优惠。

小蔡在测试这部分新增功能的时候，首先就遇到了需求不明确的情况：对于金牌用户超过1000件商品享受8折的基准费用，究竟是75折后的价格，还是以单件商品对于会费的均价，抑或是标准展示费用？她觉得应该是按75折的计算，因为这样对用户有利，用户会因为价格更优惠而进行多次购买；而开发人员则认为是以标准展示费用为基准费用，因为会费和超量展示费用中的所有数值都不是固定值， 而是拿参数计算出来的。如果基准是标准展示费用，就能大大简化计算逻辑。

在相持不下时，老牛建议她们去找业务方确认，最后得到的答复竟然是双方都没有选择的——以单件商品对于会费的均价的8折计算，也就是100 000/1000×80%=80元。

确定了需求之后，小蔡又发现在一种特殊场景下，优惠的计算是错误的：当用户第1年是银牌或者铜牌用户，觉得商品展示数量不够用，所以第2年升级到金牌用户，并且展示的商品超过了1000件时，用户得到的8折优惠是基于银牌用户或者铜牌用户的单价展示价格。

与此类似，如果用户第1年是金牌用户，但是第2年变成了银牌或者铜牌用户，超出600/300件商品的折扣却是基于金牌用户价格来计算的；更有甚者，即使变成了标准用户，但其所有商品的展示价格仍然都是基于金牌用户展示价格来计算的。

小蔡认为这个问题在于计算逻辑的复杂，所以就使用了正交试验设计法、边界值分析、等价类划分等测试用例设计方法，列出了所有测试数据和期待结果，然后把下面这些测试场景交给开发人员和业务方，希望避免出现更多的问题或者遗漏问题。

1）标准用户，第1年，100件商品，收费20 000元。
2）铜牌用户，第1年，0～300件商品，收费50 000元。
3）铜牌用户，第1年，n件（n＞300）商品，收费50 000 + 50 000/300×（n - 300）元。
4）银牌用户，第1年，0～600件商品，收费80 000元。
5）银牌用户，第1年，n件（n＞600）商品，收费80 000 + 80 000/600×（n - 600）元。
6）金牌用户，第1年，0～1000件商品，收费100 000元。
7）金牌用户，第1年，n件（n＞1000）商品，收费100 000 + 100 000/1000×（n -
1000）元。
8）铜牌用户，连续两年为铜牌用户，0～300件商品，收费50 000×75%=
37 500元。
9）铜牌用户，连续两年为铜牌用户，n件（n＞300）商品，收费37 500 +
50 000/300×（n-300）元。
10）银牌用户，连续两年为银牌用户，0～600件商品，收费80 000×75%=
60 000元。
11）银牌用户，连续两年为银牌用户，n件（n＞600）商品，收费60 000 +
80 000/600×（n - 600）元。
12）金牌用户，连续两年为金牌用户，0～1000件商品，收费100 000×75%=
75 000元。
13）金牌用户，连续两年为金牌用户，n件（n＞1000）商品，收费75 000 +100 000/1000×80%×（n - 1000）元。

这次拿给业务方确认的时候果真又出现了问题：业务方希望更多的非标准用户选择金牌用户，所以对于铜牌和银牌用户（包括金牌用户第1年），超量商品的价格应是标准用户的价格（200元）。所以包含测试数据的场景应该如下。

1）标准用户，第1年，100件商品，收费20 000元。
2）铜牌用户，第1年，0～300件商品，收费50 000元。
3）铜牌用户，第1年，n件（n＞300）商品，收费50 000 + 200×（n - 300）元。
4）银牌用户，第1年，0～600件商品，收费80 000元。
5）银牌用户，第1年，n件（n＞600）商品，收费80 000 + 200×（n - 600）元。
6）金牌用户，第1年，0～1000件商品，收费100 000元。
7）金牌用户，第1年，n件（n＞1000）商品，收费100 000 + 200×（n - 1000）元。
8）铜牌用户，连续两年为铜牌用户，0～300件商品，收费50 000×75% = 37 500元。
9）铜牌用户，连续两年为铜牌用户，n件（n＞300）商品，收费37 500 + 200×
（n - 300）元。
10）银牌用户，连续两年为银牌用户，0～600件商品，收费80 000×75% =
60 000元。
11）银牌用户，连续两年为银牌用户，n件（n＞600）商品，收费60 000 + 200×
（n - 600）元。
12）金牌用户，连续两年为金牌用户，0～1000件商品，收费100 000×75% =
75 000元。
13）金牌用户，连续两年为金牌用户，n件（n＞1000）商品，收费75 000 +
100 000/1000×80%×（n-1000）元。

当业务方确认了所有的测试场景后，小蔡和开发人员终于搞清楚业务需求究竟是怎样的了，也更有信心一次性全面地实现对应的功能，而非之前不断地对新发现的问题修修补补。她还发现，当遇到这种复杂逻辑的时候，必须使用清晰而明确的场景，甚至需要包含数据，才能让所有人对于同样功能的认识达成一致。

小蔡把自己的想法告诉了老牛，老牛告诉她，业界对这种实践已经归纳出一套理论方法，名叫“实例化需求”（Specification By Example，SBE），她可以多了解一下，同时在产品测试中实践。