金融管理系统测试报告（内部测试案例）

无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。我们力求在每个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；

经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。

目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对它做必要的测试（称为单元测试），模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这顶工作。

大量统计资料表明，软件测试的工作量往往占软件开发总工作量的 40 ％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此，必须高度重视软件测试工作．绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终日的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。

备注：

UT = Unit Test 单元测试

IT = System Integration Test 集成测试
ST = System Test 系统测试

UAT = User Acceptance Test 用户接受测试(俗称:验收测试)

NDS=Network Design Software 网络环境搭建（俗称：测试人员）

测试过程

由于不断增加新的需求，在最终系统上线前还要经过多阶段、多方面的验证过程。才可以更加有效的降低风险。

2.1阶段过程

上线投产前会有3种基本状态：开发、测试、投产。每个状态中的变更修改相互独立，从而保证开发中的程序修改不影响测试，测试结果不影响已发布的应用程序。

2.2人员安排

2.3测试过程

本次测试主要集中在系统测试。

2.3.1集成测试阶段

目的：

在把各个模块连接起来的时候，测试数据是否会丢失；
一个模块的功能是否会对另一个模块的功能产生不利的影响；
各个子功能组合起来，能否达到预期要求的父功能；
全局数据结构是否有问题；
单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。

集成阶段可以分为两个部分：

一部分是个人产品销售辅助系统集成到银行整体系统上的软件方面测试工作；
一部分是硬件设备、网络的系统集成测试工作；

本阶段，测试的重点是验证外部系统是否能与本系统集成、本系统的主要业务功能是否实现，特别要关注系统之间的数据接口是否正确

集成测试阶段安排：

集成测试从 5月 8 日至 5 月 30 日，共计17个工作日，计划安排三轮测试工作;
计划5~6个工作日测试一轮，执行 3 轮测试，需要对每轮的测试进度及质量进行跟踪，随着程序稳定后加快测试进度；
每轮测试完成后，将上一轮的测试数据全部清空，以全量的方式进行下一轮测试，测试过程中以增量方式发布，NDS 不用改动；
NDS 会单独提供一个测试环境，需要提供必需的测试数据：5月8日前 NDS 环境准备完成；
NDS 准备的新环境，如果为空库，需要准备测试数据(5月8日前准备完成并备份一份，排轮测试进行时还原数据)：如果库中有存量数据，可使用存量数据，无需再准备数据；

集成测试层次：

备注：规约即需求，如对方给与的文档等相关资料

2.3.2系统测试阶段

集成测试与系统测试的区别：

系统测试对象是整个系统以及与系统交互的硬件和软件平台。系统测试更多程度上是站在用户的角度上对系统做功能性的验证，同时还对系统进行一些非功能性的验证，包括系统测试测试、压力测试、安全性测试、恢复性测试等。系统测试的依据来自用户的需求规格说明书和行业的已成文的或事实上的标准。
集成测试所测试的对象是模块间的接口，其目的是要找出在模块接口上面，包括整体体系结构上的问题。其测试的依据来自系统的高层设计（架构设计或概要设计）。
软件的集成测试工作最好由不属于该软件开发组的软件设计人员承担，以提高集成测试的效果。

集成测试完成并达到预定目标后，即可以进入系统测试阶段。系统测试阶段的主要测试内容为验证个人产品销售辅助系统各功能、流程是否正确实现．确保系统的各项功能满足业务需求功能说明书，达到预期目标，提交UAT 测试。

系统测试阶段安排：

系统测试时间从7月3日至7月20日，共计14个工作日，计划安排三轮测试工作；
计划4-5个工作日为一轮，共执行三轮测试，测试过程中需要对测试的进度及质量进行跟踪，随着测试的进行，程序逐渐稳定，可以适当加快测试进度；
每轮测试完成后，仍然要将上一轮的测试数据全部清空，以全量的方式进行下一轮测试，测试过程中以增量方式发布，NDS 不用改动；
NDS 提供的测试环境与集成测试环境为同一环境，测试数据完成为NDS的真实数据；
需要 NDS 提供的各种数据必需在7月3日前完成提供。

2.3.3UAT测试阶段

UAT测试简介：

UAT测试，英文User Acceptance Test的简写，也就是用户验收测试，或用户可接受测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收，它让系统用户决定是否接收系统，它是一项确定产品是否能够满足合同或用户所规定需求的测试。

经过集成和系统两阶段的测试，软硬件已基本达到要求，在UAT 阶段主要验证软件在真实软硬件环境设备下的最终功能表现，以及最终的回归测试使用。

中国银行业务人员对产品销售辅助系统从业务流程及功能实现上进行验证，达到与中国银行需求相符，并对软件功能实现予以最终确认。

UAT阶段安排

UAT 测试主要由银行业务人员进行，时间为 7月21日-7月 10 日共计15个工作日
UAT 使用的测试硬件环境为系统的生产环境
计划4-5个工作日测试一轮，执行3轮测试，最后一轮安排进行回归测试，随着程序稳定后加快测试进度
UAT 测试过程中发现的问题，开发人员修改完成后，由公司测试人员在系统测试环境上进行测试，则试通过再打新的版本上UAT 环境
每轮执行完发布新版本以全量方式，测试过程中以增量方式发布
每轮测试前，清除数据库数据，以初始状态进行测试；NDS数据不需要改动

2.3.4性能测试

性能测试主要是根据用户提供的系统性能需求，通过科学的方法计算出系统需要支持的最佳并发数和最大并发数，并在测试过程中监控系统如何响应时间、吞吐量、请求数、服务器的CPU利用率、硬盘使用情况、网络使用情况的等。测试过程中，对系统进行调优，已达到客户的性能需求标准。具体性能测试内容请见4.3性能测试。

2.4版本发布过程

软件版本发布后是需要按阶段顺序验证进行的，当本阶段验证完成后才会发布到后一阶段进行验证；当某一阶段发现程序问题后，需要开发修正问题．提交新版本程序，并按阶段顺序重新验证后再发布到当前阶段验证测试。图中SIT环境即为集成测试和系统测试所用环境。

测试流程

根据测试工作实施的先后顺序，个人产品销售辅助系统的测试分为初始阶段、测试计划阶段、测试设计阶段、测试执行阶段、总结评估阶段。

3.1初始阶段

初始阶段主要是给测试人员做测试介绍，加强测试人员对测试过程和测试标准了解。

介绍内容包括：

介绍测试方法和特点
介绍测试结果评估、分析方法
介绍测试过程
介绍测试策略

3.2测试计划阶段

测试计划阶段主要是项目测试人员参与相应的需求培训，开始编制测试计划，分析测试风险要素，置顶测试范围测试目标，制定测试需求。

工作内容包括:
组织测试培训
编制测试需求
编辑测试计划

3.3测试设计阶段

测试设计阶段主要是根据测试需求设计测试用例。

工作内容包括：

分解个人产品销售辅助系统为具体的测试单元
定义测试用例
建立需求覆盖
设计测试步骤

3.4测试执行阶段

测试执行阶段主要是测试人员根据测试用例进行相应的测试工作，发现缺陷和问题后和开发人员进行沟通，并且对缺陷的解决和问题的回复进行相应的处理。

工作内容包括：

按照测试用例进行测试
填写测试报告
缺陷跟踪

测试执行过程：

问题处理流程：

3.5总结评估阶段

总结评估阶段主要是统计分析测试结果并编写测试分析报告

工作内容包括：

整理测试过程数据和问题记录
分析数据
编制总结分析报告
评估测试结果

测试内容

保证上线质量，测试主要包括正确性测试、容错性测试、性能测试等内容。

4.1测试类型

测试类型	是否采用	说明
功能测试	采用	根据系统需求文档和设计文档，检查产品是否正确实现了功能
流程测试	采用	按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程正反流程，检查软件在流程操作时是否能够正确处理
边界值测试	采用	选择边界数据进行测试，确保系统功能正常，程序无异常。
容错性测试	采用	检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，且程序对错误的输入有正确的提示信息。
异常测试	采用	检查系统能否处理异常
启动停止测试	采用	检查每个模块能否正常启动停止、异常停止后能否正常启动
易用性测试	采用	检查系统能否易用友好
界面测试	采用	检查界面是否美观合理
性能测试	采用	测试系统各关键环节基本性能指标，尤其是并发、相应时间等指标；检查系统能否承受大性能，测试产品应该能够在高强度条件下正常运行，不会出现任何错误

4.2测试技术

测试技术	是否采用	说明
审评测试	采用	里程碑的达成标准及验收方法在测试完后制定
编写测试用例	采用	在产品编码阶段编写测试用例
单元测试	采用	有开发人员进行
确认测试	采用	在产品提交前，进行基本需求的确认，确认产品是否正确实现了功能
集成测试	采用	检测模块集成后的系统是否达到需求对业务流程及数据流的处理是否符合标准、系统对业务流处理是否存在逻辑不严谨及错误以及是否存在不合理的标准及要求。
系统测试	采用	包括功能测试和回归测试

4.3性能测试

1.测试范围与目的：

范围：个人产品销售辅助系统各项性能指标，反应时间的性能测试，例如：页面加载显示数据的速度，查询或翻页时数据显示的速度。

目的：尽可能提高各项性能指标的运行速度。发现系统中可能隐藏的并发访问时的问题。例如系统中的内存泄漏、线程锁和资源争用方面的问题。

2.性能测试用例：

1）疲劳强度测试：

A、在系统稳定运行下模拟最大用户数量、并长时间运行系统，通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能。

B、疲劳强度测试的目的就是检验系统长时间运行后的性能，因此设计用例时，需要编写不同参数或者负载条件下的多个测试用例，对服务器、软件、网络进行不同条件下的综合测试分析，测试时要记录系统发生故障的信息作为测试结果。疲劳强度测试也是采用测试工具进行的。

2）大数据量测试：

A、一是针对某些系统存储、传输、统计查询等业务进行大数据量的测试；另一个是与前面并发测试相结合的综合数据测试。编写用例时主要编写前一部分，后一部分尽量放在并发测试中。

B、大数据量测试一般是针对那些对数据库有特殊要求的系统进行测试，例如电信业务系统的手机短信息表，由于有的用户关机或者不在服务区，每秒钟需要有大量的短信息保存，同时在用户联机后还要及时发送，因此对数据库性能有极高的要求，需要专门测试。

业务	场景
登录	利用N(5、10、20)个用户登录系统，并在系统中停留10s后集体退出
登录	利用N(5、10、20)个用户每3s登录系统，并在系统中停留3s后逐个退出
查询	利用N(5、10、20)个用户对系统查询模块中的查询功能进行点击,并在系统中停留10s后集体退出
查询	利用N(5、10、20)个用户每3s一个对系统查询模块中的查询功能进行点击,并在系统中停留3s后集体退出

5、测试过程标准

5.1整体测试要点

5.1.1设计功能测试

1、测试范围与目标

范围：

对系统中的文本框，下拉菜单，单选钮，多选钮，一些操作性的按钮等进行测试。

目的：

提高数据的准确性，方便用户操作。

2、测试案例

测试对象	测试要点	操作	期望输出	实际输出
文本框	输入正常的数值或字母	像文本框中输入数值或字母	能够正常输入数值或字母	与期望相符
	输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理;	将一大串数值或字母输入文本框	能够正常运行	与期望相符
	输入默认值，空白	选择文本框，按空格键输入空白	能够输入	与期望相符
	若只允许输入字母，尝试输入数字;反之;尝试输入字母	在需要输如数字的文本框中输入非数值，反之。	不能输入	与期望相符
	利用复制，粘贴等操作强制输入程序不允许的输入数据;	赋值一点文本，粘贴到只读文本框中;	不能输入	与期望相符
单选按钮控件	一组单选按钮不能同时选中，只能选中一个。		只能选择一个	与期望相符
	逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”，或是相应的代号	再有单选钮的添加功能中选择单选按钮进行添加	添加的数据能与所选择的单选按钮的数据对应	与期望相符
	一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空;		使用单选按钮时有默认选择的项	与期望相符
复选框	多个复选框是否可以被同时选中;		多个复选框可以被同时选中;	与期望相符
复选框	多个复选框是否可以都不被选中;		多个复选框可以都不被选中;	与期望相符
命令按钮	点击按钮正确响应操作。如，单击确定，正确执行操作;单击取消，退出窗口;		能够正常运行	与期望相符

5.1.2功能测试

1、测试范围与目的

范围：

主要测试添加，删除，查询等功能进行测试。

目的：

结合广大用户的需求，逐步完善各个功能，使各个功能能够正常运行。

2、测试案例

测试对象	测试要点	操作	期望	实际
添加功能	要添加的数据项均合理，检查数据库是否添加了相应的数据	输入正确的数据	数据库会添加一条新数据，并且数据与输入时相符合。	与期望相符
	留出一个必填的数据为空	留出一个必填的数据项，然后添加	给出相应的提示	与期望相符
	不符合要求的地方要有错误提示	再填写数值的地方填写字母后添加	给出相应提示	与期望相符
	是否支持table键		支持	支持
	按Enter键是否能够保存	按table键，直至到添加按钮后按Enter键	可以正常保存	可以正常保存
	若提示不能保存，也要查看数据库里是否多了一条数据		数据库不会多出新的数据	与期望相符
删除	删除是不选择要删除的对象	不选择列表中的行，直接点击删除按钮	给出提示，要求选择对象	与期望相符
	选择数据进行删除时，是否给出提示确认删除		给出提示框，带有确认（是）和取消（否）两个按钮	与期望相符
	删除成功后，查看数据库数据是否少了删除的数据（或改变了数据的某个字段的值，使其不能显示）	选择要删除的数据，然后进行删除	给出删除成功提示，并刷新列表	与期望相符
	若删除失败，要查看数据库数据是不是和删除之前一样。	选择要删除的数据，然后进行删除	给出删除失败提示	与期望相符
查询	输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据	从列表中复制要查询的条件，粘贴到查询文本框中，点击查询按钮	能够查询与条件相符的对应数据	与期望相符
	输入正确的查询条件之前加上空格，看是否能正确地查出相应的数据	从列表中复制要查询的条件，按空格键后，粘贴条件后查询	无视空格，查询与条件相符的对应数据	与期望相符
	输入格式或范围不符合要求的数据，看是否有错误提示	在输入数值范围的文本框输入字母	查不到任何数据	与期望相符
	输入数据库中不存在的数据		查不到任何数据	与期望相符
	是否支持table		支持	支持

5.1.3界面测试

1、测试范围与目标

范围：

主要针对系统整体的界面颜色，控件大小以及样式进行测试。

目的：

增强页面的美感，增强用户体验!

2、测试案例

测试对象	测试要点	操作	期望	实际
页面	页面大小合适，控件布局合理
	子窗体添加完数据后，是否刷新父页面显示的数据		子页面添加完数据后，刷新父页面所显示的数据	与期望相符
	在浏览器中运行系统时，缩放浏览器窗体，是否会随着浏览气的大小变化而变化	将浏览伸缩，观察页面布局	在浏览器中运行系统时，缩放浏览器窗体，页面布局应随着浏览气的大小变化而变化	与期望相符
菜单	选择菜单是否可以正常工作,并与实际执行内容一致;	点击系统的各个菜单	选择菜单应打开相应的数据模块	与期望相符
菜单	是否有错别字		不应有错别字	与期望相符

5.1.4容错性测试

1、测试范围与目的

范围：

主要对系统中的字符串长度，数据格式，非法参数等进行测试

目的：

保证系统的稳定性和一致性。

2、测试案例

测试对象	测试要点	操作	期望	实际
数据边界性测试	时间类型文本框填写其他类型数据	在时间文本框中输入字母，	给出相应提示。	与期望相符
	文本类型超出应用设定长度	在文本框中输入超长文本	给出相应提示	与期望相符
	是否对输入内容的进行自动转换，以防止用户内容出现输入错误	在数字文本框中输入非数字	将输入的非数字清除（小数点除外），且小数点只能有一个并且跟在数值后面	与期望相符

5.1.5安全性测试

1、测试范围与目的

范围：

用户注册、修改密码、用户权限、URL安全、Cookie安全等。

目的：

保证软件安全程度,防止黑客入侵!

2、测试案例

测试对象	测试要点	操作	期望	实际
用户注册	填写符合要求的数据注册，用户名字和密码都已最大长度	在注册文本框中输入最大字符串	能够注册成功	与期望相符
	填写符合要求的数据注册，用户名字和密码都已最大长度	在注册文本框中输入最小字符串	能够注册成功	与期望相符
	重新注册存在的用户		不能注册并给出提示	与期望相符
	用户名长度大于或小于要求注册的一位。		不能注册并给出提示	与期望相符
修改密码	新密码与确认密码不一致		不能修改，给出提示	与期望相符

5.1.6可靠性测试

软件可靠性是指“在规定的时间内,规定的条件下,软件不引起系统失效的能力,其概率度量称为软件可靠度”;

测试范围及目的

范围：

A、软件可靠性测试活动；

B、软件可靠性增长测试过程；

目的：

A、有效地发现程序中影响软件可靠性的缺陷,从而实现可靠性增长。

B、验证软件可靠性满足一定的要求。

C、验证软件可靠性满足一定的要求

2、测试用例

A、可靠性测试活动：

B、可靠性增长测试过程

软件可靠性增长测试是为了满足用户对软件的可靠性要求、提高软件可靠性水平而对软件进行的测试。是为了满足软件的可靠性指标要求,对软件进行测试—可靠性分析—修改—再测试—再分析—再修改的循环过程。

5.2缺陷修复率和覆盖率标准

缺陷修复率标准

二级错误修复率应达到100%
四及错误修复率应达到90%以上

五级错误修复率应达到80%以上

覆盖率标准

测试用例执行覆盖率应达到100%

测试需求覆盖率应达到100%

备注：覆盖率即测试完整度的衡量

5.3缺陷级别标准

缺陷应按照一定标准进行严重程度的划分，以此来确定软件开发的质量及确定修改缺陷的优先级别，本次采用以下缺陷程度定义进行划分：

严重程度	缺陷分类	描述
一级	致命缺陷（系统级）	造成操作系统、相关应用服务器宕机，整个网络系统瘫痪类系统级的 BUG。
二级	严重缺陷（应用级）	影响平台稳定性、部分网络系统瘫痪类应用级的BUG ，造成本应用系统宕机，相关的应用子系统宕机，架构类 BUG ，可移植性类 BUG，接口类 BUG，可重用性类 BUG 。
三级	一般缺陷（业务级）	业务处理终止或者出错类BUG，交易出错及其一致性类BUG，安全类BUG，容错类 BUG，性能类 BUG，算法类BUG，功能类 BUG等，
四级	微小缺陷（操作级）	易用性BUG，界面类BUG，提示信息类BUG。

5.4缺陷跟踪流程标准

根据中国银行的实际情况，计划本次缺陷的跟踪流程采用以下标准执行：

5.5缺陷的修改流程标准

本次测试的改错流程采用图5.5-1流程进行说明：

图5.5-1

6、测试工具

6.1测试工具概念

软件测试一般分为单元测试（模块测试）、集成测试（组装测试）、系统测试、业务测试和性能测试。

单元测试是测试软件模块级的功能和算法；集成测试是测试软件模块间的接口和通讯；业务测试足以需求说明书为依据，对软件的功能等测试；系统测试是将各软件环境、系统联通为一个完整的系统进行测试；性能测试则是对软件与硬件和其他相关因素的性能情况进行测试。

整个测试可以使用辅助测试工具TestDirector进行测试问题的记录维护、统计分析。

单元测试和集成测试在个人产品销售辅助系统的开发过程中完成．之后进行业务测试，再进行性能测试。

性能测试我们一般是指对于个人产品销售辅助系统的性能测试．性能测试可使用LoadRunner 等工具。

6.2缺陷跟踪系统TestDirector

缺陷跟踪系统TestDirector 是全过程问题跟踪系统，进行测试流程和测试后的管理。其最重要的功能是测试问题的记录管理，对于测试过程进行全面真实的记录，突出反映“暴露问题、角军决问题”的作用。

6.3性能测试工具

为了保证个人产品销售辅助系统能够平稳的上线运行，需要对系统的稳定性和系统性能进行一次全面的性能测试。这将对系统上线后的运行提供重要的参考，对个人产品销售辅助系统的稳定投产具有重要意义。

性能测试的原理就是使用专门的测试工其模拟大量的迭代请求和并发请求，反复执行一个测试的脚木（场景），通过监控网上银行的性能指标和相关信息来衡量并进一步设定参数优化系统性能。

本项目采用LoadRunner进行性能测试。

6.3.1LoadRunner

LoadRunner是Mercury Interactive 公司的产品，它同样可以通过模拟成千上万的用户行为实施并发负载及通过实时性能监控的方式来确定问题，并能预测系统行为并为个人产品销售辅助系统的优化提供参数依据。

通过 LoadRunner，测试人员可以轻松的创建多个虚拟用户，并向服务器发送请求，从而完成所需测试。

一般测试步骤是使用Visual User Generator生成脚本。使用Controller运行录制的脚本，在测试完成后调用Analysis 分析测试结果。