## 软件测试流程(重点)
```
1.获取测试需求
2.编写测试计划
3.制定测试方案
4.开发与设计测试用例
5.执行测试
6.提交缺陷报告
7.测试分析与评审
8.提交测试总结
9.准备下一版本测试
记住上面的步骤
1.获取测试需求:
必须知道要做的软件有什么需求,不然不能定标准
2.编写测试计划:
就是对测试全过程的组织,资源,原则等进行规定和约束,并制定测试全过程各个阶段的任务及时间进度安排,
提出各项任务的评估,风险分析和需求管理
3.制定测试方案:
测试方案一般和测试计划同时编写
内容是描述需要测试的特性,测试的方法,测试环境的规划,测试工具的设计和选择,测试用例的设计方法,测试代码的设计方案
测试计划和测试方案的区别:
测试计划是组织管理层面的文件,从组织管理的角度对一次测试活动进行规划
测试方案是技术层面的文档,从技术的角度对一次测试活动进行规划
4.开发与设计测试用例:
在没有软件的时候,我们要设计出测试用例来,测试用例是我们重点中的重点,需要我们大量练习的
测试用例是指导我们怎么进行测试的,也是用来判断软件在运行中是否有缺陷的重要依据,有了测试用例我们才开始对软件进行测试
5.执行测试:
执行测试就是按照先写好的测试用例来运行软件,当然,软件研发出来才能执行测试,这个阶段是和开发工作有交集的阶段,如果执行测试,发现和我们预计的不一样,那么就是缺陷了,就要提交到缺陷报告中
6.提交缺陷报告
我们把执行测试用例发现的缺陷要汇总为缺陷报告,然后提交上去,开发人员去修改缺陷.缺陷报告后面我们会详细讲解怎么编写
7.测试分析与评审
提交缺陷报告后还要对我们的测试进行分析,分析这次测试发现了多少个缺陷,哪个模块最多,哪个人的缺陷最多
缺陷都是什么类型的缺陷,哪种类型的缺陷最多,有多严重,缺陷是否及时修复,生命力最强的缺陷活了多长时间
评审是在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评价和批准。后面有章节会详细讲解
8.提交测试总结
用ppt或world等常用的办公软件编写总结,总结的这次测试执行的结果,测试问题的解决,测试结果的分析,数据汇总等等,落实到书面文字上
9.准备下一版本测试
了解下一个版本大概什么时候可以开始测试,增加了什么需求等等
```
## 软件测试过程模型
```
1）软件测试过程模型概述
软件测试过程模型是来指导我们软件测试工作的(重点)
软件测试也有自己的过程模型。软件测试过程是一种抽象的模型，用于定义软件测试的流程和方法
2）V模型
3）W模型
4）H模型
5）X模型
6）测试过程理念
```
## V模型(重点)
```
V模型
揭示了开发过程与测试过程中各阶段的对应关系
缺点与不足
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证；
需求的满足情况一直到后期的验收测试才被验证；
没有体现出“尽早地和不断地进行软件测试”的原则。
v模型不太科学,是早期提出的
验收测试 --> 用户需求
用户需求会指导验收测试
需求分析与系统 -->系统测试
需求分析与系统会影响系统测试,系统测试要看看需求是否满足等
概要设计 --> 集成测试
我们集成测试要关注概要设计
详细设计 --> 单元测试
单元测试要关注详细设计
测试太靠后,是在编码之后才开始测试,风险太大,不科学
但是很多企业是使用这个模型
面试考察很多
记住V模型的内容和顺序,要能画出V模型图
1.用户需求 9.验收测试
2.需求分析与系统 8.系统测试
3.概要设计 7.集成测试
4.详细设计 6.单元测试
5.编 码
```
## W模型(重点,难点)
```
W模型
由两个V字型模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系。
优点：
测试的活动与软件开发同步进行(记住,W模型的核心思想)
测试对象不仅仅是程序，包括需求和设计
尽早发现软件缺陷可降低软件开发的成本
局限性：
在W模型中，需求、设计、编码等活动被视为串行的，这样就无法支持灵活的迭代
这个W模型的开发,不太灵活
开发 测试
1.用户需求 a.验收测试设计
2.需求分析与系统 b.确认与系统测试设计 8.交付 h.验收测试
3.概要设计 c.集成测试设计 7.实施 g.系统测试
4.详细设计 d.单元测试设计 6.集成 f.集成测试
5.编 码 e.单元测试
```
## H模型
```
H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
H模型揭示了一个原理：软件测试是一个独立的流程！(重要)
H模型指出软件测试要尽早准备，尽早执行；只要某个测试达到准备就绪点，测试执行活动就可以开展，(如果测试团队强大)并且不同的测试活动可按照某个次序先后进行，也可以反复进行。
测试准备 测试就绪点 测试执行
============|=================>测试流程
|
============>-----------其他流程
如:需求文档好了,那么就开始执行测试
如果代码好了,就执行单元测试
如果哪个模块好了,就执行测试
测试准备,准备什么?
1.人员
2.时间
3.软硬件
4.测试方案
5.等等
```
## X模型
```
X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序
X模型还定位了探索性测试(记住)，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
```
## 测试过程理念(重点)
```
1.尽早测试
测试人员早期参与软件项目。(项目一开始测试人员就要参与,有需求文档了,就要开始想怎么测试需求文档)
尽早的开展测试执行工作。(早执行测试,早发现问题,不让问题拖到后期,问题到后期,修复的代价越高)
2.全面测试
对软件的所有产品进行全面的测试。(程序,文档,数据等)
软件开发及测试人员（有时包括用户）全面的参与到测试工作中。(开发,测试,用户,如内测,公测)
3.全过程测试
测试人员要充分关注开发过程。(关注开发进度,开发慢了,留给测试人员测试时间短,就麻烦)
测试人员要对测试的全过程进行全程的跟踪。(从需求文档开始,一直要跟踪,bug提交给开发,你要跟踪开发有没有去修改等等,修复了测试还要去测试)
4.独立的、迭代的测试
测试活动是独立的。(最好独立,人员,管理)
测试活动应该是循环往复、不断的进行。(软件不可能没有bug,不能保证软件是一直是好的,所以有维护,有循环测试)
```
## 软件测试分类
```
1）按照开发阶段划分
2）按照测试技术划分
3）按照代码运行划分
4）按照软件特性分类
5）其他测试概念分类
```
## 按照开发阶段划分(重点)
```
单元测试
单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试
集成测试
集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统
确认测试 (不做为正式的测试环节)
确认测试也叫有效性测试。是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备了进入系统测试阶段的资质
系统测试
系统测试是在真实的系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并最终满足用户的所有需求
验收测试
是软件产品检验的最后一个环节。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。
```
## 按照测试技术划分(重点)
```
黑盒测试
通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。
白盒测试
通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的盒子里，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。
工资高
灰盒测试(不流行了,老的概念)
介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。
```
## 按照代码运行划分(重点)
```
静态测试
指不实际运行被测对象，而只是静态地检查程序代码、界面或文档中可能存在错误的过程。
代码测试：主要测试代码是否符合相应的标准和规范
界面测试：主要测试软件的实际界面与需求中的说明是否相符
文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求
动态测试
指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序
```
## 按照软件特性分类(重点)
```
功能测试：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求
逻辑功能测试:注册或登录后,我应该能进入电商,可以购物等等
界面测试:如,界面上不能有错别字,界面上颜色必须是友好的,不能搞的像"白事"一样
易用性测试:如,用这个软件用的比较方便,比如购物后,付钱流程很麻烦.
安装/卸载测试:各个平台能否正常安装,卸载等等,如mongodb安装就比较难安装,杀毒软件不太好卸载
兼容性测试:主要是兼容硬件和软件,测试软件在各个主要平台上进行测试,功能是否正常
性能测试
功能的另一个指标，主要关注软件中的某一功能在指定的时间、空间条件下，是否使用正常
软件的性能包括很多方面，主要有时间性能和空间性能两种
空间性能包括cpu的消耗,内存的消耗,硬盘的消耗等等
安全性测试
验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。
```
## 其他测试概念分类
```
回归测试(重点)
是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例
目的：
1.验证之前版本产生的所有缺陷已全部被修复；
2.确认修复这些缺陷没有引发新的缺陷
回归测试是比较重要的测试,也常会进行的测试活动,因为软件的版本常更新
冒烟测试
是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。也叫可测性测试。
1.有些地方也叫确认测试,正向测试比较多
2.冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性
随机测试
是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。
猴子测试
把自己当成不懂产品的笨蛋或者小动物, 随便乱点, 没有任何的主观意识和想法参与进来, 让一些意想不到的操作造成错误的结果。
```
## 按照测试运行主体划分
```
1.手工测试
2.自动化测试
```
## 小结(重点)
```
1.测试流程
获取需求->编计划->定方案->设用例->执行测试->提bug->分析与评审->提总结->准备下一个版本
2.V模型
1.内容:需求->分析->概要->详细->编码->单元->集成->系统->验收
2.特点:测试是后期介入,是过时的开发过程模型
3.W模型:
1.内容:开,需求->分析->概要->详细->编码->集成->实施->交付
测,验收设计->确认系统设计->集成设计->单元设计->单元->集成->系统->验收
2.特点:开发和测试是同步工作
4.H模型:
1.内容:测试准备 测试就绪点 测试执行
2.特点:测试的独立的,有什么就马上测试什么
5.x模型:
1.内容:程序段进行更小的拆分,然后进行测试.有探索性测试
2.特点:需要有测试经验丰富的人员进行
6.过程理念:
1.尽早,全面,全过程,独立迭代
7.软件测试分类:
1.黑盒测试 -->技术
2.系统测试 -->开发阶段
3.回归测试 -->其他测试概念
4.单元测试 -->开发阶段
5.冒烟测试 -->其他测试概念
6.安全性测试 -->软件特性
7.动态测试 -->代码运行
8.自动化测试 -->测试运行主体
9.单元测试包括接口测试吗?包括
```
## 软件测试原则(重点)
```
1.所有测试的标准都是建立在用户需求之上。
解释:
是用户的正确性需求,不能违规违法
2.软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。
解释:
什么是质量
1.功能是否全部实现
2.缺陷是否足够少
3.兼容性好不好
4.性能好不好
3.事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。
解释:
没有质量标准是不能进行测试,必须有质量标准(书面的)才可以取测试
4.软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。
W模型
5.穷举测试是不可能的。
6.第三方进行测试会更客观，更有效。
解释:独立的测试团队,测试更加有效果
7.软件测试计划是做好软件测试工作的前提。
测试计划
8.测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。
9.对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。
注意:缺陷有集群效应
10.重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）
11.应当把“尽早和不断地测试”作为测试人员的座右铭
12.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见
13.测试应从“小规模”开始，逐步转向“大规模”。
14.不可将测试用例置之度外，排除随意性。
15.必须彻底检查每一个测试结果。
16.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
17.对测试错误结果一定要有一个确认的过程。
```
## 软件测试职业发展
```
1.往测试技术方面发展
```
