0.1 文档目的
0.2 文档范围
0.3 读者对象
0.4 参考文献
提示： 列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[ 标识符 ] 作者，文献名称，出版单位（或归属单位），日期
例如：
[AAA] 作者，《立项建议书》，机构名称，日期
[SPP-PROC-ST] SEPG，系统测试规范，机构名称，日期
0.5 术语与缩写解释
缩写、术语 解 释
SPP精简并行过程，Simplified Parallel Process
…
1 . 接口－路径测试用例
1 .1 被测试对象（单元）的介绍
1.2 测试范围与目的
1 . 3 测试环境与测试辅助工具的描述
1.4 测试驱动程序的设计
1.5 接口测试用例
接口A的函数原型
输入/动作期望的输出/相应实际情况
典型值…
边界值…
异常值…
接口B的函数原型
输入/动作期望的输出/相应实际情况
典型值…
边界值…
异常值…
…
1.6 路径测试的检查表
检查项 结论
数据类型问题
（1）变量的数据类型有错误吗？
（2）存在不同数据类型的赋值吗？
（3）存在不同数据类型的比较吗？
变量值问题
（1）变量的初始化或缺省值有错误吗？
（2）变量发生上溢或下溢吗？
（3）变量的精度不够吗？
逻辑判断问题
（1）由于精度原因导致比较无效吗？
（2）表达式中的高族吵优先级有误吗？
（3）逻辑判断结果颠倒吗？
循环问题戚侍
（1）循环终止条件不正确吗？
（2）无法正常终止（死循环）吗？
（3）错误地修改循环变量吗？
（4）存在误差累积吗？
内存问题
（1）内存没有被正确地初始化却被使用吗？
（2）内存被释放后却继续被使用吗？
（3）内存泄漏吗？
（4）内存越界吗？
（5）出现野指针吗？
文件I/O问题
（1）对不存在的或者错误的文件进行 *** 作吗？
（2）文件以不正确的方式打开吗？
（3）文件结束判断不正确吗？
（4）没有正确地关闭文件吗？
错误处理问题
（1）忘记进行错误处理吗？
（2）错误处理程序块一直没有机会被运行？
（3）错误处理程序块本身就有毛病吗？如报告的错误与实际错误不一致，穗虚处理方式不正确等等。
（4）错误处理程序块是“马后炮”吗？如在被它被调用之前软件已经出错。
…
2. 功能测试用例
2 .1 被测试对象的介绍
2 .2 测试范围与目的
2. 3 测试环境与测试辅助工具的描述
2 .4 测试驱动程序的设计
2 .5 功能测试用例
功能A描述
用例目的
前提条件
输入/动作期望的输出/相应实际情况
示例：典型值…
示例：边界值…
示例：异常值…
功能B描述
用例目的
前提条件
输入/动作期望的输出/相应实际情况
……
3. 健壮性测试用例
3 .1 被测试对象的介绍
3 .2 测试范围与目的
3. 3 测试环境与测试辅助工具的描述
3 .4 测试驱动程序的设计
3 .5 容错能力 / 恢复能力测试用例
异常输入/动作容错能力/恢复能力造成的危害、损失
示例：错误的数据类型…
示例：定义域外的值…
示例：错误的 *** 作顺序…
示例：异常中断通信…
示例：异常关闭某个功能…
示例：负荷超出了极限…
4 . 性能测试用例
4 .1 被测试对象的介绍
4 .2 测试范围与目的
4. 3 测试环境与测试辅助工具的描述
4 .4 测试驱动程序的设计
4 .5 性能测试用例
性能A描述
用例目的
前提条件
输入数据期望的性能（平均值）实际性能（平均值）
性能B描述
用例目的
前提条件
输入数据期望的性能（平均值）实际性能（平均值）
……
5 . 图形用户界面测试用例
5 .1 被测试对象的介绍
5 .2 测试范围与目的
5. 3 测试环境与测试辅助工具的描述
5 .4 测试驱动程序的设计
5 .5 测试人员分类
类别特征
A类
B类
……
5.6 用户界面测试的检查表
检查项测试人员的类别及其评价
窗口切换、移动、改变大小时正常吗？
各种界面元素的文字正确吗？（如标题、提示等）
各种界面元素的状态正确吗？（如有效、无效、选中等状态）
各种界面元素支持键盘 *** 作吗？
各种界面元素支持鼠标 *** 作吗？
对话框中的缺省焦点正确吗？
数据项能正确回显吗？
对于常用的功能，用户能否不必阅读手册就能使用？
执行有风险的 *** 作时，有“确认”、“放弃”等提示吗？
*** 作顺序合理吗？
有联机帮助吗？
各种界面元素的布局合理吗？美观吗？
各种界面元素的颜色协调吗？
各种界面元素的形状美观吗？
字体美观吗？
图标直观吗？
…
6. 信息安全性测试用例
6 .1 被测试对象的介绍
6 .2 测试范围与目的
6. 3 测试环境与测试辅助工具的描述
6 .4 测试驱动程序的设计
6 .5 信息安全性测试用例
假想目标A
前提条件
非法入侵手段是否实现目标代价－利益分析
……
假想目标B
前提条件
非法入侵手段是否实现目标代价－利益分析
……
7. 压力测试用例
7 .1 被测试对象的介绍
7 .2 测试范围与目的
7. 3 测试环境与测试辅助工具的描述
7 .4 测试驱动程序的设计
7 .5 压力测试用例
极限名称A 例如“最大并发用户数量”
前提条件
输入/动作输出/响应是否能正常运行
例如10个用户并发 *** 作
例如20个用户并发 *** 作
…
极限名称B
前提条件
输入/动作输出/响应是否能正常运行
…
8. 可靠性测试用例
8 .1 被测试对象的介绍
8 .2 测试范围与目的
8. 3 测试环境与测试辅助工具的描述
8 .4 测试驱动程序的设计
8 . 5 可靠性测试用例
任务A描述
连续运行时间
故障发生的时刻故障描述
……
统计分析
任务A无故障运行的平均时间间隔（CPU小时）
任务A无故障运行的最小时间间隔（CPU小时）
任务A无故障运行的最大时间间隔（CPU小时）
任务B描述
连续运行时间
故障发生的时刻故障描述
……
统计分析
任务B无故障运行的平均时间间隔（CPU小时）
任务B无故障运行的最小时间间隔（CPU小时）
任务B无故障运行的最大时间间隔（CPU小时）
9. 安装 / 反安装测试用例
9 .1 被测试对象的介绍
9 .2 测试范围与目的
9. 3 测试环境与测试辅助工具的描述
9 .4 测试驱动程序的设计
9 . 5 安装 / 反安装测试用例
配置说明
安装选项描述是否正常使用难易程度
全部
部分
升级
其它
反安装选项描述是否正常使用难易程度
附录：评审意见
对各个功能模块进行测试态让点分析，提取测试点再堆测试点进行用例编写配戚。
比如对PC端QQ账号的登录模块，提取测试点就有：
①正常登陆；
②账号帆卖局为空时点击登录；
③密码为空时点击登录；
④账号密码都为空时点击登录；
⑤密码错误时点击登录 ；
⑥找回密码功能是否有效；
⑦记住密码功能是否有效；
⑧自动登录功能是否有效。
编写测试用例该注意：
①根据项目的实际情况设计测试用例表格；
②用例格式不要生搬硬套；
③根据具体情况编写。
本文适用对象
初级软件测试人员，或想开拓思路拓展测试范围、提高测试覆盖率的所有测试人员等等。
本文目的
讲述如何快速、简单、有效、有条理地编写一条测试用例，并帮助测试人员从测试用例角度拓展测试思路。
如何简单、快速地
描述（编写）一个测试用例
测试用例的目的在于指扒首导、帮助测试人员按照既定的计划步骤执行测试，并比对测试结果与预期结果是否一致。
对于中大型软件公司而言，测试用例的管理都有既定的规范和工具，如表格管理用例、测试管理软件管理用例（如下图1所示为MeterSphere测试管理软件用例编写页面）等。
但总而言之，测试用例的内容主要不外乎3个部分：前置条件、步骤、预期结果。
那么，对于没有明确地测试管理软件的小型软件公司，或者对于测试人员而言，需要暂时快速地编写一个测试用例或记录测试过程的时候，可以怎么做呢？
推荐一个临时性的用例编写模板：GIVEN...WHEN…THEN。
让我们套用GIVEN…WHEN…THEN的模式来描述下编写用例的大致步骤：
有没有觉得很简单？
让我们再用实际案例，描述下如何用GIVEN…WHEN…THEN模板编写真实用例。以测试访问 http://www.baidu.com 链接这个用例为例1：
使用GIVEN…WHEN…THEN能够简单呈现用例前置条件、执行步骤和预期结果间的逻辑关系，并能清晰地表述一个用例。
那么，什么地方可以用GIVEN…WHEN..THEN这个模板呢？这个模板较之文档用例更为简洁，如下图2所示，对于测试用例提交故障，阐述引发故障的 *** 作方法或故障复现方法，以及故障修复后的验证时都可以使用。
如何使用探索式场景联想法
衍生测试用例
探索式测试更多的是一种测试风格和测试思想，要求测试人员在测试过程中不断思考、发散思维，记录、修改和更新测试方法和测试用例。
场景法则是要求测试人员认真分析测试需求，了解用户使用场景，根据不同的场景进行测试。
而本文讨论的 探索式场景联想法，则是将探索式测试方法、场景法和激改联想法相结合，在已有测试用例的基础上衍生更多的测试用例。
那么，如何使用探索式场景联想法衍生测试用例呢？
由上一节可知，测试用例是指导测试人员在xx预知条件（场景）下，执行xx步骤，预期得到xx结论。
显而可见，通过改变测试用例的预知条件和 *** 作步骤，则可以衍生出不同的测试用例。而这些测试用例包含不同的测试场景和不同的测试步骤。
如下图3所示，为探索式场景联想法衍生测试用例明此判的结构脑图。
改变前置条件
测试用例的前置条件基本包括：硬件资源和软件系统两个部分。
改变前置条件可以从这几方面入手。
以上节的访问 http://www.baidu.com 链接用例1为例，改变前置条件衍生新的测试用例。由于该用例的前置条件较简单，改变前置条件只需改变浏览器类型和版本即可。
由此，衍生的部分测试用例可如下所示：
改变 *** 作步骤
改变用例 *** 作步骤可以从以下几方面入手：插入步骤、删除步骤、改变步骤和重复步骤。
插入步骤
如图3所示，插入步骤又可以分为插入相关联步骤和不相关联步骤。并在插入步骤中增加用户输入。
同样以用例1为例，插入步骤衍生的测试用例可如下：
删除步骤
删除步骤可以分为删除部分步骤或者删除部分步骤中的部分 *** 作。删除部分步骤，又可以分为删除关键步骤和非关键步骤。
例如，以例1为例，删除关键步骤“点击键盘回车键“衍生新的测试用例如下所示：
改变步骤
改变步骤主要涉及步骤顺序的改变和步骤内容的改变。当测试用例具有多个步骤，且步骤间具有关联性和顺序性的时候，改变步骤顺序则会变得很有意义。改变步骤内容主要是改变步骤中用户的输入（包括数据输入、用户 *** 作等）。
以用例1为例，改变步骤内容衍生的用例如下所示：
重复步骤
对于大多测试人员来说，衍生测试用例时更多关注点在于 *** 作步骤的变化。
但是，对于不同的测试场景，重复相同的测试步骤，仍然具有很大的测试意义。重复步骤进行测试能够挖掘不同前置条件（场景）下的故障，亦能挖掘软件在多个重复步骤 *** 作下潜藏的故障。
以用例1为例，重复步骤衍生的用例如下所示：
测试结论衍生测试用例
除了通过改变前置条件和 *** 作步骤衍生测试用例外，还可以根据测试结论中的异常信息，逆推测试场景，衍生新的测试用例。
这个部分更多的需要测试人员掌握探索式测试方法，对测试过程中的软件资源监控信息、错误日志等保持警惕性，挖掘错误信息中的内容，逆推产生错误信息的原因，构建新的测试用例。
小结
本文阐述了一种可以在提交测试故障信息和验证测试故障时使用的快速测试用例编写模板，快速记录测试场景、测试步骤等关键信息。
并在此基础上，简单讲解了基于探索式场景联想法的测试用例衍生方法，可以帮助测试人员借助已有的测试用例拓展新的测试用例，扩大测试范围，提高覆盖率，挖掘更多场景下的软件故障。
转自公众号投稿： https://mp.weixin.qq.com/s/tPB9qhbaKoJX9LhcJDP3eg
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）