软件测试:软件测试基础笔记(1)

测试基础
开发模型分类
瀑布模型
快速原型模型
螺旋模型
一、测试模型-v模型(重要)
需求分析➡概要设计➡详细设计➡编码 ➡单元测试➡集成测试➡系统测试➡验收测试
v模型1、单元测试:又称模块测试,针对单一的程序模块进行的测试
2、集成测试:又叫组装测试,在单元测试的基础上进行的测试
3、系统测试:将整个软件看作一个整体来进行测试包括功能、性能、兼容性
4、验收测试
(1)内测版(alpha)内部交流版本,可能存在很多bug,不建议用户安装
(2)公测版(beta)面向所有用户,通过用户反馈,再去修改细节
(3)候选版(gamma)与正式软件相差无几
优点:
01 测试V模型即包含了底层测试又包含了高层测试;
底层测试:检验源代码质量的测试,如:单元测试;
高层测试:检验整个系统的需要,如:系统测试;
02 V模型清楚地标识出了软件开发的阶段。
03 它采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段,每个阶段的工作都很明确,
因此便于控制开发过程。当所有的阶段都完成之后,该软件的开发过程也随之结束。
缺点:
V模型一大缺点正是它自身的顺序性所导致的。到了测试阶段,程序已经完成,错误已经产生,
很多前期的错误一直到测试阶段才发现,甚至无法发现,往往无从修改了。
同时实际的开发过程中,在需求阶段很难把用户的需求完全明确下来,因此,当需求变更时将会导致阶段反复,
而且都要重复需求、设计、编码、测试等过程,返工量非常大,模型灵活性比较低。
二、w模型
优点:开发和测试伴随着整个开发周期,需求和设计同样要测试;更早的介入测试,可以发现初期的缺陷,修复成本低;分阶段工作,方便项目整体管理。
缺点:开发和测试依然是线性的关系,需求的变更和调整,依然不方便;如果没有文档,根本无法执行w模型;对于项目组成员的技术要求更高!
定义:开发一个v;测试一个v组合起来的模型(w模型也叫双v模型)
总结:v模型适用于中小企业,w模型适用于中大型企业(因为人员要求高),h模型人员要求非常高,很少有公司使用。
三、软件测试分类(重要)
软件测试分类1、按测试阶段划分:单元测试、集成测试、系统测试
2、是否覆盖源代码:
(1)白盒测试
(2)黑盒测试:1、功能测试 2、性能测试
3、是否运行:静态测试(不运行程序)、动态测试(运行程序)
4、其它:1、回归测试 2、冒烟测试 3、随机测试 4、验收测试(内测、公测、候选版)
5、是否自动化:1、人工测试 2、自动测试

黑盒测试:又称数据驱动测试,完全不考虑程序内部结构和内部特性,注重于测试软件的功能需求,只关心软件的输入数据和输出数据
白盒测试:把盒子打开研究里面的程序结构和源代码;
黑盒测试分类:(背)
一、功能测试:
1、逻辑功能测试
2、界面测试
3、易用性测试
4、安装测试
5、兼容性测试
二、性能测试:
1、时间性能
2、空间性能
3、一般性能
4、稳定性
5、负载测试
6、压力测试
随机测试:
针对重要功能、新增加的功能、特殊情况、以前发现过重大bug的模块进行二次测试;也叫探索测试,它可以结合回归测试来使用;
四、测试用例
测什么,怎么测
五、等价类划分法:
属于黑盒测试,它将不能穷举的测试过程进行分类,从而保证完整性和代表性;
思考步骤:
1、确定有效等价类和无效等价
2、有效等价类划分(题目条件,还要注意边界值(极值),中间再随意找个值)
3、无效等价类划分(跟有效等价类相反,其它特殊情况(中文、英文、特殊符号、空格、空))
注意:两个框要一个正确,一个错误,这样才能准确的判断;一定要根据需求来判断预期结果;
等价类细节
1、 考虑输入长度
2、 考虑输入类型
3、 组成规则
4、 是否为空
5、 是否区分大小写
6、 是否重复
7、 是否去除空格
六、边界值
我们在测试过程中,一定要小心边界值(极值),因为在程序中这些边界最容易出问题;具体测试用例书写思路:找到边界值和它两端的值,分别进行测试;
总结:边界值思想应该是选到边界和刚超过的值,来进行测试,也要根据实际情况来选择;边界值和等价类是相辅相成的关系,配合使用的。
七、因果图
因:输入条件
果:输出条件、出结果
适用于输入条件之间有相互制约、相互依赖的情况;
因果图中的符号:
1、恒等—有因就有果,没有因就没有果
2、非—有因没有果,没有因有果
3、或—条件有一个是真,结果就是真,条件都是假,结果才是假
4、且(与)–条件都为真,结果才是真,一个条件为假,结果就是假
判定表
根据因果图来制作判定表(因果图可以不画)
组成部分:
1、 条件桩:所有条件
2、 动作桩:所有结果
3、 条件项:针对条件桩的取值
4、 动作项:针对动作桩的取值
书写步骤:
1、 列出所有条件和动作桩
2、 填写条件和动作桩中的项目
3、 简化判定表
注意:如果出现“-“代表此选项不影响最终结果。
八、场景法
要用来测试业务流程;分为基本流(正确流程)和备选流(错误流程)
注意:还要补充一些异常情况;
在冒烟测试中主要采用场景法来测试;
九、流程分析法
适用于有先后顺序的测试;常用于业务流程、安装流程等等。每个流程就是一条测试用例,它只是在测试整体流程是否正确,细节还需要使用等价类、边界值等方法进行完善;
十、错误推断法
凭着直觉和经验来设计测试用例,它是根据之前项目相关的bug数据总结来的;
十一、正交表
从全面试验中挑选出有代表性的点进行测试(均匀分散,整齐可比);高效率、快速、经济的方法;
十二、正交表概念
正交表:一种特制的表,一般的正交表记为:Ln(mk)
-n是表的行数,也就是需要测试组合的次数
-K是表的列数,表示控件的个数(因素的个数,或因子个数)
-m是每个控件包含的取值个数(各因素的水平数,即各因素的状态数)
如: L9(34)
有4个控件
每个控件有3个取值
9为需要测试的组合个数
叫4因素3水平
十三、正交表使用方法
1、 根据控件和取值数选择一个合适的正交表
2、 列举取值并编号,生成取值表
3、 把取值表与选择的正交表进行映射
十四、混合正交表工具
在实际工作中,很多情况都是因素(控件个数)和水平(每个控件的可选个数)不同,我们在现成的正交表中找不到对应的表格,此时我们就需要使用混合正交表工具来生成混合正交表;
使用步骤:
1、 制作取值表(不需要编号,列出数据即可)

2、 复制表格中的数据放在一个新建的txt文本文档中,保存到allpairs文件夹中(例如:test2.txt)
3、 Win+r再输入cmd进入控制台界面
4、 使用控制台代码进入allpairs文件夹中(例如: e: 回车 cd 复制文件夹路径 回车)
5、 再输入allpairs.exe test2.txt>chenggong.txt (test2.txt是我们刚新建的文件,chenggong.txt是我们最终生成出来的正交表文件)
十五、测试方法的选择
• 通常在确定测试方法时,有以下几条参考原则(1/2):
– (1)拿到一个测试任务时,先关注它的主要功能和业务流程、业务逻辑是否正确实现,考虑使用场景法。
– (2)需要输入数据的地方,考虑采用等价类划分法,包括输入条件和输出条件的等价划分,将无限测试变成有限测试。
– (3)在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。
– (4)如果程序的功能说明中含有输入条件的组合情况,则一开始就应考虑选用因果图和判定表法。
– (5)对于参数配置类的软件,需要考虑参数之间的组合情况,考虑使用正交排列法选择较少的组合方式(最少的测试用例获得最大的的测试覆盖率)。
– (6)对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准,则应当再补充更多的测试用例。
– (7)采用错误推断法再追加测试用例——依靠测试工程师的经验和智慧。
十六、软件缺陷
定义:缺陷就是软件的问题,最终表现为没有满足用户的需求。
哪些属于软件缺陷
1、软件未达到规格说明书表明的功能
2、软件出现了规格说明说中指明不会出现的错误。
3、软件功能超出了规格说明书指明的范围
4、软件未达到规格说明书虽未指明但应该达到的目标
5、软件测试人员或用户觉得不好
缺陷的表现形式
1、功能、特性没有实现或者部分实现
2、设计不合理、功能不明确、逻辑不清楚或存在矛盾
3、实际结果和期望结果不同
4、没有达到规格说明说要求的性能指标
5、运行出错、崩溃、中断、界面混乱
6、数据不正确、精度不够、不完整或格式不统一
7、用户不能接受的其它问题,如存取时间过长、界面不美观
8、硬件或软件存在其它问题
缺陷的状态(重要)
1、提交—测试人员提交了一个缺陷给程序员
2、打开—待处理
3、拒绝—程序员认为不是缺陷或者重复,就可以修改状态为拒绝
4、修复—程序员修复缺陷后提交的一个状态
5、关闭—测试人员经过回归测试后,认为此缺陷已经解决,将其关闭
6、推迟—可以放在后续版本解决的问题,但是要详细写出修复的日期或版本

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值