一、软件和软件测试
1、软件缺陷的定义
- 所有不满足需求或超出需求的都是缺陷
- 没有不存在缺陷的软件,只有至今尚未发现的缺陷
- 软件未实现产品说明书要求的功能
- 软件出现了产品说明书指明不应该出现的功能
- 软件实现了产品说明书未提到的功能
- 软件未实现产品说明书虽未明确提及但应该实现的目标
- 软件难以理解,不易使用,运行缓慢或者(从测试的角度看)最终用户会认为不好
2、软件测试的定义
正向思维
- 测试是使自己确信产品是能够正常工作的,评价一个程序或系统的特性或能力,并确定它是否达到期望的结果
反向思维
- 测试是为发现错误而执行一个程序或系统的过程
- 测试是为了证明程序有错,而不是证明程序无错
- 一个好的测试用例在于它能发现以前未发现的错误
- 一个成功的测试是发现了以前未发现的错误的测试
IEEE
国际电气电子工程协会(Institude of Electrical and Electronics Engineers)
- 测试是在规定条件下运行系统或构件的过程:观察和记录结果,并对系统或构件的某些方面给出评价
- 测试是分析软件项目的过程:检测现有状况和所需状况之间的不同,并评估软件项目的特性
广义的软件测试定义
- 软件测试是对软件形成过程中的所有工作产品(包括程序以及相关文档)进行的测试,而不仅仅是对程序的运行进行测试
3、软件测试的目的
- 尽可能早的找出软件缺陷,并确保其得以修复
- 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷
4、软件测试的原则
- 所有的测试标准都是建立在用户需求上的
- 质量第一
- 测试用例是设计出来的,而不是写出来的
- 重视文档
- 尽早和不断的测试
- 完全测试程序是不可能的
- 测试是有风险的
- 测试无法显示潜伏的软件缺陷
- 找到的软件缺陷越多,说明还可能会有更多(集群效应)
- 不一定所有的软件缺陷都要修复
- 杀虫剂怪事,测试越多,其对测试的免疫力就越强
- 尚未发现或未观察到的软件缺陷是能说是潜在缺陷
5、确认和验证的区别
- 确认是通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现
- 验证是证实指定的需求是否满足
6、测试和调试的区别
| 测试 | 调试 |
---|
主体 | 测试人员 | 开发人员 | 目标 | 找 bug | 修复 bug | 方法 | 等价类、边界值等 | 程序和算法 | 思路 | 反向思维 | 正向思维 |
1、简单来说,测试是发现、报告和跟踪 bug;而调试是定位 bug 位置,分析 bug 原因,并修复 bug
2、测试是从已知的条件开始,使用预先定义的过程,并且有预知的结果;调试是从未知的条件开始,结束的过程可能不可预计
3、测试可以计划,可以预先指定测试用例和和测试过程,工作进度可以度量;而调试的过程或持续时间不可计划
4、测试的对象包括软件开发过程中的文档、数据以及代码;而调试的对象一般来说只是代码
二、软件工程
1、软件危机和软件工程
1、软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题的现象
2、软件工程包括软件开发技术和软件项目管理
3、软件测试是软件质量管理体系中一个非常重要的手段(重要)
2、软件生命周期
3、软件开发模型
瀑布模型
定义阶段:计划、需求分析 开发阶段:设计、编码、测试 维护阶段
-
存在的问题 强调时间顺序的严格执行,前阶段不完成,后阶段不开始 将测试放在了编码之后,没有体现出测试贯穿整个软件生命周期的原则 -
优点 为项目提供了按阶段划分的检查点 当前阶段完成后,只需要去关注后面的阶段 -
缺点 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量 线性开发,用户等到整个过程的末期(end)才能见到开发成果,从而增加了开发风险 不适应用户需求的变化
螺旋模型
- 引入了其他模型不具备的风险分析,是软件在无法排除重大风险时有机会停止,以减少损失
- 适合大型的、昂贵的、系统级的软件应用
迭代模型
- 迭代包括产生产品发布(稳定的、可执行的产品版本)的全部活动和要使用该发布必须的其他要素,强调开发的深入
- 在某种程度上,开发迭代是一次完整的经过所有工作流程的过程:需求分析、设计、实施和测试
敏捷模型——敏捷开发 Scrum
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。(百度百科解释) 图片来源于百度百科
增量模型
增量模型是把软件分割成独立的模块,分批次的完成和交付,一般会和迭代模型一块使用 缺点:打破了原有的软件结构和框架,可能会带来一定的风险
快速原型模型
快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析,快速实现一个原型,用户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,适应变化,最终提高软件质量。
三、测试流程
1、软件测试流程
2、软件测试过程模型
V 模型
- 缺点
需求的满足情况一直到后期的验收测试才被验证 没有体现出“尽早地和不断地进行软件测试”的原则
W模型
- 优点
测试活动与软件开发同步进行 测试对象不仅仅是程序,还包括需求和设计过程中产生的文档 尽早发现软件缺陷可以降低软件开发的成本 - 局限性
不灵活
H模型
- 原理
软件测试是一个独立的流程,软件测试要尽早准备,尽早执行(人员、时间、方案、设备)
X模型
定位了探索性测试,即不进行事先计划,帮助有经验的测试人员在测试计划之外发现更多的软件错误
3、软件测试过程理念
四、测试用例
1、测试用例的定义
设计一个情况,软件程序在这种情况下,必须能够正常运行并且达到程序所设计的预期结果
2、测试用例模板
3、测试用例设计方法
- 黑盒测试,又称为数据驱动或输入输出驱动的测试,将测试对象(程序)视为一个黑盒子,测试目标与程序的内部机制和结构完全无关
- 黑盒测试的目标是找出程序不符合规格说明书的地方
- 白盒测试,又称为逻辑驱动测试或透明盒测试,检查程序的内部结构,对程序的逻辑结构进行检查
- 白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构的程度
等价类划分法
把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据作为测试用例。测试每个等价类的代表性数据等同于测试该类的其他任何数据。 如果等价类的某个测试用例发现了某个错误,该等价类的其他测试用例也应该能发现同样的错误。反之,如果测试用例没能发现错误,那么我们可以预计,该等价类中的其他测试用例不会出现错误
可划分为有效等价类和无效等价类 注意:不要出现重复的情况,也不要出现缺少的输入部分
边界值分析法
考虑了边界条件的测试用例与其他没有考虑边界条件的测试用例相比,具有更高的测试回报率 边界条件是指输入和输出等价类中那些恰好处于边界、或超出边界、或在边界以下的状态
- 如果输入条件规定了一个输入值范围,那么应针对范围的边界设计测试用例,针对刚刚越界的情况设计无效输入测试用例
- 如果输入条件规定了输入值的数量,那么应针对最小数量输入值、最大数量输入值,以及比最小数量少一个、比最大数量多一个的情况设计测试用例
- 如果程序的输入或输出是一个有序序列,则应特别注意该序列的第一个和最后一个元素
因果图法
- 介绍
因果图法是一种适合于描述对于多种输入条件组合的测试方法 - 对比
边界值分析和等价类划分的一个弱点是未对输入条件的组合进行分析 - 设计步骤
1、认真分析规格说明书以确定出“因” 和 “果” 2、建立因果图 3、建立有限项的判定表。“因” 是条件,而 “果” 是动作 4、将判定表转化为测试用例
错误猜测
- 基本思想
列举出可能犯的错误或错误易发情况的清单,然后根据清单来编写测试用例 - 特点
直觉 + 经验
4、测试策略
- 如果规格说明中包含输入条件组合的情况,应首先使用因果图分析方法
- 在任何条件下都应使用边界值分析方法,对输入和输出边界进行的分析
- 应为输入和输出确定有效和无效等价类,在必要情况下对上面确认的测试用例进行补充
- 使用错误猜测技术增加更多的测试用例
- 针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则(最后一个最为完整)。如果覆盖准则未能被前四个步骤中确定的测试用例所满足,并且满足准则也并非不可能,那么增加足够数量的测试用例,以使覆盖准则得到满足
五、软件缺陷
1、缺陷的基本概述
缺陷的定义
缺陷的类型
- 功能(Function)
- 界面(UI)
- 文档(Documention)
- 软件包(package)
- 性能(performance)
- 接口(interface)
缺陷的严重程度
- 致命(Fatal)
- 严重(Critical)
- 一般(Major)
- 较小(Minor)
缺陷的修复优先级
- 立即解决(P1 级)
- 高优先级(P2 级)
- 正常排队(P3 级)
- 低优先级(P4 级)
缺陷的状态
- 激活/打开
- 确认
- 已修复/修正
- 关闭/非激活
- 重新打开
- 推迟
- 保留
- 不能重现
- 需要更多信息
- 重复
- 不是缺陷
- 需要修改需求说明书
缺陷的来源
2、缺陷的生命周期
发现缺陷
提交缺陷
确认缺陷
分配缺陷
修复缺陷
验证缺陷
关闭缺陷
3、缺陷的识别
- 依据需求文档、设计文档、产品原型、测试用例
- 同行业类似的成熟软件
- 和开发人员沟通,跟有经验的测试人员沟通
4、缺陷报告
5、测试需求、测试用例和缺陷报告的关系
- 首先要知道测试的基本流程:
- 每一个测试需求点就是一个测试点(测试项)
- 获取测试需求的过程中要利用思维导图对测试需求进行全面的分析
- 根据测试需求中的每个需求点进行测试用例的设计
- 执行测试之后,要有能展示测试人员工作量的东西——缺陷报告,记录了缺陷数量和用例的数量。其中最重要的是设计的测试用例总量(TC)和执行的测试用例数量(EC)
|