需求测试规范
<h1>1 工作职责</h1>
<p>需求讨论和评审： 在需求产生后参与需求的讨论，确认需求与历史策略没有冲突，没有二义性，具有可测性（也就是说能够测试或者易于测试）。
测试设计： 根据原型图制定各个需求模块的测试用例，要求测试用例使用相对真实数据，测试用例的内容精确到每个输入项。
测试执行： 以测试用例为依据，借助准备好的数据、工具开展的用例执行工作。
BUG跟踪： 及时更新每月测试看板，关注已提出BUG的解决情况。</p>
<h1>2 工作过程规范</h1>
<h2>2.1 测试工作规范</h2>
<p>测试工作中统一使用看板工具对BUG进行追踪，以自然月为统计单位。
每个月的BUG看板包含以下几个固定泳道：</p>
<table>
<thead>
<tr>
<th>序号</th>
<th>看板名称</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>打开</td>
</tr>
<tr>
<td>2</td>
<td>重新打开</td>
</tr>
<tr>
<td>3</td>
<td>已修复</td>
</tr>
<tr>
<td>4</td>
<td>已关闭</td>
</tr>
<tr>
<td>5</td>
<td>延期处理</td>
</tr>
<tr>
<td>6</td>
<td>暂不处理</td>
</tr>
<tr>
<td>7</td>
<td>无需处理</td>
</tr>
</tbody>
</table>
<h3>2.1.1 启动准则</h3>
<p>原型图、设计图开发完成并且需求评审通过以后</p>
<h3>2.1.2 输入</h3>
<p>设计文档（需求原型图、需求设计图）</p>
<h3>2.1.3 主要步骤</h3>
<h4>2.1.3.1 设计系统测试用例</h4>
<h5>2.1.3.1.1 前期文档评审</h5>
<p>需求评审是测试工作流程的一部分，是在测试用例设计之前的一个过程。 测试人员进行测试用例设计时，主要是依据设计文档。这就要求我们在测试前期介入文档的评审，以测试的角度对文档进行评估和检查。主要关注以下几方面：</p>
<p>正确性：要保证文档描述的内容是真实的、可实现的。具体说就是检查需求文档是否在业务上是合理的，与其他的功能是否矛盾。设计文档是否是可实现的，是否与其它模块和接口是匹配的；
可测试性：对一条需求，必须存在一个可以明确预知的结果，并且可以设计一个可重复的过程对此进行验证。对一段代码（要求测试的方法和接口），必须存在一个可实现的测试路径，能够覆盖设计中的路径和分支。</p>
<h5>2.1.3.1.2 迭代的用例设计过程</h5>
<p>设计测试用例时，最好不要一开始就第一个模块进行详细的用例编写。这样做的后果可能会使我们过早地陷入细节、迷失重点，使测试用例编写的进度和工作量脱离控制。 迭代的用例设计过程的方法：</p>
<p>确定测试用例设计的范围。确定用例要包含的测试类型（功能、性能、接口等）、明确用例覆盖的模块、采用的测试方法、使用的测试工具、用例大致的设计粒度。
根据上面的结果，进一步细分。设计功能测试的测试大纲，设计性能测试的方案，划分测试用例集。
测试用例设计是一个不断加深，不断调整的过程。定期的重新查看用例，不断提高用例的精度和覆盖度，调整用例的合理性。</p>
<h5>2.1.3.1.3 用例类型</h5>
<p>测试用例按照面向模块的需求差异、模块的数据流程、与其他模块的接口关系，可以大致的划分为以下几种类型：</p>
<p>功能测试：主要是根据详细设计文档的需求描述，设计相关的功能测试用例；
接口测试：根据测试模块与其他模块的接口关系，或者测试对象本身就是对外提供的API，设计相关的接口测试用例；
稳定性测试：主要是针对系统的稳定性，设计测试用例。</p>
<h5>2.1.3.1.4 用例粒度规则</h5>
<p>编写测试用例前，需要确定测试用例的粒度。既要保证功能的覆盖度，又要避免增加不必要的用例编写工作量。 测试用例设计中常常使用“原子化”的概念。在这里我们可以这样理解：</p>
<p>功能用例原子化：是指一个独立的、有实际意义的功能点。在实际测试中可以灵活使用；
接口用例原子化：一般是指一组能够独立存在的输入、输出；</p>
<h5>2.1.3.1.5 用例书写规范</h5>
<p>命名规范：需求名称-功能点名称-测试用例编号</p>
<p>用例编写规范：</p>
<p>前提条件：准备测试所需要的各种条件（创建所有必须的对象，分配必要的资源等等）；
操作步骤：执行用例的步骤；
预期结果：预期的输出结果；
实际结果：实际的输出结果；
是否一致：验证实际输出和期望输出是否一致；
释放资源：完成后清理各种资源。</p>
<h4>2.1.3.2 执行系统测试</h4>
<p>在测试正式开始前，项目经理向测试组提交可以测试的版本，由测试负责人安排搭建测试环境，如果项目计划变更，则测试计划进行相应变更。 运行自动化测试用例和手动执行手动用例</p>
<h4>2.1.3.3 BUG管理</h4>
<h5>2.1.3.3.1 整体流程图</h5>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=57bf3a04164c2173b58e833f959261c0&amp;file=file.png" alt="" /></p>
<h5>2.1.3.3.2 缺陷跟踪</h5>
<h6>2.1.3.3.2.1 提交</h6>
<h6>2.1.3.3.2.1.1 角色</h6>
<p>测试人员提交使用看板工具提交BUG；
开发人员可以解决BUG；</p>
<h6>2.1.3.3.2.1.2 步骤</h6>
<p>将BUG添加至为打开泳道；
设置 类型标签 ，在看板中将Bug的优先级分为4个等级，开发人员应该按照优先级别解决Bug：
致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃，悬挂，死机。（当天必须完成）
严重：系统停止运行；系统的重要部件无法运行；没有可行的解决方法；严重影响测试进度。
一般：系统无法满足主要的业务要求；没有显而易见的可行解决方法；性能、功能或可用性严重降低。
建议：系统可以满足业务要求，但可以进行改进。
测试人员评经验判断可以修改bug的人员，如果无法判断则提交给需求负责人，再由需求负责人转给其他开发人员；
填写缺陷的详细描述，一般包含以下几项：
前提条件
操作的步骤
期望的结果
实际得到的结果
可能的修改建议
在附件中添加必要的附件，比如屏幕截屏或错误日志。</p>
<h5>2.1.3.3.2.2 分配</h5>
<h6>2.1.3.3.2.2.1 角色</h6>
<p>测试人员、需求负责人</p>
<h6>2.1.3.3.2.2.2 步骤</h6>
<p>测试人员经过和产品经理、开发负责人沟通后将BUG移动至“延期处理”、“暂不处理”、“无需处理”
开发人员修复完成后，将BUG移动至“已修复”。</p>
<h6>2.1.3.3.2.3 解决</h6>
<h6>2.1.3.3.2.3.1 角色</h6>
<p>开发人员根据缺陷决定解决措施</p>
<h6>2.1.3.3.2.3.2 步骤</h6>
<p>如果确定是一个BUG，则需要修正，修正结束后移动至“已修复”；
如果无法再现BUG的情景（请开发人员确保该发现缺陷的版本为测试人员测试的版本而非当前的工作环境，请对应正确版本再现错误情况），测试人员将BUG移至“暂不处理”；
注： 如果开发人员认定缺陷不是自己的问题，则转给需求负责人，并与需求负责人沟通；</p>
<h6>2.1.3.3.2.4 验证</h6>
<h6>2.1.3.3.2.4.1 角色</h6>
<p>测试人员来验证请求完成的情况。</p>
<h6>2.1.3.3.2.4.2 步骤</h6>
<p>如果确认已修复并已验证，移动至“已关闭”
如果确认无法重现，移动至“暂不处理”
如果确认是保留原样，移动至“已关闭”
如果确认可以推迟修正，移动至“延期处理”
如果确认不需要解决，移动至“无需处理”
如果发现结果不正确，移动至“重新打开”</p>
<h5>2.1.3.3.3 缺陷跟踪监控</h5>
<h6>2.1.3.3.3.1 角色</h6>
<p>测试人员
需求负责人</p>
<h6>2.1.3.3.3.2 监控方式</h6>
<p>定期抽查看板流转的情况：
定期查看长时间处于“打开”或“重新打开”的BUG;
定期重新评估“延期处理”、“暂不处理”的BUG</p>
<h5>2.1.3.4 编写测试报告</h5>
<p>在开发过程中输出的测试报告为：单元测试报告（不是必须的）和系统测试报告。代码开发完毕后，由开发人员提交测试，系统测试结束后由测试人员提交系统测试报告。 在测试执行完成后，测试负责人将输出的测试报告提交给产品经理和需求负责人进行用例抽查，评测用例的覆盖率。用例覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。</p>
<h5>2.1.3.4 更新使用手册</h5>
<p>在一个需求整体测试完成后，测试人员需要及时更新对应的用户使用手册</p>
<h4>2.1.4 输出</h4>
<table>
<thead>
<tr>
<th>序号</th>
<th>输出物</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td><font color=red>测试用例</font></td>
</tr>
<tr>
<td>2</td>
<td><font color=red>测试报告</font></td>
</tr>
<tr>
<td>3</td>
<td><font color=red>更新</font>使用手册</td>
</tr>
</tbody>
</table>
<h1>3 测试用例模板</h1>
<h1>3.1 思维导图</h1>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=aafdd18d53a45066e45802d429744a0d&amp;file=file.png" alt="" />、</p>
<h1>3.2 表格</h1>
<table>
<thead>
<tr>
<th>用例编号</th>
<th>项目名称</th>
<th>功能模块</th>
<th>前提条件</th>
<th>场景描述</th>
<th>步骤描述</th>
<th>测试数据</th>
<th>预期结果</th>
<th>实际结果</th>
<th>是否一致</th>
<th>是否清理</th>
<th>设计人员</th>
<th>编写日期</th>
<th>备注</th>
</tr>
</thead>
<tbody>
<tr>
<td>0001</td>
<td>组织部</td>
<td>报表-党员双报道列表</td>
<td>无</td>
<td>登录系统后，点击报表模块，点击党员双报道列表</td>
<td>党员双报道列表界面是否展示姓名搜索框</td>
<td>姓名：孙宇强 工作单位：长春坐标软件有限公司 报道时间：2022-09-20 联系方式：13333333333 报道位置： 14585</td>
<td>展示姓名栏搜索框</td>
<td>展示姓名栏搜索框</td>
<td>是</td>
<td>是</td>
<td>高峰</td>
<td>2022/9/20</td>
<td>无</td>
</tr>
</tbody>
</table>