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

　　对于工作，我想从我们测试的角度来谈一些问题，当然也还希望大家可以一起讨论。

　　对于流程的调整，主要考虑怎样来实现工作的高效率和有效性，还有不同团队间的互动和交流。比如，我希望我们可以努力建立如下的工作流程：

　　1、需求阶段。对于开发组和测试组来说，这个阶段都是很重要得，因为我们也都体会到了需求变动对设计和开发以及测试的影响。我希望在下面的开发中，把需求放到一个决定性的位置上，虽然需求变动必然会出现，但是我们应当尽力避免掉其中的一些，主要是避免掉那些用户认为是他们的日常工作，很正常很简单的事情而没有提出的部分。通常在我们深入的研究需求和一些算法的时候，会发现这些东西。

　　我考虑从测试工作这边可以调整一下，来帮助完善需求工作。具体如下：

　　在需求阶段开始功能测试用例的设计和计划测试工作。将依照需求来完成大部分同主要业务相关的功能测试用例的设计，期望通过测试人员对业务的不同观察角度来理解需求，尽量找出需求中缺失的或者有偏差的部分；

　　将需求作为指导整个测试工作的高级文档，可以理解为“宪法”，设计文档、具体实现不得违背需求文档中的要求，对于defect的定义也将在很大程度上参考需求文档（在本文档的后说明这个defect的判断标准）；

　　对于需求文档，还要关注于文档本身的书写问题，比如是否存在二义性，是否描述准确，这个工作是检查需求文档的可测试性，也是检查需求文档是否可以很好的为测试提供依据和帮助；

　　另外，我还希望对于需求文档进行版本的控制，已经确定的需求文档进入设计和开发过程后，不应当发生变化，如果的确发生了变化或者增加了新的需求，那么应当在补充需求中说明。而且，还希望将需求在项目组内的讨论和评审作为一个有有效的工作手段使用起来。

　　2、设计阶段。这个阶段测试人员的工作主要是确认设计同需求是否对应，尽量避免同开发人员对需求的不同理解，并要保证设计文档的可测试性和描述的准确性。重点是根据详细设计文档完善、添加测试用例，重点在功能测试、性能测试和数据相关性及完整性测试方面的测试用例。

　　3、实现阶段。在开发组的编码实现阶段，测试组的工作仍将关注于测试的前期准备工作。除了继续完善原有的测试用例，将重点考虑UI测试用例。同时，考虑将适合自动化测试的用例编写成测试教本。另外，还要准备测试数据，完成执行测试前的所有准备工作。

　　4、执行阶段。这个阶段主要任务是根据测试用例进行实际的测试工作，同时提交defect，并对已经处理的defect进行回归测试。另外，还要考虑版本迭代时需要进行的衰减测试。对于一些测试用例中没有涉及到的内容，而在实际操作中发现问题的情况，作为补充测试用例加入测试用例集。

　　5、评估阶段。测试结束时，对测试工作进行总结和有效性评估，对测试流程中发现的细节问题进行调整或改进，抽取出尽量多的高层的内容，使尽量多得内容和方法可以在下一个版本的测试中迭代使用。（结束）

　　对于每个测试阶段我还会制定出一个进入和退出规则，什么时候开始那个阶段的工作，什么时候结束这个阶段进入下一个阶段，都会明确的指出。哦，还会有一个对于整个测试流程工作的详细描述的文档来清楚的表述整个测试流程中所有的任务，特别是上面几个阶段中的同工作相关的一些细节问题。

　　另外一个工作是测试用例的设计，这个问题将作为今年重要的一件事情来对待，主要考虑提高测试用例的有效性和可维护性。

　　个人一些看法，还希望有机会继续讨论、完善。