精选课件PR书写.ppt

5）ASSOCIATE SPECIFICATION： 对于有明确协议规定或者ergo定义的内容，我们可以在这个栏位加上文档名称， 以便下次测试或者他人测试这个PR时很容易找到相关的信息！ 6）TEST PLAN REFERENCE： 在提报PR时应将Testlink中的case ID填入test plan reference中！没有case覆盖的 PR，此栏位可以填写To be created，提交后立即添加新case! 7）TOOLS AND PLATFORMS USED: 可以不填。 8）USER IMPACT:用户影响 Serious” “Moderate” “Minor” 9）Reproducing rate:重现率 此栏位应该填写具体的为了复现问题而执行测试的次数，而不是单纯的百分比。 填写规则： 重现问题次数 / 测试次数 10）For FT PR, Please list reference mobile’s behavior： 可以不填。 11）Submitter ： 在“Description”的最后需要加上提交者的信息，包括：姓名、电话. * 12）Attachment：添加附件（截图、文档…） a.普通PR?不需要任何log; b.如果是屏幕显示或语言翻译以及ANR方面的问题，请提供截图 （截图不需要压缩，直接上传）; c.如果是Force Close，除了提供Force Close截图，还需要提供 ADB/MobileModem log/DB文件,如果开发特别需要Cather log,也请打包附 上.(除了截图，这些log请打包压缩再上传); d.如果是Reset问题，请提供ADB/MobileModem log/Memory Dump/ DB 文件.(打包压缩上传); e) 特殊文件才会产生问题附件中一定要加上该测试文件 ； f) 如果是描述无法说清的问题，可以用video录制当时的操作并添加到附件 中； * 注意事项 1）原则上,是有问题都尽量的提出来，但必须考虑到问题的可解决性,以及 考虑到resource 2）测试人员需要自己学会去判断问题 3）不要为了提交问题而提交问题,必须走对方向，充分利用好资源,提交有 效的PR * PR Title: 1.PR Title的描述一定要简明扼要,尽量做到让人第一眼看到PR title就大致知 道这个问题讲的是什么 2.步骤描述一定要清晰明确； 3.是REG问题的，一定要在Title加上[REG]； 4.上版本现象，Martel lite/Scribe5HD现象，都要写明具体版本；参照机现 象，写明参照机型号； 5.Regression一定要先确认清楚再选择，选择Yes的，一定要有最近哪个版 本是好的。 6.出现次数/总共次数，一定要有；且此处频率和上面选择的10,8,5,2频率需 保持一致。 … * PR 描述 步骤描述一定要清晰明确 1.在描述PR的时候，按照测试步骤,描述完后,要总结,这个问题到底是什么? 2.在描述PR的时候，不要出现不必要的信息,对人产生误导 3.写PR的时候,杜绝直接从Test case Copy测试步骤和期望结果. * PR跟踪处理流程 请先在04 TestDoc\04 Verify bug表格中进行验证，且记录验证结果. Hoperun的bug需要加Comment以及改状态，对于验证通过的PR需要自 己Close;TCL的Bug只需要在Bugzilla上加个Comment,不需要改变状态(对于 验证不通过的PR需要加备注refuse PR，这样能保证Fail的问题能第一时间 处理) ?如果为Refuse的，还需要再把这个Bug assign给对应的开发. 低概率PR验证的时候，如果第一次验证通过，请将状态改为 Monitor, 继 续再跟踪验证两个版本，加commnets, 连续三个版本验证OK, 再改成 Validated. * 注意事项： 扩展测试，需要写3点。 验证bug? Case ID 请参照最新Case ID填写方式,对于需要添加case的PR，请添加对应的case. 在Test Link New Add –From PR下面建好对应模块命名的文件夹,添加case关键字（对应模块名+From PR） 单双卡项目需要验证单双卡版本上面是否都OK * PR 及时处理 检查bugzilla搜索项，是否包含下面几项，没有请添加: 1)自己提交的，状态为Delivered 的PR? = 每天去搜索并检查是否需要处理 2)Assign到自己名下的PR = 每天去搜索并检查是否需要处理 3)自己提交的，非Close的 P0 P1 的PR = 每周一次去搜索并检查是否需 要处理