持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第12天，点击查看活动详情
按测试技术的不同来分：黑盒测试、白盒测试、灰盒测试
1. 黑盒测试
黑盒测试是个很形象的比喻，它的概念就是把测试对象看作一个黑盒子，测试人员不用考虑 程序内部的逻辑结构和内部特性，只需依据程序的需求规格说明书，检查程序的功能是否符合它 的功能说明。界面测试、功能测试就是属于黑盒测试。
黑盒测试的常用方法包括：等价类划分、边界值分析、因果图分析、错误推测法等。
2．白盒测试
白盒测试，顾名思义，就是把测试对象看作一个透明的盒子，测试人员利用程序内部的逻辑 结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序 状态，确定实际状态是否与预期的状态一致。单元测试就属于白盒测试。白盒测试方法包括：语 句覆盖、判定／条件覆盖、条件组合覆盖、路径覆盖等。
3．灰盒测试
世界不是非黑即白的，当中也存在灰色地带。灰盒测试可以理解为关注输入数据后的系统输 出数据是否正确，同时也关注内部表现，但这种关注不像白盒那样详细，只是通过一些表征性的 现象来判断内部的运行状态。例如，接口测试需要验证的是输入不同的数据，对应输出是否正确。 它就是典型的灰盒测试过程。就像在上文提到的，当测试人员在做功能测试时，界面输出是正确的，但内部其实已经错误了。灰盒测试就是避免这种问题的有效手段。
一周后，比目鱼先生查看开心的学习成果比较满意，开始给开心培训测试用例的内容。 开心打开测试用例文档，如图所示。
比目鱼先生提问：“开心，你知道测试用例是通过什么写出来的吗？”
开心想到这个问题从网络资源里看到过，答案是测试用例来自于需求，然后信心满满地回答： “测试用例是根据需求规格说明书写出来的。”说完，十分自信地等待着比目鱼先生的表扬。
“错了，测试用例和需求规格说明书之间还隔着两层呢！接下来我给你讲一下测试用例的奥 秘。”比目鱼先生回复道。
测试用例是从哪里来的，大多数人会说它来自测试需求。从之前我对测试需求的介绍可以看 出，测试用例是被细化的内容，它与测试需求之间似乎还少了点什么。少的这部分内容就是测试 用例的框架。所以，测试用例不是从测试需求直接衍生来的，它首先由测试需求衍生为测试用例 框架，再由测试用例框架衍生为测试用例。
很多情况下，大家想到测试用例就直接忽略大范围的框架，而只强调关注细节方面的内容。 这是本末倒置的做法。
如图所示，在设计阶段测试人员就可以开始测试框架的选择及编写工作
测试框架可以分为两种类型。
（1）代码型测试框架：指代码框架的选型。如自动化测试中需使用的框架Cucumber和 RobotFramework等，也可以是自己编写的框架。测试人员可以简单地使用这些框架完成测试用例 管理、执行测试、输出测试报告等工作。
（2）用例型测试框架：指编写测试用例的框架，如图所示。
在每个测试用例框架组成部分中的用例都有层级关系，如图1.19所示。 测试用例框架＝测试用例整体需求＋测试用例层级关系
测试人员在软件的设计阶段，就应该着手去跟进测试用例框架的内容。框架内容确定得越完整，在后期测试用例维护方面的代价就越小
