zl程序教程

您现在的位置是:首页 >  其它

当前栏目

测试用例设计的价值与误区

设计 价值 测试用例 误区
2023-09-11 14:20:35 时间

测试用例是一系列特定的软件行为,用于验证软件的某特定功能、检查软件能否正确处理某种出错行为、或者检查其他一些软件质量衡量的属性 (如性能、安全、可靠性等)。 一个测试用例是一个正式的文件或记录,描述了测试活动是怎样具体执行的。测试用例设计的目的就是发现缺陷,但是测试用例的用处远远超出发现缺陷。
测试用例文档的一些好处如下:
1、历史借鉴:测试用例的存在要远远超过产品发布。持续工程(Sustained engineering)以及产品未来版本的负责人往往需要借用测试用例来了解测试过什么,以及是如何测试的。测试用例文档和一个有组织的储存系统对长期支持或修订产品的一部分是至关重要的策略。----注----为了便于后来者对于测试用例的使用和借鉴,测试用例设计要尽量描述准确、步骤清晰。
2、测试进展跟踪:通过测试用例文档,可以跟踪一些额外的属性,如测试用例的执行数目,测试用例的通过或失败数目,以及每个功能领域的测试用例总数。 ----注----在测试用例管理系统中要准确且实际地描述用例的执行结果,包括其他必填的属性,便于分期人员从各个属性和维度进行测试过程分析。
3、可重复性:好的测试用例文档可以由任何人在任何时候执行。这同样适用于自动和手动的测试用例。重复准确地执行同样的测试对重现步骤或检测回归是至关重要的。 ----注----测试用例的描述要准确、全面,要能保证除自己以外的测试人员能正确理解和执行该用例。
测试用例文档也有缺点:
1、建立文档的时间:如果建立测试用例文档的时间比运行测试用例所需的时间还长,建立测试用例文档也许就没有意义了。经常有这样的情况,即测试用例只需要在一个单一的环境下执行寥寥几次。 ----注----但是从测试用例价值的角度来考虑,建立测试用例文档却是个不可裁剪的过程。但是,这个缺点会随着用例设计的熟练程度的提高以及用例设计平均时间成本的减小而逐渐减弱。
2、功能变化引起测试用例过期:建立测试用例所需的时间很可能因功能经常变化而增加,以至于失去控制。如果测试用例的功能领域变化频繁,建立测试用例文档就不一定是明智的。这种场景之一是尝试写测试用例以验证用户界面组件。 ----注----功能需求或者设计和实现的变化常常导致测试用例需要调整和修改,甚至有时候修改用例的时间会超过新建用例的时间。因此,在用例设计过程中,保持与设计、开发人员的密切沟通,及时了解功能变化的情况十分必要。否则后期再修改用例的时间成本很大。当然,在软件开发后期,软件需求和设计尽量保持稳定是最合适的。
3、很难设想读者的知识:写测试用例的人往往极为熟悉被测试的功能。这些人常犯的错误是在测试用例中使用术语或缩写,而将来运行测试用例的人很可能看不懂这些测试用例。出现这种情况出现时,测试用例已不再能准确地重复,测试用例也失去了这关键属性之一。 ----注----为了用例便于后来者正常使用该用例,用例设计应尽量避免使用只有自己熟悉的专业词汇和缩写词,或者存在用例描述太简洁但自己能理解的情况。
测试用例设计的误区
创建好的测试用例是一个困难的过程。即使一个错误就可以毁掉测试用例的意图。一些易出问题的领域如下:
1、步骤缺乏: 匆忙建立的测试用例或假设测试用例的一些步骤会被执行而未将它们包括在测试用例里是非常常见的错误, 它造成不能准确地重复。----注----必要的用例步骤不能省,避免在执行用例的时候出现描述不清导致模棱两可的情况发生,从而影响案例执行进度。
2、太多细节: 虽然提供具体和足够的信息很重要,不必要的字词或冗长的解释,会使测试用例难以遵循。仅需包含足够的信息以便精确地运行测试用例。 ----注----太多的细节描述会增加案例设计的成本,适可而止即可。
3、行话太多: 不要以为运行测试用例的人(包括产品技术支持和持续工程)都知道所有你写的缩略语,代号和缩写。阐明任何对整个产品生命周期有价值和必要的信息。 ----注----同上缺点3的注释。
4、不明确的通过/失败标准: 如果运行测试后,不清楚测试是否通过或失败,那测试用例是毫无用处的。----注----测试用例的预期结果一定要准确和清晰。对于测试后存在不符合预期结果的情况,即可判断为失败,全部符合预期结果则为成功。

最新内容请见作者的GitHub页:http://qaseven.github.io/


边界值分析法测试用例设计实例 边界值分析法是黑盒测试的重要方法,本文以一道数位DP算法题为例,自主测试黑盒测试用例,并采用JUnit5完成单元测试。
python接口自动化(三)--如何设计接口测试用例(详解) 上篇我们已经介绍了什么是接口测试和接口测试的意义。在开始接口测试之前,我们来想一下,如何进行接口测试的准备工作。或者说,接口测试的流程是什么?有些人就很好奇,接口测试要流程干嘛?不就是拿着接口文档直接利用接口 测试工具测试嘛。其实,如果只是三五个接口,你可以这么做一个临时的接口测试。但是,如果是上百个接口,或者,你们公司的这个项目,第一次做接口测试,那么,我们还是很有必要严格遵守接口测试的流程。
正交试验测试用例设计及工具推荐 在科研和生产实践中,人们往往要做许多次实验来进行某项研究。实验条件一般包括很多因素,当因素的值不同时,实验的结果也不一样。如果想把每个因素的每个值都要实验一遍,总实验数就等于各因素的值的个数的乘积,而这个数往往很大,超过了可接受的成本。 例如,假设某个实验由A,B,C,D四个因素,每个因素都有10个不同的取值,那么如果想把每个因素都考虑到,我们需要做 10*10*10*10=10000次实验。 为了减少实验数目,我们必须选出那些最有代表性的例子。于是,就要用到了正交表法(Orthogonal Array Testing Strategy)。
【软件测试】测试用例的设计方法 测试用例写的过于简单,则可能失去了测试用例的意义,设计过于简单的测试用例其实并没有真正的进行设计,只是把需要测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测试计划,提醒测试人员测试的主要功能包括哪些而已,测试用例设计的本质应该是在设计的过程中理解需求,检验需求,并把对软件系统的测试方法的思路记录下来,以便指导将来的测试