浅谈白盒测试

　　针对测试，一直都有黑，白之分。由于白盒一般情况下需要有比较高的技术要求及比一般开发人员还要高的项目经验和缜密的逻辑思维能力，所以一般做信息系统的软件公司会忽略白盒测试。但个人一直觉得，对于一个健康的测试团队来讲，必须要有一个或多个熟悉白盒测试的人员。倒不一定说熟悉白盒测试的人员一定需要写代码，但一定要懂得如何去做白盒测试和白盒测试用例的设计。

　　一个成熟的软件公司，必须要有一个精英汇集的研发团队，人数在精不在多。这个研发团队的功能主要有两个。

　　其一，严密监控业界的最新动态，根据公司的技术，软件习惯及文化，及时掌握最新的相关动态及技术信息，并将筛选出的有用信息及时转换为相关生产力，向公司内部推送。

　　内部的推送形式也可以分两种，一种是平板传达，也就是互联网上相关消息进行筛选后直接传递给开发人员，促进全员的整体技术能力的提升;另一种是实践传达，是将业界的相关最新技术研发人员自己掌握后，针对一些闪光点，做成成品DEMO，向相关高层人员，公司领导和各个业务口的项目经理进行推广。

　　其二，创建，推广及维护升级公司的整体技术框架及对于技术疑难问题的解答。一般情况下，项目的进度时间要求都比较高。因为一个业务负责人，不可能像专业人士那样熟悉了解软件开发流程，他们一旦决定做一个系统，巴不得第二天就要看到成果。虽然大家都知道前期很重要，但如果项目经理的经验有点欠缺，往往就会被业务负责人牵着鼻子走，为了加快进度而忽略了前期的工作准备。在项目一开始，就给后面的项目推广，人为的增加了难度。而有效规避该问题的一个重要手段就是，整个软件开发团队有统一的系统技术框架，将最常用的功能打包封装，诸如内容管理，系统管理等功能，直接封装好提高使用就好。针对业务功能很强的业务系统，那提供给最基础的 Framework,WebCommer之类的内容。也能给项目组提供很大的方便，节省很多时间。这样做的好处，除了可以提升项目后期开发的效率，缩短开发时间，避免不必要的加班外，统一的系统设计风格和统一的UI交互风格，让熟悉该软件团队的人，在接触到以前没有涉及的系统时，会有似曾相识的感觉。增加陌生用户对系统的亲和。

　　有了以上的研发需求，那么作为系统质量保障的测试团队，更需要对这些最底层的功能做好充分的测试，保证上层开发人员使用框架的正确性。这是一般的项目管理者都明白的道理，其实也是大家都明白的道理，好的医生治病，还没等病冒出来，就灭掉它了。

　　最底层的基础框架，测试方法只能是白盒测试中的单元测试。而且单元测试只能在研发的工作中进行。主要在于，单元测试除了要穷举测试用例外，还需要写比正常开发量3-4倍的代码量(该数据是我08年亲身体验得到的)。试想在一个有着Deadline 逼着的项目开发过程中，又有哪个项目经理会采纳单元测试的方案?!又有哪个开发人员愿意去加班写单元测试的代码?又有哪个测试人员有精力又做黑盒又写白盒?!

　　所以说，白盒测试的实施是需要很多条件的。其一，在研发项目中实施;其二，为了做到真正的测试透彻，不能有太大的测试时间压力;其三，单元测试的编码由开发人员来执行，而不是测试人员。

　　那么肯定有人要问了，大致的问题有两个，1，白盒单元测试的代码由开发人员来写，测试人员干嘛?!2，如何来保障代码的正确性?!

　　其实，回答了以上的两个问题，也就是下来要阐述的，如何在项目中实施白盒测试了。还是画图说明要清晰一些。见下图：

　　1、确定测试范围，这项工作一定是需要做的。做事没有范围就没有目标，不管是实施型项目还是研发型项目，都有一个确定的目标，这样才能更好的衡量成果。测试工作当然也一样。

　　2、测试用例设计：单元测试的用例设计很繁琐，因为此处和项目的用例设计不同。项目的测试用例设计前面已经说过了，一般情况下，编写者和执行者是一个人，大体记录下测试思路即可。但单元测试的用例设计者和执行者是分开的，而且又主要是针对异常情况进行验证的。所以单元测试的用例设计要注意，一个是穷举，一个是边界异常。

　　3、代码编写及走查：这两步和在一起进行。个人主张谁写的功能，谁来写单元测试的代码。一个是本人对他的代码比较熟悉，写起来上手快，不用走读懂代码那一段。另一个是测试人员的思路一般比较缜密，当开发人员严格按照测试用例将单元测试的用例代码完成后，以后在开发过程中，针对自己的薄弱环节会有意识的加强异常的处理。但是，人的思路是有自己的特点的，自己写的代码往往在某一点总是出问题，那么代码走查的工作就非常重要，一个是测试经理进行代码通读，检查用例的覆盖度和代码的正确度，挑出明显的代码错误外，还应加强交叉检查。通过其他人的眼睛来找到自己的差错，更容易发现问题一些。

原文转自：http://www.uml.org.cn/Test/201105201.asp