白盒测试与黑盒测试实际应用场景浅析
在软件测试工作中，为充分利用现有的时间和资源条件，提高测试效率和测试充分性，当前有多种方法辅助测试人员完成测试工作，推进项目进度，其中最普遍的莫过于白盒测试和黑盒测试，白盒测试和黑盒测试的概念和常用方法在已有理论研究中都有充分的论述，但是具体应用场景则需要测试人员根据测试任务特征和时间安排合理选用。作为一名非计算机科班出身的技术小白，两年有余的业务验收测试和系统功能测试收效明显，从最开始只能看着需求和业务规则，结合个人感觉盲写案例，到现在已经可以根据项目特征和业务场景，混搭等价类划分、边界值分析和逻辑覆盖、基本路径各种方法写案例做测试。基于个人工作经历和测试经验，以下对白盒测试、黑盒测试和灰盒测试的应用场景进行适当的推荐，仅供各位同行参考。
一、黑盒测试
首先从简单的开始，黑盒测试不要求考虑程序的内部逻辑和数据处理，不要求测试人员遍历代码阅读程序，只需要明确输入输出规则，确保系统或模块实现了业务需求。
（1）建议在对稳定运行的大中型系统进行小规模的功能优化或改造过程中使用黑盒测试方法，只需要明确当前项目的改造点，确认与已有功能的关联性和影响，针对项目改造范围进行测试，非特殊情况无需了解系统或模块的全部处理逻辑。
（2）建议复杂度和重要性较低的系统，在时间精力有限的情况下优先选用黑盒测试方法进行测试。测试人员首先明确业务需求，使用等价类划分和边界值分析方法完成测试案例设计，适当结合程序特征、个人经验以及冒烟测试情况等对测试案例进行修订补充，在系统无重大问题或异常的情况下，一般黑盒测试即可满足该类系统测试要求。
（3）建议适当考量测试人员或测试团队专业技术能力以及测试阶段，如在系统功能测试已经完成的前提下，业务方执行的业务验收测试可以使用黑盒测试方法，降低了团队组建成本和测试成本，无需要求业务人员对代码和软件逻辑进行充分学习和掌握。
二、白盒测试
白盒测试要求测试人员对代码和程序逻辑有相应了解，对测试人员专业背景或能力有一定要求，建议根据项目需求和测试要求选择测试方法。
（1）一般单元测试及集成测试需要使用白盒测试方法，包括代码检查法、静态结构分析法等，相关测试多由开发人员完成，具体视项目团队分工而定。
（2）建议针对新建系统或已有系统新增重要模块时使用白盒测试方法，例如逻辑覆盖或基本路径测试法，尤其推荐在有较多校验关系且校验关系间存在嵌套时使用，使用时一般可参考程序代码、详细设计说明书、程序控制流图等相关资料，帮助减少测试人员的分析工作量等。
（3）建议对重点系统进行架构优化、对公共函数或程序进行改造、对后台或接口内容进行调整时选用白盒测试方法，一方面关注优化改造后对原有程序的改动大小，一方面关注调用方或消费方是否受影响，新版本程序或系统对旧版本的兼容性，避免关联系统由于改造时测试不充分受到影响。
（4）建议关注测试中的集群现象，对于缺陷或问题集中的功能和模块建议及时由黑盒测试方法改为白盒测试，在缺陷管理过程中及时进行小范围的测试方法调整，同时保证测试效率和测试充分性。
在两年多的测试工作中，本人主要参与柜台业务系统、客户定制化应用等不同系统或项目的测试工作。其中柜台业务系统因为系统成熟、运行稳定，当前较为常见的是监管或业务等方面要求的小规模优化改造，例如增加校验、增加授权、更改权限级别、减少展示信息等，相关项目大多对当前内容或当前程序逻辑影响较小，通常采用黑盒测试即可。在银行对公业务尤其是大客户服务领域，定制化应用或功能较为常见，运维或客户需求改变导致的小规模优化可以选择黑盒测试方法，而新建系统或模块或功能测试需要尽量充分，白盒测试方法可以用于辅助案例设计，尤其校验关系较多且存在嵌套时，使用基本路径法设计要素级测试案例可以最小化案例数量，同一思路还可以用于设计流程级测试案例。
近期一次新增模块测试中在流程案例设计就使用了基本路径法，核心交易共有3个不同的流程，3个流程共有4种组合，每个流程涉及最少4支联机交易，最多8支联机交易，每个流程另外涉及最少3个定时交易，各流程起点以外的交易有正反两种状态，一个对象在每个流程中流转时会有15-20种状态，在测试人力有限且项目周期紧张、测试交付延误的情况下，测试方的压力巨大，穷举测试的工作量完全不可接受，要保证案例充分覆盖功能点，使用白盒测试中的基本路径法是非常有必要的，确认程序节点，画出程序控制流图，分析控制流图的环路复杂性，导出基本路径集合并进一步设计测试案例，由此保证测试充分并尽量压缩测试工作量无论对测试人员还是对整体项目都非常有意义。
总而言之，其实各种方法最终还是为软件系统服务，测试人员可以结合项目情况、时间成本、个人偏好适当选择，“不管黑猫还是白猫，抓得住老鼠才是好猫”，不论使用哪种方法或方法组合，能在适当的时间和成本下发现尽量多的缺陷和问题，保证系统按时上线稳定运行才是最重要的。
页:
[1]
