1、测试基础理论
1.1测试流程：
1.2测试角色
项目经理：leader
产品：规划产品具体怎么做。
开发（后端开发、前端开发） ：根据产品的规划依据代码来实现它。
测试：根据产品的需求文档以及开发转测的产品，来验证产品是否满足用户的需求。
设计：主要考虑的是页面的UI页面和交互。
1.3软件测试的定义
经典定义：在规定条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
1.3.1在规定条件下对程序进行操作
（1）有时间限制；
（2）需求边界（每一个版本的需求是有边界的，不能一蹴而就）；
（3）必须参考的文档是需求设计文档。
1.3.2以发现程序错误
1、功能性的维度：验证程序是否符合产品经理设计的需求文档，功能是否实现；
2、非功能性的维度：
（1）验证程序员编写的代码逻辑；
（2）如果是web产品，需要考虑主流浏览器(Chrome&Firefox&IE)的兼容性测试；
（3）如果是APP产品，需要考虑主流移动平台(IOS&Android)兼容性测试。
1.3.3衡量软件质量（测试完成标准）
（1）新功能测试通过；
（2）系统已有功能测试通过；
（3）所有BUG已解决；
1.3.4并对其是否能满足设计要求进行评估的过程
（1）逻辑，UI设计，页面，页面交互都符合最初的设计。
1.4测试尽早参与研发流程的优势
一般软件测试的原则是期望测试能够尽早的介入到整体研发流程，尽早的进入可以带来这么几个优势，具体如下：
（1）今早的熟悉产品的需求以及产品PRD的设计文档以及产品逻辑；
（2）从敏捷角度而言，文档准确性以及文档的可用性也是需要测试被验证的之一（一般测试很少这样做）；
（3）协助产品，站在用户的角度以及测试的角度来思考产品设计逻辑的合理性；
（4)尽早地介入可以更多的理清程序的逻辑；
（5)在具体到产品进行PRD评审的时候，能够尽快的进入到具体的逻辑和思考中，而不至于说之前不理解，可能一直游离在思考的阶段。
1.5软件测试目的
软件测试的目的是发现问题，发现至今未发现的问题，检查系统是否满足需求。软件测试的目的具体为：测试程序执行的过程，目的在于发现错误；一个好的测试用例在于能发现至今未发现的问
题；一个成功的测试是发现了至今未发现的错误测试。
在企业内部就是包含：UI的⻚⾯展示，程序内部的逻辑交互，页面提示信息，UI的页面布局展示，和色调等。
1.5.1 发现错误
（1）程序的具体逻辑；
（2）页面的交互验证；
（3）浏览器的兼容性验证；
（4）易用性的验证。
1.1.6测试的工作内容
（1）要求参与公司产品体系的所有流程和工作；
（2）参与到开发技术方案的评审和开发代码的评审；
（3）测试工作：编写测试用例，评审测试用例，测试具体的程序；
（4）上线后的产品质量监控。
1.7软件测试的10大原则
1.7.1测试应基于用户需求
被测试的产品是服务于用户的，是给用户赋能的。产品会收集用户的需求，需求评审后，大家就会达成一致的目标。
1.7.2做好软件测试计划是做好软件测试工作的关键
测试计划会明确规范每个时间点的工作内容和工作进度，以及工作安排、工作完成度。测试计划应包括：所测软件的功能，输⼊和输出，测试内容，各项测试的进度安排。
1.7.3应尽早的开始软件测试并不断地进行软件测试
（1）从产品经理发出需求开始，测试工作都已经进行了开展：树立需求点，梳理逻辑。
（2）产品上线后，需要持续跟踪产品的运行情况，如有设计不合理的，需要记录，到下个版本加入到需求里面。
1.7.4测试前必须明确定义好产品的质量标准
（1）会有质量标准，达到标准就可以上线，达不到就是不能。
（2)在设计测试用例的时候，要考虑到产品各个维度。
1.7.5避免测试自己的软件
场景：线上出现问题，程序员修改完成后，程序员自己进行了测试，同时反馈测试结果是ok的，那么测试还需要测试吗？需要的，因为程序员测试的不代表考虑到了所有的测试场景，必须需要测
试这边验证。程序员转测之后，测试一定要先进行冒烟测试。
1.7.6应充分注意测试中的集群现象
（1）尽可能地覆盖以及考虑到更多的场景，但是无法做到100%覆盖。
（2）测试需要持续不断的进行。
1.7.7必须检查每个实际输出结果
1.7.8穷举测试是不可能的
解决办法：由于时间和资源是有限的，所以优先考虑优先级高的业务场景来进行测试，优先级低的，可以在上线后，再进行测试。
1.7.9测试设计决定了测试的有效性和效率
（1）编写测试方案：测试的思路。
1.7.10注意保留测试设计和说明文档，并注意测试设计的可重用性
2、软件测试分类
2.1按阶段分类
2.1.1单元测试（unittest)
（1）定义：是针对程序最小离度的测试，他主要是应用于白盒测试。程序是由代码写的，代码里面的最小单位是方法或者函数，所以单元测试是针对方法或者函数的最小离度的测试。
（2）测试方法：白盒测试，根据不同编程语言有对应的测试框架，如Java里面的Junit和TestNG框架，Python里面的 UnitTest和Pytest测试框架。（主流编程语言：C,Python,Java,Go,Net）。
（3）测试内容：主要是程序内部逻辑、路径分支测试、局部数据结构测试等，单元测试测试参与的较少。
TDD（测试驱动开发）开发模式【Test-Driven Development】：先写测试的单元测试代码，后写程序代码。
2.1.2集成测试
（1）定义：是把单个模块的程序集成到一起后测试，集成测试主要来验证各个模块集成后模块与模块之间的功能性，以及各个模块集成后的功能流程性和逻辑兼容性的测试，集成测试主要应用
的技术是接口测试的技术。服务都是通过对外提供API（接口）进行交互的。
（2）现代版的集成测试包含两类：
A.现代企业都是前后端分离的模式，前后端各自完成工作后，需要联调来验证产品的完整性，即前端与后端之间进行联调。
B.后端与后端之间的联调。
C.公司程序员与第三方程序员之间的联调。
（3）测试方法：黑盒测试与白盒测试相结合，灰盒测试。
（4）测试对象：模块间的接口。
2.1.3系统测试
（1）定义：将软件看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段来验证被测程序的整体性的功能。
（2）系统测试
A.系统测试现在又称为端到端（end to end)的测试。
B.可以理解为产品的业务链，从开始至结束所有流程的验证测试 。
C.测试内容:功能、界面、可靠性（服务持续运行是否出现瘫痪）、易用性、性能、兼容性、安全性等。
（3）测试方法：黑盒测试，功能自动化测试。
（4）测试对象：整个系统（软件以及涉及到的硬件）。
（5）测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等。
2.1.4验收测试
（1）定义：验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。
（2）验收测试
A.自研公司：测试完成后，由测试发起——发邮件给产品经理，请产品经理来进行验收测试，产品经理验收测试通过后，发送邮件反馈测试——验收测试已通过，然后测试就可以开始产品上线 。
B.外包：外包验收是甲方（客户）来进行验收，要求客户参与。
2.2按查看代码分类
2.2.1黑盒测试
就是把被测试的程序看成一个黑色的盒子，看不到里面内部的结构，对应的是系统测试，是功能测试的一种形式。黑盒测试用到的测试用例的设计方法为：等价分类、因果图、错误推测法、边界
值。
2.2.2白盒测试
被测程序看成一个白色的盒子，能够看见程序内部的结构，对应的是单元测试。针对程序判断逻辑，判断分支，判断循环，程序流程走向的测试。白盒测试是一种高技能的测试。对测试的技术水
平要求是比较高的。
2.2.3灰盒测试
介于白盒测试和黑盒测试之间，它对测试的要求是：能够参与开发代码的评审，以及开发代码的检查，互联网公司基本都是灰盒测试。
2.3按编写代码分类
2.3.1手工测试
就是由人去一个一个的输入测试用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。手工测试又叫功能测试，或者说是业务测试。它的特点主要为: 优点:自动化测试是
无法替代人的测试的行为模式的，也无法替代探索性的测试。 缺点:执行效率慢，影响测试交付的效率。
2.3.2自动化测试
就是通过编写代码(使用工具)的方式来替代模拟人的一种行为方式来对系统进行的一种测试。自动化测试又分为UI自动化测试、API自动化测试、性能自动化测试。一般性说的自动化测试大多数时
候指的是UI自动化测试和API自动化测试。
3、软件的质量
3.1软件质量六大特性
描述当前软件是否好用，在当前的软件行业里我们所采用的一套标准是基于ISO组织制定的。需要我们记忆的就是软件质量的六大特性：
（1）功能性：软件需要满足用户显式或者稳式的功能。
（2）易用性：软件易于学习和上手使用。
（3）可靠性：指的就是软件必须实现需求当中指明的具体功能。
（4）效率性：类似于软件的性能。
（5）可维护性：要求软件具有将某个功能修复之后继续使用的能⼒。
（6）可移植性：当前软件可以从⼀个平台移植到另⼀个平台上去使用的能⼒。
三大主流平台：windows、unix、linux
测试开发四大主流领域
1、服务端测试开发
2、算法测试开发
（1）队列 ：先进先出
（2）堆栈 ：先进后出
3、大数据测试开发
4、移动专项测试开发
数据类型
1、int：整形数字
2、str：字符串
3、float：带小数点的数字
4、bool：布尔，判断语句，true/flase
5、表达式：<、=、 >、 &&（并且）、||（或者）、++（现有基础上加1）、 -- （现有的基础上减去1）
4、测试概述
4.1软件分类
中间件
（1）缓存中间件：Redis、MemCached
（2）MQ中间件：Kafka、 RabbitMQ
windows常用命令
1、ipconfig:查询IP的地址。
2、cmd:win+R，输入cmd，就可以打开控制台。
3、dir:展示当前目录下的文件和文件夹。
4、cd d:/ :进入到了D盘 。输入步骤为：
（1）cd d:/
（2）d: cd 文件名XX（进入d盘的XX文件中）
5、pwd:查询当前的在那个盘下。
4.2测试术语
4.2.1冒烟测试
1、目的：确认软件基本功能正常。
2、使用场景：开发转测后，测试要进行冒烟测试 ，验证被转测的软件基本流程是否正常。
4.2.2探索性测试
1、定义：可以说是一种测试思维技术，探索性强调测试人员的主观能动性。抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
2、使用场景：测试报告已经完成，要准备上线前，对产品进行探索性的测试。
4.2.3安全测试
目前安全测试更多的聚焦于渗透测试这部分。
4.2.4回归测试
1、定义：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
2、自动回归测试：自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
3、回归测试的三个场景
（1）转测后即测试阶段，对系统已有功能进行回归测试。
（2）上线前即系统测试，开发对代码进行了合并，需要对系统整体的进行回归测试。
（3）上线后即线上环境，对产品进行整体的回归测试。
4.3如何做软件测试需求分析
4.3.1为什么要需求分析
（1）软件测试需求是设计测试用例的依据。
（2）有助于保证测试的质量和进度。
（3）软件测试需求是衡量测试覆盖率的重要指标。
4.3.2分析需求测试要做什么
（1）梳理业务逻辑，了解本次迭代的要做什么？
（2）本次迭代功能是否影响之前的功能？
（3）提出疑问点？
4.3.3软件测试需求分析步骤
可以用思维导图来梳理需求文档。
（1）列出需求文档中的具有可测性的原始需求。
（2）对每一条需求进行细化分解，形成可测试的分层描述的测试点。
（3）对形成的每一个测试点，从软件产品的质量需求来分析，确定测试执行时需要实施的测试类型。
（4）建立测试需求跟踪矩阵，对测试需求进行管理。
4.3.4需求分析主要目的
获取测试点，根据测试点来编写测试用例。
4.3.5测试点的分析
（1）输入输出：通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）；
（2）逻辑处理：各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试）；
（3）业务场景：考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，⽐如界⾯的验证，异常情况（界⾯、易⽤性、兼容性、安全性、性能）。
4.3.6测试需求理解偏差相关方影响
解决方案：
1、逻辑不清晰，找开发同学多讨论；
2、开发与测试意见不一致的情况下，找产品经理；
3、产品的逻辑不合理，找产品经理，同时找开发同学，统一意见。
