一、 什么是软件测试？
软件测试定义：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。或者：为了发现程序中的错误而执行程序的过程。
软件测试存在的意义：
①程序测试为了发现程序存在的代码或业务逻辑错误；
②软件测试为了检验产品是否符合用户需求（充分站在用户的角度）；
③软件测试为了提高用户的体验。
二、软件测试的原则
1、测试应该尽早介入。
2、所有的测试都应追溯到用户需求。
3、程序员应该避免检查自己的程序。除了单元测试。因为程序员对于自己的作品，思维具有局限性。无法保证测试质量。交给第三方或者专业测试，运用各种测试技术，利用丰富的测试经验和对BUG的敏感，去提高软件的质量。
4、设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下还要制造极端状态和意外状态。
5、二八原则，测试发现的错误中80%很可能起源于20%的模块中。
6、对错误结果要进行一个确认过程（分清必现和偶然）。
7、制定严格的测试计划。
8、完全测试时不可能的，测试需要终止。
9、妥善保存测试过程中所有文档。
三、软件测试的分类
a. 按测试阶段划分：单元测试（开发的自测行为）、集成测试（多个模块共同测试）、系统测试（完整的、全面的测试）、验收测试（正式验收测试、Alpha测试（开发和测试参与，模拟用户进行测试，前期，非真实环境）、Bate测试（开发和测试都不能参与测试，由用户进行测试，后期，真实环境下测试））
b. 按测试技术划分：白盒测试、黑盒测试（主流）、灰盒测试（eg：接口测试）
c. 按测试对象是否运行划分：动态测试、静态测试（文档检查、代码走查、界面检查）
d. 按不同的测试手段划分：手工测试、自动化测试
e. 按测试包含的内容划分：功能测试（等同于黑盒测试，点点点）、界面测试（不会专门做，做功能测试时会同时做这个）、安全测试、兼容性测试（ios、安卓）、易用性测试（不会专门做，做功能测试时会同时做这个）、性能测试、压力测试、负载测试、恢复测试（灾备，若出现奔溃，需要多久自我修复）
f. 其他测试：冒烟测试（在真正测试之前，会先进行主干测试，若主干测试都无法通过，则不再进行测试）、回归测试（首先看bug是否真的修复，再次看bug修复后是否影响到与其有关的本来正常的功能）、探索性测试（测试思维）（随机测试）
四、软件生命周期（十分重要）
软件生命周期（SDLC,System Development Life Cycle）是软件开始研制到最终被废弃不用这整个过程叫做软件生命周期，整个生命周期包括问题定义及规划、需求分析、系统设计、软件编程、软件测试、软件维护等阶段。
1、问题定义及规划（参与人员：老板、产品经理（主导）、研发经理、项目经理、需求分析师）主要确定软件的开发目的及其可行性。制定开发计划（软件需求说明书、原型图）。
2、需求分析/评审（原型图/软件需求说明书、主持—>产品经理 其他参与：研发设计 测试）在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析，明确客户的需求，输出需求规格说明书（原型图）。（关注一个问题Q：测试参与这个需求分析的目的是什么？A：理解产品用途，功能如何实现）
3、软件设计（属于开发的工作）把需求分析得到的结果转换为软件结构和数据结构，形成系统架构。
概要设计：主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。（数据库、表等框架性的东西）
详细设计：对概要设计中表述（伪代码的级别）
4、软件编码（开发编码，与测试无关）
5、软件测试
在软件设计完成后要经过严密的测试，以及发现软件在整个设计过程中存在的问题并加以纠正。测试的方法主要有白盒测试和黑盒测试两种。
其中，开发：单元测试；开发or测试：集成测试、接口测试；测试人员：系统测试；客户or产品经理：验收测试（α测试、β测试）
单元测试：主要测试程序代码，为的是确保各单元模块被正确的编译，比如有具体到模块的测试，也有具体到类、函数的测试等。----一般是开发来完成。
集成测试：单元测试后，将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据能否正常传递。----比如说注册和充值这两个功能是否能够连通。
接口测试：是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
系统测试：把软件系统搭建起来，按照软件规格说明书所要求，测试软件其性能功能等是否和用户需求符合，在系统中运行是否存在漏洞等。-----根据测试用例，进行完整的系统测试。
五、运行维护阶段（版本上线，产品上线；版本升级；bug修复）
1、软件测试的工作流程：
接触人员：开发，产品经理，客服（用户反馈问题），实施/技术支持/现场实施，设计师；
2、测试工作流程：
①需求分析：1.阅读需求/理解需求 2.整理需求 3.有疑问的地方需要讨论，弄明白为止；
②软件测试计划：一个文档，测试负责人/小组长（产品经理）制定计划；测试策略（测试架构师）
文档包含内容：
目的：完成测试，何时终止，达成什么样的目标；
参与人员：谁参与，成为测试小组；
任务划分：谁负责哪个功能模块的测试/用例的编写；
时间规划：什么时候写用例，什么时候测试，什么时候解释，什么时候上线；
出具的文档：用例bug表单 软件测试报告；
资源的申请/准备：申请一台服务器？我要做什么类型的测试？需要准备什么样的工具？
③测试设计阶段：写测试用例
评审（相互检查），修改：理解错误：改正；需求变更：修改，
④软件测试的执行阶段
1.测试前，进行冒烟测试，通过继续测试，不通过，打回
2.根据测试用例执行测试：发现bug提交bug管理系统；修复后，检验，再进行回归测试。
⑤评估阶段
测试完毕，出具测试报告：1.测试通过，上线； 2.测试不通过，打回，修改
六、软件生命周期模型
作为测试工程师，我们最关心的三件事：
1.测什么？（最关注的问题）
2.怎么测？
3.什么时候测？
测试的计划是跟开发的计划走的
学习目标：
1.什么是软件测试需求？
2.软件测试需求的必要性
3.如何对软件测试需求进行分析（重点）
功能、易用、界面、权限
4.需求分析对开发和测试的影响
3.软件测试流程设计、执行、总结
4.常见面试笔试题测试结束的标准是什么：系统测试缺陷报告跟踪完毕，系统测试报告通过审批。测试用例执行完毕、用例通过率＞98%。不存在严重bug。
执行测试用例的时间：一般为3-6个月，起码3个月，但留给测试的可能只有7天。
软件测试用例的设计方法——四大金刚
1.等价类划分法
1.等价类划分法的概念
等价类划分法是一种典型的、重要的黑盒测试方法，是指某个输入域的子集合。在该子集合中，所有的输入数据对于揭露软件中的错误是等效的。
等价划分分为有效等价类和无效等价类，有效和无效是根据条件划分的。
2.错误推测法
输入错误的信息进行检测，看测试程序对错误情况的处理能力。
3.边界值分析法
1.定义：边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找。边界值分析的基本思想：正好等于、刚刚大于、刚刚小于边界的值做为测试数据。
注意：0和负数都是一个特殊值，我们在考虑边界值的时候同时也要考虑特殊值。
4.场景法（功能做好了才用）（xmind）
整个流程的描述，例如ATM取款流程
七、什么是测试用例
测试用例（TestCast）是为项目需求而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序是否满足客户需求。可以总结为：每个测试点的数据设计和步骤设计。
7.1测试用例的重要性
1.测试用例是软件测试的核心
软件测试的重要性是毋庸置疑的，测试用例是测试工作的指导，是软件测试质量稳定的保障。影响软件测试的因素很多，如软件本身的复杂程度，开发质量，测试方法和技术的使用。但有些因素是客观存在，不可避免的，如IT团队的流动、环境、情绪等。
2.评估测试结果的基准
测试用例的通过率以及错误率，是测试结束的一个重要依据，用来判断该软件测试结果是否通过，能否达到上线的标准。
3.保证测试的时候不遗漏测试功能点。可以在测试人员疲累的时候起到引导作用。
4.在编写测试用例过程，可以熟悉需求，对系统架构或者业务流程有一个整体的、深入地了解。
5.好的测试用例不仅方便自己和他人查看，而且能帮助设计的时候考虑的更周全，因此测试用例的写作和设计一样，很重要。指导性。
7.2测试用例的八大要素
1.用例编号：产品名-测试阶段-测试项-xxx
2.测试项目：对应一个功能模块（细分功能）
3.测试标题：直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复(一句话说清楚测试点是什么)
4.重要级别：高/中/低
5.预置条件：需要满足一些前提条件，否则用例无法执行（用例可写也可不写）
6.测试输入：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来一定要具有指导性意义）
7.操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作。
8.预期结果：根据与其输出比对实际记过，来判断被测对象是否符合需求。（预期结果唯一）
9.实际结果：
7.3测试用例使用工具
excel和xmind（都要会用）
八、bug的生命周期（重点）
8.1 bug的定义
软件的Bug，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。
测试工程师的职责是：发现BUG，并提交给开发，让开发去修改。
8.2 bug的类型
要确定一个bug的类型，需要对项目（或产品）有比较深的理解。这个划分对于开发定位问题影响很小，但对问题类型的统计就比较重要了。
常见bug类型划分（禅道系统为例，可自定义）：
代码错误
设计缺陷
界面优化
性能问题
配置相关
安装部署
安全相关
标准规范
测试脚本
其他
8.3bug的等级
1,2,3,4级，1级最严重的bug;3属于正常bug。
（1）致命错误：
1.常规操作引起的系统崩溃、死机、死循环，比如对话框输入信息造成程序崩溃；
2.造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息的泄露；
3.涉及金钱的方面，例如：用户余额为零，却能消费
（2）严重错误：
1.重要功能不能实现；（比如用户无法注册）
2.错误的波及面广，影响到其他重要功能正常实现：功能交互
3.非常规操作导致程序的崩溃、死机、死循环等；
4.外观难以接受的缺陷；
5.密码明文显示（界面+数据库）。
（3）一般错误：
不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷。
1.次要功能不能正常实现；
2.操作界面错误（包括数据窗口内列名定义，含义不一致）；
3.查询错误，数据错误显示；（张冠李戴）
4.简单的输入限制未放在前段进行控制；（格式限制）
5.删除操作未给出提示；
（4）可忽略错误
例如错别字，或测试人员觉得软件设计不美观等。
8.4bug的生命周期
测试(发现并提交bug至管理系统中)——>指派给对应开发人员
——>开发人员先确认是否是自己的bug，若是，确认；不是，打回测试；不是bug，不予解决，因为不是bug；或延期解决。设计如此；无法重现。——>对于打回的bug，测试再次确定需求，若的确是bug，则再次激活发给开发。——>对于修复后的bug，测试进行回归测试或验证测试，若已经解决，就直接关闭。若还未解决，再次打回给开发。
客服（客户反馈的问题）——>发给测试，若是bug,提交，若不是就告诉客服是客户的操作问题。
测试（需求的确定，需求的变更，和开发扯不清楚）——>产品经理
缺陷状态说明
新建：测试中新建的软件缺陷，还没有提交给软件工程师。一般由测试负责人进行评估，如果属于缺陷，修改为“打开”状态；如果不属于缺陷，修改为“取消”状态。
打开：测试中新建的软件缺陷，已提交给相关软件工程师。
待讨论：存在争议，需要软件工程师、需求人员和测试工程师共同确认；该状态是临时状态，在进入最后一轮ST测试执行之前，必须进行处理。
已修复：软件工程师已修正缺陷，等待测试工程师进行验证。
已发布：软件工程师已提交修复版本，并且版本管理员已将修复版本发布到测试环境。
项目内暂不处理：由于各种原因，提交的缺陷需要在后续版本才能修改，或者不修改。项目内暂不处理的缺陷需要由需求人员、软件工程师和测试工程师最终确认。对准备修改的缺陷，在进入最后一轮ST测试执行之前，测试工程师就必须和需求人员、开发人员讨论确定是“转业务需求”还是“转内部需求”，在后续项目进行修复，或者在本项目最后一轮ST测试执行前修复。对一致认可但不准备修复的缺陷，或者不能重现的缺陷，可以将“项目内暂不处理”作为终态。
已否决：软件工程师认为不需要修改，或者按照设计就应该是这样的。对于非本项目或者非本人缺陷，由于设计变更或者版本变更之前的问题现在无法重现，不能否决。无理由否决的，测试工程师一律重新打开。
已分配：转发给其他人处理。也可以转给自己处理，转给自己处理时，表明软件工程师已接受此项缺陷。
重新打开：测试工程师对已修复的缺陷进行验证，发现缺陷仍旧存在。或者测试工程师认为已被否决的缺陷确实需要修改。
已关闭：缺陷已被修复，且回归测试验证成功。
非问题关闭：对于软件工程师否决的缺陷，如果测试工程师认为确实不属于缺陷，则将缺陷状态标记为“非问题关闭”。
转业务需求：该缺陷与业务相关，需要解决，但在本项目中不处理，由需求人员在后续版本中作为业务需求提出。
转内部需求：该缺陷主要是设计实现的问题，不涉及业务需求的变更，需要解决，但在本项目中不处理，由软件工程师在后续版本中作为内部改进需求提出。
取消：测试中新建的软件缺陷，由测试负责人进行评估，确认不属于缺陷，则将缺陷状态标记为“取消”。
Bug单的要素：
九、敏捷开发
Scrum开发模型中的三种主要角色：
productowner:产品负责人，确定大家要做什么
scrummaster:负责确保Scrum模型被产品团队高效、一致理解并有效实施
team:负责把产品做出来，承担研发责任
Scrum开发中三个重要的产出：
productionbacklog（产品待办事项列表）
sprintbackblog（该冲刺阶段任务划分和详细安排）
sprintburn
down（是用于表示这个冲刺点剩余工作量的工作图表）
scrum开发中的四个会议：
sprint计划会（理解需要做什么，然后讨论怎么做）
每日站会（昨天做了什么，今天打算做什么）
sprint评审会（大家评审sprint产出，然后对待办事项做相应调整）
sprint回顾会（讨论哪里完成好，哪里需要改进）