请明确一点，我知道您不能单单检查清单，否则我们将使流程自动化-但是，一个好的清单可以帮助测试人员在疲倦和沮丧时提出想法。
是否有人有很好的步骤清单来尝试将错误减少到可以产生一致再现性的最小步骤集？
#1 楼
请注意，这是社区Wiki，如果您有其他资源，请添加。我通常不会回答自己的问题，但我认为，如果我能找到一个例子，也许其他人会对我要找的东西有更好的了解。第77课，来自“经验教训”在软件测试中学习到的，标题为“不可复制的错误是可复制的”，其中列出了常见问题类型的简短，详尽的清单，包括简要的策略。该课程的最后包括资源以获取更多信息：Nguyen（2000），Kaner等。 （1993），以及Telles和Hsieh（2001）。我还没有研究这些内容，但是一旦有空闲时间，我就会考虑这些。自下而上的方法。 ，聪明，明智，而且恰好是错误的。”），有关如何进行调查的建议以及针对潜在原因的一整套指导性启发式方法。像：如何隔离错误？或更具体的类似：隔离分布式事件驱动系统中的缺陷。
评论
非常感谢那些添加到此帖子的人！
– Ethel Evans
2011年5月23日在22:25
我没有发现坎纳（Kaner）的书中的第77课非常有用。它没有给出其中的错误的详细示例以及调查此类错误的策略。这是来自77的示例项目，它说明了我的观点-“该错误可能取决于特定的数据值或损坏的数据库。”这本书可能以有声读物的形式有用。人们可以在开车，清洁等时听到他的测试建议，而不是去看书，也就是说，不值得花时间。
– JohnSink
17-09-20在18:33
#2 楼
开发人员要求测试人员减少错误有两种感觉。首先，通常很容易得知哪些输入的值触发了该错误。其次，有时测试人员会尝试缩小产品中出现错误的位置。我假设您是在问第一个问题。与其问一个普遍适用的清单，不如问一个更好的问题是：“如何为自己的产品/功能编写一个减少错误的清单？”我认为这归结为依赖项列表和用于改变处理这些依赖项的策略的列表。
有些依赖关系是环境的，例如如何配置操作系统，正在使用的硬件以及如何配置软件。其他依赖项将对您的软件是唯一的。如果您考虑得足够广泛，那么您就可以拥有无限数量的依赖关系，但是您当然不能研究那么多依赖关系。取而代之的是，您可能会从过去触发过错误的程序开始。一些策略会很容易，例如如果您依赖于浏览器，请尝试使用其他浏览器或其他版本的浏览器。其他依赖项可能需要采取特殊措施，例如开发人员专门为诊断或调试问题而添加的特殊软件或未记录的功能。例如，如果您依赖快速的网络连接，则可以使用强制网络连接运行缓慢的代理或硬件设备。
评论
+1-您的最后一段正是我想要的东西。我自己的“产品/功能”非常庞大，包含多个服务，应用程序和网页（小公司，每个员工都有很大的覆盖范围），因此几乎每个技巧都适用于一种或另一种产品。
– Ethel Evans
2011年5月24日17:03
#3 楼
根据您的错误的上下文，试探法会有所不同。您也可以尝试以下操作，以找到确切的复制方法。1。要求您的同伴执行流程以查看他们是否可以重现该问题
2。使用新的用户帐户
3重复测试。从浏览器中删除所有缓存和cookie，然后重复执行
。如果错误的影响严重，请使用DEV的帮助进行分析
#4 楼
即使我投了反对票，我也要说出来...但是，伙计..你在跟我开玩笑吗？ :)这就像问我如何减少说的创建。或者如何使牛奶，面包或花朵更快地生长。......您有一个文本字段，当您不输入任何数据时，该字段将丢弃空指针异常。你不能减少它。
当然，如果您有一个很大的大虫子，可以说...您有一列从DEN到JFK的火车，第二排的每个人都会夏季的每个月的第三天，票号为零。我想尝试的可能是每天，而不仅仅是夏天，或者每个平原等。
我想唯一的选择就是淘汰。建立一个矩阵并尝试减少每个步骤，或者省去几个步骤，看看该错误是否仍可重现。 :)用你的大脑。回溯您的步骤。尝试忽略一些，看看会发生什么。
祝你好运！ :)
评论
您误解了清单的目的。目的是传达测试的经验。新的测试人员在减少错误时更可能考虑功能问题（实际上，您正是这样做的！）。经验丰富的测试人员知道这些错误相当容易，但是间歇性错误又如何呢？在间歇性错误中，您可以按照完全相同的步骤进行操作，并且一次又一次重现该错误？内存，CPU，竞争条件，超时等都可能导致这些错误。您如何减少它们？那是一个步骤/技巧列表派上用场的地方。
– Ethel Evans
2011年5月23日17:45
我不这么认为。那里有很多错误，这些错误不是不可复制的，而是一次，或者很难发现。您不能在上面列出清单。您没有找到任何东西的原因是没有任何东西。您必须直观。或者也许知道一些代码。
–汉尼拔
11年5月23日在20:57
埃塞尔不是要保证。她要求提供一套启发式工具-经验丰富且技术熟练的测试人员可以使用这些工具来帮助他们。如果您认为清单仅用于非熟练工作，则绝对应该阅读Atul Gawande的书：gawande.com/the-checklist-manifesto
– testerab
11年5月23日在21:29
好的，所以我不确定在这里是否有命名冲突。不管我们叫什么，第一个答案中的资源列表都是熟练的测试人员在减少错误时可以使用的资源。您觉得这些有用吗？最短的东西可能是巴赫（Bach）文章-我会挑战您阅读并说它通常不适用！
– testerab
2011年5月24日12:30
嗯。 。实际上，如果我对域名足够了解的话，我可以列出一些减少cookie配方的想法（或cookie配方中的问题）。有人在这里做它：allrecipes.com/HowTo/perfect-cookies/Detail.aspx这与我在减少错误中寻找的cookie等效。
– Ethel Evans
2011年5月24日17:42
#5 楼
我发现这类事情是主观的，并且完全取决于您所使用的环境，A的步骤并不总是适用于B的事情。这仍然是一长串，基本上需要在所有方面进行功能检查，例如已安装服务？它在运行吗？它正在更新吗？它还在运行吗？这很容易。如果您确实需要创建这样的东西，创建一个Wiki，然后记录这样的事情，那么在开始开发新产品时它就已经做到了，随着越来越多的人添加他们遇到的问题，它随着时间的推移而扩展。几年后，我们注意到了许多步骤，提示和故障排除工具。在您遇到的那种情况下，当您感到疲倦时，我会写一份关于我在做什么的文档，否则我将不能依靠自己的能力来回忆我所有的步骤。因此，也许如果我要按您的意愿列出一个列表，则可以在其中列出一个项目：缺陷。
评论
列表的第2步可以是“删除列表，删除所有与重现问题无关紧要的步骤”。
–友善
2012年7月4日在13:21
#6 楼
如果失败是由大量输入引起的，则您可能需要看一下三角调试：http://pag-www.gtisc.gatech.edu/courses/common/zeller-tse02.pdf简而言之，它接受导致故障的输入并测试其子集，目的是找到仍然导致故障的（基本上较小）输入。
评论
重大问题-错误隔离对于测试人员而言是一项被忽略的关键技能。而且，针对某事提供提示表/核对表并不能以任何方式暗示您已经设法从中汲取了技巧和判断力，只是您足够聪明地意识到他们会提供帮助。