管理决定效率，方法决定效果。万事皆如此。

　　《兵法》有云：夫未战而庙算胜者，得算多也；夫未战而庙算不胜者，得算少也。多算胜少算，而况于无算乎！

　　首先讨论当前测试部能做哪些工作。按照我们当前的开发情况，下一步将全部使用三层架构，两个开发组会按照所涉及的不同业务区分开发任务，同时开发人员也会相应的增加。单从现在的良医项目来看，使用三层架构后，将会继续增加系统的复杂程度，原因是在客户端、中间层和数据库服务器端会存在不同的业务对象，而所有业务对象间可能出现的路径也会增加。个人认为这种情况下需要开展组件测试、集成测试和系统测试。其中，组件测试和集成测试面向代码级别，系统测试面向应用程序级别。组件测试主要考虑对系统各层中存在的单个组件进行测试，检查该组件是否符合设计要求，对于相应的输入是否作出相应的动作，是否有相应的输出，这个阶段就像检查一个螺母的质量，要检查它的内径、外径、重量、高度以及螺纹是否符合设计要求等等，而这个螺母虽然是整台机器中不可缺少的部件，但它作为一个个体是不能完成任何功能的；集成测试则是重点检查组件之间的接口问题，检查多个组件是否能完成一项既定的功能，多个组件之间是否可以正常的协同工作，就好像将一个螺丝穿过一块钢板，而再将我们上面测试过的螺母拧上，如果螺丝和螺母无法紧密的结合在一起，则说明不同的组件之间的接口有问题。对于组件测试和集成测试，都可以使用黑盒测试方法和白盒测试方法来进行测试。

　　开展组件测试和集成测试的好处是从开发工作一开始，测试工作就可以介入，在早期将问题尽量限制在组件一层——或者说单元这个层面；当一个个组件经过测试验证已经到达设计要求时，再开始集成测试，这时如果出现问题，则可以局限在组件之间的接口这部分。而使用“逐步集成”，或者叫“持续集成”的方法，可以将出现缺陷的范围限制在可以控制的范围内，有利于对项目进度的把握。

　　不过，基于当前测试部的人手和能力，还无法开展组件测试和集成测试，因为人手不够，下一步即使增加到5个人，也同样无法对所有程序员的代码进行测试；同时，进行组件测试和集成测试需要开发“驱动模块”和“存根模块”，都需要针对不同的测试用例开发不同的应用程序来完成测试。同时，进行这样的工作对于人员要求也比较高，通常需要测试部配备测试用例设计人员、测试脚本开发人员、“驱动模块”和“存根模块”的设计人员、“驱动模块”和“存根模块”的开发人员，当然，同时还要有测试项目的管理人员和独立的数据库、配置管理人员。而最为关键的问题是，如果要进行组件测试和集成测试，那么整个项目需要按照一个严格的规范来进行，不同的任务之间环环相扣。比如如果前期系统分析和设计做的不够明确，而导致在开发过程中频频出现变化，那么就很难在开发过程中同时进行测试脚本和测试程序的开发。

　　我们现在可以开展的，成本相对较低，而效果比较好的是系统测试。系统测试在技术和方法方面相对成熟，而开展起来也比较容易，我们可以把精力更多的放到探索操作流程和工作方法上，而只要这些工作做扎实，引入新的技术和工具就会带来相对好的效果；相反的，如果操作流程不够明确，也没有一些有效的便于复制的工作方法，介入新的领域将必定会带来混乱。所以还是应该由易到难、循序渐进的进行尝试。

　　现在考虑对于系统测试，将涉及到五个测试类型，分别是：功能测试、性能测试、兼容性测试、界面测试和数据相关性与完整性测试。逐个解释如下：

　　1、功能测试。主要包括对系统所涵盖的实际业务的测试。这里的实际业务是指用户在不使用计算机时同样要进行的工作，比如物资的出库，必定会填写新的出库单，而出库单的填写也必定会符合一定的要求（业务规则），而出库单的处理也一定会由一些规定的流程（比如申请，审核，出库）。这部分将不考虑因为计算机系统的设计而增加的内容。

　　2、性能测试。这部分同其他系统的定义一样，主要考虑系统在不同的测试环境中对于业务的处理能力。届时将考虑客户端/服务器硬件配置、客户端/服务器软件配置、客户端/服务器资源占用情况、网络负载情况、大量业务处理、并发处理等情况。

　　3、兼容性测试。这部分主要测试公司开发的系统在不同的硬件平台和软件平台上运行时的兼容情况。对于硬件主要考虑不同打印机对打印的影响，操作系统主要考虑不同windows版本对系统运行的影响，同时，还要考虑一些常用应用程序对系统的影响，比如这段时间就发现了”清华紫光输入法“同DEV的一些控件存在冲突。如果将来涉及到广域网，还将考虑同广域网相关的一些情况。

　　4、界面测试。这部分主要测试系统中为了实现用户需要的功能而添加的同实际业务没有直接关系的部分。比如快捷键、图标的显示、文字的显示、界面的初始化、可输入控件的输入类型/长度限制、网格中列的位置调整/排序调整等等。这里关键的一点是同功能测试的区分，功能测试包含的是用户在实际工作中必须要进行的业务，而界面测试则面向那些为了实现用户需要的功能而在计算机上表现出来的东西。或许更准确的说功能测试的用例将主要来源于需求，而界面测试的用例更多的来自于设计和实现。

　　5、数据相关性与完整性测试。这部分也可以同功能测试做一个比较。对于功能测试，也同样会考虑数据的准确性问题，但是这部分测试将主要局限于单个子系统中。比如门诊收费，在对处方划价收费后，就减少药房的帐面库存，并修改处方的标志位。门诊收费子系统的操作到此为止，而负责收费的操作员对于药房中的变化并不关心，因为这部分已经超出了他的业务范围，但是药房的操作员的业务就同这些变化相关。那么这部分涉及到多个系统间数据流的测试就属于数据相关性和完整性测试。