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

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

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

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

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

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

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

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

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

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

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

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

　　4、测试执行：通过对单元测试的代码的运行，来检查原有功能的正确性。

　　5、项目总结：在完成每个工作时，对该工作的总结和前面的范围确定一样，是非常重要的。一方面有目的的检查前期测试目标是否达到，一方面通过项目的总结积累经验，总结性文档可成为测试团队成长的依据。针对个人，通过对工作的总结进行一次理论及经验的升华。