都说功能测试点点点简单，但是功能测试才是最重要的，最不可能被工具替代的。
功能测试不是等价类、边界值，需要熟悉的理论很多。
目标：熟悉测试术语、测试模型、测试流程、能编写测试相关文档、熟悉多种测试用例设计方法、bug生命周期等等。
测试理论：
0.概念
1.人们对软件测试目的的认识过程
2.测试执行
3.测试和调试的区别
4.回归测试的目的
5.软件测试的主要工作
6.软件危机的出现主要表现在
7.软件危机的后果
8.软件危机的根源
9.为什么会出现软件缺陷
10.常见引入缺陷的原因
11.缺陷的类型
12.缺陷具体表现
13.常见软件生产流程
14.软件研发三要素
15.常见项目组框架（软件项目组人员组成）
16.软件研发流程类型
17.软件研发中几个重要的过程
18.其它
0.概念
软件：实现用户需求的源代码及与之匹配的文档和支撑其运行的配置数据。是一种逻辑存在的资产。（数据结构+算法+文档+服务）。
软件测试：以用户需求为基准，运用科学的测试方法对被测对象进行检测，发现其与需求偏离的需求实现。
软件测试：是为了尽快尽早发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期、对软件产品（包含阶段性产品）进行验证和确认的活动过程。
调试：通俗的理解是对软件程序代码做出的一系列检查、改正的过程，以保证软件能够正常运行为目的。（早期软件代码少，逻辑简单，程序员完全可以应付）
软件测试的目的：
程序测试是为了发现错误而执行程序的过程；
一个好的测试用例是发现迄今为止尚未发现的错误的测试用例；
一个成功的测试执行是发现了迄今为止尚未发现的错误的测试执行。
注意：软件测试的目的不仅仅是为了发现错误，还有易用性等测试，这些统称为缺陷（发现其与需求偏离的需求实现）
修改缺陷的成本随项目发展而变高；寻找缺陷的时间随项目发展而变长。
1.人们对软件测试目的的认识过程
证明（表明软件能够工作）-->检测（发现错误）-->预防（管理质量）
注意：早期的结构化同行评审被用于帮助预防编码前的缺陷。
ps：感觉这里有点抽象，不好理解，暂时不理解。
2.测试执行
单元测试执行（UT执行）：一个测试用例的测试执行；
集成测试执行（IT执行）：一个测试用例集的测试执行；
系统测试执行（ST执行）：不同测试阶段的测试执行。
ps：这里跟我之前理解不一样。我理解的单元测试是对程序中某一个方法执行白盒测试，集成测试是多个单元集成为一个大功能进行测试，比如企业管理中增删改查集成在一起进行测试，系统测试是系统中所有的功能进行测试。
3.测试和调试的区别
| 测试 | 调试 | |
| 目的 | 找出存在的错误 | 定位错误，修改程序以修正错误 |
| 对象 | 文档、代码 | 代码 |
| 流程 | 有特定流程，有计划性 | 无特定流程，不可设计，无计划性 |
| 条件 | 从已知条件开始，用预定义过程，有预知结果 | 从未知条件开始，结束过程不可预计 |
4.回归测试的目的
（回归测试应用于：增量开发、版本控制、软件维护）（增量开发：先开发主要功能，再开发次要功能，逐步完善）
验证缺陷是否修复或增加的部分是否正确；
检测对代码的修改是否引入了新的错误。
5.软件测试的主要工作
检视代码，评审开发文档；
进行测试设计、写作测试文档（测试计划、测试方案、测试用例等）；
执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到了修复；
通过测试度量软件的质量；
......
6.软件危机的出现主要表现在
1.由于缺乏大型软件开发经验和软件开发数据积累，开发工作计划很难制定；
2.开发早期需求分析不够明确，造成开发后期矛盾集中暴露；
3.不遵循开发规范，开发文档不完善，软件难以维护；
4.缺乏严密有效的软件质量检测手段，交付给用户的软件质量差。
7.软件危机的后果
1.软件质量不高，很难稳定；
2.软件项目延期，进度无法控制；
3.成本增加，无法控制预算。
8.软件危机的根源
1.根据摩尔定律，硬件发展很快，相应对软件系统的期望越来越高；
2.软件系统复杂性提高，需多人合作；
3.软件开发是人的智力活动，无法用已有的产业工程方法来组织管理。
9.为什么会出现软件缺陷
导致软件缺陷最大的原因是需求说明书；
软件缺陷的第二大来源是设计方案；
编写代码；
其他。
10.常见引入缺陷的原因
1.开发过程缺少有效的沟通，或者没有进行沟通；（表达不正确、以致理解不正确、以致设计不正确）
2.软件复杂度越来越高；
3.编程中产生错误；（语法错误、语义错误等）
4.需求不断变更；（项目失败的最大杀手，会引起重新设计，工程重新安排等）
5.项目进度的压力；（为了抢占市场，必须比竞争对手早一步把产品提供出来，于是不合理的进度安排就产生了，不断的加班加点最终导致大量错误的产生。另一方面，由于软件项目的时间安排是最难的，通常是需要很多猜测的工作，因此当最后期限来临的时候，错误也就伴随发生了）
6.不重视开发文档；（当团队中一员离开，对于新进来的员工说，去读懂和维护一个没有文档的代码是很难的）
7.软件开发工具本身隐藏的问题；（尽量选择比较成熟的产品）
8.人员自大。
......
11.缺陷的类型
遗漏：规定或预期的需求未体现在产品中（可能未将规格说明全面实现，也可能需求分析阶段就遗漏了需求）；
错误：未将规格说明正确实现（可能设计错误、也可能编码错误）；
额外的实现：规格说明并未规定的需求被纳入产品，得到实现。
12.缺陷具体表现
软件未达到产品说明书标明的功能。
软件出现了产品说明书指明不会出现的错误。
软件功能超出产品说明书指明范围。
软件未达到产品说明书虽未指出但应达到的目标。
软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
13.常见软件生产流程
（软件的生命周期，Software Lifecycle Model，9个阶段）：
市场调研-->可行性研究-->产品立项-->需求调研-->设计开发-->系统测试-->产品发布-->产品维护-->产品升级。
问题定义-->可行性研究-->需求分析（功能建模、数据建模）-->概要设计-->详细设计-->编码-->测试-->维护。
1.计划（Planning）：（1）确定软件开发总目标；（2）给出软件的功能、性能、可靠性以及接口等方面的设想；（3）研究完成该项目的可行性，探讨问题解决方案；（4）对可供开发使用的资源、成本、可取得的效益和开发进度做出估计；（5）制定完成开发任务的实施计划。
2.需求分析（Requirement Analysis）：对开发的软件进行详细的定义，由需求分析人员和用户共同讨论决定，哪些需求是可以满足的，并且给与确切的描述，写出软件需求说明书SRS。
（针对产品的软件研发，需求来源于市场调研，特点是自己想研发什么，自己就来研发；针对项目的软件研发，需求来源于客户要求，特点是别人想研发什么，我们帮着研发。项目型软件：特定客户针对某个特定软件产品指定供应商，软件知识产权归客户所有；产品型软件：特定软件针对某个特定群体开发的通用型软件产品，软件知识产品归软件开发商所有。）
3.设计（Design，概要设计与详细设计）：是软件工程的核心技术，这个阶段需要完成设计说明书。概要设计（HLD）：在设计阶段把各项需求转换为相应的体系结构，每一部分是功能明确的模块；详细设计（LLD）：对每个模块要完成的工作进行具体的描述。
4.程序编码（Coding）：把软件设计转换成计算机可以接受的程序，即写成某个程序设计语言表示的源程序清单。
5.测试（Testing）：检验软件是否符合客户需求，达到质量要求，一般由独立的小组执行，测试工作分为：单元测试（对每一个函数进行测试）、集成测试（对函数与函数的集成，即函数间、模块与模块的集成，即模块间、子系统与子系统的集成，即系统间，进行测试）、系统测试（对每一个功能需求、性能需求等进行测试）。
6.运行和维护（Run and Maintenance）：将软件交付用户投入正式使用，以后便进入维护阶段，可能有多种原因需要对它进行修改，如软件错误、系统软件升级、增强软件功能、提高性能等。
14.软件研发三要素
人员、过程、工具；
只有适合的人员借助适合的工具经过适合的过程才能研发出高质量的软件；工具是为人员和过程服务，起辅助作用，起关键作用的是人员和过程。
15.常见项目组框架（软件项目组人员组成）
1.项目经理；
2.开发组：开发经理、分析人员、设计人员、开发人员；
3.测试组：测试经理、测试人员；
4.配置管理组：配置经理、配置管理员（CMO,configuration management officer）；
3.SQA（质量保证人员）。
16.软件研发流程类型
1.瀑布模型（Waterfall Model）：线性，串行，无风险控制能力，适合需求变化较小的情况。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用瀑布模型结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
计划阶段：项目计划书，Project Plan
需求阶段：需求规格说明书，SRS:Software Requirement Specification
设计阶段：概要设计：High Level Design，详细设计：Low Level Design
开发阶段：代码，用例
测试阶段：测试实现和执行
维护阶段：产品维护
优点：简单高效（一般产品要求立即上线，应第一时间保证运行，其它的有时间再做）
缺点：测试介入较晚，人员闲置严重，后续工作跟不上；在项目各个阶段之间极少有反馈；只有在项目生命周期的后期才能看到结果；通过过多的强制完成日期和里程碑来跟踪各个项目阶段；瀑布模型的突出缺点是不适用用户需求的变化。
适用范围：项目开发完成后才招测试人员，那么可能是瀑布模型，不适合需求频繁变更的项目。不适合大的项目，适用于小规模传统项目业务研发。适合范围：项目小、需求明确。
按照瀑布模型的阶段划分，软件测试可分为单元测试、集成测试、系统测试。
风险驱动的模型，迭代模型（Iteration），可在迭代模型中应用瀑布模型。每次迭代产生一个可运行的版本，同时增加更多的功能。每次迭代必须经过质量和集成测试。
增量：软件开发过程中，先开发主要功能模块，再开发次要功能模块，逐步完善，最终开发出符合需求的软件产品。
迭代：指增量开发过程中，各模块的开发是反复进行的，并不是完成了某个模块后就终止该模块的开发而开发下一个模块，可能还要对之前开发的模块不断完善，增加新功能。
2.螺旋模型：基于风险管理的模型，高风险的优先考虑，对风险管理人员的要求较高。综合了基本的瀑布式模型和演化/渐增原型方法。与瀑布模型不同点：螺旋模型有替代方案，是多个瀑布模型的并行集合。充分考虑了风险问题，故设计了替代方案。
优点：充分考虑风险，抗风险能力强；
缺点：成本太高，需要专业的风险分析专家参与；
适用范围：与生命财产相关的系统。
3.RUP（Rational Unified Process）：统一软件开发过程，是一个面向对象且基于网络的程序开发方法论。所有的工作流在各个阶段都有体现。面向对象的，通用的。特点：基于风险；用例集驱动；以架构为中心；迭代和增量。所以工作流在各个阶段都有体现。
优点：针对大型复杂的系统，进行逐步完善，降低了实施复杂度；用户可在早期提出变更并进行修复，从而有效控制变更风险及代价（往往都是局部变更）；可在早期增强用户的信心（看到了半成品）。
缺点：要有专业的架构师（架构师的职责），当功能与功能之间联系太过紧密的话，不太实用rup模型，比如登录与注册的联系；已经确定了的功能将不允许变更，但由于因为设计引起的内在联系引起的变更是无法控制的。
适用范围：大型复杂的项目研发，耦合度较低的系统。
4.IPD（integrated product development）：集成产品开发，IPD的思想来源于美国PRTM公司出版的《产品及生命优化法》（简称PACE-Product And Cycle-time Excellence）一书，该书中详细描述了这种新的产品开发模式所包含的各个方面。产品结构重整（资源重整）；公共模块共用。
从整个产品角度出发，不仅仅针对研发。
优点：将软硬件研发及生产、销售等各个部门有效整合，集中在一个平台下统一管理，提高了决策的准确性及时效性；利于各个部门关键数据的共享；
缺点：管理成本高；部门之间的协调关系较复杂；
适用范围：大型软硬件集成商。
5.敏捷开发：Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。
计划开发一定功能，并把一个个功能挨个快速的实现，省略文档协作（包括概要设计），在这个基础上可能增加功能。
17.软件开发中几个重要的过程
需求管理、配置管理、缺陷管理、同行评审。
18.其它
1.测试不是点点鼠标，敲敲键盘，而是要结合业务逻辑和用户需求，并使用各种技术。
2.一个好的软件测试人员，一定是懂开发知识的；一个好的软件开发人员，一定是懂测试的。
软件测试主要是为了发现以下几类错误：
①是否有不正确或遗漏了的功能？
②在接口上，输入能否正确的接受？能否输出正确的结果？
③是否有数据结构错误或外部信息（例如数据文件）访问错误？
④性能上是否能够满足要求？
⑤是否有初始化或者终止性错误？
内容来自：https://www.cnblogs.com/UncleYong/p/5875894.html