一、软件开发阶段
- 需求分析
①根据客户的要求，清楚了解客户需求中的产品功能、性能、界面和具体规格等，然后进行分析，确定软件产品索要达到的目标
②要形成规则说明书 - 概要设计
① 系统分析员审查软件计划、软件需求分析提供的文档，提出候选的最佳推荐方案，确定模块结构，划分功能模块，将软件功能需求分配给所划分的最小单元模块，确定模块间的联系，确定数据结构、文件结构、数据库模式等
② 概要设计说明书 - 详细设计
① 将每一个模块确定使用的算法，并用适当的工具（如流程图）表示算法的过程，写出模块的详细过程性描述；确定每个模块使用的数据结构；确定模块接口的细节，包括用户界面、数据输入输出等全部细节。
② 详细设计说明书 - 编码
通过编程语言实现
哪个阶段引入的缺陷最多？
二、软件测试阶段
- 单元测试
①依据：详细设计文档
②以黑盒测试（功能测试）为主，重点核心模块可以进行白盒测试（检查代码）
③可能需要编写驱动模块或桩模块【因为一个模块，可能不会单独存在，需要调用别的模块或者被别的模块调用】
驱动模块：模拟被测模块的上一级模块（调用被测模块的哪个模块）
桩模块：模拟被测模块的下一级模块（被被测模块调用的模块）
④在实际工程中，为了节约成本，单元测试经常只由开发人员完成，有悖于测试测试思想（测试必须由第三方来完成）
一个好的单元测试将会在产品开发的阶段发现大部分的缺陷，并且修改它们的成本也很低。
在软件开发的后期阶段，缺陷的修改将会变得更加困难，要消耗更多的成本 - 集成测试
①拿到一个新的集成版本的时候，一般先做冒烟测试-–利用较短时间（0.5-2天）、较少的人员（1-3名，经验丰富）对软件的核心功能进行测试，主要判断该版本是否值得一测，如果值得一测，整个测试组再投入；如果不值得一测，打回开发组，另其完善后再给出新版本。
②拿到一个新版本的测试思路：
A、冒烟测试
B、返测：对发现的缺陷是否进行修复的测试
C、回归测试：对前面版本中所有的用例再执行一遍（保证软件旧的功能是正确的）
D、对新添加的功能进行测试 - 系统测试
①对整个软件系统进行全面完整的测试过程
②在系统测试之前一般有“确认测试”：
A、确认该程序值不值得一测（冒烟测试）
B、确认相关的文档是否齐全（尤其是交给用户的文档，比如用户手册） 验收测试（用户接受度测试、用户体验测试，UAT user acceptance test）：α测试、β测试
①α测试：由最终的用户在开发的环境中，对软件进行测试（在实际中，也经常由开发方自主完成）
②β测试：由最终的用户在实际的环境中进行测试使用
对于一些没有固定用户群的公共类软件（如办公软件、游戏、输入法），一般会发型公测版（β版），让用户免费使用，发现bug后进行信息反馈
三、软件测试模型
1、概念:测试模型体现的是开发和测试的对应关系
2、V模型
优点：测试阶段明确，既包括单元级（可能涉及代码）也包括用户级，与开发关系明确
缺点：容易理解成测试只是开发后的一个工作，不符合越早测试和不断测试的原则
深入理解：
①在编码之前，我们需要对相关的需求开发文档进行测试—越早测试
②根据相关文档，在测试执行之前编写各个阶段的测试计划、测试用例等文档–测试过程是有计划的
注意：
如果做单元测试，需要有详细设计文档
如果做集成测试，需要有概要设计文档
如果做系统测试，需要有需求文档
四、软件测试的分类
1、按照测试技术来划分
- 黑盒测试（功能测试）：必须进行
- 白盒测试（逻辑结构测试），通过检查代码，对软件进行检查：可选
白盒测试重点看代码的逻辑、算法、结构是否正确，要求必须懂得代码，需要编写测试用例
- 灰盒测试：先黑盒，哪出现问题，再查看代码白盒
在单元测试时，白盒应用相对较多
在集成测试时，灰盒应用相对较多
在系统测试、验收测试时，一般不会使用白盒测试和灰盒测试（使用黑盒测试，但是发现怎么也发现不了问题，或者问题太大，这时就只能查看代码了）
2、按照是否需要运行代码划分
- 静态测试：界面、文档、代码
静态测试中代码侧重点是：代码规范性，一般检查变量的命名、注释的频率、编程的规范性，一般不需要写测试用例，有代码审查单即可）
比如Java中 int a=0,b=0,c=0;
虽然没有语法错误，但是可能不符合公司的规范
公司的规范是变量定义时，每行只定义一个，并且要有注释，定义的变量含义。
经常把白盒测试和静态测试结合在一起，形成静态白盒测试
- 动态测试：
3、按软件特性分类
- 功能测试：手工或工具
- 性能测试—分布式软件B/S、C/S,必须用工具LoadRunner
