软件测试工程师的角度看论证学问

软件测试工程师的角度看论证学问

　　争论与论证从来都不是新鲜事物，作为软件行业的科技工作者，理应对各种论证的手段了如指掌才是。然而，从各种我参与的有争论的场合来看，事实并非如此。许多论证最终都停在口号式的结论，或是由于自说自话无法进行下去。科学对人类的贡献之一在于科学的方法，而“合理”的论证方式才是科学真理得以彰显的手段。

　　《论证是一门学问》一书中提到了论证的基本规则，以及各种论证的方式：类比论证、因果论证、演绎论证。这些方法都不是什么难度很高的方法，但在实际的争论过程中，尤其是在微博上进行的论证中（字数的限制也是导致误解的原因之一），却并不经常被论证的双方所遵守。

　 　一个观点包含“前提”和“结论”。前提是为你的结论提供理由的表述。前提一般基于具体的事实或是已经被事实证实的结论，通过前提，借助各种论证的方法就 能推导出结论。这个过程看似简单，在很多情况下却并非显而易见。《论证是一门学问》一书的第3页给出了《福尔摩斯全集》中的《银色白额马》中福尔摩斯的一 个推论过程：

　　马厩里养着一条狗，然而，尽管有人进入马厩并牵走一匹马，（这条狗）却没有叫……显然，……来者是这条狗相当熟悉的一个人。

　　在这个推论中，福尔摩斯有两个前提。一个显而易见的前提是，狗没有冲着来人叫；另外，福尔摩斯使用了一个他认为我们都会认可的前提：狗会冲着陌生人叫。这两个前提合起来，便能够得出他的结论：来人是狗熟悉的人。

　　接下来我们用几个更贴近各位工作实际的例子来展示不合理的推论过程。

　　例1：

　　软件测试工程师懂得开发后，会从开发的角度思考问题。这样测试工程师就不能起到与开发工程师在思路上互相补充的效果了。

　 　这个推论过程是一个典型的假言三段论（Hypothetical syllogism，见《论证是一门学问》P80），这里的要点是，只有在连续的两个推论都都没有问题的情况下，最后的结论才是有效的。这里的两个推论分 别是：1，如果软件测试工程师懂得开发，就会从开发的角度考虑问题；2，如果测试工程师从开发的角度考虑问题，就无法起到与开发工程师在思路上互相补充的 效果。

　　显然，对第一个推论，其要害在于，是否一个人懂得了某种思考方式，就一定会应用这种思考方式？答案显然是否。很容易用反例方法推翻这个推论：成人通常也可以懂得儿童的思维方式，但这并不意味着他一定会用儿童的思维方式去思考问题。实际生活中，大多数父母都能够在懂得儿童思考问题的同时用成人的思考方式考虑问题。

　　因此，由于第一个推论就不成立，最终的结论显然不可靠。

　　例2：

　　很多组织甚至认为独立的测试团队是不需要的，这种观点是错误的！他们认为测试不重要是因为他们对质量不重视！。

　 　这里的前提有两个：1，很多组织认为独立测试团队是不重要的；2，这些认为独立测试团队不重要的组织不重视质量。很显然，稍微深入一点探讨这个结论，就 很容易发现，“很多”这个前提没有数据来源，可能仅仅是推论者的一个主观感觉；另外，由于“很多组织”本身就是一个虚拟出来的概念，更谈不上有任何实例来 说明“很多组织”中的这些都是对质量不重视的公司。反而，针对这个论断，容易举出好些反例来证明它是不可靠的（大多数互联网创业公司都会在很长一段时间内不设置独立的测试团队）。

　　关于例1和例2提到的话题，我并不想在这里进行讨论。拿它们做例子，不过是说明一个有效的论证应该是什么样子的。

　　论证中，一方面需要为自己的观点提供可靠的前提，提供合理的逻辑推断过程，同时也需要对自己不认同的观点提出置疑和反驳。与众不同的观点并不可怕，可怕的是无法以符合逻辑的方式捍卫自己的观点。

　　当对自己不认同的观点提出置疑的时候，反例是最简单的方式。但要举出反例，必须清楚的了解对方观点的定义。由于所有观点就是基于前提（事实）和推理过程的，证明对方的前提的不正确性，或是证明对方的推理过程的不正确性同样奏效。例如，有以下观点：

　　例3：

　　Google的测试工程师与开发工程师的比例是1：10，因此只需要少数的测试工程师就能做好测试工作。

　　这里的前提有三个：第一个是显而易见的前提，“Google测试工程师与开发工程师的比例是1：10”；第二个是隐含的“Google的测试工 作做的很好”；第三个前提隐藏得更深，“Google的测试工作完全是由测试工程师来做的”。这三个前提中的任何一个不成立都会导致这个结论不成立。在我 看来，最容易被击倒的是第三个前提（“Google的测试工作完全是由测试工程师来做的”），实际上，这个在Google内完全不成立。但有趣的是，相当 多的对这个观点的辩驳都集中在第一个和第二个前提上。

　　例4：

　　Google的X项目的工程师共有15名，其中测试工程师4名，因此Google所谓的开发与测试人员的比例是1：10是不真实的。

　　很显然，这个论断根本就偷换了要反驳的结论。“Google的开发与测试工程师比例是1：10”并不等于“在所有Google的项目中开发与测试的比例都是1：10”。因此，要推翻这个前提，其实最简单的方法是拿到Google的开发工程师与测试工程师的总人数比例。

　　例5：

　　Google的产品经常出现bug，因此Google的测试做的并不好。这些不好都是由于Google的测试工程师太少造成的。

　　可靠的前提才能建立可靠的结论。说Google的产品经常出现bug，最好拿出相应的数据。这方面James A. Whittaker显然就老练得多，这哥们在自己blog的为什么要离开google的文章中用了一些他自己的感知数据证明这一点。不过即使这 样，Whittaker也没有说“google的测试做的不好”，原因是“好”与“不好”根本就没有数字上的标准，bug数多少叫做好？bug的影响范围 （人数）与造成的失效成本要不要计算？这个推论的第二个部分则更是“冲动论证”的典型。它同样隐含了两个前提：1，在google中，发现缺陷是测试工程 师的职责；2，测试工程师数量的多少与产品中遗留缺陷的数量呈负相关。可惜的是，这两个前提都不能够成立。

　　啰嗦了一堆文字，也给出了一些我自己能看到和听到的不合理的论证，不过，这篇文章的用意并不是想在这些例子涉及到的问题上挑起争端，而只是希望大家都能够用更好的论证方式捍卫自己的观点，以及看待别人的观点。

　　我经历过和了解到的中国的学校（大学、中学、小学均如此），大多都不太在意对学生论证能力的培养，作为这个体制中被培养出来的一员，我在很长时 间内一直没有掌握正确的论证方法。但随着工作中的体验越来越多，接触到了越来越多的优秀同事，才发现自己身上缺少的这种论证方法的确会影响到自己的发展和 工作。鉴于此，我希望通过本文，能够让更多的工程师，尤其是测试工程师了解到论证的方法，希望有更多人能从论证中找到棋逢对手的乐趣。