但说实话，日常工作中我使用灰盒测试方法的场景相对较多，总结来说，就这么一个流程：发现问题-->我大概知道你是怎么玩的-->初步定位问题原因-->同开发确定问题-->接下来呢？恰好，我最近遇到一个问题，并且刚好使用到灰盒测试方法，分享给大家窥其一二。这算是一次我所理解的完整的灰盒测试，也是我一直推荐给组内人员的高效率的一种工作方式：我大概知道你是怎么实现业务的，实践定位问题，达到快速解决问题的目的。
对于黑盒、白盒与灰盒测试方法的理解，几年前我在某乎做过一个概念性的回答，当时提问者询问：如何跟非技术人员解释黑盒、白盒、灰盒测试的区别？
我的回答原文如下：
既然是对非技术人员解释，就不能用专业术语。
这样说吧，有个打孔机，类似这样。
纸条从盒子左方插入，从右方出来时，分别打出圆形、正方形、三角形三个样式的孔。
某天，打出来的纸条，只有一种图形。
黑盒测试员只能说：“这个打孔机坏了！”
灰盒测试员把打孔机的盖子掀开，发现打孔机的造型原来是这样的。
于是他说：“机器仍能打孔，说明主机没坏；三个桩子也都是好的；但只打印出了圆形，可能因为连接正方形和三角形桩子的地方有问题。”
白盒测试员把机器拆开，查看内部的电线、电路、控制器等等，发现连接正方形和三角形的电线烧坏了，于是说：“原因找到了，换根电线吧。”
彼时，我还是一位测试小鸟，在研习了不少理论知识后，回答了这个问题。现在，我算不上测试老鸟，但能算个测试大鸟，在工作中，越发频繁地接触这三种测试方法。
如果你要问我哪种测试方法更好，我不置评价，每个人的口味不一样，别人适合的不一定自己适合。
对于黑盒测试方法来说，是每一位测试的必备技术，没有谁不会：发现问题，抛出问题。简单、轻松、快速，是黑盒测试的优点，特别是在项目特别赶，测试时间无限被压缩的时候——只需要抛给开发问题，剩下的让开发自个儿玩去吧。
但黑盒测试人员常常被人诟病只知道点点点，抛开此类“鄙视”不谈，接着上面继续，我们是不是忽略了一个事实：项目既然赶，那开发的时间亦不充足，如果恰好遇上稍稍复杂的bug，并搭配不靠谱的开发，一个bug的生命周期可能会拉得极长，效率特别低下。
这么说，那用白盒测试方法呗，看代码，查原因，丢给开发后，留下一个高大帅气的背影，让开发心里默念——这个测试不简单。
白盒测试可以，但使用它时，你需要盘算盘算：
是否有充足的时间研究代码以及和代码相关的环境部署、配置设置等？
付出和产出是否成正比，如同自动化测试，能达到高性价比吗？
白盒是一种选择，但同样是一个难题。更别说白盒对于测试技术的高要求。
废话了这么多，你一定会说：风风，你不就是拐弯抹角地推荐灰盒测试嘛。
我不知道该怎么回答你，就像刚开始说的，每个人的口味不一样，适合自己的测试方法，最醇最香。
但说实话，日常工作中我使用灰盒测试方法的场景相对较多，总结来说，就这么一个流程：
发现问题-->我大概知道你是怎么玩的-->初步定位问题原因-->同开发确定问题-->接下来呢？
会分成两类：
1、我定位的原因并不是真正的原因。但我能通过这个过程学习到新知识、新业务，积攒个人经验（很多人往往弃步于此）
2、我定位的问题是真正的原因。就此打住吗？并不是。你能提出问题的解决建议吗？你的建议是否比开发的修改 or 产品给的方案更好，更具有可实施性？
合理地提出解决问题的建议，这才是你关注的重点，而不是因为找到问题原因而沾沾自喜，迷失于他人的赞许中。
实践是检验真理的唯一标准。恰好，我最近遇到一个问题，并且刚好使用到灰盒测试方法，分享给大家窥其一二。
先描述下业务：
我测试的X系统会从配置系统拉取几条数据，并保存在数据库A（读写库）中，数据库A又会将新数据实时同步到数据库B（读写库）中。业务上：a类用户从数据库A中读数据，b类用户从数据库B中读数据。
再说下bug：
我在配置系统删除了一条数据，结果a类用户没有读到该条数据（预期结果），b类用户却读到了该条数据（非预期结果）。去数据库查看，A库没有被删除的数据，B库仍然存在被删除的数据。
按理说，走到这一步，便可以到bug系统提交一条bug指给开发解决。不过我想到开发最近天天晚上加班，并且我之前提的几个bug反复修改，开发效率很低，加之临近上线，时间被压缩，于是乎，我额外抽出一点时间，简单定位下问题。
这个问题看起来简单，无非是同步导致两个库的数据不一致，可以得出两个猜测：
一 同步没有触发。
二 同步触发了，但数据没有在B库落库。
接着，我做了一个实验：在配置系统修改了一条数据，结果A库和B库的数据保持一致。据此，猜测一不成立。
紧接着，我又做了一个实验：进入A库，在数据库内删除一条数据，奇怪的是，B库的数据被删除了，猜测二也不成立。
两种猜测同时被证明无效，那问题究竟出在哪里呢？
于是，我上到服务器，重新在配置系统删掉一条数据，并触发了一次同步操作，我在日志上找到了两条sql：
truncate table xxtable;
insert into xxtable……;
到此，我恍然大悟。
原来因为这个业务的数据不多，开发可能是这样处理的：从配置系统拉取数据时，先清空A库的xxtable，再向A库的xxtable插入数据，以此简化数据增删改的逻辑。但我司DBA做过处理，不允许数据库级别之间进行truncate table的同步。
最后找开发讨论，果真是这个问题。
怎么解决呢，将truncate table xxtable换成delete from xxtable即可。
这算是一次我所理解的完整的灰盒测试，也是我一直推荐给组内人员的高效率的一种工作方式：我大概知道你是怎么实现业务的，实践定位问题，达到快速解决问题的目的。
最后，一如既往地做个总结吧：
- 测试时，特别简单的bug建议直接抛出，让开发去玩，没必要浪费精力定位问题
- 复杂问题多总结，定位问题时头脑要清晰且灵活，证实或否定每一个猜测
- 和开发打好关系（或强制要求），让他们在解决bug的时候注明bug产生的原因
- 多花时间在业务上，绝对物超所值
