[开发测试]软件测试基础知识

一、软件测试概述

1. 什么是软件测试？

定义：使用人工和自动手段来运行或测试某个系统的过程；目的在于验证它是否满足规定的需求，保证软件的质量，提高用户体验。

简而言之，软件测试就是验证软件的功能是否能够满足用户的需求

• 软件分为两大类：系统软件和应用软件

  • 系统软件：windowsxp windows98 windows2/203/vista linux unix …

  系统软件包括所有硬件驱动程序，使计算机的软件跟硬件结合

  • 应用软件：计算机用户为了解决某些问题而购买，开发或研制的各种程序或软件包，如app，qq，微信等

2. 软件测试的目的

1. 检验产品是否满足用户需求
2. 提高用户体验
3. 发现程序中存在的代码或业务逻辑的错误

3. 软件测试分类

3.1 按照测试阶段划分

1. 单元测试
2. 集成测试
3. 系统测试

3.2 按照是否覆盖源代码划分

1. 白盒测试：针对代码
2. 黑盒测试：针对功能、界面、易用性等
3. 灰盒测试：包含代码、界面、功能等

3.3 根据程序运行状态划分

1. 静态测试：根据需求文档，不运行程序（看界面、样式等）
2. 动态测试：运行程序去测试

3.4 其他划分

1. 回归测试：程序原来有问题，测试人员提交给开发后，开发人员对其进行更改，开发人员更改之后更新程序，测试再次检查该功能是否正常，并且此修改是否影响到了其他功能。
2. 冒烟测试：开发完程序后进行测试，测试基础功能，主要看主流程有没有问题，不针对细节进行测试
3. 随机测试：选取比较重要的功能模块进行测试
4. 验收测试：

• Alpha测试：内测版本，公司内部自己测试
• Beta测试：公测版本，把软件交给客户去测试
• γ测试：Gamma版本，软件版本正式发行的候选版本，还没有正式发型，即将发行，没有大量推广，只给少部分真实用户使用

5. 人工测试：手动测试
6. 自动化测试：交给机器去测试

4. 软件测试的工作流程

用户提出需求，产品经理整理需求文档，开展需求会议（开发人员、测试人员）讨论需求，开发人员设计开发设计计划，测试制定测试计划，开发人员利用代码实现功能，测试人员执行测试用例
当写完测试用例的时候，要进行用例评审，统一思维

5. 软件质量模型

5.1 软件产品质量六个属性

1. 功能性（适合性、准确性、互操作性、安全性、功能性的顺从性）
   能够满足明确和隐含需求的功能
2. 可靠性（成熟性、容错性、可恢复性、可靠性的顺从性）
   能够处理异常情况，在错误中很快恢复
3. 易用性（易理解性、易学性、易操作性、吸引性、易用性的依从性）
   易懂、易学、易用、好看漂亮
4. 效率（时间特性、资源利用率、效率的依从性）
   利用占用的资源提供适当的性能。通常效率就是指常说的产品性能
5. 可维护性（可分析性、可修改性、稳定性、可测试性、可维护性的依从性）
   产品客杯修改的能力
6. 可移植性（适应性、可安装性、共存性、易替换性、可移植性的依从性）
   软件产品从一中环境迁到另一种环境的能力

6. 软件开发过程模型

6.1 瀑布型模型

1. 线性模型的一种，在所有模型中占用重要地位，是所有其他模型的一个基础
2. 每一个阶段执行以此，按照线性顺序进行软件开发

• 测试切入点：
  测试阶段处于软件实现后，必须在代码完成后留出足够的时间给测试活动，否则将导致测试不充分，很多问题到项目后期才会暴露

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZlnCQiZ9-1633674685760)(Waterfall.png)]

• 优点

  • 开发的各个阶段比较清晰
  • 强调早期计划及需求调查
  • 适合需求稳定的产品开发

• 缺点

  • 依赖于早期的需求调查，不适应需求的变化
  • 单一流程不可逆
  • 风险往往延至后期才显露，失去及早纠正的机会
  • 问题在项目后期才开始暴露，前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败

6.2 V型模型

• 反映了测试活动与分析和设计的关系
• 表明了测试过程中本身不存在的阶段，从左到右，描述了开发过程和测试过程间的对应关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LFzyHumB-1633674685766)(V.png)]

1. 需求分析：用户需求、业务需求、需求规格说明书
2. 概要设计：系统架构、模块划分、模块与模块之间的接口
3. 详细设计：模块内部实现的逻辑和方法
4. 编码：实现上述设计
5. 单元测试：检测代码的开发是否符合详细设计的要求
6. 集成测试：检测此前测试过的各组成部分是否能完好地结合到一起
7. 系统测试：检测已集成在一起的产品是否符合系统规格说明书
8. 验收测试：检测产品是否符合最终用户的需求

包含底层和高层的测试
缺点是反复性大，如果需求变更比较大或者多，导致反复重复测试过程，降低效率

6.3 W模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QDnAHM81-1633674685768)(W.png)]

• 优点
  • 开发强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试
  • 更早地接入测试，可以发现开发初期的缺陷，可以用更加低的成本进行缺陷修复
  • 分阶段工作，便于控制项目过程
• 缺点
  • 依赖于软件开发和软件测试依然保持一前一后的线性关系，依然无法支持迭代、自发性和需求等变更调整
  • 对于当前很多项目，在执行的过程中根本不产生文档，那么W模型基本无法适用
  • 使用起来技术复杂度很高，对于需求和设计的测试要求很高，实践起来很困难

7. 测试用例

**定义：**测试用例（Test Case）是为特定的目的而设计的一组测试输入、执行条件和预期的结果，以便测试是否满足某个特定需求。通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的依据。

7.1 重要性：

1. 编写测试用例时，我们要思考产品需求的各个方面，这有助于我们梳理需求，及时发现需求的不合理之处，可以对需求提出更好的建议，并且这也会加深我们队需求的认识和印象
2. 编写测试用例时，可以方便以后我们有步骤有计划地进行测试，防止自己漏测
3. 通过测试用例，可以反映测试进度
4. 编写好的测试用例，可以方便我们在回归测试时，复查bug是否还会出

7.2 测试用例的编写：（8大要素）

1. 用例编号
2. 用例标题
3. 测试项目
4. 用例级别
5. 预置条件
6. 测试输入
7. 测试步骤
8. 预期结果

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3IHDHagy-1633674685773)(testcase.png)]

7.3 测试用例设计方法

1. 等价类划分法：

等价类划分就是把被测对象的输入域划分为若干个集合，对于某个集合中的某个元素和该集合中的人艺元素的表征一致，然后从每个划分的集合中去除少数的数据做为测试用例

• 有效等价类：对程序有意义的合理的数据
• 无效等价类：对程序无意义的不合理的数据
• eg：
  • 测试要求：测试qq账号，正确账号要求是6-10位正整数
  • 有效等价类：长度在6-10位的正整数
  • 无效等价累：
    1. 长度小于6
    2. 长度大于10
    3. 负数
    4. 小数
    5. 英文字母
    6. 中文
    7. 空格
    8. 特殊字符

2. 边界值法：

边界值分析法是对等价类划分法的补充，通常是和等价类划分法一起配合使用
与等价类划分法的区别：

1. 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件
2. 边界值分析法不仅考虑输入条件，还要考虑输出空间产生的测试情况
   eg:

• 微信红包：要求单个红包金额范围为：0.01-200
• 设计测试用例：
  • 等价类划分：
    • 有效等价类：0.01-200 选取一些有代表性的数据
    • 边界节：0.01, 0.02, 199.99, 200, 200.01 取边界值
    • 无效等价类：小于0.01, 大于200, 小数点超过两位数，输入中文

3. 场景法

场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程（如测试一个电商系统，先跑通主流程）
当获取测试任务后，先关注其主要功能和业务流程是否能够正确实现，这就需要使用场景法来完成测试。当业务流程或者说该软件的主要功能没有问题时，我们再重点从边界值、等价类等方面对控件进行更加细致、完整的测试。
冒烟测试主要使用场景法类进行测试
基于流程，测试主流程

4. 错误推测法

错误推测法主要利用**直觉、经验猜测可能出现的出错类型，有针对性地列举出程序中所有可能的错误和容易发生错误的情况，它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法
**基本思想：**列举处可能犯的错误或错误易发生的清单，然后根据清单编写测试用例；这种方法很大程度上是凭经验进行的，即凭人们对过去所做测试结果的分析，对所揭示缺陷的规律性作直觉的推测来发现缺陷。
错误推测法不单独使用，可以作为其他方法的补充。

二、软件缺陷信息

1. bug的定义

• 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误等各种问题
• 从产品外部看，软件缺陷是系统所需要实现的功能的失效或违背
• 软件缺陷是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求

2. bug产生的原因

软件缺陷的产生不可避免

• 用户需求定义本身存在问题
• 设计说明存在错误
• 编码说明、程序代码有错误
• 硬件或软件系统上存在错误
• 其他原因

3. bug产生的根源

• 交流不充分：客户与产品人员、开发人员与测试人员等
• 软件复杂性：功能复杂、开发复杂、测试复杂
• 开发人员的错误：对需求的理解、开发压力、能力与经验
• 需求的变化：需求说明书、设计文档、程序的变更
• 进度压力：项目周期太紧

4. bug的类型(禅道系统为例)

• 表面缺陷：
  1. 操作界面错误
  2. 打印内容、格式错误
  3. 删除操作未给出提示
  4. 长时间操作未给出提示
  5. 界面不规范
• 功能缺陷
  1. 功能无法实现
  2. 功能错误实现
• 数据缺陷
  1. 数据计算错误
  2. 数据约束错误
  3. 数据输入、输出错误
• 系统缺陷

5. bug严重程度

6. bug生命周期（重点）

bug生命周期就是从其被发现到其被关闭的过程

生命周期中缺陷状态：新建–>指派–>已解决–>待验–>关闭
中间状态：拒绝、延期等

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c2KjZxaH-1633674685778)(bug.png)]

发现bug–>提交bug–>指派bug–>研发确认bug–>研发修复bug–>回归验证bug–>是否通过验证–>关闭bug

6. 提交bug

禅道系统、jira等

7. 测试报告

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付大打下基础

7.1 测试报告的重要性

• 汇报近期测试工作
• 评估，根据测试结果评估软件质量
• 通过复盘思考之后如何改进工作

7.2 测试报告编写

• 软件测试工作完成之后编写测试报告
• 由测试负责人进行编写
• 主要内容：(通常有报告模板)
  1. 概述
  2. 测试经过
  3. 测试用例
  4. 软件缺陷
  5. 质量评估
  6. 改进建议