测试用例的书写方式及测试模板大全.docx
《测试用例的书写方式及测试模板大全.docx》由会员分享，可在线阅读，更多相关《测试用例的书写方式及测试模板大全.docx（19页珍藏版）》请在冰豆网上搜索。
测试用例的书写方式及测试模板大全
测试用例的书写方式及测试模板大全
一个优秀的测试用例，应该包含以下信息：
1）软件或项目的名称
2）软件或项目的版本（内部版本号）
3）功能模块名
4）测试用例的简单描述，即该用例执行的目的或方法
5）测试用例的参考信息（便于跟踪和参考）
6）本测试用例与其他测试用例间的依赖关系
7）本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限
8）用例的编号（ID），如可以是软件名称简写-功能块简写-NO.。
9）步骤号、操作步骤描述、测试数据描述
10）预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略）
11）开发人员（必须有）和测试人员（可有可无）
12）测试执行日期
例如以下这个模板：
项目/软件
技术出口合同网络申领系统
程序版本
1.0.25
功能模块名
Login
编制人
xxx
用例编号-
TC-TEP_Login_1
编制时间
相关的用例
无
功能特性
用户身份验证
测试目的
验证是否输入合法的信息，允许合法登陆，阻止非法登陆
预置条件
无
特殊规程说明
如数据库访问权限
参考信息
需求说明中关于“登陆”的说明
测试数据
用户名=yiyh密码=1
操作步骤
操作描述
数据
期望结果
实际结果
实际结果
测试状态
1
输入用户名称，按“登陆”按钮。
用户名=yiyh，密码为空
显示警告信息“请输入用户名和密码！
”
2
输入密码，按“登陆”按钮。
用户名为空，密码=1
显示警告信息“请输入用户名和密码！
”
------------>>>
测试人员
开发人员
项目负责人
=====需求测试用例=======
客户需求列表－需求说明书
开发人员－系统说明书-功能列表
测试人员－－功能点测试列表
1注册功能
1用户可以自动注册
（对比发现问题）
=====接口测试用例＝＝＝
接口A的函数原型
输入/动作
期望的输出/相应
实际情况
典型值…
边界值…
异常值…
接口B的函数原型
输入/动作
期望的输出/相应
实际情况
典型值…
边界值…
异常值…
…
====路径测试的检查用例====
检查项
结论
数据类型问题
（１）变量的数据类型有错误吗？
（２）存在不同数据类型的赋值吗？
（３）存在不同数据类型的比较吗？
变量值问题
（１）变量的初始化或缺省值有错误吗？
（２）变量发生上溢或下溢吗？
（３）变量的精度不够吗？
逻辑判断问题
（１）由于精度原因导致比较无效吗？
（２）表达式中的优先级有误吗？
（３）逻辑判断结果颠倒吗？
循环问题
（１）循环终止条件不正确吗？
（２）无法正常终止（死循环）吗？
（３）错误地修改循环变量吗？
（４）存在误差累积吗？
内存问题
（１）内存没有被正确地初始化却被使用吗？
（２）内存被释放后却继续被使用吗？
（３）内存泄漏吗？
（４）内存越界吗？
（５）出现野指针吗？
文件I/O问题
（１）对不存在的或者错误的文件进行操作吗？
（２）文件以不正确的方式打开吗？
（３）文件结束判断不正确吗？
（４）没有正确地关闭文件吗？
错误处理问题
（１）忘记进行错误处理吗？
（２）错误处理程序块一直没有机会被运行？
（３）错误处理程序块本身就有毛病吗？
如报告的错误与实际错误不一致，处理方式不正确等等。
（４）错误处理程序块是“马后炮”吗？
如在被它被调用之前软件已经出错。
…
=====功能测试用例=====
功能A描述
用例目的
前提条件
输入/动作
期望的输出/相应
实际情况
示例：
典型值…
示例：
边界值…
示例：
异常值…
功能B描述
用例目的
前提条件
输入/动作
期望的输出/相应
实际情况
……
======健壮性测试-容错能力/恢复能力测试用例=====
异常输入/动作
容错能力/恢复能力
造成的危害、损失
示例：
错误的数据类型…
示例：
定义域外的值…
示例：
错误的操作顺序…
示例：
异常中断通信…
示例：
异常关闭某个功能…
示例：
负荷超出了极限…
======性能测试用例=======
性能A描述
用例目的
前提条件
输入数据
期望的性能（平均值）
实际性能（平均值）
性能B描述
用例目的
前提条件
输入数据
期望的性能（平均值）
实际性能（平均值）
……
=====界面测试用例－界面检查表=======
检查项
测试人员的类别及其评价
窗口切换、移动、改变大小时正常吗？
各种界面元素的文字正确吗？
（如标题、提示等）
各种界面元素的状态正确吗？
（如有效、无效、选中等状态）
各种界面元素支持键盘操作吗？
各种界面元素支持鼠标操作吗？
对话框中的缺省焦点正确吗？
数据项能正确回显吗？
对于常用的功能，用户能否不必阅读手册就能使用？
执行有风险的操作时，有“确认”、“放弃”等提示吗？
操作顺序合理吗？
有联机帮助吗？
各种界面元素的布局合理吗？
美观吗？
各种界面元素的颜色协调吗？
各种界面元素的形状美观吗？
字体美观吗？
图标直观吗？
…
======信息安全测试用例=========
假想目标A
前提条件
非法入侵手段
是否实现目标
代价－利益分析
……
假想目标B
前提条件
非法入侵手段
是否实现目标
代价－利益分析
……
======压力测试用例===========
极限名称A
例如“最大并发用户数量”
前提条件
输入/动作
输出/响应
是否能正常运行
例如10个用户并发操作
例如20个用户并发操作
…
极限名称B
前提条件
输入/动作
输出/响应
是否能正常运行
…
======可靠性测试用例========
任务A描述
连续运行时间
故障发生的时刻
故障描述
……
统计分析
任务A无故障运行的平均时间间隔
（CPU小时）
任务A无故障运行的最小时间间隔
（CPU小时）
任务A无故障运行的最大时间间隔
（CPU小时）
任务B描述
连续运行时间
故障发生的时刻
故障描述
……
统计分析
任务B无故障运行的平均时间间隔
（CPU小时）
任务B无故障运行的最小时间间隔
（CPU小时）
任务B无故障运行的最大时间间隔
（CPU小时）
======安装/反安装测试用例============
配置说明
安装选项
描述是否正常
使用难易程度
全部
部分
升级
其它
反安装选项
描述是否正常
使用难易程度
测试的基本原则<->
在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。
这里有一组测试原则：
1、所有的测试都应追溯到用户需求。
正如我们所知：
软件测试的目标在于揭示错误。
而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2、应该在测试工作真正开始前的较长时间内就进行测试计划。
测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。
因此，所有测试应该在任何代码被产生前就进行计划和设计。
3、Pareto原则应用于软件测试。
简单地讲，Pareto原则暗示着测试发现的错误中的80％很可能起源于程序模块中的20％。
当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4、测试应从“小规模”开始，逐步转向“大规模”。
最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
5、穷举测试是不可能的。
即使是一个大小适度的程序，其路径排列的数量也非常大。
因此，在测试中不可能运行路径的每一种组合。
然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6、为了达到最佳效果，应该由独立的第三方来构造测试。
“最佳效果”指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。
7、不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现.
测试的基本原则<二>
1．应当把“尽早和不断的测试”作为开发者的座右铭
2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
软件测试从零开始
－－－－－－－－－－－－－－（威哥）51testing
本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。
鉴于国内的软件开发、测试不规范的现状，本文为软件测试新手提供了若干个软件测试的关注点。
【关键词】软件测试、测试用例、测试需求、测试结果分析
引言
几年前，从学校毕业后，第一份工作就是软件测试。
那时候，国内的软件企业大多对软件测试还没有什么概念，书店里除了郑人杰编写的《计算机软件测试技术》之外，几乎没有其它的软件测试相关书籍，软件测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测试一无所知。
不过，在正式走上工作岗位之前，公司提供了为期两周的系统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意义。
现在，我继续从事软件测试的培训与咨询服务，在这个过程中，亲眼目睹了很多软件测试新手面对的困惑，他们初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。
下面针对上述情况，给出若干解决办法。
1、测试准备工作
在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。
如果你把这个问题提给项目经理，他往往会这样回答：
“发现我们产品里面的所有BUG，这就是你的工作目的”。
作为一名软件测试新手，如何才能发现所有的BUG？
如何开始测试工作？
即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。
该从何处下手呢？
2、向有经验的测试人员学习
如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！
你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。
其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方式固化到流程中。
如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！
你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。
这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。
3、阅读软件测试的相关书籍
现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。
可以到或者等网络购书的站点查找软件测试相关的书籍。
目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。
4、走读缺陷跟踪库中的问题报告单
如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如ClearQuest、TestDirecter等工具，还是采用的Bugzilla、Mantis等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。
缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。
一般来说，缺陷报告单中最关键的几个部分包括：
第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。
通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。
这是迅速提高软件测试经验的好方法。
5、走读相关产品的历史测试用例
如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。
走读测试用例也是有技巧的。
测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。
“测试用户登录的功能”是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。
因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。
通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。
总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。
6、学习产品相关的业务知识
软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。
这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。
因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。
如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。
7、识别测试需求
识别测试需求是软件测试的第一步。
如果开发人员能够提供完整的需求文档和接口文档，那固然好。
可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。
如果开发人员没有提供软件需求文档，那该如何是好？
下面给出几个有效的方法：
8、主动获取需求
开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。
因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。
一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。
此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。
当拿到相关的资料后，从哪些方面分析需求？
如何与开发人员交流需求？
其实，只要把握需求分析的几个关键的点就可以解决问题：
输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析：
软件输入：
与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。
在测试用例设计中，这部分内容作为测试用例输入的依据。
处理过程：
描述对输入数据所执行的所有操作和如何获得输出的过程。
测试人员了解处理过程即可，在测试过程中发现BUG时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。
软件输出：
描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。
在测试用例设计中，这部分内容作为测试用例的预期输出。
性能要求：
与该需求相关的性能要求，比如“插入ATM取款卡后，3秒钟内弹出提示用户取款的图形界面”。
3秒钟这一限制，就是对需求的基本性能要求。
运行环境：
软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。
9、确认需求的优先级
确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。
如果软件公司有规范的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。
但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？
如果是这样，需求的优先级只能由测试人员完成了。
10、加入开发小组的邮件群组
测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。
如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。
如果没有变更控制，那就要采用其他的土方法了。
如果公司里面有自动化办公系统，也许采用的是LotusNotes系统，也许使用的是E-mail系统，测试人员应该加入到开发人员的邮件群组中。
当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。
即便公司里面有了软件变更控制流程，加入到开发邮件群组也是一个很好的习惯。
11、与开发人员为邻
建议测试人员与开发人员为邻。
我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。
不管开发人员有什么样的活动，测试人员都能第一时间获得信息。
无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。
一般的公司内部都存在部门墙，良好的人际关系是打通部门墙的手段之一。
向领导建议测试人员与开发人员为邻，这很必要。
A测试用例设计
测试需求收集完毕后，开始测试设计。
测试用例是什么？
测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
设计测试用例需要考虑以下问题：
测试用例的基本格式
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。
用例编号：
测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：
PROJECT1-ST-001，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。
定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题：
对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。
比如“测试用户登录时输入错误密码时，软件的响应情况”。
重要级别：
定义测试用例的优先级别，可以笼统的分为“高”和“低”两个级别。
一般来说，如果软件需求的优先级为“高”，那么针对该需求的测试用例优先级也为“高”；反之亦然，
测试输入：
提供测试执行中的各种输入条件。
根据需求中的输入条件，确定测试用例的输入。
测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤：
提供测试执行过程的步骤。
对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果：
提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。
如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试
升级会员 