- 案例1(狮子王游戏软件)
1994年美国迪士尼公司推出的狮子王游戏,因急于推出,没有对市面上的pc机进行兼容测试,导致很多pc机在安装后崩溃,以至于后续用户进行大量的投诉
- 案例2(火星登陆事故)
这个信息不知是否正确,火星登陆的时候,由于数据计算错误导致在火星登录器还未着陆的时候,被判断成已经着陆,提前释放了降落伞和保护罩,导致火星登录器坠毁
软件缺陷的定义
软件未达到产品说明书的功能《需求文档》
软件出现了产品说明书指明不会出现的问题
软件功能超出产品说明书的范围
软件测试员认为难以理解,不宜使用,运行速度缓慢,或者用户最终认为不好
—->所指是占比
- 软件产品规格说明书---->55%
很多时候,说明书没有写或者写的不够全面,经常更改,又或者开发小组没有很好的沟通,造成说明书理解的不一致
- 软件设计----->26%
没有做设计或设计不好,经常变动,和产品规格说明书一样的问题
- 编写代码---->15%和其他原因----->4%
# 需求人员 需求有错误 用户需求定义错误 需求记录错误 # 开发人员 设计说明书有误 编码说明有误 程序代码有误 # 测试人员 数据输入有误 测试有误 问题修改不正确 # 其他
不正确的结果是由于其他的缺陷产生的
# 缺陷发现的越早,则修复这个缺陷的代价就越小,在需求,设计,编码,测试,发布等不同的阶段,发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍
# 顾名思义,就是在规定的条件下对一个产品或程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。 # 什么是规定的条件? 比如开发有开发环境,测试有测试环境,意思就是我们要在这些环境下去进行测试,发现bug
需求评审参与人员:开发,测试,需求,项目经理
用例评审参与人员:开发,测试,需求,项目经理
# 1. 按阶段划分: 单元测试、集成测试、系统测试、验收测试 # 2. 按是否查看源代码划分: 白盒测试、黑盒测试 # 3. 白盒测试 是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法 大白话----->说白了就是测代码,可以说是具体到一个函数,一个类方法,去测这些方法能否实现 # 4. 黑盒测试 不需要了解程序的源代码,通过使用整个软件功能来验证程序是否满足需求的测试方法 大白话----->不需要接触代码,只是去测功能是否实现 # 5. 黑盒测试又分为:功能测试、性能测试 # 功能测试: 逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试 # 性能测试: 一般性能测试、稳定性测试、负载测试、压力测试 # 6. 按其他划分: 回归测试、冒烟测试、随机测试 # 7. 回归测试: 修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 比如在1.0版本中,有一个bug,到了2.0版本中,再重新测试1.0中这个bug # 8. 冒烟测试: 开发完成后进行的基本功能测试,看他是否具备可测性 指对一个软件进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。 测试小组在正式测试一个新版本之前,先指派一两个测试人员测试一下软件的主要功能,如果没有实现,则打回开发组重新开发,这样做可以节省大量的时间成本和人力成本。 # 9. 随机测试: 是指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误 # 10. 压力测试: 持续不断的给被测试的系统增加压力,直到被测试的系统压垮为止,用来测试系统所承受的最大压力。(测试强度)
# 11. 负载测试:
让被测系统在其能够忍受的压力范围之内连续运行,来测试系统的稳定性。(测试载重)
# 单元测试: 将软件的很多个模块进行测试,测试成功后合并到一起做一个冒烟测试,你可以理解为实现python中的一个类方法就是一个单元测试 # 集成测试: 将很多个单元测试集成到一起实现了某一个功能,常见的就是前后端交互 # 系统测试: 相当于去验证集成测试有没有问题,这个产品的很多个接口有没有问题,如果没有,那就验证他的性能有没有问题,主要就是看产品的功能有没有实现 # 验收测试: 用户那边去进行测试,如果没问题就是测试成功
#1. 应当把“尽早和不断地测试”作为开发者的座右铭。 #2. 设计测试用例时,应该考虑到合法的输入和不合法的输入,以及各种边界条件,特殊情况下要制造极端状态和意外状态,比如网络异常中断、电源断电等情况。 #3. 一定要注意测试中的错误集中发生现象,这和程序员的编程水平和习惯有很大的关系。 #4. 对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误,一定要有一个B来确认,严重的错误可以召开评审会进行讨论和分析。 #5. 制定严格的测试计划,并把测试时间安排得尽量宽松,不要希望在极短的时间内完成一个高水平的测试。 #6. 回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多错误出现的现象并不少见。7.妥善保存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档。
#1. w模型(重点)
W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。
测试与开发是同步进行的,从而有利于尽早地发现问题。
# 优点
1. 测试伴随着软件的整个生命周期,例如,在需求分析结束后就可以进行需求分析测试。 2. 测试与开发是并行独立进行的 # 缺点 1. 对有些项目,开发过程中根本没有文档产生,故W模型无法使用。 2. 对于需求和设计的测试技术要求很高,实践起来很困难。
# ② v模型(重点)
V 模型的左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。
它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
# 优点: 1、每一个阶段都清晰明了,便于控制开发的每一个过程。 2、既包含单元测试又包含系统测试。 # 缺点: 1、测试介入的比较晚,对于前期的一些缺陷无从发现和修改。 2、测试和开发串行。
③ 螺旋模型
# 优点: 1)设计上很灵活,可以在项目的各个阶段进行变更; 2)以小的分段来构建大型系统,使成本计算变得简单容易;(国企项目) 3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性; 4)随着项目推进,客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互; 5)客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。 # 缺点: 螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的。 因此,这种模型往往适应于内部的大规模软件开发。该模型建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。