新梦想干货分享——测试如何把控项目01需求评审阶段首先要确定项目的大小，比较小的项目，就正常拉会评审；比如有那种一句话两句话的需求，可能大家
觉得没必要拉会，那作为QA可以在线下拉三方评审，这样做的好处是避免大家对需求的理解不一致，往往是这种需求越容易有坑，越容易理解
不一致。如果是大项目的话，大项目指的是前后端都涉及，且后端涉及到多个系统，这种项目通常会有立项准备，主要评估产品方案及技术可行性，
立项之后是需求评审，QA要对需求充分了解清楚，有疑问的地方尽量在会上解决清楚，把遗留的待确认点列出来，及时去跟进。在需求评审阶段
还有一个重要的工作就是确定排期。一般都会有需求管理平台，大家的排期都会更新在上面，可以了解到涉及到的各方，比如后端涉及到哪些系统，
前端是否有h5页面，是否涉及app的改动。需求阶段，无论需求大小，要搞清楚需求内容，有遗留问题要及时去跟进。02开发设计阶段
需要比较小，可拉会，可在线下沟通，沟通具体实现逻辑，搞清楚比如涉及到的接口、字段含义等。大项目大需求，作为QA要充分了解自己模块
的改动，尤其是细节；同时与其他模块的交互也要了解清楚，对其他系统要做到大致了解，了解到与谁交互的，这个模块是什么作用，能串起来就行
。如果你是?app测试，需要做到了解接口的传参和时机，每个字段的含义，以及app是如何控制显示的。如果你是后端测试，要了解接口的
传参和返参，各个字符的含义，以及与其他系统之间的调用关系，例如如何传参的，传参的含义。同时也要了解读写表的操作，逻辑的判断条件，哪
个字段或者哪个库哪个表的状态等。开发设计阶段主要搞清楚实现逻辑，测试过程中遇到问题可以定位到具体模块，找对应负责人去跟进。03用例
设计和评审阶段要区分需求的大小，对于小的需求，也是要有测试用例的，哪怕一两条，也要拉着PM和RD对一下用例，目的是统一大家对
于需求的理解，同时也要多关注异常情况。对于大一点的需求，要开需求评审会，由测试来主导，目的是达成大家对于每一条case的理解是一
致的，同时有助于发现潜在的问题，比如测试没有考虑到的地方，PM或者RD可以补充一下。需求评审完成后，需求根据项目的实际情况，
确认一下是否要进行联调用例评审。用例评审阶段主要是PM、开发和QA三方对每条case理解达成一致，以及对边缘case的
补充。04测试阶段测试阶段主要分为三个阶段，测试前，测试中和测试后。1.测试前（1）测试前要先确定测试方案，比如有些场景的如何模拟
，有些条件如何触发，可以跟开发沟通下；（2）数据准备，提前准备账号或数据等。以及是否需要开发一个测试小工具辅助测试等。（3）再有可
以评估下有哪些部分可以提前介入测试，能提前的尽量提前，为后面的测试顺利打下基础。（4）测试边界划分，可以先拉个QA群，确定测试
边界，确定QAOwner，这样做的目的是为了发现可能大家对某些需求的理解不一致，同时有助于充分沟通，有问题了可以及时理解和跟进
。还有一个好处是有些边界评估哪一方去测试更方便，有助于测试的效率。2.测试中在测试进行中时，要做到及时响应和反馈，比如在群内反馈和
日报。日报的内容主要包括已经测了什么，还没测什么，遇到什么问题，需要谁配合解决，同时在群里@配合解决的同事。在解决遇到的问题的时候
，比较顺利的情况是测试点都想到了，但有的时候会遇到一些意想不到的问题，比如设计漏洞或者产品设计缺陷，要做到及时在群里沟通或者当面沟
通，确定一个合理的解决方案。同时QA要评估解决方案的影响范围，如果测试即将完毕，影响范围比较大的话，要考虑是不是有更好的解决方
案，从而把损失降到最低。3.测试后在测试后期要做的是如果没有重要的问题可以提前通知PM和UI验收，避免整体产品效果与PM要
求不一致，也可以避免UI调整影响功能逻辑。这里可以验收两轮，没有p0Bug验收一轮，最后测试完成后，上线前再验收一轮细节。
05项目总结阶段分两个维度去总结：测试维度和项目维度测试维度要将测试情况，包括提测质量、提测打回、测试覆盖率、Bug分布及趋势的分
析，比如严重Bug、UIBug等。同时要回顾一下排期是否有问题，测试方案是否考虑不周全，有哪些测试工作是可以前置的。除了测试
情况要总结外，项目情况也要总结。用从后往前推的方式，去看一下软件测试过程中遇到的情况，应该在哪个阶段发现的一些问题，问问为什么没有
发现，以后应该如何避免。还有就是一些在测试过程中没有发现的问题，在测前没有想到，在实际环境中却发现了，这样的问题应该思考下如何能提
前发现，做下Review。从后往前去回顾这个项目的每个阶段，不好的点列出来，寻找解决方案，如何下次避免，用到下次测试项目中，积累软件测试经验。每个阶段把控好后，整个项目下来才能把控好。 |
|
