信息化系统项目测试验收方案.

信息化系统项目测试验收方案项目测试、验收方案项目测试计划测试是项目质量的重要保证，因此必须高度重视项目的测试工作。在本项目中，我们将着重进行以下三类测试：项目组内部测试主要实施者为我中心项目测试小组，该测试小组主要负责对整个测试过程的组织和实施。测试小组为整个系统测试的组织者和实施者。在项目组内部测试的过程中，除测试小组外，各分系统的开发者不仅是测试组测试前的“自我测试者”，同时也要承担一部分其它的测试任务，主要是对其它分系统的测试。通过这种方式的测试，一方面可以强化各个子系统在技术上的沟通，同时也可通过对他人开发的功能模块的测试发现自身所存在的不足之处。项目组内部测试要达到的目标是消除功能上的错误，排除系统的稳定性隐患，基本上达到系统的预定设计目标。业务人员测试在业务人员测试之前，系统必须经过项目组的内部测试，并经测试主管签字后，方可组织业务人员进行测试。业务人员测试的目标是看系统功能设计是否能够满足实际的需要，操作上是否简便，界面是否友好，并确认系统所产生的数据是符合业务需要的。压力测试 应用服务器处于分布式计算的核心位置，它们之间的交互通常很难测试。分布式开发、大型的开发者团队以及对代码日益组件化的期望都有可能使应用服务的开发变得越来越容易隐藏错误。这些类型的错误极难检测出来。压力测试是检测这类代码错误的一种有效方法，但是只有在压力系统设计得比较有效的情况下才能发挥作用。1.1测试方法传统的测试方法包括某种形式的简单单元测试，通常由开发人员执行。设计这些测试需要了解软件的内部知识，并且这些测试几乎总是针对产品的非常小的、特定的部分。这些类型的测试非常适合与其它代码组件极少交互，甚至没有交互的简单 Web服务。功能验证也是一种测试过程，在这个过程中，对产品源代码了解有限的设计者进行测试以确认产品或服务的核心功能。设计这种测试是为了证明这个核心功能符合某个规范这种测试也是适合简单的Web服务，使您可以检查服务是否能够正确执行它的各个功能。 系统测试通常是在功能验证阶段完成，验证了核心功能后进行。它倾向于把整个系统作为一个整体来查找问题弄清Web服务作为系统的一部分怎样运作，以及 Web 服务相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行，所以通常不能给它分配足够的时间来完成。又因为紧张的发行日程安排以及开发的各个重要阶段的后移，系统测试阶段经常被忽略，并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误，这时也来不及确定错误的原因并设法修 复它们了。因此，在查找代码错误时，必需把系统测试应用设计得尽可能高效。系统测试通常由三部分组成，它们是： 性能： 这涉及到确定相关的产品统计数据的过程。例如：每秒有多少条消息，一个服务可同时接受多少个用户。压力(或称工作负载平衡)：它与另两个部分不同，因为它被设计为通过应用很大的工作负载来使软件超负荷运转。如果压力测试通过对产品保持高强度的使用(但不超过性能统计数字确定的限制)能有效地执行，那么它就经常能够发现许多隐蔽的错误，而这些错误用上面提到的任何其它技术都是发现不了的(这些错误也经常是最难修复的)。从检测代码错误这方面来说，可以证明这三个系统测试组件中效率最高的是压力测试部分。但由于这个过程经常跟系统的其它要素或功能测试混淆在一起，所以这个过程涉及到的方法还没有被正确着手处理或实现。 1.2压力下的错误使用压力测试，有两种错误类型是：内存泄漏：一种极难检测的现象。内存泄漏经常发生在已发行的产品中，原因很简单，很难设计测试 用例来检测它们。使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作要重复非常多的次数以使内存消耗达到能引起注意的程度。并发与同步：压力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。一般的规则是，压力测试运行的时间越长，涉及并应用的代码路径组合和定时条件就越多。当然，这也的确使得这些问题很难再现(错误可以在 5 分钟或 5 天后发生)。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑他或她的代码将与其它地方的代码(在执行单元测试时这些代码可能还没写出来)进行交互。 1.3现有的压力测试工具有许多声称能够对产品进行压力测试的可用工具目前正在开发中。被广泛应用的是针对 Web服务的那些工具。然而，这些工具中有许多只是简单的 HTML/SOAP 生成器，它们模拟许多客户机连接，并因此对Web服务器生成高负载(这对于查找 Web服务器的问题很有用，但对于查找Web服务的问题就没那么有用了)。这些工具对基本的压力测试比较有用，但它们经常是仅仅