TIP:
A:掌握,知识理解无偏差,熟练应用
B:理解,可以讲出来
C:了解,了解相关知识
TIP:
所有不满足需求或超出需求的都是缺陷
没有不存在缺陷的软件,只有迄今为止尚未被发现的缺陷
参考资料:软件开发模型
需求测试--单元测试--集成测试--系统测试--验收测试--alpha测试-(内)--beta测试(外)--UAT测试(用户接受度)--回归测试
需求规格说明书(SRS)-->概要设计(HLD:high level design) -->详细设计(LLD:low level design 伪码)--> 编码(Coding)
优点:
揭示了开发过程与测试过程中各阶段的对应关系
局限性:
优点:
局限性:
在W模型中,需求、设计、编码等活动被视为串行的,这样就无法支持灵活的迭代。
H模型将测试活动完全独立出来,形成了一个完全独立的流程,将测试准备活动和测试执行活动清晰的体现出来
H模型揭示了一个原理:软件测试是一个独立的流程!
H模型指出软件测试要尽早准备,尽早执行,只要某个测试达到准备就绪点,测试执行活动就可以开展,并且不同的测试活动可按照某个次序先后进行,也可以反复进行
X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,以后通过频繁的交接,通过集成最终合成为可执行的程序
X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,这以方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误
单元测试(模块测试)
单元测试又称模块测试,是针对软件设计的最小单位--程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求,发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试
单元测试一般要读程序和代码,大多数时候,都是由开发人员自己去完成(交叉,但是一般又不认为是在做测试),测试人员为什么不做单元测试?(大家不懂代码和算法)
集成测试(组装测试)
集成测试也叫做组装测试。通常在单元测试的基础上,将所有的程序模块进行有序的、递增测试。集成测试是检验程序单元或部件的接口关系,逐步集成为符合概要设计要求的程序部件或整个系统
比较多的涉及到接口测试(接口测试工具和方法专门学习)
确认测试(有效性测试、冒烟测试)
确认测试也叫有效性测试。是在模拟的环境下,验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试后的软件,才具备了进入系统测试的资质
确认测试(功能是否实现),一般都是正向的测试,不作为正式的测试环节
系统测试
系统测试是在真实的系统运行的环境下,检查完整的程序系统是否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确的配置、连接,并最终满足用户的所有需求
验收测试
是软件产品检验的最后一个环节。按照项目任务书或合同、仅需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接收或拒收系统。
供求双方,一般有三种验收测试的主体:
α测试:软件开发商交付前自己进行的测试
β测试:软件需求方自己进行的测试
γ测试:第三方的软件测试
静态测试:指不实际运行被测对象,而只是静态的检验程序代码、界面或文档中可能存在错误的过程
代码测试:主要测试代码是否符合相应的标准和规范
界面测试:主要测试软件的实际界面与需求中的说明是否相符
文档测试:主要测试用户手册和需求说明是否真正符合用户的实际需求
动态测试:指实际运行被测对象,输入相应的测试数据,检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试,唯一的标准是看是否运行程序
功能测试:是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求
性能测试:功能的另一个指标,主要关注软件中的某一功能在指定的时间、空间条件下,是否使用正常
软件的性能包括很多方面,主要有时间性能和空间性能两种
安全性测试:验证安装在系统内的保护机制是否能在实际应用中对系统进行保护,使之不被非法入侵,不受各种因素干扰
逻辑功能测试
界面测试
易用性测试
安装/卸载测试
兼容性测试
黑盒测试
通过软件的外部表现来发现其他缺陷和错误。黑盒测试把测试对象看成一个黑盒子,完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试,它只是检查程序是否按照需求规格说明书的规定正常实现
白盒测试
通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装载一个透明的盒子里,检查是否所有的结构及路径都是正确的,检测软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试
灰盒测试
介于白盒测试和黑盒测试之间的测试。灰盒测试关注输入的正确性,同时也关注内部表现,但这种关注不像白盒测试那样详细、完整,只是通过一些象征性的现象、事件、标志来判断内部的运行状态
手工测试(功能测试):点点点
自动化测试:利用工具软件或是编写代码的方式测试被测的软件系统
回归测试
是指对软件的新版本测试时,重复执行之前某一个重要版本所有测试用例
目的:
验证之前版本产生的所有缺陷已全部被修复
确认修复这些缺陷没有引发新的缺陷
冒烟测试
是指在对一个新版本进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性,也叫可测性测试
随机测试
是指测试人员基于经验和直觉的测试,发现一些边缘性的错误
猴子测试
把自己当成不懂产品的小动物,随便乱点,没有任何的主观意识和想法参与进来,让一些意想不到的操作造成错误的结果
用例编号、用例标题、所属模块、测试等级、预置条件、测试数据、操作步骤、预期结果、编写人员、编写时间、用例类型、备注、测试环境
测试用例示例
等价类、边界值、判定表、因果图、正交表、场景图(流程图法)、错误猜测法、状态迁移。
穷举(不可取)-->等价类(有效数据和无效数据)
取值规范:
当我的输入或者输出是一定范围的时候,取一个有效和两个无效的
当我的输入或者输出是布尔值的时候,取一个有效和一个无效
当我的输入或者输出是集合的时候,取一个有效和一个无效
当我的输入或者输出是一定规则的时候,取一个有效和n个无效
当我的输入或者输出是不同条件得到不同结果的时候,进行细分
设计用例思路
给需求进行分类
每个分类找出有效和无效
给有效和无效进行编号
设计一条用例,使其尽可能覆盖所有的有效编号
再设计一条用例,使其尽可能覆盖所有剩下的的有效编号
...
设计用例,一个无效写一条用例,确保其他数据有效
再设计用例,一个无效写一条用例,确保其他数据有效
...
等价类的补充,补充等价类中,可度量的情况下,用边界值用例设计方法
取点 y=4x+1 健壮性高低
当你的需求是不同条件组合,得到不同结果的时候,并且这里的每个条件取值是只有两种的情况下
设计用例思路
1.从需求里面提取出条件桩
2.画出条件项.2n
3.从需求里面提取出动作桩
4.根据需求填写动作项
5.合并
6.写测试用例,一种情况一条用例
当你的需求是不同条件组合,得到不同结果的时候,并且这里的每个条件取值可能大于等于1,可以使用正交,减少测试用例
场景图、错误猜测、输入域、输出域
遗漏、错误、额外实现、改进
流程管理平台:禅道、Bitnami Redmine Stack Manager Tool
正交表、评审、正规检视
原文:https://www.cnblogs.com/EwenJi/p/15225984.html