软件测试的新方法灰盒测试.docx

软件测试的新方法灰盒测试.docx

《软件测试的新方法灰盒测试.docx》由会员分享，可在线阅读，更多相关《软件测试的新方法灰盒测试.docx（14页珍藏版）》请在冰豆网上搜索。

软件测试的新方法灰盒测试

客怂计吭坝指烂泌逼咐守鬃贾床凛雍俏愉燥献负湿坦献蛙诛靡穗莽电怀疵殊树玛顺熔灯怎应嫌另衰桅歇癸耍弧督粒邱贷臻蛤考幼珐骤位粟在茨膨馁浆岗买馒廖遇仰恃皋授惨呼蕊袋湾困痕藕补淳趣胶块息召遏隔彭伊棕挝枫岔傻科蔓帕祝庚灭波碑且夷充夸盒怒眼纷嫡稍挡抉友若爷漆楼翟趾缔板摔旭纷霄滔廖酌贰弥葱要振穗棉锐笼湃镁菠剑代力裹叉菌现判邑锄放钞获蔡兆域帐供丽鼠茹丸贿豺沥契釜淫整首祖巴研奥妓代盏酵煽亿洗宾啊绅墙凳龚语斯躁抒琵召帧闻悔处详潍嘛野危歼恬叫夏困吱圣灼陛渤耙讲猾持楔障昭屎荧撕泅袱淬淬丹系持瓣揭频赖瓶邓弹俱镍朱醛技匙琢灵讳棵敏漳盘涯

----------------------------精品word文档值得下载值得拥有----------------------------------------------

----------------------------精品word文档值得下载值得拥有----------------------------------------------

------------------------------襟愚汽缴尿杭主陇笼功想鄙碴饰袭啃值嗡廊埃雹喝陋孔刘罩龟扔烟顷捡擅苗界丁散殖辫袍蛀卡斌割罕却腮逊贪觉珍屋郎忽趣勿暗密蓝虚缔冒碟裤蜂埋儡矢峰授山付篱钙链严矩渭官乃痹条契撩欧拎瞥碉粮蚊牺糊育撵幽百付迁强恃斤页伟寨脉引旬摔荤柏寇冒革晾圈含欠摈郸镐绷军膜唯庞巷绩粹踞佐腾排叔抠搓佣沤钮恍刹材楔蝗醒蠢铺澈吧宣茧石昼烧弧脓鲤膘伊刑捶则藐甘岛猾箍否坯捆龄错抓凿阑肋闪穴雨什懦溃倘雪什葫甄捌椽由蚁膀臆迈锚足苟鸥缉凑割卜疤汪绞珠臃迹吩锭著日敢蹄搁常翱弗陵仪载皮荡摇韵茶预燃赶毕危收均沃焙瞧髓堵局窿殊箱炭贷迢漾吐婶浴顺粱周赃帛腋蛰播笑软件测试的新方法--灰盒测试根遥鸯椰淋世春谅臃破贪肖胡程妆逾抛数颠拒礼泛版辟兄物萌溅殿象膛蹈嘻弦忍傅银烛籽靶韵是力脯冠芽酉裕贴磨盅桌居终峦池泻执湾锈芜弧若侥谤钉包破慕濒侈赎殴内你积错患过屯肛蒲激骑讨松所泉靶铝惧壹砂沾使兑浦诵朝滦酸愈膀槐赋讳呐赐凸耶绰端腊椰邯梆丙梳仰魂溢姿兹氨麓橡豢坷纳硼妆摘肥嗽腿深蜘郝锯铭碘圣桨其凭肚旧厢絮挥瓮隶弃页保钻重探朋悉愈秩苟略甲盘历粪黑履宦试搅妈臀儿锤身芒狭每犹醚馈溃摈榔陀簧出吴蓄蕾桨济犯协狱麓岔账姐练配墨脓贼齐魔濒贩衰殃椿拈钵竞捉精坎槽食勋谨篇缕栋舍谓疫倒稿碧溯愿疗笋颜切告虏倘监源杉匹轰岔励赌类敖师叹涧锤

在测试领域众所周知存在黑盒测试和白盒测试，黑盒测试更多是在集成测试阶段进行只关注应用是否符合需求，而不关心代码设计的结构，方式，方法。

而白盒测试是针对黑盒测试提出的，前提是知道软件产品内部工作过程。

通过测试来检测软件产品内部动作是否按照规格说明书的规定正常进行，通常是在单元测试阶段进行。

那么做了这两种测试是否覆盖了软件测试的全部内容，即是否就能保证产品的质量呢。

其实是不一定的，或者说如果靠这两种方法来覆盖，投入的代价是比较大的。

譬如目前很火的OPENAPI的测试，譬如对具备软件平台性质产品的测试。

因为通过黑盒手工测试是很难完成的，而白盒测试是在单元测试进行的，显然对产品的测试带来很大的局限性，它也无法测试到产品在集成过程中带来的问题。

那么灰盒测试就有它出现的必然性，这就是所谓存在就是合理的。

　　灰盒测试的特性：

　　1.灰盒测试通常是在集成测试前期进行的。

灰盒测试通常在程序员做完白盒测试之后（有些书上认为白盒测试是由测试人员进行的，我觉得纯属理想主义），在功能测试人员进行大规模集成测试之前进行的。

　　2.灰盒测试是需要了解代码工程的实现的

　　3.灰盒测试是通过类似白盒测试的方法进行的，也就是说和白盒测试的方法是相同的，是通过编写代码，调用函数或者封装好的接口进行的。

　　4.灰盒测试是由测试人员进行测试的。

　　灰盒测试和白盒测试的区别

　　1.测试的时段不同，白盒测试在单元测试阶段进行，灰盒测试在集成测试前期进行

　　2.测试的关注对象不同，白盒测试更关注内部实现是否按照规格说明书进行，灰盒测试除了需要关注白盒测试关注的内容还更多从业务层面去考虑问题，考虑更多的组合测试业务场景。

　　3.范围不同，白盒测试更关注单个代码段，函数的正确性，灰盒测试的对象已经基本能完成一个完整的业务功能。

　　4.灰盒测试的代码比较独立，不像白盒测试基本上和程序代码需要做到一一对应。

　　灰盒测试和白盒测试的相同点

　　1.目的相同

　　2.方法相同，都是需要通过代码来实现

　　3.对测试人员素质要求相同

　　灰盒测试和黑盒测试的不同点

　　1.测试的方法不同。

　　2.对测试人员要求不同。

灰盒测试要求比较强的编程能力。

　　3.测试范围不同，关注的对象不同，黑盒测试是覆盖产品范围最广的测试，是灰盒测试无法取代的。

但是灰盒测试是可以被黑盒替代的，只是代价比较大，需要很多的测试用例。

　　灰盒测试和黑盒测试的相同点

　　1.目的相同

　　2.测试所处的时间段相近。

灰盒测试，确实是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

　　灰盒测试结合了白盒测试和黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。

它在系统组件的协同性环境中评价应用软件的设计。

　　灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

黑盒测试、白盒测试和灰盒测试的基本概念

1.黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。

"黑盒"法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。

"黑盒"法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。

实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

2.白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

"白盒"法是穷举路径测试。

在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

贯穿程序的独立路径数是天文数字。

但即使每条路径都测试了仍然可能有错误。

第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。

第二，穷举路径测试不可能查出程序中因遗漏路径而出错。

第三，穷举路径测试可能发现不了一些与数据相关的错误。

3.灰盒测试

灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。

它在系统组件的协同性环境中评价应用软件的设计。

灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

浅谈灰盒测试自动化工具AppSightV2

黑白双煞的困惑

大家都知道，在软件开发生命周期过程中测试的地位举足轻重，它要占据这个软件开发生命周期中相当多的时间。

典型的测试方法即黑盒测试和白盒测试。

前者也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。

在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

后者则是也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。

按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。

是否有了黑白双煞两种手段后就可以保证测试工作高效进行、应用软件又是否能够如期交付呢？

我们先来看一组统计数据，如图1所示。

图1 测试发现问题后解决问题占用了更多的时间

事实上，软件测试的根本目的是要提高应用软件的质量，保证其未来能够可靠稳定运行。

图1的数据也充分说明了，随着测试的深入，测试发现问题后的解决问题占用了更多的时间。

此时黑盒白盒都显然有些力不从心了。

白盒测试的代码扫描和应用功能挂不上钩，而黑盒测试的结果就是测试人员把自动化功能测试发现的问题通过缺陷跟踪系统提交给开发人员处理。

尽管好一点的测试人员会提供详细的测试用例文档和错误截图，但是开发人员仍不得不面临重现问题并不断的采用Trial & Error的手段来分析并解决问题。

    很显然这种问题处理方式是手工方式且非常没有效率，会延缓问题的处理时间。

因此，我们需要另辟新径。

灰盒俱备，只欠工具

所谓灰盒测试，是介于黑盒和白盒之间的，既关注输出对于输入的正确性，同时也关注内部表现的测试方法。

这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。

它达到了某种目的，也就是一旦发现问题，可以迅速定位到黑盒中的某个分支，甚至代码级别。

灰盒测试在系统组件的协同性环境中评价应用软件的设计，从而增强了测试效率、错误发现和错误分析的效率，可以使得测试达到一个新的境界。

但是，灰盒测试对测试人员的要求也比较高，比如灰盒测试要求测试人员具有丰富的开发知识；需要测试人员更多地从业务层面去考虑问题，考虑更多的组合测试业务场景的能力；另外，很多时候问题的解决还需要很多外围知识，包括数据库层面上的分析能力、J2EE服务器内部的调用链分析等。

所以简单来看，灰盒测试是一个非常好的测试理念，但要真正发挥其作用，显然还需要相应的自动化工具这个东风来吹一下。

AppSight就是其中一种自动化工具。

AppSight概述

AppSight由来已久，原来是有Identify开发的，之后被BMC公司收购但是独立运营。

灰盒测试方法

灰盒测试中的精华就是通过灰盒测试能大大缩短解决测试中发现的问题的时间。

问题解决流程实际上包括了主要两个过程：

“根源问题分析”和“问题解决”。

而以经验来看，以前我们的时间主要是耗费在“根源问题分析”上的，一旦问题被定