带上X光眼镜测试软件

发表于:2009-8-06 18:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:51Testing博客转载

  本章讲四个基本测试之中的第四个——动态白盒测试。另三个为静态黑盒(测试产品说明书)、动态黑盒(测试软件)和静态白盒(检查程序代码)。

  一、动态白盒测试

  1、动态白盒测试是指利用查看代码功能(做什么)和实现方式(怎么做)得到的信息来确定哪些需要测试、哪些不要测试、如何开展测试。

  2、动态白盒测试的另一个常用名称是结构化测试(structural testing),因为软件测试员可以查看并使用代码的内部结构,从而设计和执行测试。

  3、动态白盒测试不仅仅是查看代码的运行情况,还包括直接测试和控制软件,动态白盒测试包括以下4个部分:

  (1)直接测试底层函数、过程、子程序和库。在windows中称为API。

  (2)以完整程序的方式从顶层测试软件,但是根据对软件运行的了解调整测试用例。

  (3)从软件获得读取变量和状态信息的访问权,以便确定测试与期望结果是否相符,同时,强制软件以正常测试难以实现的方式运行。

  (4)估算执行测试时“命中”的代码量和具体代码,然后调整测试,去掉多余的测试用例,补充遗漏的用例。

  二、动态白盒测试和调试

  不要混淆动态白盒测试和调试,两者表面上相似,因为它们都包括处理软件缺陷和查看代码的过程,但目标大不相同。

  动态白盒测试的目标是寻找软件缺陷,调试的目标是修复缺陷。然而它们在隔离软件缺陷的位置和原因上确实存在交叉现象。

  执行这些底层的测试,会用到许多和程序员使用的相同的工具。如果程序编译过,可能会使用相同的编译器。

  可能会使用代码级的调试器来单步跟踪程序,观察变量,设置断点,等等。也可能自己编写程序来分别测试需要检查的模块代码。

  三、分段测试

  一般产生高额费用的原因有:

  (1)难以找出导致问题的原因;

  (2)某些软件缺陷掩盖了其它软件缺陷,测试可能失败。

  1、单元测试和集成测试

  解决上述问题的方法当然是一开始就不让它发生。如果代码分段构建和测试,最后合在一起形成更大的部分,那么整个产品无疑会链接在一起。

  在底层进行的测试称为单元测试(unit testing)或者模块测试(module testing)。单元经过测试,底层软件缺陷被找出并修复之后,就集成在一起,对模块的组合进行集成测试(integration testing)。这个不断增加的测试过程继续进行,加入越练越多的软件片段,直至整个产品——至少是产品的主要部分——在称为系统测试(system testing)的过程中一起测试。

  采取这种测试策略很容易隔离软件缺陷。

  在单元级发现问题时,问题肯定就在那个单元中,如果在多个单元集成时发现软件缺陷,那么它一定与模块之间的交互有关。当然也有例外。

  这种递增测试有两条途径:自底向上(bottom-up)和自顶向下(top-down)。

  在自底向上测试中,要编写称为测试驱动的模块调用正在测试的模块。测试驱动模块以和将来真正模块同样的方式挂接,向处于测试的模块发送测试用例数据,接受返回结果,验证结果是否正确。采取这种方式,可以对整个软件进行非常全面的测试,为它提供全部类型和数量的数据,甚至高层难以发送的数据。

  自顶向下测试有点像小规模的大爆炸测试。

  2、单元测试用例

  在进行白盒测试之前,一定要根据说明书建立黑盒测试用例,用这种方式可以真正测试模块的功能和作用。

  如果先从模块的白盒角度建立测试用例,检查代码,就会偏向于以模块工作方式建立测试用例。如程序员误解了说明,于是测试用例就会不对。

  虽然测试用例精确完整地测试了模块,但是可能不准确,因为没有测试预期的操作。

  根据白盒知识增减测试用例时根据程序内部的信息对等价划分的进一步提炼。

  四、数据覆盖

  查看代码决定如何调整测试用例。合理的方法是像黑盒测试那样把软件代码分成数据和状态。从同样的角度看软件,可以相当容易地把得到的白盒信息映射到已经写完的黑盒测试用例上。

  首先考虑数据。数据包括所有的变量、常量、数组、数据结构、键盘和鼠标输入、文件、屏幕输入/输出、以及调制解调器、网络等其它设备的输入和输出。

  1、数据流(Data Flow)

  数据流覆盖主要是指在软件中完全跟踪一批数据。在单元测试级,数据仅仅通过了一个模块或者函数。同样的跟踪方式可以用于多个集成模块,甚至整个软件产品。

  如果在底层测试函数,就会使用调试器观察变量在程序运行时的数据。通过黑盒测试,只能知道变量开始和结束的值。通过动态白盒测试,还可以在程序运行期间检查变量的中间值。根据观察结果就可以决定更改某些测试用例。

  2、次边界

  以下是次边界导致软件缺陷最常见的例子:

  (1)计算税收的模块在某些财务结算处可能从使用数据表转向使用公式。

  (2)在RAM底端运行的操作系统也许开始把数据移到硬盘上的临时存储区。这种次边界甚至无法确定,它随着磁盘上剩余空间的数量而发生变化。

  (3)为了获得更高的精度,复杂的数值分析程序根据数字大小可能切换到不同的等式以解决问题。

  如果进行白盒测试,就需要仔细检查代码,找到次边界条件,并建立能测试它们的测试用例。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号