软件测试期末复习

文章介绍了软件测试中的黑盒测试技术,包括等价类划分、边界值分析、决策表和状态转换测试用例设计。同时提到了白盒测试,强调其在单元测试中的应用,以及代码覆盖率、逻辑覆盖等方法。此外,还讨论了不同类型的测试,如压力测试、负载测试和性能测试,并对比了黑盒和白盒测试的特点。
摘要由CSDN通过智能技术生成

东西太难写了,好理解不好写。选取的一点讲的重点,具体的得自己去看书。
在这里插入图片描述

软件测试设计技术

黑盒测试

等价类划分、边界值分析、决策表、状态转换

等价类划分
有效等价类:对于程序需求规格说明来说是合理的
无效等价类:不合理的。
标准等价类测试:没有无效等价类
健壮等价类测试:有效输入,每一个有效等价类中取一个数。对无效输入,测试用例取一个无效,其他都是有效。

设计:

  1. 划分等价类,编号。
  2. 设计测试用例,有效等价类尽可能多的覆盖
  3. 无效等价类:每次只覆盖一个。

在这里插入图片描述

左边有效等价类要尽可能多的,所以可以1-4-8-12-14设计为x  2-4-9-12-14设计一个。
然后对于无效的每次只能选取一个

边界值分析
如果有多个边界则都需要设计,边界值有上界下界则都要有
二值测试法:一个在边界上一个在边界外。
三值测试法:一个边界内、上、外。

如果1-100.

如果步长为x则可以设计 1-x,1,1+x,100-x,100,100+x

决策表测试

四个部分:桩部分、条目部分、条件部分、行动部分。
一条条列出来就行。
在这里插入图片描述
然后可以优化。
在这里插入图片描述

状态转换
就是根据图来全部走一遍就行。

设计测试用例
在这里插入图片描述

1.起始(根)→生成订单→支付→打印票据→提交票据
2.起始(根)→生成订单→客户取消
3.起始(根)→生成订单→支付→客户取消
4.起始(根)→生成订单→支付→打印票据→客户取消

例题

现在有一个档案管理系统, 容许用户经过输入年月对档案文件进行检索, 系统对查询条件年月的输入限定为1990年1月-2049年12月, 并规定, 日期由6位数字组成, 前4位表示年, 后2位表示月。

年份:  【1990, 2049】
月份:  【01, 12】
字符长度: 6位
字符类型: 数字

有效等价类用例: 
 用例1:  11    ( 1) ( 4) ( 7) ( 10) 
无效等价类用例: 
用例2: 198911    ( 2) 
用例3: 205011    ( 3) 
用例4:  00    ( 5) 
用例5:  13    ( 6) 
用例6:  1     ( 8) 
用例7:  113   ( 9) 
用例8:  1a/abcedf    ( 11) 
根据边界值分析法分析后补充测试用例
用例9: 199001     ( 12) 
用例10: 204912   ( 13) 

白盒

白盒测试也称结构测试,透明盒测试。主要用于单元测试阶段,代码和逻辑的测试,重点复杂的测试,是一种测试用例设计方法,不同于黑盒测试,白盒测试是可以看到内部代码如何运作的,可通过测试来检测产品内部是否符合规定正常运行。
白盒测试优缺点

优点:

    代码覆盖率高

缺点:

    覆盖所有代码路径难度大

    业务功能可能覆盖不全

    测试开销大

白盒测试方法

先静态分析
    桌面检查
    代码审查
    代码走查
    代码扫描工具

在动态分析
  逻辑覆盖法
        语句覆盖
        判定覆盖
        条件覆盖
        判定条件覆盖
        条件组合覆盖
        路径覆盖
    基本路径测试法(最常使用)

语句覆盖
每一条语句执行一次。
语句覆盖率=(被执行语句的数量/所有语句数量)×100%

int test(boolean a,boolean b,boolean  c,boolean d){
  if(a && b)
     action1;
   if(c || d)
     action2;
}

语句覆盖:

可以看出一共有2条语句。全部执行就可以。
abcd
TTTF
覆盖标准最弱:

判定覆盖
判断覆盖:也叫分支覆盖,设计测试用例,使得程序中的每个判断 的”真“和”假“都至少被执行一次
设上面程序

p1a && b
p2c|| d

那么判定覆盖可以设计为

abcdp1p2
TTTFTT
FFFFFF

覆盖率是通过测试执行的判定结果的数量除以测试对象中判定结果的总数来测量,通常以百分比表示。

条件覆盖
条件覆盖:设计测试用例,使得判定中的每个条件至少有一次取真值,有一次取假值.这个程序中abcd每一个都是一个判断,

abcd
TTTT
FFFF

判定-条件覆盖
两个判定的“真”和“假”至少执行一次且两个判定的的每个条件取得各种可能的结果
等同于判定+条件

abcda&&bc||d
TTTTTT
FFFFFF

组合覆盖
两个判定的每种条件组合至少都被执行一次

abcd
TTTT
TFTF
FTFT
FFFF

路径覆盖
每条通路的路径至少执行一次
通过a&&b后有a1、a2的2条路
然后其分别进入c||d又会有b1、b2的2条路
所以有四条,覆盖其路径需要
在这里插入图片描述

静态测试

绘制程序流程图、程序流程控制图

环形复杂度:
1.程序控制流图中区域数
2.V(G)=E-N+2,其中,E是流图中边的条数,N是结点数。
3.V(G)=P+1,其中,P是流图中判定结点(分叉的点)的数目。

独立路径集合:
至少沿一条新的边移动的路径。对所有独立路径的遍历使得程序
中的所有语句至少被执行一次。

设计测试用例:
每一条路径设计一个,包括输入数据和预期结构。

代码检查种类:(了解区别)
1.桌面检查:程序员自查
2.代码审查:程序员讲解,与测试员共同检查
基本情况、注释、源代码细节。能不能让别人好理解。
3.代码走查:充当计算机,按照程序逻辑走一遍
4.技术评审:开发、测试和相关人员联合,采用讲解、提问等。一般有计划、流程和结果报告。

生命周期测试

V模型
使用范围:瀑布模型
描述了基本的开发过程和测试行为。
缺陷:测试放在最后阶段,没有尽早测试
优点:清楚表示了各个阶段,分工明确。
在这里插入图片描述

w模型
开发和测试是并行的关系。
优点:解决了v模型测试过完,让测试尽早介入开发。有利于及时了解项目的难度,设计结构和代码结构,及早识别测试风险,及早制定应对措施。
缺点:开发和测试的线性关系导致需求变更的不便。如果没有文档,根本无法执行W模型。
在这里插入图片描述

H模型
测试点就绪就可以做测试了
相比w模型来说让测试更早。
在这里插入图片描述
x模型
一边编码一边测,还加入了探索性测试
存在风险。
在这里插入图片描述
测试执行过程:
在这里插入图片描述

组件测试:

驱动模块和桩模块。
驱动:主程序,如junit
桩:嗲用的子函数,如junit里面的equals等方法

集成测试

在这里插入图片描述

1.非增量式测试
对每一个模块进行分别测试一个个测然后组合测试
先对abcdef单独测试,最后依据程序结构连起来集成测试
对b驱动模块是a,桩模块是e
2.增量式测试
(1)自顶向下增量式测试
深度优先方式的集成,一条路走到底在从另一条路走到底
顺序是abecdf
广度优先方式的集成,一层一层走
abcdef
(2)自底向上增量式测试
先ecf在bd在a
(3)混合增量式测试
衍变的自顶向下的增量式测试

自底向上-自顶向下的增量式测试
先向上过一遍在下

性能测试

1.常规性能测试:正常情况
2.压力测试(Stress Testing):不断增加压力,压力大小
3.负载测试(Load Testing):负载下持续时间
4.可靠性测试(Reliability Testing):平均无故障时间或系统投入运行后出现故障数目
5.大数据量测试:大量数据测试;也可以和上面组合进行综合数据量测试。

黑盒和白盒比较
在这里插入图片描述

下面的是了解
软件质量模型的内容了解每一项是干嘛的。

缺陷的类型:
错误,该有的没有,不该有的有,应该有的没有,难以理解

CMMI的级数判断
如: 某企业的软件成熟度等级为CMMI3级,说明他们满足了至少多少个过程域

18
1级0
2级7
3级11

六西格玛(6σ)管理:

软件测试的原则:
原则 1:测试说明缺陷的存在,而不能说明缺陷不存在。
原则 2:穷尽测试是不可能的。
原则 3:测试的尽早介入可以节省时间和成本。
原则 4:缺陷的群集效应。
原则 5:杀虫剂悖论。
原则 6:测试活动依赖于测试内容和情境。
原则 7:不存在缺陷的谬论。

软件测试计划内容

  • 9
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

一只小余

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值