您的位置:首页 > 其它

浅谈软件测试

2017-06-22 15:56 288 查看
软件测试是为了发现错误采用测试用例执行软件的活动;

测试的意义在于预防,发现错误并提供诊断错误信息

测试可结束的标志:达到所要求的覆盖
自动化测试:多用于回归测试

测试V模型:
需求分析 -> 概要设计 -> 详细设计 -> 编码实现
验收测试 <- 系统测试 <- 集成测试 <- 单元测试 (程序员把单元集成系统,客户确认验收)

测试阶段划分:
1. 审查需求规格说明书
2. 审查系统设计文档
3. 单元测试
4. 集成测试
5. 确认测试
6. 系统测试(alpha,beta)
7. 验收测试
测试过程:
分析测试需求, 制定测试计划, 构建测试环境, 设计测试用例, (测试实现:自动化脚本)执行测试, 总结并生成报告。

典型测试用例结构:
测试用例:{
ID:					编号
For: 				用途
Before/After:		前/后置条件
I/O:				输入/预期输出
FactOut:			实际输出
Version:			运行版本号
Datetime:			执行时间
User:				测试人
Remark:				执行过程记录
}

测试用例的设计方式:
1. 基于功能的黑盒测试:
边界值分析:
若输入限制域为[m,n],则输入应包含:m-1,m,m+1,n-1,n,n+1
若限制输入参数数量为[m,n],则要求用: m,n,m-1,n+1 个参数分别输入
若输出有限制,应有输入使得输出达到其边界值+边界值左右
等价类分析:
等价类划分规则:
规定一组值且对每个值做不同处理,则可确定一组有效等价类和一个无效等价类
规定输入数据规则,则可确定一个有效等级类和一组无效等价类
如:	限制输入参数范围,可确定一个有效等级类和若干无效等价类;
限制输入参数数量,可确定一个有效等级类和两个无效等级类(多or少)
等价类生成测试用例规则:
设计测试用例使其覆盖尽量多的未覆盖的有效等价类直到覆盖所有(有效等价类);
设计测试用例使其只覆盖一个未覆盖的无效等价类直到覆盖所有(无效等价类);
2. 基于逻辑的白盒测试:
覆盖能力:语句覆盖<判定覆盖<条件覆盖<路径覆盖
语句覆盖: 使得每个可执行语句(块)都执行一次;
判定覆盖: 使得每个判断至少获得一次"TRUE"和一次"FALSE";
条件覆盖: 使得判断中的每个条件的可能取值至少满足一次;
路径覆盖: 使得每条可能路径都至少执行一次,若存在环则每个环至少执行一次;(可用McCabe计算路径数)
* McCabe计算复杂度( V(G) ): P+1 , p是图中判断节点的数量

集成测试:
着重考虑:
将各个子功能组合起来,检查能否达到预期要求的各项功能;
单个模块的误差积累起来,是否被放大,从而达到不可接受的程度。
一个模块的功能是否会对另一个模块的功能产生不利的影响;
全局数据结构是否有问题,会不会被异常修改;
将各模块连接起来,数据经过接口是否丢失;
集成测试策略:
非增量测试;
增量测试:自顶向下(加桩模块),自底向上(加驱动模块),混合式(包括三明治和改进三明治)
比较增量测试和非增量测试:
增量测试工作量较大,时间长;非增量测试工作量要小一些。
增量测试只能串行测试,非增量测试可以并行测试。
增量测试发现错误早;非增量测试则晚。
增量测试易于诊断错误,非增量测试发现错误,较难诊断;
增量测试测试更彻底。

软件的6大质量:
功能性: 用户需求满足程度
可靠性: 异常恢复的能力
可用性: 交互友善性,是否方便学习和使用
效率特征: 实现某功能消耗的资源量
可维护性: 需求变更版本迭代时修改的容易程度
可移植性: 改变运行环境的容易程度

系统常见性能指标
(1)用户数: 在线人数、并发用户数、系统用户数。
(2)响应时间:系统对请求作出响应所需要的时间。
(3)吞吐量:单位时间内系统处理的客户请求的数量。度量单位可以是字节数/天、请求数/秒、页面数/秒、访问人数/天、处理的业务数/小时等。
(4)资源利用率:对不同系统资源的使用情况。比如服务器的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: