开发人员，测试人员和业务用户是否应该具有一个统一的测试脚本？

在开发中，我通常会拥有自己的测试脚本，这些脚本将记录计划测试的数据，方案和执行步骤。这是我的开发测试计划。将功能部署到Test后，测试人员将使用自己编写的测试脚本对其进行测试。在UAT中，业务用户然后使用他们自己的测试计划进行测试。

回想起来，这似乎提供了更好的覆盖范围，开发测试混合了黑盒和白盒测试，而测试人员和企业用户则专注于黑盒测试。但是另一方面，这带来了仅在每个阶段执行的独特测试用例（即，测试人员认为仅在测试阶段执行的一些用例），并且希望开发人员错过它，这使其成为查找/错误。 。

从一开始就合并测试脚本是否值得？因此，使用一个统一的测试脚本，还是在前期做起来有点困难？

首先，质量检查不是测试。如果您的质量检查部门没有参与整个开发过程，则它们是测试，而不是质量检查。质量保证在工作时提供质量保证，充其量地说，测试表明质量缺乏，但不能证明质量存在-即测试表明质量保证已失败，但不能表明其成功，因此测试和质量保证不应属于同一部门。

我认为最好的方法是让每个小组管理自己的测试，因为它的确提供了更好的覆盖范围。但是，每个团队都应尽快开始测试。这意味着UAT会在用户可能使用某些功能后立即开始，Test在其要进行测试的部分准备就绪后立即开始启动。这可能意味着您需要重新调整工作模型，因为UAT和Test经常希望使用完整的产品，并且需要培训以测试部分完整的输出。除非取消工作流程并且开发人员“完成”表示完成，否则它可能会更昂贵。

质量保证部门应对此进行监督，同时还要采取其他质量措施，以确保过程不仅可以提供所需的质量输出，而且还可以达到适当的效率水平。

编辑：原始问题对质量检查的引用已被删除，因此此答案现在显示为OT。

我们从一开始就使用UAT。

它可以作为通用参考，我认为效果很好。尽管可能只有开发人员或测试人员将测试脚本用于较小的组件，但测试的方向始终指向一个统一的目标。归根结底，UAT是唯一重要的功能，因此您不妨一开始就将其作为重点。

从一开始就进行UAT也有一个额外的好处。它确实消除了客户期望与您自己之间的任何歧义。

他们不需要统一的测试脚本，因为他们测试的事物和执行测试的方式通常被认为是不同的，他们需要的是各方都在努力的统一要求。如果UAT和QA正在测试开发人员从未想到的事情，那么该是时候查看这些要求了。

我同意，拥有针对开发人员，测试人员和业务用户的统一测试脚本会很高兴，但是我相信，如果不付出太多努力，那么付出的代价就不菲了。

造成这种困难的原因是每个系统中的数据库内容都是不同的，并且测试通常严重依赖于数据库内容。我们“统一测试”的方法是，每个系统还获得一个额外的测试数据库，并且有一些脚本可以从头开始创建该数据库。测试脚本针对标准内容的testdb运行。

理想情况下，开发人员必须具有单元测试（xUnit），测试人员-自动集成测试（Selenium）和业务用户-验收测试（FIT）。他们可以相互访问测试。

这确实取决于项目。在某些情况下，开会讨论结果的统一测试，质量检查和UAT团队可能会非常有益。它节省了重复的测试工作，并通过UAT脚本确保各方对业务需求有更清晰的了解。另一方面，根据项目的复杂性，在测试业务示例之前对输入和输出进行全面质量检查可能更有意义。对于自行开发的系统，在用户接受之前必须进行初始质量检查。对于开箱即用的实现，一个统一的测试团队将是最有意义的。