本故事纯属虚构，如有雷同，纯属巧合
大毛小心翼翼的试着写了一些代码，同事们也帮忙出主意做检查，毕竟领导请吃饭的机会还是要争取的。
然而正当大毛觉得胜利在望之际，领导忽然站到他后面说：“你继续干活，不用管我。”
大毛耸耸肩，继续写代码。这次要完成的是一个单元测试，确保提交代码的质量。大毛实现了一系列行动来模拟用户的一个主要应用场景。要是这个测试通过，应该是可以提交了。
谁知道还没写完，领导就叹了一口气：“好啦，这顿饭没戏了，大家要报仇雪恨的就找大毛吧。”
“啥？”大毛差点从椅子上摔下来，“老大你太赖了，你得给我一个说法！”
同事们也围上来听，当然主要是不甘心到手的请客机会丢了，意图声援大毛。
“好啊，我问你，这个测试的目的是什么，为什么要自动化？”
“这是保证提交质量的，通过了就可以提交。自动化的原因一是短时间来执行大量测试，二是让开发人员不需要了解测试步骤也可以执行这个测试。”
“通过了就可以提交，那么不通过就不能提交是吧？”
“对啊。”
“为什么呢？”
“那还用说吗，你看这些、这些、这些步骤，不通过就是大问题了。”
“那倒数第三个步骤呢？”
“呃，这个，小问题，但是它是功能说明上列出来的主要应用场景的一个步骤啊。”
周围同事也看出来不对了，有人说：“不对吧，这个步骤出问题只影响比较次要的功能的。”
“那我是按照功能说明来做的嘛。”
“大毛啊”领导把话题引回来，“你也觉得有些步骤不通过不代表是严重问题，对吧？”
“嗯，对。”
“而且你的自动化测试的确满足了当初需要达到的目的，执行时间够短，开发人员也不需要了解测试步骤，对吧？”
“对啊，那你当初不是说我会忘记最初的目的……”
“我知道，只是你还不经意的附加了多一个目的，把功能说明上的一个主要应用场景全部实现，对吧？”
“呃，我开始没打算这么做，后来慢慢有这个想法。”
“那么原先的要求是没有大问题就可以提交，现在的结果是需要通过较次要的功能才能提交，对吧？”
“嗯，是这样的。”
“那么你就把提交代码的质量要求提高到一个地步，就是必须全部通过一个主要应用场景的各个步骤。我们可以达到这个地步，但实际上并不需要达到这个地步。”
“提高质量要求不是更好吗？”（见作者注1）
“较次要的功能如果为了准时发布或者达到商业竞争的目的，完全是可以牺牲的，也就是说有可能为实现其他更重要的功能而削掉它。那么你在每次提交都要执行的测试里面去检验这个步骤能否通过，显然没有必要，而且迫使每一个开发人员随时关注这个功能，以及为了提交成功一直照顾这个功能。”
“哦，我懂了。像阿德的代码并不涉及和依赖这个功能，但是他每次提交代码都得确保这个步骤没错，其实没有必要。”
“那认输不认输？”
“我……我要搞明白一个问题，怎样找到不重要的步骤呢？我总是下意识的按着功能说明走。”
领导拉过一个白板，在上面画了一些大写字母并且用箭头连接起来。
“你提到依赖，这很好。看看这些字母代表各个步骤或者子功能，有些步骤取决于另外一些步骤，举个例子，记事本程序的显示文本文件内容功能依赖于文本文件打开功能。我用箭头表示依赖关系，A指向B表示A依赖B；没箭头的线则表示谁先谁后没有关系。
“有些步骤是相当重要的，例如记事本程序的保存功能，写半天字没法保存，是严重的数据丢失问题。我在这些代表重要步骤的字母上画个圈。
“重要的步骤，也就是画圈的步骤，加上它们所直接和间接依赖的所有步骤，也就是从圈开始顺着箭头走遍的所有步骤。其它的步骤都是不重要的，不需要出现在保证提交质量的测试中。如果一个步骤后来被认为是重要的，可以，在这个图上面再走一次。”
“我请你吃饭好了，老大。”大毛说。
作者注：如果有开发人员明明测试通不过，还是要提交代码，这往往是开发和测试团队结下矛盾的开始。先不要激动，听听开发人员怎么说，如果是埋怨通不过的步骤，可以尝试一下依赖图的方法，并且和开发人员分享这个依赖图。因为高标准严要求，不见得是合适的。工程问题要用工程方法解决，不要用哲学方法解决。
作者注1：这个理由可是通杀四方的大道理，谁遇上它都无言以对。只是照这个逻辑，所有测试，——包括整合、性能、可靠性、压力……全部家当加起来都通过才能提交，岂不是最高的质量标准？那质量一定很好了吧？实际上，这样做的话，没人能够顺利提交，或者要花大量时间才能提交。没有做完的产品，或者没法按时做完的产品，何来质量可言？
5827
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
