软件测试开发学习笔记-软件测试基础

一、软件测试基础

1.软件测试的定义：

        使用技术手段验证软件是否满足使用需求。目的是减少软件缺陷，保障软件质量。

2.软件测试分类：

(1) 按测试阶段划分：

        ① 单元测试：针对程序源代码进行测试；

        ② 集成测试：又称接口测试，针对程序接口进行测试；

        ③ 系统测试：针对程序功能和非功能进行测试；

        ④ 验收测试：主要分为内测、公测，使用不同用户来发掘项目缺陷。

(2) 按代码可见度划分：

        ① 黑盒测试：不关注源代码，针对程序UI功能进行测试（系统测试）；

        ② 灰盒测试：针对程序部分代码进行测试（集成测试）；

        ③ 白盒测试：针对程序源代码进行测试（单元测试）。

还划分为：

        ① 功能测试：主要验证程序的功能是否满足需求；

        ② 自动化测试：使用代码和工具代替手工，对项目进行测试；

        ③ 接口测试：使用代码或工具对服务端提供的接口进行测试；

        ④ 性能测试：模拟多人使用软件，查找服务器缺陷。

3.质量模型的重点五项：

        功能、性能、兼容、易用、安全

        除此之外，还包括可靠性、可移植性、可维护性。

4.测试流程的六个步骤：

      ①  需求评审：确保各部门需求理解一致；

       ② 计划编写：测什么、谁来测、怎么测；

       ③ 用例设计：验证项目是否符合需求的操作文档；

       ④ 用例执行：项目模块开发完成开始执行用例文档实施测试；

       ⑤ 缺陷管理：对缺陷进行管理的过程；

       ⑥ 测试报告：实施测试结果文档。

5.测试模板八个要素：

        ① 用例编号：项目_模块_编号

        ② 用例标题：预期结果（测试点）

        ③ 项目/模块：所属项目或模块

        ④ 优先级：表示用例的重要程度或者影响力P0~P4（P0最高）

        ⑤ 前置条件：要执行此条用例，有哪些前置操作

        ⑥ 测试步骤：描述操作步骤

        ⑦ 测试数据：操作的数据，没有的话可以为空

        ⑧ 预期结果：期望达到的结果

二、测试设计

1.对穷举场景设计测试用例

1.1 等价类划分法：

        说明：在所有测试数据中，具有某种共同特征的数据集合进行划分

        分类：有效等价类：满足需求的数据集合；无效等价类：不满足需求的数据集合

        步骤：① 明确需求；② 明确有效和无效等价类；③ 提取数据，编写测试用例。

        重点：有效等价和单个无效等价各取1个即可；

                   正向：一条用例尽可能覆盖多条；逆向：每一条都是一个单独用例。

1.2 适用场景：

        针对：需要有大量数据测试输入，但是没法穷举测试的地方

                ① 输入框、②下拉列表、③单选复选框

        典型代表：页面的输入框类测试。

2.对限定边界规则设计测试点

2.1边界值分析法

        说明：使用边界值解决边界位数限制问题

2.1.1 边界范围节点

       选取正好等于、刚好大于、刚好小于边界的值作为测试数据

•                上点：边界上的点（正好等于）

               离点：距离上点最近的点（刚好大于、刚好小于）

               内点：范围内的点（区间范围内的数据）

       提示：

                ① 有关范围限制，最多7条用例（暂时未优化）

                ② 边界值能解决位数限制问题，但是不能解决类型问题（要结合等价类）

2.2 步骤：

              ① 明确需求

              ② 确定有效和无效等价类

              ③ 确定边界范围值

              ④  提取数据编写测试用例

2.3 案例优化：

        结论：7个优化为5个点

                上点：必选（不考虑区间开闭）

                内点：必选（建议选择中间范围）

                离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

2.5 使用场景

       1.在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）

       2.常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语

       3.典型代表：有边界范围的输入框类测试

       强调：单个输入框，常用的方式： 边界+等价类

3.对多条件依赖关系进行设计测试点

3.1判定表法

       3.1.1说明：

等价类边界值分析法主要关注单个输入类条件的测试

              并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试

       3.1.2判定表定义及组成部分

              定义：是一种以表格形式表达多条件逻辑判断的工具

              组成：

• 条件桩：列出问题中的所有条件，列出条件的次序无关紧要
• 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
• 条件项：列出条件对应的取值，所有可能情况下的真假值。
• 动作项：列出条件项的、各种取值情况下应该采取的动作结果。

   规则：

•         判定表中贯穿条件项和动作项的一列就是一条规则
  • 假设有n个条件，每个条件的取值有两个（0，1），全组合有2^n中规则

3.2步骤

       1.明确需求

       2.画出判定表

              1）列出条件桩和动作桩

              2）填写条件项，对条件进行全组合

              3）根据条件项的组合确定动作项

              4）简化、合并相似规则（有相同的动作）

       3.根据规则编写测试用例

3.3使用场景

       有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系

       判定表一般适用于条件组合数量较少的情况（比如4个条件以下）

提示：

1. 多条件之间有依赖关系，使用判定表来进行测试覆盖；
2. 判定表一般适合4个以内条件依赖关系
3. 如果条件超过4个，就不适合覆盖所有条件，应采用（正交法）来解决

4.对于项目业务进行设计测试点

重点：

1.覆盖业务测试，需要使用流程图法

2.先测试业务，在测试单功能、单模块、单业务

4.1场景法

说明：场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例

意义：

用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用

测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

5.错误推荐法

5.1 定义：通过经验推测系统可能出现的问题

       思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷

5.2 场景：

1. 时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试
2. 实践宽裕通过该方法列出之前出现问题较多的模块再次测试

三、缺陷管理

1.缺陷的定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug

2.缺陷的评定标准：

        ① 软件未实现需求（规格）说明书中明确要求的功能-少功能

        ② 软件出现了需求（规格）说明书中指明不应该出现的错误-功能错误

        ③ 软件实现的功能超出需求（规格）说明书指明的范围-多功能

        ④  软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求-隐性功能错误

        ⑤ 软件难以理解，不易使用，运行缓慢，用户体验不好-不易使用

3.缺陷产生的原因：

        ① 需求阶段：需求描述不易理解，有歧义、错误等；

        ② 设计阶段：设计文档存在错误或者缺陷；

        ③ 编码阶段：代码出现错误；

        ④  运行阶段：软硬件系统本身故障导致软件缺陷。

4.软件缺陷的生命周期

5.软件缺陷的核心内容

        缺陷标题：描述缺陷的核心问题

        缺陷的预置条件：缺陷产生的前提

        缺陷的复现步骤：复现缺陷的过程

        缺陷的预期结果：希望得到的结果

        缺陷的实际结果：实际得到的结果

        缺陷的必要条件：图片、日志等信息（证据）

回归测试：

        常规项目回归：项目本次发布新增2个模块，最基本要新增模块功能及新增模块关联的旧模块。

        非常规项目（银行、部队、航天）：新增功能，必须全部复测

回归bug：上一个版本发现的缺陷，开发修复完毕，在下一个版本进行重新验证。

6. 缺陷提交要素

缺陷报告编号：缺陷的唯一性标志

严重程度：

        严重（s1）：主功能

        一般（s2）：次要功能

        微小（s3）：易用性，界面

        建议（s4）：建议性问题    

缺陷优先级：

        Priority0：24小时内解决

        Priority1：发布前必须修复

        Priority2：可以在下一个版本中修复

Bug类型：代码错误、兼容性问题、设计缺陷、性能问题

缺陷状态：

       New：新建

       Open：打开

       Closed：关闭

Postponed：延期

7.软件缺陷类型：

        功能错误，界面（UI）错误，兼容性错误，数据错误，易用性、建议、架构

8.缺陷编写

8.1缺陷报告示例

8.2提交缺陷注意事项

        可重现、规范性、唯一性

        面试题：发现缺陷后，首先会怎么办？--确定bug可复现，确定是bug

        提交时，要检查缺陷是否存在

8.3缺陷管理工具

        1.项目管理工具-管理缺陷（禅道、JIRA、TFS）

        2.Excel管理缺陷