如何编写好的软件测试用例

上一篇 / 下一篇  2012-03-30 14:53:25 / 个人分类:测试用例

收藏

首先了解什么是软件测试

  软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试,甚至根据需要编写不同的测试工具,设计和维护测试系统,对测试方案可能出现的问题进行分析和评估。执行测试用例后,需要跟踪故障,以确保开发的产品适合需求。是帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程;是SQA(software quality assurance)的重要子域。软件测试的发展,是伴随着软件开发技术的进步,以及软件质量管理观念的形成。软件测试是从软件质量保证过渡而来,软件测试的职位从传统的白盒测试逐渐演变到黑盒测试,从单一的测试岗位发展到众多的测试岗位,如:WEB测试、数据库测试、安全测试手机测试

  学好软件测试

  首先,是重点概念,现在有很多同学说概念或理论自己看书就能解决,主要是没有实际工作经验,其实老师在讲解概念或理论的同时,也在不断灌输软件测试的实质,没有理论上的掌握,你就无法理解一个软件产品怎么测试,为什么这么测试,怎么去考虑测试的方法或策略,软件测试术语是怎么引申来的,其实都在启发你的逻辑思维能力;也在不断的讲授和上机练习中体验软件测试的流程,软件测试的过程,由无形到有形,从无序的知识点到有序的系统的知识体系。

  其次,要有统筹兼顾,全盘考虑的思想,做测试工作不是一个孤立、片面的工作,很多同学都曾说过以前的学哥学姐都传授过经验,测试就那么回事,等到了工作单位,每天就那点活,老是机械式的重复,这些都是我们没有看到或没有意识到的,目前的软件开发与软件测试已不再是小作坊式的规模了,它需要大量的人力来协同工作,每个人的工作都是必不可少的一部分,所以需要在全局上把握,从宏观上考虑,这就是软件测试策略的由来,但是具体测试工作还是微观上的,还需要掌握软件测试的各种方法,另外还要站在项目管理的层面上,从时间上、成本上、效率上、人员分工上、测试团队的能力上、风险上等诸多方面来统筹考虑,要做到从事软件测试工作要从宏观到微观、从全面到局部去认识,不能再盲人摸象或者摸石头过河,要从认识论升华到方法论上;

  最后,要多上机实践,这个是非常关键的一点,多思考,会思考,找出疑难与不解,要从软件测试实践中总结出测试理论,再用测试理论去指导实践,这是个循环往复的过程,只有当你的认识达到一定的高度,你就深刻理解了什么是软件测试,你才会发现原来软件测试是那么的有意思、那么有动力、那么具有挑战性,以后还有很多未知的迷团需要你去拨开,还有更多的知识需要你去掌握。软件测试技术到目前为止,还是一门新兴学科,还没有形成固定的理论体系,还需要很多人的努力,最终将这门艺术变成一种科学。

  、一份需求文档,里边有很多功能点,就会有更多测试点。那么一般用用例设计方法来设计某一模块,具体操作起来是怎样的流程?那些用例设计方法的对象是功能点还是测试点?

  专家分析:用例的根本目的是给测试人员使用,故在设计用例时,若脱离用例本身的使用环境而空空其谈,也就违背了用例设计的根基,直接导致被设计出的仅仅是无效用例而已。

  所以,经常被谈到用例粒度、覆盖率等,虽然提及的次数多,但一直没有明确的标准规范。其很大程度就是因为用例本身的使用环境差异较大,若不进行实际情况分析,就无法得到恰当粒度的用例。

  比如,针对某一模块,如手机电话本进行用例设计,大致流程如下:

  (1)根据电话本需求文档列举所有的功能点。若不能很好掌握功能点划分的粒度,可考虑使用UI结构图代替

  (2)分类各个功能点,主要依据为在实际测试中,各个功能点是否可能被其他用例补充。如,后台运行的功能点需单独分割作为被中断用例的前置环境;被动消息功能点则会被作为中断用例的操作步骤;与其他模块存在接口的功能点则会作为其他模块的补充用例….等等

  (3)根据单个功能点的复杂程度,考虑是否存在需要提取公共用例。如将各个功能点的编辑框提取出来设计单独的编辑框用例。

  (4)使用常规的用例设计方法,通常为等价和边界设计基础用例。若功能点过于复杂,可考虑继续继续分割功能点或使用高级用例设计方法。

  (5)完成以上4步后,使用容错和场景法对设计用例的覆盖率进行验证。

  (6)最后,根据此功能模块在系统流程图中的位置,设计该模块被其他模块调用的补充用例。(若每个模块都能保证完成以上5个步骤,第6步其实可以省略)

  (7)根据设计要求,考虑NFT用例的分布,通常会根据每个功能点单独提取,也可以通过用例优先级控制。(NFT用例分布策略通常取决于公司测试策略,主要适用即可,不需要太纠结于形式)

根据用例设计方法来设计一个模块的测试用例,如果该模块最后有300条用例,那么一般设计这些用例需要多长时间?

  专家分析:排除设计人员本身技术高低或用例管理工具难易程度等其他因素,就用例本真而言,用例设计时间通常被两个因素影响:

  (1)功能复杂程度

  (2)用例粒度(也可以简单理解为用例个数)

  所以,建议比较合理的是自己先试验一次,然后再通过考虑其他因素影响,评估出贴近实际的时间。

  26、在项目紧急,没有需求文档,没有用例评审,又只能独自完成测试的情况下,如何保证测试用例不会漏测呢?

  专家分析:严格来说,这个问题只看”测试用例不会遗漏”已经是伪命题。 至今没有哪个公司敢宣称:咱们的测试用例覆盖率100%。

  所以,这个问题还是回到了实际环境分析出发,建议先分析以下几点得到大致的测试标准:

  (1)客户对产品的质量要求程度。简单可以理解为: 客户使用什么样的方式来验收产品。常见的方式为:3个月试用、1个月客户测试团队复检、1天客户体验…不同的验收的方式在很大程度上决定了产品的预期质量目标。

  (2)产品的功能覆盖和2级交互测试,一般被作为满足产品输出的最低质量保证。单黑盒方面来说,这部分可考虑自己设计功能结构图,然后通过1次功能点分类得到。

  (3)再补充一个常用的用例设计信息:用例设计的时间通常不会超过测试周期总时长的1/3,用例遗漏的部分,最快速的方式是使用探索测试完成。(当然,测试人员或开发人员的实际使用测试也能为补充测试泄露提供一定程度的帮助)

  27、对于一个复杂的java管理系统,功能中主要以增删改查、新增-审批-发布,类似这些重复的功能特性,请问在设计测试用例时,如何保证设计的全面性?

  专家分析:(1)先按照流程图或场景法先清理测试点的思路框架。

  (2)提取多次被重用的子功能测试点单独设计公共用例组。公共用例组保证为子功能的最大合集,并注意分类方式,方便被提取时,可快速删选。需要注意公共用例组的粒度,可能它不仅仅只是一个小功能,比如编辑框;在某些情况下,也可以考虑将一小段流程整个作为公共用例组,如审批过程。

  (3)由于ERP系统完整流程运行一次的时间较长,且可被中断的测试点较多,通常会将交互用例组单独分割出来,然后逐个重新加载到需要模块基础功能测试用例组中。

  (4)NFT的部分,可参考交互用例组的处理方式。

  (5)最后,留下设计用例整个周期约1/4左右的时间评审和完善用例组。

  (6)至于黑盒外的测试用例组,除使用标准的白盒用例设计方法外,在测试数据选择方面,建议考虑以量的方式来补足。毕竟白盒测试的运行速度远远高于黑盒用例。

  28、对于一些特殊的项目,比如说时间短,开发文档不齐全,我们是不是非要执着于去编写测试用例?如果写,时间从何而来;如果不写,如何保证测试的全面和保证测试人员测试的情况?

  专家分析:除了经常涉及的简化测试用例的方法外,针对极限条件(无需求,无测试用例),提供一些相关信息,供参考:

  必要条件:

  (1)测试领导者对测试原理有较深刻认识(至少需要达到裁剪测试流程水平)

  (2)测试团队具备较高的可控性(至少能理解测试领导者每个测试任务的实际内容,并且能”踏实”的完成执行测试)

  (3)测试团队仅限于单个site。(跨Site测试团队合作项目,可考虑每个独立测试团队分派不同的任务)

  测试策略:

  极限测试条件下,首先需要高度保证测试过程的运行策略的易操作性。

  虽然复杂的测试策略的风险更小,但是它需要消耗更多的时间去理清信息和调整。在极限条件下不可能有那么多的时间和资源完成,所以,把握测试的核心,以己之力,牵动整个团队的步伐,达到最终的目标。(这里并不是说决策者不会失误,只是单个决策者比多个决策者的效率更高而已。)

测试执行:

  (1)测试任务每日分派,任务来源与测试计划的细化。(至少需要细化到每个人。当然,如果小组长技能水平较高,可考虑细化到小组)

  (2)每日周期跟踪各个单位任务执行状态(比较合理的周期可考虑,取决于跟踪单位任务执行消耗的时间为决策者1/2的工作总时间)

  (3)每日对当天的bug进行分析,将分析结果转化为测试点分配到各个负责单位。每周进行一次bug分析汇总,修订周测试计划的重点。

  (4)每周进行一次测试状态检查,可选择的方式有交叉测试或核心测试人员抽检。

  (5)测试决策者每日与RD就bug修改方案沟通的时间不少于总时间的1/4。

  (6)至于其他特殊环境或情况,只能说:见招拆招。

  (7)第一阶段为复制。适用于测试新手,基本所有的测试人员设计用例都是从这个出发点开始的。

  (8)第二阶段为重置。通常在测试人员入行半年以后开始,通过对之前人员设计用例的模仿,加上自己对测试功能的理解,运用简单的测试方法,重新设计属于自己风格的测试用例。

  (9)第三阶段为扩展。努力的测试人员在1年后开始进入此阶段,其表现基本与你现在的状态基本一致。此阶段的根本目的是了解和学习更多测试用例设计相关信息和资料,最终掌握它们,周期因为个人的努力程度和机遇,各有不同。列举一些此方面的需要了解和掌握的信息:系统原理、硬件特性、驱动原理、软件设计、市场信息、编码技术、自动化测试技术、自动化工具原理、缺陷管理工具原理….

  其实可以用简单一句话概括:所有与测试相关的技术,均需要了解。

  (10)第四阶段为大同。当在第三阶段收集的信息数量达到满足自身测试的需求后,可开始通过各种信息直接提炼出新的测试点,对第二阶段测试用例的遗漏点进行补足,进一步提升测试用例的覆盖率。

  29、N个输入条件时怎样用正交法设计测试用例?

  专家分析:通常,正交表解决问题分为两类:

  1)测试元素满足标准正交表条件,可直接套用。

  2)当测试元素不满足标准正交表条件时,可先考虑测试元素是否是某个标准正交表的子集。

  如,某个功能有4个测试元素(因子),每个测试元素的水平分布如下:A4,B3,C2,D2 。

  我们可以直接选择L16(5^4)正交表,将仅有的4个测试元素和水平放入表内,得到16组测试用例。

  也可以选择先将某些测试元素的水平先组合再分离的方式来设计。如上述例子使用将A元素的4个水平中的两个组合在一起看做1个水平。然后套用L9(4^3),得到9组用例后,再将A元素组合的两个水平拆开(包含组合水平的用例有2个),得到4个新的用例,最终得到12个用例组成的新用例组。

  30、如果某个项目很大时间很长,写出来的用例都是上千上万的,请问,测试用例用什么样的模板比较好,word还是excel?

  专家分析:条件允许的情况下,建议使用专门的用例管理工具。没有条件的情况下,强烈建议使用Excel而非Word。原因很简单,单是数据统计一项,Word已经捉襟见肘。而且一个excel文件可以包含多个表。

  31、测试前期,需求和设计发生变化,需要去修改原先的测试用例,这个无可厚非,但问题是如果已经开始测试了,发现自己写的测试用例部分不符合需求与设计、发现可以新增一些测试思路、用例。请问:在这种情况下,我们还要去修改、新增用例?时间从何而来?用必要补充已经测试的用例吗?等项目测试完了,有补充的必要吗?如果项目一个接着一个,时间问题要如何解决?

  专家分析:若用例与需求完全不符,需立即修改。若用例存在遗漏,可先只增加基础功能用例,其他类型用例组有时间再增加。(增加用例的原则,可考虑根据用例的实际用途,如,首先保证关键里程碑用例组的完整性)

  时间问题,可以说有也可以说没有。举个例子,当一个bug的来源不是用例时,即说明此用例有泄露,报完bug后,将bug的步骤作为用例步骤增加到相应模块。也就只是增加了1,2分钟而已。建议举一反三,时间问题其实关键只在于做与不做。若此部分用例后期不再被使用,则可考虑不补充。若后期仍会复用的用例,建议还是早补早好。

  个人认为,项目完了再补不科学,当然项目实在急在不得已的情况下可以后补。但要明白“今天的事明天做”的道理。


TAG: 测试用例

 

评分:0

我来说两句

Open Toolbar