主要关注的是将测试每个零件所需的时间最小化发布。我们有一个大型的旧代码库，它使用的旧技术不利于自动化测试，这意味着我们的大部分回归测试都是手动的。我们不想使用不会增加长期价值的测试来增加每个版本的手动测试负担。
我们也处于受监管的环境中，因此我们确实需要一些方法记录我们测试的内容，我认为当您更改某些内容而不是进行临时测试时，设计一个好的测试是有价值的，但是实际上，如果我们证明了某些事情，那么不会突然中断两年，现在，它们已被修复。
我的“胆量”说的一些示例仅对包含它们的第一个版本有用：
改变形状图形控制显示器，并确保显示这种显示器的所有位置都使用新形状（即，我们没有重复自己的操作，也没有为显示器复制代码-这是我们旧有代码库中的一个示例，在该示例中，我们经常发现粘贴的代码和其他重复内容。
对于控制硬件的软件产品，我们删除了对某些硬件支持的附加设备的支持，这些设备存储在数据库中。我们测试了将数据库从支持设备的版本升级到不再支持设备的版本的行为，并且该设备不再存在于新版本中。
修复了一个“明显”的错误，其中出现了对话框取消等操作时未正确清理。
从另一个方向询问相同的问题：
如何保持手动回归套件随着时间的流逝，“气球”失控了吗？
#1 楼
在决定是否向回归套件中添加某些内容时，我会考虑很多事情。不过，我认为很多都是针对特定产品的；理解客户如何使用产品，升级行为是什么等等在这里非常重要。1）如果错过了旨在测试的缺陷，该怎么办？
/>取决于测试发生的级别（单元测试，集成测试，验证测试等），这可能很难估计，但是您离最终用户看到的内容越近，就越容易分辨出什么内容风险是。
2）被测试的代码更改在程序层次结构中的什么位置？对于非常糟糕的意大利面条式代码，这可能很难说出来，但是依赖该函数的事物越多，您（可能）需要测试的与此事物相关的事物就越少，因为该函数的破坏会破坏该函数中的任何其他组件。操作系统。
3）错误让自己暴露出来，有多少错误？在这里，实际上，我倾向于保留回归套件中涉及更多错误的事物，而不是那些容易暴露自身的事物，因为与在复杂测试中发现更简单的错误相比，发现更复杂的错误的可能性更大。错误。 （这是假设您有测试人员会注意到发生的错误，这些错误不属于测试方案文档。）
3）测试是否可以包含其他测试？例如，当我第一次测试新的，复杂的代码区域时，我首先验证了函数A是否起作用。然后，我验证了函数B是否起作用。然后，我验证了函数C是否起作用。这些功能都在同一代码区中，并且是相关功能，因此，我希望能够在发生问题时缩小错误源范围，并简化调试过程。现在，我同时测试它们，因为测试都很重要，但是如果发现问题，我会感到惊讶。如果其中之一发生了，并且调试起来很困难，那么我总是可以返回并单独测试功能，以查看是哪个问题。
4）有问题的错误在代码中存在了多长时间，它暴露了什么？如果不了解更多有关被测物的信息，就很难对其进行量化，但是如果您由于边缘情况而专门暴露了某些东西，则不必将其添加到回归存储桶中，而是将其添加到我的将来我在编写测试时应该考虑的“最终用户所做的愚蠢的事情对我来说是永远不会发生的。”
5）在某些方面，问题有多细微？问题越细微，您应该对其进行更多的测试。
6）某些功能在现场会发生多少次？在上面给出的示例中，如果可以确定在发布新版本之前每个人都将在发布新代码后立即获得新代码，则可能只需要对数据库更新进行一次测试。但是，如果您接下来可能要有人在三年内选择该程序的新版本，而当前版本已过期两年，那么将回归方案不包括在回归存储桶中可能是个问题。 （我不确定您现在如何进行迁移测试，因此您可能担心也可能不担心）。
评论
这是从“测试创作时间”的角度广泛回答的第一个答案。在悬赏期内，我将敞开大门，争取更多好的答案，但现在将其标记为接受，以确保如果在接下来的几天内没有其他答案出现，将获得悬赏。
–c32hedge
17年8月30日在18:38
这个问题很难解决。如果其他人可以提出更好的建议，我们欢迎他们提供赏金。
–凯文·麦坚时（Kevin McKenzie）
17年8月30日在18:54
#2 楼
可以采用的一种方法是编写一个详细测试该错误的一次性测试，但在回归套件中的现有测试中添加一两个步骤以验证该区域仍然可以正常进行。它仍然会增加套件，但是速度要小得多。“自动化测试”是模棱两可的，它具有很多含义（Selenium端到端测试，集成测试，单元测试等）。 ）。
假设您指的是某种“端到端，前端测试”，另一种方法是让开发人员围绕该区域编写一个单元测试，以验证该错误是否已修复（在构建中运行）管道），请对其进行一次手动测试，然后将手动测试存档。
评论
假设我们在这里谈论的是手动测试，并且由于现有体系结构不佳，甚至单元测试也不总是可能的。在我们可以编写单元测试的情况下，通常这样做而不是添加更多的手动测试。
–c32hedge
17年8月25日在19:01
虽然第一点是+1。如果人们寻找一个现有的测试来更新而不是为每个回归创建一个全新的测试用例，那肯定会有所帮助，但是很难做到这一点。
–c32hedge
17年8月28日在22:06
#3 楼
自从我写下答案以来，似乎该问题已得到实质性编辑。 OP现在说他们有大量的手动测试。我在某处读到的一条经验法则是考虑丢弃任何一年内未检测到错误的测试。如果问题不是很严重，则将其丢弃，如果检测到的问题是严重的，则将其保留。只需手动操作即可。
如果您多次运行测试，为什么会摔倒而需要将其丢弃？ CPU时间便宜。
仅在需求发生变化时丢弃它，不值得为了适应变化的需求而进行修复。
代码（包括自动测试）就像纹身：它将粘在您身上很长的时间。
如果只想执行几次测试，强烈建议不要100％自动化：准备有能力的测试文件。只考虑将零件重复很多（数十次和数百次）的自动化零件。或者在确切的步骤和时机至关重要的地方。
评论
问题不在于是否要自动化。正如我提到的那样，使用该技术，我们无法轻松地自动使用其中的许多功能。假设所有有问题的测试都是手动的。我100％同意CPU时间便宜，如果我们将这些测试自动化，就没有理由放弃，但是我们谈论的是测试人员/开发人员的时间，因此，每增加一次测试发布就意味着我们不花时间在下一个版本中工作。
–c32hedge
17年6月28日在20:35
好的，您已经大幅度更改了您的问题，所以我尝试回答您的新问题。
–Peter M.-代表莫妮卡（Monica）
17年6月28日在21:35
我所做的只是用粗体显示了一些内容:)
–c32hedge
17年6月29日在13:15
另一方面，如果测试没有发现任何东西，是测试，还是您没有改变测试方式，那么看起来什么样的测试数据足以捕获问题？
– Veretax
19年4月2日在19:58
#4 楼
一些注意事项：设置时间限制，当套件达到时，减小套件的大小，直到其在该限制以下
设置手动测试以尽可能地模拟和存根和合适的
标签测试，并执行诸如高兴和冒烟等子集
大图片视图。 1个测试很少会失败，例如千分之一。1000个测试中，概率= 1：1可以吗？
评论
您能否弄清楚最后一点是什么意思？
–c32hedge
17年7月11日在13:53
想讲解吗？ :)
–c32hedge
17年8月29日在15:12
#5 楼
我不明白您是否正在手动测试由于回归测试中包含的模块而未更改的模块？那不要那样做回归测试区域存在可能出问题的风险。或者您在一个模块中进行了更改，并且有可能在另一个模块中发生了故障，因此您也必须进行测试？然后，您需要更好的开发实践，因为那还不行，并且测试将无济于事，甚至讨论测试实践也毫无意义。
评论
我不太明白你的第一个问题。手动测试将是回归测试，但我想更好地应对，假设我们已经确定了可能出问题的风险，是否还有足够的额外风险，有人将来会破坏相同的功能，这是一个无意的更改，值得长期进行回归测试。至于第二个问题，这是处理大型旧代码库的不幸方面。与20年前撰写时相比，现在我们有更好的开发实践，但就目前而言...
–c32hedge
17年8月25日在20:30
...这就是我们的位置。我们需要继续支持现有软件（数百万个LOC），因此即使我们今天可以开始进行完全重写，我们仍然需要在相当长的一段时间内维护现有代码库的测试。
–c32hedge
17年8月25日在20:35
如果您的回归套件包含测试x y和z，也许在回归测试1中您需要执行测试x和y，而在回归测试2中您需要执行测试y和z？换句话说，在计划回归时，您包括事先确定的测试，在此回归测试中实际上是有价值的。您可以根据编写的代码及其影响的范围来确定有价值的内容。
–乔治
17年8月25日在20:51
嗯，我想您指的是我的小组所说的“回归回合”。尽管我们确实尝试限制根据风险分析实际重新运行的测试，但由于存在相互依赖性，我们采用了确定由于给定回合的低风险而无法运行的测试的方法，而不是确定会导致风险的测试应该运行。我知道，它是倒退的，但人们的信念（不确定我是否同意）是，与确定针对给定发行版/回合的100多个修复程序来确定要重新运行的每个测试相比，这工作量少。
–c32hedge
17年8月25日在20:57
恐怕我当时没办法。除非您重写系统的足够部分或开始做较小的发行版，否则我认为您可能只会被可怕的回归所困扰。因为如果一切都可以破裂，它们实际上可能会以某种方式变得有价值。也许排名测试？从高风险区域开始，移至低风险区域，如果发现任何错误，对其周围的事物进行调查等。随着新的更好的测试的加入，逐步淘汰较低的测试。
–乔治
17年8月25日在21:11
评论
我实际上不了解，这些手动回归测试如何进行？您基本上已经列出了这些开发人员必须检查的事情？我们实际上是编写一个手动测试用例，或将其添加到现有的测试用例中。如果是错误修复，则测试将使测试人员行使可以发现该错误的功能，并且预期结果描述了正确的行为。更改后的功能类似。
感谢到目前为止的答复。但是，我认为当前答案尚未解决的一件事是用于确定何时编写测试的想法，该测试是长期有用的还是仅运行一次即可。我们绝对需要跟上修剪旧版本的步伐，但是如果我们制定了一些准则，并且可以在编写“一次性”测试时将其标记为此类，那么维护会容易得多。在开始编写/记录它们的方式上，我们也可能会更轻巧。
这听起来可能有点前途（但是，它不认为这在现代世界中是一件非常复杂的事情），但是可以构建一个神经网络，在当前回归集上对其进行训练（这里最具有挑战性的事情是分解测试）对象变成一组“功能”），如果测试是针对测试创建时间的一次性测试，则该NN会回答。毕竟，NN是用来解决分类任务的。
@AlexeyR。不错的主意，但是可以肯定的是，将测试分解为正在接受的培训。在某些时候，我想浏览并制作某种“功能图”，并将其与我们正在实际测试的区域相关联，因此也许可以将这些构想以某种方式组合起来。