白盒测试经验杂谈

Siva

反思经历过的项目的白盒测试工作，有失败的地方，也有成功的地方，但更多的是积累了经验。这里谈谈自己经历这个项目后的感受：

1、程序员永远是对的
测试员最需要的是交流，而白盒工作和程序员交流最多。但是，往往在测试工作中受到一些规范、流程的左右，必定要和程序员的观念不合，甚至产生矛盾。这时候，就要记住——程序员永远是对的，即使他们做错了。首先要尊重程序员的设计，不要妄加评论，即使这种设计不是最好的，也体现了一个程序员自己的风格。只有在尊重程序员个性特点的基础上，才能将来更好地合作。

2、程序员永远是错的
这一条看起来和上一条似乎矛盾，但是，上一条是大前提，这一条适用于具体的测试工作。测试员需要对一切抱持怀疑态度，白盒测试也是一样，甚至更需要。作为一个测试远，需要明白：
程序员是很不小心的
程序员是很懒的
程序员是很不注重细节的
每当进入工作时都先这么想，才能做到每个细节，每个要素都不放过，因为难不准程序就在某个不起眼的地方当掉了。

3、关注细节，自底向上
一般白盒测试的流程是先单元测试，再集成测试。这就体现了自底向上测试的理念。这个理念不仅仅适用于流程，在具体工作时也可以参照。比如测试一个模块时，可以从细节做起，从小到大，从底层到上层。

4、一定要注意编码规范！
这里要注意区分编码规范和编码风格的区别。不同的测试员有不同的风格，也是个性的体现，但如何能统一规范？有许多程序员根本不在乎规范问题，认为只要代码能完成既定功能，没有bug，就是完成了项目，其实不然。现在市面上，会写程序的一抓一大把，但是能称为“程序员”的人甚少，顶多算“懂程序的人”。合格的程序员不仅仅是会写代码，而且还应该具备将代码融入项目的素质。作为一个程序员，写的是工程项目，开发的模块是给大家用的。而不是小作业，小程序。所以，代码要考虑到项目中其它合作开发人员的使用，考虑到测试员的阅读，考虑到将来其它项目人员的维护，作为程序员就不能随心所欲地写代码，而是要遵循编码规范，端正编码行为。

5、文档在哪里？
项目的每个阶段都需要产出文档，这是连学生都知道的事情。但是，实际情况又怎么样呢？可惜在中国，70%以上的项目开发时间不足而延期，那么怎么办？牺牲测试时间，这种做法越来越多的开发团队明白并不可取，那么，唯有牺牲写文档的时间。也许这种做法也不正确，但可以理解。作为白盒测试人员，如何面对这种窘境？强迫开发人员腾出部分编码时间来整理文档似乎也是不可取的。我推荐的做法是要求开发人员腾出少许时间直接将内容口述讲解给测试人员，因为项目时间紧，口述时间比写成文档要少得多，而且也挽救了测试时间（测试人员不用等文档出来才开始测试）。当然，文档还是要的，因为还要考虑到维护人员和其它项目相关人员。

6、测试时间不够怎么办？
事实上很多项目（包括Avatar）都有这种情况发生，这时候就要学会取舍，不要墨守成规地按照流程做事。测试最终的目的是保证质量，合理利用测试员的经验，优先测试那些你认为有必要的。

7、白盒测试与黑盒测试是相辅相成的
这句看似是废话的道理，其实很多人还是不以为然。有的没有配测试员的开发团队，认为开发完成后做一次黑盒就够了，完全不检查自己的代码，或者边编码边测试，项目完成后也不进行一次整体回归。这都是不合理的做法，虽然看起来节省了开发时间，殊不知质量不合格的话，打回来进行二次开发需要花费更多的时间，并且无形中降低了团队的声誉。所以，用一句老话——“两手都要抓，两手都要硬”。

ilovejolly

自底向上和自顶向下一般都要结合用