关于软件测试这东西,玩了四年,仍然没有摸透它的脾气。

  有人说,软件测试是为了发现更多的缺陷,也有人说,软件测试是为了保证产品的质量。都没错啊,一个是从职责的角度来看,一个是从控制的角度来看。

  软件测试,其实就是一个验证的过程,测试人员竭尽所能的折腾一套软件,看它是否符合客户要求的标准,是否能经得起折腾,借以评价产品的质量好不好。不就是这样吗?:-)

  常规的测试理论是遵循了V模型中的V&V过程,也就是Validation and verification。Validation是对客户需求的验证,比如通常所说的验收测试、Beta测试。Verification指的是软件过程中每一次确认活动,包括客户需求确立以后的每一阶段关键产物的评审与测试。

  按照V模型的概念,我们将软件过程分为了客户需求、需求规格、概要设计、详细设计、编码、系统测试这几个关键的阶段。每一个阶段都会有相关的评审与测试,因此,以客户需求为主要依据的测试,我们称之为验收测试,着重于用户需求的验证,通常由客户来做;以需求规格为主要依据的测试,被称为系统测试,着重于对产品综合能力的验证,通常由专业的测试人员来做;以概要设计为依据的测试叫做集成测试,着重于对各级别的接口所进行的验证,通常会由编码人员与测试人员一起完成;以详细设计为依据的测试就成为了单元测试,着重于对代码的最小级别进行验证,通常由编码人员实现。看到这样的一个规则,我们很容易理清,每一个测试阶段,所要测试的对象是不同的,而相应的依据一旦通过了评审,便可以着手进行该项测试的准备。

  相对于之前的每一个关键阶段而言,测试阶段的执行顺序刚好相反。编码阶段只能执行单元测试,只有单元测试通过了,才可以对单元与单元之间进行集成,测试它们之间的接口,这被称之为集成测试。当软件所有的模块完成之后并且通过了集成测试,那么就可以进入系统测试阶段了。这个时候,测试人员摩拳擦掌,跃跃欲试,不找出Bug不罢休。

  然而,到底每一个测试阶段的测试工作是怎样开展的呢?这样的一个过程,我们称之为测试管理过程。每一个测试阶段,都会包括测试计划、测试设计、测试执行这三部分,有些人会把它划分得更细,比如获取测试需求、测试实施、搭建测试环境等。

  测试计划并不是单纯的写一个时间表,它是当对应的作为测试依据的文档定格之后(通常我们叫做基线化)就开始做的,最主要的目的是要告诉你的项目组成员,你要做什么(明确测试目的)?对什么来做(明确测试对象及测试需求)?怎么做(制定测试策略)?要使用什么来做(确定测试资源)?何时做(安排测试进度)?需要注意跟控制什么(估计测试风险,使用规避手段)?

  测试设计是要在测试计划通过了评审之后才做的,主要的产物是测试用例,是将你的测试策略升级为详细的步骤,对你确定的测试对象进行验证,应该要出现的理想结果是什么。当执行测试的时候,人们依据这份文档,会发现实际的结果与预期的不一样,于是便把它判定为缺陷。辅助的测试设计产物还包括测试环境的搭建、测试脚本、测试使用的数据等。关于测试脚本,是要衡量开发成本与预期收益的,不可以为使用了自动化的测试就是测试高手,这是个极其严重的误区。测试脚本的目的是要提高你的测试效率,怎样设计还是依赖于一个人的测试水平,如果片面的追求编程技能,把这认为是测试技能的提高,那么你不用做测试了,去做开发吧。在单元测试跟集成测试过程中会使用较多的测试脚本,是因为这些代码的复用率极高,几乎编码过程中的每天都会执行N遍。而系统测试阶段,由于测试重点不同,测试脚本的复用率也远远达不到前两个阶段的效果,自然就更要慎重了。要知道,一个常规的80/20法则,描述了一个事实,就是80%的缺陷是手工测试出来的,只有20%的缺陷是使用自动化测试得到的。你花费了两个月的时间去做了一套测试脚本,却只需要执行四五遍,发现的缺陷也寥寥可数,毕竟测试中的很多验证点是程序无法实现的。那么,如果使用两个月的人工测试,收到的效果会是天壤之别。你会选择哪一种方式呢?

  测试执行是在必备的代码实现之后才可以做的。拿着文档做设计,却不在真正的环境中执行,就变成了纸上谈兵的赵括。因此,你可以说测试设计是最重要的,我毫不反对,但是,测试执行却是最关键的。只有这个时候,你才能了解软件的质量如何,存在多少问题,需要怎样修复。在这时,才是我们经常说的测试阶段(单元测试阶、集成测试阶段、系统测试阶段)。测试阶段中,缺陷管理变成了重中之重,缺陷的追踪与控制成为弥补软件缺陷、控制产品质量的最直接有效的手段。

  在测试的每个环节都会产生相应的文档:测试计划、测试用例、测试报告,这三份文档成为最基本的资源。一份文档的好坏,关键不在于文笔怎样,而是能否清晰的表达你的意图,并让所有的人员能够了解,使得你所做的工作是可见可控的,不会出现较大的偏差。因此,写文档不是随便完成任务那么简单,它融入了你全部的思想、你的技能、你的沟通水准,是站在一定的高度上来完成的。即使你是个捉虫能手,但你不会写文档,不会把自己的思路清晰的表达出来,这至少能表明你不是个优秀的测试人员。

  我绝对不赞同一个测试新手去写什么测试计划、测试用例。他能把测试报告、缺陷描述写清楚就不错了。试想,谁也不是天生的文档高手,必然是经过千锤百炼、日益积累而成的。先要学会测试,能从测试中找到很多的缺陷,知道测试应该是怎样一种过程,再开始进行文档的修炼。

  我并不认为一个测试人员一开始写测试计划/用例的时候,就能够根据用户需求/需求规格/概要设计/模块设计这类的文档,写出好的东东。毕竟在国内,大多数技术类文档并不是很过关的。因此,我觉得要练习写,就要从一个你比较熟悉的已经成形的软件开始练起。此时你不需要去假想一个软件应该是怎样,而是针对一个实际的软件开始操作,记录你的操作跟你的结果,把它变为你的测试用例。测试计划更不消说,自然是要在你熟悉这套软件,知道怎样去测它的基础上来完成的。

  经过了这样一个锻造,你会明白要怎样展现自己的思路,在新项目中,根据分析或设计文档,你只要考虑它具体实现的是什么,然后根据你的测试思想,你的撰写经验,来完成一份较高质量的测试文档。

  任何一种理论都有着它存在的意义,任何一种开发模式也有它生存的理由。对于测试,也是相同。理论上,测试的设计一定会在它所依据的文档通过了评审以后才开始,可是,到那时你又该如何确定这些文档能为你所用呢?

  当我们从一片混乱,到开始一个正规的测试流程时,我们或许并没有可以借鉴的经验,只能凭着理论带给我们的指导,一步步摸索前进。那么,在实际的过程中,我们如何来进行这场软件过程的革命呢?

  ......

本文转载自51Testing软件测试网,查看全文:http://www.51testing.com/html/21/n-243521.html