软件测试定义：
通过手工或者工具对“被测对象”进行测试操作，从而验证实际结果与预期结果之间是否存在差异。
软件测试的作用：
1，通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。
2，测试可以记录软件运行过程中产生的一些数据，从而为决策提供数据支持。
3，测试可以降低同类型产品开发遇到问题的风险。
测试原则：
所谓的测试原则指的就是我们在执行测试工作时必须要遵守的一些规则。
1，测试证明软件存在缺陷：无论执行什么样的测试操作都能证明当前软件是有缺陷的。
2，不能执行穷尽测试：有些功能是没有办法将所有的测试情况都逻辑出来，所以任何的测试操作都有结束的时间。
3，缺陷存在群集现象：对于软件功能说，核心功能占20%，非核心80%。在实际工作中我们会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%。因此我们就会遇到缺陷都集中在20%功能模块里的现象。
4，某些测试需要依赖特殊的环境。
5，测试应尽早介入：为了更多的发现和更好的解决软件中的缺陷。我们追求测试工作尽早的开展。
6，杀虫剂现象：同样的一个测试用例不能重的执行多次，因此软件会对它产生免疫。
7，不存在缺陷谬论：任何软件不可能是完美的。
测试对象的介绍：
对于当前的测试行业来说我们最经常测试的主题就是软件（主体功能），但是需要我们明白的是一个软件也不仅仅只有功能需要测试。我们可以将软件分为三个部分组成：功能集合+使用说明书+配置数据。
测试的阶段：
1，需求分析阶段：各种需求规格说明书。
2，软件架构设计：API接口文档（接口测试）
3，编码实现阶段：源代码（白盒测试，单元测试）
4，系统功能使用：软件功能主题（当前行业做的最多的一种测试）
测试级别
常见的测试分类：
1，单元测试（UT unit test）：在软件测试中单元指的就是组成软件最小的底层代码结构，一般就是类，函数，组成（当下的软件测试行业，不会刻意要求测试人员对源代码进行测试）。
2，集成测试（IT system ingertaion test）：将多个单元模块组合在一起，然后验证他们之间沟通的“桥梁”是否能正常工作（接口测试）
3，系统测试（ST system test）：这是当前行业做的最多的一种测试。由于测试人员充当用户然后对软件的功能主体进行测试。
4，验收测试：
（1）a测试----内侧
（2）β测试----公测
（3）UAT（user acceptance test）测试----由客户派出对于业务非常精通的人员来使用该动能，从而对功能进行测试。
（4）验收测试的核心就是让用户为当前软件“买单”
（5）
系统测试分类：
1，功能测试：验收当前的软件主体功能是否可用。
2，兼容性测试：验收当前软件在不同的环境下是否还可以使用。
3，安全测试：验证软件是否是能授权用户提供功能使用。
4，性能测试：相对于当前软件消耗的资源它的产出能力。
1.8 常见的系统测试方法
一，按测试对象进行分类
1，白盒测试：这种测试的主题就是软件的底层代码，不会在意外在的界面是否OK，只要求底层功能实现，同时逻辑正确。
2、黑盒测试：这种测试指的是被测软件外在主体功能是否可用
3，灰盒测试：介于两者之间（接口测试）
4，上述三种方法当中的“盒”指的就是被测对象。
黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联
系？
黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性， 只依据程式的需求说明书
来检查程式的功能是否满足它的功能说明。
白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及 相关信息，设计或选择测
试用例，对程式所有逻辑路径进行测试。
单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。
集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。
系统测试：在所有都考虑的情况下，对系统进行测试。
验收测试：第三方进行的确认软件满足需求的测试。
黑盒有等价类划分法，边界分析法，因果图法和错误猜测法。
白盒有逻辑覆盖法，循环测试路径选择，基本路径测试。
黑盒 白盒 灰盒区别：
黑盒是模拟用户操作，点点看看；
白盒是像程序员一样，对一个未成型的，可能看到代码的产品进行输入输出测试；
灰盒是对介于二者之间的过程测试。
黑盒测试关注程序的功能是否正确，面向实际用户；
白盒测试关注程序源代码的内部逻辑结构是否正确，面向编程人员；
灰盒测试是介于白盒测试与黑盒测试之间的一种测试。
所以通俗来讲黑盒测试就是看我开始用一个软件，它可以满足我的需求不出错吗？
白盒测试就是我写的程序代码是不是没有问题呢，我得在源程序中看看。
灰盒测试就是综合两种测试策略。
简述黑盒测试和白盒测试的优缺点？
黑盒测试的优点有：黑盒测试关注程序的功能是否正确,面向实际用
1.比较简单，不需要了解程序内部的代码及实现；
2.与软件的内部实现无关；
3.从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
4.基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
5.在做软件自动化测试时较为方便。
黑盒测试的缺点有：
1.不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的 30%；
2.自动化测试的复用性较低。
白盒测试的优点有：白盒测试关注程序源代码的内部逻辑结构是否正确,面向编程人员
灰盒测试是介于白盒测试与黑盒测试之间的一种测试。
所以通俗来讲黑盒测试就是看我开始用一个软件，它可以满足我的需求不出错吗？
白盒测试就是我写的程序代码是不是没有问题呢，我得在源程序中看看。
灰盒测试就是综合两种测试策略。
比较简单，不需要了解程序内部的代码及实现；
与软件的内部实现无关；
从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
在做软件自动化测试时较为方便。
软件质量特性：
描述当前软件是否好用，在当前的软件行业里我们所采用的一套标准是基于ISO组织制定的。需要我们记忆的就是软件质量的六大特征：
1，功能性：软件需要满足用户显示或者稳式的功能。
2，易用性：软件易于学习和上手使用。
3，可靠性：指的就是软件必须实现需求当中指明的具体功能。
4，效率型：类似于软件的性能。
5，可维护性：需求软件具有将某个功能修复之后继续使用的功能。
6，可移植性：当前软件可以从一个平台移植到另一个平台上去使用的能力。（功能靠用，效率可“以”）
软件测试的流程：
从产品接到需求开立项会，确立需求文档，测试进行编写测试计划，根据需求文档进行编写测试用例，开发进行编码，等编码结束会对主要功能进行冒烟测试，测试执行测试用例，
如果发现bug进行提交bug，开发进行修改，当开发修改后对bug进行在次的回归测试（1.bug是否已经解决，2.解决后的bug是否对正常功能的影响）如果bug修改完成测试将bug的状态改为关闭，如果bug没有修改或者是修改后对其他的功能进行影响则bug重新打开并在次提交
需求分析：
1，当前阶段的核心目的就是梳理清楚我们需要设计的点是什么
2，需求的来源：需求规格说明书，API文档，竞品分析，个人经验
如果公司内部没有需求文档或者是API文档你怎么做测试：
1.根据公司的产品进行对同行业或是同类软件进行分析，找到相关文档。
2.根据跟人经验对软件进行测试
3.先做到UI页面和业务逻辑是否匹配 在进行功能模块的实现能否正常 然后在整个软件进行系统分析并实现，然后开展性能测试或者是接口测试
4.没有api文档的时候 进行接口测试 可以通过抓包工具（charles /fiddler）来获取接口相关信息（url 请求方式 参数 响应结果等）进行对单个接口测试或者是通过接口录制（bodboy 对web端进行录制 jmeter对移动端的录制） 实现多接口或者一个业务场景进行接口测试
5.进行性能测试或者是自动化测试
测试计划：
测试背景 测试目的 测试需求（软件 硬件 人员） 测试用例的设计以及评审
执行进度 bug跟踪 风险评估
如何做测试用例的评审？
1.是否覆盖测试需求上的所有功能点，不违背产品原型和代码设计，用例设计的结构安排是否清晰合理，有利于高效覆盖需求
2.用例是否具有可执行性，前提条件、执行步骤和预期结果是否正确，有明确的验证方法。优先级安排是否合理
3.是否从用户层面来设计用户使用的场景和业务流程
4.是否包含充分的异常测试用例
5.是否简洁，不冗余，复用性强
******
如何设计测试用例
用例的设计点：
1功能上
2.UI页面
3.性能
4.安全
5.弱网
6.易用性
1，用例就是用户为了测试软件的某个功能而执行的操作过程
2，设计用例是有方法的（等价类，边界值，判定表......）
评审用例
对当前的用例进行添加或者删除
配置环境
1，环境：指的就是当前被测对象运行所需要的执行环境，作为测试人员需要具备配环境的能力。（一般情况下都会使用一键安装的集成环境）
2，环境分类：操作系统+服务器软件+数据库+软件底层代码的执行环境
执行用例
1，一般在执行用例之前我们会做一个冒烟测试。这种测试的核心就是快速的对当前软件的核心功能或者主体执行流程进行验证。如果冒烟测试阶段有问题，则可以将此版本回退给开发
2，如果冒烟测试通过那么才会开展示全面的测试
回归测试及缺陷跟踪
1，回归测试指的就是当我们将某个缺陷提交给开发之后，由他们进行修复，修复完成之后需要测试人员再次对其进行测试（回归测试）
2，缺陷跟踪：指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪
输出测试报告
将当前的测试过程中产生的数据进行可视化的输出，方便其他人去查看
测试结果
当将整个测试过程中产生的一些文档进行整理归档，方便后续版本使用
在测试过程中 如果开发人员说改bug不是bug的你怎么办?
在多次测试以及不同的测试环境中测试后将bug的复现步骤进行总结并提交开发人员让开来确认
可以找项目经理或者产品经理根据根据规格说明书来进行对bug进行确认是否为bug
测试人员可以将bug的内容和步骤以及相关内容（1，执行的测试用例）保存进行到测试总结中，留意在后期出问题进行文件提供。
软件架构
所谓的软件架构我们可以理解为是用来指导我们软件开发的一种思维，目前来说最常见的两种架构模式就是b/s c/s
b---browser 浏览器
C----clent 客户端
S----server 服务端
两种架构的比较
1，标准：相对于cs架构来说bs架构的两端都是在使用现成的成熟产品。所以bs会显示的标准一些。
2，效率：相对bs架构来说cs中的客户端可以分担一些数据的处理，因此执行效率会高一些
3，安全：bs架构当中得到数据传输都是以HTTP协议进行的输出，而HTTP协议又是明文输出。可以被抓包，所以相对于cs架构来说bs就显得不那么安全（相对的）
4，升级：bs架构只需要在服务器端将数据进地更新，前台只需要刷新页面就可以完成升级，而cs架构当中必须要将两端都进行更新
5，开发成本：相对于bs架构来说cs当中的客户端需要自己开发，所以相对于来说成本会高一些
浏览器基本介绍
浏览器是什么
浏览器本身就是一款软件，安装在操作系统之上。一般给用户提供浏览网页的服务。目前来说我们会认为的将所有浏览器总结出一个所谓的五大生产厂商。（对于浏览器来说最核心的技术就是内核）
五大浏览器生产厂商
1，IE（微软）---- trident
2，Chrome（谷歌）---- blink
3，Firefox（火狐）---- gecko
4，Safari（苹果）---- webkit
5，Opera（欧朋）---- presto（现在已经放弃自己的东西完全向Chrome）
图片类型
1，JPG（JPEG）：这是一种可以高度保留图片色彩信息的格式
2，PNG：该类型的图片可以实现透明
3，GIF：图片所占体积小，可以实现动图
4，PSD：它是一种分层的图片
测试用例 定义：
要素： 用例编号 所属模块 前提条件 测试输入 预期结果 实际结果
备注 版本 测试人 测试日期
测试方法：
等价类划分 因果图 边界值 正交法 错误推断法 场景法
面试题：
在项目中的哪些场景中运用了测试方法
测试用例的评审：
评审内容
评审的内容有以下几个方面
1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2)优先极安排是否合理。
3)是否覆盖测试需求上的所有功能点。
4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。
5)是否已经删除了冗余的用例。
6)是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。
7)是否从用户层面来设计用户使用场景和使用流程的测试用例。
8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤
分为组内和组外评审：
组内评审的人员： 测试Leader 和 测试人员
组内评审着重与 1. 用例的冗余性
2.用例的准确性
3.用例的覆盖度 70%-80%
4.用例满足需求
组外评审： 测试leader 测试人员 项目经理 产品经理
组外评审： 1.是否满足软件的需求
2.用例覆盖率
3.用例的执行性
4.用例的复用性
5.用例是否具有正反的用例
6.编写用例的模板
7.非功能性测试用例的编写
8.缺陷率在执行的测试用例中的占比
测试计划：
开发团体人员： 5：1
10人开发团队 1 UI 5个后台开发 2个移动端 1个测试/运维 1产品
项目开发周期： 6个月
版本迭代： 大版本 1个半月 小版本 1周
测试分工： 功能界面 性能+接口 自动化