测试工作看起来比较简单,但是实际上并不是如此容易,它所涉及的内容是很多,而且还要充分地认识到它前期的工作和后期的工作。其中前期的工作就是非常仔细的测试设计和围绕测试设计所选择的恰与其分的测试用例。另外这里的所说的后期工作就是如何对问题进行分析判断问题在各个部分中存在和分布的情况,这是一件不容易的事情。这需要充分的测试实战经验和能够合理地、有序地对问题进行分析。这需要有充分的数据资源。基于以上情况,我将综合五年来我在测试工作上经验和行动。根据测试部数以百计的测试文档。较系统地综合归纳测试的工作。
总述
前期的测试文档的设计主要集中在测试大纲的编写、测试设计(包括测试方法的挑选)的编写,然后根据测试设计的要求从测试用例库中精心地挑选具有典型的用例。
对测试前期的文档设计的要求就是能够根据产品总体设计和产品详细设计中得到要测试的东西,因为软件测试的路子千千万万条,首先绝对不能保证面面俱到,另外在测试中重复性的路径测试过多。所以即要保证通过测试设计做到能够抓住重点,而且还要保证撒出的网的比较大。因此在前期工作中建立的测试大纲和测试设计看起来的就是很重要的,可以说它是指明了方向。(它们二者之间的关系将在图1)。
测试大纲和测试设计建立出来后,只能说前期测试工作的骨头架子已经打起来。下面就是要求填血肉的了,这就是在测试设计上选择能够适应的测试用例。我认为在前期文档编写中测试设计的编辑是最耗时间和精力的。诚然编写一个很好的测试设计是很不容易的,但是难度之二就是选择测试用例。为了缓解工作压力,我希望能够建立一个比较充实的测试用例库,库中可以进行有效分类地保存。当要对一个产品的某一部分使用一种测试方法,可以很容易寻找到相应的测试用例。
图1
后期的文档的编写将重点集中在对数据的处理和统计,如将对测试过程中所发现的问题进行系统的整理和统计(主要是通过各种数据统计图表进行分析)。另外还要对本次测试中的测试用例进行统计和入库处理。这一点是非常关键,因为在后期的文档编写就是要通过进行数据的各种统计来找出测试中的教训和经验。
另外后期的文档的编写工作还可以很好地支持测试各项的工作顺利地开展。如测试用例库的建立可以很好地支持的测试的前期文档的编写,并且将给测试人员给予极其大的帮助。测试问题库的建立和使用,不仅可以给测试人员极大的帮助,而且它也成为了测试用例库的很好的素材,并且将有助于开发人员的工作(即可以起到跟踪问题的效果)。
测试问题库和测试用例库的建立和使用。关键就是在于这两个库的数据一定要详实。将每一种情况的都要做到分类量化。便于进行各种数据统计。
在数据统计中,常用的方法主要就是表格,典型的分析表格就是柏拉图。另外现在比较的重要的图表分析方法就是问题分析趋势图。建立问题分析趋势图对于监管测试工作是一个非常好的方法。做到这一点不是一件非常容易的事情。对监管人要有很好的要求。
后期文档的管理和控制参照图2
图2 测试前期的文档——测试大纲
测试大纲可以说一份指导性的文件。它所起到的作用可以说有以下两种作用。首先保证在测试中所要测试的面基本上可以起到完全覆盖的作用。其二是大纲中的内容不仅是首先要求填写的,有一部分是要求使用者(即为测试者)自行填写的。
测试大纲的建立和使用是从1998年开始的,经过多年的使用后,发现原先希望它能够起到的作用的并没有达到。2001年,测试部着手对测试大纲进行仔细地修改。
后来发现,在建立了测试规范后,测试大纲的作用逐渐明朗起来了。将它和具体的测试设计分家和结合。完成了测试大纲作为总纲地位的确定。
对于测试大纲的设计要求来说,要求不一定很详细。要求的就是面面俱到,对于每一个面做到点到为止。保证当使用测试大纲时,不会出现遗漏的现象。
新版的测试大纲在设计上和思想的考虑,比以前的测试大纲有了突破。
1、标准化处理:标准化的处理,是对测试文档建立和管理的基本要求。测试大纲的每一条测试路径都要求进行标准管理。
2、加入测试方法:在测试大纲中加入测试方法的描述,即在测试某一部分时,也要主要地说明它的测试方法。
3、权值的加入:在测试大纲中每一条测试路径后面都要求加入必要的权值。而且要求在加权值时要对各种参数都要有要求,必须在进行一次主要的测试时,要都要修改权值。而且最好是两次。头一次是预期值,第二次是测试完后的实际权值。这样可以进行合理地比较。现在看起来这是极其重要的(加权值的方法非常重要。在下面将较完整的描述。
测试大纲应该是一种常新常换的文件,如在权值的设定上,每一次运行系统程序或应用程序,所对应的权值都会发生相应的变化。
测试大纲在设计上应该注重在简洁性、实用性。能够方便测试人员使用。内容结构如下:
图3 测试前期的文档——测试设计
测试前期中最重要的文档就是测试设计,这里先简单地说明为什么要在黑盒测试中考虑到做到测试设计。首先将测试操作分为两部分,这两种方法都是相对极端的。第一种方法就是测试凭着自我感觉进行。进行这种测试时不需要打腹稿,想到哪里就测试到哪里。第二种方法就是测试的每一步骤都要设定下来并加以文字说明,如象记录到打开一个记录,然后光标定位到某一个字段,输入一个字节。
可以说这两种方法都存在各自的误区,第1种方法可以说盲目性太大,并且重复性和遗漏性也比较高。第2种方法在测试设计上又过于僵硬和死板,操作起来没有更好地变通性。
所以基于以上两种情况,测试设计就出现了。可以说它是在考虑了上述两种情况之后,所考虑的一种变通和调节。我们要从测试设计中体现一种思想,这种思想就是在进行功能测试中,我们即要追求测试深度的渐进,还要考虑到测试广度的延伸覆盖的程度。
从另一个方面来说,测试设计的编写实际上使对测试大纲中某一部分的放大。可以说测试大纲的前期的全部编写可以由测试主管或者测试项目负责人来进行。而测试设计可以分配给各个测试人员来编写,谁来负责一部分就由谁编写相关的测试设计。
对编写测试设计的要求是比较高,主要要求如下:
1、要求在编写相关的测试设计,要具有一定深度和较大的面。一定的深度的意思就是要切中要害。通过仔细地研究各种技术文件和被测软件,对自己认为可能会出现问题的地方做到更深一层的思考和判断。较大的面就是所铺开的网尽可能的大。不要存在遗漏,这样做也可以避免重复性操作的产生。
2、对所了解的测试方法也要有要求,测试大纲中的测试方法只是相当于一个概念性的。而在测试设计中所要求的测试方法就要比较具体。比如在时钟测试中,在走时的精确度的测试,可能就要标注上要用的方法就是比较法。各种的测试方法有很多种,在黑盒测试中主要的测试方法就有:等价类、边界值、正交法和判定表这样的方法。
3、在测试设计中对于除了正常的功能测试还需要进行那些特殊的测试,如强度测试、回归测试和安全测试等都必须加以标注。
好的测试设计,可以帮助测试人员理清整个测试的脉络。并且可以很有效地
查找到测试。这是一份非常重要的文档,它也和测试大纲一样,为了更高地寻找和发现到错误,并且在每一次测试中进行修改。
在测试设计中也要求分清测试项目中哪些是重点,这是贯穿到整个测试。测试设计中的深度的意思也是针对该点。没有重点就不能谈到深度的要求。测试设计经过多次地修改,每一次都能够确定相关的重点。测试设计中的重点需要进行二次评审。第一次是在进行实测前的确定重点。第二次确定重点是要在实测后重新划分。第一次的确定主要靠的是经验。
在测试设计中确定各种测试方法,具体到什么地方使用什么样的测试方法,这是极其关键的。在这一点上需要测试人员的经验的培养。
现在以一份较好的测试设计加以说明:
测试设计上的编写实际上就是让测试人员在测试前理清一遍自己的测试思路。这是非常关键的。所以对于测试设计上来说,就要求进行必要的测试设计方面的评审工作。
测试前期的工作文档——测试设计和测试用例库的结合
测试部自2001年4月份就强调测试用例的编写,在目前并没有很好的系统地对测试用例进行研究的情况。目前就是将测试用例全部记录下来。在测试用例比较多的时候,就必须将它象测试问题库一样建立起来测试用例库。测试用例库的具体建立和操作在这里不做过多的说明。
这里想说的就是将测试用例库中的测试用例和测试设计建立相关联的方法。让我们来看看测试用例吧,找出它们之间的规律。看起来针对一个产品的测试用例有成千上万条。但是通过采取测试方法或者测试范围找规律,只有最多不超过一百处具有较相同规律的测试用例。
再看看测试设计,固然编好测试设计,需要的是测试人员的经验。但是如果有一个强大的数据资料库的支持。就可以为建立一个高效率的测试设计节省了很多时间。而且可以保证你所编写的测试设计非常精辟。
比如在选择需要进行安全性测试的情况(即要通过各种正常、异常的操作突破密码的防范)。在测试设计中编写到这一部分时,就可以调出以前对安全性测试的资料。可能就会有十几种供你选择。
测试的强大资料库——测试问题库和测试用例库
测试工作中我们会记录下大量的数据资料。其中宝贵的资料是很多的。我们自己有一个习惯,就是喜欢有书面记录下成绩。当然这是很重要的。但是经过我多年的工作下来。我已经越来越不喜欢用书面记录下记录。因为这些内容如果没有专人来管理。很容易会成为压箱底的东西。
你的资料需要得到灵活的运用。这就需要靠这些手段来完成。因此我建立了测试问题库这一方式来保存数据资料。
测试问题库在许多的高科技开发公司都已经存在。有很多已经实现了自动入库的方式(即当你出一份测试问题报告,测试问题报告中的信息就已经编写到库中了)。
我强调的是在目前要求测试问题库中的信息可以包括很多,并且要记录下来有价值的内容。因为测试问题库建立起来,第一不仅要交给测试人员使用,还要帮助开发人员跟踪问题和修改问题。第二是一个完善的测试问题库还可以为建立问题分布柏拉图和问题分布分析趋势图都有很多的帮助。
从下图中可以看出,测试问题库中包含的信息是比较多的。通过库可以了解到被测软件的一些基本信息资料。有描述的比较完善的问题过程、问题现象和问题分析的内容。同时为了便于跟踪记录,有两个栏位就是为了跟踪问题的发展(特别是对未被改正的问题)。
测试人员通过使用测试问题库,可以非常方便地查询问题,另外可以自己在编写测试文档过程中确定重点的方向。
另外测试问题库的确立和使用,还有更为深远的意义。测试问题库的建立实际上为建立动态地对测试问题的控制和管理打下了良好的基础。
同样,为了配合测试工作的顺利高效的进行,我们要求建立第二个资料数据库,这就是测试用例库。关于测试用例库的重要性的介绍中,前面在简要介绍测试前期的文档和后期的文档作用已经通过图表描述了。
这里说测试问题库的建立是对测试结果的保存和使用。而测试用例的建立就是对测试过程的保存和使用。
这两个数据库极其关键和重要,我从事测试工作多年,比较遗憾的事情就是一直在研究对测试工作如何进行有效率的控制,而不是人为地控制。其实现在才发现通过测试问题库和测试用例库的使用就是可以进行有效的控制。
测试后期的工作文档——数据统计图表
在介绍测试两个巨大的数据库的内容时,已经提到可以通过图表描述,那么这里有两种图表加以介绍。
一种的图表中就是柏拉图的方法。柏拉图的内容可以通过一个具体的例子来进行说明。
问题分析的柏拉图的内容是由两个坐标组成的,一个是以柱状图说明在哪些软件模块的问题分步数目。第二个是以线状图来表示出在总的问题量每一个模块所占有的问题的百分比的分布。
通过问题分布的柏拉图可以很容易看出哪些问题是很容易出现问题的地方。柏拉图的作用:第一可以便于可以根据柏拉图进行问题数据统计分析。另外如果正在分阶段地进行对一个大系统的测试。通过柏拉图还可以进行分阶段的问题技术分析。通过每一个阶段的柏拉图来找出这个大系统的问题分布的一般规律。通过柏拉图来分析出高风险的问题区域。这一点是非常关键的。对于在测试大纲中设定权值有非常大的作用。
问题分析的第二中图表的分析就是使用缺陷分析图表。这是一种非常管用的分析图表。它是用来记录在测试过程中的问题的变化(也称‘打开/关闭’图表[打开的意思就是寻找发现问题,而关闭的意思就是修改问题])。
在一个测试过程,关于发现和修改问题都有一定的规律。
这是一个p5v6.80问题趋势图,我们可以把这个图的变化趋势分为三个阶段(上升阶段、中间阶段和平缓(结尾)阶段)。上升阶段就是指刚刚测试产品时,在该阶段会发现大量的问题。累计问题数目趋势线会上升很快,甚至非常陡,这是非常棒的。第2个阶段就是中间阶段。这个阶段就象我们上山一样。有陡然上升的阶段,也有平缓的阶段。造成这种情况的是存在着很多我们在测试中不可预知的东西,属于测试稳定阶段。第3阶段在经历了累计问题数目阶段和测试稳定阶段。被测试的软件基本上趋于稳定。在正常状态下该问题的曲线应该平缓。所说的就是接近直线。当然可能达到这一阶段的时间是可以预计的,或者是不可很好地预计。但是我们可以通过该分析图的下面两条线做出判断。一条线是真实地记录了每一天发现的问题个数,第二条线则就是描述了对这些问题的哪些问题进行了改正。
因为我们知道对问题的改正实际上就增加产生问题的新的隐患。所以每次改正问题后直接的就是在上图中的趋势线出现波动。我们希望的每一次改动问题都不会让趋势图发现很大的波动影响。第二就是在到了第3阶段时下面的两条线都可以逐渐接近横轴。并且没有什么样大的变化。
我们看出在问题分析我们灵活地运用柏拉图和缺陷分析图表分析被测模块的高风险性和在测试过程考察被测的效果。总之一句话,我们通过问题分析,可以更好地保证软件的可靠性。这一点至关重要。
测试后期的工作文档——测试报告和未改问题集
测试报告是组成测试后期工作文档的最重要的技术文档。测试报告主要有五个部分组成:1)测试条件创建的描述;2)柏拉图的画制;3)根据柏拉图进行问题分析,指明高风险区;4)列出未改问题集;5)总体分析评价。
关于第2部分和第3部分在前面已经做了介绍。下面我先说明第1部分和第5部分内容。至于第4部分内容我将单独说明。
第1部分——测试条件创建的描述:在软件测试中,建立一个良好的测试环境。所有在测试中涉及到的条件(包括工具、机器配置、编译环境)以及在相关的企业标准中所涉及到的内容(如指环境测试、强度测试和电气测试)。一个好的测试环境,可以排除掉一些不存在的问题。也为寻找和修改问题提供了便利。我们认为测试环境应该尽可能和开发调试中的环境相类似,甚至相同。
特别如果在测试中测试到专门的情况时,如功耗测试或者灵敏度测试时,在建立测试环境时应该由开发人员确认。其实在建立测试环境时,应该由专业人士认可。
正是由于建立一个良好的、完整的和准确的测试环境是那么重要。那么我们在编写测试报告时就应该将一个你所建立的一个较完整的测试环境系统说明清楚。包括上述所说明的内容(详细的内容可以参照国家软件文档设计标准)。在特定的情况。如在描述测试电气特性的时候,可以将接线图绘制出来。我们希望能够重点注意一下建立测试环境上,并且能够较详细地说明出来。因为上面也说过。出现问题的地方在建立错误的测试环境会有很大关系。关于建立一个测试环境的事情。在后面将详细总结。
第5部分——总体分析评价:请千万不要忽视掉总体分析评价的内容,当你的测试报告快要写完的地方,并且感觉很累的时候。希望你能够在写总体分析评价时能够休息一下大脑。想一想在经过一个时间不短的测试后,如何能够对最终的产品给出一个令人信服的结论。因为总体分析评价的内容可能是在开评估会时就有可能关心的。
现在我们应该认为总体分析评价是最客观的。最好不要存在什么主观的意念。那么如何才能使总体分析评价具有很强的客观性和准确性。我想有应该有两点应该注意就是:
(i) 实事求是,不能够就人论事。把你自己的主观感觉强加在总体分析评价中,特别你自己的喜怒哀乐。当然你也不能受外界因素的影响,力求做到按照既定的原则处理。
(ii) 在要求总体分析评价的客观性中,我想如何要一个总体分析评价客观性,最好的办法就是收集和整理各种客观实际的数据资料。关于收集和整理的客观数据资料。我们已经在介绍数据统计分析中说明了一些。但是我们还有很多方法可以来运用。关于这一点的详细介绍我将在《对各种测试资料的灵活统计分析》一文详细论述。下面我只蜻蜓点水的说明一下。
|