一、需求评审
1.需求评审的目的
明确功能优先级，评审业务流程设计的合理性，评估技术可行性。
2.需求评审中注意事项
a)提前了解产品需求，明确核心流程、功能结构
b)评审过程中不避免乏味，时间越长越容易分心，所以先了解重点模块，循序渐进
c)评审中遇到争议点，避免发散讨论，引导大家快速决策，明确沟通，明确产品拍板
d)评审中遇到无法决策的点，记录下来，会后处理，不过多纠缠，后续让产品决策后更新需求文档。
3.需求评审中常见问题
a)需求不明确。（包含需求写的不详细，涉及到的功能描述不清楚，该需求涉及到的功能没有考虑全面）
一般情况下产品的需求设计都会存在考虑不全，QA可能最全面最了解整提需求的人，遇到不明确的问题可以当场指出，请产品决策，不能当场决策的可会后记录拍板后更新文档。
b)需求有异议。（包含认为需求本身的不合理性、测试方案的不可行性）
需求评审中可以对需求本身提处异议，可以发表自己的见解，是否采纳产品决定。例如：
需求评审中需求设计到的测试，经评估觉得按照测试方案来算不可行，可以提出异议。多方商议折中处理。
c)需求文档缺失。（包含但不限于需求涉及到的地方比较多，文档中没有描述清晰）
描述不清晰的地方或者一笔带过的地方也要让产品补全，为了后续的case编写和测试减轻沟通成本。
d)数据埋点需求存在问题。
需求评审也包含数据埋点的评审，埋点评审主要关注埋点的数量，参数的合理性，方便后续测试 ，有疑问的埋点可以当场指出，并得出结论。待确定的问题要记录并提醒产品更新。
二、case编写1.什么是测试用例
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。
2.为什么要写测试用例
（1）、 理清思路，避免遗漏
理清思路是我们认为最重要的一点，有的系统本来就是一个大而复杂的项目，我们需要把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。
（2）、 跟踪测试进度进展
通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度，方便跟踪我们的测试进度。
（3）、 回归测试
首先我们的系统不是测一遍就完了的，我们需要在集成环境测试，线上还要进行回归，其次还要全部业务线合并集成测试，而且也有可能会有不同的人在不同的阶段、不同的集成环境进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。
（4）、 历史参考
在我们所做项目的各个版本中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。
另外如果产品发布后出现了发布缺陷（就是我们现在的线上问题），测试用例也是分析发布后缺陷的依据之一。
3.如何编写测试用例
（1）、测试需求分析，得到测试点
在测试需求分析阶段，我们只有需求文档，所以编写测试用例的唯一依据就是需求文档，因此在进行用例编写之前一定要进行需求分析，需求分析的主要工作就是：了解需求的整个实现背景；分析需求的合理性；明确需求的范围，挖掘需求文档中隐藏的需求；在通过需求交底的过程，确定开发的初步实现思路和方法，随着测试需求分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等；确定一些测试可以提前介入的工作等；需要说明的是对于需求中的问题一定要记录下来，找需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。
（2）、分析得到用例优先级
得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优等级，一般分为高中低三个优先级，我认为得到优先级后可以让需求用例的设计更有侧重和着重点。
（3）、细化测试点变成可执行case
根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况，还要注意各个测试点的反向测试的情况。
在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。
另外需要考虑的就是测试点细化到什么程度的问题，也就是一个度的问题，我们要把握好测试点细化的一个度的问题，太粗的测试点没有指导意义，太细的测试点容易让我们纠的太细，忽略整体的测试，反而也起不到一个指导的效果，所以一定要把握好测试点细化的度。
（4）、及时更新测试用例
需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的， 所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。
另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，测试case描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改我们的用例。
（5）、及时维护核心测试用例（也可以叫做通用的测试用例）
什么是核心测试用例呢？我理解的核心测试用例就是：项目中或者跨项目中很多的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测试用例。当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等，这个时候通过梳理业务的通用属性，通用用例梳理梳理成章。所以说，核心的测试用例是一个对用例不断维护的产出，因此我们在测试软件维护的过程中一定要及时的更新核心测试用例，对后面的测试和用例维护有一个很大的指导作用。
4.如何提升用例的编写能力
（1）、 熟悉业务，了解系统
任何系统都有大的业务背景，只要熟悉了业务知识才能更有效的使用系统。
任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问题和业务问题。
（2）、 用客观的思考方式站在用户的角度分析
作为测试人员如果想提升测试用例的编写能力，首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么，客户不想要什么，也就是所谓的客户的使用场景，这样有利于我们更好的挖掘和思考隐含的需求。至于这个需求该不该做，那是需求人员的职责，这个需求做起来复不复杂那是开发人员的事情，作为测试人员需要考虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景，以及一些客户基本不会用到的场景有哪些。
（3）、 多思考，不要拘束于惯性思维
我们知道一个人做一个工作时间越久，也就是我们说的经验越丰富，可能这个思维方式就会越被限定住。比如，测试的统计表多了，当拿到一个新增的统计表的时候，首先想到的是公用用例上所列的测试点基本上就是最全的了，我都不用思考，直接用就行了。
其实这是一个误区，公用用例的目的是帮助我们减少一些不必要的内耗，但是我们的思维不要被它所限定，如果公用用例中某个点是错的，那我们岂不要一错再错了。所以作为一个测试人员如果想要提升自己的测试用例设计能力，一定要多思考，不要被这种惯性思维束缚，不要被所谓的经验束缚。
（4）、 不要闭门造车，利用好网络资源
提升测试用例设计能力，多思考是非常重要的，但是不是让你傻思考，当你的进步遇到瓶颈的时候，不要闭门造车，做井底之蛙，要充分利用网络上的学习资源，学习一些前辈的经验，并把这些运用到实际的测试用例设计中去。山外青山楼外楼，多浏览和关注一些关于测试用例设计的网站或者微信公众号，广开言路，相信会对你的测试用例设计能力的提升会有很大的帮助的。
（5）、 善于总结分享
基于以上四点我们还要做到善于总结，乐于分享，把经常见到的用例设计的误区和一些好的用例设计，和用例设计习惯分享给周围的小伙伴，这样可以集众人之所长，不断提升我们的用例设计能力。
5.编写用例中常遇到的问题
（1）、case编写时无从下手
总结了一下本人编写case的方法，仅供参考
按照模块划分，梳理思维导图
按照页面划分，梳理思维导图
按照测试重点划分，梳理思维导图
（2）、相同页面或相同场景一样的需求，但是涉及到的页面过多，重复case太多
一般情况下可以把相同的case整理成一条，后面详细标注一下每一个入口或者每一个页面或每一个操作。简单举个例子~
（3）、异常场景考虑不全面
总计一下我们现在测试中异常场景可以分为以下几类：
网络异常：弱网、断网、网络切换等
服务端返回异常：必要的字段未返回或返回为空（可用Charles模拟），格式返回不正确等
电话、短信、等第三方打断操作
页面多次切换、同一接口多次请求、前后台切换等
备注：case是给所有人看的，所以case编写的时候一定要清晰明了，重点描述清晰。
三、问题跟进
1、如何跟进问题
（1）、明确问题优先级，优先解决P0级别的问题。
测试中常遇到的影响主流程的问题、崩溃、该功能开发未完成等情况，先找开发沟通解决问题，后续补提jira。不要只提jira不找开发跟进，会影响测试进度。不影响主流程和新功能测试的bug可以先提jira，后沟通或先不沟通，等一轮测试完成后在持续跟进bug。
（2）、持续更新问题事宜明细与跟踪
p0级别的bug要持续催促开发优先解决问题，非P0级别的bug 一轮测试完成后也要持续跟进未解决的问题，二轮测试阶段要每天bug清0，每天下班前验证待测试的bug。
（3）、遇到需求变更怎么办
a:要求产品、开发、测试三方一起评估是否可做。不可做的要给出明确的不可做理由，例如：测试人员紧缺、测试时间不够，需求不合理等。
b:开发同意后评估测试成本和时间，
c:明确提测时间和测试影响范围
d:明确指出新增需求如果测试中出现问题（例如提测delay，影响范围过大，测试成本太高等问题）如何解决
e:明确是否可以代码回滚
（4）、有冲突的问题及时寻求外部支持
如何获取外部支持
*合理选用书面沟通和口头沟通，准备好清晰的沟通材料
*明确并熟知各部门职责的三级负责人（每个模块的产品、客户端开发、API开发、后端开发）
*不明事宜或困难及时找三级负责人沟通
*沟通技巧：换位思考、同理心沟通
*三级负责人之间如果存在沟通后不能解决的问题，可以找二级负责人或一级负责人。
（5）、测试时间太紧张怎么办
a：明确需求优先级
b：合理安排测试时间
c：分批提测，提前介入测试
d：把控提测质量，要求开发必须执行准入case切通过后才可以提测。
e：及时跟进开发进度，避免提测delay
四、总结
测试闭环也就是是一个项目的测试周期，从前期的需求评审到后期的发版整个流程缺一不可。
