百胜FIS 2.0 CMD

测试用例规范

1 本系统功能测试

1.1 模块功能测试

1.1.1 测试用例属性

1.1.2 测试用例功能设计原则

设计测试用例的方法参考本文档的附录

1. 根据需求文档划分测试场景，按照测试场景命名测试步骤名称。如下图所示：

2. 用例编号的命名规则为“模块名称（缩拼）”+“-”+“4位编号”，编号自0001号开始。例如：基础信息模块的用例编号，JCXX-0001；【注】该条为EXCEL测试用例书写规则

3. 对于XX点的测试需求，至少需要确定两个测试用例。一个测试用例代表预期的条件，它可用于核实行为是否正确或符合预期结果（正面测试）。另一个测试用例代表不可接受的、异常的或意外的条件，它可用于核实是否以预期结果实现（负面测试）；

4. 每条测试用例是该页面中唯一的检查项；

5. 每条用例描述的系统默认状态、默认数据也是该页面唯一的检查项。

1.1.2.1 数据输入

本系统中需输入的类型包括：文本框、下拉框、复选框、单选框、日期控件

◆ 公共用例

A. 文本框/文本域（100、1000个字符）：长度校验、类型校验、是否必填项校验

1) 超出数据库长度、页面定义的长度均不允许输入

2) 当定义的长度“数据库长度>页面长度”时，超出页面长度则不允许输入

3) 禁止输入的文本框，默认禁灰显示

B. 下拉框：选择数据后是否有联动效果、点击后下拉显示数据内容、点击空白后下拉框收缩

C. 单选框：选中、更换

D. 复选框：选中、取消

E. 日期控件：弹出位置、选中后日期按格式要求显示在日期输入框、输入日期后点击日期控件自动定位到所选择的的日期

F. 分页：下拉框条数选择、首页、上一页、下一页、尾页、GO、输入框页数

◆ 各模块需书写的用例

A. 文本框：字符长度限制校验、输入类型校验、描述是否必填

B. 下拉框：是否有默认值、选择项数据来源（需描述来源是：页面固定、数据库调用（描述出来源的数据表））【注】前期可以不需要描述数据表、后期确定后需补充

C. 单选框：个数、显示方式（例如：是、否）、默认项

D. 复选框：个数、显示方式、是否默认勾选

E. 日期控件：是否有选择范围控制

1.1.2.2 需求覆盖

测试用例中的测试点要覆盖需求规格说明书中的业务场景以及业务规则（具体内容如下），且书写的测试操作步骤、预期结果（正确、是否类词语不能出现）无歧义。

A. 页面通用功能，如：通知、讨论、日志、导出、上传附件、返回；

B. 页面基本功能，如：新增、删除、修改、查询、保存；

C. 特定页面的功能，如：呈递、审批、重置、清空、同步、锁定；

1.1.2.3 功能点分类（讲述时加上背景）

按照模块的“一级菜单(一级目录)、二级菜单（二级目录）、页面名称（三级目录）、TAB页名称（四级目录--如果页面中存在TAB页签）、页面按钮/链接操作（用例的名称）、步骤/测试数据”，如下图所示：

用例设计编写如下：

1. 页面元素检查：

 页面标题；

 页面所有控件及对应的字段名称（按钮、文本框、下拉框、单选框、复选框、日期控件）；

 控件是否有默认值显示以及对应的数据来源；

 控件是否可编辑；

 必填项校验（必填项的显示效果检查）；

 校验控件的格式、长度（有则需描述，无则略过）；

 页面包含的列表字段名称（有则需描述，无则略过该条件）；

【注】页面检查在查询、新增、编辑、审批页面需要添加描述

2. 查询：

 列表默认数据（如果无数据显示是否有提示信息）；

 列表默认排序；

 哪些字段支持排序功能；

 单条件查询（每个查询条件均需编写用例，需描述是否支持模糊查询）；

 全条件查询；

3. 新增：

 必填项效果检查（未填写保存后的提示效果，如：弹出必填提示信息，点击后光标定位到必填项文本框等）；

 保存功能（必填项未填写，保存弹出提示）；

1) 全部字段信息填写；

2) 只填写必填项；

 保存成功提示语；

 保存成功后停留在那个页面（新增页面、列表页面）；

 新增成功后需检查信息被添加至列表页面；

 列表页面显示的字段信息为新增时填写的信息；

4. 编辑：

 字段需显示之前填写的信息；

 必填项效果检查（未填写保存后的提示效果，如：弹出必填提示信息，点击后定位到必填项文本框等）；

 字段是否可编辑；

 单字段修改；

 全部字段修改；

 保存功能（必填项未填写保存弹出提示；单字段修改保存成功后编辑页面/列表页面只是单个字段的信息被修改）；

 保存成功提示；

 保存成功后停留在那个页面（新增页面、列表页面）；

 修改成功后需检查信息被添加至列表页面；

 列表页面显示的字段信息为修改时填写的信息；

5. 删除：

 信息是否被引用；

 单个删除；

 批量删除；

 复选框的选中/取消；

 删除弹出的提示；

 删除成功的提示；

6. 呈递：

 呈递后的审批人；

 呈递后添加一条信息至列表页面；

 呈递审批列表页面查看下一节点的接收人；

 呈递审批列表显示目前流程的进度；

 呈递审批列表显示审批单的状态；

 发送任务给审批人；

7. 审批：（分审批通过、审批拒绝2种结果书写）

 页面需显示呈递的信息；

 单个审批；

 批量审批；

 必填项效果检查（如：审批拒绝，须填写拒绝原因）；

 审批后添加一条信息至呈递审批列表页面；

 呈递审批列表页面可查看下一节点的接收人；

 呈递审批列表显示目前流程的进度；

 呈递审批列表显示审批单的状态；

 发送任务给审批人；（每个节点审批均需要检查）

 终节点的审批人，审批通过需发送一条通知给申请人

 每个节点的审批人，审批拒绝需发送一条通知给申请人（每个节点审批均需要检查）

8. 上传附件：

 页面特殊的附件需描述；

 链接跳转至那个页面需描述；

 附件个数；

 新附件是否覆盖之前的旧附件；

 附件格式筛选；

 附件提示；

 附件上传成功在列表页面显示信息；

 附件的操作；

9. 通知：

 候选人；

 已选人；

 单选功能；

 全选功能；

 通知后列表页面添加通知信息；

 列表可查看通知的人员；

 通知后我的工作室有一条通知信息；

 点击通知链接可以跳转至对应的页面；

10. 讨论：

 必填项效果检查（未填写发送后的提示效果，如：弹出必填提示信息，点击后定位到必填项文本框等）；

 候选人；

 已选人；

 单选功能；

 全选功能；

 讨论后列表页面添加讨论信息；

 列表可查看讨论的人员；

 列表可查看讨论的信息内容；

 发送讨论后我的工作室有一条通知信息；

 点击通知链接可以跳转至对应的页面；

11. 日志：

 查看日志记录；

 核对字段记录信息；

 关闭日志记录；

12. 返回：

 返回至XX页面；

 链接跳转是否正确；

要求：

1) 按照特有的条件（如：不同类型的餐厅、不同角色）分开书写测试用例步骤

2) 按照“查看页面、操作页面、保存页面、辅助功能的操作”的顺序书写测试用例

1.2 模块间数据交互测试

1.2.1 关联点（前置条件、后置条件）

模块间存在的关联点，需描述出在A模块中的功能以及对B模块的影响。例如：A模块的某个审批单在审批之后才开启B模块中的页面。

1.2.2 数据交互

1. 模块间存在数据交互，设计测试用例时需描述数据在A、B模块中的一致性。例如：A模块的数据是审批通过的某个定额，数据在B模块显示时，数据必须与A模块中显示的一致。

2. 模块间存在状态变更的，需描述在A模块修改状态之后，关联模块的B模块状态也随之修改。

1.3 兼容、安全、UI测试

1.3.1 兼容测试

不同浏览器版本在对同一处功能点显示时，会有不同之处。测试用例设计时，高版本浏览器和低版本浏览器需分别设计测试用例。例如：用户IE8的浏览器需要显示IE9的特点时，需针对IE8浏览器设计不同的测试用例。

1.3.2 UI测试

对不同的页面都需要描述界面检查，检查内容如下：

1. 窗口切换、移动时正常吗？（公共用例，思考）

2. 各种界面元素的文字正确吗？（如标题、提示等）

3. 各种界面元素的状态正确吗？（如正常、退出等状态）

4. 各种界面元素支持键盘操作吗？

5. 各种界面元素支持鼠标操作吗？

6. 对话框中的缺省焦点正确吗？

7. 数据项能正确回显吗？

8. 对于常用的功能，用户能否不必阅读手册就能使用？

9. 执行有风险的操作时，有“确认”、“取消”等提示吗？

10. 操作顺序合理吗？

11. 分页显示，翻页、跳页是否实现？

12. 界面各元素美观合理吗？

1.3.3 安全测试

1. 应用程序级别的安全性：检查角色只能访问其所属用户类型已被授权访问的那些功能或数据。

2. 系统级别的安全性：检查只有具备系统和应用程序访问权限的角色才能访问系统和应用程序。

3. 对于各别页面需取消权限限制。例如：报表通知某些人员，这些人员点击链接是可以访问无权限查看的页面。

4. 无权限访问的页面，拷贝有权限访问人员的有效URL地址，检查无权限人员是否能访问

2 系统间接口测试

1. 设计接口测试用例时，需描述接口间交互的类型（如：删除、新增、修改），分类型书写测试用例；

2. 同步接口时是否需要准备数据以及所准备数据的格式等，需详细描述；（如：.Csv文件）

3. XX系统的业务流程审批完成，下一步需接口测试的，需描述出此时的同步状态；

4. 接口同步成功、同步失败反馈的状态、备注等信息需描述；

5. 涉及金额类数据接口测试时，需描述出检查接口同步前与同步后的金额、数量数据是否一致。

6. 接口测试的数据部分需在数据库中检查时，需在接口测试用例中描述并给出具体的数据库名称或者查询语句。（限QC中书写测试用例）

3 测试用例执行

A. 单元测试（此处单元测试指本系统中单模块测试）：

B. 集成测试：

C. 系统测试：

4 附录

4.1 场景法设计

4.1.1 定义

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。由此会产生很多组场景，如下图所示：

● 基本流：经过测试用例最简单的路径。

● 备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

4.1.2 场景设计

上图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。

例如，假定上图描述的用例对备选流 3 规定如下：

“如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤 2‘输入提款金额’，此时银行客户可以输入新的提款金额。”

据此，可以开始确定需要用来执行备选流 3 的测试用例：

注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。

下面是一个由用例生成测试用例的更符合实际情况的示例。

示例：

一台 ATM 机器的主角和用例。

下表包含了上图中提款用例的基本流和某些备用流：

可以从这个用例生成下列场景

【注】为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入上表。

对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例 ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由 CW2 至 6 表示（阴影单元格表明这种条件下需要执行备选流）。虽然 CW2 至 6 对于基本流而言都是负面测试用例，但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 - 基本流）。

每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误，至少需要三个正面测试用例（以激活场景 4）：

 输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。

 输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。

【注】在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：

 场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用

 场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款

 场景 7 - 帐户余额不足：请求的金额超出帐面金额

在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：

 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）

 无法读卡（读卡机堵塞、脱机或出现故障）

 帐户已消户、冻结或由于其他方面原因而无法使用

 ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）

 无法联系银行系统以获得认可

 银行网络离线或交易过程中断电

在确定功能性测试用例时，确保满足下列条件：

 已经为每个用例场景确定了充足的正面和负面测试用例。

 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边界条件/值上都存在测试用例。

 测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还应能处理用户界面对象状态或条件。

 测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。

4.1.3 设计步骤

 根据需求说明书中对该模块的业务描述，分析可能的情况并划分出程序的基本流及各项备选流；

 根据划分出的基本流和各项备选流生成不同的场景；

 对每一个场景生成相应的测试用例，分步骤描述不同场景的前置条件、预期结果；

 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值

4.2 边界值设计

4.2.1 定义

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下其测试用例来自等价类的边界。

4.2.2 设计方法

 通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、质量、大小、速度、方位、尺寸、空间等

 相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等

 如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚超越这个边界范围的值作为测试输入数据；

 如果输入条件规定了字符个数，则用最大字符数、最小字符数、比最大字符数多1、比最小字符数小1的数作为测试输入数据；

4.3 等价类划分设计

4.3.1 定义

等价类划分法是将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。等价类划分不仅可以用来确定测试用例中的数据的输入输出的精确取值范围，也可以用来准备中间值、状态和与时间相关的数据以及接口参数等，所以等价类可以用在系统测试、集成测试和组件测试中，在有明确的条件和限制的情况下，利用等价类划分技术可以设计出完备的测试用例。

4.3.2 设计方法

 在输入条件规定的取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类。

 在规定了输入数据的一组值中（假定有n个值），并且程序要对每个输入值分别处理的情况下，可以确定n个有效等价类和一个无效等价类。

 在规定输入数据必须遵守的规则的情况下，可以确定一个有效等价类和若干个无效等价类。

 在输入条件规定了输入值的集合或规定了“必须如何”的条件下，可以确定一个有效等价类和一个无效等价类。

 在确定已划分的等价类中各元素在程序处理中的方式不同的情况下，则应将该等价类进一步地划分为更小的等价类。

（完整word版）测试用例设计规范