证明更高的管理，测试已经正确完成
作为一个测试人员，我经常会遇到这样的情况，我已经批准了一项功能正常工作。但是，当它转移到生产环境时，功能似乎完全/部分地被破坏了。在两者之间，我可能会收到来自开发人员的各种bug修复的版本数量。在这个时候，任何版本的功能可能都会被破坏。但是，我可能无法每次验证每个新版本的完整产品。最终，在生产中报告错误时，测试团队的问题就是“为什么错过了以及如何？”。主要问题是我可能没有必要的证据来证明我已经正确测试了我的声明，或者我甚至不知道在哪个版本中发生这种破损。证明更高的管理，测试已经正确完成
那么，我在这里错过了什么。如何证明测试已正确进行。另外，在进行新版本时应该设置什么样的入门标准。请帮我在这
该死的，你遇到了一个难题。当你看到一个失败的生产系统在你面前时，我认为你无法向你的经理证明任何东西。
您可以部分防止发生这种情况。恕我直言，唯一的方法就是编写自动化测试，这将对每个新版本进行严格的测试工作。如果在测试功能（并且很好）之后，请使用测试来保护它。从那一刻起，如果开发者通过修复另一个问题（假设你写了一个好的测试）来解决这个问题，测试将会失败。通过这种方式，您可以防止测试功能中出现的错误...部分...
部分原因是因为错误经常发生在角落案例中。从理论上说，你应该在测试中打满所有角落。在现实世界中，您正在进行风险评估，并确保所有重大风险都得到缓解。根据同样的经理现在不得不处理破损的应用程序，测试其余的可能的错误通常太昂贵了。你能做的唯一一件事通常是让经理意识到他的选择。
所以实际上最主要的是：如果可以的话，写自动化测试，记录任何可能的事情，并显示可接受的风险。仍然管理者可能对你很难......至少当你编写的自动化测试在当前系统上失败时，你可能已经保存了你测试它的时间证明，并且它工作。
万无一失测试的关键在于准备comprehensive和宽基于用例场景不等，预计所有可能exceptionalconditions;准备测试数据以有效测试此类情景并根据预期结果评估获得的结果。由于在测试之前已经预见了各种场景及其组合，因此在生产过程中遇到任何错误的可能性大大降低 - 如果不能完全消除的话。
此外，在发生各种各样的事件后，您可能会了解一些功能/模块，这些功能/模块主要受到各种构建的影响或破坏。因此，至少在高优先级的基础上 - 您可以测试它们，如果不是完整的产品。
您还可以找到一种方法来记录任何经过全面测试的测试 - 屏幕截图，视频或任何其他类型的报告，以防万一您需要证明该场景未被忽略并且在测试过程中运行由你。
确切地说，我需要做的就是收集在初始测试期间没有错过这种情况的证据。我正在考虑一个截图选项来做到这一点。但我的软件有一个选项，在任何时候，任何新的页面都可以基于新的设备添加添加。因此，我需要查看的页面数量可能会一天一天地变化。这种情况可能是这样的，同一个页面重复n个设备的数量为100.在这种情况下，我的大部分时间都将用于截取屏幕截图。但坦率地说，sc.shot是最好的，但是想知道最好的方法， – TestBud
在发布之前，应该对应该做多少回归测试做出明确的决定。这个决定应该基于对引入生产错误风险的测试所涉及的努力进行权衡。
这是生成测试报告的原因之一。这不仅仅是为了表明测试成功完成，还要显示什么测试没有完成。
通常，业务代表将审查测试报告并决定他们是否感觉测试已足够。这通常是一种折衷。
是那些获得作出的决定可能是这样的：
我们将做充分的回归测试上最流行的浏览器，但我们不会做它在其他浏览器。
或
我们会做一个局部的回归测试，希望只覆盖最重要的功能。
其中一个重要的方面是，对产品负责的人有意识地决定承担风险。如果在未经测试的区域发现错误，他们就不能转身抱怨。
理想的方法是在发布前进行完整的回归测试。通常，唯一可行的方法是使用测试自动化。添加这种自动化覆盖可能会很昂贵，但应该始终认为自动化测试可能会运行数百次或数千次。 每次测试运行的自动化测试成本可能很小。
是否有任何有关如何在发现错误时做出决定的参考，在不同的环境中连续部署。因为即使错误是通过自动化套件识别出来的，我的困境是我是否必须遵循初始测试环境中的错误修复，或者是否直接在发现错误的环境中应用修复。即如果在分期中发现我的错误，那么我是否应该在分期中应用修补程序，或者先在我的测试床中应用，然后应用于分期。 – TestBud
如果存在尚未解决和重新测试的已知错误，正式组织将不允许代码从一个环境移到下一个环境。唯一的例外是如果一个商业人士同意推迟这个错误，因为它是低优先级的。敏捷组织中的方法会有所不同。一旦发现错误，他们很可能会编写自动化测试。这个测试是为了在错误存在时失败而编写的。然后，一旦错误得到解决，自动化测试将重新运行以确认修复。它也可以在其他环境下轻松重新运行。 –
这很有帮助，编写失败的自动化测试并在下一次构建期间重新运行。注意！。如果你能指引我参考一下，我可以看到类似的情景以及必须采取的行动，这将会非常有帮助。因为作为持续部署的一部分，所有我听到的持续集成都是自动化的一切。但是，这是必要的，我正在寻找什么时候什么是自动化的，什么时间点以及什么时候决定自动化某些东西的标准。坦率地说，我根据场景寻找战略决策 – TestBud
对我来说，可能会有环境问题。在我以前的项目中，有时准备安装说明很有用。它防止了许多问题。当你在一个环境中进行测试并且你做了几次升级时，你可以忘记你改变了什么，例如数据库中的一些新的字段，计算机，浏览器，一些库的配置需要安装等的一些变化等。 这将是伟大的您可以在安装到其他环境后再次测试您的系统（例如，集成或验收测试应该在不同的环境中提供，就像您进行系统测试一样）。如果不可能，请考虑在内部第二环境中构建系统。我的意思是在完成测试后，将系统安装在其他环境中并再次进行测试（至少是回归测试）。
你可以考虑的其他事情是测试数据。也许你在完全不同的数据上进行测试，比如在实时系统中。如果有可能问你是否可以得到一些真实数据的样本（可能是在匿名之后）。
感谢您的回复。从答案来看，我已经得出使用自动化套件的结论是最适合的情况。我已经尝试了一些POC的一些新的发展，它证明是非常有效的，同时节省了大量的体力劳动，而质量没有任何妥协。我现在唯一的问题是糟糕的测试数据集准备。不过，我打算加强与其他团队成员的意见一致，以使该套件处理所有情况。此外，计划为可重用性提供一个完整的框架。
此外我会集中精力。 1.测试数据准备和参数化。 2.工作框架准备。 3.正确报告框架集成以提取故障和截图。 4.实现与CI工具的持续集成。
我会尽全力保证您的工作按计划进行。
再次感谢大家给我的清晰。干杯！！！！！！！！！
您没有正确进行测试。你没有测试投入生产的版本，而且你被烧了。如果您获得了错误修复版本，那么请检查每个错误修复。但最终，在部署之前，您需要再次测试一切。当然，如果你使更多的测试自动化，那么你可以在每个构建中运行它们，这是最好的地方。 –