目录
一、 规范需求分析阶段
对于需求设计者，如何进行需求分析；对于质量保证来讲，测试活动应该从需求分析阶段开始介入，参加需求评审会。如何规范评审活动，就要建立评审流程。
（1）准入条件
需求说明书，评审核对单，涉及评审的软件流程和准则。
（2）角色和职责
（3）评审步骤
步骤一：制定评审计划。项目负责人在项目策划阶段制定评审计划
步骤二：评审准备
① 根据项目计划，项目负责人确定评审员必须参加审查，并指定审查会议的记录员，然后通知相关的利益相关者。
② 项目负责人指派评审员，审查所需的输入条件要确定下来，标准必须提前准备而且要经过确认。
③ 评审会议召开前夕，每个评审员可以通过邮件的方式收到评审通告、需要审核的资料，还有其有关资料，这样才能保证评审会议能召开。
④ 根据评审检查单的检查项，各评审员预审评审资料。这期间察觉的缺陷填在评审检查单相应的检查项后的注释栏里。
步骤三:评审会议
① 业务人员或者需求分析师负责介绍项目产品，负责解释任何一个评审参与者提出的问题。
② 对评审中提出的每一个问题必须要有明确的结论。
③ 确定问题的修改者和确认者。修改者需要给出调查问题的时间。
④ 评审参与者讨论发现的问题，直到得到一致确认意见；记录员负责记录审核结果（包含发现的问题，采取的措施和提议），进行记录
⑤ 根据评价标准对工作产品的评价进行了总结。在严重缺陷的情况下，审查没有通过;在无严重缺陷的情况下，普通等级的缺陷个数超过4个，评审不通过；在无严重缺陷并且普通等级的缺陷个数小于4个的情况下，评审通过。
⑥ 评审会接近尾声时，由记录员重新阐述会议上发现的问题，然后由
评审员对问题进行分类。
⑦ 如果评审会议的审核结论是不通过，那么就要重新评预约第二次评审会议时间进行再审。
⑧ 项目负责人指派有关与会者搜集一切相关的评审资料。
步骤四：对评审结果采取行动
① 记录员将会上提出的缺陷和探讨出的论断记录详实，整合会议记录，评审原稿完成。
② 项目负责人指派需求设计师剖析评审会议最终稿，制定缺陷解决计划，放工工作产品。
③ 项目负责人指派记录员把《评审报告》中遗漏的内容补充到《会议纪要》中去。
④ 项目负责人指派记录员把《评审报告》中遗漏的内容补充到《会议纪要》中去。
步骤五：追踪评审结果直至完成
步骤六：提交和归档
项目负责人指派工作人员将审查记录提交给配置管理员。
（4）输出物
输出物包括已通过审核的需求说明书、评审检查单、缺陷管理单、评审总结。
二、规范单元测试阶段
单元测试可以由具有编程功底的测试人员进行测试，也可以由开发人员进行自测。基于现测试团队中缺少这样高技能的测试人员，暂时由开发人员代替进行单元测试。
一）、单元测试流程：
- 要做测试分析，提出相应的测试要点；
- 第二，根据测试要点编写测试案例，选择适当的输入，得到预期的输出结果；
- 开发符合功能模块的测试编码，并在块程序右侧添加注释标明；
- 执行测试代码，检查实际结果与预期结果不一样；
- 执行测试案例，标出测试结果，若发现问题，记录在缺陷工具里；
- 依据缺陷查找代码出错的根源，修复代码缺陷，重新复测直至测试通过。
- 编写单元测试报告，评审通过后进行存档。
二）、实施单元测试需要注意以下几点：
（1）测试代码可以作为程序模块中的一部分，通过调测接口开关，有利于在模块中安装和拆除测试代码。
（2）单元测试应该对程序语句测试达到百分之百的执行率。
（3）对于删除、整合或者调优的代码都必须被评审和验证。
（4）代码版本升级时必须要做经过严格的单元测试，确保代码不会因为新增或迁移模块导致其他模块实现有误。
（5）对于程序各个预期会报错的场景，要努力在单元测试中复现。
（6）单元测试也可以使用系统测试的测试方法去验证代码，比如路径分析法、程序插装法等。
经过半年时间严格按照规范执行需求分析和单元测试后，交付到测试环境上的产品经系统测试后发现，如表 5-2 所示，需求问题和代码问题与流程改善前的数据相比，大幅度减少了，缺陷总数也随之减少了。产品质量稳步提高。
三、测试人员关注5 Why的使用
（一）辨别问题
发生了什么？例如，在生产问题逃逸数的 C 图中发现一个异常控制点。
（二）澄清问题
问题是什么？从抽象的数据表中剥离出异常点对应的相关数据，然后将数据反推定位到具体问题描述。比如，该问题描述是：“在版本 FP2.0 中，用户在发布环境上发现了已注册用户在输入正确的用户名和密码的情况下，依旧无法登陆 APP。”
（三）分解问题
将问题分解成几个小单元。问题一：“所有已注册用户不能登陆吗？”回答一：“不是，只有用微信注册的用户无法登陆。”问题二：“未注册的用户能保证一定不能登陆吗？”回答二：“是的。”通过问题分解，可以缩小问题范围，确定生产问题是：只通过微信注册且没有通过 APP 注册的用户无法登陆。
（四）用 5 个“为什么”来追根求源
“为什么这个问题会发生?”
“因为测试时没有考虑到只用微信注册的用户登陆的情况。”
“为什么没有考虑到这种情况？”
“因为测试用例没有覆盖这种场景。”
“为什么没有覆盖到这种场景？”
“因为没有做好需求分析。”
“为什么没有做好需求分析？”
“因为测试时间紧，没有时间仔细做需求分析。”
“为什么觉得测试时间紧？”
“因为没有足够的测试人员支持测试任务。”