应用系统设计及验收技术规范Word文件下载.doc
- 文档编号:8447272
- 上传时间:2023-05-11
- 格式:DOC
- 页数:8
- 大小:56.50KB
应用系统设计及验收技术规范Word文件下载.doc
《应用系统设计及验收技术规范Word文件下载.doc》由会员分享,可在线阅读,更多相关《应用系统设计及验收技术规范Word文件下载.doc(8页珍藏版)》请在冰点文库上搜索。
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.预期的最繁重工作量
可采用多种方法来执行此操作,其中包括:
1.直接将事务强行分配到服务器上,这通常以结构化查询语言的调用的来实现。
2.通过创建虚拟的用户负载来模拟许多个客户机。
此负载可通过远程终端仿真工具来实现。
此技术还可用于在网络中加载流量。
3.使用多台实际客户机运行测试脚本,在系统上添加负载。
性能测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。
性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。
第十八条强度测试
找出因资源不足或资源争用而导致的错误。
强度测试还可用于确定测试对象能够处理的最大工作量。
核实测试对象能够在以下强度条件下正常运行,不会出现任何错误:
1.服务器上几乎没有或根本没有可用的内存。
2.连接或模拟了最大实际允许数量的客户机。
3.多个用户对相同的数据或账户执行相同的事务。
第十九条容量测试
使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。
容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
核实测试对象在以下高容量条件下能否正常运行:
1.连接或模拟了最大数量的客户机,所有客户机在长时间内执行相同的、且资源开销最大的业务功能。
2.已达到最大的数据库大小(实际的或按比例缩放的),而且同时执行多个查询或报表事务。
第二十条安全性和访问控制测试
确保在预期的安全性情况下,用户只能访问特定的功能、用例,或者只能访问有限的数据。
可采用如下方法进行测试:
1.确定并列出各用户类型及其被授权访问的功能或数据。
2.为各用户类型创建测试,并通过创建各用户类型所特有的事务来核实其权限。
3.修改用户类型并为相同的用户重新运行测试。
第二十一条故障转移和恢复测试
确保测试对象能成功完成转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件和网络故障中恢复。
确保对于必须持续运行的系统,一旦发生故障,备用系统能够及时替代发生故障的系统,以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。
在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障。
然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。
在所有上述情况中,应用程序、数据库和系统应该在恢复过程完成时立即返回到一个已知的预期状态。
第二十二条安装测试
确保该软件在正常情况和异常情况的不同条件下(例如,进行首次安装、升级、完整的或自定义的安装)都能进行安装;
核实软件在安装后可立即正常运行。
该测试主要用于客户端软件的安装。
核实测试对象在以下条件下能否正常运行:
启动或执行安装,使用预先确定的功能测试脚本来运行事务。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应用 系统 设计 验收 技术规范