系列文章目录
第一节 软件测试概念
第二节
提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档
第一节 软件测试概念
一、软件测试定义
软件测试是指使用人工或自动手段来测试某个软件系统的过程，其目的在于检验是否满足需求或找出预期结果与实际结果的差别。
二、测试必备概念
1.软件生命周期
计划：确定开发目标、完成项目的可行性研究、对项目进度进行预估和安排、制定实施计划。
需求分析：分析整理项目的需求项、根据需求项编写需求规格说明书（SRS）、制作产品原型。
设计：完成项目概要设计、完成项目详细设计。
编码：完成代码编写。
测试：单元测试（对程序的最小单元进行测试，最小单元：某个函数或类）、集成测试（对模块与模块之间的调用接口进行测试）、系统测试（包括系统的性能和功能）、验收测试。
运维：产品部署、运行维护、功能升级、性能提升。
2.常见的测试模型
传统的瀑布模型：缺点：测试太靠后，难以回溯，修改成本非常大。
V模型：将测试过程细化成四个阶段，但仍然测试后置，未解决风险问题。
W模型：将测试和开发过程分离出来，对整个项目过程中的需求文档、设计文档同样测试，将测试前置，降低整个项目的质量风险。
敏捷测试模型：应用最广泛。
特点：主要为了适用公司的“短频快”的开发节奏。
3.软件质量模型
定义：基于ISO25000和GB/T25000制定的可用于测量产品质量的模型，该模块提供了从不同维度考量产品质量属性的依据。
质量模型规定的各个不同质量属性和不同的测试类型之间具有映射关系，所以可以用不同的测量类型来测试不同的质量属性。
3.1 软件质量模型属性
-
功能性
-
适应性：为指定的任务或用户提供一组合适的功能的能力
-
准确性：提供所需精确度或相符的结果或效果的能力
-
互操作性：与一个或多个规定系统交互的能力
-
保密安全性：保护信息或数据的能力
-
功能性的依从性：遵守与功能性相关的标准、阅读、法规以及类似规定的能力
-
-
可靠性
-
成熟性：为避免由软件中错误导致失效的能力
-
容错性：出现故障时维持规定的性能级别的能力
-
易恢复性：失效发生时重建规定的性能级别并恢复受直接影响的数据的能力
-
可靠性的依从性：遵守与可靠性相关的标准、约定、法规的能力
-
-
易用性
-
易理解性：使用户理解软件是否合适以及如何将软件用于特定的任务和使用环境的能力
-
易学性：使用户能学习软件怎么用的能力
-
易操作性：是用户能操作和控制软件的能力
-
吸引性：吸引用户的能力
-
易用性的依从性：遵守与易用性相关的标准、约定、法规的能力
-
-
效率
- 时间特性：规定条件下，执行功能时提供适当的响应、处理时间、吞吐率的能力
- 资源利用性：规定条件下、执行功能时使用合适的资源数量和类别的能力
- 效率依从性：遵守与效率相关的标准、约定的能力
-
维护性
-
易分析性：诊断软件中的缺陷、失效原因、待修改部分的能力
-
易改变性：指定的修改可以被实现的能力
-
稳定性：避免由于软件修改造成意外结果的能力
-
易测试性：修改部分能被确认的能力
-
维护性的依从性：遵守与维护性相关的标准、约定的能力
-
-
可移植性
-
适应性：适用不同的指定环境的能力
-
易安装性：在指定环境中被安装的能力
-
共存性：公共环境中和其他独立软件共存的能力
-
易替换性：同样环境下，替换另一个相同用途的指定软件的能力
-
可移植性的依从性：遵守可移植性相关的标准、约定的能力
-
转载：https://blog.csdn.net/z0y00000/article/details/84881877
例子： 如何测试一个水杯？
3.2 常见测试类型与质量属性关系表
| 名称 | 说明 | 对应的质量属性 |
|---|---|---|
| 功能测试 | 验证产品是否满足用户特定功能要求并作出正确响应 | 功能性 |
| 安全性测试 | 验证产品是否有保护数据的能力，并能在合适的范围内承受恶意攻击 | 功能性 |
| 兼容性测试 | 验证产品是否能够和其他相关产品顺利对接 | 功能性 |
| 配置测试 | 验证产品是否能够在推荐配置上流畅运行；验证产品为了完成特定功能的输入是否会出现故障 | 功能性、易用性 |
| 可靠性测试 | 验证产品在长时间运行下能否满足保证系统的性能水平；在存在异常的情况下系统是否依然可靠 | 可靠性 |
| 易用性测试 | 验证产品是否易于理解、易于学习和易于操作 | 易用性 |
| 性能测试 | 测试产品提供某项功能时的时间和资源使用情况 | 效率 |
| 安装测试 | 测试产品能否被正确安装并运行 | 可移植性 |
</tbody>
</table>
| 测试阶段不同 | 代码是否可见 | 执行手段不同 | 测试目的不同 | 其他测试类型 |
|---|---|---|---|---|
| 单元测试、集成测试、系统测试、验收测试 | 黑盒测试、白盒测试、灰盒测试 | 手工测试、自动化测试 | GUI测试、接口测试、性能测试 | 回归测试、冒烟测试、探索性测试 |
4.测试阶段主要文档
测试计划和方案：
测试用例：（重要）
缺陷报告：（重要）
测试报告：（重要）
三、测试流程
分析：需求评审、测试需求分析
计划：测试计划和方案文档编写
设计：测试用例设计
实现：编写测试用例、测试脚本等
执行：搭建测试环境、执行测试脚本、报告缺陷。
1.需求评审
1.1需求来源
合同型项目（外包、有甲乙方）
- 用户业务需求—>产品需求
产品型项目（没有明确的用户）
-
协议/标准/规范
-
继承性需求
-
竞品分析
1.2需求评审检查表
2.测试需求分析
2.1做测试需求分析的理由
- 了解要测试的系统是干什么的
- 理解系统有哪些特点
- 知道系统有那些功能
- 知道系统的业务流程
- 系统在某个版本上，那些需要测试，那些不需要
- 系统对性能、安全性上有没有什么需求
2.2 测试需求分析流程
- 根据产品需求提取系统的测试点
- 编写需求跟踪矩阵
- 根据测试点利用适当的测试用例设计方法设计测试用例
2.2.1 测试设计与测试用例
测试设计：将测试点转化为测试用例的过程
测试用例：一种用来说明具体如何进行测试操作并验证结果的文档
测试用例模板：