非常赞同作者对于互联网产品较于传统产品测试策略比重变化的观点。我们项目属于互联网产品，采用微服务的架构而且前后端完全分离。当时在项目初期自动化框架选型的时候，鉴于项目迭代速度快、人员短缺且大部分缺少比较好的代码能力的情况，我决定采用了postman+newman+jenkins的方式，在api层面实现了从数据初始化到覆盖系统7大流程的集成、系统回归测试。中间有尝试使用python进行脚本化的转变，但是效率却没有得到提升。原因可能是我们脚本可能不够灵活吧，但还有一个原因是我们通常使用postman进行接口的调试，调试完成后可以进行简单的参数化就把这些调整过的接口或者新增的接口纳入到回归测试脚本中，不用再进行额外的开发。而且postman流程化的脚本，可以在任意步骤打“断点”，对于我们人工进行流程调试验证以及造数据都有很大的方便性，至少这个这个项目一年多了，在主流程上通过api流程化脚本的覆盖下，还没有发生过大的问题。但是之前跟一个测试经理沟通时，他说我们的方式根本不属于自动化的范畴。但我个人还是比较坚持，毕竟自动化是为了提高效率并且需要注重投入和产出的，只要效果是好的，形式不是很重要不是吗？不知道作者能不能谈下您的观点？

嗯嗯，其实之前，我一直把金字塔模型作为目标，但是回头看看实际情况，我们确实是一直还在 GUI 自动化上挣扎。

看到茹老师的菱形测试策略，感觉如获至宝。

一方面，GUI 自动化可以下沉，往接口测试靠拢，UI 操作的底层实际也是接口的调用关系，所以是可行的；

另一方面，单元测试可以加大颗粒度，这样也变成了接口测试，单元测试的颗粒度要求真的太细，对于快速迭代的互联网产品来说，需要有一套完备的机制来保证，而这个在目前的国内环境是办不到的，如果加大颗粒度到接口测试，应该也是可行的；

但是，目前很多公司的现状是，开发代码的分层并不明显，导致接口测试需要大量的 mock 测试代码，同时也增加了实现的难度，这是我们目前面临的比较大的问题。

以上，欢迎关注公众号「sylan215」一起沟通交流。

工业机器人、敏捷团队，属于敏捷下的传统测试。
我们测试人员的KPI指标是测试自动化率，所以gui测试也基本全部自动化，一旦用户界面变动测试人员就要加班改测试代码。
我们测试人员写单元测试的目的是用单元测试覆盖测试需求，减轻gui覆盖测试需求的代码量和维护成本，而在前面的文章中已经说明单元测试应当覆盖代码保证代码质量、而不是覆盖测试需求。
在之前公司做通信应用层测试时，在信令交互中，会为了测试某一个模块功能，模拟其它模块向该模块发布消息，以便检测该模块的回复消息，是不是属于api测试?
52讲12篇拜读下来，感叹于老师测试知识的广博。想请教老师:一个测试人员应当如何进行积累以达到测试知识的体系化与深度?似乎找不到测试体系化的教科书，我们可以有哪些途径进行积累。
向老师请教，谢谢老师