一、测试行业：
1、 测试的重要性（所有的产品或者服务上线都需要进行测试）
2、 测试工程师成长路线
管理方向：测试组长\测试经理\测试总监
技术方向：测试工程师、测试开发、测试架构师、性能测试、安全测试
转岗：开发、运维
3、 人员要求
懂技术、懂代码、精通测试、懂运维
4、 测试发展过程
初级阶段：以发现bug为主，手工测试为主
平台建设阶段：从手工解放
全面监控项目质量
全员测试阶段：测试人员具有开发工具的能力，开发更智能的测试工具
二、基础概念：
1、 什么是软件测试？——找bug，发现缺陷
检查软件产品是否符合设计的要求
确认软件产品是否符合用户的实际要求
提高软件产品的质量信息，投入较低的成本保障极大的降低劣质产品
验证软件产品的需求，设计和实现的一致性
对软件质量的全面评估
提示软件产品的质量风险
验证和确认
2、 测试的定义
使用人工或者自动的手段来进行或者测试某个系统的过程
目的在于检验它是否满足规定的需求
弄清预期结果和实际结果的区别
3、 测试的目的
以最小的人力、物力和时间，找出软件中潜在的错误和缺陷。
4、 测试的原则
证明软件中存在缺陷
不能穷尽测试
测试应该尽早介入
28原则：我们80%的用户只用到%20的功能，重点测
不存在缺陷谬论：没有程序没有缺陷
妥善保存一切文档：工作记录，回归测试
5、 测试标准
国际标准：ISO25010
国内标准：GBT20438 GBT18905
6、 测试的基本要求
外观界面测试
功能测试
性能测试
安全性测试
兼容性测试
易用测试
7、 bug的由来
作为一名软件测试人员，我们经常听到Bug这个词。
测试的过程其实就是在找Bug！
Bug是一个英文单词，本意是指昆虫、小虫子。
那为什么测试就是在找Bug呢？
这需要我们去追溯历史，当时人们还在使用第一代真空计算机（马克二型），这种计算机是依靠控制电流来改变开关，从而实现控制，但是它会发出大量的热和光。1949年9月9日，天气非常炎热，有一只娥死在了70号继电器里面，造成电路不通，机器死机，经过近一天的检查，Grace Hopper（格蕾斯哈珀）终于找到了真凶，原来正是被光吸引过来的娥造成了机器宕机，在这儿之后，在计算机科学中，Bug就从虫子变成了程序的缺陷，一只虫子就这样被载入了计算机史册。
三、测试与开发模型：
1、 测试工作流程
A、需求分析：
阅读需求文档、产品文档、产品详细设计说明书——分析需求的点——参与需求评审
快速熟悉项目
B、测试计划与测试方案：
制定计划：测试整个项目的总体的规划
测试的范围，进度的安排、人力物力的安排，整体的测试策略，风险的评估，风险的规避
5w 1h——why when who what where how
测试方案： how
测试的目标，测试工具，测试的方法，测试的重点
C、测试用例设计
边界值 等价类…
D、测试用例执行
E、评估阶段，测试报告
2、开发模型
A、瀑布模型
特点：
阶段间具有顺序性和依赖性、推迟实现、质量保证的观点
是文档驱动的模型，遵守这个约束可使软件维护变得更容易一些，从而显著降低软件预算。
优点：
为项目提供了按阶段划分的检查点；
当前一阶段完成后，只需要去关注后续阶段；
可以在迭代模型中应用瀑布模型
缺点：
用户可能需要较长等待时间来获取一个可供使用的系统，也许会给用户的信任程度带来影响和打击；
不适合需求模糊或者需求经常变动的系统；
由于开销的逐步升级问题，它不希望存在早期阶段的反馈；
在一个系统完成以前，它无法预测一个新系统引入一个机构的影响。
B、 增量模型
把瀑布模型的顺序特征与快速原型法的特征相结合，将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量
C、 快速原型：
是快速建立起来可以在计算机上运行的程序
优点：
克服了瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，适合预先不能确切定义需求的软件系统的开发。
缺点：
所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下，使用的前提是要有一个展示性的产品原型，一点程度上可能会限制开发人员的创新。
1、 快速分析
2、 构造
3、 运行
4、 评价
D、 螺旋开发模型
E、 迭代开发模型
和增量模型类似。一个小的版本往上开发，不可以并行。
F、 敏捷开发模型
3、 测试模型
V模型
需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试
优点：
每一个阶段都清晰明了、便于控制开发的每一个过程，既包含单元测试有包含系统测试。
缺点：
测试介入的较晚，对于前期的一些缺陷无从发现和修改，测试和开发串行，总用时较长。
W模型
测试与开发同时进行，有利于尽早地发现问题。
优点：
测试伴随软件的整个生命周期。例如，在需求分析结束后就可以进行需求分析测试。测试与开发是并行独立进行的。
缺点：
对需求和测试的技术要求高，使用于大中企业。
4、 开发和测试的关系
目标相同：都是为了制造出高质量的软件
相辅相成：开发经验对测试有用，测试经验对开发有用
侧重点不同：开发注重于从无到有，测试偏重于从有到优
思维定式、测试力度、关注度
四、软件测试的分类：
1、测试（开发）阶段来分：
单元测试：一般在编码完成前后；（模块、类、函数、方法）；开发人员、白盒测试人员
集成测试：单元测试完成以后；模块已经完成编码以后；（模块和模块之间内容）；开发人员、白盒测试人员
系统测试:集成测试完成之后；（程序、软件、APP、系统、网站、项目）整体测试；开发人员、白盒黑盒测试人员测试
验收（交付）测试：系统测试之后；（整个的系统：α测试【小范围、内测】、β测试【大范围、公测】）；媒体、用户
2、是否覆盖源码
黑盒测试：没有覆盖源码；不关心代码如何实现，只在乎结果。
功能测试
性能测试
白盒测试：覆盖源码（透明测试）
灰盒测试：介于黑盒与白盒
3、是否运行
静态测试
动态测试
4、是否自动化
手工测试
自动化测试
5、地域测试
本地化测试
国际化测试
6、其他测试分类
回归测试
冒烟测试
随机测试
探索测试
五、测试用例
1、 概念：
测试用例又叫test case，是为了某个特殊目标而编制的一组测试输入，执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
2、 特性：
有效性：测试用例可以被使用，且不同人员使用测试结果一致
可复用性：良好的测试用例具有重复使用的功能，如：回归测试
易组织性：好的测试用例会分门别类地提供给测试人员参考和使用
可评估性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的标准
可管理性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的标准
3、 测试用例的要素
1. 测试用例编号
编号由字符和数字组合成的字符串，用例编号具有唯一性，容易识别
2. 测试项目/模块
测试的项目属于哪个项目或者被测试的需求，被测的模块、被测的单元等
3. 预置条件
执行当前用例的前提条件，如果前提条件不满足，则后面的测试步骤不能进行或者得不到预期结果
4. 测试输入
测试用例执行过程中需要加工的外部信息，根据测试用例的具体条件有手工输入、数据库等
5. 预期输出
测试用例的预期输出结果，包括返回值内容、界面响应结果等（来自需求文档）
6. 操作步骤
执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据步骤完成测试
7. 测试用例标题
对测试用例的简单描述。用概括的语言描述该测试用例的测试点，每个测试用例的变体不能够重复，因为每个测试用例的测试点是不一样的
8. 级别
a、高级别：保证系统基本功能，核心业务，重要特征，实际使用频率比较高的用例
b、中级别：重要程度结余高和低之间的测试用例
c、低级别：实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例
9．其他要素
【】对应的开发人员，出现bug后能及时找到相应的人员进行修护
【】测试结果，执行用例最后的结果，包括pass、fail、block
【】用例的设计者，能准确找到测试用例设计人员，对用例修改时能方便找到人员
【】用例设计日期，方便查用例的设计进度
【】测试类型：功能、性能、压力等
4、 测试用例的设计原则
1. 明确性
尽量避免测试赛用例存在含糊的因素在测试过程中，测试用例的测试结果是唯一的
2. 代表性
尽量将具有相似功能的测试用例抽象合并，功能相似的用例要合并
3. 简洁性
可读性良好，测试过程目的明确，测试结果唯一。测试用例要用陈述性语句直指问题的核心，不要使用浮夸的修饰手法
5、 测试用例的设计方法
a.等价类划分法
定义：是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数代表性的数据作为测试用例。使用等价划分法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例机用例完整性和代表性。
b.有效等价类
有效等价类是指对程序的规格说明来说是合理的，可检验程序是否实现了规格说明中所规定的功能和性能。
c.无效等价类
可检验程序对于无效数据的处理能力，检测程序的健壮性和容错能力。
设计测试用例步骤
1. 确定需求
2. 确定有效等价类和无效等价类
3. 对每条等价类设计测试用例
d.边界值法
e.因果图法
f.判定表法
g.正交表法
h.场景法（冒烟测试）（例如：打电话的过程）
i.流程分析法（例如：ATM、银行设备）广度、深度
j.错误推断法
测试用例的力度:简单、复杂、中庸
六、测试用例设计方法总结
本质：
基于需求
理解需求，反应需求，忠于需求
需求会变化，则测试用例也应该是活的，变化的
及时响应变更比准寻变化更重要
原则：
1. 根据程序的重要性和一旦发生故障带来的损失，来确定测试等级和测试重点。
2. 认真选择测试策略。用尽可能少的的测试用例发现尽可能多的的错误。测试用例不足则会导致风险的增大；测试过度会导致资源浪费。需要找到平衡点。
方法选取：
1. 先关注主要功能，业务流程、业务逻辑是否正确，考虑场景法
2. 需要输入数据的地方，考虑等价类划分法
3. 在任何情况下都使用边界值法
4. 如果程序的功能包括输入条件的组合情况，则选取因果法和判定表法
5. 对于配置类软件，需要考虑参数的组合情况，考虑使用正交表法
6. 对照程序逻辑，如果发现没有达到要求的覆盖标准，社党补充更多的测试用例
7. 采用错误推断法，追加其他测试用例
七、测试用例的评审
1. 同行评审
“个体和交互比过程中和工具更有价值”
有测试小组内部进行评审，达到思想碰撞，通过探讨、协作完成测试用例设计
2. 用户评审
“顾客的协作比合同谈判更有价值”
如果测试是对产品的批判，则顾客是最终用户或者顾客代表
在公司内部可以是市场调查人员或者相关领域专家
如果测试视为软件开发提供帮助和支持，那么顾客就是程序员
八、软件缺陷
定义：
内部：产品开发或者维护过程中存在的错误
外部：系统所需要实现的某种功能失效或者违背
总的来说，缺陷就是问题，最终表现为所需要的功能没有完全实现，没有满足用户需求
具体包含（程序、数据、文档）
缺陷产生的原因：
需求解释或者记录错误
用户需求定义错误
需求说明存在错误
编码说明、程序代码有误
硬件或者系统存在错误
文档错误、内容不正确、拼写错误
缺陷产生的根源：
交流不充分
软件的复杂性
开发任务的错误
需求的变化
进度压力
九、缺陷报告
在测试后，如果发现缺陷，则应该进行缺陷报告。
缺陷报告有如下作用：
1.记录测试结果
2.方便开发人员进行缺陷定位
3.为后期统计缺陷提供依据