应用系统设计及验收技术规范

应用系统设计及验收技术规范第一条 应用系统的开发过程可分为项目立项、开发商选择、系统设计、项目实施、系统验收和投入正式运行这几个阶段。其中，设计阶段和验收阶段是控制项目质量和实现项目目标的关键阶段。第二条 为了规范和统一公司各级信息中心在应用系统开发过程中设计和验收阶段的工作方式和方法，特制订本技术规范。本技术规范适用于公司管理各单位的信息管理工作。第三条 本技术规范的内容主要涵盖应用系统开发过程中的共性问题，如与其它专有的管理制度或技术规范内容交叠，应以专有的制度和规范为准。第一章 设 计第一节 概述第四条 设计是系统开发的基础，一切开发工作都建立在需求提出者、项目管理者和开发实施者等几方面共同确认的设计方案的基础上。因此，在系统的设计阶段，必须得到经过业务部门的信息中心负责人签字的设计方案，方可进入系统的实施阶段。第五条 系统设计方案一般分为两部分，即系统概要设计和系统详细设计。其中，（一）概要设计的主要内容是：1. 需求分析，将用户的需求进行归纳、筛选，在充分理解的基础上，对其进行分析，从而明确系统的目标、内容、范围和各项业务要求。2. 软件系统结构设计，通过对系统抽象和分解，将系统按照功能划分为模块，并明确模块间的相互关系和接口。3. 数据库结构设计，按照模块的划分，设计其底层数据的组织方式。（二）详细设计的其主要内容是：1. 功能模块详细设计，将概要设计的内容具体化。2. 用户界面设计，确定系统中信息的展现方式，并实现系统与用户的交互。3. 部署设计，制订系统的部署实施方案，也是上线计划的主要内容。4. 标准规范，说明系统开发中所有引用的标准、规范等，以及适用于本系统的相关约定等。作为系统设计阶段的成果，最终各方确认的系统设计方案应包含上述的各项内容。第二节 设计要求第六条 考虑到公司信息化战略的需要，信息管理的要求，以及具体的现实情况，对于应用系统的设计公司有以下几方面的要求和建议：（一）系统架构建议应用系统的整体架构采用三层的B/S结构，即web浏览服务层、应用业务逻辑层、数据库层，以便于对应用系统进行管理和部署，也容易部署和实施安全控制措施。系统的客户端应设计为瘦客户端，在客户端应尽可能不要求安装和设置，不进行业务逻辑处理工作。通过此设计可以方便的实施系统的部署和推广，并且避免了不同系统之间的客户端安装冲突的问题。（二）身份认证和权限管理应用系统的身份认证应与公司统一部署的活动目录集成，通过域服务器进行统一的身份认证。通过此设计可以保证各系统中的用户信息统一和一致，便于系统的维护和管理，也便于用户管理账户和密码。系统的权限管理模块建议采用“账户角色权限”的管理模式，三者之间可实现多对多的对应关系，可以达到对每一账户灵活的授予和撤销任何权限。权限管理模块中应实现权限的委托功能，为防止管理的混乱，还应做到委托后的账户无任何权限，不能正常使用，同时应对权限委托的情况进行记录。（三）系统日志建议在系统中设计日志功能，可以对账户的使用、重要操作和业务流程进行记录。第二章 验收第一节 概述第七条 系统验收是通过对应用系统的全面测试，验证系统的功能、性能和可靠性。也是对系统开发成败做出评定的过程。同时，系统验收还是项目质量控制的重要环节，开发费用核算的标志。第八条 鉴于系统验收的重要性，系统正式投入运行前，必须进行系统验收。验收应由信息中心、业务部门和开发商共同组织进行。第九条 在不具备系统验收的条件时，也不应该强行进行验收，以避免对资源的浪费。可将不具备测试条件的内容，或业务部门和开发商一致同意延期测试的内容，记录在双方达成的项目验收备忘录中，在日后具备条件时进行再进行测试。第十条 系统验收应按照如下的步骤进行：（一）制定测试计划1. 根据系统需求书收集和组织测试需求信息，确定测试范围和内容。2. 制定测试策略，针对测试内容确定测试类型、测试方法以及需要的测试工具等。3. 建立测试通过准则，根据项目实际情况为每一个层次的测试建立通过准则。4. 确定资源和进度，确定测试需要的软硬件资源、人力资源以及测试进度。（二）设计测试1. 设计测试用例，对每一个测试内容，确定其需要的测试用例、输入和预期结果。2. 确定测试用例的测试环境配置、需要的驱动界面。3. 根据界面原型为每一个测试用例定义详细的测试步骤。4. 为每一测试步骤定义详细的测试结果验证方法。5. 根据上述内容，汇总生成验收大纲。（三）实施测试1. 按照验收大纲进行测试。2. 手工或利用程序记录测试结果。3. 记录缺陷的详细情况以及发生条件。（四）对测试进行评估和分析1. 对每一个测试的结果进行分析。2. 对每一个测试覆盖情况进行评估。3. 对每一个发现的缺陷进行统计分析，并提出变更请求或其他处理意见。4. 确定每一个测试是否完成。第十一条 测试中缺陷的分类和测试通过的标准：级别1. 系统不运行，除非进行更正，否则测试将不能进行。级别2. 主要问题，该缺陷导致其它的相关测试被中止。级别3. 功能限制，测试在一般操作情况下不受影响，但在某种情况下不能实现既定的功能，或者该缺陷可能直接影响其它测试。级别4. 需完善的小问题，该缺陷仅影响当前测试并且整项测试工作能够完成。测试中出现级别1至3的缺陷时，该测试应被判定为不通过。第二节 各类测试说明第十二条 本节中将验收中可能进行的各类测试的目标、内容、方法加以说明，实际验收时可根据项目情况进行选择。在应用系统验收中必须进行的测试有：数据和数据库完整性测试功能测试集成测试性能评测安全性和访问控制测试第十三条 数据和数据库完整性测试其目标为：确保数据库访问方法和进程正常运行，数据不会遭到损坏。调用各个数据库访问方法和进程，在数据库中填充数据或对数据进行查询请求。检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件已正常发生；或者检查所返回的数据，确保检索到了正确的数据。在进行此项测试时，不应通过测试对象的用户界面进行测试，应直接在数据库中进行测试。第十四条 功能测试其目标为：核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：1. 在使用有效数据时得到预期的结果。2. 在使用无效数据时显示相应的错误消息或警告消息。3. 各业务规则都得到了正确的应用。此类测试基于黑盒技术，该技术通过用户界面与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。测试应侧重于所有可直接追踪到测试用例、业务功能和业务规则的测试需求。第十五条 集成测试其目标为：检测系统是否达到需求对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：1. 在使用有效数据时得到预期的结果。2. 在使用无效数据时显示相应的错误消息或警告消息。3. 各业务规则都得到了正确的应用。此阶段测试基于功能完成的测试。第十六条 用户界面测试其目标为：确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，用户界面测试还可确保用户界面中的对象按照预期的方式运行，并符合公司或行业的标准。为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的状态。第十七条 性能测试其目标为：核实性能需求是否都已满足，测试和评估系统在不同工作量条件下的性能行为，以及持续正常运行的能力。核实所指定的事务或业务功能在以下情况下的性能行为：1. 正常的预期工作量2. 预期的最繁重工作量可采用多种方法来执行此操作，其中包括：1. 直接将事务强行分配到服务器上，这通常以结构化查询语言的调用的来实现。2. 通过创建虚拟的用户负载来模拟许多个客户机。此负载可通过远程终端仿真工具来实现。此技术还可用于在网络中加载流量。3. 使用多台实际客户机运行测试脚本，在系统上添加负载。性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。第十八条 强度测试其目标为：找出因资源不足或资源争用而导致的错误。强度测试还可用于确定测试对象能够处理的最大工作量。核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：1. 服务器上几乎没有或根本没有可用的内存。2. 连接或模拟了最大实际允许数量的客户机。3. 多个用户对相同的数据或账户执行相同的事务。第十九条 容量测试其目标为：使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。核实测试对象在以下高容量条件下能否正常运行：1. 连接或模拟了最大数量的客户机，所有客户机在长时间内执行相同的、且资源开销最大的业务功能。2. 已达到最大的数据库大小（实际的或按比例缩放的），而且同时执行多个查询或报表事务。第二十条 安全性和访问控制测试其目标为：确保在预期的安全性情况下，用户只能访问特定的功能、用例，或者只能访问有限的数据。可采用如下方法进行测试：1. 确定并列出各用户类型及其被授权访问的功能或数据。2. 为各用户类型创建测试，并通过创建各用户类型所特有的事务来核实其权限。3. 修改用户类型并为相同的用户重新运行测试。第二十一条 故障转移和恢复测试其目标为：确保测试对象能成功完成转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件和网络故障中恢复。确保对于必须持续运行的系统，一旦发生故障，备用系统能够及时替代发生故障的系统，以避免丢失任何数据或事务。恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障。然后调用恢复进程并监测和检查应用程序和系统