要说测试，首先要说测试的蓝本，也就是进行测试的依据——测试式样书，有的人也称其为case书，因为它是以case为单位的，一个测试点就是一个case。一个项目测试结果的质量根本就在于测试式样书的好坏，如果case书里面详尽，你实施起来就可以走遍所有的情况，不管是正常还是异常；如果case书写的比较拙劣，那就只能凭借测试人员的经验和水平了，但是纵观经历的几个项目，测试人员都是只有一两年工作经验的同事，而且他们的经验还不只是测试方面的，所以这么一交叉，测试经验就可想而知了，如果有个三四年经验的leader来领导测试可能还会好点，但他最好不是纯粹的开发人员，开发和测试还是有很大不同的，说说就跑偏了，回到正题，如果你是一个leader，你要么有比较好的测试式样书，要么有个比较有经验的测试工作者，起码工作三年以上。

　　测试其实是一个很考验思维的活：有的式样业务分歧比较多，当你为了测试不同的情况而造了七八组数据时，你会感慨为啥这么麻烦，但有人面对同样的测试点，可能只会造三四组数据，因为他的每组数据可以跑更多的点，走更多的情况，这个就是测试思想的问题了，你应该在造数据的时候尽量多个case组合到一个用例中，这也就要求了你要纵观整个case书后再进行测试，而且最好是按照业务流程把每一条线都分清楚，此时可以用不同的颜色在文档中进行标记，划分不同的pattern，然后就可以每组每组有条不紊的进行了。

　　测试还是一个很考察细心的活：一个case一个点，不能看着某个case和另外的一个比较相似就一块画OK或者NG，更不能想当然的去填入判断结果，测试测多了就会感觉画面中就是这样表示的，然后就在某个项目后画上OK了，但其实不然，这个项目的固定文言可能就有个字不正确，或者读出的数据格式format不正确，所以必须千真万确的校对后才能在那个框框里写上结果。

　　测试一定要有正确的标准：虽然测试时有式样书可以参照，但是某些项目它只是写了预期结果，具体如何进行它并没有提及到，此时就要求你得跟你的leader去确认，待掌握了正确的测试方法后再进行，比如测更新操作的排他，有的通过不同用户进行相同的操作来测试，有的需要修改DB来测试，但还有的要依靠开发环境通过debug来测试，所以要有正确的测试标准，掌握对的测试方法。

　　测试还需要有一定的原则性：作为测试人员就是要完成测试case，找到程序的bug，然后找开发人员解决，使程序更加完善。这个过程中我们要和开发人员站到对立的方向，不能跟着他们的思维走，面对一个问题，case书里是这样描述的，而他却说开发就只能开发成那样的，遇到这样的问题，就要跟leader反映，然后找到正确的标准，肯定不能跟着开发者的思路，随意的进行确认。

　　测试还需要一双善于发现“美”的眼睛：当case书描述的情况不是很全面时，我们就需要根据自己的经验和感觉去发现程序的不足，也许这个经验来自你的一个错误操作，也许来自你某次的网上经历，要抱着一个怀疑的态度去进行测试，相信它的程序肯定有问题。

　　最后再总结一下，测试对于程序就相当与数学中的验算，要保证数学题的正确就要对他进行一系列的验算，即使你再聪明也有马虎的时候，这时候就体现出了验算的作用，同样的道理再牛的程序员也会有失误的时候，测试就是来找到这些点，然后改掉它。