怎么样才算是比较优秀的测试分析？
1、覆盖度够全
PRD、UI搞、时序图、表结构变更设计、概要设计文档、接口文档等等的参考文档上的内容在测试分析中都有体现
2、结构清晰易懂
不了解此块业务的人看到测试分析，也能快速了解业务框架结构、细节逻辑、业务间关联关系
3、维护成本低
在需求不断变化，迭代速度越来越快的情况下，如何快速找到所有需求要更新的部分，以及合理把新增
部分加入到原有的测分中且不用对原有结构做大的调整
4、隐式需求挖掘较透彻
往往需求文档写的不够细致到位，或者是为了实现新的需求的部分细节功能会和与原有的某些功能相违背
甚至是不兼容、设计的不合理，可变性降低等等
5、非功能性方面的考虑
性能能否满足、容错处理、业务层面的安全性考虑、用户体验等
如何去一步步分解转化成测试分析呢？
1、展现层的需求先缕顺
先对照着需求文档、UI稿、系分文档等多看几遍，缕一缕和此功能点有关联的所有要素，
再依次考虑每个要素的实际可能性，再把每一种可能性关联到改功能上，看看是否有一定的关联关系，完整的
分析功能本身和功能周边影响点
2、根据功能链路，摸清整个链路中涉及的环节的设计实现
3、从其他测试的角度考虑，看看是否存在可补充的内容(错误猜测、安全、容错、性能、用户体验交互等等)
4、结合1、2、3两步骤梳理的内容，考虑如何在测试分析上组装展示
好的分析设计的结构并不是简单把你分析出来的所有内容堆上去即可，是需要斟酌下
1、有层次结构， 层级合理
2、如何把公共的东西抽取出来，做好封装
3、如何把抽取出来的东西，更方便的被需要的地方调用
4、不适合用文字表达的部分， 考虑怎么用更合适的表现形式展现
5、如何突出重点
6、测试分析里需要整理的是测试点，归纳同类测试点给出测试预期结果，而不要步骤和分析点混淆一起
5、考虑第一层、第二层的框架怎么搭建
1、高度概括功能
2、同一层级的类目是否是真的同一层级
3、未雨绸缪下，可能的各类更新或者删除是否容易快速且完整的找到
综上，还有几点原则
1、涉及系统的多个页面或者是多个系统之间的功能，需要先上浮业务流程梳理，且业务流程的梳理过程，同步去了解链路里的每个环节的从展现层到数据库的存取
2、单功能点中，UI验证、交互验证、操作处理规则类验证(服务端处理、数据库、接口关键处理直接渗透进去写)
3、单拎出一块总体说明下该功能的核心处理(redis、mysql、http接口)
4、主体功能在别处已经整体有一块测试分析，在你的分析里只是要涉及此部分功能且略有差异改动，则可以在测试分析里关联下主体用例，差异改动部分重点说明(一般情况下，此类功能基线之后，要更新到主体功能那部分的基线中，而在你的测试分析基本无需改动)
比如说写交易的人会涉及保养、轮胎、纯服务、车品、以及公共部分等等各类交易下单的情况，但是车品模块的测试分析里也会有车品自己下单的分析，当写此部分时大部分测试分析都可以关联交易测试分析中的公共用例，再加上车品自己的需要关注的交易部分的内容
5、存在我们的前端应用调用对接的是其他业务prod，或者的是我们的prod，但是实际上业务处理较少，核心是调其他业务系统，这种情况下，要更加谨慎些，分清自己测试的界限，界限点上如何做充分的对接保障
本文链接：https://my.lmcjl.com/post/3649.html
4 评论