软件测试UISA
2019-12-20 13:52:06 0 举报AI智能生成
登录查看完整内容
为你推荐
查看更多
软件测试
作者其他创作
大纲/内容
软件测试UISA
软件缺陷报告
软件测试执行与追踪
软件缺陷的描述
缺陷生命周期
发现->打开->修复->关闭
缺陷严重性和优先级
严重性
致命的(fatal)>严重的(critical)->一般的(major)->微小的(minor)
优先级
P1(立即)->P2(高级)->P3正常-->P4低级
软件缺陷根据和分析
软件度量
软件产品的质量度量
定性->定量
评估系统测试的覆盖程度
目的
量化测试进程
未测试或质量分析报告生成所需的量化数据
基于缺陷分析的产品质量评估
种子公式
已测试出的种子/所有种子 = 已测试出的非种子/所有非种子
变异测试
变异测试是一种基于错误的软件测试技术
DRE和DD的计算
DRE = N1/N1+N2
DD = N / size
MTTF计算
软件损耗的计算
软件消耗 = 缺陷数目 * 发现的阶段前夫期加权值 / 缺陷数目
测试报告的具体内容
单元测试
why
1:越早测试越好
平均每一千行代码2-6个错误
what
purpose
发现编程过程中的错误
验证代码是否和设计一致
追踪需求和设计的实现
发现设计和需求中的错误
how to do
静态测试
可以被开发人员独立地测试
评审集合
同行评审
同行
审查
会议
走查
小组
动态测试
设计执行测试用例
工具
Junit
C++ Test
...
单元测试策略
Driver(驱动模块)
Stub(桩模块)
前置条件和后置条件
集成测试
定义
集成测试策略
基于分解的集成-关注结点
非渐增式集成
大爆炸集成
方法
将所有模块一次性的全部集成起来进行集成测试
优缺点
优点
很快完成并有很少的存根和驱动
缺点
系统测试前很多接口错误很难被发现
适用范围
已经存在的有很少不重要修改的系统
小而具有完整单元测试的系统
由明确的高质量的可复用的模块制作的程序
特点
渐增式集成
自顶向下
深度和广度优先可选
在早期实现软件的一个完整功能
没有底层返回真实的数据流
自底向上
三明治
结合自顶向下和自底向上的策略
真正集成之前每一个模块还没有完全测试过
装模块和驱动模块的开发工作比较小
把程序划分成小块来构造和测试
基于调用图的集成-更关注边
成对集成
限制在调用图的一对单元上
对调用图的每条边有一个继承测试过程
方法实例
相邻集成
借用拓扑学的邻接概念
对饮结点的桩和驱动模块集合
免除了驱动/桩的开发工作
接口关系测试充分
测试集中于衔接的功能性
测试和集成可以并行开始
调用或协作的关系可能是错综复杂的
特定的调用或协作可能是不完全的
缺陷隔离
尽快论证一个可运行的调用或协作
被测系统也清楚定义了模块的调用和协作关系
基于功能优先级的集成
核心系统先行继承测试
基于进度的集成
高频集成
原则
5条
核心模块必须充分测试
所有接口必须测试
集成测试应该根据计划并且保护随机测试
系统测试
一些配置只在系统层面可被验证
可以包含用户在这个层面
系统环境应该被重视
concept
只有系统成功的集成了商业要求和环境才被认定
系统测试过程
功能测试 -> 非功能测试 --> 验收测试 -- > 安装测试
系统软件需求--> 其他软件需求 -- > 客户需求规格 -- > 用户环境
系统测试方法
性能测试
为了发现系统性能问题或获取系统性能相关指标而进行的测试
需求和指标
数据传输的吞吐量
QPS/TPS
数据处理效率
数据请求的响应时间
内存和CPU使用率
压力测试
并发性能测试
验收测试
概念
交付测试
Alpha testing
alpha测试是内部开发团队的模仿的真实操作的测试
Beta Testing
Beta测试包含开发或用户对软件的操作性测试
局限性
为了评价软件或获得软件而参与测试
回归测试
昂贵并且频繁的执行
test case minimization
做法
Test case selection
子主题
test case prioritization
when
一定规则下
tools
Selenium
QTP
RFT
冒烟测试
可用性测试(Sanity test)
BVT(build verification Test)
冒烟测试和可用性测试都是为了避免浪费时间和努力通过快速决定应用是不是太缺陷以至于接收严谨的测试1
0 条评论
回复 删除
下一页
