一、白盒测试

　　1. 白盒测试和黑盒测试

　　以往只用黑盒方法测试的时候，总是对测试结果不放心，万一有些情况没考虑到而且出问题的话就不好了。但是如果经过白盒分析后，对测试结果更有信心了，因为确认测试用例和测试数据基本上已经覆盖到了程序主要语句和边界。对整个内部的处理过程了解之后，所有测试数据所检测到的地方信心更充足，而不仅仅是依赖测试方法理论。

　　白盒和黑盒的另一个重要区别是，白盒测试人员了解代码设计后，能推断出这个设计本身存在什么逻辑上的漏洞，如果什么情况发生，可能会出现BUG，然后进一步进行确认，但是黑盒就无法从这个角度去发现了。所以静态白盒测试要比动态黑盒测试可能要更容易或更早发现同一个BUG，特别是设计思想正确，而在代码实现上出现了问题这种情况，如果是检查代码很容易发现的。

　　关于不同的等价类，在程序中的体现在if…else、switch之类的会产生分支的语句，因为不是同一等价类，所以需要进行逻辑处理的语句也就不一样，反之亦可。其实黑盒的等价类划分基本上就等于白盒测试的语句覆盖，有的时候，黑盒的角度看不是同一等价类，也许程序中是视作同一类型，所以处理的语句也是一样的；有的时候，黑盒的角度看是同一等价类，但是程序中是需要区别处理的。所以，黑盒+白盒进行测试用例和测试数据的设计，才是最优的测试方法。

　　2. 阅读代码

　　C文件的阅读，在具体阅读代码之前先画出这个源文件的函数调用关系图。首先找到这个源文件所在的最上层的函数（比如说main），然后找到这个函数里面又调用了哪些函数，以此类推，最后画出函数的相互调用关系图，那么其中的每个函数都是一个单元模块，然后根据这个函数关系图，逐步的去了解每个函数的作用（一般都有函数的注释），这个时候就能知道这个功能内部处理的顺序是什么（细节方面的实现没有了解），这个时候就可以做灰盒测试了，如果还想了解的更深入，则去了解每个函数的具体实现是什么样的，细节到每一个语句，这个时候就可以进行白盒测试了。总之，先画出函数调用关系图，再仔细阅读代码时会更快、更有效率。

　　系统函数调用和程序逻辑结构可以自己摸索，但至于为什么逻辑要设计成这样，就得去理解程序人员的算法了。比如说程序中创建一个子进程，子进程实现的每一步骤都能理解，但创建子进程的目的到底是什么，如果无法从子进程代码实现中了解到，只能去问程序人员了。

　　做任何事情最重要的就是坚持，阅读代码文件也是如此。在开始看某个陌生C文件时会很迷惑，比如说有些对象（暂且把所有变量、内存、共享内存、文件都叫做对象）不明白为什么需要，但还是要坚持下去，越看到后面越能理解为什么这么设计，因为在对象使用的过程中，它的作用就慢慢浮现出来了，从代码中思考它的设计意图，层层剥析，其实无非就是一堆变量、共享内存、文件、网络接口中数据的操作。总之，坚持下来，一定会有收获的。

　　3. 设计用例

　　当黑盒测试时，设计的有效测试用例或测试数据组合情况太多时，可以用白盒方法对组合情况进行筛选。去了解程序处理这些条件的顺序是如何的，比如说有A和B2个条件，程序中发现是先处理A再处理B，而且他们之间基本上没有关系（数据的传递），那么组合情况只要考虑AB，A和B这2种组合情况就不用考虑了。

　　4. 驱动模块

　　无论是使用编写的驱动模块还是使用正常的上层模块，你所测试的模块的测试需求是一样的，每个测试用例的测试目的也是一样的，只是测试用例的操作步骤上有些不同。从定位的角度看，使用驱动模块能准确定位到一定是被测模块的问题。从用户角度看，使用正常的上层模块测试通过才是真正的没问题，用户不关心是你所测试的模块的问题还是上层模块的问题。使用正常的上层模块测试会更快捷而且更有效些，但是使用编写的驱动模块可以测试到上层模块无法发送测试数据的某些失败测试用例。如果正常的上层模块没有开发完成的情况下，可以使用驱动模块去测试，测试时间可以提前。总之，无论使用驱动模块还是上层模块，各有利弊，在适当的时机下选择最适合的方式就行。

　　本文出自caicai1724的51Testing软件测试博客：http://www.51testing.com/?25347

　　二、合作与沟通

　　先理解，而表达

　　先去理解对方的观点和情况，并予以肯定，表示你已经明白了对方所要表达的意思，然后表达自己的想法，而且以询问的方式征求对方的意见，如果对方觉得你说得对，自然会接受你的想法，如果对方觉得你说的不对而且有不同的观点，正好大家可以讨论一番，因为有不同观点才会有新的收获嘛，真理往往越辩越明，而且印象深刻。总之，想了解对方才能更好的进行沟通。

　　当彼此的观点和想法有很多不同的地方，而且不能立刻接受的时候，是保留意见，还是直接提出来？如果没有权威性的理论支持，我相信很难使相反意见的人接受，这个时候最好是先理解对方的观点，然后保留自己的想法，再在实践中思考，要么发现自己的观点的确错误，要么找出权威性的理由证明自己的观点正确。所以不要完全接受对方的观点，也不要完全否定对方的观点，需要一段时间的思考。

　　关于BUG的沟通

　　一个人要去做一件事情，一般来说是按照自己的意愿去做的，如果不是自己想做而是被要求这么做的话，心里一定会留下点不愉快，特别是那种有自信有自己主见的人，比如说开发人员，当测试人员发现一个BUG，然后告知开发人员后，开发人员之所以会去修改BUG，是因为他自己认为的确需要修改，而不是因为你提到要改他才改的，所以当他认为不需要修改的时候，肯定是有自己的想法和理由，不妨理解下他们，合理的就可以接受，不合理的话，也不要强制的让他去修改，试着解释给他听，让他心甘情愿的去修改，这才不会让他心里产生不愉快的情绪，开发人员和测试人员彼此间的关系才不会弄得很紧张，如果强制性的让他修改多次的发生，那么开发人员会对测试人员慢慢的产生成见，这样就不好沟通了。

　　有时候也许是描述BUG时的语言表达有问题，或者是开发人员的理解能力有问题，描述BUG一遍后，开发人员可能还会有不明白的地方，需要再次沟通，如果当场演示就比较容易理解了。可能我们都没有问题，只是根据自己所知道的信息和对方所知道的有所误差，有些共识还需要互相确认，所以提交BUG时不仅仅是简单的描述一次，而是多次的沟通和确认。