1．引言
1.1编写目的
在开发大型软件的漫长过程中，面对极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺。因此，在软件生命周期的每个阶段都不可避免地会产生差错。尤其对于机票预订系统这类会影响人们生活．财产的工程软件，必须尽量减少差错，以免造成严重的损失。测试是“为了发现程序中的错误而执行程序的过程”。测试的目的就是在软件投入生产性运行之前，尽可能多的发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明．设计和编码的最后复审，也是必不可少的关键步骤。
1.2项目背景
(2)任务提出者：XXX
(3)开发者：XXX软件工程小组
(4)用户：基金用户
(5)实施单位：XXX软件工程小组
1.3定义
SQL SERVER: 系统服务器所使用的数据库管理系统（DBMS）。
SQL: 一种用于访问查询数据库的语言
事务流：数据进入模块后可能有多种路径进行处理。
主键：数据库表中的关键域。值互不相同。
外部主键：数据库表中与其他表主键关联的域。
ROLLBACK: 数据库的错误恢复机制。
1.4参考资料
1.《基金管理系统项目计划任务书》 软件开发小组
2．《基金管理系统项目开发计划》 软件开发小组
3．《需求规格说明书》 软件开发小组
4.《概要设计说明书》 软件开发小组
5.《详细设计计划》 软件开发小组
6．《软件工程》 张海藩 清华大学出版社
7．《软件工程》 钱乐秋 清华大学出版社
2．任务概述
2.1目标
测试是“为了发现程序中的错误而执行程序的过程”, 测试的目的就是在软件投入生产性运行之前，尽可能多的发现软件中的错误。
2.2运行环境
- 软件环境：Windows 10系统
- 开发工具：
前端框架与开发工具： HTML，JavaScript，Jquery，Semantic，Apache ECharts，WebStrom
后端框架与开发工具：Spring boot，Mybatis，IDEA
数据库技术与开发工具：MySQl，Navicat
- 该基金管理系统采用BS结构，采用semantic+Springboot+MyBatis技术框架进行开发与搭建的。
- 测试工具：
- Postman：前后端接口测试
- Junit:后端单元测试以及集成测试
2.3需求概述
该基金管理系统需要界面简洁美观，功能友好。系统采用了可视化的图表，方便用户可视化地分析数据的对比与变化，给用户更加直观的感受和分析个人的基金，并且通过我们的系统可以在线购买和抛售，免去了一些繁琐的过程，增强了用户体验。
- 数据表格和统计图表结合分析
- 基金情况横纵对比（不同基金的，同一基金不同时间）
- 多种查询方式，智能表格排序
- 多种数据统计（种类统计，盈亏统计，收支统计）图表展示
- 在线抛售与购买，记录购买和抛售记录
- 强大的安全系统（支持原密码，邮箱，密保多种密码修改方式）
2.4条件与限制
必须在保证各硬件设备．软件系统齐备的情况下，资金充足，人员齐备，各方面互相配合，齐心协力，共同完成。
3.1测试方案
测试方案是测试阶段的关键技术问题。为了提高测试效率降低测试成本，本测试方案采用黑盒法设计基本的测试方案，再用白盒法补充一些方案。在黑盒法测试案中，采用等价划分技术，把所有可能的输入数据（有效的和无效的）划分成几等价类，其划分类在以下的输入中再详述。
3.2测试项目
单元测试通过对软件中的最小可测试单元进行检查和验证，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。
这里的话我们是对后端编写的各个接口类进行测试，查看其各种覆盖率，看其是否能够达到标准。
- 集成测试
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。
这里的话我们将各个模块进行连接后，进行相应的集成测试。
- 接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
- 需求测试
我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。
这里我们主要测试是否满足了用户的需求，具体的需求可参考“需求规格说明书”
- 系统测试
系统测试是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善，能不能保证系统不受非法侵入。再例如，压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等情况下是否还能正常地工作。
3.3测试工具
在测试前，与各模块的主要负责人共同协商讨论，以概要设计说明书.详细设计说明书作为总的提纲,选择合适的输入输出数据,并加以意义列举说明。
本次测试测试工具如下：
- Postman：前后端接口测试
- Junit:后端单元测试以及集成测试
3.4测试机构及人员
测试机构由XXX工作组组成，人员包括软件开发小组全体人员。
4．测试项目说明
4.1测试项目名称及测试内容
在测试过程中，首先需要对各子单元过程进行测试。在各子单元过程测试完毕后，再对各模块（包括各子单元过程之间的接口）进行测试，处理好各模块之间的接口，最后对系统进行测试和维护。
- 单元测试
单元测试通过对软件中的最小可测试单元进行检查和验证，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。
这里的话我们是对后端编写的各个接口类进行测试，查看其各种覆盖率，看其是否能够达到标准。
测试方法：白盒测试
- 集成测试
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。
这里的话我们将各个模块进行连接后，进行相应的集成测试。
测试方法：黑盒测试和白盒测试结合
- 接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
测试方法：黑盒测试
- 需求测试
我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。
这里我们主要测试是否满足了用户的需求，具体的需求可参考“需求规格说明书”
测试方法：黑盒测试
- 系统测试
系统测试是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善，能不能保证系统不受非法侵入。再例如，压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等情况下是否还能正常地工作。
测试方法：黑盒测试
4.2 测试过程
本次的测试计划的顺序，是根据软件的开放过程来设计的，测试人员在需求和设计阶段参与需求评审和设计评审、在开发完成前实施测试案例设计和测试开发，在系统开发完成之后正式执行测试，流程如下图。
4.3前端测试用例
我们先分析一下我们的基金管理系统，前端多涉及用户的输入操作我们采用黑盒测试，后端我们主要采用白盒测试，黑盒测试辅助。
- 前端界面的输入:
- 登录表单
- 注册表单
- 基金购买
- 基金抛售
- 个人信息修改
- 规定
- 邮箱：正确的邮箱格式
- 密码：非空、6~10位
- 等价类划分
| 有效等价类 | 无效等价类 |
| 正确的邮箱格式（1） | 不正确的邮箱格式（2） |
| 非空（3） | 空（4） |
| 6~10位（5） | 5及以下位（6）、11位及以上（7） |
- 测试用例
| 输入数据 | 预期结果 | 覆盖的等价类 |
| {2563599705@qq.com、123456abc} | 格式正确 | （1）（3）（5） |
| {abcde、12345} | 邮箱格式不正确、密码长度不符合 | （2）（6）（3） |
| {2563599705@qq.com、} | 密码不能为空 | （1）（4） |
| {abcde、12345absdfe} | 邮箱格式不正确、密码长度不符合 | （2）（7）（3） |
- 规定
- 邮箱：正确的邮箱格式
- 密码：至少包含数字和英文、6~10位
- 等价类划分
| 有效等价类 | 无效等价类 |
| 正确的邮箱格式（1） | 不正确的邮箱格式（2） |
| 6~10位（3） | 5位及以下（4）、11位及以上（5） |
| 至少包含数字和英文（6） | 只包含数字（7）、只包含英文（8）、都不包含（9） |
- 测试用例
| 输入数据 | 预期结果 | 覆盖的等价类 |
| {2563599705@qq.com、123456abc} | 格式正确 | （1）（3）（6） |
| {abcde、12345} | 邮箱格式不正确、密码不符合 | （2）（4）（7） |
| {2563599705@qq.com、fdafadsfadsff} | 密码不符合 | （1）（5）(8) |
| {abcde、-++*/@#} | 邮箱格式不正确、密码长度不符合 | （2）（3）（9） |
- 规定
购买份额：正整数
- 等价类划分
| 有效等价类 | 无效等价类 |
| 正整数（1） | 0（2）、负数（3）、小数（4） |
- 测试用例
| 输入数据 | 预期结果 | 覆盖的等价类 |
| 100 | 格式正确 | （1） |
| 0 | 格式不正确 | （2） |
| -3 | 格式不正确 | （3） |
| 4.5 | 格式不正确 | （4） |
- 规定
抛售份额：正整数、不能超过所拥有的份额
这里我们假设的份额为 800
- 等价类划分
| 有效等价类 | 无效等价类 |
| 正整数（1） | 0（2）、负数（3）、小数（4） |
| 不能超过所拥有的份额（5） | 超过所拥有的份额（6） |
- 测试用例
| 输入数据 | 预期结果 | 覆盖的等价类 |
| 100 | 符合 | （1）（5） |
| 0 | 不符合 | （2） |
| -3 | 不符合 | （3） |
| 4.5 | 不符合 | （4） |
| 1000 | 不符合 | （1）（6） |
- 规定
这里我们只对用户的昵称进行了限制
昵称：4-8字符之间
- 等价类划分
| 有效等价类 | 无效等价类 |
| 4-8字符之间（1） | 3字符及以下（2）、9字符及以上（3） |
- 测试用例
| 输入数据 | 预期结果 | 覆盖的等价类 |
| 希望之光 | 格式正确 | （1） |
| 希望 | 格式不正确 | （2） |
| Superstar | 格式不正确 | （3） |
4.4后端测试用例
| 编号 | 功能点 | 测试分类 | 用例内容 | 预期结果 | 测试人 |
| 1 | 后端Dao包数据接口测试 | 白盒测试 | 使用JUnit测试各种方法的覆盖率并通过所有测试用例 | 测试样例全部通过 | XXX |
| 2 | 后端Service包数据接口测试 | 白盒测试 | 使用JUnit测试各种方法的覆盖率 | 测试样例全部通过 | XXX |
| 后端Controller包测试 | 白盒测试 | 使用JUnit测试各种方法的覆盖率 | 测试样例全部通过 | XXX | |
| 4 | 前后端接口测试 | 白盒测试 | Postman工具测试 | 测试样例全部通过 | XXX |
| 5 | 集成测试 | 白盒测试 | 使用JUnit测试集成模块覆盖率 | 测试样例全部通过 | XXX |
我们对Dao包的数据接口进行测试，这里我们拿“IUserDao”进行举例说明
- 编写测试类
- 编写测试用例
| @SpringBootTest @RunWith(SpringJUnit4ClassRunner.class) class IUserDaoTest { @Autowired private IUserDao userDao; @Test void selectUserByEmail() { assertEquals(25,userDao.selectUserByEmail("2563599705@qq.com").getAge()); } @Test void updataUserInfoByEmail() { assertEquals(1,userDao.updataUserInfoByEmail(new User("14312@qq.com","7899654das","测试用例3"))); } @Test void selectUserByEmailAndPassword() { assertEquals("我思故我在",userDao.selectUserByEmailAndPassword(new User("110@qq.com","123456abc")).getNickname()); } @Test void addOneUser() { assertEquals(1,userDao.addOneUser(new User("2999899@qq.com","456123abc","测试用例"))); } @Test void updateUserPassword() { userDao.updateUserPassword(new User("123@qq.com","liu123456","测试用例2")); } } |
- 查看测试结果(包括多种覆盖率)
4.5进度
图 4-5 测试计划图
| 任务名称 | 工期 | 开始时间 | 完成时间 |
| 单元测试 | 8 个工作日 | 2022年5月17日 | 2022年5月24日 |
| 集成测试 | 4 个工作日 | 2022年5月25日 | 2022年5月28日 |
| 接口测试 | 3 个工作日 | 2022年5月29日 | 2022年5月31日 |
| 需求测试 | 2 个工作日 | 2022年6月1日 | 2022年6月2日 |
| 系统测试 | 2 个工作日 | 2022年6月3日 | 2022年6月4日 |
4.6条件
必须在保证各硬件设备．软件系统齐备的情况下，资金充足，人员齐备，各方面互相配合，齐心协力，共同完成。
4.7测试资料
测试资料主要是XXX软件开发小组的各类文档
5．评价
5.1准则
定义系统测试通过准则，以下是测试通过准则：
- 可执行软件与需求规格说明书、设计说明书是一致的；
- 测试覆盖率应达到100%（注：对于白盒测试，覆盖率指的是代码覆盖率，对应的是函数覆盖率；对于黑盒测试，覆盖率指得是需求覆盖率）
- 测试用例通过率要达到95%；
- 软件缺陷终结率达到100%
- 系统页面风格符合规范化要求，程序代码编写以及各种命名符合规范化要求。
- 各模块正确衔接。
- 对异常数据应有相应的提示信息，并能安全终止异常操作。
5.2 数据处理
测试结果分为通过和未通过。测试达到通过准则的要求称为"通过"，测试结果没有达到测试通过准则的称为"未通过"。
594
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
