以下哪些陈述是正确的？
程序规范中的错误对您造成的损失最大修复
代码错误修复最昂贵
需求缺陷修复最昂贵
设计缺陷修复最昂贵
我的想法除非您知道特定项目的状态，故障类型和故障的根本原因，否则问题是不完整的。例如，如果项目仍处于需求收集阶段，在瀑布环境中，答案将是“要解决的问题最昂贵”
但是，如果您处于瀑布环境中的测试阶段，并且由于以下原因而发现故障，程序规范，答案应该是：“程序规范中的错误是最昂贵的修复程序”
我想知道
这种vag实际考试中有问题吗？
我对问题的处理方法有误吗？
您认为正确的答案是什么？
预先感谢您的时间和精力帮助我完成考试
#1 楼
这个问题是假的。由于最昂贵的修复方法取决于故障的复杂程度。在软件开发周期的任何阶段中解决小问题都是很便宜的。由于复杂的问题可能需要完全重写。此重写可能不是由错误的要求引起的，而是由意大利面条代码或其他方式引起的，具体取决于谁和在何处使用了快捷方式。此问题可能与Boehm定律有关：（此博客的图片） -post）
平均在开发周期中发现错误将花费更多的时间和资源。从这个角度来看，答案将是：
代码中的错误修复起来代价最高
作为错误，无论是设计还是需求或者如果您已经构建了代码错误，则修复它们的代价会更高。您将需要再次构建它们，因此将花费更多的钱。这就是为什么我建议进行敏捷开发的原因，然后您在每个迭代中都会得到一个像这样的图，而不是一个大的发布周期。敏捷将这种风险降到最低。
回答其他问题：
实际考试中是否存在此类模糊的问题？
是的，ISTQB以这类问题和模糊的理论而闻名。 ISQTB是关于理论测试，而不是实际的实际测试。如果您想找一个好的测试课程，可以看看敏捷敏捷测试员认证课程，因为它们既有实践考试，也有问题考试。如果可以的话，我会停止ISTQB，然后改用CAT版本。
我的问题解决方法是错误的吗？
不，我喜欢您的方法。根本原因是关键。尽管看各阶段是一个好的方向。重要的是已经执行了多少工作，并且由于此错误您必须重新执行多少工作。在Waterfall项目中当然是这样，但是希望没有人再做大瀑布项目了。我认为我阅读的最新统计数据是，大约7％的人仍在进行传统的瀑布项目管理。这个数字正在迅速下降。不要浪费太多时间去理解它，我认为高水平就足够了。
评论
+1为课程建议！我也喜欢您对问题的看法。现在事情变得有趣了。教学大纲中未提及勃姆定律。因此，您给了我更多思考的观点。感谢您开阔我的视野！
–迪皮卡·费尔南多（Deepika Fernando）
16 Dec 17'在11:01
我认为ISTQB确实触及了这个主题（十年前已读过这本书），他们只是不相信Boehm先生。这是我发现的一些在线参考istqbexamcertification.com/…
– Niels van Reijmersdal
16 Dec 17'在11:04
感谢您的链接，是的，您是正确的。教学大纲讲的是这个理论，但没有提及人的名字。顺便说一句，我刚刚完成考试，我觉得自己做得很好。现在等待结果
–迪皮卡·费尔南多（Deepika Fernando）
16 Dec 19'2:59
#2 楼
这个问题试图说明的重点是：我们应该建立“质量”而不是对其进行测试。
测试应在开发开始后立即开始。 />如果我们在开发的早期阶段遗留任何错误，它们将导致“蝴蝶效应”，并且修复起来将变得困难而昂贵。我在这里要使用的类比是：较早的开发就像为建筑物绘制示意图并奠定基础，如果一开始出现问题，由于已经奠定了基础并且已经建立了多个故事，修复起来将非常昂贵。修复后，为了修复其基础/设计中的错误，每个人都需要拆除。
我认为正确的答案是：设计中的错误修复成本最高，因为设计是最早的阶段的发展。
评论
是的，这只是一个观点。另一方面，让我们想象一下该软件已构建并经过测试。当进入“实时”环境时，用户会发现一个错误。您分析问题的根源，找出原因在于“错误的要求”。因此，错误的要求也很昂贵。我只是想从不同的角度分析这个问题。非常感谢任何人都可以把自己的想法放在😊中
–迪皮卡·费尔南多（Deepika Fernando）
16 Dec 17'8:46
#3 楼
在这些选择中，我要说的是，解决需求中的错误是最昂贵的，好像在很早的阶段就没有发现它们，因此必须至少重新检查它们，并可能将其丢弃并从头开始。 。从个人经验来看，更昂贵的一件事是缺少要求，甚至没有要求，就好像您没有要求一样，您无法实现该行为，对其进行测试等，因此您在发现缺少的需求的时间上摆布，这可能会使迄今为止完成的所有工作无效。
#4 楼
请注意。该问题指出何时未发现错误。修复req中出错并在交付后期发现的错误是最昂贵的。
评论
如果这个问题是考试的典型问题，那么考试就很糟糕。您可以对这些答案中的任何一个做出合理的解释，这取决于何时发现故障，每个阶段的整体复杂性，故障的复杂性，负责包含该故障的阶段的工作人员是否仍然可以修复以及其他许多因素。这个问题确实是典型的。解决此问题的正确方法是记住ISTQB的观点是正确的，而不是实际上试图弄清楚这些几乎没有上下文的问题。
迪皮卡（Deepika），这就是为什么许多人不支持或认为认证不能衡量一个人成为优秀软件测试员的能力的原因。最好不要对此过于迷恋，而要通过与人练习和互动来学习实际的测试。
是的，同意！刚完成我的考试，并且很高兴，考试没有像这样的非常模糊的问题。我的意思是，有一些模糊的问题，但是没有这个问题那么模糊