软件：selenium、appium、postman、jmeter、fiddler
一、为什么软件测试：
1、一款软件从无到有会经历很多的开发阶段由不同的人来参与开发，最终产出的软件功能可能会出现很多的问题，因从为了保证软件功能是可用的，我们必须要进行测试。
2、当前的软件行业已经不在是功能为王了，用户不仅仅只盯着软件的功能历来满足需求，还会对软件是否容易上手，执行的效率是否可以，等一系列其他体验有了更高的要求，所以我们要有大量的测试。
二、为什么选择软件测试
1、当前国内的软件行业对于专业的软件测试人员需求是慢慢的变大。
2、有的人喜欢创造世界，做了开发，而我i们就是希望这个世界变得更加的美好 所以做了测试
三、为什么不让开发自己做测试
1、当前的行业有许多的测试从业人员本身之前就是开发岗。
2、专业度：软件测试、软件开发分别属于软件行业当中二个不同的技术方向，所以让人做专事对于质量更加有的保证。
3、思维定式：在软件的开发周期中，对于程序员来说，大多数的时间都是来思考实现具体的软件功能。而不会从用户的角度去考虑如何去“奇葩”的使用这些功能。
4：测试力度：相当于开发来说，产品就相当于是他们的“孩子”。所以“下手”不会太狠。
四、软件测试定义
1、通过手工或者工具对被测试对象进行测试操作，从而验证实际结果于预期结果之间是否存在差异。
五、软件测试的作用
1、通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的信心。
2、测试可以记录软件运行过程中产生的一些数据，从而为决策提供数据的支持。
3、测试可以降低同类品产品的开发遇到的风险。
六、测试原则
所谓的测试原则就是我们在执行测试工作时必须要遵守的一些原则。
1、测试证明软件存在的缺陷:无论执行什么样的测试操作都只能证明当前软件是有缺陷的。
2、不能执行穷尽测试：有些功能是没有办法将所有的测试情况都罗列出来，任何的测试操作都有结束时间。
3、缺陷存在群集现象：对于软件的核心功能占20%，非核心是80%（2、8理论）。在实际工作中我们会集中测试核心的功能，所以这个发现缺陷就是高于非核心功能，所以我们遇到的缺陷都集中在核心功能的模块里。
4、某些测试需要依赖特殊的环境
5、测试应尽早介入：为了更多的发现和解决软件中的缺陷，我们追求测试工作尽早介入。
6、杀虫剂现象： 同样的一个测试用列不能重复执行多次，因为软件会对它产生免疫。
7、不存在缺陷谬论：任何软件不可能是完美的。
七、测试对象
对于当前的测试行业来说最经常测试的主体就是软件（主题功能），但是需要我们明白的是一个软件不仅仅是只有功能需要测试 。我们可以将软件分为三个部分组成：功能集合+使用说明书 + 配置数据。
对于一款软件来说无从到有需要不同的过程，我们可以将这个过程分为不同的阶段，然后每个阶段都会有相应的测试对象。
1、需求分析阶段：各种需求规格说明书。
2、软件架构设置：API接口文档（接口测试）
3、编码实现阶段：源代码（白盒测试，单元测试）
4、系统功能使用：软件功能主体（当前行业做的最多的测试）
软件的开发都会依据相应的开发模型。而测试级别就是在模型当中我们认为定义的开发步骤，其中对于测试来说我们常见的一种级别分类如下：
1、单元测试：[UT unit test] 在软件测试中单元就是组成软件最小的底层代码结构，一般就是类、函数、组件（对于当下的软件测试行业不会刻意要求测试人员对源代码进行测试）。
2、集成测试：（接口测试）将多个单元模块组合在一块，然后验证他们之间沟通的桥梁是否能正常工作。
3、系统测试：当前行业做的最多的一种测试，由测试人员充当用户然后对软件的功能主体进行测试。
4、验收测试：为了让用户为其进行买单 α测试—内测，β测试——公测 ，UAT测试—由第三方客户对于非常精通的人员使用该软件，从而对功能进行测试。
1、功能测试：验证当前的软件主体功能是否可用
2、兼容性测试：验证当前软件在不同的环境下是否可以使用。
3、安全测试：验证软件是否只是能授权用户提供功能使用。
4、性能测试：相对于当前软件消耗的资源它的产出能力。
1、测试对象进行分类：白，黑，灰盒子测试
盒就是被测对象，白盒子的主体就是软件的底层代码。不会在意外在的界面是否ok，只要底层功能实现，同时逻辑正确。
黑盒子就是指测试软件的外在主体功能是否可用。
灰盒子是介于二者之间。（接口测试）
2、测试对象是否执行分类：静态：测试不执行
动态：将软件运行在真实的使用环境中进行测试。
3、测试手段：手工：由测试人员手工对被测对象进行验证，优点就是灵活的改变测试操作及环境。
自动化测试：所谓自动化有两种，一种是自己写测试脚本，另外一种就是通过第三方的工具对被测对象进行测试。优点是高效率的去执行有一些人工无法实现的操作。
描述当前软件是否好用，在当前的软件行业里我们所采用的一套标准是基于ISO组织制定的，需要我们记忆的就是软件质量的六大特性：
1、功能性：需要满足用户显示或者隐式的功能。
2、易用性：软件易于学习和上手使用。
3、可靠性：软件必须实现需求当中指明的具体功能。
4、效率性：类似于软件的性能。
5、可维护性：要求软件具有将某个功能修复之后继续使用的功能。
6、可移植性：当前软件可以从一个平台移植到另一个平台上使用的能力。
[功能靠用，效率可‘以’]
1、需求分析：当前阶段的核心目的就是梳理清楚我们需要设计的点就是什么。 需求的来源 ：需求规格说明书、API文档 、竞品文档，个人经验。
2、设计用例：用户为了测试软件的某个功能而执行的操作过程。设计用例是有方法的（等价类，边界值，判定表）
3、评审用例：对当前的用例进行添加或者删除。
4、配置环境：环境就是被测对象运行所需要的执行环境。作为测试人员需要具备配环境的能力。【一键安装的集成环境】 环境分类：操作系统 +服务器软件+数据库+软件底层代码的执行环境。
5、执行用例 ：一般在执行用例之前我们会做一个冒烟测试。核心就是快速的对当前软件的核心功能或者主体执行流程进行验证，如果冒烟测试阶段有问题，则可以将此版本退给开发。 如果冒烟测试通过那么才会开展全面的测试。
6、回归测试及缺陷跟踪：我们将某个缺陷提交开发之后，由他们进行修复，修复完成之后需要测试人员再次进行测试。
7、输出测试报告：将当前的测试过程中产生的数据进行可视化的输出，方便其他人查看。
8、测试结束：将整个测试过程中产生的一些文档进行整理归档，方便后续版本使用。
十三、软件架构
所谓的软件架构我们可以理解为是用来指导我们软件开发的一种思想，目前来说最常见的两种架构模式就是 B/S、C/S
B --browser 浏览器
C -- clent 客户端
S --server 服务端
两种架构模式的比较：
标准：相对于c/s来说，b/s架构的二端都是在使用线程对的成熟产品，所以bs会显示的标准一些
效率：相对于bs架构来说，cs中的客户端可以分担一些数据的处理，因此执行效率会高一些。
安全：BS架构当中的数据传输都是以HTTP协议进行的输出，而HTTP协议又是明文输出，可以抓包，所以相对于cs架构来说bs就显得不那么安全。
升级：bs架构只需要在服务器端将数据进行更新，前台之需要刷新页面就可以完成升级，而cs架构当中必须要将二端都进行更新。
开发成本：相对于bs架构来说cs当中的客户端需要自己开发，所以相对于来说成本会高一些。
十三、浏览器
浏览器就是一款软件安装在操作系统上，一般给用户提供浏览网页的服务，五大厂商。对于浏览器来说最核心技术就是内核。
IE(微软)：--trident
chrome（谷歌）--blink
firefox（火狐）--gecko
safari（苹果）--webkit
opera（欧朋）--presto [放弃自己的东西向谷歌看齐]
**********************************************************
开发模型：
瀑布模型 优点:开发阶段，各个阶段都比较的清晰，强调了早期计划及需求调查；适合稳定雪球的产品开发
改良：每个阶段都可以融入小的迭代工作。
快速原型：克服了瀑布模型的缺点，更好的满足用户的需求并减少由于软件需求不明确带来的项目开发风险。
缺点：不适合大型系统的开发，适合开发小的，灵活性高的系统。
实现一个基本的原型，让用户对原型进行评价，逐步的调整，使其满足用户最终的需求。
螺旋模型：开发过程中分为螺旋几周期的模型，于瀑布模型相符合。会进行风险评估。很少会用到螺旋模型。
有相当的专业经验才会从螺旋模型。
*****
测试模型：V、W、H模型。
V模型：需求分析-概要分析-详细设计-编码-单元测试-集成-系统-验收
单元测试：又称为模块测试，针对软件设计中的最小单位-程序模块，进行正确检查到的测试工作。
集成测试：组装测试，把单元测试的基础上，将所有程序模块进行有序、递增的测试，重点测试不同模块的接口部分。
系统测试：将整个软件系统看为一个整体进行测试。包括对性能、功能、兼容性以及软件所运行的软硬件环境进行测试。前期看功能，中期看性能，后期看兼容性。
验收测试：α测试：内部人员先测试，bug多，用户不要安装，主要是测试人员在开发环境下的测试。
β测试：公测。面向用户，通过反馈再去修改小细节，是在实际环境中的测试或者公司人员内部在模拟真实环境的测试。
γ：gamma于正式软件相差无几。
V模型优点：包含了底层模式（单元测试）和高层模式（系统测试）。清楚的标识了开发和测试的各个阶段。每个阶段分工明确，便于整个项目的把控。
缺点：自上而下的顺序，测试工作在编码之后，导致了错误不能及时纠正。实际工作中，需求经常改变，导致V模型步骤反复执行，返工量大，灵活度降低。
改良：每个步骤都可以进行小的迭代工作。
W模型优点：伴随着整个开发周期，需求和设计同样要测；更早的介入测试，可以发现初期的缺陷，修复的成本低，分阶段工作，方便项目的整体的管理。
缺点：开发和测试依然是线型的的关系，需求的变更和调整，依然不方便，如果没有文档，根本无法执行W模型，对于项目组成员的技术要求更高。
定义：开发一个V，测试一个V组合起来的模型。
总结：V模型适用于中小企业，W模型适用于中大型企业（人员要求高）,H模型人员要求非常高，很少有人用。
软件测试分类：
白盒测试：把程序打开研究里面的程序结构和源代码
黑盒测试：又称数据驱动测试，完全不考虑从内部机构和特性，注重软件的功能要求（不管代码）
灰盒测试：介于白和黑之间。
静态测试：指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误过程。
动态测试：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
随机测试：是指被测软件的一些重要的功能，进行复测，也包括测试那些当前的测试用例没有覆盖到的部分。也就是说针对重要功能、新增功能、特殊情况、以前发现过重大bug的模块进行二次的测试。
测试用例：测什么？怎么测？
等价类划分法
属于黑盒测试，它将不能穷举的测试过程进行分类，从而保证完整性和代表性。
1、 确定有效等价类和无效等价类。
2、 有效等价类划分（题目条件、还要注意边界值（极值），中间再随意找个值）
3、 无效等价类划分（跟有效等价类相反，其他特殊情况（中文、英文、特殊符号、空格、空））
注意：两个框要一个是正确的，一个错误，这样才能正确的判断；一定要根据需求来判断预期结果
等价类细节：
1、 考虑输入长度
2、 考虑输入类型
3、 组成规则
4、 是否为空
5、 是否区分大小写
6、 是否重复
7、 是否去除空格
边界值：
我们在测试过程中，一定要小心边界值（极值），因为在程序中这些边界最容易出问题。具体测试用列书写思路；找到边界值和它的两端的值，分别进行测试
总结：边界值思想应该是选到边界和刚超过的值，来进行测试，也要根据实际情况来选择，边界值和等价类是相辅相成的关系，配合使用的。
因果图：
因：输入条件
果：输出条件、出结果
使用于输入条件之间有相互制约、相互依赖的情况。
基本符号：
恒等：若原因出现，结果出现。若原因不出现，结果不出现。
非（~）：若原因出现，结果不出现。原因不出现，结果出现。
或（V）：若几个原因中有一个出现，则结果出现。若几个原因中都不出现，则结果不出现，
与：若几个原因都出现，则结果才出现，若其中一个原因不出现，则结果不出现。
判定表：
根据因果图来制作判定表
条件桩：所有的条件组合。
动作桩：所有结果
条件项：针对条件桩的取值
动作项：针对动作桩的取值
书写步骤：
列出所有条件和动作桩
填写条件和动作桩中的项目
简化判定表
注意：如果出现“-”代表次选项不影响最终结果
场景法：
主要用来测试业务流程：分为基本流（正确流程）和备选流（错误流程）
注意：还要补充一些异常情况
在冒烟测试中主要采用场景法来测试。