您如何测试可能出错的所有内容？

#1 楼

我会有一个分阶段的环境，那就是现场的精确克隆。然后，当您必须回滚错误时，您也可以对其进行跟踪并在暂存环境中进行修复。

一旦有了完整的bug及其原因的清单，您就可以发现趋势并阻止它们再次发生。

#2 楼

当某些用户输入的数据与
测试数据不同时，会发生错误。除了边界测试之外，模糊测试也可能会有所帮助。实际上，任何类型的随机生成或随机变异的数据（根据您的业务规则）都可以帮助发现此类错误。专门尝试破坏系统并且不仅仅测试系统是否正常运行的测试人员通常也非常擅长查找恶意输入或恶意数据组合。


变化会影响另一个区域并通过测试滑动。


最近我已经在很多单位中（使用WPF）在UI中看到了此类错误测试周围的业务逻辑。有人更改了控件模板，而其他某些事情则无法正常工作或看起来不正确。自动化的UI测试可以帮助解决此问题，但是创建和维护它们确实很繁琐。不过，专用的测试人员可以很快找到这些东西。如果是业务逻辑失败，则创建更多的单元测试并争取更高的覆盖率。代码契约和数据库上更严格的约束也可能会有所帮助。

#3 楼

60％的代码覆盖率意味着您的单元测试中仍有很大的改进空间。但是，提出单元测试来处理远离幸福道路的情况可能会非常困难。您的单元测试将永远不会测试事物在夜间颠簸的所有方式。

人类可以非常接近。聘请测试人员。它们很便宜，并且具有极高的成本效益。一个好的测试人员将模仿两个关键行为：纯粹的愚蠢，以弥补您的非最佳用户所犯的愚蠢错误：如果我这样做，该怎么办？好吧，那不是很有趣。是时候打开一个错误报告了。

简直是邪恶的事情，来弥补那些不是最理想的程序员所犯的愚蠢错误：如果我那样做，会发生什么？好吧，那不是很有趣。是时候打开另一个错误报告了。


让测试人员可以使用正在开发的产品，并且发布时不会有那么多有趣的问题。

#4 楼

“几个内部人员，我们可以花一些时间进行质量检查”

这几个人是专业的质量检查人员/测试人员吗？还是只有几个小时的空闲时间？

设计和开发主要功能更新需要多长时间？也许您需要的是“几天”或“几周”，而不是“质量检查的小时数”？如果您真的不知道原因，很难确定解决方案。

#5 楼

大卫，

伟大的一般性问题，并为工作提供了详细的细节。

我一直专注于回答“软件测试人员如何使用尽可能少的时间/最少的测试数量来发现最多的缺陷？”这一问题。在过去的五年中。每当测试人员试图解决“在有限的时间内要进行太多可能的测试”的问题时，我强烈建议他们尝试使用成对和/或更全面的组合测试设计方法。这些测试设计方法是为解决此特定挑战而定制的。

以下是我上周发布的三个视频，它们介绍了这个重要的主题（在我看来，这是个被低估的话题）：测试-> http://www.youtube.com/watch?v=kFH4QnymGGc

成对和组合软件测试简介（续）-> http://www.youtube.com / watch？v = Za5aQAMIq_g

如何考虑成对和组合软件测试中的测试输入-> http://www.youtube.com/watch?v=EZHha-nGvcM

这些类型的测试设计方法可以使几乎所有被测系统都能很好地工作。并且它们在与您类似的情况下（例如具有多种配置选项和很多复杂性的系统）特别强大。




通过这些测试设计生成的测试将通过方法
确定每个有用的测试？不会。它们会生成
种类繁多且功能强大的“入门”测试，您可以
通过您设计的其他测试（特别是
阴性测试）进行补充。

他们可以生成您想要的大多数测试吗？是的（提供的
您会仔细选择测试输入）。

与大多数其他手动方法相比，用这种方法生成的测试是否会发现不成比例的
大量缺陷
/>选择测试条件以用于测试用例？是的。

您如何开始快速测试这种方法是否对您的环境有帮助？一种方法是遵循第三个视频中描述的“每个参数最多使用3个值”方法。

为什么这些测试设计方法往往比手动选择的测试用例选择方法更强大？


产生更多的可变性测试之间（例如，...
...科学地最小化了从一个测试用例到另一个测试用例的重复量），并且
您将通过简单的成对实现每对测试输入对的100％覆盖测试计划；如今，通过简单的成对测试就可以检测到生产中84％的缺陷。（1）
通过快速“调高覆盖范围”，您将实现所有三元组或所有四元组的100％覆盖率；这种设计测试的方法使您可以将测试重点放在最有可能获得“最大收益”的地方，并可以根据业务利益相关者的意见做出明智的选择，以了解是否有适当的数字在给定情况下的测试数量是（a）最强大的几十个测试，或（b）最强大的几百个测试，或（c）最强大的几千个测试。



我希望这些建议能对我们有所帮助。在IEEE计算机杂志上发表的这篇文章中，描述了通过执行周全的成对测试来触发当今的趋势：http://app.hexawise.com/Combinatorial-Software-Testing-Case-Studies-IEEE-Computer- Kuhn-Kacker-Lei-Hunter.pdf

#6 楼

不幸的是，没有解决您提到的问题的灵丹妙药。这是每个测试团队都必须学习并从客户的反馈中改进其测试过程的学习经验。设计是极好的资源。进行探索性测试肯定会大大有助于提高质量。单元测试不能解决客户遇到的质量问题。一个好的单元测试套件对于发现代码级回归问题绝对必要。培训质量检查人员以“像客户一样思考”是成功进行测试的重要方面之一。质量检查人员应充当客户的拥护者，对每项要求，GUI，文档和所有可交付成果进行质疑和审查。鼓励测试人员超越记录在案的测试用例和验收测试。詹姆斯·惠特克（James Whittaker）的书提供了一个很好的框架，测试人员可以围绕该框架执行这些任务。

#7 楼

我们也有一个如此复杂的系统，实际上，我已经问过关于同一问题的另一个问题。现在，我们要做的是拥有一对具有最佳相似性的孪生服务器，包括已安装的应用程序，硬件规格，网络功能等。另一个是测试服务器（许多开发人员称为AKA登台服务器）。

但是，我们根本没有单元测试。唯一提高我们质量的是，我们制定了计划，以使每个部署都应处于冲刺测试阶段。这意味着在每个冲刺（生产周期）结束时，我们将新功能部署到我们的测试环境中，并且我们非常重视我们的测试服务器。我的意思是，我们应避免任何撤消操作，或在最严格的级别上避免此类操作。

我们的测试人员也不只是陪同公司的测试人员。实际上，我们已经将这些应用程序中的一些（在测试服务器上）免费出售给了一些客户，以便他们可以对其进行测试。

这样，我们通常会在测试阶段遇到很多错误。我知道我们有beta，alpha，CTP，RM，R2等术语。但是，毕竟，重要的是，我们采取了使所有人满意的策略，并提高了质量。

因此，我的建议是您可以部署到测试服务器（该服务器的行为就像正常的生产服务器一样，您将认真对待并尊重它）并定义测试周期。 >

#8 楼

您真的想尽可能地尝试测试吗？尝试构建一个Chaos Monkey，看看系统的容错性如何。

#9 楼

通常，单元测试会验证满意的路径是否有效，并且会根据方法正确地处理错误。因此，将测试重点放在（a）不太常见的路径上会导致客户不满（您的注册可能工作得很好，但是您的退订是否有无休止的循环？），以及（b）端到端错误，可能会更有成效。行为-如果您实际上让那些单元测试错误状态之一通过堆栈传递给用户，那么他们是否将获得您感到自豪的错误报告和恢复经验？

#10 楼

如果要求我帮助进行故障排除，请先询问您的生产问题是在部署期间出现还是在系统已经部署了一段时间之后出现。

如果问题在部署期间出现，我接下来考虑您描述的硬件差异，询问您是否部署质量检查环境是否与部署生产系统完全相同。

排除所有部署问题后，我将询问您的错误是否在特定区域还是系统性的。从您的问题来看，这些错误是系统性的。在那种情况下，对于每个错误，我都会问该错误是应该由自动测试还是手动测试捕获的。如果是自动测试，我会问测试的作者是否知道为什么测试没有找到错误。如果是手动测试，我会问是否已记录手动测试。