我正在构建一个CD管道。我正在计划它的自动化测试部分。我计划做UI，WebService，Security，Perf测试。我有一个关于代码结构的问题。因此，我计划在与代码相同的repo中进行测试，然后为核心测试框架（如）进行单独的repo
回购产品
- 产品代码（项目）
- 集成测试（项目）
- 功能/e2e测试（项目）
- UI测试（包）
- WebSvc测试（包）
- Perf测试（包）
- Sec.测试（包）
回购测试核心
- UI测试框架代码（项目）
- WebSvc测试框架代码（项目）
- Perf测试框架代码（项目）
- Sec测试框架代码（项目）
有人看到这个结构有什么问题吗？还有其他想法吗？此外，我对集成测试和功能测试项目中的内容有点模糊（例如，WebSvc测试可以是两者的一部分）。验收测试在哪里（功能测试或集成测试）？如果有人能指出一些关于这方面的例子或文章，那就太好了。
感谢
我觉得这种结构有些烦人。
从提议的结构中，我推断您想要构建自己的测试框架。这听起来很可疑，尤其是当你想写其中的4个时。
另一方面，您将它们都放在同一个存储库中，因此它们似乎密切相关。再说一遍：不一定坏/错，但确实出乎意料。
由于除了结构之外，我在你的问题中找不到任何提示，这为拥有单独的存储库提供了一个很好的理由，所以我建议只使用一个，假设你的"测试框架"只是测试你的主要项目的实用程序。
基本规则是，一起发生变化的东西应该放在一起（在一个存储库中）。其他一切都让开发变得非常麻烦：更改A、安装、更改B、运行、调试、重复而不是更改、运行、除错、重复
既然你提到你还不完全清楚，什么会去哪里，我建议如下：
从一个项目开始。在该项目的测试目录中编写所有测试。观察你是否遇到问题。如果是这样，请调整。你可能会经历的事情，触发项目提取：
- 测试运行缓慢，并且您希望单独运行它们
- 测试需要一个已部署的应用程序，所以它们应该在构建和安装完其他所有东西之后运行
- 不同模块中的测试需要访问不应该存在于主项目中的代码，因此它可能最终会出现在具有测试支持代码的模块中