• 0
  • 1
分享
  • 白盒测试与黑盒测试实际应用场景浅析
  • 恬恬圈 2020-02-10 09:20:36 字数 2088 阅读 4370 收藏 1

在软件测试工作中,为充分利用现有的时间和资源条件,提高测试效率和测试充分性,当前有多种方法辅助测试人员完成测试工作,推进项目进度,其中最普遍的莫过于白盒测试和黑盒测试,白盒测试和黑盒测试的概念和常用方法在已有理论研究中都有充分的论述,但是具体应用场景则需要测试人员根据测试任务特征和时间安排合理选用。

作为一名非计算机科班出身的技术小白,两年有余的业务验收测试和系统功能测试收效明显,从最开始只能看着需求和业务规则,结合个人感觉盲写案例,到现在已经可以根据项目特征和业务场景,混搭等价类划分、边界值分析和逻辑覆盖、基本路径各种方法写案例做测试。基于个人工作经历和测试经验,以下对白盒测试、黑盒测试和灰盒测试的应用场景进行适当的推荐,仅供各位同行参考。

一、黑盒测试

首先从简单的开始,黑盒测试不要求考虑程序的内部逻辑和数据处理,不要求测试人员遍历代码阅读程序,只需要明确输入输出规则,确保系统或模块实现了业务需求。

(1)建议在对稳定运行的大中型系统进行小规模的功能优化或改造过程中使用黑盒测试方法,只需要明确当前项目的改造点,确认与已有功能的关联性和影响,针对项目改造范围进行测试,非特殊情况无需了解系统或模块的全部处理逻辑。

(2)建议复杂度和重要性较低的系统,在时间精力有限的情况下优先选用黑盒测试方法进行测试。测试人员首先明确业务需求,使用等价类划分和边界值分析方法完成测试案例设计,适当结合程序特征、个人经验以及冒烟测试情况等对测试案例进行修订补充,在系统无重大问题或异常的情况下,一般黑盒测试即可满足该类系统测试要求。

(3)建议适当考量测试人员或测试团队专业技术能力以及测试阶段,如在系统功能测试已经完成的前提下,业务方执行的业务验收测试可以使用黑盒测试方法,降低了团队组建成本和测试成本,无需要求业务人员对代码和软件逻辑进行充分学习和掌握。

二、白盒测试

白盒测试要求测试人员对代码和程序逻辑有相应了解,对测试人员专业背景或能力有一定要求,建议根据项目需求和测试要求选择测试方法。

(1)一般单元测试及集成测试需要使用白盒测试方法,包括代码检查法、静态结构分析法等,相关测试多由开发人员完成,具体视项目团队分工而定。

(2)建议针对新建系统或已有系统新增重要模块时使用白盒测试方法,例如逻辑覆盖或基本路径测试法,尤其推荐在有较多校验关系且校验关系间存在嵌套时使用,使用时一般可参考程序代码、详细设计说明书、程序控制流图等相关资料,帮助减少测试人员的分析工作量等。

(3)建议对重点系统进行架构优化、对公共函数或程序进行改造、对后台或接口内容进行调整时选用白盒测试方法,一方面关注优化改造后对原有程序的改动大小,一方面关注调用方或消费方是否受影响,新版本程序或系统对旧版本的兼容性,避免关联系统由于改造时测试不充分受到影响。

(4)建议关注测试中的集群现象,对于缺陷或问题集中的功能和模块建议及时由黑盒测试方法改为白盒测试,在缺陷管理过程中及时进行小范围的测试方法调整,同时保证测试效率和测试充分性。

在两年多的测试工作中,本人主要参与柜台业务系统、客户定制化应用等不同系统或项目的测试工作。其中柜台业务系统因为系统成熟、运行稳定,当前较为常见的是监管或业务等方面要求的小规模优化改造,例如增加校验、增加授权、更改权限级别、减少展示信息等,相关项目大多对当前内容或当前程序逻辑影响较小,通常采用黑盒测试即可。在银行对公业务尤其是大客户服务领域,定制化应用或功能较为常见,运维或客户需求改变导致的小规模优化可以选择黑盒测试方法,而新建系统或模块或功能测试需要尽量充分,白盒测试方法可以用于辅助案例设计,尤其校验关系较多且存在嵌套时,使用基本路径法设计要素级测试案例可以最小化案例数量,同一思路还可以用于设计流程级测试案例。

近期一次新增模块测试中在流程案例设计就使用了基本路径法,核心交易共有3个不同的流程,3个流程共有4种组合,每个流程涉及最少4支联机交易,最多8支联机交易,每个流程另外涉及最少3个定时交易,各流程起点以外的交易有正反两种状态,一个对象在每个流程中流转时会有15-20种状态,在测试人力有限且项目周期紧张、测试交付延误的情况下,测试方的压力巨大,穷举测试的工作量完全不可接受,要保证案例充分覆盖功能点,使用白盒测试中的基本路径法是非常有必要的,确认程序节点,画出程序控制流图,分析控制流图的环路复杂性,导出基本路径集合并进一步设计测试案例,由此保证测试充分并尽量压缩测试工作量无论对测试人员还是对整体项目都非常有意义。

总而言之,其实各种方法最终还是为软件系统服务,测试人员可以结合项目情况、时间成本、个人偏好适当选择,“不管黑猫还是白猫,抓得住老鼠才是好猫”,不论使用哪种方法或方法组合,能在适当的时间和成本下发现尽量多的缺陷和问题,保证系统按时上线稳定运行才是最重要的。


版权声明:本文出自51Testing会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 前言容器化这个词,对于互联网公司的运维人员来说是非常熟悉的。但我们测试开发的兄弟姐妹可能会有疑问:这个与测试有什么关系?其实不是有关系,而是回归到我们平时工作中遇到的困难,以及对于这些困难,我们提供了什么解决方案。不管从事开发工作也好,测试工作也罢,如果懂得容器化会对自己的工作有很大的增益。工欲善其事必先利其器,容器化(Docker)不管对于开发者来说,还是测试人员来说都是一把利器。比较重要的一点是可以帮忙公司降低cost,这对于老板们来说是非常有说服力的,以下给大家举两个例子,说明一下Docker的用处,都是女巫工作中遇到的典型案例,当然这远远不能全面说明Docker的好处,但是已经很能说明...
            10 10 1628
            分享
          •   Deepfake 人工智能系统最险恶的功能之一是能够复制一个人的声音,即使只是一段简短的录音。 人们声音的深度伪造版本以及伪造的视频可以用来使其听起来和看起来好像政客或名人说了一些他们实际上从未说过的话。此外,还有一些情况是,人们接到诈骗电话,其中朋友或家人的深度伪造声音要求他们因某种紧急情况尽快汇款。 此外,复制的声音可用于绕过语音识别安全系统。  然而,一种名为 AntiFake 的新软件工具可以帮助防止这种情况发生。  已经有技术可以确定所谓的声音是否是深度伪造的,AntiFake 是最早阻止此类伪造声音产生的系统之一。 简而言之,它是通过让人工智能系统更难读取真人声音录音中的关键声...
            0 0 926
            分享
          •   用例设计是测试工程师的日常工作之一,也是基本技能,今天,从实际工作的角度,跟大家分享下快速设计用例的7个小技巧:  1. 根据需求,先拆分大的功能点,作为主用例。例如,常见的增删改查,就属于大的功能点,可以作为主用例。  2. 使用等价类划分,按分类设计用例,基本分类可以从正面场景和负面场景入手。例如,测试创建可分为创建成功和创建失败2种场景,可分别设计用例。  3. 善用边界值,可结合等价类使用。测试经验告诉我们,测试有时会涉及大量数据,遍历所有数据效率较低,如果是手工执行,更难以实现覆盖所有数据,更有效率的做法是,先划分等价类,再从等价类中选择部分参数测试。  边界值是等价类所有可选参...
            0 0 889
            分享
          •   TikTok 今天告诉用户,TikTok 的 10 亿美元创作者基金将于 2023 年 12 月 16 日终止运作。TikTok 发言人玛丽亚-荣格(Maria Jung)说,美国、英国、德国和法国的创作者将不能再通过这一基金为自己的内容转化收入,不过意大利和西班牙的 TikTok 用户不受此影响。  创作者基金最初于 2020 年推出,公司承诺在三年内向制作应用程序病毒内容的用户支付 10 亿美元。创作者的报酬基于浏览量和其他参与度指标,一路走来,平台网红和其他内容创作者都注意到,该基金的报酬很低,有时几百万的浏览量才得到几美元的报酬,这使得他们无法仅靠创作者基金谋生。TikTok 没有...
            0 0 889
            分享
          • 前言我曾经在好几个项目里都近乎完整参与过补齐前端测试的工作,也收集到不同项目的同事很多关于前端测试的困惑和痛点,这其中大部分都很相似,我也感同身受,在这篇文章里,我会针对大家和自己常遇到的痛点分享一些自己的经验,如果你也有如下相似的困扰,那希望这篇文章能对你有些帮助~常见问题(排名不分先后):前端测试感觉写起来很复杂,会花很多时间,甚至经常是业务代码时间的好几倍前端测试怎么TDD?测试一些第三方UI控件时,特别难模拟与之的交互有些东西不知道怎么mock,比如时间,浏览器全局变量(window.location,local storage)等测试里准备数据的代码特别长,真正的测试代码很靠后,要翻...
            0 0 1999
            分享
      • 51testing软件测试圈微信