1、完整版研发体系问题单处理流程研发体系问题单处理流程 研发体系问题单处理流程 1 研发体系问题单处理流程 2 研发体系问题单处理流程 ：当前责任人要做的事情A ：问题单的状态S TRAC上对问题单的操作线上的文字，中文：判断结果；英文：在 1. 问题定位确认测试人员发现问题后，如果是必现、确定的问题，直接提单；如果是无规律重现问题，或者不 确定是否是问题，可以找相关开发人员进行测试现场定位分析，排除误操作等原因，确定问题现象及初步分析结论，由测试人员提单给定位责任人进一步跟踪； 2. 问题单提交 问题单严重程度有四个等级：致命、严重、一般、提示； 问题严重程度级别判定原那么：问题级别判定应该就重
2、不就轻，当问题现象可能符合多个问题级别定义的描述时，应该选择级别最严重的作为最终的问题级别。 致命 3 研发体系问题单处理流程 定义：产品的关键功能和性能不能符合用户要求，或由于产品质量原因造成业务中断、频繁瞬断或效劳质量严重下降等可能给用户收益或声誉造成较大损失的问题。举例：（包括但不限于以下情况） （1）整机或关键部件异常重新启动或瘫机； （2）由于产品质量原因造成的根本业务失效、局部失效及不能稳定提供； （3）可能影响用户收益或声誉的； （4）重要操作维护功能完全失效，例如用户无法对系统进行操作维护或操作维护经常被打断，无法对系统进行维护，告警功能完全丧失等； （5）系统性能基于上一个版
3、本下降10%以上并可能影响用户收益或声誉的； （6）按照版本升级指导书操作导致系统升级失败； （7）其他可能造成业务中断、频繁瞬断或效劳质量严重下降等可能给用户收益或声誉造成较大损失的问题，例如资源大量吊死、大量消息丧失、时钟丧失无法恢复等。（8）产品不符合行业标准或目标客户群所在地区的相关标准，如果不解决将导致无法在该地区销售； （9）不符合平安标准，在遵守平安规程进行操作维护的情况下可能造成重大人身伤亡的问题； 严重 定义：在产品规格书或行业标准规定的条件范围内，系统的主要功能和业务性能不符合用户要求，或不能稳定运行，但仍然可以向用户提供根本的业务。举例：（包括但不限于以下情况） （1）非
4、根本业务功能失效或局部失效； （2）根本业务功能在特定的不常见的条件下的失效，例如在某异常情况下的处理不符合协议； （3）非关键性部件故障，这些部件的故障不会影响用户使用根本业务； （4）系统数据丧失或出现不一致但不会给用户带来损失； （5）系统未到达要求或设计的性能指标、系统或模块性能下降但不影响根本业务； （6）用户资料存在严重的技术错误或缺少重要技术内容； （7）其他各种可能对客户造成影响但尚未影响根本业务的问题； （8）局部主要功能操作很不方便，多数用户会认为这些操作方式显著影响工作效率； 4 研发体系问题单处理流程 （9）不符合平安标准，在遵守平安规程进行操作维护的情况下可能造成轻微
5、人身伤害或设备损坏的问题； 一般 定义：局部次要功能失效或性能略有降低，但不会造成用户收益或荣誉受损失； 举例：（包括但不限于以下情况） （1）非根本业务功能的一个特例失效； （2）出现异常告警/断言等但没有影响系统的正常运转； （3）局部次要功能操作不方便； （4）在某些罕见或外界强烈干扰情况下（不包括外部灾难情况）会出现短暂的次要功能失效，且能够自动恢复； 提示 定义：系统功能可以正常运行，但存在不影响功能正常完成的操作、理解上不合理的的问题。举例：（包括但不限于以下情况） （1）用户界面文字排版风格问题； 问题单提交时注意填写如下说明： (1)问题-概要描述问题涉及的主要场景和产品特性；
6、 (2)问题说明：应包含： 产品信息，版本信息，特性版本信息，测试环境，操作步骤、期望输出，问题现象等内容；可以参考如下格式： 【】：简要概括描述问题的出现现象 【问题出现版本号】：xxx 【系统环境】： 【浏览器】：xxx 【出现概率】：测试10次，出现3次，必现问题不必写 【问题复现步骤】：XXXX 【测试结果】：XXXX 【期望结果】XXXX 【问题定位】xxx 5 研发体系问题单处理流程 xxx 【修改建议】 附上一切对问题定位有价值的内容，例如：前后台日志、截图等；(3) 问题单定位分析、修改验证、代码上库、归档3. 上。.doc作为附件上传到bug1）填写问题单xxxx定位分析及修
7、改说明报告 ）如果有周边影响，需要通知相关人员。2 上。）提交问题修改代码比拟报告，压缩上传到bug3 日志填写应遵循格式：【问题单号】问题描述。SVN4) 代码上SVN库时，也可以直接转给对应5）如果不是自己的问题，可以返回给工程经理（不知道谁来定位时） 的开发人员（知道是谁的问题时）。4. 问题单解决、审核验证、修改报告、待回归测试 将解决后的问题转给工程经理，由工程经理审阅相应定位分析、 版本号等信息填写是否完全； 问题单回归、关闭5. 新版本软件包制作完毕，进行开发自测试时，要求问题单修改责任人使用该新软件包进行(1) 问题场景的自测试，验证在新版本中问题是否得到解决； 自验证完毕后，
8、知会工程经理将归档在案的问题单转交给测试负责人组织回归测试； (2) 测试负责人将问题单转给相应的测试人员进行回归测试； (3) (4)测试人员按照问题场景进行回归测试，确认问题已经得到解决后，关闭该问题； 6. 本卷须知 (1)不允许从开发人员定位直接关闭问题单; (2)修改人和审核人不能是同一个人; (3)修改人必须填写问题定位分析、问题修改验证等必要信息；无原因走单将由审核人直接驳回； (4)根据工程情况，测试负责人审核和工程经理审核两个环节可以裁剪掉； (5)工程经理的角色可以由资深开发人员担任； 7. 附录 6 研发体系问题单处理流程 问题单xxxx定位分析及修改说明报告.d 定位分析及修改说明报告 xxxx1. 问题单 7
