??管理决定效率，方法决定效果。万事皆如此。
??《兵法》有云：夫未战而庙算胜者，得算多也；夫未战而庙算不胜者，得算少也。多算胜少算，而况于无算乎！
??首先讨论当前测试部能做哪些工作。按照我们当前的开发情况，下一步将全部使用三层架构，两个开发组会按照所涉及的不同业务区分开发任务，同时开发人员也会相应的增加。单从现在的良医项目来看，使用三层架构后，将会继续增加系统的复杂程度，原因是在客户端、中间层和数据库服务器端会存在不同的业务对象，而所有业务对象间可能出现的路径也会增加。个人认为这种情况下需要开展组件测试、集成测试和系统测试。其中，组件测试和集成测试面向代码级别，系统测试面向应用程序级别。组件测试主要考虑对系统各层中存在的单个组件进行测试，检查该组件是否符合设计要求，对于相应的输入是否作出相应的动作，是否有相应的输出，这个阶段就像检查一个螺母的质量，要检查它的内径、外径、重量、高度以及螺纹是否符合设计要求等等，而这个螺母虽然是整台机器中不可缺少的部件，但它作为一个个体是不能完成任何功能的；集成测试则是重点检查组件之间的接口问题，检查多个组件是否能完成一项既定的功能，多个组件之间是否可以正常的协同工作，就好像将一个螺丝穿过一块钢板，而再将我们上面测试过的螺母拧上，如果螺丝和螺母无法紧密的结合在一起，则说明不同的组件之间的接口有问题。对于组件测试和集成测试，都可以使用黑盒测试方法和白盒测试方法来进行测试。
??开展组件测试和集成测试的好处是从开发工作一开始，测试工作就可以介入，在早期将问题尽量限制在组件一层——或者说单元这个层面；当一个个组件经过测试验证已经到达设计要求时，再开始集成测试，这时如果出现问题，则可以局限在组件之间的接口这部分。而使用“逐步集成”，或者叫“持续集成”的方法，可以将出现缺陷的范围限制在可以控制的范围内，有利于对项目进度的把握。
??不过，基于当前测试部的人手和能力，还无法开展组件测试和集成测试，因为人手不够，下一步即使增加到5个人，也同样无法对所有程序员的代码进行测试；同时，进行组件测试和集成测试需要开发“驱动模块”和“存根模块”，都需要针对不同的测试用例开发不同的应用程序来完成测试。同时，进行这样的工作对于人员要求也比较高，通常需要测试部配备测试用例设计人员、测试脚本开发人员、“驱动模块”和“存根模块”的设计人员、“驱动模块”和“存根模块”的开发人员，当然，同时还要有测试项目的管理人员和独立的数据库、配置管理人员。而最为关键的问题是，如果要进行组件测试和集成测试，那么整个项目需要按照一个严格的规范来进行，不同的任务之间环环相扣。比如如果前期系统分析和设计做的不够明确，而导致在开发过程中频频出现变化，那么就很难在开发过程中同时进行测试脚本和测试程序的开发。
??我们现在可以开展的，成本相对较低，而效果比较好的是系统测试。系统测试在技术和方法方面相对成熟，而开展起来也比较容易，我们可以把精力更多的放到探索操作流程和工作方法上，而只要这些工作做扎实，引入新的技术和工具就会带来相对好的效果；相反的，如果操作流程不够明确，也没有一些有效的便于复制的工作方法，介入新的领域将必定会带来混乱。所以还是应该由易到难、循序渐进的进行尝试。
??现在考虑对于系统测试，将涉及到五个测试类型，分别是：功能测试、性能测试、兼容性测试、界面测试和数据相关性与完整性测试。逐个解释如下：
??1.功能测试。主要包括对系统所涵盖的实际业务的测试。这里的实际业务是指用户在不使用计算机时同样要进行的工作，比如物资的出库，必定会填写新的出库单，而出库单的填写也必定会符合一定的要求（业务规则），而出库单的处理也一定会由一些规定的流程（比如申请，审核，出库）。这部分将不考虑因为计算机系统的设计而增加的内容。
??2.性能测试。这部分同其他系统的定义一样，主要考虑系统在不同的测试环境中对于业务的处理能力。届时将考虑客户端/服务器硬件配置、客户端/服务器软件配置、客户端/服务器资源占用情况、网络负载情况、大量业务处理、并发处理等情况。
??3.兼容性测试。这部分主要测试公司开发的系统在不同的硬件平台和软件平台上运行时的兼容情况。对于硬件主要考虑不同打印机对打印的影响，操作系统主要考虑不同windows版本对系统运行的影响，同时，还要考虑一些常用应用程序对系统的影响，比如这段时间就发现了”清华紫光输入法“同DEV的一些控件存在冲突。如果将来涉及到广域网，还将考虑同广域网相关的一些情况。
??4.界面测试。这部分主要测试系统中为了实现用户需要的功能而添加的同实际业务没有直接关系的部分。比如快捷键、图标的显示、文字的显示、界面的初始化、可输入控件的输入类型/长度限制、网格中列的位置调整/排序调整等等。这里关键的一点是同功能测试的区分，功能测试包含的是用户在实际工作中必须要进行的业务，而界面测试则面向那些为了实现用户需要的功能而在计算机上表现出来的东西。或许更准确的说功能测试的用例将主要来源于需求，而界面测试的用例更多的来自于设计和实现。
??5.数据相关性与完整性测试。这部分也可以同功能测试做一个比较。对于功能测试，也同样会考虑数据的准确性问题，但是这部分测试将主要局限于单个子系统中。比如门诊收费，在对处方划价收费后，就减少药房的帐面库存，并修改处方的标志位。门诊收费子系统的操作到此为止，而负责收费的操作员对于药房中的变化并不关心，因为这部分已经超出了他的业务范围，但是药房的操作员的业务就同这些变化相关。那么这部分涉及到多个系统间数据流的测试就属于数据相关性和完整性测试。
??对于工作，我想从我们测试的角度来谈一些问题，当然也还希望大家可以一起讨论。
??对于流程的调整，主要考虑怎样来实现工作的高效率和有效性，还有不同团队间的互动和交流。比如，我希望我们可以努力建立如下的工作流程：
??1.需求阶段。对于开发组和测试组来说，这个阶段都是很重要得，因为我们也都体会到了需求变动对设计和开发以及测试的影响。我希望在下面的开发中，把需求放到一个决定性的位置上，虽然需求变动必然会出现，但是我们应当尽力避免掉其中的一些，主要是避免掉那些用户认为是他们的日常工作，很正常很简单的事情而没有提出的部分。通常在我们深入的研究需求和一些算法的时候，就会发现这些东西。
??我考虑从测试工作这边可以调整一下，来帮助完善需求工作。具体如下：
??.在需求阶段开始功能测试用例的设计和计划测试工作。将依照需求来完成大部分同主要业务相关的功能测试用例的设计，期望通过测试人员对业务的不同观察角度来理解需求，尽量找出需求中缺失的或者有偏差的部分；
??.将需求作为指导整个测试工作的最高级文档，可以理解为“宪法”，设计文档、具体实现不得违背需求文档中的要求，对于defect的定义也将在很大程度上参考需求文档（在本文档的最后说明这个defect的判断标准）；
??.对于需求文档，还要关注于文档本身的书写问题，比如是否存在二义性，是否描述准确，这个工作是检查需求文档的可测试性，也就是检查需求文档是否可以很好的为测试提供依据和帮助；
??另外，我还希望对于需求文档进行版本的控制，已经确定的需求文档进入设计和开发过程后，不应当发生变化，如果的确发生了变化或者增加了新的需求，那么应当在补充需求中说明。而且，还希望将需求在项目组内的讨论和评审作为一个有有效的工作手段使用起来。
??2.设计阶段。这个阶段测试人员的工作主要是确认设计同需求是否对应，尽量避免同开发人员对需求的不同理解，并要保证设计文档的可测试性和描述的准确性。重点是根据详细设计文档完善、添加测试用例，重点在功能测试、性能测试和数据相关性及完整性测试方面的测试用例。
??3.实现阶段。在开发组的编码实现阶段，测试组的工作仍将关注于测试的前期准备工作。除了继续完善原有的测试用例，将重点考虑UI测试用例。同时，考虑将适合自动化测试的用例编写成测试教本。另外，还要准备测试数据，完成执行测试前的所有准备工作。
??4.执行阶段。这个阶段主要任务就是根据测试用例进行实际的测试工作，同时提交defect，并对已经处理的defect进行回归测试。另外，还要考虑版本迭代时需要进行的衰减测试。对于一些测试用例中没有涉及到的内容，而在实际操作中发现问题的情况，作为补充测试用例加入测试用例集。
??5.评估阶段。测试结束时，对测试工作进行总结和有效性评估，对测试流程中发现的细节问题进行调整或改进，抽取出尽量多的高层的内容，使尽量多得内容和方法可以在下一个版本的测试中迭代使用。（结束）
??对于每个测试阶段我还会制定出一个进入和退出规则，什么时候开始那个阶段的工作，什么时候结束这个阶段进入下一个阶段，都会明确的指出。哦，还会有一个对于整个测试流程工作的详细描述的文档来清楚的表述整个测试流程中所有的任务，特别是上面几个阶段中的同工作相关的一些细节问题。
??另外一个工作就是测试用例的设计，这个问题将作为今年最重要的一件事情来对待，主要考虑提高测试用例的有效性和可维护性。
??个人一些看法，还希望有机会继续讨论、完善。
??陈雷
??
本文地址：http://com.8s8s.com/it/it35960.htm