《CR提交和处理规范实用实用教案》由会员分享，可在线阅读，更多相关《CR提交和处理规范实用实用教案（25页珍藏版）》请在金锄头文库上搜索。
1、CR主流程框图(kungt)第1页/共24页第一页，共25页。CR的状态(zhungti)状态说明SubmittedSubmitted测试人员第一提交的CRAssignedAssignedPL接收后分配给各研发人员OpenedOpened研发人员接受此CR并且准备实施解决此问题Review_Requested已经解决了此问题，并提交给相应的人进行ReviewMerge_RequestedMerge_Requested审核通过则进行合并请求Merge_ApproveedMerge_Approveed经过审核，同意合并到相应的版本ResolvedResolved由测试人员回归CRClosedClo
2、sed所有研发人员和测试人员DuplicateDuplicate与其他CR重复（可能是现象重复，可能是原因重复）PostponedPostponed延迟解决延迟解决Need_InfoNeed_Info信息不全，不足以分析问题，需要提供更多的信息信息不全，不足以分析问题，需要提供更多的信息InvalidInvalid无效无效CRCRSuspendedSuspended由于功能、性能方面不能解决，或硬件问题，或无法再次重现等原由于功能、性能方面不能解决，或硬件问题，或无法再次重现等原因，以后不再做解决的缺陷，经过因，以后不再做解决的缺陷，经过CR REVIEWCR REVIEW，由，由tester
3、tester设置为此状设置为此状态。态。第2页/共24页第二页，共25页。如何(rh)提交一个CR点击(dinj)工具栏的Newchange，出现下表，完成后点”OK”第3页/共24页第三页，共25页。CR提交规则(guz)（针对ST)并非测试发生死机或assert才要提交CR外，不明确的问题需要和需求对照(duzho)以及与开发沟通，确认问题。但对于下面明确的问题请提交CR。1、手机发生ASSERT、死机、定屏、画屏提交CR2、测试中发现功能错误，不合理、失效、显示错误3、操作响应慢、连接多次失败、发送多次不成功请提交CR。4、杂音、破音、断续、音乐视频不流畅、格式不支持、安装失败等文件处理
4、请确认源文件是否异常，确认源文件正常，请提交CR5、逻辑关系不合理、优先级顺序不合理、和需求不一致，请提交CR第4页/共24页第四页，共25页。如何(rh)填写CRHeadline：产品项目标识、简单描述此CR。Catalog：判断是哪个类别的问题，选择相应(xingyng)的类别，软件-SWProduct：项目project类别：如：MOCOR、8800G、MOCORSMARTBaseOn(Ver)：测试的版本编号FixOn（Ver）：CR解决和merge的版本-由开发解决人员填写Severity：缺陷的严重级别ChangeType：根据选择的ChangeType不同，Description
5、中的提示也不一样，请按照要求填写(一般由测试人员提交的CR为defect）Probability：缺陷重现的概率Component：在哪块功能上出现问题Priority：缺陷的优先级Owner：填写此CR的处理人，一般可以填写PL或该模块开发人员。Description：根据给出的提示详细填写重现CR的步骤、表现的现象和相关的分析，可能的原因等等信息，帮助CR相关的人员了解所要反映的问题（尽可能具体，详细，信息准确）。第5页/共24页第五页，共25页。严重(ynzhng)级别severity1-Critical致命问题造成(zochn)整个系统崩溃或死机的问题；常用以及主要功能必现的死机或As
6、sert问题2-Major严重问题造成(zochn)主要功能失效的问题常用以及主要功能失败或错误问题系统性能问题3-Average一般问题造成(zochn)部分功能失效，但不影响主要功能的缺陷非主要及常用功能失败或错误问题4-Minor提示性问题影响系统外观，但不影响系统功能。如:写信息中的错别字，界面颜色等5-Improved改进建议不影响系统功能，满足需求，但可考虑改进以更好的满足用户需求。第6页/共24页第六页，共25页。优先级priority1-ResolveImmediately对于产品在市场上的成功至关重要。能够(nnggu)直接影响销售和公司的成功。迫切需要开发组织理解以及立即解
7、决。2-GiveHighAttention对于产品的成功至关重要。开发组织应该尽快理解和解决。3-NormalQueue对于产品的成功是重要的。该缺陷研究和修改的时间应该列在存在的项目日程中。4-LowPriority如果时间不允许，可以暂缓解决第7页/共24页第七页，共25页。缺陷(quxin)重现概率Probabilityoccurcount/testcount发生了几次/测试了几次1-AlwaysRecurrence每次同样操作(cozu)必发生同样的缺陷现象。2-OccasionallyRecurrence同样的操作(cozu)会发生多次同样的问题。3-SeldomRecurrence
8、缺陷重现的概率很低。注：对于非必现的问题，需要在Description中写明发生过几次这样的现象，自动测试发现的问题，概率写1/100第8页/共24页第八页，共25页。ODC缺陷(quxin)分析填写ODC-缺陷分析填写发现活动：有系统测试、外场测试之分如：ST则填写系统测试触发(chf)因素：单一功能、边界、非法、顺序、交互、负载/压力、配置根据操作发生问题的情况进行填写，如果是顺序操作产生的CR，则填写顺序缺陷年龄(ST测试人员提交时不用填写此项）：基础(BASE)、新的(New)、重写(Rewritten)、重写修复(ReFixed)第9页/共24页第九页，共25页。HeadLine的填
9、写(tinxi)(针对ST)Headline编写规范：-Headline的正确编写，有利于CR搜索。Headline必须包含如下信息：1）产品项目(xingm)标识：芯片小工程如：6800h6804h_240X4002）如果是中移测试：需要添加模块中移规范测试，如wap中移规范测试3）如果是自动测试：需要有自动测试字样4）请简要概述所在或涉及模块的操作和现象5）如果发生assert，请把Assert文件写在Headline中。如Exceptionat0x08c90994ASSERT,如果是手动assert不用说明assert文件。第10页/共24页第十页，共25页。Desciption的填写(
10、tinxi)硬件：填写手机硬件平台及编号如：6600L_P3_#53版本：填写Download的具体的版本信息，即PS文件夹对应的名称，如：sc6800h_sp6801h_builddir如果是来自研发人员的临时版本，请注明研发人员姓名。如：VersionfromShijun存储卡：存储卡的品牌、类型、容量大小SIM卡：sim卡卡号步骤：详细描述测试时的步骤现象：清晰描述测试的结果和问题,同时也要写清楚预期结果和实际结果1）出现ASSERT时，要拷贝(kobi).ass文件中的assert文件信息到描述中；memory信息不完整的一定要注明；2）由于特殊原因没有相关log信息，一定要具体描述之
11、前做过什么操作，说明没有相关信息的原因；3）自动测试提交的CR，需要注明相关信息，格式为：自动测试：自动测试文件，主要测试内容，问题。出问题的自动测试脚本提交在CR的attachments里，便于回归；log信息同样存放在服务器上4）预期结果：需要填写正确操作结果5）Logpath：请填写log压缩包的存放路径6）如果涉及到操作相关文件，需要提供文件的具体路径第11页/共24页第十一页，共25页。界面相关(xinggun)控件描述10A和09A 手机界面(jimin)按键命名规范第12页/共24页第十二页，共25页。界面(jimin)相关控件描述PDA和SMARTPHONE 手机界面(jimi
12、n)按键命名规范第13页/共24页第十三页，共25页。CR填写(tinxi)示例(ST)第14页/共24页第十四页，共25页。日常(rchng)CR处理我们每天需要处理哪些CR？InvalidNeed_InfoOwner为自己，状态为非resolve/close的另外还有待观察的CR需要定期(dngq)每个版本处理：owner为自己，状态为reslvoed，fixon版本在之前版本的（非leatest版本）第15页/共24页第十五页，共25页。Invalid(ST)Invalid:IndicatetheCRisnotvalid造成原因(yunyn)：（1）需求不明需求不明的地方多与开发和需求设
13、计人员交流，积累经验，有必要的话从需求分析人员处要详细的需求规格说明书（2）测试环境不满足部分模块测试时需搭建测试环境,如用于实现某功能的跳线没有跳;或者是没有安装PCCamera的驱动程序当前网络环境不支持（3）特殊异常对比其他商用机器的处理现象，如当前网络信号不稳定导致的通讯失败；特殊的文件或损坏的文件处理处理方法：确认该CR是不是由客观原因(yunyn)引起的，根据notes里的说明判断是否Re_Submit或Close.对于不认同的CR，需要与研发人员和需求设计人员进行沟通。第16页/共24页第十六页，共25页。Need_infoNeed_Info：Needmoreinformatio
14、nandstandardization造成原因：信息不全；缺少必要信息1.Log信息不全（1）抓了Log忘记在server上放Log信息 （2）非必现的问题没有抓arm-Log或dsp-log2.缺少片源信息有些模块测试时需要片源信息，CR描述时请注意：（1）指明片源位置外网testingforCR.（2）具体描述发生问题时的现象（3）对于提交给北京研发的CR，要把多媒体文件放在外网FTP上 3.开发添加trace（1）个别难重现CR，开发还尚未解决，只是添加了一些trace相关信息补充完整后，再次Re_submit给相关研发人员对于无法重现，且缺少log信息的CR，需要在CR描述中说明情况，
15、并在之后的版本继续(jx)进行关注5个版本，如果没有重现则将CR状态改为suspend，如果重现则resubmit.第17页/共24页第十七页，共25页。DuplicateDuplicate:DuplicatesanotherCR造成原因(yunyn)：（1）提交CR前未进行索引操作导致提交问题重复（2）本质上是同一问题引起的不同现象注意事项：（1）需多了解需求、经验共享、了解需求规格说明书（2）养成提CR前索引相关问题的习惯处理方法：对于Duplicate状态的CR不要急于验证关闭，请务必先查看Duplicateof的对应的CR状态，即源头CR的状态：（1）如果Duplicateof的CR的
16、state为close，需要验证该问题是否还存在，如果存在，则Re_submit；如果不存在，则close（2）如果Duplicateof的CR的state为Resolve，同样需要验证问题是否还存在，如果存在，则Re_submit；反之则close（3）如果Duplicateof的CR处于其他状态，则暂时不关闭，同时关注Duplicateof的CR状态的更改（4）如果Duplicateof的CR不是同一个平台，则不能关闭CR（5）以上CR如果是非必现的CR，则需要验证5个版本没有重现后才可close第18页/共24页第十八页，共25页。CR的回归(hugu)根据PL提供的ReleaseNot
17、es进行回归测试；ReleaseNotes中的CR处于Resolved/closed/merge-approval/部分duplicate（duplicate看源头CR处于resolved,closed,mergeapproval状态)状态是需要我们回归的。另外(lnwi)回归的时候还需特别关注下版本号，只有fixon在该版本(和该版本以前的版本）上的CR才需要回归。（1）对于发生概率为always的CR，回归通过后在Notes中标明如下信息：testerpassedon 版本号同时Action选择Validate（验证）Apply,CR状态自动变为Closed（2）如果回归失败的CR，在No
18、tes中写明testerfailedon版本号，并写明相关的操作步骤和现象，同时Action选择Reject（驳回）Apply，CR状态自动变为Opened(请注意一定要reject处理，不能re-submit处理）（3）对于非必现（seldom或occasionally）的CR1）解决CR的开发人员如果确实找到了问题的原因并且做了有把握的修改，在Analyzie中写出详细（包括问题的原因、解决的思路）或直接和项目测试PL沟通能达成一致，则采用一次方法（一个版本回归超过10次），没有重现则关闭。2）如果开发人员没有把握，只是尝试或开发人员与测试PL无法达成一致，则跟踪5个版本。3）如果在某一个
19、版本上重现了该问题，则在Notes中表明failedon版本号，同时Action选择Reject（驳回）Apply，CR状态自动变为Opened第19页/共24页第十九页，共25页。CR的回归(hugu)（4）对于无法回归的CR（如状态不正确，或研发人员提交的且无有效验证手段的），需要在CRnotes中标注与开发人员的沟通结果和NA原因，同时在回归测试报告的测试结论中填写NA,并注明(zhmn)NA的原因（5）如果问题已解决，但又发现了新问题，原CRValidate 关闭，另提CR（6）当回归CR的“resolution”属性页中有duplicates的CRlist时，也需要将duplicat
20、es的CRlist中每一个CR作回归。如果解决则关闭，如果没有解决则reject。（7）如果CRfixon的版本回归fail了,请reject处理.回归pass了,请close处理如果在fixon的版本上回归pass了,但是在projectareafixon的任何一个版本上回归fail,请重新split一个新CR出来.(原CRclose)这个CR在这个版本上(projectareafixon)也是回归失败的,测试人员notes里说明下,另外测试报告的结果也是fail的.(8)如果测试人员误rejectCR了，在确认问题确实解决后，可请开发人员在open状态走到re-submit状态，然后CR可
21、由测试人员直接关闭.测试人员关闭CR需慎重!第20页/共24页第二十页，共25页。回归(hugu)通过的CR示例第21页/共24页第二十一页，共25页。回归没有通过(tnggu)的CR示例第22页/共24页第二十二页，共25页。谢谢！第23页/共24页第二十三页，共25页。感谢您的欣赏(xnshng)！第24页/共24页第二十四页，共25页。内容(nirng)总结CR主流程框图。研发人员接受此CR并且准备实施解决此问题。3）如果是自动测试：需要有自动测试字样(zyng)。步骤：详细描述测试时的步骤。4）预期结果：需要填写正确操作结果。Owner为自己，状态为非resolve/close的。（1）抓了Log忘记在server上放Log信息。感谢您的欣赏第二十五页，共25页。
