测试基本概念
测试是什么
软件测试是评估软件质量和降低软件运行中出现失效风险的一种方法。整个测试活动过程中应用到的方法都是在帮助我们更好更快速的去完成质量的评估与风险的预防。
为什么进行测试（测试目标）
测试活动的目标并非一成不变，测试目标需要结合实际情况做出对应变化，测试目标的确认，是测试活动的关键，将直接决定测试活动的成败，以下列举常见目标，至于如何确定目标不在此处讨论，后续单独展开。
通过评估工作产品以防止缺陷，例如需求、用户故事、设计和代码
验证是否实现了所有指定的需求
检查测试对象是否完成，并确认是否按照用户和其他利益相关方期望那样工作
建立对被测对象质量级别的信心
发现缺陷和失效，从而降低软件质量不足的风险
为利益相关方提供足够的信息以允许他们做出明智的决策，特别是关于测试对象的质量级别
遵守合同、法律或法规要求或标准，和/或验证测试对象是否符合这些要求或标准
软件为什么会有错误
了解软件为什么出错有助于我们识别一个项目的风险，当一个项目出现一下情况下均会对其质量产生较大影响
时间紧任务重，研发人员没有时间去详细考虑设计和自测
项目存在新人缺乏经验或技能不足
代码、设计、架构的复杂度过高
采用了新的不熟悉的技术
对系统内和系统间接口的误解，特别是当系统内和系统间的交互数量比较多的时候
项目参与者之间沟通有误，包括需求和设计之间的沟通误解。
测试需要保障的主要质量特性
功能性，性能效率，兼容性，易用性，可靠性，安全性，维护性，移植性
测试的主要价值
优化产品需求，解决用户痛点
测试人员参与需求评审或用户故事细化，可以发现这些工作产品中的缺陷。识别和修复需求缺陷可以减少被开发（功能）特征的不正确或不可测试的风险。
助力软件设计，降低设计缺陷
在系统设计过程中，让测试员与系统设计人员密切合作，可以提高各方对设计和如何测试的理解。理解的增加可以降低基本设计缺陷的风险，并使测试能够尽早介入。
在开发代码过程中，让测试员与开发人员密切合作，可以提高各方对代码以及如何测试的理解。理解的增加可以降低代码和测试中出现缺陷的风险。
提升发布质量，增强产品价值
测试人员在发布之前对软件进行验证和确认，可能发现之前遗漏的失效，并帮助修复导致失效的缺陷(即调试)。这样就增加了软件满足利益相关方需求的可能性
助力质量内建，推动研发效能
测试人员与研发团队紧密配合，不断的发现，并优化过程中的问题，并与项目团队共同改善，从而达到质量与效率的双重提升
测试基本原则
原则 1 测试说明缺陷的存在，而不能说明缺陷不存在
测试可以证明存在缺陷，但不能证明不存在缺陷。测试降低了软件中存在未发现缺陷的可能性，但即使没有发现缺陷，测试也无法证明其对象的正确性。
原则 2 穷尽测试是不可能的
进行穷尽测试（输入和前提条件的所有组合）是不可行的，除非是小型的案例。应利用风险分析、测试技术和优先级确定测试工作量，而不是试图进行穷尽测试。
原则 3 测试的尽早介入可以节省时间和成本
为了尽早发现缺陷，应该在软件开发生存周期中尽早启动静态和动态测试活动。测试的尽早介入有时被称为测试的左移。在软件开发生存周期的早期进行测试有助于减少或消除代价高昂的变更
原则 4 缺陷的群集效应
通常在少数模块中包含了大部分在发布前测试中发现的缺陷，或者是造成大部分运行失效的原因。预测的缺陷集群和在测试或操作中实际观察到的缺陷集群，应该作为风险分析的重要输入，并用来集中测试工作量（如原则 2 所述）。
原则 5 杀虫剂悖论
如果多次重复同样的测试，最终这些测试将不再能够发现任何新的缺陷。为了发现新的缺陷，可能需要更改现有的测试用例和测试数据，并且可能需要编写新的测试。（测试不再能有效发现缺陷，就像杀虫剂在一段时间后对杀死昆虫不再有效一样）。但是在某些情况下，杀虫剂悖论也有好处，例如在自动化回归测试中，发现的回归缺陷数量相对较少。
原则 6 测试活动依赖于测试周境
测试在不同周境下是不同的。比如，安全关键工业控制软件的测试不同于电子商务移动应用。另一个例子，在敏捷项目中进行的测试不同于在顺序软件开发生存周期项目中进行的测试
原则 7 不存在缺陷的谬论
有些组织期望测试员能够运行所有可能的测试并发现所有可能的缺陷，但是原则 2 和原则 1 分别告诉了我们这是不可能的。另外，期望仅仅发现并修复大量缺陷就能确保系统的成功，这是一个谬论（即错误的信念）。例如，穷尽测试所有指定的需求并修复发现的所有缺陷，仍然可能会生产出一个难以使用，或无法满足用户需求和期望，或与其他竞争产品相比更差的系统。
测试人员需要具备的思维
用户思维
以终为始，站在用户的角度思考才能开发出成就用户的产品，成就了用户，产品才能获得成功。
批判思维
批判思维是指一种合理性的反思思维，它借助观察，经验，推理，沟通，等收集信息，并对信息进行抽象与总结，以此决定相信什么和做什么，从批判思维来看软件测试就是借助观察，经验，沟通等方法收集信息，并对软件产品的质量进行分析，以此评估软件的质量，可以说软件测试就是测试人员不断质疑被测系统的过程。
逻辑思维
逻辑思维是建立在因果关系之上的反映客观现实的思维方式。在表达上的体现就是，说话有理有据，条理清晰。
逆向思维
测试设计过程中，测试将可以根据结果逆推条件，从而得出输入条件的等价类划分。
缺陷分析过程中，进一步定位问题的所在，往往就是逆流而上，分析代码的实现方式，分析上层流程是否存在问题。
极端思维
极端思维是为了保障我们所测试的软件再极端的输入条件下可以稳定正常的运行，再测试过程中的边界值测试，压力测试都是典型的极端思维的一种应用。
组合思维
组合思维是为了保障我们所测试的软件在较为复杂的输入组合条件下可以正常运行，是指把多项貌似不相关的事物通过想像加以连接,例如软件在一个人用的时候可以正常使用，那么就要考虑在多个人同时操作是否会出现问题。
简单思维
剥离一些非关键特征，追逐事物的本质，让事物简单的只剩下“根本”， 针对事物本质（解决问题的本质）的测试，让我们不至于偏离方向，且可能更加省力
全局思维
我想说的全局思维不是无所不知，更不是全栈，而是我们对于知识或者业务脉络体系化的梳理
例如对一个系统进行测试，那么首先要对系统的整体业务脉络做一个梳理，待你整体梳理完成后那么你对系统的的感觉将完全不同，这时会对业务和功能调整有更强的把控能力，例如对于系统整体实现架构的梳理我们会发现跟多的测试可能性，找到更多的测试方法
在梳理全局的过程中，不要一上来沉浸在某个的细节，这样会减缓你的梳理步伐，最后迷失在细节的了解中，当你了解全局后再去根据实际情况判断哪里需要进行详细的了解
比较思维
认识事物时，人们往往都是通过和头脑中的某些概念进行比较，找出相同、相异之处，或者归类，从而将其加入大脑中的知识体系，可能的话，再建立好的搜索方式，以便以后使用，应用模式是“比较思维”很常见的例子，现在模式很火，有设计模式、体系结构模式、测试模式、等等，一些专家针对一些相关问题的共性找出来的解决方法，取完名字后，可以让大家方便的复用， 让经验在这里发挥作用，测试中经验很重要，比较思维是使用经验的方式。
工程师思维
某件重复发生的事情只干一次就好，以后也不需要再重复做。
从浅层的意义来说，就是要实现业务的自动化。如每版机械回归的内容是否可以用自动化的方式进行覆盖
更深层的逻辑是如何把问题彻底解决掉，而不只是以自动化的方式去解决问题，比如项目如何解决测试覆盖度低的问题，显然通过简单的自动化无法解决，这要我们对问题本身有更深的思考与分析。
迭代思维
对于当前自己的工作内容进行反思，自我批判，在不断审视自己中不断的提升，这里想说的迭代包含对于我们已有技能的迭代，也包含这自身知识体系的迭代。
已有技能的迭代要做的是纵向的深入，对已掌握技能的不断打磨，不断精进，比如我们看上一版自己写的方案，写的用例，写的自动化脚本，是否有部分可以进行优化，需要进行修改，通着不断的反思提升自己的专业深度
自身知识体系的迭代想说的是我们要不断的打破技能的边界，不断的扩充自己的认知范围，扩展自己的技能范围，比如刚入职时那我们可能只是会点点点的测试小白，那么通过不断的打破这个技能边界，我们可能会不断的掌握，功能测试，性能测试，安全测试，研发等技能
这些都需要我们一次次的跳出舒适区，完成一次次的自我迭代，自我精进。
成长性思维
不设限，乐于接受挑战，并积极地去扩展自己的能力，勇敢的应对自己不擅长
闭环思维
凡事有交代，凡事有着落，件件有回音
“闭环”的理论根据是“PDCA循环”，是由美国质量管理专家休哈特博士提出的：计划（Plan）、执行（Do）、检查（Check）、行动（Act）
1、计划阶段。要通过市场调查、用户访问等，摸清用户对产品质量的要求，确定质量政策、质量目标和质量计划等。包括现状调查、分析、确定要因、制定计划。
2、设计和执行阶段。实施上一阶段所规定的内容。根据质量标准进行产品设计、试制、试验及计划执行前的人员培训。
3、检查阶段。主要是在计划执行过程之中或执行之后，检查执行情况，看是否符合计划的预期结果效果。
4、处理阶段。主要是根据检查结果，采取相应的措施。巩固成绩，把成功的经验尽可能纳入标准，进行标准化，遗留问题则转入下一个PDCA循环去解决。
测试人员的发展路径
技术 + 管理方向：
一枚萌新→ 技术阶段→ 测试经理、主管这样的管理岗
纯技术方向 ：
一枚萌新→功能测试 →自动化/性能/安全→测试开发/性能、安全测试专家/架构师
产品方向：
一枚萌新 →业务专家 → 产品经理、产品需求等岗位。
其他方向
回家继承千亿资产
测试学习路径介绍
通用学习路径
2本书+领域专家+实操+持续提升
2本书：1本讲解基础以及理论书籍+1本实战书籍。所有的书一定要经典书籍。
理论书籍让你快速了解所学知识脉络框架，实战数据指导你可以从零上手，理论结合实践才能有事半功倍的效果。我们常常开始学习知识的时候通过论坛的方法，这种方法入门比较容易，但是很难系统，也会占据非常多的时间。为什么要经典书？读书的最大成本不是买书的钱，而是读书的时间，所以看书一定要看最经典的书，怎么找经典书？可以到豆瓣、专业论坛、当当上看看评论。每个领域有每个领域的书籍。
领域专家
成长过程中如果有领域专家的支持，就会少走不少弯路，多与自己能接触到的专家去沟通你将获得事半功倍的效果
实操
软件开发与测试都属于工程类的工作，这类工作一定要动手去实验，动手去实操才能有更深的体会，真正的掌握所学知识
持续提升
软件行业是一个需要持续学习，持续更新迭代自己的行业，要想成为领域的专家，或者是高级人员就需要不断更新学习新的知识和技术
测试的技能树
测试理论+业务知识+测试技术
测试理论
测试用例
测试执行
业务测试
自动化测试
测试流程
主流测试工具
测试结果分析
、、、、
业务知识
软件是承载业务的载体，软件的成功与否在于是否能够真正的承载起业务，解决好用户的业务需求
业务知识的理解可以采取5W1H8C1E方法去学习和理解
5W 包括 When（何时）、Where（何地）、Who（何人）、What（何事）和 Why（何因），代表需求产生的背景和功能上线后的运行环境；
H 是指 How（如何），代表业务需求的处理逻辑。
8C 为8个质量特性，包括性能、成本、时间、技术、可靠性、安全性、合规性、兼容性，代表保证质量符合要求的约束条件（Constraint）。
E 是指 effect（效果），反映了业务上线之后的效果，包括业务效果和系统效果。
测试技术
通用技术
Linux基础
关系型与非关系型数据库的应用
Web容器与中间件基础
Docker等容器化基础
编程语言（建议学习所测项目使用的语言，当然建议是Java，Python，C都能掌握）
专项技术
自动化
白盒测试
性能测试
安全测试
DevOps
敏捷测试
测试开发等
学习的高阶玩法
费曼学习法
费曼学习法是，理查德·费曼，提出的一种学习方法，据传13岁就学完微积分；高中毕业之后进入麻省理工；24岁就加入曼哈顿计划天才小组，一起研发原子弹；33岁在加州理工学院期间，费曼因其幽默生动、不拘一格的讲课风格深受学生欢迎；47岁获得诺贝尔奖。
费曼学习法是一种“以教促学”的方法，以教授的方式让我们发现自己对于知识点的盲区，并主动完善，以此让自己的知识体系更加牢固，为己所用。
费曼学习法步骤；
明确目标
明确要学习或者要输出的内容，建议可以吧目标定义为自己下一等级所要具备的能力或知识，如果涉及的知识过多可以采取分而治之的方式，将大的晋升目标化解为一个个小的目标
以教促学
1、想象自己讲这些知识讲述给完全不懂的人员
2、看自己讲解的过程是否顺畅，是否有盲区
3、如果存在知识的盲区，那么尽快去补足这部分盲区，并分析为什么这块存在盲区，防止以后再出此类问题
4、如能够比较顺畅的讲解一个内容后那么进入，提炼简化阶段
提炼简化
将知识点内容进行简化，使其更加精简，方便理解与记忆。