《笑傲测试》笔记(第三式:仙源何处)

上一篇 / 下一篇  2012-12-09 10:06:19

从大的门类上说,测试能够分成白盒测试黑盒测试。在白盒和黑盒测试的大范畴之内,还有种类繁多的各种其他的测试形式。它们是:自动测试、手工测试、压力测试、协议一致性测试、互操作性测试、现场测试、用户界面测试、文档测试等等。

白盒测试是属于代码级的测试,深达代码内部寻找其内部结构的BUG,而黑盒测试属于系统级的测试,一般要到开发的后期,系统基本稳定之后,从功能和性能方面着手来进行的测试。

(1)白盒测试

白盒测试的优点是从程序的内部结构设计入手,测试能够进行的非常深入。我们都知道一个错误发现的越早,造成的损失就越小,这是常识。

通常的白盒测试,比如单元测试和集成测试,都发生在项目开发的初期,加强这一阶段的测试投入必然能够大幅度降低今后对测试的投入,而且由于测试直接面对代码,理论上来说发现问题的效率和解决问题的效率都应该是有保证的。

白盒测试的缺点是投入人力资源的难度大,执行白盒测试需要测试人员有不亚于开发人员的技术背景和对代码熟悉的程度,而这往往是很难做到的。很多情况下执行白盒测试的任务主要是由开发人员兼任。

白盒测试是一种微观的测试,更注重局部而不是整体。白盒测试有其清晰的适用范围,它适用的场合通常是函数级的单元测试和模块级的集成测试。在此时,往往没有一个成熟稳定可工作的版本供黑盒测试使用,所以白盒测试是唯一可行的路径。

白盒测试常用的方法一般有判断覆盖、条件覆盖、路径覆盖等。

(2)黑盒测试

一般测试流程中的系统测试和验收测试都属于黑盒测试。黑盒测试的优点是:投入小,见效快。黑盒测试更适用于给出全局性的判断。

黑盒测试对技术要求不高,如何在不了解系统结构的条件下系统地计划、组织和设计整个测试过程才是黑盒测试的关键所在。

(3)自动测试(自动化测试

自动化测试的优点:

<!--[if !supportLists]-->(1)      <!--[endif]-->自动化测试的可重复性;

<!--[if !supportLists]-->(2)      <!--[endif]-->执行的速度与效率。

自动化测试的缺点:

1)前期投入比较大(买工具、针对工具的培训、测试脚本的开发)。在投入方面起点高,投资大,见效慢,只有随着测试的进行和重用,自动化测试的成本优势才能逐渐体现,只有当测试进行的轮次高于一定水平之后,自动化测试才有成本的优势。

2)自动化测试过于机械呆板。自动化测试是人事先定义好的,所有步骤和检查点全部要定义的清清楚楚才行。

自动化测试适用的场合:待测软件成熟度(软件比较成熟、功能比较成熟)、待测软件测试周期越大越好、测试数据量要大、待测软件输出类型(输出的结果必须机器可以识别,如数字、文本和图像等)

(4)压力测试(Stress Test

压力测试是指为了某个单一的目的,大强度地重复性的使用软件的某一功能,以期发现该功能在压力条件下的性能指标。当测试软件长时间运行的性能时,可以叫做疲劳测试。当聚焦在某一个特定功能的循环使用时,可以叫做专项测试(Focus Test)。

压力测试的适用场合:

第一种场合,产品上市前对不够自信的功能进行集中专项的压力测试。

第二种场合,是在产品上市后对客户反馈的模糊信息进行集中的测试以精确定位问题。这样的压力测试往往考验着测试人员的灵感和锲而不舍的精神。

(5)协议一致性测试

测试人员按照协议而不完全是开发人员的设计进行测试,测试通过与否的唯一准则是是否与协议的要求一致。协议一致性测试的方法很多,主流的有协议分析仪等测试工具和测试设备,此外还可以组建实际测试网络来验证协议的规范。

(6)互操作性测试(Interoperability Test/兼容性测试

互操作性测试就是验证自己的产品和其他的设备是不是能够正常通信。这种测试的着眼点在于考察不同终端设备之间和终端与服务器之间的兼容性测试。

(7)现场测试(外场测试/前方测试)

现场测试是一种着重考察通信终端设备和不同网络设备之间信号特性相匹配的测试。当待测设备的功能和性能依赖于周围的环境尤其是信号环境时,现场测试往往是必要的。

现场测试不可能做到完备,我们没有时间和金钱去覆盖全部的实际网络。因此做现场测试的一个先决条件是要了解已有网络的配置,选取一些典型的区域,一般原则是:不同厂商基站设备覆盖范围的分界线、不同协议版本的设备覆盖范围的分界线、网络信号覆盖复杂的区域等等。

(8)用户界面测试(UI Test

用户界面被设计的越来越方便。

用户界面测试是用来考察用户界面的易用性和功能的完善性。

衡量一个界面是否足够友好的指标:

<!--[if !supportLists]-->(1)      <!--[endif]-->界面的有效性,指执行特定操作所需要花费的时间或步骤的数目,这个数目越少越好;

<!--[if !supportLists]-->(2)      <!--[endif]-->界面的连贯性,在不同窗口或不同子模块中,用户界面的风格应当是一致,要不然愚蠢的用户们该抱怨不习惯了。

<!--[if !supportLists]-->(3)      <!--[endif]-->界面的传统型,界面的风格和术语是否符合使用者的习惯。

(9)文档测试(Document Test/说明书测试

文档是指那些伴随着产品同时提供给用户的各种使用手册、说明书、须知等。

一般在开发过程中,文档的质量往往被忽视导致文档描述与产品实际不一致的情况,

原因一:文档的开发一般超前于产品,这是因为文档都要有一个排版印刷的过程。

原因二:有的人不认为文档的开发是产品开发的一环,这种忽视往往容易导致文档的测试不够充分。

版权声明:本文出自 hellorenwei 的51Testing软件测试博客:http://www.51testing.com/?578951



TAG:

 

评分:0

我来说两句

Open Toolbar