测试用例设计白皮书之场景设计方法.docVIP

测试用例设计白皮书之场景设计方法一.方法简介1、目的 　　站在用户的角度，以用户的使用逻辑及操作习惯为出发点，结合功能用例的设计方法，使用例设计更符合用户使用逻辑更具有可执行性，从而最大程度上覆盖用户需求。 、测试用例设计方法 　　按照不同的规则可以将测试用例分为四个部分：场景用例（用户场景）、系统用例（用户场景的细化）、功能用例（基于业务规则、界面）、设计指标（基于环境、性能、安全等）。 　　 用户场景用例：按照用户的实际操作与业务逻辑设计用例，不必涉及很复杂的操作或逻辑，把用户最常用的、正常的操作流程作为一个场景设计测试用例 　　 系统用例：是用户场景的细化，包含正常场景、分支场景和异常场景，是两个或多个有关联的功能组合而成的场景。 　　 功能用例：用于验证各功能点的业务规则，包括界面元素和各功能的业务规则验证。主要针对单个功能点。 　　 设计指标：系统所需要达到的各级指标。主要包含环境、性能、安全等方面的指标。 　　第一步：用户场景用例（关键字：模拟用户实际操作） 　　描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景，这类的用例不宜过多。 　　第二步：系统各角色的系统用例 　　将系统划分多个角色，再将每个角色分解为多个任务，每个任务就是一个系统用例。系统用例分别正常流程、异常流程，分支流程，以场景的形式描述。 　　系统用例命名原则：正常（异常、分支）流程_描述 　　第三步：功能用例 　　描述单点功能的逻辑规则及页面元素，分层描述逻辑规则，对逻辑规则细化可直接作为用例的操作步骤描述。 　　第四步：设计指标 　　设计指标包含三种类型的用例：环境测试用例、性能测试用例、安全性用例。 　　环境测试用例可依照操作系统版本，浏览器版本不同划分为多个用例。每个用例下可直接调用已有的用户场景用例、系统用例、功能用例，可无须单独编写用例。 　　现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。 　　基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。 二.实战演习 1.例子描述 下图所示是ATM例子的流程示意图 2.2.场景设计：下表所示是生成的场景。 　　注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。 3.用例设计 　　对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。 　　表3-9 测试用例表 4.数据设计 　　一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。 　　测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。 表3-10 测试用例表 三.场景测试设计中性能设计 性能测试按照场景不同一般可以分为两大类，一类是为了测试目的而进行的场景测试，另外一类是基于用户实际情况而进行的场景测试。因此，性能测试用例的设计应该面向性能测试场景来进行。 　　实际上，由于开发环境硬件配置不高，基于用户的测试多在用户现场进行，而为了测试目的而进行的测试多在开发环境即开发团队内部进行，不过两者进行的场所没有严格的界限，例如也可以在开发团队内部模拟用户的环境进行性能测试。 　　“ 为了测试目的而设计的测试用例场景”主要根据测试设计人员的经验来进行，但是仍然要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据。例如一些业务系统，虽然备份历史数据的周期为一年，但是设计大数据量测试用例时仍然包含了系统运行一个月、半年等的数据量模拟测试，因为这些均属于用户的典型场景。 　　综合上面可以看出，性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。下面详细介绍一下常见的三类用户场景： 　　一天内不同时间段的使用场景。在同一天内，大多数系统的使用情况都会随着时间发生变化。例如对于新浪、网易等门户网站，在周一