如何保证测试用例质量

将大目标分解为每个阶段的小目标，根据目标来开展相关工作：计划、方法、执行、总结，下面针对各个阶段保障案例质量提供方法，供大家参考，同时也希望在工作过程中积累经验并分享：概要测试需求阶段阶段要点：概要测试需求完整性保障措施：1、 测试设计人员编写概要测试需求，概要测试需求尽量细化，保证每个概要测试需求分解为3-5个需求点；2、 通过跟研发的沟通和评审来不断的细化和完善概要测试需求，并签字确认需求矩阵全部覆盖；3、 编写过程中项目经理对每天对每个模块进行检视，尽早发现需要返工的问题，测试经理进行抽查，问题都记录在VSS上归档，记录返工次数；4、 内部交叉评审时检查需求矩阵是否全部覆盖；尽量案例老员工、技术骨干人员进行评审，问题超过15%编写人员需要增加时间进行整改，再进行一次评审直到问题低于15%，且无基本需求遗漏，记录返工次数；5、 概要测试需求全部完成后正式进行开发测试的评审，并让开发确认并需求矩阵是否全部覆盖，问题超过15%编写人员需要增加1天进行全部用例自检然后修改，再进行一次评审直到问题低于15%，且无基本需求遗漏，记录返工次数；测试指导书阶段阶段要点：测试指导书通俗易懂、深入了解原理、能够高效的指导测试，能覆盖所有用户场景和网络拓扑；保障措施：1、 写模块测试指导书之前先与版本测试经理、开发人员、测试经理、技术骨干人员范围讨论模块测试指导书设计方法和思路；2、 测试设计人员通过学习其它产品线资料、开发设计文档、用户需求、网络资料进行编写；编写过程中每天与开发人员进行沟通；并检视需求缺阵中该模块是否全面覆盖；编写完成后与开发人员确认模块原理深度、是否正确理解、是否覆盖所有用户场景和网络拓扑；3、 编写过程中项目经理对每天对每个模块进行检视，尽早发现需要返工的问题，测试经理进行询问，问题都记录在VSS上归档，记录返工次数；4、 内部交叉评审时检查需求矩阵是否全部覆盖；尽量案例老员工、技术骨干人员进行评审，问题超过15%编写人员需要增加时间进行整改，再进行一次评审直到问题低于15%，且无基本需求遗漏，记录返工次数；5、 测试指导书演讲：对模块的理解达到了对应开发人员的水平（可以对应的开发人员的评价做参考），需求演讲90以上的问题都能正确回答；（具体考核参考测试人员工作标准）6、 根据评审意见优化模块测试指导书，并提供模块的测试策略给版本测试经理；详细测试需求阶段阶段要点：案例框架和设计思路的合理性、规范性、测试点的充分性和测试点规范性保障措施：1、 写模块框架之前先与版本测试经理、测试经理、技术骨干人员范围讨论出案例框架和设计思路；2、 测试设计人员通过产品线内部的案例库，保障常用的测试点能覆盖，根据讨论结果和完全对照功能和性能案例框架checklist建立基本框架；3、 案例设计思路和模块的说明写在基本功能案例的描述框内；4、 设计思路和模块说明完成后，召集项目经理和对应研发和研发的技术经理进行评审，评审通过后才能往后走，否则返回重来，记录返工次数；5、 根据概要测试需求进行详细测试需求编写，对照测试中心功能和性能checklist中共性需求点是否覆盖、产品线内部案例checklist；并完成自检，文档归档到VSS上；并参考本产品线和其他产品线发现的网上问题、相似模块的TD问题和案例、网上相关资料查找；6、 编写过程中项目经理对每天对每个模块进行检视，尽早发现需要返工的问题，测试经理进行抽查，问题都记录在VSS上归档，记录返工次数；7、 进行组内交叉评审，尽量案例老员工、技术骨干人员进行评审，问题超过15%编写人员需要增加时间进行整改，再进行一次评审直到问题低于15%，且无基本需求遗漏，记录返工次数；8、 版本测试经理和测试经理针对重要模式进行评审；9、 详细测试需求全部完成后正式进行开发测试的评审，并让开发确认并需求矩阵是否全部覆盖，问题超过15%编写人员需要增加1天进行全部用例自检然后修改，再进行一次评审直到问题低于15%，且无基本需求遗漏、覆盖所有需求矩阵，并记录返工次数；汇总开发评审测试用例汇总表并提交给TCM和SQA确认；测试用例编写阶段阶段要点：测试方法、案例步骤、检查点的规范性、充分性、容懂、后续执行效率；保障措施：1、 测试设计人员学习测试用例设计学习素材常见问题；2、 编写几个典型的用例，可参考其它产品线案例、网络相关资料，产品线内部进行评审：测试方法、案例规范、测试思路，检查点、用户场景、网络拓扑；3、 测试设计人员按照评审意见和用例整体规范checklist保障案例规范，并完成案例checklist自检、文档归档到VSS；4、 编写测试用例的过程中采取A/B视角的互评（主要检查用例本身的问题），并且将评审的问题发出来，让其他人避免犯类似的问题；5、 采用与开发的A/B角日结，开发每日进行案例检视，测试人员根据代码检视案例和需求点，归档到VSS；6、 编写过程中项目经理对每天对每个模块进行检视，尽早发现需要返工的问题，测试经理进行抽查，问题都记录在VSS上归档，记录返工次数。如果检查出来的问题比较多，则暂时停止编写用例再次安排专门学习（后面再加强检查）7、 每个模块编写过程中或完成时与对应开发人员确认，是否有些逻辑用例没有走到，并优化案例；另外也让开发通过查看用例想到自己哪些没有处理到的地方，提前预防；8、 安排很有经验的老员工每天抽查一个模块，重点检查考虑不到的地方，抽查出来的问题要求进行分析，为什么会有这些问题，以及后面怎么去避免类似的问题；9、 组内交叉评审，安排有经验，技术骨干人员进行交叉评审，重点放在需求点、异常测试、需求矩阵、案例checklist完整性，可以分任务进行评审；10、模块案例全部完成后正式进行开发测试的评审，问题超过15%编写人员需要增加时间进行整改，再进行一次评审直到问题低于15%，记录返工次数；集成测试阶段阶段要点：案例优化补充，执行人员进行案例勘误、为模块案例覆盖率负责。保障措施：1、 测试执行人员使用执行人员专用的简易checklist在执行过程中进行规范性和勘误检视。2、 测试执行人员将所有案例无覆盖的案例进行修改（2种情况，无案例修改权限的记录到表格中，每日发给案例负责人进行修改，并确认修改结果，有案例修改权限的直接修改，距离修改或新增的案例号）3、 开发人员执行的案例要关注执行结果，如是案例问题和需求点未考虑需及时修改；4、 采用A/B角日结，每日进行案例检视，检视对象为记录的被修改过的案例，归档到VSS；5、 有经验和技术骨干人员根据代码、沟通、发现的问题进行模块需求点提炼并补充案例；6、 提交开发评审和测试中心评审：版本可靠性测试指导书、测试案例、可靠性测试案例；汇总开发评审测试用例汇总表并提交给TCM和SQA确认；系统测试阶段阶段要点：案例持续优化，执行人员进行案例勘误、需求点提炼；保障措施：1、 测试执行人员使用执行人员专用的简易checklist在执行过程中进行规范性和勘误检视。2、 测试执行人员将所有案例无覆盖的案例进行修改（2种情况，无案例修改权限的记录到表格中，每日发给案例负责人进行修改，并确认修改结果，有案例修改权限的直接修改，距离修改或新增的案例号）3、 采用A/B角日结，每日进行案例检视，检视对象为记录的被修改过的案例，归档到VSS；4、 例行工作：每周检查bug关联案例情况、每周测试用例抽查、每周针对模块进行需求点评审；5、 随着模块的逐渐熟悉、发散测试、代码覆盖情况提炼需求点和案例优化，并关注模块案例覆盖率；6、 在测试的过程中发现bug时需要弄清bug产生的真正原因，是否该用例能够必现，或者通过其他的步骤可以必现，这个时候就需要分析和优化用例，针对改动很大的模块，要进行系统的分析和案例优化，版本测试经理要推动针对用例无覆盖的bug分析；7、 针对未改动和小改动模块：如发现基本功能存在非遗留问题，并分析bug产生的原因和改进措施，如发现的问题较多，需加强此模块测试，并检视其它模块是否存在此问题；8、 阶段性总结时如果发现案例质量存在比较大的问题，在版本间歇期进行案例的重新检视和评审，并回溯进行补救；9、 每轮总结时要求开发经理、产品线主管、规划经理、版本经理和测试项目组成员参与，会上针对模块提出想法，确认是否发散，相关逻辑是否覆盖到，关联部分，并记录和跟踪会议记录，并及时优化和补充案例，必须要求开发人员提出意见；10、版本预发布后针对测试用例做整体总结，并提出改进措施和具体的方法，并优化案例，保证版本案例与版本一致，整改完成的模块合入到产品线基线案例库中；测试案例编写人员素质保证1、 产品线内部组织学习和培训，只有通过案例编写考核的人员才有资格进行案例编写工作，由测试中心组织考试；2、 产品线可根据案例的返工次数排名进行考核项；3、 产品线可根据案例评审意见排名进行奖励；4、 案例编写前期工作最好安排有经验、测试设计师以上人员跟踪和编写；5、 测试人员在编写案例过程中产品线要定时指导和检查，同时测试人员要学习素材库和参考一些好的测试用例；需求变更1、 需求变更之前需组织讨论此变更带来的影响，并分析需求变更的测试点、关联测试、异常测试，在详细评估工作量后在提交需求变更；2、 测试过程中的需求变更，无论大小，必须要保证新需求都走了需求更正、测试用例编写、评审、执行，质量分析和总结；3、 过程中控制小需求变更的数量，可合并在一起做需求变更流程；4、 一般来说，大版本第三轮不能在加入任何小需求变更，第一轮之后不能加入大需求变更，小和中版本第一轮后期不能在加入任何需求变更，如有特殊情况，需给出风险分析报告，并加大测试力度；问题合入：分为网上问题、遗留问题；1、 版本前期将所有需合入的网上问题、遗留问题汇总，和开发人员达成一致并分析问题带来的影响和测试点的全面性，在编写案例时覆盖需合入的问题，在集成测试阶段验证问题是否全部合入，版本测试经理或测试经理抽查；2、 测试过程中的合入的问题，分析问题带来的影响和测试点的全面性，并补充案例，版本测试经理或测试经理评审案例；3、 版本后期严谨合入问题，不严重的问题可以在R版本中合入，如遇严重问题需合入，和开发分析问题带来的影响和测试点的全面性，并加大对模块的测试和基本功能覆盖；