软件测试中的典型测试错误

测试软件或计划测试工作时很容易出错。许多不同的人如此频繁、如此反复地犯一些错误，以至于他们应该被贴上经典错误的标签。

在测试软件或制定测试工作计划时，很容易犯一些错误。有些错误往往是很多不同的人反复犯的，应该归为典型错误。

经典错误被有效地分为五组，我称之为“主题”:

典型的错误可以有效地分为五组，我称之为“主题”。

测试的角色:测试团队为谁服务，以及如何服务？

测试的角色:谁对测试团队负责，如何做？

计划测试工作:整个团队的工作应该如何组织？

制定测试工作计划:整个团队的工作应该如何组织？

人员问题:谁应该测试？

人事问题:谁应该做测试？

工作中的测试人员:设计、编写和维护单独的测试。

工作中的测试人员:设计、编写和维护各种测试。

技术泛滥:针对难题的快速技术修复。

过度使用技术:对困难问题的快速技术修复

这篇论文我有两个目标。首先，它应该识别错误，把它们放在上下文中，描述它们为什么是错误，并提出替代方案。因为一个错误的背景通常是之前的错误，所以论文是以叙述的方式写的，而不是可以以任何顺序阅读的列表。第二，论文应该是一个方便的错误清单。出于这个原因，经典错误出现在文本中时会用更大的粗体字印刷，并且在结尾也有总结。

本文有两个目标。首先，我们应该识别错误，将它们放在特定的环境中，描述为什么它们是错误，并给出替代方法的建议。因为一个错误的具体环境通常是一个先决错误，所以本文将以叙述的方式描述它，而不是以任何顺序阅读的列表。第二，这篇文章应该是一个易于查看的错误列表。由于这个原因，文章中的典型错误会用大号粗体字打印出来，并在文章末尾进行总结。

尽管这些错误适用于所有类型的软件项目，但我特别关注的是商业软件产品的测试，而不是定制软件或安全关键或任务关键的软件。

尽管这些错误中的许多适用于所有类型的软件项目，但我的重点将是商业软件产品的测试，而不是定制软件或高度安全或任务关键型软件的测试。

这篇文章本质上是一系列测试过程的错误报告。你可能会认为有些是特性，而不是bug。你可能不同意我指定的严重程度。您可能需要更多的信息来帮助调试，或者自愿提供您自己的信息。任何像样的bug报告系统都会将原始的bug报告视为对话的第一部分。这篇论文也应该如此。因此，请点击此链接继续讨论这一主题。

本文主要是测试过程中的一系列错误报告。你可能会认为有些是功能问题而不是bug。你可能不同意我设定的严重程度。您可能需要更多信息来帮助解决错误，或者您可能希望提供自己的信息。任何设计良好的错误报告系统都将原始错误报告作为对话的开始。本文也是如此，大家可以按照链接参与这个话题的讨论。

主题一:测试的作用

主题1:测试的角色

人们犯的第一个主要错误是认为测试团队负责保证质量。这个角色，通常分配给组织中的第一个测试团队，使它成为最后一道防线，开发团队(被指控生产了糟糕的质量)和客户(必须保护客户免受其害)之间的屏障。它的特点是有一个测试团队(通常称为“质量保证小组”)有正式的权力阻止产品的发货。这本身就是一个令人沮丧的任务:测试团队不能提高质量，只能执行最低水平。更糟糕的是，这种权力通常是表面上的，而不是真实的。发现这一点，再加上告诉开发人员质量是其他人的工作的不正当动机，导致测试团队和测试人员幻灭，愤世嫉俗，并认为自己是受害者。我们从戴明和其他人那里学到，当每个人在开发的每个阶段都对他们的工作质量负责时，产品会更好，生产成本也会更低。

人们犯的第一个主要错误是测试团队应该负责质量保证。这个角色经常被分配给组织中的第一个测试团队，它被用作最后一道防线。它成为开发团队(被指控生产劣质产品)和客户(必须保护客户免受劣质产品影响)之间的障碍。它的特点是测试团队(通常称为“质量保证团队”)有阻止产品发货的权力。这本身就是一个令人沮丧的任务:测试团队无法提高质量，只能强制一个最低水平。更糟糕的是，这种权力似乎比它实际上更重要。如果发现了这一点，再加上开发人员的质量是其他人的事情这一有悖常理的暗示，测试团队和测试人员会感到失望、怨恨，并感觉自己是受害者。从戴明等人的工作中我们可以知道，如果每个人都在开发的各个阶段对自己的工作质量负责，那么产品就会又好又便宜([戴明86]，[石川85])。

在实践中，不管正式的角色是什么，大多数组织都认为测试的目的是为了发现bug。这是一个比前一个定义更温和的定义，但是它缺少了一个关键词。当我与程序员和开发经理谈论测试人员时，一个关键的句子不断出现:“测试人员没有发现重要的错误。”有时这只是抱怨，有时是因为程序员对什么是重要的有一种扭曲的感觉，但我很遗憾地说，这往往是有效的批评。太多来自测试人员的bug报告是次要的或者无关紧要的，太多重要的bug被遗漏。

事实上，无论表面上的功能是什么，大多数组织都认为测试的目的是为了找到bug。这个定义比前一个危害小，但是忽略了一个关键词。当我和程序员、开发经理谈论测试人员的时候，不时听到一句关键的话:测试人员找不到重要的bug。有时这种说法只是一种抱怨，有时是因为程序员对什么是正确的感觉不正确，但我很抱歉地说，它们通常是有效的批评。太多来自测试人员的bug报告都很小，无关紧要，太多重要的错误被遗漏。什么是重要的bug？对谁重要？大致来说，答案肯定是“给客户”。几乎每个人听到这个定义都会点头，但他们是真心的吗？这是一个对你的组织成熟度的测试。假设您的产品是一个接受电子邮件服务请求的系统。一旦收到请求，它会发送一个回复，说明“您1997年5月12日的请求已被接受，其参考ID为NIC-051297-3”。一个每天发送许多请求的测试人员发现她很难跟踪哪个ID对应哪个请求。她希望将最初的请求附在回执之后。此外，她意识到有些客户每天也会产生许多请求，因此也会喜欢这个功能。她会:

什么是重要的bug？对谁重要？直觉估计，答案肯定是“为了客户”。听到这个定义，几乎所有人都会点头称是，但他们真的这么想吗？这是为了测试你的组织的成熟度。假设您的产品是一个接受电子邮件请求服务的系统。当收到请求时，它立即发送回复“您97年5月12日发送的请求已被接受，参考ID为NIC-051297-3”。一个每天发送许多请求的测试人员发现很难区分哪个请求对应于哪个ID。她希望最初的请求可以附在确认邮件中。而且她意识到有些住户可能每天也会产生很多请求，所以她会高度评价这个功能。然后她会:
1。提交一份记录可用性问题的bug报告，并期望它被分配一个合理的高优先级(因为修复显然对每个人都有用，对一些用户很重要，并且容易做到)？

写一个bug报告，记录一个可用性问题，希望能够分配一个合理的高优先级(因为这个修复显然对每个人都有用，对某些用户非常重要，并且容易修改)？

2.提交一个bug报告，期望它被赋予“增强请求”优先级，并且永远消失在bug数据库中？

写一个bug报告希望被赋予“功能改进请求”的优先级，从bug数据库中永远消失？

3.提交一个bug报告，产生一个“按设计工作”的解决代码，也许用一个程序员或开发经理的电子邮件“nastygram ”?

写一个错误报告，产生一个“按设计工作”的解决方案代码，可能还有一封来自程序员或开发经理的“不同意”的电子邮件？

4.不要为错误报告而烦恼，因为它会出现在情况(2)或(3)中？

懒得写bug报告，因为会以情况(2)或(3)收场？

如果可用性问题不被认为是有效的bug，那么你的项目对测试任务的定义就太狭隘了。测试人员被限制在检查产品是否做了预期的事情，而不是预期的事情是否有用。客户不关心这种区别，测试人员也不应该关心。

如果可用性问题不被认为是有效的bug，那么你的项目对测试任务的定义就太狭隘了。测试人员被严格限制在检查产品是否按预期工作，而不管这个预期是否有效。客户不在乎这种差异，测试人员也不应该在乎。

测试人员通常是组织中唯一像专家一样大量使用系统的人。他们注意到专家会看到的可用性问题。(正式的可用性测试几乎总是集中在新手用户身上。)专家客户通常不会报告可用性问题，因为他们被训练得知道这不值得他们花费时间。相反，他们等待(也许是徒劳的)一个更有用的产品，并转向它。测试人员可以防止收入损失。

测试人员通常和组织中的专家一样使用系统。他们会注意到专家会看到的可用性问题。(正式的可用性测试几乎不可避免地关注没有经验的用户。)专家客户通常不会报告可用性问题，因为他们已经被训练得知道不值得花时间这么做。相反，他们(也许是徒劳的)等待下一个可用的产品，然后切换。测试人员可以避免这种损失。
虽然将测试的目的定义为“发现对客户重要的bug”是一个进步，但它比我喜欢的更具限制性。这意味着没有关注质量评估(以及评估的质量)。对于一个有五个子系统的产品，考虑这两种情况。

将测试的目的定义为“找到对用户重要的bug”是一个进步，但与我最喜欢的定义相比还是有局限的。这意味着没有关注质量评估(以及这种评估的质量)。考虑用五个子系统测试一个产品的两种情况。

1.发布前在子系统1中发现了100个错误。(为了简单起见，假设所有的bug都是最高优先级的。)其他子系统没有发现bug。发布后，在子系统1中没有报告错误，但是在其他子系统中发现了12个错误。

在发布之前，在子系统1中发现了100个bug。(为简单起见，假设所有bug都是水平的。)其他子系统没有发现bug。发布之后，在子系统1中没有报告错误，但是在其他子系统中报告了12个错误。

2.在发布之前，在子系统1中发现了50个错误。在其他每个子系统中发现6个错误。发布后，在子系统1中发现了50个错误，在其他每个子系统中发现了6个错误。

在发布之前，在子系统1中发现了50个bug。每隔一个子系统就发现六个错误。发布后，子系统1中报告了50个错误，其他子系统中报告了6个错误。从“发现重要的bug”的角度来看，第一次测试的效果更好。它在发布前发现了100个bug，而第二个只发现了74个。但我认为你可以强有力地证明，第二次努力在实践中更有用。让我根据测试经理在发布前可能会说的话来重申这两种情况:

从“发现重要bug”的角度来看，第一个测试用例是理想的。在发布之前发现了100个bug，但是在第二种情况下只发现了74个。但我认为你可能会给出一个强有力的理由，说明第二种测试在实践中更有用。让我用产品发布前测试经理可能会说的话来重新描述这两种测试情况:

1.“我们已经非常彻底地测试了子系统1，我们相信我们已经发现了几乎所有优先级1的错误。不幸的是，我们对其余五个子系统的bug一无所知。”

“我们已经全面测试了子系统1，我们相信几乎所有优先级为1的bug都被发现了。不幸的是，我们对其他五个子系统的bug一无所知。”

2.“我们适度测试了所有子系统。子系统1仍然有很多问题。其他子系统大约有1/10的缺陷，尽管我们确信缺陷仍然存在。”
“我们已经全面测试了所有子系统。子系统1还有很多bug。其他子系统都有bug，但只有子系统1的十分之一的bug。”

诚然，这是一个极端的例子，但它表明了一个重要的观点。项目经理有一个艰难的决定:保留产品进行更多的工作会更好，还是应该现在就发布？许多因素——所有对未来可能的粗略估计——都必须加以权衡:竞争对手会抢在我们之前发布产品并占领市场吗？将一个未完成的特性放到某个杂志的“Java开发环境”特刊中会不会让我们在评论中吃亏？挑剔的客户X会对进度计划失误或不稳定的产品更恼火吗？产品会有足够多的问题，以至于利润会被支持成本或者更糟的召回所吞噬吗？

诚然，这是一个极端的例子，但它证明了重要的一点。项目经理有一个艰难的决定:我们应该推迟产品交付，工作一段时间，还是现在交付？很多因素——都是粗略评估——必须权衡:竞争对手会不会先发布产品，占领市场？如果我们丢失了一个未完成的功能部分，某杂志Java开发环境专刊上的评论会对我们造成伤害吗？重点客户X对产品延期或劣质产品更恼火？产品是否存在太多bug，以至于支持成本会吃掉利润，或者更糟，召回产品？

如果测试团队首先集中于提供对产品缺陷的估计(减少不确定性)，然后集中于发现更多估计存在的缺陷，那么它将更好地为项目经理服务。这会影响下一个主题的主题——测试计划。

如果测试团队首先关注产品错误的估计(减少不确定性)，然后发现更多的错误，他们将更好地为项目经理服务。这将影响测试计划。测试计划将在下一个主题中讨论。

它还会影响状态报告。测试经理经常错误地报告错误数据，而不把它放到上下文中。没有上下文，项目管理倾向于关注一个图表:

这也会影响状态报告。测试经理常常会被没有放到具体环境中的报告 bug数据误导。没有具体环境，项目管理倾向于集中于一幅图：



这也将影响状态报告。测试经理经常被报告的错误数据误导，而这些数据并没有放入特定的环境中。没有特定的环境，项目管理往往会集中在一张图上: