感谢这么大篇幅的回复


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

每个模块暴露的接口都要写各种测试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.*

这几天一直在消化你说的这些框架，以及查找资料。

发现很多框架是针对编程语言或程序类型的，web测试工具、框架就比较多。像c++写应用程序好像就不怎么好测试，c++写的服务程序，gui程序等等。如果是针对功能、接口写测试代码，比方说我新加一个接口，可能需要写5个case，但是如果开发人员偷懒或者没想到那种情况，写两三个case，还是会引入bug，那是不是只能边人工测试边加自动化测试得case了。

那些开源项目没有通过自动化测试就不能提交代码是如何做到的呢？
【 在 eGust 的大作中提到: 】
: 大的小的都一样啊，正常都是拿成熟的测试框架直接用啊。
: unittest 是非常成熟的，稍微新点儿的语言都直接自带了，老点儿的也都有主流的包。比如你说的 go 就不算老，直接就能 go test。像 python、ruby 这类脚本语言就算老，加个测试也就一个官方包而已。js 的话，jest 是占主导地位的，还有 mocha 也比较流行。
: 理论也很简单，就是保证每个单元都能单独正常工作，出 bug 就在相关测试里加 case。设计上就是分层，尽量相对独立，可以单独测试。不同层之间 interface 尽量稳定，必要时按照接口 mock 其它层，这样尽量保证每一层的功能稳定。很多静态语言的框架里，有时甚至专门套一层，就是为了方便 mocking，然后就搞成了俄罗斯套娃。
: ...................
--
FROM 124.126.202.*

它能检查每个分支有对应的测试单元？

这个框架是要有解析语言的能力，那真是太强大了

我记得在很多年前，用过pc-lint检查代码，感觉他爆出来的太多，不实用，也就不再用了。（也许是当年还年轻，不会用），他好像就是语法级检查。

如果没有开源或现成框架，搞一个您说的那样测试框架，对于小团队来说，那就望尘莫及了

【 在 dpblue 的大作中提到: 】
: 有自动化工具检查新增加的代码有没有单元测试
: 比如代码原来是：
: if (this) then that
: ...................
--
FROM 124.126.202.*

是，bug不可避免，只要是人去做，就有出错的可能。

其实，我主要想把严重的bug在编译完成之后，打包之前能筛选出来。以前碰到过什么情况，就是一个人引入一个fatal bug，导致QA拿到新的包不可用，不光影响QA的工作，别人修改的代码也无法验证。

这时候如果有自动化测试环节，可能影响就会降低很多。长期来看，对整个团队的效率都有提高。


【 在 eGust 的大作中提到: 】
: c++ 的测试框架我没概念，毕竟没做过相关的方面。
: 不是不能提代码，你一样能 commit，能建 PR，只不过不能 merge 而已。对于成熟的老程序，最暴力的方式就是跑完测试之后看 coverage，没到100%挂掉就完了，当然前提是已经有100%的底子。另外，至少 review 的时候，就算看不出来全不全，至少有没有还是很容易的。
: 另外要明白自动测试的价值所在，并不能避免 bug 的发生，但是能够避免同样的 bug 再次发生。有个经典的笑话：
: ...................
--
FROM 124.126.202.*

可以通过流程管理来避免break build这种情况。

developer提交完代码可以自己提交编译自己那部分，编译成功之后，自己可以先拿回来测试一下或者跑一下自动化测试，没有问题就当作打包的备选版本。整个项目打包的时候不再build，而是去拿这些备选版本打包。这样可以做到开发者随时发现编译问题，或重大问题版本不入包，需要整体安装包的时候也能在很短的时间内出包。
【 在 leadu 的大作中提到: 】
: 赞！
: 我之前参加过的项目有这种情况，这都是大型项目了。
: 严重影响QA的主要有两种情况，一种是break build，另一种是build不能用。
: ...................
--
FROM 124.126.202.*