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