对测试的简单了解——笔记

一、为什么需要软件测试

1.一款软件从无到有，会经历很多的开发阶段，有不同的人参与开发，所以最终产出的软件功能可能会存在问题，因此未来保证软件的功能是可用的，我们必须要进行测试！

2.当前软件行业，已经不再是功能为王，用户不仅仅只盯着软件的功能是否满足需求，还会对软件是否容易上手，执行效率是否OK，等等一系列其他体验都有了很高的要求，所以这也是需要我们对软件进行大量的测试来达到我们最终想要的结果。

二、为什么选择软件测试

1.需求量大

2.薪资可观

3.行业稳定

4.不受开发语言限制

三、为什么不让开发做测试

1.专业度

2.思维定制

3.测试力度

四、什么是软件测试

定义：通过手工或者工具对“被测对象”进行测试操作，从而验证实际结果与预期结果是否存在差异。

五、测试级别

软件的开发都会依据相应的开发模型，而测试级别指的就是在这个模型当中我们人为定义的开发步骤。

开发模型：W模型,V模型,H模型，瀑布模型

1.单元测试

软件由多个模块组成，对每个模块单独进行测试

2.集成测试

模块联合使用是否可以正常使用

3.系统测试

开发完成，一期完成之后的测试，一般是两到三轮的测试。

4.验收测试

三个阶段：

α测试：测试作为用户

β测试：公测，软件几乎没有很大的问题

UAT测试：安全要求高的，进行专项测试

α测试：非正式验收测试，由用户、测试人员、开发人员共同参与的内部测试 。α测试是指软件开发公司组织内部人员在开发环境下模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。

β测试：内测后的公测，即将正式发布，完全交给最终用户的测试。β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)，着重于产品的支持性，包括文档，客户培训和支持产品生产能力。

注：α测试和β测试均不能由程序员和测试员完成。

六、系统测试分类

1.功能测试

2.兼容性测试

3.安全性测试

4.性能测试

七、常见的测试方法

三个方面

一、按测试分类进行分类

1.黑盒测试：测试软件外在主体功能是否可用

2.白盒测试：这种测试的主体就是软件的底层代码，不在意外在的界面，只要求底层功能实现，同时逻辑正确

3.灰盒测试：介于两者之间，（接口测试）

二、按测试对象是否执行分类

1.静态测试：指的就是测试对象不执行

2.动态测试：将软件运行在真实地使用环境中，进行测试

三、按测试手段进行分类

1.手工测试：测试人员手动的对被测对象进行验证。优点：可以灵活地改变测试操作及环境

2.自动化测试：分为两种 优点：高效率执行人工无法实现的操作。

1.自己写测试脚本

2.通过第三方工具测试

八、软件质量的特性

1.功能性：软件需要满足用户显示和隐式的功能

2.易用性：软件易于学习和上手使用

3.可靠性：软件必须实现需求当中的具体功能

4.效率性：类似于软件的性能

5.可维护性：要求软件具有将某个功能修复之后，有继续使用的功能

6.可移植性：当前软件从一个平台移植到另一平台上使用的能力 java

九、软件测试流程

1.需求分析：梳理清楚需要涉及测试的业务点是什么

需求分析的来源：规格说明书，API文档,竞品分析，个人经历

2.设计测试用例：用例是用户为了测试软件的某个过程而执行的操作过程

3.测试用例评审：由测试人员发起，将一些相关的开发人员客户代表等相关项目人员组织起来进行测试用例评审，确定本 项目采用放入测试用例完整度和测试效果，最后相关人员进行签字确认。

4.配置环境：

环境：当前被测对象运行所需要的执行环境，作为测试人员需要具备配置环境的能力。

环境的分类：操作系统，服务器软件，数据库，软件底层代码的执行环境

5.执行用例：执行用例之前会做一个冒烟测试。如果冒烟测试通过才会开展全面的测试工作。

冒烟测试：来源于硬件测试失败冒烟效果，在这里指的是软件的主体业务功能是否可以正常运行。

6.回归测试及缺陷跟踪：

定义：当我们将某个缺陷提交给开发人员之后，由他们进行修复，完成之后需要测试人员再次进行测试。

7.输出测试报告：将当前的测试过程中产生的数据进行可视化的输出，方便其他人查看。

8.测试结束：将整个测试过程中产生的一些文档进行整理归档，方便后续版本使用。

十、常见的软件架构

软件架构：用来指导我们软件开发的一种思想。

两种架构模式：

1.B/S Browser - Server

2.C/S Client - Server

比较

1.标准 ：相对于C/S来说，C/B架构两端都是在使用现成的成熟产品，所以B/S架构会显示的标准一些。

2.效率：相对于B/S架构来说，C/S架构中的客户端可以分担一些数据的处理，因此执行效率高一些。

3.安全：B/S架构当中的数据传输都是以HTTP协议进行的传输，而HTTP协议又是明文输出，可以被抓包，所以B/S不太安 全

4.升级：B/S架构只需要在服务器里将数据进行更新，前台只需要更新页面就可以，C/S架构需要将两端都进行更新。

5.开发成本：C/S架构当中的客户端需要自己开发，所以相对于B/S架构成本更高一些。

十一、浏览器和图片类型

一、浏览器是什么

浏览器本质就是一款软件，安装在操作系统之上，一般给用户提供浏览网页的服务

二、五大浏览器生产厂商

1.IE

2.Chrome

3.FireFox

4.Safari

5.Opera

三、常见的图片类型

1.JPG（JPEG）：这是一种可以高度保留图片色彩信息的格式。

2.PNG：该类型的图片可以实现透明。

3.GIF：图片所占体积小，可以实现动图。

4.PSD：一种分层图片。

十二、软件开发模型

1.瀑布模型

是线性模型的一种，占有重要地位，是其他模型的基础

需求分析--->设计---->编码--->实现--->软件测试--->完成--->维护

之后就是 : ->需求变更---->软件测试--->维护

优点：

• 开发的各阶段比较清晰

• 强化早起计划及需求调查

• 适合需求稳定的产品开发

缺点：

• 依赖于早期的需求调查，不适应需求的变化

• 单一流程不可逆

• 风险往往延至后期才显露，失去及时纠正的机会

• 问题在项目后期才开始暴露

• 前期未发现的错误会传递并扩散到后面的阶段，可能会导致项目失败

  改良

  • 每个阶段都可以融入小的迭代工作

2.快速原型模型

在开发系统之前，构造一个原型，在这个原型的基础上，逐渐完成整个系统的开发工作

快速分析——需求说明——构造原型——原型——运行原型——评价原型——修改意见

步骤

• 构建一个原型，实现用户与系统的交互，用户对原型进行一个评价，进一步细化对待开发软件的需求，通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么。

• 在上一步的基础上开发出用户满意的软件产品。

优点：

• 克服瀑布模型的缺点，更好的满足用户的需求，并减少由于软件需求不明确带来的项目开发风险，适合预先不能确切定义需求的软件系统的开发 。

缺点：

• 不适合大型系统的开发，前提要有一个展示型的产品原型，因此在一定程度上限制开发人员的灵活性

3.螺旋模型

十二、软件测试模型

随着测试过程的管理和发展，测试人员通过大量的实践，从而总结出了不少测试模型，如常见的V模型，W模型，H模型等，这些模型与开发紧密结合，对测试活动进行了抽象，成为了测试过程管理的重要的参考依据。

一、V模型

概念

• 需求分析

即首先要明确客户需要的是什么，需要软件做成什么样子，需要有哪几项功能，这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确的把客户所需要达到的功能，实现方式，等表述出来，给出分析结果，写出需求规格说明书。

• 概要设计

主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。

• 详细设计

对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，这一阶段要求达到伪代码级别，已经把程序的具体实现的功能，现象等描述出来。其中需要包含数据库设计说明。

• 软件编码

按照详细设计好的模块功能表，编程人员编写出实际的代码。

• 单元测试

按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同，比如有具体到模块的测试，也有具体到类，函数的测试等。

• 集成测试

经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。

• 系统测试

将整个软件系统看做一个整体进行测试，包括对功能、性能以及软件所运行的软硬件环境进行测试 。

系统测试由黑盒测试员来完成，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，是否存在漏洞，以及在不同的软硬件环境中的兼容性，主要依据是《系统需求规格说明》文档 。

• 验收测试

主要就是用户在拿到软件的时候，在使用现场，会根据用户需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。包括功能确认测试、安全可靠性测试、易用性测试、可扩充性测试、兼容性测试、资源占用率测试、用户文档资料验收等。

优点：

1. 测试V模型即包含了底层测试又包涵了高层测试

2. V模型清楚地标识了软件开发和测试的各个阶段

3. 它采用了自上而下的逐步求精的方式，把整个开发模型分成了不同的阶段，每个阶段的工作都很明确，因此便于控制开发的过程。当所有的阶段都完成之后，该软件的开发过程也随之结束。

缺点：

• V模型一大缺点正是它自身的顺序性所导致的。到了测试阶段，程序以及完成，错误以及产生，很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了

• 同时实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复，而且都要重复需求，设计，编码，测试等过程，返工量非常大，模型灵活性比较小。

二、W模型

W模型是由V模型演变而来的，它强调测试伴随整个软件生命周期。其实W模型是个双V模型，软件开发是一个V模型，而软件测试是与开发同步进行的另一个V模型。

优点：

• 开发强调测试伴随整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试。

• 更早的介入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复。

• 分阶段的工作，便于控制项目过程。

缺点：

• 依赖于软件开发和软件测试依然保持一前一后的线性关系，依然无法支持迭代，自发性和需求等变更调整。

• 对于当前很多项目，在执行的过程中根本不产生文档，那么W模型基本无法适用。

• 使用起来技术复杂度很高，对于需求和设计的测试要求很高，实践起来很困难。

三、H模型（不是重点）

十三、测试用例

定义：测试用户(Test Case)是为特定的目的而设计的一组测试输入，执行条件和预期的结果，以便测试是否满足某个特定的需求，通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的依据。

测试用例就是建造一个小场景去测试某一个软件，去比较预期结果和实际结果之间的差异。

十四、测试用例八大要素

1. 用例编号

2. 用例标题

3. 测试项目

4. 用例级别

5. 预置条件

6. 测试输入

7. 执行步骤

8. 预期结果

   实际结果

   是否bug

十五、测试用例测试方法————等价划分法

定义：等价划分法是一种重要的、常用的黑盒测试方法，不需要考虑程序内部结构，只需要考虑程序的输入规格即可。它将不能穷举的测试过程进行分类，从而保证设计出来的测试用例具有完整性和代表性

有效等价类：对于程序的规格说明来说是合理的，有意义的输入数据构成的集合，它能检验程序是否可以实现规格说明中所规定的的功能需求。————>满足题目需求

无效等价类： 对于程序的规格说明来说是不合理的或无意义的输入数据构成的集合，它能检验程序在不符合规则的数据输入下，是否会有异常。————>不满足题目需求

等价类设计步骤

1. 明确需求

2. 确定有效和无效等价类

   • 有效等价类就是题目条件（两端的极值（边界值）要判断，中间随意一个值也要判断）

   • 无效等价类先划分有效等价类相反的情况，在找到特殊情况（中文，英文，特殊符号，空格，空字符）

3. 编写测试用例：对于所有的无效等价类，测试用例要尽量全覆盖；一条测试用例尽可能的覆盖所有有效等价类。

等价类试用范围

适用于单个输入的功能