测试理論|软件的生命周期、开发模型、测试模型（V W)、软件测试的生命周期、测试用例的设计方法、软件测试的分类
1. 软件测试教程
文章目录
- 1. 软件测试教程
- A. 概念篇
- B. 基础篇
- C. 用例篇
- D. 进阶篇
A. 概念篇
1. 目的和原则
a) 目的：验证软件有或没有问题。 原则：以客户为中心，遵循软件测试的规范、流程、标准和要求
2. 什么是需求
b) 软件需求 (1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 (3)一种反映上面(1)或(2)所述条件或权能的文档说明。
c) 用户需求 可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
3. 什么是bug
a) 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。 当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
4. 什么是测试用例
a) 为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
(1)
5. 软件的生命周期
a) 需求分析、计划、设计、编码、测试、运行维护
6. 开发模型
a) 瀑布模型
(1) 模型
(2) 优点 1.强调开发的阶段性； 2.强调早期计划及需求调查； 3.强调产品测试
(3) 缺点 1.依赖于早期进行的唯一一次需求调查，不能适应需求的变化； 2.风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。
b) 螺旋模型
(1) 适用场合 一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一
(2) 优点 1.强调严格的全过程风险管理。 2.强调各开发阶段的质量。 3.提供机会检讨项目是否有价值继续下去
(3) 缺点 1.引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入
c) 增量
(1) 显著降低项目风险，结合软件持续构建机制
i) 逐块建造
d) 迭代
(1) 反复求精
e) 敏捷
(1) 敏捷宣言
个体与交互重于过程和工具 2.可用的软件重于完备的文档 3.客户协作重于合同谈判 4.响应变化重于遵循计划
(2) scrum
i) 角色 product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
ii) 基本流程 产品负责人负责整理user story，形成左侧的product backlog。 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。
7. 测试模型
a) v模型
(2) 特点 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系
(3) 局限性 仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试
b) W模型
(2) 特点 测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
(4) 缺点 需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
8. 配置管理和软件测试
B. 基础篇
1. 软件测试的生命周期
a) 需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
2. 如何描述一个bug
bug即软件缺陷
3. 如何定义bug的级别
a) Blocker（崩溃）
(1) 阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
b) Critical（严重）
(1) 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
c) Major（一般）
(1) 功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
d) Minor（次要）
(1) 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
4. bug的生命周期
C. 用例篇
1. 测试用例的基本要素
2. 测试用例的设计方法
a) 测试用例的总体设计方法 基于需求的设计
(1) 验证需求是否正确、完整、无二义性，并且逻辑一致。 （2）要从“黑盒”的角度，设计 出充分并且必要的测试集，以保证设计和代码都能完全符合需求。
b) 具体的设计方法
(1) 等价类
i) 概念 依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过
ii) 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能；无效等价类：根据需求说明书，不满足需求的集合。
(2) 边界值
i) 概念 对输入或输出的边界值进行测试的一种黑盒测试方法
(3) 因果图
ii) 概念 直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。
iii) 适用场合 测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况
iv) 步骤 (1)分析所有可能的输入和可能的输出。 (2)找出输入与输出之间的对应关系。 (3)画出因果图。 (4)把因果图转换成判定表。 (5)把判定表对应到每一个测试用例
(4) 正交排列
i) 概念 根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合
ii) 正交表的性质 每一列中各数字出现的次数都一样多。 任何两列所构成的各有序数对出现的次数都一样多
iii) 步骤 1、有哪些因素（变量） 2、每个因素有哪几个水平（变量的取值） 3、选择一个合适的正交表4、把变量的值映射到表中5、把每一行的各因素水平的组合作为一个测试用例 6、加上你认为可疑且没有在表中出现的用例组合
(a) 正交表
行数(Runs)：正交表中的行的个数，即试验的次数,用N代表。 因素数(Factors)：正交表中列的个数，用C代表。 水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”，用T代表。 正交表的表示形式： L=行数(水平数 因素数) L=N(TC)
(5) 场景设计法
i) 概念 事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流
(6) 错误猜测法
i) 概念 基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例
D. 进阶篇
1. 
2. 按开发阶段划分
a) 单元测试(Unit Testing)
又叫模块测试
b) 集成测试(Integration Testing)
c) 系统测试(System Testing)
(1) 回归测试(Regression Testing)
i) 修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
(2) 冒烟测试（smoke testing）
i) 冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员
d) 验收测试(Acceptance Testing)
3. 按实施组织划分
a) α测试(Alpha Testing)
(1) 由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试
b) β测试(Beta Testing)
(2) 阿尔法测试与贝塔测试的区别 测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。 Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。 alpha测试先于beta测试执行。
c) 第三方测试
4. 按是否运行划分
a) 静态测试(Static testing)
(1) 指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。 对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错
(2) 检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册 静态质量：度量所依据的标准是ISO9126
b) 动态测试(Dynamic testing)
(1) 通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能
(2) 组成 构造测试用例、执行程序、分析程序的输出结果
5. 按是否手工划分
a) 手工测试(Manual testing)
(1) 手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤
(2) 优缺点 优点：自动化无法替代探索性测试、发散思维结果的测试 缺点：执行效率慢，量大易错
b) 自动化测试(Automation Testing)
(1) 在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程
(2) 步骤 1.完成功能测试，版本基本稳定 2.根据项目特性，选择适合项目的自动化工具，并搭建环境 3.提取手工测试的测试用例转化为自动化测试的用例 4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期 5.生成自动测试报告 6.持续改进，脚本优化。
6. 按是否查看代码划分
a) 黑盒测试(Black-box Testing)
也叫功能测试
(1) 把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据与输出数据
b) 白盒测试(White-box Testing)
也叫结构测试、逻辑驱动测试或基于代码测试
c) 灰盒测试(Gray-Box Testing)
(1) 不仅关注输出、输入的正确性，同时也关注程序内部的情况
7. 按测试地域划分
a) 国际化测试
b) 本地化测试
8. 按测试对像划分
a) 业务测试
(1) 测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程
b) 界面测试
简称UI测试
(1) 测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等
c) 容错性测试
(1) 检查软件在异常条件下自身是否具有防护性的措施或某种灾难性恢复的手段。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统
d) 文档测试
(1) 文档的术语 文档的正确性 文档的完整性 文档的一致性 文档的易用性
e) 兼容性测试
(1) 软件之间能否很好的运做，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃
(2) 测试点 平台测试 浏览器测试 软件本身能否向前或者向后兼容 测试软件能否与其它相关的软件兼容 数据兼容性测试
f) 易用性测试
g) 安装测试
h) 性能测试
(1) 对资源利用（如内存、处理机周期等）进行的精确度量 对执行间隔 日志事件（如中断，报错） 响应时间 吞吐量（TPS） 辅助存储区（例如缓冲区、工作区的大小等） 处理精度等进行的监测
i) 安全测试
(1) 对资源利用（如内存、处理机周期等）进行的精确度量 对执行间隔 日志事件（如中断，报错） 响应时间 吞吐量（TPS） 辅助存储区（例如缓冲区、工作区的大小等） 处理精度等进行的监测