小白成长建议(6)-测试的灵魂-云层

用例设计与管理

如果前面说的缺陷管理是作为测试最基本的要求的话,那么用例的设计与管理就是真正成为测试工程师的核心技能。

为何说用例设计与管理是测试工程师的核心技能的,而不是大家所关注的什么技术方向。首先技术方向是手段,但是任何的技术手段都是为了测试目的而服务的,如果这个目的出了偏差,那么所有的手段都无法达到预期的目的,或者就算达到了目的也并没反馈你所希望的效果。

例如我们需要测试登月车在月球上能否正常工作,那么你拿什么技术去测试呢?本质上还要换个角度从测试的思路上改变,在地球上模拟一个类似月球的环境。

那么测试用例的测试与管理主要分为下面三块:

1.测试用例的格式

2.测试用例的设计

3.测试用例的管理

测试用例的格式

用例的格式其实并不是非常复杂的东西,但是这里提出来还是希望和上一章的缺陷同样的概念,就是用例写作时候的要素。

相对缺陷看不懂来说用例更容易看不懂,一个没头没尾的文字让别人看了完全不知道想说明啥或者到底对错在哪里。一般功能型黑盒测试用例由7个要素组成,主题-预置条件-输入数据-操作步骤-预期结果-实际结果-优先级,他们规范了用例的组成部分,以便有效地避免歧义性等问题。对于一个用例来说最重要的就是要让执行的人看了之后知道:

1.到底怎么操作

操作的步骤是一个相当复杂的东西,因为它涉及了操作步骤、后台环境,很多缺陷不能重现或者不能准确定位都和操作的背景有些关系。整个用例不能有效的完整的重现制造缺陷的流程,测试的目标不是很精细,就会导致一个用例对应了大量的覆盖点。

2.怎么算是错误

作为缺陷提交的参考基础,错误的判定标准,也就是期望值是非常重要的。通过前面的测试用例操作过程后,到底什么结果算是正确的,必须要非常明确正向的表达。而中文在这里又具备一点二义性,在表达上就会更加容易出问题。

这里需要重新强调一点,执行用例的人未必是写用例的人,写用例的是设计人员,执行用例的是执行人员,设计人员必须要保证执行人员能够按照自己的思路准确的完成测试。

测试用例的设计

测试用例设计是测试设计人员从写好基本步骤的基础上更深层次的要求,所谓的测试用例的设计只是通过某种方法准确的覆盖被测对象的各个方向角度,达到一定的覆盖率,从而提高软件质量的手段。

为什么要使用测试用例的设计方法呢?首先我先举个简单的例子,就是当你要出门旅游,你要考虑你需要携带的内容,有哪些呢?(这里大家可以先思考2分钟想想)然后就会出现一个问题,就是每次出门到了景点总会遇到点问题,然后发现少带了点啥,慢慢的多来几次就会做这样的一件事情,写一个外出携带物件表。

1.重要证件(护照、身份证、机票、手机、钱包、银行卡、现金等)

2.必备生活用品(充电器、剃须刀、毛巾、换洗的衣服、睡衣、拖鞋等)

3.别的(雨伞、地图、紧急联系人、部分急救药物等)

4.出门前家里要检查的内容(水电气、门窗)

以后每次出门都按照这个流程检查一遍,那么就不太会出现因为遗漏而导致的某些意外了,特别是经过多次的反复测试后会发现这个用例会越来越完美。

同样对于软件来说也是这样的,直接每次测试前空想一下哪里要测试,这个效果会非常的差,很依赖于当时设计人员的状态和经验。通过科学的方法可以帮助我们有效的将测试用例的设计从感性思考变成理性设计,比如上面写得出门常备内容其实就用到了等价类的方法来进行分割。

关于测试用例设计方法我这里就不具体说明了,大家可以自己上网搜索一下,我这里做一点点补充就是,无论是黑盒测试用例设计方法还是白盒测试用例设计方法,本质上都是从各个角度有效的覆盖其各个分支流程。在做测试用例设计的时候如果能做到黑盒用例设计能看到白盒,白盒用例设计能看到黑盒,那么就非常厉害了。

测试用例的管理

既然前面我们都提到了测试用例的设计,那么接着就会涉及到管理的问题。那么用例的管理到底管理什么呢?首先用例是有层次的,用例设计其实分两部分(用例分析,用例设计),用例分析指从某一块入手(先用等价类切,可以用软件质量模型或者别的巴拉巴拉的方式),得到了每一类后再对这一类进行详细的设计覆盖这一类情况下的各种分支。这样说吧我有一个页面有一个登陆功能,那么登陆功能我可以从安全性考虑这就是分析,安全性下面会有注入型攻击,这还是分析,那么到了设计做什么呢?开始根据注入的不同输入来覆盖过滤机制证明这类注入都是不可行的。

在上面这些内容中,就涉及到了层次管理,大家所用的所有测试管理工具中对于用例管理都提供了层次管理的功能(有点需求管理的感觉),关于需求和用例的关系我们等到需求部分再来提。我们通过工具将用例进行层次化管理,这样就可以分门别类,进行维护统计分析,最终得到覆盖率的数据(在系统测试中一般是用例对需求的覆盖)。但是这里我也要补充一句100%的覆盖率并没有什么太大的意义,因为针对需求的100%覆盖并不能代表什么,一个需求一个用例是没法保证质量的,要做的好是能做到系统测试用例跑出白盒覆盖的效果。

用例的设计与管理其实是一个很大的话题这里寥寥几笔也只是将我心中的一些主干说了出来,而要做好这块事情没有1-2年的业务和技术背景是不太可能的。虽然大家都会觉得写用例不是什么技术,但是这却是做测试最厉害的技术。

测试用例是测试人员的灵魂,切莫为了项目进度及个人态度等原因而忽视了测试用例的重要性。设想一个人连灵魂都没有了,那还能留下点什么呢?

时间: 2024-10-07 11:09:56

小白成长建议(6)-测试的灵魂-云层的相关文章

小白成长建议(8)-知己知彼-云层

需求管理 需求管理我放在了理论的最后一部分来说,也是我觉得最难的地方.需求管理的难在于它对测试很重要但是又离测试工作很远.在前面我们说过用例,特别是系统测试用例非常依赖于需求文档,因为用例的期望值也就是最终结果,是通过需求来确定的.所以用例是否正确其实很多时候依赖于需求是否正确. 记得有这样一句英文非常的经典: Are we build the right product? Are we build the product right? 这里可以很好的说明到底用例重要还是需求重要.优秀的测试人员

小白成长建议(1)-深思熟虑-云层

前言 在群里有很多人问我这个问题,我是个小白怎么能够进入软件测试这个行业,今年本来我也准备写点关于入门的内容,于是这篇连载就诞生了,估计章节应该会超过20章,每章大概2000字左右,希望大家能够喜欢. 测试工作 在第一章我觉得首先应该谈的就是当你准备进入测试工作的时候,你应该先问自己几个问题: 1.我了解测试工作么 2.我适合测试工作么 3.我能做好测试工作么 因为选择第一份工作是很重要的,当然如果它是你转行之作也是非常重要的,因为只有在一个相关行业有一定的沉淀和积累,那么才能让这个工作变得有成

小白成长建议(7)-蛛丝马迹-云层

配置管理 从某个角度来说,我一直觉得配置管理才是软件开发的最基本内容,注意这里我说的是软件开发的基本,不是测试!那么和测试有啥关系呢? 在解释这个问题前,我还是想先聊点别的,最后大家自然就知道答案了.配置管理到底是啥,简单来说就是版本控制和回溯,虽然这个概念说出来其实不太对,但是对于大多数情况来说确实就是这么回事. 在配置管理这个话题上可以说的很大,但是也可以说的很小,我觉得这么抽象的一个理论还是用个简单的例子来说明吧. 图书馆大家都应该知道,如何保证图书馆内的书被有效的借阅.订正.标记?这个和

小白成长建议(5) 缺陷与管理-云层

缺陷管理 缺陷管理是最开始也是最基础的测试必备技能.在工作了很多年后仍然会发现大量的测试人员没有办法合理的做好缺陷管理. 在我眼中的缺陷管理包含以下几层概念: 1.缺陷的描述 2.缺陷的定义 3.缺陷的跟踪 4.缺陷的度量分析 也许你觉得作为测试提一个缺陷很简单,但是要提一个好的缺陷其实是非常难的.在这里其实还有个隐藏的属性,叫做缺陷的概念,也就是说什么是缺陷? 一般来说缺陷有两种情况,一个是违反了所谓的规则,还有一种是我们无法接受这样的情况.比如对于美来说,每一个人心目中都有一种对美的定义,你

小白成长建议(4) -从头开始-云层

测试入门 从这里开始我们正式来谈谈关于具体的测试技术,我先列一下目录,以便大家知道后面几章的内容: 1.测试基础及测试方法 2.缺陷管理 3.用例管理 4.配置管理 5.需求管理 6.单元测试 7.集成测试 8.系统测试 9.自动化测试 10.性能测试 这些是我觉得比较基本所需要知道的测试技术,而相关的一些开发.数据库.环境搭建等都应该在这之前基本具备的,我也不专门写点啥来解释了. 首先我们先来谈一下所谓的测试基础和方法. 测试基础 其实一说到测试基础能谈的东西特别多,但是理论性又很强,让我消化

小白成长建议 (3)-看书和选书-云层

测试入门 在有了对这个行业的一个了解及需要具备哪些基础后,我们就来谈谈测试入门.那么测试到底是啥,简单说来就是通过一定有效的方式来模拟用户运行软件,证明软件能够达到一定质量水平的手段吧.这里我用的话语很通俗并不规范,其实大家也不用太在意测试的某些概念具体怎么说,总的来说就是better more better,说到这里我想先提一下关于大家总关心的测试入门看什么书的问题. 怎么看书和怎么选书 在谈具体推荐什么书前,我不得不再好好的把怎么看书和怎么选书说一遍.其实在我看来书本无好坏,一本书不可能烂到

小白成长建议(2)-扎实基础-云层

测试基础 不知道在看完上一章之后你是否还有勇气继续选择测试这个工作,或者对这个工作有了一定的了解.那么在进入正题前,抱歉我还是要再做个铺底.就是我们的第二章测试基础. 测试需要基础么? 需要,很需要,甚至我觉得都需要一点点天赋!就像不想做厨师的会计不是好司机一样,测试是一个非常需要跨行业跨领域跨传统思想的工作.想要做好测试,那么你必须啥都会一点,而且为了说服别人,你还得啥都比别人厉害点,这样别人才会服你. 比如你告诉别人乱穿马路是不对的,这是没用的,因为别人不一定明白道理.如果你让他作为司机感受

小白成长建议--小白如何提问

人类最高级的智慧就是向自己或向别人提问——苏格拉底. 我曾经思索过一番有关提问与回答的不同.在我看来,回答是面向过去的,是被动的,是过去式:而提问则是面向未来的,是主动的,是现在式,它往往意味着对现状的不满,意味着有新的发现.千百年来人们都对苹果落到地上习以为常,但牛顿却对此提出了疑问,也就在那一刹那间,一个崭新的世界已经展现在了他的面前.所以说,好的提问往往比答案更有力量,更能给人以启发! 长期在各个QQ群和网站社区上回答问题,久而久之就开始不太淡定,按照某些人的说法就是“你对我这样一个新人怎

小白成长建议(9)-苞丁解牛

单元测试 估计对于小白来说,一提到单元测试就是开发.开发.开发,好深奥.好难.但是我想说,单元测试可能是所有测试中最简单的了,想反系统测试可能是最难的,只是所谓的开发门槛让测试人员有些抵触而已. 为何说单元测试是最简单的内容呢,我们先来看一个例子: 有一个人去医院看病,然后医生问了一下病况后直接让你先去抽血,根据抽血的结果告诉你你是感冒了,给你开了一些感冒药.在这个情况下你觉得医生有多少的技术在里面? 另外一种情况,还是去医院看病,病人刚进来还没说话,医生就已经准确的说出了病人的病情和对应的诊疗