本故事纯属虚构，如有雷同，纯属巧合
“更少的测试用例达到同样的效果？”大毛思索着领导说的话，“这还是为了我为了大家？”
“搞不懂啊。”大毛叹了口气。
领导又换了个话题。当然了，大毛习惯了。
“你没负责过一个组件的完整测试流程对吧？”
“那我上个星期设计了测试用例，这算吗？”
“那就是没试过啦。这样吧，你就负责这个组件的质量，业绩这样算：设计的测试用例要在代码完成之前准备好，发布之前执行完，发布之后才暴露的bug少于每千行代码3个（见作者注1）。做不到就没奖金，如何？”
大毛的脑门上顿时冒了一堆的汗。
这可不是开玩笑的，大毛重新翻出全部的资料：功能说明、设计说明、计划明细表、其它组件的测试用例文档……从来不看的文档也被找出来左看右看，从来不注意的日期和数字都琢磨有没有关系。“像疯狗一样刨了一个星期，”大毛这样形容自己，“捣腾出生平第一份测试计划。”
领导打开一看，一个Excel表格列着所有要执行的测试用例，不禁开怀大笑起来。
“大毛啊。”
“嗯……”
“拿纸笔记着。”
……
“每个测试用例都执行多少次？”
“呃……”
“如果没有时间执行的话，你打算放弃哪些？”
“不好吧，我可是忙了一个星期弄出来的。”
“那你像以前一样把它们全执行完，好吧？”
“别介嘛，我把不重要的挑出来好了。”
“所以测试用例是有优先级的，并且有些需要重复执行，有些执行一次就好，重复执行的频率也不一样。记下来这个。下次我要看到每个测试用例都落到合适的优先级和频率上。”
……
“这些测试用例，大概五十多个吧，需要执行很长时间吧？”
“嗯，一个得一个多小时吧，需要准备和导入数据，所以很费劲。”
“你打算多久重复一次？”
“恐怕只能一个月一次了，但其实我认为一天一次比较合适，这些测试用例还是比较重要的。”
“那一个就一个多钟，五十个就得五六十个钟，这五十个用例就得八个人一起才能每天完成一次了。”
“是不太靠谱。”
“那你说是多招人来执行还是你去重新设计测试用例呢？”（见作者注2）
“……明白，重新设计要容易，应该能改善不少。”
“那就记下来。下次我要看到为了测试这一系列功能的用例在两个钟头内完成。”
“那就得每个用例在两分钟内完成？”
“为什么一定要这么多用例呢？是碰巧做出来那么多还是深思熟虑想出来的结果呢？”
“没想那么多啦，想到一个写一个的。”
“好好想想怎样合并测试步骤和缩减费时步骤，你就把它当成程序性能调整好了。”
……
看着记得满满的本子，大毛欲哭无泪，奖金怕是要泡汤了。
领导看着大毛的表情，乐翻了。
“如果你不负责这个组件的质量，就不用关注这些东西了吧？”
“是啊，不当家不知油盐贵啊。”
“现在知道为什么要更少的用例达到同样的效果了吧？”
作者注：网上搜一下test plan template可以找到不少测试计划模板作为参考。绝大部分都会说明做什么和怎么做，但说明为什么这样做和做的代价的则不多，这缺少的两点，分别是测试策略和成本分析。后者往往是测试团队加班和延迟的原因之一。前者嘛，大毛很快就不得不要面对了。
作者注1：参见代码大全（第二版）http://book.douban.com/subject/1432042/。微软应用程序部门的经验显示，发布前平均找到的bug是10到20个每千行代码，发布后则是0.5个。此外，航天等人命关天的软件能达到每50万行代码0个。
作者注2：还是有打算招人的例子的，当然了，那是最后无可奈何的选择。
1360
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
