关于测试

最新推荐文章于 2024-08-05 20:30:00 发布

LuckyFBB

最新推荐文章于 2024-08-05 20:30:00 发布

阅读量1.5k

点赞数 2

分类专栏：测试文章标签：测试

本文链接：https://blog.csdn.net/LuckyFBB/article/details/80846846

版权

测试专栏收录该内容

1 篇文章 0 订阅

订阅专栏

三天的测试小结

软件测试的必要性

软件测试心理学

软件测试就是证明软件不存在错误的过程
软件测试的目的在于证明软件能够正确的完成其预定的功能
测试是为了发现错误而执行程序的过程

软件测试经济学

软件测试不能发现程序的所有错误
黑盒测试：通过有限的测试用例最大限度的提高发现
白盒测试
穷绝路经测试

测试的原则

测试用例中的一个必需部分是对预期输出或结果的定义。
程序员应当避免测试自己编写的程序。
编写软件的组织不应当测试自己编写的软件。
应当彻底检查每个测试的执行结果。
测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。
检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
应避免测试用例用后即弃，除非软件本身是一个一次性的软件。
计划测试工作时不应默许假定不会发现错误。
程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
软件测试是一项极富创造性、极具智力挑战性的工作。

测试与质量保证

正向思维

软件测试就是为程序能够按着预期设想那样运行而建立足够的信息
软件测试是一系列活动以评价一个程序或系统的特性或能力并能否达到预期的结果
测试时为了验证软件是否符合用户需求，即验证软件产品是否能正常工作

逆向思维

测试是为了证明程序有错，而不是证明程序无错误
好的测试用例在于它能够发现至今未发现的错误
成功的测试是发现了至今未发现的错误的测试

软件质量的内涵

质量是系统、部件或过程满足
a. 需求明确
b. 客户或用户需求或期望的程度不同

软件缺陷

软件缺陷术语
a. 错误(error)
b. 缺陷(fault)
c. 失效(failure)
d. 事故(incident)
软件缺陷构成：规格说明书；设计；代码；其他。

测试用例

测试用例是一组输入和为了某特定的目标而生成的预期结果及与之相关的测试规程的一个特定合集，或称为有效地发现软件缺陷的最小测试执行单元。

软件测试分类

按技术分类
- 白盒测试：对程序内部结构的分析、检测来寻找问题
- 黑盒测试：通过软件外部表现来发现其缺陷和错误
按测试方法分类
- 静态测试：对需求分析说明书、软件设计说明书、源程序做结构检查、流程图分析等找出软件错误分析
- 动态测试：执行被测程序，通过执行结果分析软件可能出现的错误。
按测试阶段分类
- 单元测试：各模块内部可能存在的各种差错。
- 集成测试：把通过单元测试的各个模块组装在一起之后进行测试。依据的标准是概要设计规格说明书
- 确认测试：检测集成后的软件功能是否符合用户需求。
- 系统测试：一般依据系统需求规格说明书。
- 验收测试：验证软件的功能、性能及其他特性是否与用户的要求一致。
按测试内容分类
- 功能测试：验证每个功能是否按照事先定义的要求那样正常工作。
- 压力测试：用来检测系统在不同负载条件下的系统运行情况。
- 性能测试：不同负载条件下的系统具体性能指标。

常见测试模型

V模型

局限性：仅仅是把测试作为编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认功能。
W模型

局限性：w模型的发展，强调的是测试伴随整个软件开发周期，测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，有利于尽早发现问题。
H模型

强调测试是独立的，只要测试准备完成，就可以执行测试。

软件测试方法

等价类划分方法

等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的。
分为有效等价类和无效等价类。

边界值分析方法

确定边界情况（输入或输出等价类的边界）
选取正好等于、刚刚大于或小于边界值作为测试数据

决策表(判定表)

条件桩：列出问题的所有条件
动作桩：列出可能针对问题所采取的操作
条件项：针对所列条件的具体赋值
动作项：列出在条件项（各种取值）组合情况下应该采取的动作。
规则：任何一个条件组合的特定取值及其相应要执行的操作。(与取值和条件有关)

因果图

多种输入条件的组合，产生多种结果设计测试用例。
1. 恒等-关系:果J取决于因i。因出现，则果也出现。
2. 非-关系:只有当因i不存在时，果J才出现
3. 或-关系:i1或i2存在时，结果J才出现
4. 与-关系:i1、i2同时存在时，结果J才出现

约束：输入状态相互之间还存在某些依赖关系
1. E约束(异)：条件中最多一个为真
2. I约束(或)：条件中至少一个为真
3. R约束(要求)：条件均相同
4. O约束(唯一)：条件中有且只有一个为真
5. M约束(强制)：若E1为1，强制E2为0。

逻辑覆盖

语句覆盖
设计若干测试用例，运行被测程序，是程序中的每个可执行语句至少被执行一次。
判定覆盖
设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。
条件覆盖
设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。
判定-条件覆盖(不够强大)
判定和条件覆盖设计方法的交集
条件组合覆盖(效率不高)
设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次。

基本路径测试

路径覆盖就是设计所有的测试用例，来覆盖程序中的所有可能的执行路径
圈复杂度(环路复杂度):代码逻辑复杂度的度量。
V(G)=连线数量-节点数量+2

单元和集成测试

单元测试

定义
单元测试是对软件基本的组成单元进行独立的测试
时机
单元测试与编码同步进行
在TDD中，强调测试在先，编码在后
单元测试一般由开发人员完成，QA人员辅助
尽早发现错误，降低成本，修改问题更容易
检查代码是否符合设计和规范，有利于将来代码的维护
目标
单元模块被正确编码
内容
a.模块接口测试
b.局部数据结构测试
c.执行路径测试
d.边界条件测试
e.错误处理测试

集成测试

识别组合单元之间的问题
1. 分类
非渐增式测试模式:先分别测试每个模块，再把所有的模块按着设计要求放在一起结合成所要的程序。
渐增式测试模块:把下一个要测试的模块同已经测试好的模块结合起来进行测试。
2. 桩模块和驱动模块
- 桩模块:用来模拟被测试模块工作过程中所调用的模块。(自顶向下)
- 驱动模块:用来模拟被测试模块的上级模块。(自底向上)