11 | 互联网产品的测试策略应该如何设计？
该思维导图由 AI 生成，仅供参考
研发流程的不同决定了测试策略的不同
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
互联网产品的测试策略与传统软件产品有着明显的差异。由于互联网产品的快速迭代和发布周期短，测试时间有限，因此需要采用并发执行机制和缩短测试执行时间的策略。相比传统软件产品的金字塔模型，互联网产品的测试策略更像是菱形结构，重点放在API测试上，采用轻量级的GUI测试和分而治之的单元测试。GUI测试通常采用“手工为主，自动化为辅”的策略，而API测试则具有高效率、稳定性和可重用性的优势。单元测试则针对相对稳定和核心的模块和服务进行全面测试。这种测试策略的设计能够更好地适应互联网产品的特点，确保测试质量和覆盖率。
《软件测试 52 讲》，新⼈⾸单¥68
全部留言(49)
- 最新
- 精选
堂置顶非常赞同作者对于互联网产品较于传统产品测试策略比重变化的观点。我们项目属于互联网产品，采用微服务的架构而且前后端完全分离。当时在项目初期自动化框架选型的时候，鉴于项目迭代速度快、人员短缺且大部分缺少比较好的代码能力的情况，我决定采用了postman+newman+jenkins的方式，在api层面实现了从数据初始化到覆盖系统7大流程的集成、系统回归测试。中间有尝试使用python进行脚本化的转变，但是效率却没有得到提升。原因可能是我们脚本可能不够灵活吧，但还有一个原因是我们通常使用postman进行接口的调试，调试完成后可以进行简单的参数化就把这些调整过的接口或者新增的接口纳入到回归测试脚本中，不用再进行额外的开发。而且postman流程化的脚本，可以在任意步骤打“断点”，对于我们人工进行流程调试验证以及造数据都有很大的方便性，至少这个这个项目一年多了，在主流程上通过api流程化脚本的覆盖下，还没有发生过大的问题。但是之前跟一个测试经理沟通时，他说我们的方式根本不属于自动化的范畴。但我个人还是比较坚持，毕竟自动化是为了提高效率并且需要注重投入和产出的，只要效果是好的，形式不是很重要不是吗？不知道作者能不能谈下您的观点？作者回复: 我是完全支持你的观点的，这个一定是属于自动化测试的范畴，postman+newman是很好的轻量级api测试实践，在结合jenkins可以说能够满足绝大多数的CI/CD的要求。👍
2018-07-3029
Cynthia🌸置顶关于api测试，希望后续仔细讲讲如何开展。因为具体到业务的api，数据之间流转，各种关联性还是比较强的。有些还牵扯到加密，解密等等。 但是对于单独一个api的开发而言，他可能根本不关心数据的流转，只知道按照需求实现代码，这样就给测试带来很多问题，和开发沟通时很难一下子找到自己想要的内容。 希望能聊聊您的经验。 另外就是对于互联网测试的策略总结的很好，现在看到不少书还是沿用传统的思路去说测试策略，感觉又笨重又无法迅速拿来进行实践。 这部分以后会深入聊么，还是点到为止了？作者回复: 你说的很多，单个api测试容易，但是很多api之间交互和依赖，再加上现在的微服务化，都对api测试提出了很高的挑战，后续文章会专门来讲这块，尤其会去谈基于消费者契约的api测试。关于互联网测试策略，后续我们会讲的测试数据服务和测试基础架构设计都是为了适应互联网产品测试的实践，希望可以对你有帮助。非常感谢高质量的留言👍
2018-07-2338
Laura张远园工业机器人、敏捷团队，属于敏捷下的传统测试。 我们测试人员的KPI指标是测试自动化率，所以gui测试也基本全部自动化，一旦用户界面变动测试人员就要加班改测试代码。 我们测试人员写单元测试的目的是用单元测试覆盖测试需求，减轻gui覆盖测试需求的代码量和维护成本，而在前面的文章中已经说明单元测试应当覆盖代码保证代码质量、而不是覆盖测试需求。 在之前公司做通信应用层测试时，在信令交互中，会为了测试某一个模块功能，模拟其它模块向该模块发布消息，以便检测该模块的回复消息，是不是属于api测试? 52讲12篇拜读下来，感叹于老师测试知识的广博。想请教老师:一个测试人员应当如何进行积累以达到测试知识的体系化与深度?似乎找不到测试体系化的教科书，我们可以有哪些途径进行积累。 向老师请教，谢谢老师作者回复: 感谢你的大力支持，其实很多知识都是来自于项目的实践，并没有大而全的教科书可以告诉我们所有的东西，其实这也体现出了测试工程师必须要具有的我快熟学习能力。另外你说的信令测试，这个严格来讲不属于api测试，而是属于集成测试的范畴。
2018-09-015
Nic辉少打卡，👍作者回复: 👍
2018-07-291
乐少目前公司的api业务都是异步处理的,想听听老师又那些方案分享一下的作者回复: 异步的api测试是比较麻烦的，我会在后面讲api的时候详细来谈。
2018-07-251- Geek__c1668bdf82c6我们项目就是属于开发周期短，版本迭代快的那种，目前我们一周一发版，以前对各功能做了全面的ui自动化测试，后来产品对页面做了重构，ui就全部更换，自动化就停止了，现在主要放在了api自动化测试上，相对稳定，不需要经常改
作者回复: 这是目前很多企业的思路，但是还是建议做清凉级的gui测试
2019-04-15 
宁江孤影敏捷开发模式下，测试时间严重不足，目前所在的项目组并没有要求做自动化测试。自己利用空余时间用RF+jenkins把测试用例跑起来，想问下老师目前比较流行的python在用例维护上会比工具来的方便吗？作者回复: 使用python也是需要使用工具来管理用例的
2019-01-10
年轻人的瞎折腾^.单个API测试，我们用postman+思维导图+后期接口自动化输出。其实也会有场景侧漏的情况，请问是要如何尽可能避免场景侧漏的情况呢，是需要看开发的代码改动点么，但是看开发改动点不会有点麻烦？还有什么好方法么？作者回复: 可以基于代码覆盖率给出参考，但是对于没有在代码中处理但是应该要处理的部分，通过代码覆盖率依然无能无力，还是需要从需求的边界情况出发来设计用例
2018-12-092- 张哈哈您好，这是我的第一次留言，阅读了老师的文章，每一篇都或多或少的给了我启发，谢谢老师。 自我从事测试以来，我的测试重点都是GUI测试上，而API测试只是简单的测一下。特别是从事APP测试以来，感觉很少问题会出现在API开发上，大部分问题还是产生在移动端的开发上 我想问一下：在测试时间有限的情况下，如果我把重点放在API测试上，是否会不合理呢？
作者回复: 现在很多大型互联网公司都把测试重点放在了后端api上，当然这还要取决于你的系统架构是怎么设计的
2018-12-06 
【粉粉】我属于传统测试类，想了解一下，互联网中单元测试，只对那些相对稳定并且核心的服务和模块开展，而应用层或者上层业务只会做少量的单元测试，这么做考虑的主要因素是什么呢作者回复: 主要还是研发的cost问题，同时上层变化的几率要比较大，roi不高
2018-11-18
