白盒测试

         --关于游戏测试的一些感悟

        在国内一家知名的游戏公司做白盒测试已经快一年了，或多或少都有一些感悟。回头想想也是其实白盒测试是所有测试中最有争议的职位。如果和功能测试、性能测试、等等其他测试相比，似乎要求的编程能力和相应的技术能力要高很多，但是对于一个合格的程序员来说却是在国内这种现状下做白盒测试似乎有点屈才的味道。但是白盒测试发挥的“功效”和认可是成正比的，这就是目前白盒测试所处的比较尴尬的位置吧。

        关于白盒测试的一些方法，相信去百度一搜一大堆，很多很多。但我这里要说的是根据我们实际工作中的体会来描述的，从两个大方向来说主要有静态测试和动态测试。静态测试就是不用运行程序，从看代码这个曾是就发现了程序本身的问题，而相比之下更复杂的是动态测试，我不知道大家是怎么理解动态测试的，反正在我们的理解中就是程序必须得动起来，至于怎么动，方法有很多。

        静态测试，静态测试比较好说，就是你给程序员们制定了一些“规章制度”，当然我们有个更形象的说法--潜规则。让他们必须遵守，当然并不是每个程序员都会严格遵守这些“规章制度”的，而且这些潜规则随着时间、具体情况也会出现修改潜规则。但是最后的目的就是把这些潜规则整成一套自动执行的检查框架，每天早上一来就开始跑一下，然后根据工具产生的错误日志，定点定位的去解决一些问题。这里给大家推荐一些静态代码检查工具吧，PC-lint、CppCheck...省略了很多自己开发的工具，因为公司保密原则，所以不便一一列举。但是如果能充分应用好这两个工具，代码问题基本上不会出现问题，但是你要做好面对PC-lint、CppCheck产生的庞大的日志，并且有效的处理它们。最后搭建成自动化测试框架就成为水到渠成的事了。

        动态测试，简言之：覆盖。相比静态而言要复杂的多，而且不管用哪个工具都不可能完全适应项目。这里要说的动态检查工具有Google gTest、CppUnit、动态调试、日志形式的记录...关于gTest网上有一系列很经典的文章，但是那只是入门，真正要符合自己实际项目的需要必须做出很多很大的改动和新的应用。相比而言比CppUnit简单、有效。当然gTest的核心思想是继承自CppUnit，就连伟大的JUnit也是继承自CppUnit，可想而知CppUnit是多么权威，归纳起来就是gTest和CppUnit可以归纳起来就是单元测试，是要编写测试用例才能有效地使用的。虽然利于总结和传承但是对于少数逻辑上的和代码调用层次复杂的却只能无能为力。这个时候动态调试就发挥作用了，它以优雅、高效的身影，一直被程序员们追捧。但是解决完问题之后，就没了。通过跟踪代码所走过的路，路就没了，我们测试根本就不能够去确保或者重现这些错误，而且是没有积累和总结的。当然相比动态调试在效用、和性能方面做了一个这种的办法就是日志记录，记录程序中每一个变量在执行过程中的数值，从而达到跟踪代码，也就是所谓的代码覆盖了。

        好了，今天就说到这里吧。白盒测试在国内还刚开始起步，将来还有很长很长的路要走，希望各位有志从事这个行业的人能够发明更多更好的方法，应用更好的思想来指导白盒测试。