合理的测试策略从何而来？
功能测试的工作究竟是不是点、点、点呢？
我认为点点点是功能测试工作的一部分，但不是全部。测试工作表现在执行层面，就是通过自动化或者手工的方式去完成测试场景、案例，所以执行阶段的点点点是一定要有的。但正是因为测试工作的重复性和执行层面的直观性，掩盖了测试岗位的核心能力，那就是你的测试策略！
测试策略涵盖了分析设计、案例拆分、造数等等，好的测试策略可以充分覆盖所以场景，能够暴露所有缺陷。举个栗子：
假如测试对象是一个后台接口。有如下两个测试策略：
策略A：测试字段入库、非空字段、字段截取、入库补数逻辑、测试接口时延、下抛报文；
策略B：（1）字段入库：考虑各字段入库的正常、异常、截取、转换；（2）关联逻辑：考虑入库补数关联、字段入库之后与其他字段的连接和拆分；（3）其他：接口调用方全流程测试、单接口与多接口之间的耦合、接口时延和超时、下抛报文、安全性测试。
对比一下策略A和策略B哪个好？很明显策略B更全面、更详细。尽管策略A也可以覆盖一个接口80%的功能，经过策略A测试的接口上线之后不会有大问题，但是如果一旦有异常情况出现，就会暴露问题。
测试岗位的尴尬也体现在这里了，一个接口测完之后，策略B和策略A可能暴露的问题是一样的，但是策略B耗费的时间明显更多，难道我们应该舍B取A吗？我认为不应该，因为功能测试是证实的，不能证伪，所以被证实的范围越大就代表待证伪的空间就越小，质量越有保证。
那合理的测试策略从何而来呢？或者换句话说，如何保证测试质量呢？
归结起来就是两个“多”--多学习、多总结。具体到执行层面就是要做到如下几件事情。
首先就是要多学习相关技术，每个对接的产品都会有一个技术栈，针对产品特性学习相关的技术很有必要。例如大数据相关的产品，就有必要学习一下Hadoop、Spark、Flink、Kafka这些东西是做啥的，有哪些需要注意的点；例如AI模型类的产品，就有必要学习一下机器学习的一些概念，回归和分类什么区别，损失函数是什么，准确率和召回率怎么计算的，测试集和验证集怎么划分的等等。当然，一些通用的计算基础知识必须掌握，“计院四大名著”跑不了的，数据库基本知识、编程语言要掌握。
其次是建设资产库，制作checklist。一个项目结束之后，必须留一段时间作总结，一方面是将本次项目的改动点维护进资产库，方便后续查阅。一方面是对本次测试过程中出现的问题进行总结，好的测试方法要及时记录，容易遗漏的测试点要及时归纳。最重要的是要结合项目实际情况建设产品ckecklist！checklist就是将本项目所有的测试点编辑成条、成册，一方面是给自己做分析设计时提供参考，打开思路，另一方面是给项目的新人提供快速上手的依据。
做完分析设计之后，一定进行评审。条件允许先在组内进行集中评审，给同事展示自己的测试策略，邀请同事提供评审意见。每个人做分析设计的思路不一样，角度不一样，往往能发现很多意想不到的测试点，集思广益很重要。再者一定要拉上业务、开发进行测试要点评审，在评审会上将测试要点讲清楚，即使是简单的点也要复述清楚，不确定的点需要让业务和开发知悉并进行确认。
经过前面几步，基本可以确保一份测试设计或者叫测试策略能覆盖绝大部分的场景。
最后一步是进行集体缺陷分享和测试经验学习。前面做的几步都是基于单个项目层面的，客观上依旧是信息孤岛。通过缺陷分享和测试经验学习，交换测试心得，可以将组内各自负责的产品出现过的问题、好的测试经验传递给其他项目组。通过这种方式又可以丰富产品自身的checklist。
归纳几个关键字：提前学习技术栈、组内评审设计、三方评审设计、沉淀资产库、积累chcklist、缺陷分享和测试经验学习
这是一个闭环，需要时间积累。只要每一步都执行到位，一定可以做到测试策略合理、全面、覆盖率高。
标签：策略,接口,评审,学习,从何而来,测试,合理,入库 来源： https://www.cnblogs.com/xiaoxiami1995/p/15775588.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。