吃软件测试这碗饭的，如果基础理论都不懂，说不过去吧？
欢迎点进来学习！助你月薪翻倍哦~
前言
只要做测试的同学，就没有不知道黑盒测试 灰盒测试 白盒测试的。但是面试官依然喜欢让你简单谈一谈，你怎么说？
那么要怎么说才能显得有条理，高大上呢？请继续阅读，哦不对，是死记硬背！！！
黑盒测试
测试对象：完整的功能或系统
测试方法：十一种黑盒用例设计
实际目的：尽早达到验收/上线标准。
理论目的：检查需求和功能是否一致。
介入时间：功能完成
介入条件：无
评估标准：需求覆盖率
最低标准：保证必要性，不保证充分性
优点：简单、模拟用户操作。
缺点：测试介入晚，测试不充分，修复bug代价高。
灰盒测试
测试对象：模块，接口，微服务，脚本等。
测试方法：自下而上，自上而下，大突击，三明治
目的：逐步集成，尽早定位bug。尽早展开测试。
介入时间：内部接口等对象完成开发
介入条件：出现难定位的bug；关联度复杂度高的接口；软件质量要求极高；跟生命安全相关功能。
评估标准：接口覆盖率
优点：定位准确，介入早于黑盒测试
缺点：难度大，技术要求高，工作量也大
白盒测试
测试对象：函数，代码，接口。
测试方法：五种白盒用例设计法
目的：把bug修复成本和风险降到最低，
介入时间：开发同事写代码过程中
介入条件：业务，技术，团队达到充分配合和较高技术水准和认知
评估标准：逻辑覆盖率
最低标准：看以往软件质量定标准
优点：能测到代码内部，发现很多隐藏bug
缺点：难度最高，工作量最大。
适用场景：20%的代码量即可，如：常用功能，核心功能，复杂度高功能，公共模块，复用度高功能，新研发同事，研发同学技术差，自测不充份。
开展步骤：依据LLD画出函数代码的流程图→变成圈图→整理出代码路径→写成测试用例。
注意，一旦你提到白盒测试，那么面试官必然会追问一些白盒测试细节，所以我上面对白盒测试多写了一些内容。
