软件测试
2019-06-25 14:59:27 38 举报
AI智能生成
软件测试复习资料
作者其他创作
大纲/内容
测试阶段
单元测试
测试目标
对软件基本组成单元(类/模块)进行测试,比如模块的接口是否正常工作
由开发人员和qa人员共同完成
测试方法
设计测试用例
为被测对象设计驱动模块和装模块
执行测试获得测试结果
jUnit框架
测试过程
设计测试计划
(当前测到哪个阶段,用什么方法来测的)
集成测试
测试目标
检查模块之间的接口是否正常工作,比如数据的传递等
保证系统的完整性
集成策略
渐增式
自顶向下
优势
劣势
自底向上
优势
劣势
混合策略
关键先行
非渐增式
大棒集成
优势
缺点
系统测试
测试目标
确保系统的功能性和非功能性需求被满足
功能测试
测试目标
根据需求说明和功能说明对系统功能进行整体测试
过程
内容
非功能性测试
压力测试
破坏性压力测试
目的:找到系统的瓶颈
稳定性压力测试
目标:给出系统正常运行的范围/边界条件
容量测试
在给定(极限)条件下,系统正常运行并能够处理的最大负载
性能测试
确定系统的性能指标,给出合理的配置信息(最佳/极限)
安全测试
系统抵抗非法入侵的能力
让入侵代价大于入侵回报
容错测试
系统在异常条件下的恢复以及容灾手段
验收测试
测试目标
系统达到了用户需求规格说明书的要求
测试内容
易用性测试
针对界面
安装测试
兼容性测试
文档测试
测试环境/标准
用户实际运行环境下运行所有测试用例
测试方法
黑盒测试
白盒测试
测试用例
标准
具有代表性
可再现
可判定
设计步骤
根据需求确定用例
为测试确定输入输出
编写测试用例
评审
执行跟踪分析
作用
避免盲目测试
估算测试工作量
减少回归测试的复杂度
方便缺陷报告书写
实施不同级别的测试
概念
尽快找出软件系统中的缺陷并督促相关人员修复,保证软件系统正确性,完整性,安全性和质量的过程
软件开发的过程
瀑布模型
测试驱动开发TDD
增量开发
原则
不可能全部测完
软件测试是有风险的
不能展示隐藏的缺陷
找到越多的缺陷,被后肯定有更多的缺陷
不是所有的缺陷都需要被修复
一个缺陷是否真的是一个缺陷?这很难说
需求是永远不会圆满的
软件测试人员并不是最受欢迎的
软件测试是一件专业的事情
团队建立
团队工作
人员配置
测试组长
配环境的
测试设计人员
执行人员
模型
V模型
就是在所有开发工作完成后再进行测试
H模型
强调软件测试是独立流程/在某个开发过程就绪后即可开始某个阶段的测试
W模型
v模型的改进,强调测试在设计和开发过程中同步进行(静态/动态测试)
同样是以瀑布模型为基础的线性过程,不支持迭代
回归测试
定义
对修正缺陷后的内容进行再测试
既要测试缺陷是否被修正
也要测试原有的功能是否正常进行
方法
执行全部测试用例
挑关键测试用例执行
只执行发生问题的测试用例
冒烟测试
每次内容更新后都进行基本测试
确保被测试内容基本没有问题再进行细致测试,以免时间浪费
测试环境
软件
硬件
网络环境
数据
测试工具
QSA(软件质量保证)
对软件产品和活动有计划的进行评审和审计来验证软件是否合乎标准的系统工程活动
管理整个软件测试的过程
软件测试是QSA的一个手段
软件测试为QSA提供依据
软件维护
定义
对交付之后的系统进行错误修正或满足新需求
类型
改正性维护
适应性维护
完善性维护
预防性维护
结构化维护/非结构化维护
维护工作量因素
系统大小
使用的程序语言
系统年龄
采用的软件开发技术
其他
过程
可维护性
可理解性
可测试行
可修改性
可靠性
可使用性
可移植性
效率
软件配置管理SCM
定义
执行版本控制,变更控制,使用合适的配置管理软件保证所有配置项的完整性和可跟踪性
软件配置项
合同,过程,设计相关的文档和数据
源码,目标代码和可执行代码
相关工具
版本管理
版本定义
对某一配置不同版本进行管理
基线
一个配置项在其生命周期的某一特定时间,被正式表明,固定并经正式批准的阶段性版本
配置控制组
负责评估和评审配置项变更的人员
0 条评论
下一页