质量保证分享

质量保证经验分享需求评审外部体验阶段内部测试阶段编码阶段发布阶段40~1000倍外部体验阶段30~70倍内部测试阶段20~40倍编码阶段10倍设计阶段需求阶段设计阶段3~6倍需求阶段1倍发布阶段任何一条需求需要清晰完整地描述，不能出现歧义，避免评审人员随意猜测。任何一条需求在文中的表述需要完全一致，不能出现前后矛盾或者不一致的地。需求是否可测，每条需求是否可以用测试用例进行覆盖，需求是否有内部和外部依赖。一些需求的行为成立有一定的前提条件，针对这些需求，是否有明确的先决条件进行说明。准确性一致性可测性约束性需求评审架构设计设计是否与需求一致模板说明内容是否完整，时序图监控说明：业务监控、服务监控（功能模块、监控指标、统计周期、报警条件）容灾和容错接口设计接口的定义是否清晰、明确接口的设计是否便于查错接口设计是否一致包含了数据采集和上报接口架构/接口设计评审测试排期尽量不要压缩因素内容项目复杂度团队因素历史版本质量发布标准测试用例编写功能测试性能测试接口测试兼容性测试安全测试遗留BUG回归测试测试方案发出之前要和项目组确认建议测试的相关标准定义也附上测试方案测试排期测试排期注意信息登记，便于后期统计“测试打回”数据邮件附上checklist，不建议写上不通过项，不便于追溯准入测试标准：P0级测试用例通过率100%010203准入测试注意事项准入测试执行测试的注意事项执行测试、提交缺陷、与项目成员沟通时尽量做到严谨，避免出现不必要的分歧£฿¢$€BUG的严重等级是否符合定义？不确认是不是BUG时，先和产品开发沟通

BUG描述的语言避免出现模糊和强硬的词语概率性BUG补充说明“无规律重现”、“无法重现”若BUG以“无法重现”的原因被打回，先检查一下步骤是否有遗漏或者不清晰，再去找开发人员沟通执行测试回归测试的注意事项执行测试、提交缺陷、与项目成员沟通时尽量做到严谨，避免出现不必要的分歧£$确定缺陷解决方法与根因，便于回归，建议开发人员提供两个信息：BUG根因关联点的测试建议不要轻易关闭非必现的BUG，关闭的时间和标准建议确定回归测试测试总结01缺陷分析，总结经验教训，为项目组提供改进建议，避免问题持续发生，造成不必要的人力和工期浪费02为项目考核提供绩效数据03组织级项目经验共享现状分析改进测试总结测试总结——现状用客观数据说话！测试总结——现状缺陷解决率打回次数缺陷密度reopen及时率提测延期指标测试总结——现状缺陷解决率打回次数缺陷密度reopen及时率提测延期时间版本人指标+维度指标体现指向角色缺陷密度综合体现“研发过程”质量全员、开发缺陷解决率开发人员的BUG修复能力开发提测延期排期的合理性开发编码能力\开发对工作单元分解和评估的能力PM、开发打回次数开发自测开发重新打开率开发自测、BUG修复能力开发BUG扭转及时率新-接受/处理BUG积压：开发人员的工作安排合理性

BUG确认：1.开发人员的能力，产品业务熟悉度

2.测试提交缺陷的清晰、准确度开发、测试接受-已解决开发人员对BUG的修复效率开发重新打开测试人员对缺陷验证的效率测试已关闭已拒绝标准不明确或不了解开发、测试挂起测试总结——现状测试总结——现状测试总结——现状

原计划提测时间实际提测时间延期天数测试完成时间压缩测试工期版本A8月1日8月3日2天8月5日1.5天版本B..........版本C..........版本D..........平均\\2天\2天测试总结——现状测试总结——现状测试总结——现状又称数据表，用于收集数据的查对清单收集潜在质量问题的有用数据特别方便在开展检查以识别缺陷的数据缺陷的数据和后果的数据，经常使用帕累托图显示飞机误点原因误点次数误点发生百分比天气9847%空管6833%机械2512%机场104%其他62%测试总结——分析工具（检查表）为了有重点的采取纠正措施测试总结——分析工具（帕累托图）①确定问题影响最大，最重要的问题每次确定的主问题只有一个②识别问题根因随机，头脑风暴逐一攻克，逐一分析直至分析出可以行动的根本原因③制定解决方案解决方案尽可能的解决多个分支问题不要期望一次根因分析就能识别出全部根因，全部推动解决测试总结——分析工具（鱼骨图/因果图）输入错误率增加能力不够身体不适情绪低落精神不集中设备因素个人因素显示器太差键盘失灵硬件故障软件不好使……期限太急逻辑混乱特殊字多字迹不清环境嘈杂