软件测试必备知识

news2025/1/6 18:44:58

一、软件测试的基本概念

①需求

IEEE规定：软件需求是（1）用户解决问题或达到目标所需条件或权能。（2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。一种反应上面（1）或（2）所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。

在多数软件公司，会有两部分需求：用户需求和软件需求。

用户需求：可简单理解为甲方或者终端用户提出的需求，该需求一般比较简略。

软件需求：又叫功能需求，该需求会详细描述开发人员必须实现的软件功能，大多数情况下软件需求将作为测试和开发的工作依据。

软件需求分析点：

技术角度分析：技术上是否可行，人力/资金投入成本
是否存在较大的市场需求
成本和受益的占比

②测试用例

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

测试用例解决了测什么和怎么测这两大问题。

③Bug

1️⃣当且仅当产品规格说明书存在且正确时，程序的实现与规格说明书要求不匹配的时候，那就是软件错误。
2️⃣当产品规格说明书没有提到某功能时，以用户为准，也就是说，当程序没有实现其用户合理预期的要求是，那就是软件错误。

④产品的生命周期：

需求分析

市场分析、投入和受益的占比、技术上实现是否可行

计划

什么时候开始？什么时候结束？

设计

将一个大的需求拆分成一个个具体课实施的任务。（设计哪些接口，采用什么框架，采用哪些技术。）

编码

开发人员参考需求文档和技术文档等资料来进行代码开发

测试

测试人员参考测试用例来设计测试。

运行维护

修复性维护：对项目中没有发现的问题要及时进行修复

完善性维护：对功能进行完善

预防性维护（居安思危）：为了避免产品在线上运行期间出现意想不到的问题，需要进行一些预防的手段。

⑤软件测试的生命周期

需求分析

测试人员需要站在用户角度思考问题：软件需求是否合理？
技术角度思考问题：技术上是否可行？是否还有优化空间？
测试的角度思考问题：是否存在业务逻辑冗余/冲突

测试计划

什么时候开始测试，什么时候测试结束，耗时多久。

测试设计与开发

写测试文档，明确标注使用到的测试方法、测试工具、测试形式等。参考需求文档、技术文档等编写测试用例。

测试执行

充分利用测试用例和其他工具对项目尽可能做到全方位的测试。

测试评估

评估产品是否存在其他的质量问题以及功能演示。

二、开发模型和测试模型

1、瀑布模型

使用场景：需求固定的小项目。

特点：线性结构，每个阶段只执行一次，是其他模型的基础框架。

缺点：

1.测试后置：1）前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会。2）必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷暴露给用户（产品质量差
2.周期太长，产品很迟才能被看到和使用。

螺旋模型

使用场景：规模庞大、复杂度高、风险大的项目。

特点：螺旋模型中增加了风险分析和原型

缺点：

1.项目中可能存在的风险性与风险分析人员的技能水平有直接关系。
2.需要人员、资金、时间的增加和投入，可能会导致项目的成本太高。

3、迭代模型和增量模型

假设一个软件，共有 A、B、C、D、E 五个功能

增量模型：可以先开发A、B需求，然后再开发C、D、E

迭代模型：先将A、B、C、D、E功能开发出来，然后不断进行完善。

4.敏捷模型

scrum模型

特点：轻流程、轻文档、中目标、重产出。

三个角色和五个重要会议

三个角色：产品经理、项目经理、研发团队
五个会议：
发布计划会议：最终确定本次迭代要完成的需求。
迭代计划会议：任务拆解、确定责任人、工时的评估。
每日会议：昨天做了什么、今天要做什么、当前遇到的问题。（每日会议结束后需要给出“可交付的软件”）
演示会议：产出用户需求。
回顾会议：总结当前迭代周期的不足，并在下一次迭代中进行优化。