软件测试概念篇

目录

1.软件测试

2.需求

2.1 用户需求

2.2 软件需求

2.3 测试人员眼里的需求

2.4 需求的重要性

3.测试用例

3.1 什么是测试用例

3.2 为什么有测试用例

4.BUG

4.1 BUG的概念

4.2 如何描述一个BUG

4.3 如何定义BUG的优先级

4.4 BUG的生命周期

5.软件生命周期

6. 软件开发模型

① 瀑布模型 (Waterfall Model)：往往适用于需求非常稳定的项目。

② 螺旋模型(Spiral Model)：大型项目，具有一些风险适用于螺旋模型。

③ 迭代、增量模型

④ 敏捷模型

7.软件测试模型

① 软件测试v模型

② 软件测试W模型

8.软件测试生命周期

 

---

1.软件测试

定义：软件测试就是一系列活动，这些活动是为了评估一个程序或者软件系统的特性或能力，并确定是否达到了预期的效果。

软件测试是一个过程，就是进行一个比较，拿着预期的结果和程序的执行结果作比较。

特点：软件测试只是一个样本试验，具有不可穷尽性。

---

2.需求

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

在大多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据 就是软件需求。

软件需求是测试人员进行测试工作的基本依据。

用户需求比较简答，软件需求越详细越好。

2.1 用户需求

可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须完成的任务。该需求一般比较简略。

2.2 软件需求

或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

2.3 测试人员眼里的需求

需求是测试人员开展软件测试工作的依据。

测试人员以“用户登陆”为例，来阐述下整个过程：

业务需求—>软件功能需求点—>测试需求点—>测试用例

2.4 需求的重要性

① 从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。

② 对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。

---

3.测试用例

3.1 什么是测试用例

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

3.2 为什么有测试用例

执行测试用例的时候，绝大部分的测试点都是参考测试用例执行的。

① 测试用例解决测试人员工作重复性的问题。

② 测试用例可以提高测试人员的效率。

③ 测试用例是自动化的基础。

---

4.BUG

4.1 BUG的概念

准确的来说：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。

当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能需求时，就是软件错误。

4.2 如何描述一个BUG

① 发现BUG的版本

② 问题出现的环境：PC电脑，手机，浏览器型号、版本

③ 错误重现的步骤：通过什么样的操作可以出现这个问题

④ 预期行为的描述：预期结果的描述

⑤ 错误行为的描述：执行结果的描述

⑥ 其他：bug标题，bug优先级

⑦ 不要把多个bug放到一起

4.3 如何定义BUG的优先级

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

① 崩溃(Blocker)：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错 误，主要功能丧失，基本模块缺失等问题。
② 严重(Critical)：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他 功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用 冲突，安全问题、稳定性等。
③ 一般(Major)：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
④ 次要(Minor)：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

4.4 BUG的生命周期

测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。

bug的不同状态：Start 与 End 不是流程里的状态，只是开始，结束标志。

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。

● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。

● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

● Rejected：如果认为不是Bug，则拒绝修改。

● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。

● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。

● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

无效的bug：open->closed open-rejected-closed

---

5.软件生命周期

软件的生命周期：软件从诞生到不能使用。

软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。

① 需求分析

测试人员产出需求文档(软件规格说明书)

开发人员判断需求是否合理，需求是否完整。

② 计划

软件开发让谁去做，软件什么时候开始开发，什么时候结束开发。

③ 设计

UI设计师：产出一个UI设计稿

开发人员：产出一个技术文档(接口，库表，缓存，mq...)

④ 编码

写代码实现需求

⑤ 测试

执行测试，提出BUG，验收BUG，发送测试报告。

⑥ 运行维护

上线、维护线上软件质量(当发现线上BUG，测试人员需要复现BUG，开发人员需要修复问题)

6. 软件开发模型

① 瀑布模型 (Waterfall Model)：往往适用于需求非常稳定的项目。

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一 次，因此是线性顺序进行的软件开发模式。

特点：每个阶段之间的关系是线性的。

优点：每一个阶段要做的工作非常的清楚。

缺点：产品效果出现的较晚。如果测试人员介入的太晚，以至于如果测试阶段发现问题，需要不断的向前回溯，如果需求出现问题，此时我们之前的工作(开发，测试)付之东流，需求需要重新设计。

② 螺旋模型(Spiral Model)：大型项目，具有一些风险适用于螺旋模型。

特点：每一次实施的时候都要进行风险分析。

优点：风险分析可以避免一些未知的问题。

缺点：风险分析错误，会导致一系列的损失。风险分析需要一定的成本。

③ 迭代、增量模型

例如淘宝：登录、注册、搜索、查看商品信息、支付……

迭代：先开发淘宝-登录大概框架，先开发淘宝-注册大概框架，先开发淘宝-搜索大概框架，查看，支付……

增量：先开发登录直到登录开发结束再去开发注册，注册开发结束在进行下一步……

增量：适用于模块和模块之间没有任何关系。

迭代：项目先看到雏形，然后再仔细开发最终实现项目。

④ 敏捷模型

敏捷宣言：

个体与交互重于过程和工具。

可用的软件重于完备的文档。

客户协作重于合同谈判

响应变化重于遵循计划

在每对比对中，后者并非全无价值，但我们更看重前者。

特点：重沟通，轻流程。重支付，轻文档。重协作，轻谈判。拥抱变化。

Scrume角色：

PO：产品经理，收集用户需求

SM：项目经理，对项目进行计划、对需求进行优先级排序。

Team：研究团队(开发---实现需求、测试---负责项目测试、设计师---产出交互设计稿)

Scrume具体流程：

7.软件测试模型

① 软件测试v模型

特点：线性的；左边是开发，右边是测试。

优点：将测试分为了好多种类型。每个阶段要做的工作非常明确。

缺点：测试介入的太晚，测试和开发是串行的。

② 软件测试W模型

 特点：开发一个V，测试一个V。

优点：测试人员尽早介入了需求。开发人员和测试人员并行的。

缺点：测试和开发相应来说也是串行的。不能拥抱变化，不能适用于敏捷。

8.软件测试生命周期

软件测试的生命周期：

需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估→维护上线。

每一个阶段测试人员做的工作

需求分析：分析需求正确性、完整性

测试计划：who(由谁测试)，when(何时开始测试、何时结束测试，测试点有哪些)

测试设计：编写测试用例、编写测试工具、测试用例评审

测试执行：执行测试用例，发现BUG，提交BUG，验收BUG...

测试评估：产出一个测试报告

运行维护：上线、维护线上软件质量(当发现线上BUG，测试人员需要复现BUG，开发人员需要修复问题)