用例设计考虑面

设计全面的测试用例,可提高测试质量,减少线上问题漏出。

一、需求评审阶段考虑

项目角度

1)需求优先级
2)截止时间
3)外部系统对接人确认

业务场景角度

1)站在使用者的角度,考虑用户遇到的各种情况,反观各种情况在需求中能找到对应描述–用户故事
2)根据用户故事构思简单的流程图,各自路径的约束关系,执行条件是否有明确合理的定义–业务流程图

功能点角度

1)数据约束是否全面、合理存在分支的描述,是否覆盖所有路径
2)多状态流程,状态流转描述是否合理且完整
3)权限描述是否正确,对各项操作的权限进行准确的说明

系统交付角度

1)穷举系统,并且找出相关系统
2)划分系统边界
3)新方案对系统原有设计侵入性评估–尽量跟原有模块解耦
4)改动量评估

二、开发设计阶段考虑

异常情况

1、接口调用失败
2、MQ消息丢失
3、Redis崩溃
4、被调用服务器重启
5、网络超时等
6、服务器或数据库备份与恢复

特定技术栈

1、Redis是否考虑数据的主动刷新,数据穿透,容灾数据全量恢复等问题–Redis防被攻击
2、MQ丢消息、时序性等问题
3、task:任务防重措施、处理结果幂等
4、DB:普通索引合理性,唯一索引合理性,锁表问题,数据线程安全

数据层面

1、表数据对象没有包含该对象完整的数据属性
2、数据对象是否包含不应该存在的多余数据对象
3、表字段是否满足单一职责
4、表字段是否存在二意性,每个字段只负责存储一种数据

逻辑层面

1、梳理新流程是否有遗漏的外部系统需要改动
2、梳理已有数据特性,检查新逻辑是否兼容历史数据等
3、接口设计是否合理
4、设计是否能够通用
5、设计是否对原有系统影响最小,是否解耦
6、导入场景需考虑开发设计的最大值导入值(行)
7、导出场景考虑如存放的空间不足处理方式

三、测试设计阶段考虑

功能流程

1、流程覆盖思考点
1)系统的主流程(业务流程)
2)条件备选流程
3)数据流向,信息/数据在系统中的流动、存储和处理
4)关键的判断条件
条件判断:根据某个条件是否满足来判断
时间判断:根据时间的先后顺序来判断
人员判断:根据人员的不同角色或权限来判断
数据判断:根据数据不同值或状态来判断
2、流程图路径分析
1)画出业务流程图
2)定义状态节点和条件分支
3)确定测试路径
4)选取测试数据,构造测试用例
3、异常流程考虑
1)流程未完成,到了某个时间是否会自动结束,不结束的话,状态显示情况
2)同一流程多次驳回,再次发起申请相同流程
3)驳回后流程状态显示,驳回是否可在驳回流程上再次提交,还是需要重新提交发起新流程
4)流程进行中,修改流程配置
5)流程结束后,修改配置,是否影响历史已结束流程数据
6)相同数据/流程删除后,再新增同样数据/流程

关联功能

1、关联值
值被其他地方引用到,做删除修改操作
2、同一控件
1)罗列使用该控件的相关功能,覆盖对应场景
2)如同一控件减少值,考虑单个功能个性化处理,不影响对应关联功能
3、本系统
本次版本修改是否影响系统其他功能,考虑关联的功能
4、外部系统
本次修改是否影响外部系统,考虑关联的系统

配置/数据兼容

1、初始状态(系统配置为空)是否影响已有功能的正常使用
2、考虑是否有初始化配置脚本/初始数据
3、历史数据兼容,是否需要刷数,验证历史数据完整性

输入域

1、范围内值
2、边界值
3、特殊字符校验
4、必选参数校验
5、接口幂等,幂等就是不管你执行多少遍,结果都是一样的,场景场景是支付场景
6、参数类型校验
7、组合参数校验
8、权限校验

日志相关

1、日志时间准确,有明确的用户标识和行为信息,如IP地址,用户名等
2、日志不打印敏感信息
3、关注日志级别定义,防止未达到错误级别的日志也打印成错误日志,这也是错误日志数量大的原因之一
4、关注日志级别,不打印过多日志,考虑生产环境使用用户较多时可能打印过多日志导致磁盘爆满等
5、观察报错日志,分析问题,作为用例场景
6、观察日志中用户使用习惯,作为用例覆盖场景

数据库相关

1、检查数据库数据存储值正确性
2、数据库数量达到很大量(千万级别)时,对系统使用的一些影响
3、前端提交的表单是否在对应的每个字段都正确的写入,例如功能提交成功后,数据库可能会更新多张表,检查多表的数据存储情况
4、数据库读写安全
1)数据加密,在数据传输过程中,需要对数据进行加密处理,已确保数据在传输过程中不被窃取或篡改。场景的加密方式包括SSL、TLS等
2)认证与授权,在数据传输过程中,需要对数据的发送方式和接收方式认证和授权,以确保数据值被授权的用户访问
3)数据完整性验证,在数据传输过程中,需要对数据的完整性进行验证,以确保数据在传输过程中不被篡改或破坏
4)防范攻击,在数据传输过程中,需要考虑各种攻击方式,如拒绝服务攻击,中间人攻击等,以确保数据传输过程的安全性

复盘问题

1、线上问题,总结为系统的测试用例场景
2、其他系统遇到的问题,考虑本系统是否页存在类似场景,考虑作为补充用例

线程安全

并发测试

故障注入法

1、Redis故障降级测试
1)Redis宕机
2)考虑服务器故障发生时,系统功能的使用情况,快速恢复系统使用性
2、MQ消息积压场景测试
3、服务器故障转移测试,服务器发生故障时能够自动将服务迁移到备份节点的测试

四、专项测试

兼容性覆盖

1)功能兼容性(不同系统、不同浏览器)
2)ui兼容性(不同系统、不同浏览器、不同分辨率、不同屏幕大小)
3)数据兼容性(历史数据兼容性、缓存测试)
4)版本兼容性(app版本兼容性、不同版本浏览器、同一系统不同版本)
5)环境兼容(考虑测试环境,生产环境的差异性)

安全性考虑

安全测试左移,目前有内部安测组,后续大家在功能测试阶段可考虑安全测试场景,比如身份证,密码加密显示,加密存储,越权,XSS攻击,日志无敏感信息等

性能测试

接口性能,大数据量系统处理能力,页面图片加载速度,页面加载速度等

用户体验

现在越来越重视用户体验的问题,可需求阶段提前提出体验问题,确认是否考虑,测试用例里可包含体验场景的考虑

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
毕业设计,基于SpringBoot+Vue+MySQL开发的体育馆管理系统,源码+数据库+毕业论文+视频演示 现代经济快节奏发展以及不断完善升级的信息化技术,让传统数据信息的管理升级为软件存储,归纳,集中处理数据信息的管理方式。本体育馆管理系统就是在这样的大环境下诞生,其可以帮助管理者在短时间内处理完毕庞大的数据信息,使用这种软件工具可以帮助管理人员提高事务处理效率,达到事半功倍的效果。此体育馆管理系统利用当下成熟完善的SpringBoot框架,使用跨平台的可开发大型商业网站的Java语言,以及最受欢迎的RDBMS应用软件之一的Mysql数据库进行程序开发。实现了用户在线选择试题并完成答题,在线查看考核分数。管理员管理收货地址管理、购物车管理、场地管理、场地订单管理、字典管理、赛事管理、赛事收藏管理、赛事评价管理、赛事订单管理、商品管理、商品收藏管理、商品评价管理、商品订单管理、用户管理、管理员管理等功能。体育馆管理系统的开发根据操作人员需要设计的界简洁美观,在功能模块布局上跟同类型网站保持一致,程序在实现基本要求功能时,也为数据信息临的安全问题提供了一些实用的解决方案。可以说该程序在帮助管理者高效率地处理工作事务的同时,也实现了数据信息的整体化,规范化与自动化。 关键词:体育馆管理系统;SpringBoot框架;Mysql;自动化
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值