测试用例设计的完整过程

2015.12.22更新，将本文最后附的测试设计文档包含的基本要素，独立出来成一篇独立博客，增加了测试用例书写规范（此部分是转载，原文链接：http://www.51testing.com/html/65/n-3694665.html）

-----------------------------------------------------------------------------

前一篇有讲 “测试用例内容及评判标准”，本篇我们来讲讲测试用例设计的完整过程以及做好测试用例的关键。

测试用例设计的完整过程

一个项目启动后，开发会根据项目的需求文档（RFP：Request for Proposal）编写开发计划（SDP：System Development Plan）和系统需求说明书（SRS：System Requirement Specification）;与此同时，测试根据需求文档，SDP和SRS来提取测试范围（或者测试需求），思考可能使用到的测试方法和测试工具，测试环境等，这些都会编写在测试计划文档里（STP：System Test Plan至于测试计划包括的具体内容我们下篇讲）。

根据RFP，SDP，SRS，STP就去详细地写一条一条的测试用例可能并不实际，因为项目初期RFP这些文档就是粗略型的大纲文章。当然需求越早确定越好，并尽量避免后期的频繁改动。然而实际项目中你会发现需求在早期就确定下来是一件多么困难的事情。为了梳理当前测试需求，并指导后期测试用例编写，在测试用例编写之前需要输出一份测试需求文档或者叫做测试设计文档（STD：System Test Design，文章最后会附STD具体包含的内容）。文档编写形式多样，里面可以用思维导图（Xmind，FreeMind）列出每个正常测试点，异常测试点等等，整理出测试思路。更重要的是从这份文档里测试人员能够有个清楚的测试思路，并找出自己为了达到测试目的，自己需要做哪些准备。

STD顺利完成之后，再转换成STC就很容易，且不容易遗漏。STC永远不是一蹴而成的，它是个持久性活动。一轮测试后，探索测试，交叉测试使得测试人员又有新的测试思路，都可以作为补充STC的来源。

测试用例设计出来以后是需要评审的，评审人员主要有需求方，设计人员，开发人员，其他测试人员，以及开发主管和测试主管。最后将评审结果记录在文档里或者记录在管理文档的系统里，比如CC或者在线管理工具RedMine，以便后期查看和维护。

做好测试用例的关键

1.多和开发沟通，在项目前期就达到深层次理解和分析需求，最后经过STD将这份理解分析转化成后期可执行的测试用例。

2.多和开发沟通，控制需求变更对测试用例的影响。

 测试用例编写规范（更新于12.22）

      用例编写规范目的

　　1.统一 测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。

　　2.测试用例，不仅仅用于QA阅读和执行。它们也可能会被开发、PD、PM等阅读审查或执行；也更可能被其他测试人员或者新员 工作为业务 学习、测试执行的参照。

　　3.编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例并执行用例。

　 　例模块划分规范

　　要求：

　　1.产品、功能点同一层级的结构按同一个纬度来划分。如应用、同等级产品、同等级功能点等；

　　2.产品是指产品线下大的业务模块。如交易购物车、交易下单；

　　3.功能点指业务模块下的子功能点，是最小功能点叶子节点。如01 功能_02 购物车展示_01 顶部及导航；

　　4.功能点目前无法再细分层级，后续会扩展功能点层次，在此之前，允许使用功能点名进行分层用例划分。如06 边境仓_03 发货单管理_02 创建发货单；

　　5.产品、功能点划分不允许包含冒烟、回归、自动化这类以测试阶段或测试方法的命名的名称；

　　6.主干用例库中产品、功能点已废弃的需要删除；

　　7.主干用例库中产品、功能点是之前QC迁移过来的，命名格式需要修改标准格式；

　 　用例颗粒度划分规范

　　用例颗粒度原则：测试用例是执行的最小实体

　　用例划分基本原则是以最小功能模块来划分，为保障用例的可执行性、覆盖度，规范编写用例的粒度要求如下：

　　1.一个功能正常流程，编写一个测试用例；

　　2.一个功能中多个异常流程，应分开编写多个测试用例；

　　3.同一功能不同入口，可合并编写一个测试用例；

　　4.同一功能不同数据准备，应分开编写多个测试用例；

　　5.同一个功能用例的自动化用例和功能用例要匹配，若自动化用例不能完全覆盖功能用例，自动化用例和功能用例拆分两个互补测试用例；

　　 用例编写要求规范

　　用例编写最基本的要求：

　　1.具有清晰名称、前提条件、操作步骤、期望结果的；

　　2.可被他人理解的；

　　3.可被他人执行的；

　 　具体分项要求如下：

　　1.用例名称

　　1）常用的结构“主、谓、宾”；

　　2）名称简洁易懂，不要包括具体操作步骤；

　　2.前置条件

　　1）执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；

　　2）不可将其他用例作为前置条件，前置条件需要语言描述；

　　3）完整清楚，包括入口、帐号类型、账号权限、数据准备等，具体要求如下：

　　3.1）入口：覆盖所有功能入口，包含URL直接访问；

　　3.2）账号类型和权限：覆盖全部会员类型，注意业务权限控制，比如子账号权限，disable会员权限；

　　3.3）数据准备：数据准备完整正确，覆盖到线上环境的所有情况；标识出业务流程处于的条；件，写明 数据库表字段值，如OFFER.status=TBD；对于复杂的数据准备，写清具体 SQL

　　3.操作步骤

　　1）操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；

　　2）操作和结果是一一对应的，但操作中不要包含结果的检查；

　　3）用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）；

　　4）用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；

　　5）用例描述中不允许出现二义性语句；

　　4.预期结果

　　1）原则上每个用例必需要有预期结果，结果不能为空；

　　2）结果中只能包含结果，不能有步骤；

　　3）一个结果有多个检查点时，确保检查点完整；

　　3.1）结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；

　　3.2）结果涉及页面，需明确页面提示结果、数据变化；

　　3.3）结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；

　　3.4）结果涉及消息：需明确关键查看内容；

　　3.5）结果对应不同输入数据有差别时需分别对应描述清晰；

　 　用例维护规范

　　测试用例编写完成后，应对测试用例进行持续的维护：

　　1.新项目需求变更，应及时对测试用例进行修改；

　　2.维护期项目，可根据项目组情况周期对用例进行维护；

　　3.所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例；

　　4.项目发布后的三个工作日内，需将项目用例根据具体情况归入产品功能用例库下