软件测试简介（Ammann和Offutt）在第32页中提到了5级测试成熟度模型：

级别0测试和调试之间没有区别。

1级测试的目的是证明该软件可以正常工作。

2级测试的目的是证明该软件无法正常工作。

3级测试的目的不是证明任何特定的东西，而是降低使用该软件的风险。

4级测试是一门精神学科，可帮助所有IT专业人员开发更高质量的软件。

尽管它们没有进一步详细介绍。调试和测试之间有什么区别？

测试的目的是从代码中或从不同的角度查找缺陷，以在适当水平（永远不能100％）证明该程序执行了应做的工作。它可以是手动的也可以是自动化的，并且具有许多不同的类型，例如单元，集成，系统/验收，压力，负载，浸泡等测试。

调试是从程序中查找并删除特定错误的过程。由于所有错误均不同，因此它始终是手动的一次性过程。

我的猜测是，作者的意思是，在0级上，仅以临时的方式执行手动测试，而没有测试计划或任何可确保测试人员实际全面测试被测功能的测试，并且可以进行测试。可靠地重复。

调试是一个手动的逐步过程，涉及，结构化且不可靠。通过调试进行测试，您将创建不可重复的场景，因此对于回归测试无用。出于这个确切的原因，除0（在您的示例中）以外的所有级别在我看来都不包括调试。

调试是通过有条不紊地遍历代码来解决已知和未知问题的尝试。当您进行调试时，通常不会把重点放在整个代码上，并且几乎总是在后端的实际代码中工作。

测试是通过使用各种可以调试的代码的方式来创建问题的尝试。它几乎总是在用户空间中完成的，您在该空间中以最终用户运行代码的方式运行代码，并试图使其中断。

简而言之，当您的程序在执行时没有按照应有的方式运行时，就发生了“错误”。也就是说，它不会产生预期的输出或结果。任何试图找到此错误的根源，寻找纠正行为的方法以及对代码或配置进行更改以纠正问题的任何尝试都可以称为调试。

在测试中，您可以确保程序或代码在不同条件下能够正常运行并以健壮的方式运行：您可以通过提供输入，标准正确的输入，有意的错误输入，边界值，变化的环境（操作系统，配置文件）来“测试”代码。本质上，我们可以说您尝试发现错误，并最终在测试过程中“调试”它们。希望能有所帮助。

没有了。如果您做对了：

命中率高，命中率低：

回归测试和Saff压缩

三河研究所肯特·贝克

摘要：为了有效地隔离缺陷，请从系统级测试开始，逐步进行内联和修剪，直到您拥有最小的可以证明缺陷的测试为止。

在发布给客户端之前，测试是您享受的特权。

在将错误发布给客户端之后，错误是您忍受的噩梦。

其他人提到了测试和调试之间的区别。

我想强调一个共同的部分。当测试人员发现缺陷时，必须将其隔离。调试是通过在运行时分析应用程序状态及其代码来隔离问题并找到根本原因的技术之一。实际上，牛津词典将调试定义为“ 从计算机硬件或软件中识别和消除错误的过程”。

谁将隔离（或特别调试）缺陷（无论是测试人员还是开发人员）是第二个问题。

您列出的测试成熟度模型是对开发团队心态的描述。

清单中没有明确指出的是，心态的变化如何影响进行测试的方式。

随着开发团队的发展，测试范围将会扩大。

在0级，由于团队认为没有必要进行测试，因此未进行测试。

在级别1，进行了测试以提供基本功能的名义覆盖。

在第2级，测试范围扩大到包括第1级的所有内容，并增加了破坏性测试（专门的测试团队，他们有权访问开发人员可以访问的所有信息，包括源代码和二进制文件，并尝试查找可能的错误。由用户角色触发）

在级别3，除了级别1-2中的所有内容之外，还添加了基于非功能的测试/基于非正确性的测试（例如性能特征）。

在第4级，每个人（包括面向客户的IT员工）都很好地理解了软件测试的目标。因此，IT员工将能够提供有关要测试的方案的反馈，从而提高了第4级的风险覆盖率。

（免责声明：我无权使用该教科书，因此我的术语可能不正确。）

错误是可见的错误。调试是在测试用例设计之后开始的过程。这是比测试更困难的任务，因为在调试过程中，我们需要找出错误的根源并将其消除，因此有时调试会使用户感到沮丧。

用日常的实际用语来讲，我认为这完全取决于上下文。

在一个大型团队中，以高/非常高的标准（例如银行，军事，大规模，高预算或关键业务系统）工作，那么我认为“调试”显然应该是“测试的结果”，并且它们显然是完全不同的事情。理想情况下，测试会导致调试（在过渡环境中），而在生产中，我们需要将两者中的任何一个都接近零。

测试范围广泛，定期且非常正规-尽管调试是一个特殊的过程，但有时需要修复特定的故障-这并不明显，并且需要对系统的功能和结果输出进行更深入的调查。

在我看来，测试是必不可少的，而调试是仅在解决故障的方法不透明时才需要的特定工具。

我完全理解TDD在大型团队和/或系统中具有明显的效用，而不仅仅是无法承担“麻烦”。对于复杂的系统（通常是“后端”），或者与输出相比，代码的复杂性比例很高，这显然也很有意义。然后，“测试”就有实际的机会通知何时以及为什么发生故障。执行大量复杂工作或导致输出明显可测量的系统通常易于测试，因此测试与调试不同。在这些情况下，测试强烈暗示一种基于程序的形式化方法，用于确认或取消确认期望与实际输出的匹配。测试一直在进行，有时会通知我们调试的必要性。

如果这是一个普遍存在的事实，那将是很可爱的，如果我的开发周期被明确定义的二进制输出（红色，绿色）所分隔，我会喜欢的，但是...

就我而言（这很特别-在中小型，资金不足，基于Web的，以数据为中心的公司管理系统上独自工作的98％），我真的不知道TDD可以如何帮助我。确切地说，“调试”和“测试”实际上是相同的。

尽管使用术语“测试”主要意味着/紧密联系TDD的方法。

我知道这完全是完全不符合时代精神的 “回避非信徒，回避，回避”，这显然是一件很酷的事情。但是考虑一下我的背景，我什至没有模糊地戴着一顶实用的帽子，在我最疯狂的想象中，看到了TDD如何帮助我为客户带来更多的物有所值。

更确切地说，我强烈不同意“测试”是基于代码的正式过程的普遍假设。

我的基本异议（适用于我的特定 *上下文*）是...

如果我不能写代码，可靠地工作-当时如何地狱我应该是工作可靠写代码测试大概说子标准代码。

对我来说，我从来没有见过任何例子也不论点，即（在我的特定情况下）热情我，足以甚至懒得思考关于编写一个测试，我可以写一些可笑单薄测试代码，现在，也许“做我的仓库回报用户名称为== X的实体，当我确切地-唯一地-那个吗？自我满足，狂野地低估了血液，沸腾了，愚昧的，愚蠢的垃圾，但是我只是觉得有必要在这里扮演魔鬼的拥护者。（那种希望有人能给我带来光明并让我转变，也许最终会为我的客户带来更好的物有所值？）。

可以说，“调试”有时与“测试”相同。我的意思是说，在我的日常工作中，我至少花费三分之一的时间在不同的浏览器中浏览系统的本地版本，拼命尝试各种古怪的尝试，以破坏我的工作，然后进行调查失败的原因并予以纠正。

我100％同意TDD口号“红色/绿色/重构”中的明显效用，但是对我来说（以低预算工作，在RIA土地上工作），我真的很希望有人能告诉我如何做可能，在逻辑上和极其逼真地 得到任何额外的价值从写更多的（就像可能有缺陷的测试代码），比我从我的努力的充分（而且基本上只）输出，基本上势必真人互动实际上交互做。

对我来说，当开发人员谈论“测试”时，它通常意味着TDD。

我尝试编写代码，好像有测试一样，我认为所有以测试为重点的开发所鼓励的所有模式/实践和趋势都是奇妙而优美的，但是对我而言，“测试”并不是编写更多的代码，实际上测试现实世界会以逼真的方式将其输出，这实际上与调试相同，或者说，这里的积极变化是“调试”，这是人工的，以输出为中心的非自动化“测试”的直接结果。这与普遍接受的将“测试”视为自动化和形式化，将“调试”视为人为，即席或非结构化的观点形成对照。

如果目标是真正的物有所值，那么您在制作基于Web的交互式应用程序，则该工作的结果就是网页，以及从根本上说它们对人工输入的反应 -因此“测试”最好通过测试来实现这些网页，是通过真正的人类互动而实现的。当这种交互导致意外的或不希望的输出时，就会发生“调试”。调试还与实时检查程序状态密切相关。测试通常与自动化相关联，我认为这通常是不幸的。

如果目标确实是努力的价值，并且自动化测试是高效且非常有益的，而调试只是该测试的结果，或者是自动化测试的不佳替代品，那为什么是访问量第二大的网站（Facebook ），那么常常会出现令人眼花obvious乱的明显错误（对用户而言，但显然不是测试团队和测试代码）错误？

也许是因为他们专注于使人放心的绿灯，却忘记了实际使用他们的工作成果吗？

是否有太多开发人员认为测试是您使用代码完成的事情，调试是您偶尔使用IDE进行的事情，因为图标变为红色并且您无法弄清楚为什么？我认为这些词具有与之相关的不幸的价值判断，这些判断通常模糊了我们应关注的实际现实，以缩小预期与产出之间的差距。

只是，

测试是指在调试时查找导致软件故障的输入，这是查找给定故障的故障的过程。