软件测试-带你了解金融业务测试流程

项目准备

2.1金融项目专业术语

债权人：拿钱出来的企业或个人

借款人：贷款的企业或个人

投资：拿钱出来的人(承担风险)

投标：右边案例中100万中的部分份额(xxx项目现在缺100万，由于某种原因将100万变为’股份’让其他人来购买，任何人都可以按照要求来购买100万中的部分份额！)

债权转让：将债权转入给第三人的行为

等额本息：

等额本金：

提前还款：

2.2熟悉项目的步骤

1.熟悉项目的业务特性–-项目是干啥的？

项目介绍：是一个p2p项目，用于p2p的借款和投资管理

2.熟悉项目的用户—项目是给谁用的

角色和用户

前台：借款人，投资人

后台：平台管理员

3.熟悉项目的功能架构—项目的功能有哪些？

功能模块

该金融项目包含三个子系统：

(1).Web用户端

PC 站，供借款人和投资人使用

址：

功能模块：

借款人：借款人管理

投资人：理财管理

公共：登录，注册，会员中心，资金管理，账户管理，推广管理

(2).手机用户端

APP和 WAP 借款人和投资人使用

址：

功能模块：

登录，通用，借款，认证，用户中心，债权转让，推广，托管

(3) 后台管理系统

PC 站，内部运营管理系统

址：

功能模块：

登录，系统首页，借款管理，资金管理，认证管理，用户管理，内容管理，系统管理，统计管理，扩展管理

4.熟悉项目的技术架构—项目的技术实现是什么？

5.绘制架构图的目的，对系统的了解更加全面及方便写用例

1. 先画出前台和后台所有的组织架构图
2. 按照组织架构图的模块依次去操作系统和熟悉系统
3. 最终找到系统中最核心的模块

6.绘制技术架构图：

web用户端和手机用户端

(实际工作中web和手机用户端，对应的后台业务代码可以是同一套的，因为功能一样)

(前后端分离的项目需要做接口测试，不是前后端分离的不做接口测试)

操作流程：Web用户端—-web用户系统—-数据服务系统—-数据库

7. 绘制项目核心业务流程图：借款人— 站—投资人

1. 目的熟悉业务流程
2. 指导业务流程来编写测试用例

绘制方式:1) 按照业务流程格式绘制

2) 如果业务流程复杂可以将业务流程划分为若干个子流程图

项目的测试流程（除了5和6 和功能测试流程一样）

1，需求评审—评审前准备和评审过程

2，制定测试计划和方案—找测试计划模板和填写关键信息，评审测试计划

3，编写系统测试用例并评审—整理测试点和写测试用例

4，编写接口测试用例并评审

5，接口测试用例执行bug跟踪

6，系统测试用例执行bug跟踪

7，编写测试 告

功能测试优先级>接口测试

如果前后端同时就绪，直接进行功能测试（此时不做手工接口测试，自动化的接口测试在功能测试结束后进行）

如果后端代码就绪前端未就绪，只能先做手工接口测试

(自动化测试岗位：80%手工+20%的自动化)

1，需求评审（分析测试点，为写用例做准备）

评审前准备：

看需求说明书 把疑问点记下来

1. 明确自己负责的需求模块
2. 提前熟悉需求，记录对需求的疑问，为评审会议做准备
3. 针对需求描述，思考如果进行测试设计，只要需求的描述模糊或描述不清楚 不能完全支持写用例，就提出来。

评审过程中

l 产品，开发，测试开会来评审需求内容

l 目标：

评审需求说明书是否有遗漏

确保需求说明书清晰，明确

确保项目组的成员对于需求说明书的理解达成一致

借款和投资流程介绍：略

软件测试计划的核心内容

1. 测试的目标和范围
2. 执行计划的角色与职责
3. 任务的进度安排与资源分配
4. 风险估计与应急准备有关
5. 测试的准入和准出的标准

软件测试方案的核心内容

1. 测试的策略
2. 测试环境
3. 测试工具

测试计划和测试方案核心

1. 测什么
2. 谁来测
3. 怎么测

编写测试计划的步骤

提示：软件测试计划的进度安排要参照项目整体交付计划

1，找到/整合合适的文档模板

2，准备测试计划的核心内容

测试目标和测试范围

评估测试工作量

测试人员和时间

测试方法和工具

3，按照模板，编写软件测试计划文档

4，测试团队内外沟通，确认软件测试计划

评审测试计划

1. 测试计划文档涵盖了核心内容
2. 测试计划合理，可行，能够达成目标
3. 测试方法正确，有效，能够指导具体工作
   注意：测试过程中，根据测试工作开展的实际情况及时调整测试计划。

功能测试步骤

1，整理测试点

1. 先将需求页面分为显示，操作两部分
2. 按照需求文档的描述，一句一句的整理

1) 一个小功能点是一个测试点

2) 一个规则是一个测试点

3.结合产品原型图，来对比检查是否有遗漏

4.针对每一个测试点，分析是否要使用测试用例设计方法来进行测试数据的设计

2，编写测试用例

不同研发模型的测试计划【目前常用的2种模型如下】

敏捷模型：互联 公司用

1. 开发周期（包括测试）：1个月
2. 测试周期：1–2周

瀑布模型：传统公司用

1. 开发周期长（包括测试）：3-6个月（一个版本迭代周期）
2. 测试周日：1-2个月（一个版本迭代周期）

针对不同的模型中测试过程的文档不同：

瀑布模型

所有的文档都回比较规范，完善

测试计划—（我们提供的模板的内容）

敏捷模型

所有的文档都会比较简洁，只写核心内容

测试计划—直接使用excel来写清楚每个需求模块负责人，任务，时间进度，交付产物

测试计划的评审

测试计划的人员时间任务安排：

人员分工：通过将需求按照功能模块相关性划分为几个块，每块安排对应的测试人员

时间安排：由于实际项目不同的需求，在评审，测试的时间都不同，因此会针对不同的模块分别来预估对应的时间。

按照模板进行测试计划的编写：

需要针对如下部分的内容，结合项目进行修改

1. 测试的目的和范围
2. 测试的人员和职责
3. 测试的任务的分工和时间安排
4. 风险评估和应急预案
5. 准入准出的标准
6. 测试策略

评审测试点的注意点

1. 测试点正确覆盖了所有的功能点，没有错误和遗漏
2. 测试点能够指导测试用例的编写

不能只是列出界面上的内容

不能只是列出需求文档中的文字描述

需要结合界面显示和需求描述，从正向逆向的维度来分该测试哪些点

写测试点或测试用例时，需要重点关注该功能页面的核心功能时什么？核心功能是重点，非核心功能顺带测试（非核心功能，通常在页面中用一个用例覆盖）

怎么汇 工作进展

1. 组员：需求1（完成），需求2（完成40%）
2. 组长：

1) 每个需求1 .2.3…….N的完成情况

2) 每个需求对应的负责人

团队测试工作进展

每个人能够说出自己的工作进度

1. 每个人能够说出自己接下来的要做的工作
2. 组长告知小组成员目前小组的整体工作进度（单独发送）
3. 组织能够根据小组的整体工作进度及时调整工作安排