问：我过去在另一家公司，从调研、设计数据库设计功能、开发、测试、写文档、实施推动上线协调各方、培训、修改客户需求、接听客户电话都是开发部一伙人自己做。
现在这家公司还好点，有实施部，有客服部。测试就是他们在做。但也都是糊弄事，他们又不懂编程，深层次问题都测不出来，只能测些表面问题。况且，我们过去没有详细文档，他们测试也只能随便点几下，录几个ABC看看能不能保存，保存后再查询能不能出来数据，数据出来后对不对。他们又不使用系统，而客户是每天要使用系统的，一使用问题立刻出来了，客户说我们都把他们当测试品了。客户抱怨很大呀，实施部对我们意见也很大，说我们质量很差。虽然说实施部应该好好测，因为毕竟客户出了问题先找他们，但是他们毕竟不是使用者，要么乱点，要么简单敲几个字母。怎么测也测不出来。
我们测试确实很有问题，那测试应该怎么做呢？
答：测试应该雇佣熟悉数据库操作并且有客户实施经验的人。因为测试不仅仅是表面的测试，而且数据库内部变化也要测试。测试还要针对不同的测试目的，有不同的测试方法，需要准备不同的测试数据，所以让一天在外出差培训的实施部去临时兼任测试是不可取的。
测试必须是开发部的一部份，是开发部的人员，而不要单独再成立一个部门，否则又多了一条裂缝，还需要分散精力去搞定他们。
测试从开发设计的第一阶段就在全程参与。从设计测试到编码测试到帮助文档测试。
首先，业务能不能走通，业务有没有什么矛盾？业务组长在设计业务功能，测试组就在测试是否有问题。
技术大牛也必须在产品设计第一阶段就要全程参与。如果他一门心思就在考虑技术扩展，通用，那么有个通用功能交给他，他根本不知道这个功能未来会如何发展，他又怎么能设计出适合未来变化的接口呢？这也就是很多大牛学习了很多OO技术都改变不了软件变化的问题，因为他们根本不知道软件会怎样变化，只能骂中国社会变化太快也解决不了问题。
只有这样，技术大牛在设计数据库的时候，才能知道怎么扩展并且结构更灵活，性能更高，并且为编程方便、查询方便、以后多维统计也方便。
在这里，有一个关键点，就是数据库设计由业务组长出初稿，而技术大牛出终稿的方法。为什么要这样。因为技术大牛承担着通用功能和接口的开发，而业务组长只想着自己这个模块的方便，所以业务组长设计的数据库结构就有局限性。并且业务组长是业务型人才，所以设计的结构未必能承担以后的多维统计复杂报表的需要。而且各组组长思维不一致技术层次不一致，设计的数据库就千奇百怪了。所以，数据库设计必须采用这样的方法。
技术大牛设计完数据库结构，就需要业务组长评估测试，全程业务跑一遍，看看业务设计是否能全支持，并且非常方便的支持。
对于编码测试，在编码过程中我们就必须同步测试。我们不能把一切都投入进去，然后到了最后才说：我们看他能不能正常运行。当然，这样的结果往往大半都是不能正常运行。而这时候开发人员已经以为开发已经完成了，而且开发人员已经很疲惫心累了，早就想逃跑了，你根本无法再让他们花100%的精力去改正错误。所以我们要全程测试。
测试，非常有要求。
首先，测试什么功能。这个功能的设计界面、功能描述、输入要求、输出要求、数据库存储更新文档都要从设计阶段就参与、熟读、评估、建议。
第二，测试什么方面。测试有好几个层次：
1正确的操作，正确的输入，得到正确的输出
2正确的操作，不正确的输入，是否能阻拦
3不正确的操作，不正确的输入，是否能阻拦
4速度压力测试。录入速度，点击速度快，是否正常
5并发压力测试。多人并发，是否正常
6数据量压力测试。单笔数据量是否正常。总体数据量大，是否正常。
第三，测试人员根据测试层次以及设计文档，设计测试数据。所以，测试人员要求有客户经历，至少做过客户实施。只有这样，才能设计出合理的测试数据，而不是乱敲几个字母，或乱点击，没目标，没层次，没计划。
然后，开始测试。测试完毕后，记录下测试的时间，测试的人，测试的模块，测试的模块版本，测试的类型，测试的数据，测试的操作过程，测试的结果，有错误截屏幕下来。并且当时的数据库数据
对于帮助文档也要测试。因为设计也对了，编码也对了，但是最后客户的使用方法错了，那岂不是可惜。所以对帮助文档必须测试。就按照帮助文件的做法去操作，测试是否走的和过去的设计文档一致。
测试部门测试完了，就需要让实施人员和客服人员内部测试了。他们对系统内部不了解，他们也不是开发人员的思路，他们完全是一个普通的使用者，用户，他们会再次检查出很多开发人员意想不到的操作引发的错误。
但其实，经过公司内部测试完，其实这个产品仍然是实验室里的产品，没有经过客户现实的检验，到底设计的功能是否真的是客户实际操作，是否真的能解决客户问题，客户真的这样使用这个功能，这些都没有答案。我们需要去检验，怎么去检验，我们会在下面几讲中讲到。