QC 使用规范

QC 使用规范
一目的
统一QC 使用规范，便于QC 中各项目的管理。
二编码原则
对系统的需求、测试计划进行统一编码。
规则：
◆ 编码最多不可超过6 级，下级继承上级编码并新增码位最为自己的编码
◆ 需求、测试计划编码要求保持一致。
三测试需求编制原则
根据系统的需求进行编写测试需求，测试需求的编写，需简单明了。
3.1 需求描述
需求描述总体遵循以下原则：
􀂾 需求名称要直观表达所测功能
􀂾 需求名称由编码和文字描述共同组成
􀂾 需求描述中要注明该条需求所对应的产品需求
􀂾 最后一级需求要在需求描述中写明预期结果
3.2 需求树组织
测试树的组织要以易于理解测试内容为主。
􀂾 在需求编写的大体分级上，应该遵循的顺序：主菜单→次菜单→功能点。
􀂾 当需要对功能点的某一需求进行分级时，也遵循“功能点－需求点”的规范
􀂾 功能点的划分遵循：
􀂗 页面级：页面表格样式、表格字段、按钮文字样式显示位置
􀂗 通用功能：搜索、翻页、排序，此类可以建立唯一的基本测试流，对于涉及的
多个页面采用的方式是重复执行基本测试流
􀂗 独立功能：增删改查，基本测试流只存在一个且可在测试实施过程中被多次执
行
􀂗 关联业务：不同业务前提，对功能操作的影响
􀂾 当需求编写完毕后要导到测试计划中。
􀂾 需求树组织可以和功能需求目录不一致。
3.3 需求粒度
最后一级测试需求在实现转换后，会自动做为测试用例。
􀂾 多步操作--->多个输出：每个操作，输出做为最后需求，产生多个需求，从而得
到多个用例，记录输出结果。
􀂾 多步操作--->一个输出：一个需求
􀂾 单步操作--->一个输出：一个需求
􀂾 单步操作--->多个输出：一个需求
􀂾 多步操作--->多个检查验证：每个操作，输出做为最后需求，产生多个需求
􀂾 多步操作--->一个验查验证：一个需求
􀂾 单步操作--->一个检查验证：一个需求
􀂾 单步操作--->多个检查验证：一个需求
四测试计划编制原则
4.1 用例描述
测试步骤的描述要包含以下几部分内容：
􀂾 条件：当测试在某个特定条件下进行时，必须填写本项，没有时可以不填；
􀂾 操作部分组成：
􀂗 操作的起始页面
􀂗 输入数据
􀂗 具体操作
􀂾 预期结果
4.2 目录组织和步骤原则
用例树的组织、测试步骤的粒度遵循如下原则：
􀂾 目录和用例之间为1：多
􀂾 目录和用例出现1:1 时：用例直接向上级平移
􀂾 用例步骤：原则上不超过3 步，当多于三步时要进行用例拆分
4.3 分支测试流编写
分支测试流的测试内容大多在基本测试流中已经有描述，所以分支测试流只有用例
主体，没有具体内容，其用例描述可直接填写需要执行的基本测试流用例编号。
五测试实验室编制原则
5.1 编制原则
测试实验室中上级目录同测试需求和测试计划一一对应，测试集与测试计划中的文件夹
同级，总体遵循如下：
􀂾 组织分级遵循的顺序：项目名称→测试人员→功能点。
􀂾 测试集下测试用例条数遵循：5 到15 条测试用例。
􀂾 要执行多次测试用例时，在测试实验室中应该保存执行的结果。
􀂾 分支测试集实现：将分支测试用例中描写的基本测试用例直接添加到测试集中。
5.2 测试执行
暂未完成。
六缺陷管理原则
6.1 bug严重程度
——1、紧急(urgent)：
① 后台数据受损或丢失
② 导致被测软件响应明显很慢（假死）、死机、非法退出、崩溃；
——2、高(HIGH)：
① 用户需求未实现（影响到用户完成业务）；
② 用户需求实现错误（影响到用户完成业务）；
③ 用户使用频繁的功能，响应时间超出忍耐限度（不影响其他功能模块）；
——3、中等(medium)：
① 用户需求未实现（不影响用户完成业务、用户使用不频繁)；
注：用户执行删除操作时系统应弹出确认提示将固定视为用户需求，无删除确认提示
的缺陷归属本类
② 用户需求实现错误（不影响用户完成业务、用户使用不频繁)；
③ 用户操作过程中系统出现异常报错，但不影响系统功能的使用。
④ 用户使用不频繁的功能，响应时间超出忍耐限度；
注：忍耐限度根据实际软件系统的特点而定
⑤ UI 上存在错误引导用户的信息。
⑥ UI 上信息缺失、无法显示完整或出现乱码从而给用户造成疑惑的。
⑦ 用户频繁使用的功能易用性差（操作起来麻烦、复杂、效率低）
——4、低(low)：
① UI 控件不符合界面规范。
② 影响UI 友好性。
3 用户不频繁使用的功能易用性差
6.2 bug优先级
——1、紧急(urgent)：
1 预期功能或流程未实现
2 测试工作无法继续进行
——2、高(high)：
1 程序常见的错误，如边界值，极限值有错误；数据计算错误；功能实现有错误
等
——3、中(medium)：
1 不影响系统测试，但处理花费时间可能较长
2 系统遗留程序错误，需要修正
3 性能需要优化的问题
——4、低(low)：
1 建议性修正
2 不影响用户体验的缺陷
3 处理时间无法预估，解决问题花费时间超过5 工作日的缺陷
6.3 bug发生原因划分
——程序编码错误；
——数据有错需完善；
——错误引起新的错误；
——新人培训不足开发不熟悉；(该原因可以逐渐不被使用)
——需求不明；
——沟通不及时例如版本冲突；
——外部关联问题例如其他系统影响到的错误；
——非缺陷；
——建议性修正
——其他
缺陷发生原因按开发人员修正缺陷时所选原因进行分类，缺陷原因可以进一步调
整或细分，目前使用以上划分即可！
6.4 bug的合并与分拆
测试人员提交的bug 中，可能会有属于同一节点的不同bug，而且可能是一系列bug，
或者同一个功能模块中，bug 出现过多，导致分类不清晰，这时候，需要对bug 进行合并，
以便开发人员进行修改；当该BUG 中部分已经修改，部分没有修改或者是部分修改后复测
不通过，此时应将该BUG 进行分拆，以便统计。
6.5 bug提交
􀂾 测试在提交新bug 时，要首先对bug 进行查重，避免提交重复bug。
􀂾 缺陷摘要遵循规则：“模块-菜单-页签-问题概括”。
􀂾 缺陷描述遵循原则：
􀂗 定位：模块-菜单-页签-页面
􀂗 操作：操作过程
􀂗 预期结果：期望的结果
􀂗 实际结果：实际系统展示的结果
􀂗 其他说明：其他项目说明，比如测试人员对问题的分析，或者描述其他同类等。
􀂾 测试实验室生成缺陷修改原则：
手工删除下图部分显示的内容
􀂾 手工添加缺陷遵循原则：
缺陷和用例之间存在回溯过程，所以手工添加的bug，必须和某个用例进行关联。
6.6 bug注释
bug 的每一步状态修改都需要填写注释。已方便对争议问题进行分析处理。
开发人员对bug 的修改如果没有填写注释，可以打回要求开发人员补充注释。
七组权限管理原则
7.1 需求
◆测试负责人拥有所有权限
◆测试人员拥有添加需求、修改需求权限
7.2 测试计划
◆测试负责人拥有所有权限
◆测试人员拥有添加、修改测试，添加、修改步骤，添加、修改文件夹权限。
7.3 测试实验室
◆测试负责人拥有所有权限
◆测试人员拥有添加添加测试集、复制测试集、添加文件夹、运行测试、修改运行权限。
7.4 缺陷
◆缺陷状态：新建、打开、暂不处理、非bug、建议、已修改、已复测、重新打开、已
关闭。
◆测试人员可修改状态：已修改—>已关闭；已修改—>重新打开；非bug—>重新打开；
非bug—>已关闭；暂不处理—>已关闭；暂不处理—>重新打开。
◆测试负责人可修改任意状态。
◆开发人员可修改状态：打开—>已修改；打开—>非bug，打开—>暂不处理；重新打
开—>已修改；重新打开—>非bug，重新打开—>暂不处理；建议—>已修改；建议—>
暂不处理。
八数据备份
QC 系统管理员要定期备份QC 数据，在需求编写，用例编写，测试执行期保证至少每
周一次备份数据。