测试文档模板推荐(测试用例模板和例子分享)

该范例已经包含一个测试用例的模板。

项目/软件

技术出口合同网络申领系统(企业端)

程序版本

1.0.25

功能模块名

Login
测试文档模板推荐(测试用例模板和例子分享)

编制人 

xxx

用例编号-

TC-TEP_Login_1

编制时间 

2002.10.12

相关的用例

功能特性

用户身份验证

测试目的

验证是否输入合法的信息,允许合法登陆,阻止非法登陆

预置条件

特殊规程说明

如数据库访问权限

参考信息

需求说明中关于“登陆”的说明

测试数据

用户名=yiyh密码=1

操作步骤

操作描述

数据

期望结果

实际结果

实际结果

测试状态(P/F)

1

输入用户名称,按“登陆”按钮。

用户名=yiyh,密码为空

显示警告信息“请输入用户名和密码!”

2

输入密码,按“登陆”按钮。

用户名为空,密码=1

显示警告信息“请输入用户名和密码!”

3

输入用户名和密码,按“登陆”按钮。

用户名=yiyh,密码=2

显示警告信息“请输入用户名和密码!”

4

输入用户名和密码,按“登陆”按钮。

用户名=xxx,密码=1

显示警告信息“请输入用户名和密码!”

5

输入用户名和密码,按“登陆”按钮。

用户名=xxx,密码=2

显示警告信息“请输入用户名和密码!”

6

输入用户名和密码,按“登陆”按钮。

用户名=空,密码=空

显示警告信息“请输入用户名和密码!”

7

输入用户名和密码,按“登陆”按钮。

用户名=yiyh,密码=1

进入系统页面。

8

输入用户名和密码,按“登陆”按钮。

用户名=Admin,密码=admin

进入系统维护页面。

9

输入用户名和密码,按“登陆”按钮。

用户名=yiyh”,密码=1

显示警告信息“请输入用户名和密码!”

10

输入用户名和密码,按“登陆”按钮。

用户名=yiyh,密码=1”

显示警告信息“请输入用户名和密码!”

11

输入用户名和密码,按“重置”按钮。

用户名=yiyh,密码=1

清空输入信息

测试人员

开发人员

项目负责人

3、测试用例设计的误区

1、能发现到目前为止没有发现的缺陷的用例是好的用例:

首先要申明,其实这句话是十分有道理的,但我发现很多人都曲解了这句话的原意,一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去,忘记了测试的目的所在,这是十分可怕的。我倾向于将测试用例当作一个集合来认识,对它的评价也只能对测试用例的集合来进行,测试本身是一种“V&V”的活动,测试需要保证以下两点:

l程序做了它应该做的事情

l程序没有做它不该做的事情

因此,作为测试实施依据的测试用例,必须要能完整覆盖测试需求,而不应该针对单个的测试用例去评判好坏。

2、测试用例应该详细记录所有的操作信息,使一个没有接触过系统的人员也能进行测试;

不知道国内有没有公司真正做到这点,或者说,不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中,对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧,除了自己没人能够执行,写得太详细吧,消耗在测试用例维护(别忘了,测试用例是动态的,一旦测试环境、需求、设计、实现发生了变化,测试用例都需要相应发生变化)上的时间实在是太惊人,在目前国内大部分软件公司的测试资源都不足的情况下,恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人,甚至是测试工程师本身,全然不顾实际的资源情况,一定要写出“没有接触过系统的人员也能进行测试”的用例。

在讨论这个问题之前,我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷,测试活动本身也可以被看作是一个Project,也需要在给定的资源条件下尽可能达成目标,根据我个人的经验,大部分的国内软件公司在测试方面配备的资源都是不足够的,因此我们必须在测试计划阶段明确测试的目标,一切围绕测试的目标进行。

除了资源上的约束外,测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻,那测试用例就没有必要太详细了,文档的作用本来就在于沟通,只要能达到沟通的目的就OK。

在我担任测试经理的项目中,在测试计划阶段,一般给予测试设计30%-40%左右的时间,测试设计工程师能够根据项目的需要自行确定用例的详细程度,在测试用例的评审阶段由参与评审的相关人对其把关。

3、测试用例设计是一劳永逸的事情;

这句话摆在这里,我想没有一个人会认可,但在实际情况中,却经常能发现这种想法的影子。我曾经参与过一个项目,软件需求和设计已经变更了多次,但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措,间接的后果是测试用例成了废纸一堆,开发人员在多次被无效的缺陷报告打扰后,对测试人员不屑一顾。

这个例子可能有些极端,但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的,测试用例文档是“活的”文档,这一点应该被测试工程师牢记。

4、测试用例不应该包含实际的数据;

测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出,没有测试数据的用例最多只具有指导性的意义,不具有可执行性。当然,测试用例中包含输入数据会带来维护、与测试环境同步之类的问题,关于这一点,《EffectiveSoftwareTest》一书中提供了详细的测试用例、测试数据的维护方法,可以参考。

5、测试用例中不需要明显的验证手段;

4、测试用例在软件测试中的作用

1、指导测试的实施

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准,测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中,以便自动生成测试结果文档。

根据测试用例的测试等级,集成测试应测试那些用例,系统测试和回归测试又该测试那些用例,在设计测试用例时都已作明确规定,实施测试时测试人员不能随意作变动。

2、规划测试数据的准备

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据,以及标准测试结果。尤其像测试报表之类数据集的正确性,按照测试用例规划准备测试数据是十分必须的。

除正常数据之外,还必须根据测试用例设计大量边缘数据和错误数据。

3、编写测试脚本的”设计规格说明书”

为提高测试效率,软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书,那么测试脚本的设计规格说明书就是测试用例。

4、评估测试结果的度量基准

完成测试实施后需要对测试结果进行评估,并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例:测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少,等等。以前统计基准是软件模块或功能点,显得过于粗糙。采用测试用例作度量基准更加准确、有效。

5、分析缺陷的标准

通过收集缺陷,对比测试用例和缺陷数据库,分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善,应立即补充相应测试用例,最终达到逐步完善软件质量。而已有相应测试用例,则反映实施测试或变更处理存在问题。

5、试用例编号规则

目的:好的测试用例编号,可以更好的去了解此项用例所针对的模块,也有助于记忆和新用例的增加。

规则:测试用例编号采用“版本 细类 编号”的形式。

备注:其中“版本”为设计此测试用例的软件版本。

“细类”为小模块中的汉字头一个字母,以最多5个字母为标准。

“编号”为BUG用例的编号,以4位为标准,依次递增。

例如:引导系统V2.01版本中,候车点设置,用例编号可以书写为:

2.01_HCDSZ_0001

发表评论

登录后才能评论