【软件测试】测试常见知识点汇总

这里目录的内容看起来有点多，但其实只是作为一个思维导图的作用，文内内容比较精简，但基本是按照理解分析的，各位读者可以作为借鉴参考一下，文内若有理解错误的地方欢迎指出。

一、什么是测试

• 测试是测试人员验证软件特性是否符合需求的过程

1.1 测试和调试的区别

• 1、目的：测试的目的是找问题，调试的目的是找到并解决问题。
• 2、人员：测试由专门的测试人员完成，调试由开发人员完成。
• 3、结果：测试从已知条件开始，使用预定义的过程，并且有预期结果；而调试条件未知，结果不可 预知。
• 4、过程：测试可以预先计划，可以制订测试用例和计划，进度可以度量；调试没有计划，进度也不可以度量。
• 5、阶段：测试贯穿于软件生命周期的整个阶段；调试只在编码阶段进行

1.2 什么是需求

1.2.1 用户需求

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

1.2.2 软件需求

详细描述开发人员必须实现的软件功能，软件需求是测试人员进行测试工作的基本依据。

1.3 测试用例要素

通用测试用例八要素：

1、用例编号；

• 一般是数字和字符组合成的字符串，可以包括（下划线、单词缩写、数字等等），但是需要注意的是，尽量不要写汉语拼音，因为拼音的意义可能有好几种，有可能会导致乱码；
• 用例编号具有唯一性和易识别性。

2、测试项目；

• 测试项目对应的就是测试用例中的子项名。

• （1）系统测试用例：对应一个功能点（功能测试）、性能指标（性能测试）、界面中控件（GUI测试）等等。
• （2）集成测试用例：对应集成后的模块功能或者接口功能。
• （3）单元测试用例：对应函数名。

3、测试标题；

• 测试标题考虑的是如何来完成测试项目，或者说从哪个角度来对测试项目进行测试，有的公司也取名为测试目的。
• 测试标题一定要简单、概要；体现测试的出发点和关注点。

4、重要级别；

• 用例的重要级别一般分成三个级别：高、中、低。
• 高级别：对应保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例；
• 中级别：对应重要程度介于高和低之间的测试用例；
• 低级别：对应实际使用频率不高，对系统业务功能影响比较大的模块或功能的测试用例。

5、预置条件；

• 测试用例在执行前需要满足一些前提条件，否则测试用例是无法执行的，这些前提条件就是预置条件。

6、测试输入；

• 用例执行过程中需要加工的外部信息，根据软件测试用例的具体情况，有手工输入、文件、数据库记录等。
• 禁止过多描述性语言，若为文件，会有提示选择路径，最好写具体，让别人易懂易操作。

7、操作步骤；

• 明确描述测试执行过程中具体的操作步骤，以方便测试执行人员可以根据该操作步骤完成测试用例执行。

8、预期输出

• 预期输出是测试用例中非常重要的一部分，预期输出可以检验被测对象是否正常工作，如果我们的预期输出写的不完整不全面，整个测试用例就会受到影响。

• 具体可参考 https://blog.csdn.net/weixin_44015669/article/details/121082810

1.4 软件的生命周期及各阶段概述

• 需求 —> 计划 —> 编码 —> 测试 —> 上线 —> 维护

需求：确定软件要做成什么样

计划：确定软件什么时候开发，什么时候开始测试，什么时候结束开发，什么时候结束测试

编码：通过软件需求实现软件特性

测试：测试人员测试软件是否有缺陷

上线：将项目推上上线环境，让用户可以访问到

维护：项目如果在线上出现问题，此时测试人员、开发人员定位问题、解决问题，项目还需要优化，测试人员，开发人员需要对项目不断地优化。

1.5 开发模型和测试模型（记住特点和适用场景）

1.5.1 开发模型

1.5.1.1 瀑布模型（自上而下、相互衔接的固定顺序）

特点： 线性的，测试参与时机太靠后，不能尽早发现问题

适用项目： 适用于小型项目，项目迭代周期非常短，比如项目周期1天或者0.5天

1.5.1.2 螺旋模型

特点： 每个阶段开始之前都有一个风险分析，可以避免一定的风险，但是风险分析需要一定的投入，如果分析错了，会带来一定的损失，同时不断地迭代，有可能导致项目延期

适用场景： 比较复杂，风险比较大的项目

1.5.1.3 增量模型和迭代模型

• 增量模型，一个模块开发完毕，再开发下一个模块
• 迭代模型，所有模块一起开发，先开发大的框架，再开发细节

1.5.1.4 敏捷模型

Scrum三个重要角色和五个重要会议:

• 角色：

• 产品经理（PO）：收集需求，来自客服反馈，来自用户
• 项目经理（SM）：需要进行需求优先级确定，项目计划确定
• 研发团队（ team）：不光包含开发，还包含测试，UI

• 会议：

• 发布计划会议：产品经理（PO）负责讲解user story，SM项目经理对其进行估算和排序，发布计划会议的产出，就是制定出这一期送代要完成的story列表，sprint backlog.
• 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计
• 每日站会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题
• 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story
• 回顾会议：项目团队对本明迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果

特点：

• 个体与交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划
• 在每次比对中，后者并非全无价值，但我们更看重前者

1.5.2 测试模型

1.5.2.1 V模型

特点： 左边是开发，右边是测试，测试介入太晚，发现问题时机就会越晚，测试和开发是串行的

1.5.2.2 W模型 / 双V模型

特点: 第一个是开发，第二个V是测试，测试在刚开始就介入了整个项目，测试是对整个项目的每个阶段进行了测试，但是测试，开发还是串行的，所以不能拥抱变化

二、测试基础（部分）

2.1 什么是Bug

• 1）当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
  
• 2）当需求规格说明书没有提到的功能，判断标准以最终用户为准： 当程序没有实现其最终用户合理预期的 功能要求时，就是软件错误。
  

BUG可以理解为：

（1）在软件开发的生命周期中可能导致软件产品出现问题的程序缺陷。

（2）产品说明书中规定要做的事情，而软件没有实现。

（3）产品说明书中没有提到过的事情，而软件确实现了。

（4）产品说明书中没有提到但是必须要做的事情，软件却没有实现。

（5）软件很难理解，很难使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。

2.2 Bug描述

1.概 述：用一句话简要描述Bug的现象。需要包括bug所在的模块及出错点

前置条件： 产生bug需要的前提（必要时填写）

2.步 骤：使用数字编号的形式，相对详细阐述出现Bug的操作步骤，需保证使用这样的叙述其他人便可重现bug，必要时需要描述bug产生的前提和条件。

3.预 期：填写上述操作过程应该输出的正确结果。

4.结 果：用文字准确描述出Bug引起的结果及现象，必要时需要有图形附件用拷屏方式将错误信息添加进来。

5.结果分析：bug修改完毕后，简要描述此Bug产生的原因。

2.3 Bug等级

• 大概有崩溃、严重、一般、次要
  具体可参考：https://zhuanlan.zhihu.com/p/103637796

2.4 Bug的生命周期

三、测试用例

3.1 测试用例的基本要素

• 如上文1.3所述

3.2 设计测试用例的万能思路

• 功能，兼容，界面，易用，性能，安全，网络，安装测试，卸载测试
  
• 参考如下登录页面的测试用例：
  

3.3 基于需求设计测试用例

• 可参考水杯测试用例（运用万能公式）

3.4 具体的设计方法

等价类、边界值、判定表、正交法、场景法、错误猜测法等

3.5 测试分类

3.5.1 按照测试对象划分

• 界面容错可靠兼容文档易用安装卸载安全性能内存泄漏

3.5.2 是否查看代码

• 白盒测试：白盒测试又称为结构测试或逻辑驱动测试，它是把测试对象看成一个透明的盒子，它允许测试人员利用程序内部的逻辑结构设计测试用例，对程序所有逻辑路径进行测试。（具体可参考https://blog.csdn.net/qq_42944594/article/details/121907540）
• 黑盒测试：在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试人员进行直接测试，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果等，检查相应的文档是否采用了正确的模板、是否满足规范需求。（具体可参考https://blog.csdn.net/yeuteyietir/article/details/93522978）

3.5.3 开发阶段

• 单元测试、集成测试、系统测试、验收测试（具体可参考https://blog.csdn.net/ty6693/article/details/89215677）

3.5.4 实施组织

• α测试和β测试：
• 区别：
• 它们都是验收测试！
  α测试是指把用户请到开发方的场所来测试
  β测试是指在一个或多个用户的场所进行的测试。
  α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
  β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。
  α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长

3.5.5 是否运行代码

• 静态测试、动态测试

1、测试部分的不同

静态测试是指测试不运行的部分：只是检查和审阅,如规范测试、软件模型测试、文档测试等。动态测试是通常意义上的测试，也就是运行和使用软件。

2、测试方式不同

静态测试，通过评审文档、阅读代码等方式测试软件称为静态测试，通过运行程序测试软件称为动态测试。

3、测试方法不同

静态测试是指不用执行程序的测试，它主要采取方案—代码走查、技术评审、代码审查的方法对软件产品进行测试。动态测试主要通过构造测试实例、执行程序、分析程序的输出结果这三种方法来对软件进行测试。

3.5.6 是否手工

• 手工测试

• 手工测试是一种软件测试的类型，其中测试人员无需使用任何自动化工具即可手动执行测试用例。手工测试的目的是识别软件应用程序中的错误、问题和缺陷。手工软件测试是所有测试类型中最原始的技术，它有助于发现软件应用程序中的关键缺陷。
• 任何新应用程序都必须先进行手工测试，然后才能使其测试自动化。手工软件测试需要更多的精力，但对于检查自动化的可行性是必需的。手工测试概念不需要任何测试工具的知识。软件测试基础之一是“不可能实现100％自动化”。这使得手工测试势在必行。

• 自动化测试

• 使用一种自动化测试工具来验证各种软件测试的需求，它包括测试活动的管理与实施、测试脚本的开发与执行。
• 自动化测试只是测试工作的一部分，是对手工测试的一种补充; 自动化测试绝不能代替手工测试;多数情况下，手工测试和自动化测试应该相结合，以最有效的方法来完成测试任务。

3.5.7 跨地域

• 国际化测试
• 本地测试
• 国际化：货币格式、语言、页面布局、时间、日期、流行的设备