感谢这么大篇幅的回复


但是不同类型的软件可能测试方法天差地别。对于一个小团队来说，如果想实施自动化测试的话是不是只能依赖现成的测试框架，就是想问问大家有什么好的方法或测试框架。

每个模块暴露的接口都要写各种测试case吗？那些不向外暴露接口的模块怎么处理？比方说exe程序。

只能自己写针对性的代码？这样的测试代码量可能很大吧，亦或者有类似liquibase针对数据库的测试框架

现在团队做的产品涉及web前后端（go，js，vue），Windows客户端（gui，Windows service）各种类型应用
【 在 eGust 的大作中提到: 】
: CI/CD 可以说是这些年发展最快的方向之一。以前 jenkins 什么的部署、设置啥的还有点儿小麻烦，现在几大 repo 服务商 github 等都自带 docker + yaml 的解决方案，可以设成 build 跑通了才能 merge PR。aws 也有 codebuild/pipeline/deploy 等类似的解决方案或者接口。
: 现在不少开源项目都实现了完全自动 CI/CD，之前给 DefinitelyTyped 提过一次代码，整个过程有个 bot 辅佐。只要测试全过，至少一个 member 已经 review 了，merge 的主动权可以在提 PR 的人手中，之后大概几分钟就能发布到 npm。前脚 merge 了，后脚直接就给公司的项目提了个 PR 移除自己的类型声明补丁。整个过程在我开源项目 issue/PR 中是体验最好的一次，不像很多项目半年都没人理，等收到 review 邮件，我都不记得有提过代码这回事了。而且 merge 的主动权还给提 PR 的人一些成就感，反正我是很乐意下次发现问题再提代码的。
: 测试也是分很多层，gui 的项目至少也是能做 unittest 的。当然还是取决于项目的设计，我们公司最复杂的 rails 项目是从90年代 oracle db 起家的，核心逻辑都在数据库里。导致的结果就是，unittest 没多大意义，因为 ruby 这边业务逻辑不完整。而 db 这边所有人都不知道该怎么搞 unittest。不重构的话，目前最好的解决方案就是 e2e test，不过这方面 web 还是工具非常多的，直接在 container 里面跑 headless 浏览器。
: ...................
--
FROM 124.126.202.*