Groza-测试总结
| 这个作业属于哪个课程 | 软工-2018级计算机1班 |
|---|---|
| 这个作业要求在哪里 | Groza-团队作业5项目冲刺 |
| 这个作业的目标 | 冲刺的时间计划安排，反思过往，进行调整 |
| 小组的组号和队名 | 第三组 Groza |
| 小组的队长姓名 | 雷思骞 |
随笔链接
github链接
正交排列法
• 正交排列法就是能够使用最小的测试过程集合获得最大的测试覆盖率.
• 特点: 均匀分散，齐整可比
举例
字符属性设置的程序
窗体中有多个控件（字体、字符样式、颜色、字号），每个控件有多个取值
字体：仿宋、楷体、华文彩云
字符样式：粗体、斜体、下划线
颜色：红色、绿色、蓝色
字号：20号、30号、40号
正交表的概念
• 一种特制的表，一般的正交表记为:
• n是表的行数，也就是需要测试组合的次数
• K是表的列数，表示控件的个数（因素的个数，或因子个数）
• m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）
• 如:
• 有4个控件
• 每个控件有3个取值
• 9为需要测试的组合个数
• 叫4因素3水平
举例
系统查询企业单位
测试设计用例数：
混合正交表
• 混合正交表的水平数不同. 水平数不固定.
举例
体型 年龄段 性别
胖 老人 男
适中 青年 女
瘦 儿童
工具
• 正交表生成工具allpairs(混合正交用这个), 正交设计助手(正常的可以用它)
• allpairs使用步骤：
• 1、制作对照表（只列出数据即可，不用编号）
• 2、复制取值表的数据，放到文本文档中保存（注意不要更改任何格式，例如文件叫Test2.txt ）
• 3、把文本文档放在allpairs文件夹中
• 4、win+r后输入cmd进入控制台
• 5、使用控制台代码进入allpairs文件夹（cd 目录名字）
• 6、在控制台中输入allpairs.exe hunhe.txt>resutl.txt （ resutl是自己起的名字，用来存放生成的组合用例，可以自动生成，不必提前建好）
案例加深练习
体型 年龄段 性别
胖 老人 男
适中 青年 女
瘦 儿童 保密
中年
测试用例的力度
• 测试用例可以写的很简单，也可以写的很复杂
• 大多数的测试团队编写的测试用例的力度介于两者之间
测试用例的设计本质:
• 在设计的过程中理解检验需求，对软件系统的测试方法的思路记录下来，指导后面的测试
• 不要认为测试用例设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都要回来重新评审和完善测试用例
测试用例评审
• 同行评审
• 测试用例的检查方式有很多，同行评审是其中最敏捷的一种
• 用户评审
• 顾客的协作比合同谈判更有价值
软件缺陷的定义
• 软件未达到需求规格说明书表明的功能
• 软件出现了需求规格说明书指明不会出现的错误
• 软件的功能超出了需求规格说明书指明的范围
• 软件未达到需求规格说明书虽未指明而应该达到的目标
• 软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好
软件缺陷的表现形式
• 功能、特性没有实现或部分实现。
• 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
• 产品实际结果和所期望的结果不一致。
• 没有达到需求规格说明书所规定的性能指标等。
• 运行出错，包括运行中断、系统崩溃、界面混乱等。
• 数据不正确、精度不够、不完整或格式不统一。
• 用户不能接受的其他问题，如存取时间过长、界面不美观。
• 硬件或系统软件上存在的其他问题
软件缺陷产生的原因
• 需求解释或者记录错误
• 设计说明存在错误
• 编码说明、程序代码有误
• 硬件或者软件系统上存在错误
缺陷的根源
• 交流不充分
• 客户与开发人员、开发人员与测试人员等
• 软件的复杂性
• 功能复杂、开发复杂、测试复杂
• 开发人员的错误
• 对需求的理解、开发压力、能力与经验
• 需求的变化
• 需求说明书、设计文档、程序的变更
• 进度压力
• 项目周期比较紧
软件缺陷的信息
• 为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计
编号
属性名称
描述
1
缺陷ID
唯一的缺陷ID，可以根据该ID追踪缺陷
2
缺陷状态
缺陷状态指缺陷通过一个跟踪修复过程的进展情况
3
缺陷标题
描述缺陷的标题
4
缺陷的严重程度
对软件产品的影响程度，分致命、较严重、严重、一般、低
5
缺陷的优先级
缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正
6
缺陷所属模块
缺陷所属的项目和模块，要能较精确的定位至模块
7
缺陷记录者
提交缺陷的人员姓名
8
缺陷提交时间
缺陷提交的时间
9
缺陷处理人
处理缺陷的处理人
10
处理结果描述
对处理结果的描述，描述处理情况和代码修改说明
11
缺陷处理时间
缺陷处理的时间
12
缺陷验证人
对被处理缺陷验证的验证人（回测者）
13
验证结果描述
对验证结果的描述（通过、不通过）
14
缺陷详细描述
缺陷的重现步骤
15
缺陷环境说明
对测试环境的描述
16
必要的附件
如涉及到附件的或错误现象的图片等
缺陷的状态
• 1.提交 (Submited) 已提交的缺陷
• 2.打开 (Open) 确认“提交的缺陷”，等待处理
• 3.拒绝 (Rejected) 拒绝“提交的缺陷”，不需要修复或不是缺陷、重复缺陷、无法重现
• 4.修复 (Resolved) 缺陷被修复
• 5.关闭 (Closed) 确认修复的缺陷, 将其关闭
• 6.推迟 (Later) 可在以后解决，但要确定修复日期或版本
软件缺陷的严重程度
严重等级
描述
5-Critical
系统瘫痪、异常退出、死循环、严重的计算错误等
4-VeryHigh
频繁的死机，系统大部分功能不可用
3-High
a.功能点没有实现，或不符合用户需求
b.数据丢失
2-Medium
a.影响一个相对独立的功能 b.仅仅在特定条件上发生
c.与产品需求定义不一致 d.断断续续的出现问题
1-Low
表面性错误（如错别字）
软件缺陷优先级
优先级别
描述
5-Urgent
最高优先级。在这个错误影响下，系统几乎不可用
4-VeryHigh
高优先级。错误对这套系统的能力产生严重的影响
3-High
中优先级。如果这个错误存在与系统中，会制约开发和测试的活动的进行，如果先前没有修复它，那么需要在发布前修复它
2-Medium
低优先级。不会延迟发布，但是会在以后修正这个错误
1-Low
最低优先级。时间和资源允许时修正
缺陷的分类
缺陷类型
内容说明
备注
系统缺陷
1.由于程序所引起的死机，异常退出
2.程序死循环
3.程序错误，不能执行正常工作或重
要功能，使系统崩溃或资源不足
不能执行正常工作或重要功能，使系统崩溃或资源不足
数据缺陷
1.数据计算错误
2.数据约束错误
3.数据输入、输出错误
严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启不属更正方法）
数据库缺陷
1.数据库发生死锁
2.数据库的表、缺省值未加约束条件
3.数据库连接错误
4.数据库中的表有过多的空字段
接口缺陷
1.数据通信错误
2.程序接口错误
功能缺陷
1.功能无法实现
2.功能实现错误
严重地影响系统要求或基本功能的实现，但有合理的办法更正（重新安装或重新启动不属更正方法）
缺陷类型
内容说明
备注
安全性缺陷
1.用户权限无法实现
2.超时限制错误
3.访问控制错误
4.加密错误
兼容性缺陷
与需求规定配置兼容性不符合
性能缺陷
1.未达到预期的性能目标
2.性能测试中出错，导致无法继续进行测试
界面缺陷
1.操作界面错误
2.打印内容、格式错误
3.删除操作未给出提示
4.长时间操作未给出提示
5.界面不规范
操作者不方便或遇到麻烦，但不影响执行工作功能的实现
建议
1.功能建议
2.操作建议
建议性的改进要求
开发人员拒绝修改的缺陷
• 程序员无法重现或者现象难以捕捉
• 没有明确的报告以说明重现缺陷的步骤
• 程序员无法读懂的缺陷报告
• 用户很少使用或者不符合用户使用习惯的操作出错
• 由不受信任的测试人员提出
缺陷修改说明
• 不是所有缺陷都会修改
• 市场的压力使得产品最终发行有时间限制
• 测试人员错误理解或者不正确操作引出的缺陷(FAQ)
• 错误的修改影响的模块较多，带来的风险较大(遗留)
• 修改性价比太低
• 缺陷报告中提出的问题很难重现
项目测试评述
通过软件的编写过程的测试，项目的软件模块的功能是和需求分析文档的内容一致
测试体会
1、测试工作切忌上手就开测，一定要好好的了解项目背景以及相关需求，不明白一定要问清楚，这样你可以很好的掌控测试的力度和大方向；
2、测试计划方案制定之前，最重要的是确定测试范围和测试标准。以需求为标准，切忌测试人员以开发设计的功能为标准
3、测试计划和方案制定的时候有必要和开发负责人、项目经理了解一下目前项目的项目计划和真实进度，以此为依据制定一下测试计划；
4、尽力去了解整个系统，空闲的时候可以好好想想项目的功能交互，各功能之间会不会出现反人类的“骚”操作，这样的“骚”操作往往是bug出现的地方
5、编写测试用例框架，从整体梳理一下测试思路，数据、业务规则、UI或者拆分模块、或者先接口后功能再集成最后场景，随机应变吧。骨架搭好了，就需要对应需求了。
6、测试的一切工作的基础不是需求文档，而是你的测试用例，所以一定要将需求和项目的一切变动都实时的更新转化到你的测试用例里面，为了避免成为背锅侠，所以此时的测试用例是你工作的底气也是你的工作成果，你懂的；
7、测试软件过程中，忌讳一遇到问题就马上找开发，测试的工作时间是碎片化的，但是开发的工作时间一定不能是碎片的，否则开发会疯的；对于测试进行不下去的bug你可以实时找开发外，其他的比较重要的你要收集好一起反馈给开发
浙公网安备 33010602011771号