质量检查方法：您是否重新测试对新版本或仅更改代码的所有更改？

#1 楼

我太清楚这个问题了。不幸的是，没有“正确”的答案，但是您可以采取一些措施来解决此问题。


依赖关系图-您是否具有严重依赖关系的应用程序功能列表并在其他领域发生变化时趋于破裂？如果您知道特征X的变化会破坏特征Y，那么您就始终需要检查特征Y是否存在特征X的变化。反面，如果特征Z被很好地封装并且不会破坏其他位置，则您也许不需要测试elsez是否具有功能z的修复。
考虑一下您的损坏历史记录-系统的哪个区域最脆弱？哪个最稳定？如果您不了解这些知识，则应该能够从组织的问题跟踪系统中检索到该知识，或者与项目经理和其他人交谈以查找信息。
考虑一下整个项目的生命周期-听起来好像您正在通过瀑布式系统工作，在该系统中，代码修复被扔在墙上，以供测试人员签名（如果不正确，请您道歉）。您如何与开发团队合作，以改善团队与团队之间的反馈？它们如何使您的生活更轻松？你让他们更容易吗？两个团队的目标是相同的：您希望将优质的产品提供给客户。我的经验是，通过“如何使这项工作更好？”与开发人员接洽。通常会得到很好的回应。另一个很好的对话开始者是：“我们可以在团队中做到这一点，但这需要几个小时。我想如果你们中的一个这样做，一次只需几分钟，然后每次只需几分钟我们对其进行测试。” （在要求开发人员添加一些挂钩以使自动化更容易时，这确实很方便-但如果您要查找上下文信息或随每个构建通知发送的变更清单等信息，也可能会有所帮助。）
你能得到零钱清单吗？ -如果您的构建通知包含针对该构建而更改的文件的列表，则您将具有更改的起点。结合脆弱和坚固区域的知识，可以为您提供信息，您可以用来确定跳过回归的部分是高风险还是低风险（或介于两者之间的某处）。

您不是关守-测试团队并不是决定是否可以发布系统的真正决定者。通常，您是在向项目管理或产品经理提供有关产品状态的信息。这种思维方式使您可以告诉项目/产品管理人员：“我们可以为此版本跳过测试功能Y，但是存在很大的问题风险，因为对功能X的更改通常会导致功能Y出现问题”等等。根据我的经验，即使假设测试团队是看门人，实际上他们也将被覆盖-我对此非常熟悉。
关注您的角色-测试团队的实际角色是提供向开发人员，项目/产品经理以及某些情况下的客户提供有关应用程序状态的信息。状态信息包括您已测试的事物，已发现和纠正的问题，尚未发现的问题，尚未解决的原因，原因以及尚未测试的事物和原因。这种方法意味着测试团队不再对应用程序的质量负全部责任-它由开发人员，测试人员和项目/程序管理人员共享。

距离完整的清单还很遥远，但希望它将为您提供一些使用的选择。

#2 楼

首先，我一直在你的身旁，我知道你正在经历的痛苦。目前，每个人都谈论“自动化”以及它如何成为持续集成的“金牌”，这也非常“酷”。每个人都希望自己的东西快点消失。

有很多方法可以解决这个问题，但就我个人而言，我认为在两种情况下都需要对风险有所了解。快还是慢。

我不容忍急于发布，这是一件可怕的事情，但是我主张在发布之前对分支代码进行测试以巩固回归计划。您只需进行构建并编译结果，即可获得一些真正的快速胜利。永远不要让开放的错误让构建顺利进行，请始终注意您下次将执行何种回归测试以确认构建。因为我非常了解自己可以使用的平台，并且我们的核心回归测试实际上覆盖了我们代码库的主要或较恐怖区域（例如下订单，用户管理，管理付款明细，安全选项等）。

基本上，我会考虑以下内容：


Build上的测试（dev分支或类似版本）
要重新编译功能测试的列表-作为RC中的回归运行
将这些软件包捆绑在一起以发布（我假设有多个开发分支/版本）
运行任何其他已知的更改以计划其他功能测试（总有人想添加一些东西）
查看RC以扩展回归测试的覆盖范围（您是否覆盖了要添加的所有内容？）
是有没有涵盖软件的任何高优先级或关键区域？ （回归覆盖面太少？！）
继续进行功能测试，错误修复和回归（如上所述）。

没有理由让它“变慢”，这只是需要一些周全的考虑和计划才能取得好的结果。我的经验法则是，如果我三思而后行，那么它在测试中就足够重要了。

上面的好处是它也是一个过程，可以帮助您引入良好的自动化实践可以将您所有的开发分支/构建功能测试都转换为自动回归，从而在RC测试中节省时间。

问的一个好问题是“发布必须快吗？”很多人会说“是”，但是您的客户通常想要什么？ -可能是错误修复，而不是功能。也许考虑不同类型的发布，以及它可能如何帮助创建渠道来集中精力更快，更快地交付某些东西。

虽然这不是“答案”，但我认为。当您对所测试的软件，回归覆盖率以及自动化的测试量（单元，功能，集成自动化）更满意时，做出这些决定会感到更满意，但是您要谨慎。比其他任何人都要谨慎。这不是一个容易的地方，但它是正确的地方。

适应他们的评论祝您好运。您没有做错任何事情，只需考虑效率，而不要增加将代码发布作为测试的唯一风险。如果您考虑正确的话，可以将他们的需求变成对您和您的团队都有利的东西；）

#3 楼

我遇到了完全相同的问题，没有“正确的”答案，但是我可以与您分享我所学到的知识：

1）在一个地方进行代码更改可能在另一个地方引起问题。除非您的项目的文档记录得如此难以置信，以至于您确切知道更改会产生什么影响，否则在发行版上测试整个应用程序很重要。

2）在完成完整测试的频率之间找到平衡。如果您的发布周期是每月一次，那么也许每隔一周运行一次完整的测试周期就足够了。这对您和开发人员都有利，因为您不想等待太久才能发现阻塞性问题，所以不必等到最后才运行全套测试，但是如果每天这样运行，那么每天都要运行一次

3）自动化真的很有帮助。您可能会多次运行许多这样的测试，并且如果有一个自动化的地方，您可以确信它可以很好地完成工作，则可以节省很多时间。

4）如果您不得不妥协（让我们面对现实，有时业务需求会超出我们希望做的事情），则最好的一些完整测试可以测试通用流程。这是确保您测试对客户影响最大的项目的好方法。

5）做初次发言也可能会帮助他们。如果您可以花一个小时来排除高风险的错误（例如上次构建中发生的错误），那么如果仍然存在问题，则可以节省到达该点的时间。开发人员需要了解的是，经过此测试之后，未经测试，它已经准备好进行完整的测试。我认为从长远来看确实可以节省时间，但是一开始他们可能不明白。

我希望这些帮助。我认为您是对的，您需要对计划投入生产的任何版本进行完全成功的测试。

#4 楼

您已经有许多出色的答案。再加上我的2分钱，您的故事将流传至家庭。管理层和我达成了一个令人满意的折衷方案，那就是我仅针对高流量区域和程序模块创建了“小型回归”测试方案。最小回归是根据需要执行的，但通常在安装测试期间执行。这并非适用于所有质量检查环境，但对于我们的环境而言，它可以正常工作。如果发现问题，则将它们记录在问题列表中（而不是缺陷跟踪器）。管理层审查问题；有些被推动，有些被转发给开发人员。从头到尾，如果未发现任何问题，迷你回归大约需要2个小时。但是，如果我发现错误，则可能需要整天视错误而定。

我的建议是保持灵活性！我以前对覆盖范围不足感到沮丧，但是如果管理层认为当前流程可以接受，那么在需要之前就无需进行更改。最好将创造性的精力放在可以做什么而不是不能做什么上。

#5 楼

基本上，您的问题是，您试图将两个月的工作压缩为一个，使自己变得非常高效，同时还要处理大量的代码，还有一大群人声称您正在放慢速度。完全正确，虽然给出的所有答案都会有所帮助，但您还需要使用一些外交手段才能解决这一问题。像其他人一样，在这种情况下，您的人数比4或5多于1，而那4或5在不断增加代码，这些代码可以一次无处不在。您希望能够最大程度地降低风险，并且如果您的经验和缺陷跟踪已表明，一项更改或修正通常能带来更多的收益，那么您就需要在更多领域进行测试。您可以做的事情以最大程度地减少对您的影响（其中一些需要开发人员的帮助，但是如果他们希望缩短发布周期，他们应该希望帮助您）。


开发测试日！我的一家老公司所做的事情，每当开发团队准备进行构建时，他们都会接受它，并提供一些测试清单，然后检查代码。却不是自己的！他们进行了自己的安装并检查了无法使用的区域。通常，这可以使您摆脱安装程序问题的困扰，因为现在您有更多的眼睛来检查问题，通常当他们发现问题时，他们就知道问题并在您之前处理了这些问题，而由于他们刚刚完成了构建，因此对您的抱怨就更少了！ br />发展您的自动化。您无法自动完成所有操作，也无法一次完成所有操作，因此您需要零碎添加内容，找到可以在发布周期内快速进行自动化的一件事，以便进行回归。
了解依赖关系，拥有一个依赖关系图很棒（尽管需要维护），但是我发现效果很好的一件事是与Devs讨论他们认为是什么依赖关系。通常，他们会想到别的东西，特别是如果他们专注于某个领域，然后与受到“可能”影响的人交谈，然后看看他们怎么说。
使构建自动化并进行一些测试，看看是否可以得到每晚进行构建，并每晚进行一些自动化检查。这样，您可以确保某些测试将一直运行。尝试使您的开发人员也进行此工作，因为同样有用的是昨晚构建失败的人，需要对其进行修复。

很难削减测试，而在此期间，风险并显示可能或可能不存在的问题，有时开发小组需要加紧对他们的工作承担责任。这需要大量的外交手段才能使他们接受，理解它，然后继续进行下去，直到它成为文化的一部分为止，但这是可以做到的。