用例和bug描述规范参考

题 记 这篇文章比较适合菜鸟，测试管理者也可以参考制定测试规范。 从众测上拷贝的，不代表本人观点。

一一 BUG描述基础知识

1. Bug标题中需包含Bug的具体位置并以【】标注 举例：【模块-子模块-页面】XXXXXXXXXXXX
2. Bug标题中切勿出现错别字 错误示例： 奔溃（崩溃），电击（点击），登陆，（登录），重置（充值），现实（显示）
3. 当所发现Bug前提条件为空时，需要填无。特殊条件下的Bug必须详细描述产生Bug的前提。 示例：只有在使用附件中的图片（大图片：60M）时，会出现此Bug。
4. 描述复现步骤中的页面切换为避免出现描述不清晰或者有歧义，需用“->”符号连接 正确示例：（首页->我的->我的订单->未支付，点击一个未支付订单，进入订单详情页）
5. 在描述过程中 错误提示类Bug需用引号进行标注，不能出现描述不清的情况。
6. Bug的附件中包含的截图需增加相应的红框标识，便于Bug的定位。
7. 所提Bug附件的命名需要与Bug标题相呼应，不能出现名称怪异或冗长。 错误示例：QQ视频20168377894872.MP4
8. Bug中的视频附件需采用MP4格式，不能出现非Mp4格式视频
9. 在描述Bug过程中不能不精确词语，这会导致Bug描述不清晰，没办法复现Bug
   • 示例1：连续几次，多次点击，长时间上下滑动屏幕等模糊表述
   • 示例2：进入页面后等待一段时间。再点击XX按键。
   • 示例3：APP崩溃，手机崩溃，系统崩溃，APP重启，手机重启此类表述混乱。
10. 描述Bug过程中“预期结果”与“实际结果”必须有条理且符合逻辑。
11. Crash的Log取的时间尽量不能超过10分钟。
12. Bug截图、视频、Log以及描述需和Bug内容必须相符合。
13. 交付过程中需对提出Bug内容进行梳理和归类不能出现明显的重复Bug。

二一 用例设计基础知识

1. 用例执行前，需要制定严格的测试计划，而且测试计划中必须留出半天的内部审核时间。
2. 执行用例过程中需严格按照测试用例描述执行，规定的前提条件、输入数据、步骤，检查实际结果，必须保证测试结果的真实性。
3. 执行用例过程中发现问题时，记录完整的信息，如：测试手机型号、操作系统版本、测试网络、标准的佐证文件（视频、图片、Log文件）。
4. 执行用例出现非Pass的用例必须添加详细备注信息,Fail用例必须添加BugID；由于某个Bug或者缺少测试条件导致用例不能执行，标为Block添加备注信息；功能模块没有设计好，或者不适用于本轮测试的用例，标为N/A加备注信息。
5. 执行用例出现无法执行的测试用例,或者无测试数据时，必须及时与客户沟通，需要得到客户的确认后再处理，不能自主填写备注信息不执行。
6. 执行用例中原则上同一Bug只能Fail一条测试用例，在其他测试用例中，如果存在此Bug，但又不影响继续测试，不能跳过不执行。
7. 执行用例中测试进度必须严格按照测试计划执行，如果出现不可抗拒因素，无法按时完成任务， 必须提前与客户沟通，征得客户同意才能延期。
8. 设计用例中测试用例编写按照统一的模板进行，并约定模板的使用方法。
9. 设计用例中测试用例开始设计时，必须制定完整的设计计划，列出所需要覆盖的功能子模块，以及各子模块的大概用例数。
10. 设计用例中用例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点。
11. 设计用例中测试用例设计条理清晰，描述正确。 用例名称：描述清楚该用例所要达到的测试目的。 用例必须清晰地描述此用例所需的前提条件。 测试用例编写要步骤明确，输入输出要素清晰，并且清晰无疑义。 测试用例结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果且预期结果可以验证。
12. 设计用例中测试用例的粒度必须合理，均匀覆盖测试需求，基本度是：验证一个功能点（同一页面没有任何操作，整体页面检查算一个功能点）一条用例，没有重复、冗余的测试用例。