软件测试笔记

1 概述

什么是软件测试：（广义和狭义）

广义的概念：指软件生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段，以及完成开发后维护阶段的各类文档、代码的审查和确认

狭义概念：识别软件缺陷的过程，即实际结果与预期结果的不一致（编码后测试），传统的瀑布模型中软件测试仅处于运行维护阶段之前

软件测试通常包括验证(verification)和确认(validation)：

- 验证（正确性测试）：软件是否实现某一特定功能的一系列活动（是否和需求说明书流程一致）

- 确认（完整性测试）：有效性确认，软件是否真实满足了用户业务需求的一系列活动（是否功能完全覆盖。需求说明书本身可能出错，并且客观需要need（必须实现的）和主观需求request（可要可不要的）有所不同。）

- 如何平衡客户的需求，就是软件测试需求分析需要考虑的方面。

软件测试的原则

1. 所有测试的标准都是建立在用户需求之上的，测试的目的在于发现系统是否满足规定的需求；
2. “尽早地和不断地测试”，越早进行测试，缺陷的修复成本就会越低；
3. 程序员应避免检查自己的程序，由第三方进行测试更客观有效；
4. 穷举测试是不可能的；
5. 充分注意测试中的群集现象，一段程序中一发现的错误数越多，其中存在的错误概率越大，因此对发现错误较多的程序段，应进行更深入的测试；
6. 设计测试用例时应包括合理输入和不合理输入，以及各种边界条件、特殊情况下要制造极端状态和意外状态；
7. 注意回归测试的关联性，往往修改一个错误会引起更多错误；
8. 测试规模应从小到大，单元测试->系统测试；
9. 测试用例是设计出来，不是写出来的，应根据测试的目的，采用相应的方法设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性；
10. 重视并妥善保存一切测试过程文档（测试计划，测试用例，测试报告等）；

软件测试的规律

木桶原理

Bug的80-20原则

80-20原则

1.80% 的工程量用在 20% 的需求上 （关键需求 ）

2.80% 的开发成本花费在 20% 的部件上

3.80% 的错误是由 20% 的部件引起的

4.80% 的延期或返工是由 20% 的变更造成的

5.80% 的系统资源是由 20% 的部件消耗的

6.80% 的进度是由 20% 的人完成的

 

软件测试的重点

• 测试用例的良好设计
• 测试工作的管理
• 测试环境的建立：应该与实际测试环境一致

软件测试度量

测试覆盖率、缺陷发现率（数目和严重程度-致命/严重/轻微错误） 、测试成功率

软件测试的分类

 软件测试技术

 

软件测试流程

 

软件测试V模型

单元测试：一般是白盒，接口测试（进出的数据流正确性）、内部/全局数据结构、边界值、语句覆盖、路径覆盖

集成测试：不要一次性集成除非小规模，要增量集成

系统测试：功能需求、性能需求、其他需求（安全性、容错性、兼容性）

用户验收/确认测试：配置审查（文档资料检查）、Alpha测试（用户在开发者场所）、Beta测试（用户在用户场所）

回归测试：修改缺陷、添加新功能后，测试全部用例/基于风险选择测试

软件测试过程

– 拟定软件测试计划、方案

– 设计和生成 测试用例 、准备 测试数据

– 执行测试，记录原始数据，对缺陷进行管理

– 生成软件测试报告、缺陷的统计和报表