在我目前的测试项目中，我们使用 TestNG 作为测试框架。我们将测试套件放在一个单独的文件夹结构中，但它们仍然是项目的一部分。
如果基础架构或编码策略不允许向源代码添加不相关的文件，该怎么办
还针对不同的场景组织了 test_suite.xml 文件（由一个XML文件表示，因为套件是执行的特征），因为默认情况下它们不能在测试源代码中定义。
这样做的主要优点是可以灵活配置要运行的测试。此外，他们可以得到测试人员的支持，他们对测试项目知之甚少。
我认为这取决于您的目标/团队和项目。我曾经在两个模型中工作过，但发现使用这两个模型的优缺点。
同一存储库中的自动化：
优势：
- 您可以共享代码和元素定位符（例如，与Espresso共享），因此易于维护
- 对于开发人员来说，维护很容易（如果他们想要/必须的话）
- 对于开发人员来说，进行代码审查和检查PR更容易看到
- 在开发人员和质量保证人员之间共享有关代码和测试的知识
- Dev可能会意外破坏自动化代码（但是如果qas在做评论，这应该很少）
- 测试自动化将与开发代码使用相同的语言
缺点：
- 您可以共享代码，因此，如果您有一个带有错误的函数，并且在测试中使用相同的函数，那么您的测试也将有一个错误。
- QA可能会意外破坏开发代码（但如果开发人员正在进行审查，这应该很少）
- 项目之间的端到端测试没有意义，因为这些测试被放在一个项目的仓库中并与其他项目集成在一起
- 项目之间的E2E测试将需要具有模拟功能，以测试其他产品/项目上的场景，否则，如上所述，将测试项目包含在项目存储库中是没有意义的
- 无法在项目之间共享代码/功能，因为在不同的存储库中使测试项目与其他测试项目共享功能会造成混乱（除非您使用这些共享功能创建测试存储库）+您可能具有测试自动化用javascript编码的Web项目和移动项目，您将具有与开发团队相同的代码，这可能与网络不同，例如kotlin或swift
在单独存储库中的自动化：
优势：
- 您可以在测试项目之间共享代码
- 由于该项目可以在不同平台项目之间共享，因此您将减少维护成本
- 测试自动化可以使用要编写代码的团队所熟知的语言，也可以使用在不同平台上的项目之间维护代码时更具优势的语言
缺点：
- 对于开发人员来说并不真正可见，因为他们可能不会关注
- 您可以适当地创建涉及不同平台中所有项目的E2E测试，而无需模拟它们
- 对于开发人员而言，遵循并维护测试自动化并不是一个很大的动力
无论如何，我可能会缺少一些东西，但是我只是想记住所有关键点。最后，团队应该共同做出决定，因为这又取决于开发人员是否还要维护测试以及是否要进行e2e测试，而无需模拟其他项目