目录
一.什么是测试
测试：测试是一个过程，是测试人员验证软件的特性是否符合需求
软件特性：特性分为功能相关的特性与非功能相关的特性，后续再进行详细介绍
二.测试与开发之间的区别
1.工作内容上的区别
开发：主要的工作内容是利用编程语言进行软件开发，修复BUG和开会...
测试：理解需求，设计测试用例，执行测试，发送测试报告......
2.技能要求上的区别
测试：测试人员在技能广度上要求更高
开发：开发人员在技能深度上要求更高
3.发展前景
测试：初级测试->中级测试->高级测试->架构师->CTO
开发：初级开发->中级开发->高级开发->项目经理/产品经理
测试与调试之间的区别
1.阶段不同：测试贯穿软件开发的整个声明周期，而调试只能等开发人员写出部分代码或者全部代码之后才能进行
2.参与人员不同：调试是由开发人员来完成，而测试是测试人员和开发人员共同参与，一般而言，黑盒测试是由测试人员完成，而部分的白盒测试是由开发人员来完成的（如部分单元测试和部分系统测试）
3.目的不同：调试的目的是发现并解决问题，而测试的目的是为了发现问题
4.手段不同：调试通常使用debug+打断点和利用代码间的逻辑进行，而测试则是使用丰富的测试方法，如等价划分法，边界值法，判定表法......
三.优秀的测试人员所应具备的素质
分两个方面进行讲述：
技能相关：包括测试用例的设计方法和编程能力......
非技能相关：沟通能力，文字表达能力，抗压力以及责任感等等
四.需求
需求的概念
需求：满足用户需要或者正式规定文档中所具有的条件和权能，需求可以分为用户需求和软件需求
用户需求：由甲方（用户提出来的需求），这类需求一般比较简单，对需求的描述也不是非常清楚。
软件需求：由产品（人员）设计产生，详细描述需要实现的功能需求
需求的产生，需求是怎么来的？
需求主要由产品经理通过各种渠道收集用户需求信息，并由此生成一份完整且详细的需求文档
测试人员眼中的需求
测试人员会将业务需求划分为不同的软件功能模块，将每个模块细化为不同的功能和测试点，根据每个细化的功能和测试点从功能相关，兼容性相关，安全性相关，外观相关，易用性相关等方面设计不同的测试用例
例如：
需求的重要性
如果对于软件设计的需求不清楚，或者没有需求，会导致很严重的问题。比如如果开发人员和测试人员对于软件设计的需求没有得到统一，在这种情况下一旦项目上线，由于可能测试人员对于项目的需求水平较低，而没有考虑全面的测试用例，可能会导致很严重的问题；同时开发和测试需求不统一两者在项目协作上效率也会很低。
例如我们拿登录这样一个业务需求来说，如果需求不清楚，将会导致我们对登录的方式，账号密码的来源和账号密码的显示形式都不清楚，则会有极大的可能性导致测试人员设计的测试用例与开发人员开发的软件不匹配，测试也可能会导致漏测的产生
漏测：软件测试人员测试用例不全面，在软件上线之后出现BUG
测试人员如何深入理解需求
需求是在需求评审会议中产品经理通过需求文档的形式向测试人员介绍需求，后续测试人员通过产品的需求文档和开发方的技术文档，并通过后续与产品经理和开发人员之间的沟通深入理解需求
五.测试用例
概念
测试用例是为了实施测试面向被测试的系统提供的一组集合，这组集合包括：序号，测试标题，测试环境，操作步骤，测试数据，预期结果等要素。测试用例是测试人员执行测试的重要依据。
我们拿测试用户登录的一组用例来讲述：
测试序号：001 测试标题：用户登录的正常测试 测试环境：本地 操作步骤：输入账号，输入密码，点击登录 测试数据：账号+密码 预期结果 ：登录成功
我们再举一个我们之前博客系统的一个测试用例：
测试用例的重要性
测试用例是测试人员执行测试的重要依据：我们在执行测试之前要先设计好测试用例，所以它是测试人员执行测试的重要依据。
测试用例是自动化测试的重要依据：我们进行自动化测试虽然不需要人工手动执行测试过程，但是仍需人工设计好测试用例
测试用例降低测试人员的重复性：如果我们要进行的测试可以分为很多项，需要不同的测试人员进行协作测试，如果不规定好每个测试人员所需要测试的用例，很容易造成同一个测试项多个测试人员的重复测试
测试用例可以保证测试质量：只有设计出完成且高质量的测试用例，才能保证测试的质量
六.BUG
概念
在规格说明正确的前提下，程序与规格说明不匹配的现象我们称之为BUG
评判标准
BUG的评判标准主要依赖于以下两个点：
①规格说明中存在，且规格说明确保正确，程序与规格说明不符，则说明出现了BUG
②规格说明书中没有提到的功能，以用户作为最终的评判标准，当程序最终没有实现用户的合理预期功能时，我们称出现了BUG
七.软件生命周期
概念
即需求，计划、设计、编码、测试、运行维护
详细介绍
需求产生与需求分析：产品人员将用户需求转化为软件需求 ，并生成需求文档，根据需求文档进行需求分析，并分析需求是否合理和完整
计划：规定项目整体规划，即项目有谁开发，由谁维护，什么时候开始开发和开发结束，什么时候测试结束，什么时候上线等等
设计：开发人员设计项目底层如何实现，输出一个技术文档（详细记录了软件技术上如何实现，接口，库表，定时任务，mq......） 和UI设计稿（UI设计师将需求文档转化为图片）
编码：开发人员开发软件，测试人员设计测试工具，设计测试用例
测试：执行测试，提交BUG，验收BUG
运行维护：将项目推到线上，如果发现线上BUG，此时需要修复和重新上线
八.开发模型
瀑布模型
特点：每个阶段都是线性执行的
优点：每个阶段的目标都很明确
缺点：测试人员介入太晚，如果出现问题，只能一步一步向前回溯，直到发现问题所在
适用项目：小型项目
螺旋模型
特点：每一次实施之前都要进行风险分析
优点：风险分析可以避免一些未知的问题
缺点：风险分析一旦出现错误就会带来损失，同时风险分析需要一定的成本（时间人员金钱）
增量、迭代
我们说一下增量和迭代的区别：
假设APP的开发包含了1,2,3,4这四个模块
增量：先开发1模块，再开发2模块，再开发3模块，再开发4模块
迭代：先开发一模块中的一部分，比如整体架构等等，再开发二模块的一部分，再开发三模块的一部分，再开发4模块的一部分，这样一直往复，直到开发结束
敏捷
scrum是敏捷开发模式中的一种实现
敏捷宣言
个体与交互重于过程和工具 ：敏捷开发模式更注重开发项目中开发者之间的交互，而设计的开发过程与开发工具都是服务于开发者之间的交互可用的软件重于完备的文档 ：即使在某些特殊情况下开发人员没有生成技术文档，我们仍然可以通过与真实可用的软件生成完整的测试用例进行测试客户协作重于合同谈判 ：我们无权要求用户在项目设计之初就把所有需要实现的功能和具体细节全部写入项目合同中，而应该是用户与开发者在整个项目开发过程中进行往复的交互。（在开发过程中用户可能提出新的功能要求和细节实现）响应变化重于遵循计划 ：比起之前设计好的计划，敏捷开发模式更注重开发者如何响应变化在每对比对中，后者并非全无价值，但我们更看重前者。
scrum中的角色
PO(产品经理)：负责收集用户需求，并生成需求文档
SM(项目经理)：在项目开发过程中出现的问题由项目经理负责协调帮助
Team(开发团队，包括前端开发，后端开发，测试，设计)
敏捷开发流程
与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4 周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。
我们按照开发流程一一进行解释说明：
1.产品经理(PO)负责收集用户需求，并将用户需求写入需求池，从而生成product log
2.项目经理（SM）负责对所有需求的优先级进行排序，并生成项目执行计划（谁来开发，谁来测试，开发时间，测试时间....）
3.每日站会：每天早上负责对昨天的任务进行总结以及阐述是否需要帮助，对今天的任务进行计划
4.演示会议：将一个迭代周期的项目开发完成后将项目演示给组中未参与开发的人员，由他们来提出建议，如果需求合理则加入需求池，下一阶段的开发完成这个需求
5.回顾会议：对项目开发过程中出现的问题进行记录，以便后续开发出现类似问题时进行解决或提供解决方案
软件测试V模型
我们对其进行详细介绍：
用户需求：PM收集用户需求并产出软件需求需求分析与系统：F分析需求是否正确和完整
概要设计：对项目进行整体方面的设计，包括使用什么语言，什么框架，以及项目结构如何设计等等
详细设计：对每个功能进行详细设计，最终生成技术文档（技术文档中包括接口，库表，mq,redis，定时任务......）
编码：详细代码的实现
单元测试：测试一个一个的单元（一个类，一个方法...）
集成测试：测试某个模块
系统测试：把整个项目运行起来然后整体进行测试
验收测试：将最终成果交给产品，运营与用户进行验收
特点：
是线性的，左边是开发，右边是测试优点：每个阶段所要做的任务都是非常清晰的，测试被划分为了许多类型
缺点：测试人员介入太晚，测试和开发是并行的
软件测试W模型
W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分 别代表测试与开发过程，图中明确表示出了测试与开发的并行关系
特点：开发一个V，测试一个V
优点：测试人员尽早介入了需求 测试和开发是并行的
缺点：不能拥抱变化，发生变化之后还是得一步一步向前回溯找出错误，也就意味着不适用于敏捷开发模式，测试和开发并不是完全并行，在一定程度上也是串行的