单元测试
why
1:越早测试越好
平均每一千行代码2-6个错误
what
单元测试是软件开发过程应用中最小的可测试部分,可以独立通过适当操作测试
测试内容可以使一个方法,一个功能,一段程序
purpose
发现编程过程中的错误
验证代码是否和设计一致
追踪需求和设计的实现
发现设计和需求中的错误
how to do
静态测试
检查代码语法,或者回顾代码和文档去寻找错误
可以被开发人员独立地测试
单元测试策略
Driver(驱动模块)
被用于模拟上级测试模块的模块,接收测试数据,传输相关数据去测试模块,开始测试模块和输出相应结果
Stub(桩模块)
用于模拟calling模块,一般的,他们只产生少量数据
前置条件和后置条件
集成测试
定义
一个软件测试周期,独立的软件模块被合并和作为一个组测试
集成测试策略
基于分解的集成-关注结点
非渐增式集成
大爆炸集成
优缺点
优点
很快完成并有很少的存根和驱动
测试人员可以并行工作,人和物利用率高
缺点
当错误发生时,本土化和debug很困难
系统测试前很多接口错误很难被发现
适用范围
已经存在的有很少不重要修改的系统
小而具有完整单元测试的系统
由明确的高质量的可复用的模块制作的程序
特点
需要的用例少,比较简单,效率较高,但不能处理复杂的程序,而且不容易一次性成功
先进行单元测试,在将所有模块一起集成测试
渐增式集成
自顶向下
方法
先关注顶层模块,然后逐步向下测试底层单元
深度和广度优先可选
产生回归测试,包含集成过程产生的错误
所有模块被集成后完成测试,否则重新测试
自底向上
方法
从底部最小的独立单开始,根据独立结构体,图层向上集成检查整个系统
优缺点
优点
可以并行继承,对被测模块可测试要求比自顶向下策略低
缺点
驱动模块开发量大,整体设计的错误发现较晚,集成顶层时变得越来越复杂
三明治
方法
结合自顶向下和自底向上的策略
真正集成之前每一个模块还没有完全测试过
保证每个模块得到单独的测试,是测试比较彻底
优缺点
缺点
增加了缺点的定位难度,目标层在集成前测试不充分
特点
比较容易定位和改正错误,对接可以进行更彻底测试
把程序划分成小块来构造和测试
基于调用图的集成-更关注边
成对集成
特点
免除桩/驱动的开发工作,使用实际代码
限制在调用图的一对单元上
对调用图的每条边有一个继承测试过程
方法实例
相邻集成
特点
借用拓扑学的邻接概念
再有向图中,结点邻居包括所有直接前驱结点和又有直接后继结点
对饮结点的桩和驱动模块集合
方法实例
优缺点
优点
免除了驱动/桩的开发工作
接口关系测试充分
测试集中于衔接的功能性
测试和集成可以并行开始
缺点
调用或协作的关系可能是错综复杂的
参与者没有被单独测试,要充分测试底层模块比较困难
特定的调用或协作可能是不完全的
缺陷隔离
适用范围
尽快论证一个可运行的调用或协作
被测系统也清楚定义了模块的调用和协作关系
基于功能优先级的集成
依据功能的优先级,逐一将功能上的各个模块继承起来
核心系统先行继承测试
基于进度的集成
高频集成
特点
优缺点
优点
能再开发过程中即使发现代码错误,能只管地看到开发团队的有效工程进度
缺点
需要开发和维护源代码和测试包,有时候可能不能暴露深次层的编码错误和图形界面错误
将最早而获得的模块进行继承,以最大程度保持与开发的并行性
原则
5条
核心模块必须充分测试
所有接口必须测试
当接口改变,所有相关接口应该通过使用回归测试
集成测试应该根据计划并且保护随机测试
集成测试策略应该关注质量,花费,进程的关系
系统测试
why
一些配置只在系统层面可被验证
可以包含用户在这个层面
系统环境应该被重视
concept
系统测试是一个如果遇到特定的需求,测试整个集成系统去验证的过程
只有系统成功的集成了商业要求和环境才被认定
系统测试过程
功能测试 -> 非功能测试 --> 验收测试 -- > 安装测试
系统软件需求--> 其他软件需求 -- > 客户需求规格 -- > 用户环境
系统测试方法
性能测试
目的
为了发现系统性能问题或获取系统性能相关指标而进行的测试
需求和指标
数据处理效率
数据请求的响应时间
内存和CPU使用率
验收测试
概念
在SDLC阶段验收测试是一个前置测试去决定软件是否满足用户定义的验收标准,
最后,用户和使用者可以通过验收测试决定是够接收这个产品
交付测试
Alpha testing
alpha测试是内部开发团队的模仿的真实操作的测试
早期的,不稳定的软件版本所进行的验收测试,受控的实验室测试
Beta Testing
概念
Beta测试包含开发或用户对软件的操作性测试
晚期的,更加稳定的软件版本所进行的验收测试,不受控的非实验室测试
局限性
测试人员不是专业的,问题停留在易用性上
环境不可控,使用不当引起的问题居多
为了评价软件或获得软件而参与测试
反馈信息简单,无法重视
回归测试
why
修复一个bug,同时创造一个bug
昂贵并且频繁的执行
what
必须执行回归测试当:<br>1:需求改编,代码根据需求修改<br>2:缺陷修改<br>3:新特性被添加
how to do
影响分析,根据影响分析一些测试用例被选择关注被影响的区域
从现有的测试用例集T中选取一个子集T'<br>在修改后的代码P'上运行T',泳衣确定P'的正确性<br>建立新的测试用例集T''<br>在修改后的代码P'上运行T'',泳衣确定P'的正确性<br>有T,T',T''建立P'的测试历史和测试用例集T''
test case minimization
找到一个测试用例子集,并且能够有和原始测试用例组一样的覆盖率
做法
1:选择满足测试需求的最大用例<br>2:选择满足未实现的测试需求的最大测试用例<br>3:首先选择测试组中所有必不可少的测试用例,对于剩下的测试需求,使用贪婪添加算法,例如,2<br>4:溢出所有多余的测试用例,使测试用例都是必须的
Test case selection
从原始用例中选择一个子集,但不能够提供一样的覆盖率
test case prioritization
when
常规执行(每日,每周,每月)
一定规则下
冒烟测试
可用性测试(Sanity test)
BVT(build verification Test)
冒烟测试和可用性测试都是为了避免浪费时间和努力通过快速决定应用是不是太缺陷以至于接收严谨的测试1
