第3节 被挑战了

腾小宇在这样的环境中，每天努力工作，在完成培训计划的同时，也承担部分的测试工作，成长很快。直到有一天，他所在的测试组收到了一封邮件，来自平时一向表现稳重的一个业务部门的运营同事，原文大概如下：

致技术部的大牛们：

我一向认为自己谦虚友善、善于沟通，也尊重技术部同学的专业性和工作评估；但今天我忍无可忍，因为业务冲量迫在眉睫，所以希望能够修改激励用户的一个小小的奖励算法。

开发哥告诉我只要修改一个公共方法，三行代码；但你们的测试姐告诉我，因为不确定影响了哪些功能，为了确保不出问题，所以要测试所有的核心功能，一个全职投入的测试姐要一个星期的工作量。加上各种版本管理的时间，这样一个简单的需求，需要两周才能上线。

我们还是遵循敏捷研发流程的互联网企业吗？难道这个工作效率比有关部门会高一些吗？

我也是技术部出身，以前我曾深深地以技术部为荣，今天，我不得不以技术部为耻！

“这么劲爆的邮件！”腾小宇心里想，“要回复吗？该怎么回复呢？”可是，等了一个小时，两个小时，四个小时，还是没看到谁来回复这封邮件。可是，小宇注意到，自己的leader莎姐神色凝重的坐在那里，一言不发。

小宇心想：“不是在憋什么大招吧？”

可是，这一天就这么平静地过去了。转眼到了周末，大家又都各自忙各自的去了。

回归测试带给我们的痛苦

场景一：

开发哥：“刚修复了一个紧急用户反馈，安排测试测一下吧！”

测试姐：“改了哪些地方？对哪些功能有影响？”

开发哥：“改了好些地方，为了保险，把基本功能都测一下吧。”

场景二：

开发哥：“昨天的修改测试完成了吗？”

测试姐：“哥，别催！还在测试中，要跑500个用例呢！”

开发哥：“啊，我只修改了一行代码吧，怎么需要测这么多呢？”

对于以上对话，是否有似曾相识的感觉？作者不敢妄自揣测所有人都经历过，但在作者的职业生涯中，这样的情况很常见，至于结果，那就是留下测试人员独自在风中凌乱。测试为什么要测这么多地方？因为我们需要做大量的回归测试。

在最早的测试理论中，对回归测试的定义是这样的：“回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试作为软件生命周期的一个组成部分，在整个测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。内容通常是重复以前的全部或部分的相同测试。”

在测试实践中，回归测试需要反复进行，当测试人员一次又一次地完成相同的测试时，这些回归测试会变得相当令人厌烦，当大多数回归测试需要手工测试来完成的时候尤其如此。传统的测试理论是这样建议的：“在给定的预算和进度下，尽可能多地、有效地进行回归测试。”

在互联网的企业中，这种现象也非常常见：一个有一定的功能复杂度，开发测试人员在30～50人左右的产品，测试用例总量上万是很常见的事；即使我们只选取核心功能作为缩减后的回归测试用例，也高达2000～3000或以上。我们来看看一个实际的较大版本的测试工作量评估：

□ 开发工作量估算：35人月。

□ 测试工作量估算：13人月。

□ 第一批需求测试：约1000测试用例，需25人日。

□ 第一批回归测试：约800回归用例，需20人日。

□ 第二批需求测试：约800测试用例，需20人日。

□ 第二批回归测试：约600回归用例，需15人日。

□ 第三批需求测试：约900测试用例，需23人日。

□ 第三批回归测试（可能会和集成测试合并）：约600回归用例，需15人日。

□ 集成测试：约2500用例（主要指集成相关的测试用例集合），需63人日。

□ 整体回归测试：约3700用例（部分需求用例加上部分缩减回归用例），需93人日。

□ 预发布回归测试：约500用例，需13人日。

这个计划可能还是一个相对比较保守的计划，如果在开发过程中，由于开发过程质量比较差，出现比较多的bug，那么零散的回归测试会更多。

从这个计划上来看，实际上需求测试的用例执行次数约为2700次，回归用例的执行次数约为8700次。回归测试执行占总测试量的比例为76%，而且至少超过半数都不是新写的（新需求或需求的变化），为什么？多数团队从风险规避的角度出发，即使知道这样的测试必定是有冗余的（多么痛的领悟），也不得不扩大测试范围。“谎言重复一千遍就变成了真理”，在测试行业中，这种现象很普遍，测试人员甚至把这样的现象奉为方法论。