谬论：如果我们正在寻找很多程序缺陷，我们正在做重要的测试。
事实：找到很多程序缺陷的唯一好处就是告诉我们产品存在很多程序缺陷。它没有告诉我们测试覆盖的质量，程序缺陷的严重性，或是客户将在实际中碰到它们的频率。同样它也没有告诉我们遗留下多少程序缺陷。
停止找到程序缺陷的唯一确定方法就是停止测试。它看起来是荒谬的，但这个想法是有价值的。这个难题的症结在于指出产品的什么特性确实需要研究。我已经提到产品中的许多工作流实际没有被使用——并且如果它们没有被使用，它们就不需要被研究。直接在你的测试计划中合并客户使用知识以及缺点筛余机制提高了你预测客户影响和与缺点相关的风险概率。在你的测试计划解决中合并基于风险和客户分析将产生一个更加实际和实用的测试计划。一旦你对你的测试计划有信心，你可以在你已经执行计划之后停止测试。 [Page]
你如何建立那种信心？开始你的测试计划时要确定你需要测试的所有区域。让客户检查和评价商业过程并使用实例以便你懂得每一个被提议的测试实例的频率和重要性。要特别注意检查测试漏洞。对每一个迭代要持续更新和检查你的测试计划和测试实例。你的目标是找到什么没有被覆盖到。做到这个的一种方法是通过软件区域和测试种类来映射程序缺陷计数。如果一个软件区域没有被记录缺点，它可能意味着这个区域是十分有效的或者它还没有被测试。看缺陷文件的时间戳。如果最后的缺陷是去年公布的，可能它暂时不用被测试。找到错过的程序错误的模式是检查测试覆盖的一个重要技术。
谬论：完全的测试意味着测试 100% 的需求。
事实：测试需求是重要的，但是不是充分的。你还需要测试那些遗漏的事情。有什么重要需求的没有被列出？
找到没有被列出的是一个有趣的挑战。 迭代测试很早就使客户客户参与进来。客户懂得他们的业务如何进行和他们如何工作。他们可以告诉你你的应用软件中错过了什么，并且提出什么妨碍了他们需要完成的任务。
谬论：它是一个间歇的程序错误。
事实：不存在间歇的程序错误。问题是一直存在的——你只是没有指出正确的条件来复制它。提供可用的工具来持续监控执行，应用软件降级开始的自动校准，以及在降级的时候自动发出适当的数据（优先于应用软件实际崩溃）减少内部故障诊断时间和客户停工时间。迭代测试和迭代可用性活动都可以减少没有被发现的程序错误对商业的影响。
更加实用和好用的诊断程序增加了你的产品的客户价值。当你的产品开始升级时，通过前摄的监控环境，你可以减少分析时间甚至可以避免由于开始各种自动更正校准和工作区的例行程序而导致的停工。自治服务例行程序的这些类型增加了你的产品的可靠性，耐久性，和运行持续时间，甚至如果程序缺陷复制品的条件是未知的。 在某种意义上，自治的恢复例行程序提供了一个标准的持续的技术支持。环境记录和处理跟踪信息被自动收集并被发送，以用于更进一步缺点分析的开发，同时也提供了关于你的产品是如何被实际使用的重要数据。
如果我们承认程序缺陷是不可避免的，我们同样需要认识到适当有用的例行程序的重要性。这些自诊断和自行监控功能在增加客户价值和满意度中是有效的，因为它们减少了客户受程序缺陷消极影响的风险。然而即使这些例行程序增加了客户价值，只有少数几个开发周期被用于将这些过程归位。
谬论：产品应当在压力下被测试以验证性能、可伸缩性和耐久性。
事实：上面是正确的。但它的反面也是正确的。使一个应用软件保持在空闲，或长期处于暂停的状态来仿效客户去吃午饭或使应用软件在周末暂停，并经常暴露一些问题。[Page]
我推荐在你的功能测试方法中包括睡觉，暂停，中止，中断和睡眠状态恢复。仿效一个地理分布式工作环境，当你的应用软件处于中止或暂停状态，而其中的共享工件和数据库正在变化（正如同事们在其他人的业余时间在一个偏僻的地点工作）。测试当使用者“唤醒它”时发生了什么，这与他们被挂起的环境是不同的。然而更好的是将你的产品放到一个真实的客户环境中并运行仿效上面的一些场景的系统测试。
谬论：客户总是正确的。
事实：可能他不是一个正确的客户。你不可能使用一个发布来使每一个人都满意。因此，要在你的发布定义特性设置中有选择性。瞄准一个特殊的，高度概括的测试场作为用户的一种类型目标。然后对于下一个发布或迭代，选择一个不同的人群。你将更有效地测试；当你的产品成熟的时候，你将通过在不同阶段中增加满意的客户来增加你的客户基础。
谬论：自动化！自动化！自动化！
事实：在脑海中客观的看待自动化，并考虑 ROI。测试环境越象最终产品环境，测试的可靠性越高。如果客户的产品是100%自动化的，那么自动化！自动化！自动化！如果你的产品不打算在客户环境中实现自动化，那么你需要将自动化的，特殊化的，探查的以及客户场景的测试进行合并。
它同时对于扩展你的自动化定义有所帮助。自动化测试实例可以重复测试你已经手工测试过的区域。但是那不能增加你的测试覆盖或你对使用者对于应用软件是如何反应的理解。相反，创建自动化实际上允许你投入更多的精力在创造性的手工测试上。使事情自动化是你经常需要做的并且那将使你花费很长的时间来完成，象：
分解和建立原始环境来测试每一个构建。
对每一个构建，集成点，或迭代的全面验收测试。
跨越各种平台，操作系统和语言测试相同的套件，。
低级别组件的单元和命令行测试。
谬论：迭代开发行不通。
事实：它是人类对于未知和未尝试的领域怀疑的天然属性。在迭代开发经验中，每一个成功阶段的好处逐渐增加。因此，迭代方法的所有好处是只有在开发周期的末尾才被重视。对于第一个吃螃蟹的人来说，那个推迟的满意可以真正地成为信念的行为。我们没有使用方法的经验，并且所以我们不太信任即将使用的方法。当我们认识到时间正在流逝，我们放弃了信念并抛弃了迭代过程。在恐慌状态中，我们又回到了我们的老习惯。迭代开发多半没有实际失败。我们只是没有给它一个成功的机会。
迭代测试在迭代开发的累积好处的每一个迭代中提供了可见的记号。当团队共享增加的成功标准（例如，每一个迭代的进入和退出标准）时，站在正确的方向上是更加容易的。
因为我们根据出口标准持续监控结果，我们可以更容易地在迭代中调整我们的测试来达到我们的最终目标。例如，在中间迭代中，我们可以观察我们关键的和高缺陷计数在增长，并且我们可以比修正它们更快地找到它们。因为我们早已经认识到这个趋势，我们可以重新分配资源来加深对于关键路径活动的关注。我们可以再分配研究“乐意拥有” 特性的开发人员来修正“发布定义” 特性中的缺陷，或者删除与高缺陷计数有关的乐意拥有特性。
结论
我只接触到了我们假设每天都会遇到的软件开发的谬论中的少数一部分。如果我们假设做得越多，我们就会越少发现不可预知的事情——所有关于软件测试的。
不幸的是，我们提到的谬论是非常诱人的。它们被伪装成答案，并且它们方便地结束了对话。当我们人员不足并承受压力时，接受假设作为事实是非常诱人的。
因为我们经常难以分辨谬论和事实，我们需要检查我们的答案。这个简单而有效的颂歌，总结了我已经在这篇文章中论述的所有东西，将有助于你保持在正确的轨道上：迭代测试从来都没有满意的正确答案。
文章来源于领测软件测试网 https://www.ltesting.net/
