小白的白盒测试之路
需求了解篇
接到一个功能的测试，第一步就是了解整个需求，能否将整个需求了解透彻直接关系到后续测试工作开展和测试质量；如何在做好需求了解呢？下面我们就分析一下。
1. 一个版本开始了，产品找测试和开发讲需求，听听都是什么需求。
遇到问题：对于测试而言主要关注这个需求要做一件什么事，要怎么做，实现的效果是什么样的，解决了什么样的问题，做到这些我们已经对这个需求有了一个大概的了解，但往往我们会忽略这个需求的细节和关联功能逻辑的处理，怎样在需求讲解过程中获得更多的信息呢？
解决办法：需求讲解前做充足的准备，先自己理解一遍需求，对不明确的地方和可能影响的其他模块功能记录下来，在会上听需求过程中解决这些疑问，这样即有利于自己对需求的把握，也使得需求文档更详细，开发在做这个需求时也更明确；
2. 功能提测了，这个需求是什么来着？
遇到问题：有些需求提出时间很早，但做出来提测的时间比较晚，在提测时测试这边对需求的逻辑已经很模糊了，重新看需求文档相当于又了解了一遍需求，时间消耗多，需要讲解会上大家讨论的问题有些没有及时记录，导致关注点被遗漏，这该怎么办？
解决办法：按照正常的阅读习惯，阅读文字了解逻辑通常要比看图了解逻辑慢很多，因此在听完需求讲解后，对每个需求绘制测试逻辑流程图，在图上重点标注会上大家讨论的部分和分支逻辑，这样在功能提测时就不会出现还要再了解一遍需求的尴尬局面，也不用努力回忆会上大家讨论的事情；
3. 找开发问代码实现，开发说的很详细，但是好像都没听懂，还不好意思说都没懂，自己回去看要花好长时间，项目delay，加班ing
遇到问题：刚开始做白盒测试的时候经常遇到这种问题，对整体代码结构不了解，去找开发了解实现需求时，就直接说我是来了解实现需求的，你能给我讲一下吗，开发带着你边看代码边讲实现逻辑，很是详细，可是你却听得一头雾水，想着开发还有很多事情要忙，又不好意思总说听不懂，结果很显然，只能自己回来慢慢看，测试时间被消耗在看代码上，导致测试时间delay，每天工作时间很长却看不到成果。
解决办法：开始的时候想着现在对整体代码还不了解，等着对全局代码有了大概的了解时就不会这样了，其实并不是这样。主要原因是了解实现的方法不正确，主要问题有下面几点：
1) 问问题的方法：你找到开发，问他你是怎么实现的，你说开发怎么给你讲呢，从哪开始讲呢，换位思考一下，一个外国人问你汉语怎么说，你要怎么解释呢；结论是没法解释，或你解释的东西不是他想要的；怎么问问题呢？
Ø 有范围的问题：如“这个函数中英文词覆盖组词的逻辑是怎么实现的呢？”有范围的问题更容易让讲解者了解你想要了解的重点
Ø 带着问题去问：根据绘制的测试流程图列出自己想要关注的点，如对外的接口函数，逻辑分支的实现方法，与其他模块有关联的部分的处理办法
Ø 适当打断讲解者：开发讲的东西不一定都是你所需要的，而且你集中精力的时间是有限的，对于开发讲的你不需要的东西要打断他，继续询问自己关注的问题
2) 钻牛角尖了解与功能无关的复杂逻辑：一个功能的完成很多时候是基于其他功能，我们听不明白往往是因为这个功能牵扯的其他逻辑太多，了解这些逻辑，时间消耗大，产出低，因此对于这些逻辑，我们只需要知道他们的功能是什么，怎么用就可以了，更多的时间放在主线逻辑上
3) 想知道的逻辑要问到底：对必须要了解的实现逻辑要问到底，因为实现过程中越是复杂的逻辑就越是容易出错，一定要和开发把这个问题弄明白，不能因为不好意思问和其他个人因素就放弃，这很可能就是一个大问题
如需转载该篇文章，请注明来自“搜狗测试”