信息化系统项目测试验收方案Word文档格式.docx

1、系统测试通常是在功能验证阶段完成，验证了核心功能后进行。它倾向于把整个系统作为一个整体来查找问题弄清Web服务作为系统的一部分怎样运作，以及 Web 服务相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行，所以通常不能给它分配足够的时间来完成。又因为紧张的发行日程安排以及开发的各个重要阶段的后移，系统测试阶段经常被忽略，并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误，这时也来不及确定错误的原因并设法修 复它们了。因此，在查找代码错误时，必需把系统测试应用设计得尽可能高效。系统测试通常由三部分组成，它们是：性能： 这涉及到确定相关的产品统计数据的过程。例如：每秒

2、有多少条消息，一个服务可同时接受多少个用户。压力（或称工作负载平衡）：它与另两个部分不同，因为它被设计为通过应用很大的工作负载来使软件超负荷运转。如果压力测试通过对产品保持高强度的使用（但不超过性能统计数字确定的限制）能有效地执行，那么它就经常能够发现许多隐蔽的错误，而这些错误用上面提到的任何其它技术都是发现不了的（这些错误也经常是最难修复的）。从检测代码错误这方面来说，可以证明这三个系统测试组件中效率最高的是压力测试部分。但由于这个过程经常跟系统的其它要素或功能测试混淆在一起，所以这个过程涉及到的方法还没有被正确着手处理或实现。1.2压力下的错误使用压力测试，有两种错误类型是：内存泄漏：一种

3、极难检测的现象。内存泄漏经常发生在已发行的产品中，原因很简单，很难设计测试 用例来检测它们。使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作要重复非常多的次数以使内存消耗达到能引起注意的程度。并发与同步：压力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。一般的规则是，压力测试运行的时间越长，涉及并应用的代码路径组合和定时条件就越多。当然，这也的确使得这些问题很难再现（错误可以在 5 分钟或 5 天后发生）。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测

4、出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑他或她的代码将与其它地方的代码（在执行单元测试时这些代码可能还没写出来）进行交互。1.3现有的压力测试工具有许多声称能够对产品进行压力测试的可用工具目前正在开发中。被广泛应用的是针对 Web服务的那些工具。然而，这些工具中有许多只是简单的 HTML/SOAP 生成器，它们模拟许多客户机连接，并因此对Web服务器生成高负载（这对于查找 Web服务器的问题很有用，但对于查找Web服务的问题就没那么有用了）。这些工具对基本的压力测试比较有用，但它们经常是仅仅扩展功能验证阶段来重复地执行相同的功能任务。如果足够的时间和资源可用，就可以

5、通过创建定制构建的压力测试系统来实现更有效的测试。由于压力系统的设计者通常对要测试的产品和 Web 服务有更多的了解，所以他们将能够确保压力系统可以用于哪些具体的代码区域。1.4设计压力应用设计试图对Web服务进行压力测试的压力测试系统时，要让它们以某种特定的方式运行代码。这些风格超越了功能验证，目的是要弄清楚被测试的Web服务是不是不仅能做我们认为它能做的事，而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对Web服务应用四个基本条件。许多已建立的压力系统应用了这些条件。有效的压力测试系统将应用以下这些关键条件：重复：或许最明显的且最容易理解的压力条件就是测试的重复。换句话

6、说，测试的重复就是一遍又一遍地执行某个操作或功能，比如重复调用一个Web 服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。这对于推断一个产品 是否适用于某种生产情况至关重要。客户通常会重复使用产品，因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件，但简单地扩展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时，重复就可以发现许多隐蔽的代码错误。并发：并发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试，例如在同一个服务器上同时调用许多 Web

7、 服务。这个原则不一定适用于所有的产品（比如无状态服务），但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能测出 来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一个Web服务压力测试需要一次模拟多个客户机。Web服务（或者任何多线程代码）通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引入并发性意味着一个线程中的代码有可能被其它线程中的代码中断，所以错误只在一个指令集以特定的顺序（例如以特定的定时条件

8、）执行时才会被发现。把这个原 则与重复原则结合在一起，您可以应用许多代码路径和定时条件。量级：压力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如，一个 Web服务允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是，您增加了这个操作的量级。这个量级 总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它。例如，数据的大小、延迟的长度、数量的转移、输入速度以及输入的变化等等。单独的高强度操作自身可能发现不了代码错误（或者仅能发现功能上的缺陷），但

9、与其它压力原则结合在一起时，将可以增加发现问题的机会。随机变化： 最后任何压力系统都多多少少具有一些随机性。如果随机使用前面的压力原则中介绍的无数变化形式，就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生命周期内改变测试的示例。使用重复时，在重新启动或重新连接服务之前，可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的Web服务的顺序。使用并发，可以改变一起执行的 Web服务、同一时间运行的Web服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。量级或许是最容易更改的， 每次重复测试时都可以更改应用程序中出现的变量（例如，发送各

10、种大小的消息或数字输入值）。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的机会就会更大。一个压力测试通常会结合上述的所有原则，并且在允许的范围内尽可能长时间地运行。测试被允许的执行时间越长，就可以遍历越多的代码路径，并且发现的错误也越多。当然，一旦找到错误就必须 诊断并修复它。由于一个代码错误可以在压力测试运行多日以后自己显示出来，所以系统必须保证当出现错误时所有可用的调试信息都被生成 否则可能就必须花费同样多的时间来重现这个错误。测试是软件开发过程中至关重要的部分，并且一个重要的、经常被曲解或忽略的部分是压

11、力测试。遵循上面的原则，就可以设计并实现有效的压力测试系统，用来查找一些与您的代码相关的、比较隐蔽的问题。无论是利用预先写好的工具，还是创建一个完全专用的压力系统，压力测试都是用于查找问题的本质方法，并能最终提高系统的质量。测试的主要内容包括：1.5功能测试测试目标确保测试对象的功能正常，符合业务办理逻辑技术利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。完成标准所计划的测试已全部执行。所发现的缺陷已全部解决。需考虑的特殊事项无1.6用户界面测试核实以下内容：通过测试

12、对象进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab 健、鼠标移动、和快捷键）的使用窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。操作符合业务人员的习惯，为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。成功地核实出各个窗口都与设计保持一致，符合业务人员的操作习惯。无。1.7性能评测核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量（50个并发用户访问时）预期的最繁重工作量（200个并发用户访问时）正常的业务办理。调用楼盘。调用档案材料。大数据量的查

13、询和统计。使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项”）上重复。系统能否正常完成功能。响应时间是否能达到合同要求。综合的性能测试还包括在服务器上添加后台工作量。可采用多种方法来执行此操作，其中包括：直接将“事务强行分配到”服务器上，这通常以“结构化查询语言”（SQL） 调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。此负载可通过“远程终端仿真”（Remote T

14、erminal Emulation） 工具来实现。此技术还可用于在网络中加载“流量”。使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。1.7负载测试核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。50个用户情况下应用系统速度和服务器的工作负载情况。200个用户情况下应用系统速度和服务器的工作负载情况。使用程序方式模拟多用户并发操作的情形。系统能够正常运行，服务器CPU和内存的使用在可接受范围之内。负载测试应该在专用的计算机上或

15、在专用的机时内执行，以便实现完全的控制和精确的评测。负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。1.8强度测试核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：服务器上几乎没有或根本没有可用的内存（RAM 和 DASD）连接或模拟了最大实际（实际允许）数量的客户机多个用户对相同的数据或账户执行相同的事务最繁重的事务量或最差的事务组合（请参见上面的“性能测试”）。注：强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的情况或条件。使用为性能评测或负载测试制定的测试。要对有限的资源进行测试，就应该在一台计算机上运行测试，而且应该减少或限制服务器上的 RAM 和 DA

16、SD。对于其他强度测试，应该使用多台客户机来运行相同的测试或互补的测试，以产生最繁重的事务量或最差的事务组合。所计划的测试已全部执行，并且在达到或超出指定的系统限制时没有出现任何软件故障，或者导致系统出现故障的条件并不在指定的条件范围之内。如果要增加网络工作强度，可能会需要使用网络工具来给网络加载消息或信息包。应该暂时减少用于系统的 DASD，以限制数据库可用空间的增长。使多个客户机对相同的记录或数据账户同时进行的访问达到同步。1.9容量测试核实测试对象在以下高容量条件下能否正常运行：连接或模拟了最大（实际或实际允许）数量的客户机，所有客户机在长时间内执行相同的、且情况（性能）最坏的业务功能。

17、已达到最大的数据库大小（实际的或按比例缩放的），而且同时执行了多个查询或报表事务。使用为性能评测或负载测试制定的测试。应该使用多台客户机来运行相同的测试或互补的测试，以便在长时间内产生最繁重的事务量或最差的事务组合（请参见上面的“强度测试”）。创建最大的数据库大小（实际的、按比例缩放的、或填充了代表性数据的数据库），并使用多台客户机在长时间内同时运行查询和报表事务。所计划的测试已全部执行，而且在达到或超出指定的系统限制时没有出现任何软件故障。对于上述的高容量条件，哪个时间段是可以接受的时间？1.10安全性和访问控制测试应用程序级别的安全性：核实业务人员只能访问其所属用户类型已被授权访问的那些功

18、能或数据。系统级别的安全性：核实只有具备系统和应用程序访问权限的业务人员才能访问系统和应用程序。确定并列出各用户类型及其被授权访问的功能或数据。为各用户类型创建测试，并通过创建各用户类型所特有的事务来核实其权限。修改用户类型并为相同的用户重新运行测试。对于每种用户类型，确保正确地提供或拒绝了这些附加的功能或数据。系统级别的访问：请参见以下的“需考虑的特殊事项”各种已知的人员类型都可访问相应的功能或数据，而且所有事务都按照预期的方式运行，并在先前的应用程序功能测试中运行了所有的事务。必须与相应的网络或系统管理员一起对系统访问权进行检查和讨论。1.11配置测试核实测试对象可在所需的硬件和软件配置中

19、正常运行。使用功能测试脚本。在测试过程中或在测试开始之前，打开各种与非测试对象相关的软件（例如 Microsoft 应用程序：Excel 和 Word），然后将其关闭。执行所选的事务，以模拟主角与测试对象软件和非测试对象软件之间的交互。重复上述步骤，尽量减少客户机工作站上的常规可用内存。对于测试对象软件和非测试对象软件的各种组合，所有事务都成功完成，没有出现任何故障。需要、可以使用并可以通过桌面访问哪种非测试对象软件？通常使用的是哪些应用程序？应用程序正在运行什么数据？例如，在 Excel 中打开的大型电子表格，或是在 Word 中打开的 100 页文档。作为此测试的一部分，应将整个系统、Ne

20、tware、网络服务器、数据库等都记录下来。项目验收系统验收是根据以上所涉及的系统测试方法，对项目建设情况进行验证，并最终签署项目验收并进行项目成果移交。2.1验收目的为使该项目建设按照用户项目建设要求进行，确保项目竣工后达到有关要求和标准，并能正常投入运行，必须进行项目验收。2.2验收对象项目建设平台、业务应用以及相关的文档资料等。2.3项目验收的前提条件1）所有建设项目按照合同要求全部建成，并满足使用要求；2）已通过功能确认测试评审；3）已通过系统性能测试评审；4）系统已置于配置管理之下；5）各种技术文档和验收资料完备，符合合同的内容；6）项目建设和数据处理符合要求；7）合同规定的其他验收

21、条件。2.4验收依据作为项目验收需要有一定的验收依据，本项目的验收选用项目合同书（以及国标、行业标准和相关政策法规、国际惯例等）、项目招投标文件作为项目验收的依据，对项目的系统功能、性能以及相关文档进行测试验证。2.5验收方法项目验收是项目开发建设中有组织的主动性行为，它是对项目建设高度负责的体现，也是项目建设成功的重要保证。切实做好项目建设中的验收工作至关重要，应当采取有效措施，实实在在做好。为保证项目验收质量，针对不同的验收内容，在实施验收操作中，可以采取以下不同的方法：1）登记法对项目中所设计的所有内容进行登记，不可遗漏，并妥善保管。对项目建设中根据实际进展情况双方同意后修订的合同条款、

22、协调发展建设中的问题进行登记。2）对照法对照检查项目各项建设内容的结果是否与合同条款及项目建设需求报告方案、项目实施方案一致。3）操作法这是项目建设最主要的验收方法。首先，对项目检验其管理硬件及应用软件的实际能力是否与合同规定的一致；然后对运行应用软件，实际操作，处理业务，检查是否与合同规定的一致，达到了预期的目的。2.6验收步骤1）需求分析 项目建设单位组织人员与项目业主单位对项目进行验收需求分析，针对项目验收，项目建设单位和业主单位均需配备有经验的工程师和行业专家来组成项目团队，负责具体的工作。2）成立项目验收小组实施测试验收工作时，应当成立项目验收小组，具体负责验收事宜。3）项目验收的实

23、施严格按照合同进行全面的测试和验收。4）提交初步验收报告项目验收完毕，对项目情况等做出全面的评价，得出初步结论性意见，对不合格的项目予以指出，对严重问题提出具体的解决要求及意见。5）召开项目验收评审会召开由验收委员会全体成员参加的项目验收评审会，全面细致的审核项目验收测试小组所提交的验收报告，给出最终的验收意见，形成最终验收评审报告，验收委员会成员签字，并提交给项目建设单位以及业主进行存档。2.7验收结论标准1）项目验收结论标准验收结果分为:验收合格、需要复议和验收不合格三种。2）验收结论确认和处理业主单位及相关部门组织人员对验收报告和相关结论资料进行确认，对项目验收结论进行确认。对验收结论为验收合格的，项目业主单位将全部验收材料装订成册并连同相应的电子文档备案。验收结论需要复验的，项目业主单位以书面形式通知建设单位在规定时间内补充有关材料或者进行相关说明。验收结论为验收不合格的，项目业主单位以书面形式通知项目建设单位，限期进行整改，整改后试运行合格的，项目建设单位重新申请验收。项目未通过验收的，不得交付使用。2.8项目交接项目竣工验收合格后，与项目业主单位进行项目交接手续办理。项目的移交包括实体移交和项目文件移交两部分。