QA_测试用例设计规范QA_测试用例设计规范.docx

必威体育官网网址级别公开版本号V1.0文档编号[XXXX]系统测试用例设计规范撰写部门：测试部撰写时间：2014年3月4日发行范围：开发部和测试部文档记录版本编号变化状态简要说明撰写/变更人批准人批准日期V1.0C创建测试部相关流程文档张梅娟*变化状态：C――创建、A――增加、M――修改（+修改说明）、D――删除（+删除说明）文档审批信息序号角色审批人签字审批日期备注目 录1目的42适用范围43术语解释44测试用例设计44.1测试用例作用44.2设计思路44.2.1完整项目型用例设计54.2.2集成产品型用例设计54.3编写规范54.3.1测试用例设计范围和原则54.3.2测试用例设计方法64.3.3功能和业务用例设计规范74.3.4角色模块功能点用例设计规范74.3.5业务用例设计规范85结合工具使用95.1测试用例管理（直接建立测试需求和测试项）95.2测试执行管理155.3缺陷管理151目的统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。2适用范围本规范适用于[XXX]系统测试用例的管理和缺陷的管理。3术语解释系统测试：系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正测试用例（Test Case）：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。需求用例驱动测试用例设计：通过需求文档来推动整个测试用例的设计进行，但需求测试驱动测试用例的设计并不只是单纯的用例设计工作，而是把需求分析，测试用例的设计的量化的过程。4测试用例设计4.1测试用例作用便于测试经理检查测试人员对系统的理解程度。便于测试人员和开发人员就测试内容和范围达成一致，利于交流。指导测试人员的执行过程，使测试过程有序不重复。方便测试经理把握测试的实际进度，做到心中有数。便于测试结果分析。4.2设计思路系统测试的目的在于与系统的需求定义做比较，发现软件与系统需求定义不符合或相矛盾的地方。所以编写系统测试用例前，测试人员要根据需求规格说明书和测试需求整理文档，详细理解用户的真正需求，并对软件所实现的业务目标准确理解。研发中心软件产品根据开发形式大致有完整项目型和集成产品型之分，所以我们针对不同性质的产品要采用不同的用例设计思路。软件产品的定义由研发中心高层经理决定。本文中涉及的设计思路包含两种，以软件功能模块划分进行设计和需求用例驱动设计方法。【完整项目型：（需求+知识学习）与集成产品型：(项目紧急，需求定义不明确）划分，不同项目有不同的测试用例设计方法】4.2.1完整项目型用例设计这种类型的产品是一个完整的项目产品，可直接适应于用户，所以产品经理（后续角色）或测试人员在这类产品的需求编写阶段就要介入，对系统需求进行全面的了解和相关知识的学习。这种类型的产品采用以需求用例驱动的设计思路。以产品需求为依据，产品经理或测试人员用面向对象的思想对产品需求进行二次加工，提炼加工出测试需求文档。针对提炼出的测试需求文档，产品经理或测试人员要和开发人员进行讨论确认。确认之后进行步骤3，否则重新执行步骤1。根据提炼出的测试需求文档进行系统测试用例设计，按业务流程和角色模块功能设计测试用例。测试用例设计完成后，要进行用例评审。评审不通过时，重新执行步骤3.4。4.2.2集成产品型用例设计这种类型的产品不是直接面向用户的，是一个框架体系结构。这种产品采用业务流程和功能模块划分的方法进行设计。以需求规格说明书中提供的功能列表和功能模块划分为依据，测试人员在此基础上进行细化，提取出业务用例。在业务用例的基础之上提取界面元素和各功能业务规则中的功能点。根据1和2中提取的功能点和基本业务流程设计系统测试用例。测试用例设计完成后，要进行用例评审。评审不通过时，重新执行步骤1.2.3.4。4.3编写规范本部分内容作为具体编写系统测试用例的依据。4.3.1测试用例设计范围和原则测试用例按安装配置测试、业务流程测试、角色模块功能点测试（或模块功能点测试）、产品接口测试、数据权限测试、故障转移与恢复、用户界面测试、性能测试进行测试范围划分和管理，测试用例按基本流和异常流进行设计，基本流和异常流中每一个测试点标题明确测试目的，每个测试集（业务目标或功能点）开始明确测试范围和前置条件（可选），每个测试点前置条件，紧跟测试标题，测试目录和测试集按测试优先级进行编号排序，基本流和异常流中的测试点也按测试优先级进行编号排序，测试用例管理如下图所示。安装配置测试正确性验证，依据安装配置