关于测试和测试人员

     <p><strong>本文的作者Sriram Krishnan是一名程序员，曾在Yahoo和微软工作过，开发过很多软件，曾被纽约时报<a href="/misc/goto?guid=4958330045199715072" target="_blank">报道</a>，写过<a href="/misc/goto?guid=4958330046025349256" target="_blank">一本书</a>，本文是他的一篇博客。<br /> </strong></p>    <p>这些年来，我对测试工作、测试人员，以及整个软件质量管理体系形成了一些明确的观点。受一篇关于非死book的测试的<a href="/misc/goto?guid=4958330046820647877" target="_blank">帖子</a>的启发，我想把这些写下来，用以拿给人看。有些观点是有争议的。事实上，即使在交谈中稍微表现出这样的看法，都会招致人们的鄙视。</p>    <ol>     <li>大多数的开发团队并不需要一个独立的测试角色。即使有一个，他的所有的开发时间比上所有的测试时间应该 >20:1。证据吗？光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的非死book，还是30年前最初的NT团队，很多伟大的产 品都是出自没有或很少测试人员的团队。</li>     <li>开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。</li>     <li>我有一些政治上不正确的话要说。一些大型的软件开发公司会从一些不能胜任开发工作的程序员中选择测试人员。我经历/听说过很多在面试开发人员过程 中有人说“他/她做开发不行。也许可以做测试？”这导致了一个被广泛默认，但很少公开宣称的认识：做测试的不如做开发的聪明。正是由于这普遍的偏见，少数 一些对质量和测试工作极具热情和天赋的人受到了不公平的待遇。我知道他们，因为我曾经和一些这样的人一起工作过。</li>     <li>追求代码测试覆盖率是危险的。因为它很容易测量，它经常会变成真正目标的替代品——开发有质量的软件。如果你的开发团队把功夫都用在写愚蠢的测 试，来覆盖每一个罕有能用到的代码路径——因为这些数据会出现在一些报告里——你有问题了。测试覆盖率只是我们用的的很多指标中的一个，你需要使用它，但 并不是因为它以自然的数字呈现，它就能压倒其它指标。它成了<a href="/misc/goto?guid=4958330047613292725">古德哈特法则</a>的牺牲品。</li>     <li>我也曾看到有些公司里有独立的测试人员，他们写出非常好的测试代码。不幸的是，这被人们当成了一种常识，即使是在根本不需要这样的时候。</li>     <li>正像测试覆盖率被过度使用，有些质量指标是被忽略轻视了。比如：过程中产生了多少技术支持邮件？自己是否在任何时候都在真正的使用自己的产品，检测里面的问题？分析从生产环境和客户安装那里产生的日志文件。所有的这些策略都在上面的非死book的帖子里有提到过。</li>     <li>技术领导的一个常见的减少测试队伍的体积的办法是做自动化测试。这是个巨大的错误。如果你有一个用户直接接触的产品，你绝对需要用人眼去测试它。 如果你和微软Windows团队的人坐下来一起和咖啡，你会听到他们抱怨过度依赖自动化测试导致了Windows Vista大量的bug。这个错误说明的问题就是：你需要一个全职的测试人员来使用你的产品。</li>    </ol>    <p id="page-note">[本文英文原文链接：<a href="/misc/goto?guid=4958330048410010503">On testers and testing</a> ]<br /> 本文转载自: 外刊IT评论 <a href="/misc/goto?guid=4958183272158702965" rel="nofollow" target="_blank">http://www.aqee.net/</a> </p>