“一个好测试”或“一个坏测试”-每个测试人员都会遇到这两个术语。
有时，对于经验丰富的测试人员而言，很难判断它是好是坏。因此，这里有一个非常简单的问题：
好的测试和不好的测试有什么区别？
#1 楼
这取决于有很多因素决定测试是“好”还是“坏”（有用或没有）-一些示例是：
A如果测试能够浮出水面关于软件性能的新信息，则测试就更有可能实现。
探索新功能时所做的快乐路径测试一旦变得不那么好，就会变得不那么好稳定，但可用于回归检查。
用于一次性软件（例如概念证明应用程序）的测试可能比计划进行的软件测试有用。
测试对于高风险的方案（即发生的可能性很高，如果发生的话会产生很大的影响）可能比测试低风险的方案更有用。如果回归测试涵盖了80％的用户使用的20％的软件的核心功能或功能，则该测试更可能是好的。只是不要忘记在该标准中包括恶意用户）。
如果测试涵盖了应用程序中其他测试未涵盖的部分，则该测试更有可能很有用。
除了一般原则外，实际上没有任何“硬性”规则。现代软件通常是响应式和不确定性的，因为您只能预测总功能的一小部分的行为（因为完整的行为集接近无限）。
经验丰富的测试人员将研究软件的使用方式，要解决的问题以及要解决这些问题的人员，并进行相应的测试。
评论
如果测试更容易，更快速地运行，那么测试也更有可能是好的。
–克莱里斯-谨慎乐观-
17年11月27日在17:19
@chrylis-不一定。我可以想到许多容易且快速运行的无用测试。它们没有用，因为它们不提供任何有意义的信息。
–凯特·保罗（Kate Paulk）
17年11月27日在19:55
一个不好的测试将是容易出错的，并且会带来很多假阳性的失败。这将导致您忽略测试失败，即使它们是有效的
–大卫说恢复莫妮卡
17年11月28日在1:41
@KatePaulk是的，但是功能上相当快速的测试（例如直接依赖注入而不是启动俘虏容器）更有可能经常运行。
–克莱里斯-谨慎乐观-
17年11月28日在14:59
#2 楼
好问题。每个测试都有其价值和成本。其价值在于降低风险的能力。以下是一些使测试有价值的方法：
影响。检测高影响力的错误比检测低影响力的错误更有价值，而检测低影响力的错误比不检测任何错误更有价值。
诊断价值。缩小错误原因范围的测试比仅仅报告
"something went wrong". 一致性的测试更有价值。产生一致结果的测试比不一致的测试更有价值。
成功率。检测实际发生的错误的测试比检测从未发生的错误的测试更有价值。 br />
资源密集型。一项需要大量计算资源或大量资金的测试比不需要它的测试昂贵。
时间密集。长时间运行的测试要比短期运行的测试昂贵。
易碎。需要大量维护的测试比不需要更新的测试更加昂贵。
如果您知道测试的价值和成本，就可以判断其优劣。 br />
高价值和低成本的测试是不错的测试。
低价值和高成本的测试是不好的测试。一般般啦。例如，覆盖整个用户界面但需要大量维护的Selenium测试可能还可以。您可以通过重写测试（或UI）使它成为更好的测试，以使测试不那么脆弱。
低价值，低成本的测试就可以了。锻炼很困难，因为价值和成本会随着时间而变化。一些测试人员建议定期检查测试套件，以删除或重写不良测试。
评论
极好的答案；我只是说我会将测试视为价值-成本，而不是将价值和成本放在不同的轴上。一项测试的成本可能很高，但影响确实非常大，并且是一项出色的测试。
–凯文·麦坚时（Kevin McKenzie）
17年5月5日在20:39
谢谢。我将它们放在不同的轴上，因为单位不同。示例：从检测高风险错误的能力中减去30分钟的运行时间，结果的数量和单位是什么？
–user246
17年5月5日在21:18
产生一致结果的稳定测试非常适合发现小的回归，但是经常使用不稳定，脆弱，复杂的测试来发现新的意外错误。我们需要两种类型的测试，但是我们需要记住它们为不同的目标服务。请参阅Microsoft的相关研究报告：uploads.pnsqc.org/2016/papers/…。
– dzieciou
17年12月8日在19:17
#3 楼
好的测试所产生的信息的价值超过了测试的成本。评论
+1。答案很简洁。所有其他答案都用更多的话说了同样的话。和细节。测试成本：编写，运行，在测试的系统更改时进行维护，分析故障。所有这些都不是免费的。
– Peter M.-代表莫妮卡（Monica）
17年11月30日在15:18
+1可能会进行很长时间的脆弱测试，这些测试会产生有关查找新错误的信息。即使它们的维护成本很高，也不时运行它们并花费更多的时间进行故障分析可能还是值得的。
– dzieciou
17年12月8日在19:54
#4 楼
请注意，优缺点往往呈递减比例，但好的列表中的特征越多越好。“良好”测试的特征：
对于如何以及何时运行它有明确的说明
测试是否存在期望的行为
测试不存在不期望的行为
提供良好的隔离-如果失败，则知道问题出在哪里！
基于需求而不是实现。
是可维护的，并且具有良好的可跟踪性，因此，如果规格更改，您可以快速进行匹配。即，如果通过，则存在期望的行为，而不期望的行为丢失，如果失败，则确实存在问题。
以低成本提供快速的结果。
首先测试最重要的行为
要么终止第一个或第n个问题，要么就当前状态提供持续的反馈。
可中断，但如果部分中断仍然有用结果
可以很好地覆盖被测物，可能会花费额外的时间。
实现成本低，稳定，寿命长，工具支持良好
而不依赖平台br />针对正在进行的测试类型遵循公认的良好做法
是非侵入性的，即可以在可部署的代码上运行而无需进行任何更改
不良测试的特征
没有证件，或者只能由专家操作
不确保存在期望的行为
不确保不存在不希望的行为
是基于实现而不是要求
很难维护和/或缺乏可追溯性，从而使您不知道规范更改的影响
告诉您存在问题，但不是问题或原因是什么
有时会传递不良物品和/或会因良好而失败。
花费很长时间和/或成本很高
直到最后都不会给您任何结果或反馈（然后您可能发现3周前有问题可以纠正）。以及到目前为止的结果。
仅涵盖了代码中的“良好”路径，因此覆盖率较低。 >仅在一台特定机器上运行
与任何公认的方法都不匹配
需要特殊的代码版本，而该代码与生产代码不匹配。
#5 楼
自动化测试是更改的障碍。好的测试是仅在破坏/不希望的更改时失败的测试：破坏的功能，回归，用户会认为是错误的东西。
糟糕的测试在随机或期望的更改上失败：随机地，每当有人重构代码而没有行为更改，在更改中执行代码的环境，引入新功能时，等等。
错误的测试意味着开发人员在想要完成任何事情时都浪费时间进行测试。
还有其他一些实际方面需要考虑：测试运行的速度如何，以及提供多少有关测试的数据。故障的根源（这种变化触发了断裂）-但在我看来，它们是次要的。
#6 楼
好的测试的特征是：行为：它们测试行为而不是实现。
不可理解：当它们失败时，您就会理解为什么失败。该名称是对测试失败时的帮助的描述。错误/断言消息也是如此。一个好的测试失败会解释为什么会失败，所以非开发人员/测试人员也可以理解它。不多。这与一个断言不同，多个断言可以测试一件事。
独立性：好的测试可以单独运行，从而使其更容易/更快地验证它已被修复。 br />
快速：它们执行起来很快。使用GivenWhenThen或AAA模式。
可维护：当被测应用程序更改时，它们需要进行最少的更新。您不应该讨厌测试。
文档：它们可以用作文档形式。
不闪烁：它们绝不会因错误的原因而失败，例如它是可重复的。
不良测试与好的测试相反。
我认为这些东西对于手动和自动测试都很重要。
评论
我也将Automatable放在这里。如果它是自动的，那么您每次开发人员提交到您的开发分支时都可以运行它，与必须将其推送到测试/暂存/尝试推送到要进行测试的产品相比，它可以更快地捕获错误。
–莫妮卡基金的诉讼
17年11月29日在9:21
短期测试可能对回归套件很有用，但长期测试通常会发现更多意外错误。请参阅我的回答和Microsoft的论文：uploads.pnsqc.org/2016/papers/…。
– dzieciou
17年12月8日在19:45
#7 楼
这里有一些很好的答案。马克·温特宁厄姆（Mark Winteringham）最近在道场（Dojo）上写了一篇有关“好坏测试之间的区别”的文章。
任何测试要注意的重要事项是它要解决的风险。这可能会引发许多其他问题，这些问题随后将扩展您的测试和想法，以加强方法。
#8 楼
对我来说，一个好的测试是能够捕获错误并且不会产生假阳性或假阴性结果的测试。评论
什么是不良测试？两者之间有什么区别？
–嵌入式
17年11月27日在14:24
您的答案没有错，但过于简单。例如，只要测试能够可靠地检测出对我而言很重要的故障，我就不会检测到某些甚至很多故障。
–Rsf
17年11月27日在15:18
我故意以简化的方式回答，因为否则，举报主要是基于意见的。在许多情况下，根据情况和经验对经验可争辩。不可能有客观的核心答案。
– Alexey R.
17年11月27日15:21
#9 楼
良好的测试会在针对其编写的一个单元中的错误上失败。它们不受其他单元中的错误的影响。这些其他单元都有自己的测试。良好的测试还不如较差的测试脆弱，因为随着合法行为的发展，良好的测试可能需要花费大量的精力来保持最新。不良测试通常比根本没有测试要好。
评论
我敢于您编写系统级测试，它将指导您在一个模块中并且仅在一个模块中解决问题。实际上，很多时候不良测试会浪费您的时间和精力，从而导致质量降低；另一方面，简单测试或覆盖范围较小的测试要比根本没有测试好很多时间
–Rsf
17年11月28日在12:42
#10 楼
自动化或手动/探索性测试？一个好的自动化测试（通常是单元测试）是一个软件。要成为一个好的测试，必须对其进行良好的编程-可读性，可维护性，合理的无缺陷性，足够快的频率以使其能够经常运行。被测系统（通常是一个类），仅测试公共方法，但很少有类能够完全隔离。为了提供模拟，测试人员必须了解方法的工作方式。自动化测试应涵盖被测系统的合同以及通过这些方法合理选择路径。覆盖所有这些元素通常太昂贵了。
一个好的测试自动化工程师具有训练和思维模式，可以查看代码并选择能够提供足够好的覆盖范围的数据。许多被告知“为类编写测试”的程序员只是将单元测试的覆盖率提高到100％－每个指令至少执行一次。
好的手动测试可以充分利用（昂贵的）人工。从业务角度讲，它涵盖了系统的最关键部分，并使用了测试人员的专业判断。例如，我发现编写用于响应式Web设计的自动化测试是不切实际的。因此，我改为记下我们需要进行手动测试，“在所有测试设备上调用该网站，并在适用的情况下调整浏览器窗口的大小。确定外观是否可接受，否则记录设备和设置。”一些可怜的schmuck却得到报酬去做。但是并非每个版本都这样，因为那样太昂贵了。
一个好的手动测试可以一次测试很多东西。如果自动测试可能先登录用户然后关闭浏览器，而下一个测试可能先登录另一个用户然后退出浏览器，则手动测试将覆盖登录和注销，这是其他一些测试用例的一部分，这需要登录用户。
#11 楼
对我而言，糟糕的测试是任何没有价值的“测试”。您可以执行任何其他有价值的测试或检查，例如提供有用的信息是一个很好的测试。
测试是否有用取决于上下文。我可以想到各种非常有用的测试，它们在不同的上下文中完全没有意义。
#12 楼
我相信良好的测试开发策略类似于用于建立质量回归测试套件的策略。设计此测试套件后，测试团队将基于风险的方法应用于选择敏捷项目中的回归测试用例。团队通常选择以下测试用例：发现关键的产品功能
不重复
在先前的迭代中稳定检测到的错误
我认为相同原理可以应用于设计任何测试。良好的测试应完全涵盖产品功能，包括几乎不会遗漏错误且独特的测试用例，即测试用例在整个套件中不会重复。最后但并非最不重要的一点是：良好的测试应该可维护，因为应用程序的功能可能经常更改。
#13 楼
自动化测试有两个目标：门控制-它们决定何时发布新软件或将软件从一个测试环境转移到另一个测试环境。 >发现新错误-它们有助于识别新的意外错误
每个目标都有不同的要求，因此通常有利于发现新错误的测试可能不利于门控制。
此处的大多数答案仅讨论门控制的测试，即回归测试，因此，我将仅总结此处编写的内容。门控测试需要精确，确定性，稳定和快速，并明确声明。
发现新错误的测试有所不同。它们的召回率较高，但精度较低：它们可能会有更多的故障，但是这些故障可能是假阴性。因此，故障需要更多的分析和故障排除。发现新错误的测试通常较长，涉及系统的多个部分且不确定（例如，可能具有诸如模糊测试之类的随机性元素）。当发生意外情况时，它们将失败，但与回归测试不同，您不会明确编写所有断言。
#14 楼
事实是，编写好的测试与编写好的生产代码一样困难。这需要实践，并且需要仔细考虑，但是很多次我都看到测试如何被视为二等公民，这通常意味着我们无法获得好的测试套件的全部好处，而最终得到的套件更多负担比资产要重。一个好的测试套件：
给您信心。
查找错误。
维护成本低。
记录系统信息。
健壮性。
没有错误（自我测试）。
评论
您目前对相同的理解是什么？是什么使事情变得复杂？请编辑问题并添加详细信息。在什么情况下..
但是上下文确实很重要，对于由专门团队测试的受管制医疗设备，对于为移动应用程序构建概念证明的小型初创公司，答案将有所不同。
我不同意，我的回答试图解释原因。
除非您有目标，否则根本不应该创建测试。一个好的测试可以达到目标。不好的测试不会。