软件测试中不需要测试的八件事

     <div id="news_body">     <p> 英文原文：<a href="/misc/goto?guid=4958332665246489732">Eight Things You May Not Need To Test</a></p>     <p> <strong>不要测试它</strong></p>     <p> 做为一名测试人员，我们也许会问我们自己很多问题：</p>     <ul>      <li>我们可以立即执行的最好的测试是什么？</li>      <li>我将要使用的测试方法是什么？</li>      <li>这是一个 Bug 吗？</li>      <li>我已经测试完成了吗？</li>     </ul>     <p> 但是我们之中会有多少人提出以下的这些问题呢？</p>     <ul>      <li>这个组件需要一直被测试到吗？</li>      <li>需要由我来测试它吗？</li>      <li>如果它不工作，谁会去在意它呢？</li>     </ul>     <p style="text-align:center;"><a title="test" rel="lightbox[15054]"><img title="test" alt="test" src="https://simg.open-open.com/show/75f4b8ae80ee98c20925dfd62789f270.jpg" width="466" height="256" /></a></p>     <p> 在我看来，我们提出的问题中和以上三个问题类似的还远远不够。可能这是因为我们已经被告知要测试一切东西。甚至我们的一部分人会在其质量团队中有一个流程，要求某个人把每一个组件都贴上“已测试”的标签。我们对待测试就像一个常规的工厂程序，我们甚至有时候引以自豪的说…</p>     <p> “我是测试工程师。因此，所有的东西都需要被测试…由我来做…即使非测试人员已经测试过了…即使我已经知道它将会通过测试…即使需要一个程序员告诉我怎么去测试…我必须测试它，没有例外！”</p>     <p> 这类想法可能会让测试人员有一个坏名声。由于欠缺思考的过程导致它强调了测试的重要性，而不是给一些人提供最有价值信息的服务。</p>     <p> James Bach 带着以下的测试观点出现:</p>     <p> 基本的观点：“如果它存在，我就要去测试它”</p>     <p> 正如前面内容和我经常发布的文章中，我不同意这个观点。尽管如此，我完全同意 James 在 2006 年 8 月 7 日，他在博客发布的完整版本中关于这部分的介绍：</p>     <p> “如果它存在，我就要去测试它（唯一的例外是我有更重要的事情要做）”</p>     <p> 第二句话是可以有很多的理解方式！为什么呢？因为我们经常会有更重要的事情去做，通常是另外的测试工作！不幸的是，重要性往往不是区分的很明显。所以与其衡量重要性，我更喜欢提出上面的三个问题，去寻找那些可能不值得浪费我的时间去测试的东西。下面八个例子是我讨论的内容：</p>     <p> <strong>0.  不会在产品中出现的组件-</strong> 我的团队中在每次迭代中都有这些内容。例如增强功能中的错误记录表或者跟踪生产活动中的审查报告。在敏捷开发的团队中这些被归入开发者用户故事（Developer User Stories）。这些内容不会随便的在产品中出现并且由于其本质不会直接影响到用户。</p>     <p> <strong>1.  关键产品问题的补丁不会很糟糕</strong> – 一天下午客户给我们的技术支持打电话，由于我们的产品的一个阻塞性质的 bug 导致他们处于错过一个关键最后期限（DeadLine）的边缘。我们只有一个小时交付修复的产品。程序员很快的修复了问题，由于当前的产品是无效的，所以对修复之后进一步的产品存在的风险来说这是微不足道的。想要当英雄吗？不要让事情慢下来。快速的让产品通过测试。如果需要以后再去测试。</p>     <p> <strong>2.  界面问题修复要有适度的准备时间</strong> – 我们修复了一个在屏幕上出现的用户错误消息中的拼写错误。用户并没有察觉到拼写错误但是我们无论如何修复了问题。很快而且简单。触发这个错误消息需要 30 分钟的准备时间，值得吗？</p>     <p> <strong>3.  直接了当的配置改变</strong> – 去年我们产品开始偶尔出现很大的作业不能处理的问题。一个程序员尝试改变通用配置修复问题。但在 QA 的环境中没有一个简单的方法去创建一个足够大的作业超过这个临界值，很难去测试。我们在产品中修改了配置然后用户很高兴的为我们做了测试。</p>     <p> <strong>4.  技术性的需要非程序员的测试</strong> – 测试部分功能时需要实施某种行为而在代码中设置断点来复现竞态条件.有时测试人员与工具和程序员精通产品代码的知识并不匹配。讨论这个测试但是回避它。</p>     <p> <strong>5.  非测试人员借用</strong> – 如果团队中一个非测试人员帮忙去做测试工作，或者更重要的，想帮忙测试某一组件，让他去做吧。跟他分享测试的思路并且跟他要测试报告。如果你觉得满意，不需要再去测试它了。</p>     <p> <strong>6.  没有复现步骤</strong>- 程序员偶尔会尝试某些东西。经常会出现一些错误报告，但是没有人能对这些错误给出确切的重现步骤。我们也许想对修改的区域做回归测试，但是我们发布的时候不会阻止这种明显的修复，因为我们不知道它管不管用。</p>     <p> <strong>7.  不足的测试数据或硬件</strong> – 让我们面对它吧。在我们 QA 的环境中，根据产品中所需要，大部分情况我们没有足够多负载平衡服务器。当一个有效的测试需要的资源在产品使用环境之外不可用时，我们可能无法对其进行测试。</p>     <p> 很多人也许尝试想像上面这些如果不去测试会导致的问题。我也会做这些。记住，这些事情也许不值得花费我们的时间去测试。再次权衡你所做的事情，如果在不是很清楚的时候，去问问利益相关者。</p>     <p> 如果你选择不去测试某些东西，很重要的是，不能被我误导。这是在我的团队中使用到方法。在我们进行组件审查时，我们的（测试人员）说，“我们将不会去测试这些”。如果有人反对，我们会改变我们的想法并且测试它。如果没有人反对，我们就“未经审查即批准（rubber stamping）”。即表明没有被测试就让它通过这样可以让他进入到最终产品。</p>     <p> 所以下次你发现你自己正在着手做的测试，感觉比其他你应该做的事情更不重要时，你应该需要考虑…不去测试它。逐渐的，你的团队将会尊重你的决定并受益于更少的瓶颈，以及在你实际增加的价值的地方增长的覆盖率。</p>     <p> 编译：<a href="/misc/goto?guid=4958185140659301754" target="_blank">伯乐</a>在线 – <a href="/misc/goto?guid=4958332666815408688" target="_blank">李岩</a></p>    </div>