功能测试之经典思路---灰盒测试

发表于:2017-1-05 11:43

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

 作者:trhimily    来源:51Testing软件测试网采编

  一、灰盒测试概念
  灰盒测试是一种基于黑盒测试白盒测试之间的测试方法,是业务流程基础上关注系统模块(单位不固定模块是泛指可能是一个或几个类、一个job、一个功能模块、一个处理分支等等)之间如何交互运作的测试方法,灰盒测试既可保证黑盒的关注点又可掌控白盒的内部结构,但不会去对内部程序功能和运作做详细了解,灰盒测试结合了白盒测试和黑盒测试的要素。
  二、黑盒测试、灰盒测试、白盒测试区别
  1、  黑盒和灰盒的区别:
  如果某软件包含多个模块,当你使用黑盒测试时,你只要关心整个软件系统的边界,无需关心软件系统内部各个模块之间如何协作。而如果使用灰盒测试,你就需要关心模块与模块之间的交互。这是灰盒测试与黑盒测试的区别。
  2、  白盒和灰盒的区别:
  在灰盒测试中,你还是无需关心模块内部的实现细节。对于软件系统的内部模块,灰盒测试依然把它当成一个黑盒来看待。而白盒测试则不同,还需要再深入地了解内部 模块的实现细节和各个分支。所以,这是灰盒测试与黑盒测试的区别。
  3、  单元测试和灰盒的区别:
  首先,在进行单元测试时,需要写一些测试代码(行话叫“桩代码”,叫stub)。一般来说,测试代码与被测试代码采用同种语言(比如Java的单元测试通常也用Java来写),且测试代码和被测试代码之间的耦合很紧密。因此,单元测试通常由开发人员来完成的——测试人员的能力未必能胜任。
  其次,单元测试的颗粒度会更细(会细到模块内部的类一级、函数一级),而灰盒测试仅仅到模块一级。
  三、灰盒测试测试流程
  1、  需求分析以及评审
  首先需求评审产品需要提前发出需求,测试先过一遍把疑问记录下,测试过的过程中需要结合接口、UED界面、功能描述进行拉通。以便在讲解需求时能提出业务问题。
  2、  开发控制流程图
  需求评审后,开发需要输出控制流程图,此处说的控制流程图不是概设也不是详设,而是介于这两者之间的一种图形,也就是跟灰盒测试相对应的流程。最好带有简单的功能说明,开发输出的这份文档应该对系统有了一个分析过程,数据字典应该已经输出。
  简单的业务说明:
  1、  测试分析
  在拿到产品的需求文档、UED以及接口文档,开发的控制流程图后可以进行详细的拉通评审工作,评审控制流程图的过程也是重新梳理需求的过程,此过程可以做到产品、开发、测试三方对软件的理解一致,对业务有疑问的地方可以跟产品确认,可以跟开发详细谈,这个过程就是真正做到尽可能早的测试以及返工导致的成本浪费。此时应该已经可以做到从系统整体到局部都有了解。
  2、  测试案例以及场景输出
  结合需求经过模块与模块交互的详细分析,此时可以设计测试案例了,案例设计具体我们把一个系统按照大的功能模块进行组划分;在同一个功能模块下又可区分为:页面测试、接口测试、业务/逻辑测试、场景测试、安全性测试,另外再梳理出联测案例;这样的区分主要是便于条理清晰以及模块复用,比如业务逻辑测试这个组下的案例经过开发控制流程的分析可能判断出在不同模块功能对它都是调用的相同类或对象,那此时这部分案例我只需要写一次在模块后面备注需要用到的模块即可,那不同模块对此部分的相同逻辑的案例只需要执行一次即可,为了保证整体功能的正确性此时场景案例和联测案例是需要在不同模块之间都需要测试的。
  二级目录为功能模块名称:
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号