测试用例设计规范.docx
《测试用例设计规范.docx》由会员分享，可在线阅读，更多相关《测试用例设计规范.docx（27页珍藏版）》请在冰点文库上搜索。
测试用例设计规范
百胜FIS2.0CMD
测试用例规范
目录
1本系统功能测试2
1.1模块功能测试2
1.1.1测试用例属性2
1.1.2测试用例功能设计原则2
1.2模块间数据交互测试7
1.2.1关联点（前置条件、后置条件）7
1.2.2数据交互7
1.3兼容、安全、UI测试7
1.3.1兼容测试7
1.3.2UI测试7
1.3.3安全测试8
2系统间接口测试8
3测试用例执行8
4附录10
4.1场景法设计10
4.1.1定义10
4.1.2场景设计10
4.1.3设计步骤15
4.2边界值设计15
4.2.1定义15
4.2.2设计方法15
4.3等价类划分设计15
4.3.1定义15
4.3.2设计方法16
1本系统功能测试
1.1模块功能测试
1.1.1测试用例属性
测试用例属性
QC中是否使用
EXCEL中是否使用
备注
模块名称
✓
✓
测试场景
✓
✓
用例编号
✓
用例名称
✓
✓
Description
角色
✓
✓
前置条件
✓
✓
需要的模块必须指出
操作步骤
✓
✓
预期结果
✓
✓
创建人\测试人
✓
可选
测试结果
✓
EXCEL中是“通过”/“不通过”
测试时间
✓
可选
BUG编号
✓
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.2UI测试
对不同的页面都需要描述界面检查，检查内容如下：
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.单元测试（此处单元测试指本系统中单模块测试）：
版本号
版本说明
V0.1
对所有主要功能进行测试
V0.2
V0.3
V0.4
V0.5
V0.6
执行所有功能、UI、控件测试用例
V0.7
V0.8
V0.9
BUG回测
V1.0
说明：
第一轮测试5个版本，第二轮测试3个版本，第三轮2个版本，共计10个版本
B.集成测试：
版本号
版本说明
V0.1
执行所有的集成测试用例
V0.2
V0.3
V0.4
V0.5
V0.6
回测BUG以及执行页面UI以及页面控件测试用例
V0.7
V0.8
V0.9
BUG回测
V1.0
说明：
第一轮测试5个版本，第二轮测试3个版本，第三轮2个版本，共计10个版本
C.系统测试：
版本号
版本说明
V0.1
在不同客户端环境下进行全面测试
V0.2
V0.3
V0.4
V0.5
V0.6
BUG回测
V0.7
V0.8
V0.9
进行上线前的全面测试
V1.0
说明：
第一轮测试5个版本，第二轮测试3个版本，第三轮2个版本，共计10个版本
4附录
4.1场景法设计
4.1.1定义
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
由此会产生很多组场景，如下图所示：
●基本流：
经过测试用例最简单的路径。
●备选流：
一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。
4.1.2场景设计
上图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。
基本流用直黑线来表示，是经过用例的最简单的路径。
每个备选流自基本流开始之后，备选流会在某个特定条件下执行。
备选流可能会重新加入基本流中（备选流1和3），还可能起源于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和4）。
从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
场景1
基本流
场景2
基本流
备选流1
场景3
基本流
备选流1
备选流2
场景4
基本流
备选流3
场景5
基本流
备选流3
备选流1
场景6
基本流
备选流3
备选流1
备选流2
场景7
基本流
备选流4
场景8
基本流
备选流3
备选流4
注：
为方便起见，场景5、6和8只描述了备选流3指示的循环执行一次的情况。
生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。
例如，假定上图描述的用例对备选流3规定如下：
“如果在上述步骤2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。
系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤2‘输入提款金额’，此时银行客户可以输入新的提款金额。
”
据此，可以开始确定需要用来执行备选流3的测试用例：
测试用例ID
场景
条件
预期结果
TCx
场景4
步骤2-提款金额>帐户余额
在步骤2处重新加入基本流
TCy
场景4
步骤2-提款金额<帐户余额
不执行备选流3，执行基本流
TCz
场景4
步骤2-提款金额=帐户余额
不执行备选流3，执行基本流
注：
由于没有提供其他信息，以上显示的测试用例都非常简单。
测试用例很少如此简单。
下面是一个由用例生成测试用例的更符合实际情况的示例。
示例：
一台ATM机器的主角和用例。
下表包含了上图中提款用例的基本流和某些备用流：
基本流
本用例的开端是ATM处于准备就绪状态。
准备提款-客户将银行卡插入ATM机的读卡机。
验证银行卡-ATM机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。
输入PIN-ATM要求客户输入PIN码（4位）
验证帐户代码和PIN-验证帐户代码和PIN以确定该帐户是否有效以及所输入的PIN对该帐户来说是否正确。
对于此事件流，帐户是有效的而且PIN对此帐户来说正确无误。
ATM选项-ATM显示在本机上可用的各种选项。
在此事件流中，银行客户通常选择“提款”。
输入金额-要从ATM中提取的金额。
对于此事件流，客户需选择预设的金额（10美元、20美元、50美元或100美元）。
授权-ATM通过将卡ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。
对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。
出钞-提供现金。
返回银行卡-银行卡被返还。
收据-打印收据并提供给客户。
ATM还相应地更新内部记录。
用例结束时ATM又回到准备就绪状态。
备选流1-银行卡无效
在基本流步骤2中-验证银行卡，如果卡是无效的，则卡被退回，同时会通知相关消息。
备选流2-ATM内没有现金
在基本流步骤5中-ATM选项，如果ATM内没有现金，则“提款”选项将无法使用。
备选流3-ATM内现金不足
在基本流步骤6中-输入金额，如果ATM机内金额少于请求提取的金额，则将显示一则适当的消息，并且在步骤6-输入金额处重新加入基本流。
备选流4-PIN有误
在基本流步骤4中-验证帐户和PIN，客户有三次机会输入PIN。
如果PIN输入有误，ATM将显示适当的消息；如果还存在输入机会，则此事件流在步骤3-输入PIN处重新加入基本流。
如果最后一次尝试输入的PIN码仍然错误，则该卡将被ATM机保留，同时ATM返回到准备就绪状态，本用例终止。
备选流5-帐户不存在
在基本流步骤4中-验证帐户和PIN，如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款，则ATM显示适当的消息并且在步骤9-返回银行卡处重新加入基本流。
备选流6-帐面金额不足
在基本流步骤7-授权中，银行系统返回代码表明帐户余额少于在基本流步骤6-输入金额内输入的金额，则ATM显示适当的消息并且在步骤6-输入金额处重新加入基本流。
备选流7-达到每日最大的提款金额
在基本流步骤7-授权中，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在24小时内允许提取的最多金额，则ATM显示适当的消息并在步骤6-输入金额上重新加入基本流。
备选流x-记录错误
如果在基本流步骤10-收据中，记录无法更新，则ATM进入“安全模式”，在此模式下所有功能都将暂停使用。
同时向银行系统发送一条适当的警报信息表明ATM已经暂停工作。
备选流y-退出
客户可随时决定终止交易（退出）。
交易终止，银行卡随之退出。
备选流z-“翘起”
ATM包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。
在任一时刻，如果某个传感器被激活，则警报信号将发送给警方而且ATM进入“安全模式”，在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。
在第一次迭代中，根据迭代计划，我们需要核实提款用例已经正确地实施。
此时尚未实施整个用例，只实施了下面的事件流：
基本流-提取预设金额（10美元、20美元、50美元、100美元）
备选流2-ATM内没有现金
备选流3-ATM内现金不足
备选流4-PIN有误
备选流5-帐户不存在/帐户类型有误
备选流6-帐面金额不足
可以从这个用例生成下列场景
场景1-成功的提款
基本流
场景2-ATM内没有现金
基本流
备选流2
场景3-ATM内现金不足
基本流
备选流3
场景4-PIN有误（还有输入机会）
基本流
备选流4
场景5-PIN有误（不再有输入机会）
基本流
备选流4
场景6-帐户不存在/帐户类型有误
基本流
备选流5
场景7-帐户余额不足
基本流
备选流6
【注】为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。
对于这7个场景中的每一个场景都需要确定测试用例。
可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。
本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。
然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。
例如，在下面的矩阵中，V（有效）用于表明这个条件必须是VALID（有效的）才可执行基本流，而I（无效）用于表明这种条件下将激活所需备选流。
下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。
TC（测试用例）ID号
场景/条件
PIN
帐号
输入的金额
（或选择的金额）
帐面金额
ATM内的金额
预期结果
CW1.
场景1-成功的提款
V
V
V
V
V
成功的提款。
CW2.
场景2-ATM内没有现金
V
V
V
V
I
提款选项不可用，用例结束
CW3.
场景3-ATM内现金不足
V
V
V
V
I
警告消息，返回基本流步骤6-输入金额
CW4.
场景4-PIN有误（还有不止一次输入机会）
I
V
n/a
V
V
警告消息，返回基本流步骤4，输入PIN
CW5.
场景4-PIN有误（还有一次输入机会）
I
V
n/a
V
V
警告消息，返回基本流步骤4，输入PIN
CW6.
场景4-PIN有误（不再有输入机会）
I
V
n/a
V
V
警告消息，卡予保留，用例结束
在上面的矩阵中，六个测试用例执行了四个场景。
对于基本流，上述测试用例CW1称为正面测试用例。
它一直沿着用例的基本流路径执行，未发生任何偏差。
基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。
这些负面测试用例由CW2至6表示（阴影单元格表明这种条件下需要执行备选流）。
虽然CW2至6对于基本流而言都是负面测试用例，但它们相对于备选流2至4而言是正面测试用例。
而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1-基本流）。
每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。
要全面地测试场景4-PIN有误，至少需要三个正面测试用例（以激活场景4）：
Ø输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3-输入PIN。
Ø输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。
Ø最后一次输入时输入了“正确”的PIN。
备选流在步骤5-输入金额处重新加入基本流。
【注】在上面的矩阵中，无需为条件（数据）输入任何实际的值。
以这种方式创建测试用例矩阵
升级会员 