银行领域应用测试项目
托马斯·汉密尔顿
⚡ 智能摘要
银行业应用测试旨在验证处理敏感交易的金融软件的功能、性能和安全性。本教程将介绍领域知识、银行应用特性、测试阶段、示例测试用例以及针对银行、金融服务和保险 (BFSI) 行业特有风险的关键缓解策略。
银行领域测试
银行领域测试 软件测试是对银行应用程序进行功能、性能和安全性测试的过程。银行应用程序测试的主要目的是确保银行软件的所有活动和功能都能流畅运行，无任何错误，并确保软件始终受到保护。
银行、金融服务和保险 (BFSI) 行业是 IT 服务的最大消费行业。银行应用程序直接处理机密的财务数据，因此，银行软件执行的每一项操作都必须可靠且无误地运行。银行软件的功能包括资金转账和存款、余额查询、交易记录和取款等。对银行应用程序进行测试，不仅能确保这些操作正确执行，还能确保其免受黑客攻击。
测试中的域是什么？
测试中的域 指的是软件测试项目所针对的行业。该术语在讨论软件项目和开发时经常使用。例如，保险领域、银行领域、零售领域和电信领域。
虽然开发ping 任何特定领域的项目，通常都需要寻求领域专家的帮助。领域专家是该领域的专家，对应用程序了如指掌。
为什么领域知识很重要？
领域知识对于任何软件产品的测试都至关重要，因为它能直接提高测试覆盖率、缺陷检出率和利益相关者的信心。了解银行业务流程的测试人员能够发现非领域测试人员完全忽略的极端情况。
银行领域知识 – 简介
银行业领域概念广泛，大致可细分为两个部门：
- 传统银行业
- 服务型银行业
下表列出了这两个子行业所涵盖的服务。
| 行业领域 | 包含的服务 |
|---|---|
| 传统银行业 | 核心银行系统、公司银行系统、零售银行系统 |
| 服务型银行业 | 核心业务、企业业务、零售业务、贷款业务、贸易融资业务、私人银行业务、消费金融业务、伊斯兰银行业务、客户交付渠道/前端交付 |
根据项目范围，您可能需要测试上述一项或多项服务。在开始测试之前，请确保您对被测服务有足够的了解。
银行应用程序的特征
在开始测试之前，务必了解任何银行应用程序都应具备的标准功能，以便您可以根据这些特性调整测试工作。标准的银行应用程序应满足以下要求：
- 支持数千个并发用户会话。
- 可与交易账户、账单支付、信用卡等多种应用程序集成。
- 处理快速安全的交易。
- 配备一个大型存储系统。
- 提供强大的审计能力，以排查客户问题。
- 处理复杂的业务流程。
- 支持多平台用户（Mac、Linux、Unix、 Windows).
- 支持来自多个地点的用户。
- 支持多语言用户。
- 支持用户使用各种支付系统（VISA、AMEX、MasterCard）。
- 支持多个服务领域（贷款、零售银行等）。
- 提供万无一失的灾害管理机制。
需要测试的银行应用程序类型
地图之前ping 在测试阶段，了解哪些银行应用程序通常在测试范围内会有所帮助：
- 核心银行系统（CBS）： 存款、贷款和账户的中央引擎。
- 网上银行： 面向客户的用于转账和账单支付的网络门户。
- 手机银行： iOS和 Android 具备生物识别和通知功能的应用程序。
- ATM和自助服务终端软件： 自动取款机上的嵌入式软件。
- 支付网关： 银行卡、UPI 和钱包交易处理程序。
- 贷款和财务模块： 后台信贷和外汇应用程序。
银行应用程序测试的测试阶段
一旦确定了测试范围内的应用，测试通常会按以下几个阶段进行。
- 需求分析： 由业务分析师执行，负责收集和记录特定银行应用程序的需求。
- 需求 Review： 质量分析师、业务分析师和开发主管审查需求文档并进行交叉检查，以确保其不会破坏任何现有的工作流程。
- 业务需求文档： 质量分析师编写业务需求文档，涵盖所有已审核的需求。
- 数据库测试： 银行应用测试中最重要的部分。它验证数据完整性、数据加载、数据迁移、存储过程、功能验证和业务规则。
- 集成测试： 下 整合测试所有已开发的组件都已集成并一起验证。
- 功能测试： 标准测试活动，例如 测试用例 在此阶段，将进行准备、测试用例审查和执行。
- 安全测试： 确保软件不存在安全漏洞。质量保证团队应包含正反两方面的测试场景，尝试入侵系统并在任何未经授权的人员发现漏洞之前将其报告。银行还应强制执行多层访问验证，例如一次性密码。自动化工具通常用于…… 安全测试 包括 IBM AppScan 和 HP WebInspect， 手动测试 通常依赖于 Proxy Sniffer、Paros Proxy 和 HTTP Watch。
- 可用性测试: 确保残疾用户能够像其他用户一样轻松使用系统——例如，配备语音指导和盲文键盘的自动取款机，方便残障人士使用。
- 用户验收测试： 最后阶段由最终用户执行，以确认应用程序在实际场景中运行正常。
网上银行登录应用程序的测试用例示例
对于任何银行应用程序而言，安全性都至关重要。在测试准备阶段，质量保证团队应同时包含负面和正面测试场景，以便在未经授权的人员发现漏洞之前对其进行探测并报告。这意味着不仅要编写负面测试用例，还要编写破坏性测试用例。
下表列出了银行应用程序的通用测试用例。
| 区域 | 示例测试用例 |
|---|---|
| 管理員 | 使用有效和无效数据验证管理员登录；管理员无数据登录；所有管理员主页链接；管理员使用有效、无效和现有数据更改密码；管理员注销。 |
| 新分行 | 创建包含有效、无效和现有数据的新分支；创建不包含数据的新分支；重置和取消；更新包含有效、无效和现有数据的分支；取消；删除包含和不包含依赖项的分支；分支搜索。 |
| 新角色 | 使用有效、无效、现有数据创建新角色；创建不带数据的角色；验证角色描述和类型；取消和重置；删除有依赖项和无依赖项的角色；验证角色详细信息页面上的链接。 |
| 顾客和访客 | 验证所有访客和客户链接；客户登录时使用有效、无效或无数据；银行家登录时使用有效、无效或无数据。 |
| 新用户 | 使用有效、无效和现有分支数据创建新用户；创建时不带数据；取消并重置；使用有效、无效和现有数据更新用户；取消；删除用户。 |
银行业测试领域面临的挑战及其缓解措施
即使拥有完善的测试阶段和模板，测试人员在银行业项目中仍然会面临一些反复出现的挑战。以下缓解措施已在实际项目中证明有效。
| 挑战 | 减轻 |
|---|---|
| 获取生产数据并将其复制为测试数据非常困难。 | 通过数据脱敏、合成测试数据和系统集成测试，确保测试数据符合监管合规要求并维护机密性。 |
| 从旧的银行系统迁移到新的银行系统——包括流程、程序和数据上传——是最大的挑战。 | 对新旧系统进行完整的数据迁移测试和回归测试用例，比较结果直到两者一致。 |
| 需求文档可能不完善，导致功能性缺失。非功能性需求通常没有文档记录，因此测试人员不知道是否需要对其进行测试。 | 测试人员应从需求分析阶段开始参与，并积极审查业务需求。 |
| 验证系统是否遵循既定的政策和程序。 | 进行合规性和监管政策测试。 |
| 随着银行应用程序与互联网的集成，其范围和时间表也在不断扩大。 电话 银行业。 | 当银行应用程序有很多外部接口时，应在计划中预留足够的时间进行集成测试。 |
