银行综合核心业务系统之卡系统测试方法与实施毕业论文

在于检验它是否满足约定的需求或是比较预期结果与实际结果之间的差别。这一定义非常明确地提出了软件测试以检验是否满足需求为目标。

个人对软件测试概念即过程的总结：软件测试就是由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，编写测试案例，实施测试，记录测试结果并对测试记录进行分析，通过提交BUG的形式反馈给开发人员，并根据回归验证情况撰写测试报告，最终解决问题，保障产品最终质量的一个过程。

2.3 软件测试的目的

简单的讲，软件测试的目的就是： a).找出错误（未发现的错误）； b).验证（功能，性能）。

软件测试的目的是为了证明程序有错，而不能保证程序没有错误。 个人对软件测试的亲身感受：起目的就是通过各种软件测试测试手段，尽量多的发现软件存在的各种缺陷，验证软件是否符合需求、软件功能是否实现，来保证软件质量。

2.4 软件测试的分类

软件测试技术静态测试代码走查技术评审代码审查黑盒测试动态测试回归测试白盒测试功能测试性能测试攻击测试逻辑覆盖基本路径测试因果图等价类特值法随机边界值图2-1软件测试分类

2.5 软件测试计划

软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试。

其做好测试计划工作的关键 ：目的，管理，规范 A. 明确测试的目标，增强测试计划的实用性

编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确

B. 坚持“5W”规则，明确内容与过程

“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。 C. 采用评审和更新机制，保证测试计划满足实际需求

测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。 D. 分别创建测试计划与测试详细规格、测试用例

应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

第三章 测试用例

3.1 测试用例概念

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

3.2 设计方法

在软件测试中，都会给客户交付测试计划、测试用例、测试报告、用户手册等各种文档，但对于测试而言，测试用例是很重要的文档，然而如何去设计好测试用例，一直是值得各测试人员所思考的问题。目前全国大部分的公司都运用黑盒测试的方法进行测试，其针对黑盒测试而言，如何去设计更好的测试用例是作为测试人员必须掌握的一项基本工作。

测试用例的设计人们都会想到运用黑盒测试中比较常用的方法等阶类划分法、边界值分析法、错误推测法、因果分析法等。这些只是针对一个小的模块，甚至一个小输入框而言的。而我们在项目中如何设计测试用例是个重点问题。

其实，大多项目的测试都可分为界面测试、数据测试、业务测试、流程测试等几个类型，在设计测试用例的时候可根据测试功能的特性进行设计，将不同类型的测试分开来进行设计，保证测试用例不冗余且条理清晰。

? 界面测试：所有的项目都是由界面显示，这是最基础的一部分。界面中包含

文本框、下拉框、大文本输入框、日期、文本（即标签）等各控件，且可点击输入框后的图标弹出一个新的窗口进行选择，也包含保存、取消、新增、删除、编辑、查看等各种按钮，数据量庞大时会分页显示等，在同一界面上的，可以将界面上同类型的放在一起进行设计。

? 数据测试：项目中的各个模块都有数据的流动，一些基本的增删改查只要保

证检测数据的正确性即可，比较有代表性的是报表的测试。针对报表，准备一些基础数据，然后通过计算，设计出报表输出结果，需保存各计算公式的正确性即可。

? 业务测试：主要是各基础模块间的数据传递，保证接口的正确，及业务的正

确。这种类型的测试，可根据业务图进行设计，遍历各分支即可。 ? 流程测试：主要是同一模块中，不同角色不同人员之间数据的流动，比较代

表性的是OA系统中的审批。这种类型的设计，需了解各种流程中需要哪些角色哪些人员参与，然后组合各种情况，遍边各个流程分支进行设计

另外，对于一个项目而言，肯定有些是公用的，比如说分页，各个页面 都统一调用同一分页，因此在设计时只需设计一个分页即可，其他页面用到时调用即可，不需重复设计。很多增删改查及各类型控件的检测基本都是一致的，都可放入公共用例中，进行调用即可，避免用例的冗余。

3.3 用例编写

当有了明确的需求说明书后，况且系统框架基本稳定，测试人员根据测试用例的设计原则，则开始进行测试用例的准备，下面长春农商行借记卡模块ATM加/清钞交易为例，编写出的测试用例：

表3-1长春借记卡ATM加/卸钞（012015）差异功能测试用例 测试内容:长春借记卡ATM加/卸钞（012015）差异功能测试用例 用例代号 长春借记卡_ATM加/卸钞_001 长春借记卡_ATM加/卸钞_002 功能点 ATM加/卸钞--页面初始化--成功 ATM加/卸钞--页面初始化--成功 前置条件 测试步骤 根据交易代码进入ATM加/卸钞界面或通过左侧的菜单进入界面 1、加卸钞：A加钞 2、ATM终端编号：10000011 3、币种：人民币 1、加卸钞：A加钞 2、ATM终端编号：10000011 3、币种：人民币 4、金额：0 1、加卸钞：A加钞 2、ATM终端编号：10000011 3、币种：人民币 4、金额：100 1、加卸钞：R卸钞 2、ATM终端编号：10000011 3、币种：人民币 4、金额：0 预期结果 能够进入ATM加/卸钞页面 存在ATM终端编号和ATM虚拟柜员号及ATM地址 存在ATM终端编号和ATM虚拟柜员号及ATM地址 存在ATM终端编号和ATM虚拟柜员号及ATM地址 存在ATM终端编号和ATM虚拟柜员号及ATM地址 页面初始化正确，列表值正确 ATM虚拟柜员号和ATM地址自动回显 长春借记卡_ATM加/卸钞_003 ATM加/卸钞--加钞-失败 提示信息：金额必须大于0 长春借记卡_ATM加/卸钞_004 ATM加/卸钞--加钞-成功 经授权后，加钞成功 长春借记卡_ATM加/卸钞_005 ATM加/卸钞--卸钞-失败 提示信息：金额必须大于0