测试基础

1.软件测试的概念

软件测试（Software testing）:是一种实际输出与预期输出间的审核或者比较过程。

经典定义：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

IEEE定义（1983）：使用人工或自动的手段来运行或测定某个软件系统的过程，目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别

2.测试的目的

测试是为了发现程序中的错误而执行程序的过程
好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案
成功的测试是发现了至今为止尚未发现的错误的测试
测试并不仅仅是为了找出错误，通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进
这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性
没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法
另外，根据测试目的的不同，还有回归测试（bug回归、版本迭代回归）、冒烟测试（主要功能或者流程跑一边）、压力测试、性能测试等，分别为了检验修改或优化过程是否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等

3.软件测试的七大原则：（重点）

原则一：测试可以显示缺陷（BUG）的存在
原则二：穷尽测试是不可能的
原则三：测试应该要尽早介入
原则四：缺陷的集群效应，即测试对象中发现的80%的缺陷来自20%的模块
原则五：杀虫剂悖论，即同样的测试用例被重复执行多次，将不能发现新的缺陷
原则六：测试活动依赖于测试对象的背景
原则七：不存在缺陷并不代表是有用的系统

4.测试结束标准

符合客户的需求（满足需求文档的要求）
1，2，3级的BUG都已经全部解决了
测试用例100%都执行了
测试文档都完成了

常见的开发模型（了解）
在这里插入图片描述

敏捷开发

在这里插入图片描述

5.软件测试的分类

按测试执行阶段划分：单元测试（单元测试属于白盒测试的一种）、集成测试（集成测试属于灰盒测试的一种）、系统测试、验收测试（正式验收测试、Alpha测试、Beta测试）
- 单元测试：对软件中的最小可测试单元（函数、类、方法）进行检验
- 集成测试：组件测试或接口测试（内部接口测试、第三方接口测试）
  - 集成测试中所使用的对象应该是已经经过单元测试的软件单元
  - 把两个已经测试过的单元组合成一个组件，测试它们之间的接口
- 系统测试：是针对整个产品系统进行的测试（软件、硬件、外设、网络等其他元素结合）
  - 分类：功能测试、健壮性测试、安全测试、性能测试、安装测试…
- 验收测试：是部署软件之间的最后一个测试操作
  - Alpha阿尔法测试：α测试在开发环境下，先于β测试；是对一个早期的、不稳定的软件版本所进行的验收测试
  - Beta贝塔测试：β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试；不能有程序员或测试员完成；是对一个晚期的、更加稳定的软件版本所进行的验收测试
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vatnwxN0-1647517758135)(images/image-20220304094901279.png)]
按测试技术划分：白盒测试、黑盒测试、灰盒测试
- 白盒测试：对代码的测试（函数、方法），一般来说很少专门进行白盒测试
- 灰盒测试：测试接口
- 黑盒测试：对应系统测试，不关注于代码层面的
按测试对象是否运行划分：动态测试、静态测试（文档检查、代码走查、界面检查）
按不同的测试手段划分：手工测试、自动化测试
按测试包含的内容划分：功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试、压力测试、负载测试、恢复测试
其他测试：冒烟测试、回归测试、探索性测试/自由测试（测试思维）

6.软件开发&测试流程

软件开发流程

项目计划：可行性分析（经济可行性、技术可行性、社会背景可行性等）

需求分析：根据功能收集需求，出说明文档

概要设计：设计软件总体的结构，有哪些子系统、角色

详细设计：详细设计软件的各个子系统功能

编码：开发人员

测试：测试人员（根据需求文档编写测试计划、测试用例、测试总结）

发布：发布软件、说明文档

运维：软件维护

测试流程

制定测试计划与测试方案：对要测试的产品进行分析，制定测试计划，由组长制定
- 测试目的
- 测试范围：要测的功能模块
- 测试策略：要用到测试的方法
- 测试人员、时间安排
- 风险和意外的处理
测试需求分析：
- 针对需求分析测试功能点
- 分析模块和模块或者功能和功能之间业务联系
测试设计阶段(用例编写、用例评审)
测试执行阶段：搭建环境、执行测试
测试总结

测试报告
1. 测试过程
2. 测试情况分析
3. 测试BUG统计分析
4. 测试BUG记录
5. 遗留问题清单
6. 评估结果
7. 改进建议

你们公司的测试流程？各个阶段有哪些产物（面试）

【参考答案】
我们首先会召开需求分析会议，参加人员有产品、开发和测试，主要是探讨需求主要的一些功能点，完了之后，开发就排期进行开发，我们测试会按照测试主管写的测试计划进行任务分配。先会参考需求规格说明书及原型图提取出要测得功能点，然后写测试用例，写完之后会进行用例评审，用例评审以后要修改的就修改整理形成最终的用例版本，之后开发人员版本编译完成后，我们会先进行冒烟测试，如果冒烟测试不通过，直接返回给开发进行修改。冒烟测试通过，依据测试用例进行系统测试，测试过程中，提交bug，跟踪bug，进行回归测试直至不存在严重bug，满足用户需求，测试完后编写测试报告，发布上线后，关注软件是否正常运行。

7.测试用例

BUG划分(重点)：

致命的 --系统无法使用
严重的 --系统里面主要或者核心的功能无法使用
一般的 --一般的功能无法使用
轻微的 --显示、提示信息，不影响客户使用

测试用例定义

为了某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求

目的是能够将软件测试的行为转化成可管理的模式

为什么要编写测试用例

避免测试点的遗漏
可以提高测试效率
便于重复测试
便于团队交流
便于统计跟踪

测试用例八要素（重点）

用例编号
- 唯一标识作用
测试项目/模块
标题
- 对一条用例的说明
- 不要包含是否、可能等不确定词汇
预置条件
操作步骤
输入数据
预期结果
优先级

测试用例设计技术

等价类划分法：把所有可能的输入数据，即程序的输入划分为若干类别，然后从每一类中选取少数有代表性的数据作为测试数据
- 有效等价类：代表对程序的有效输入（符合需求规定的数据）；一条测试用例覆盖多个有效等价类，有效减少测试用例的条数，提高测试效率
- 无效等价类：代表的则是其他任何可能的输入；对于每一个无效等价类，至少编写一条相应的测试用例，用于覆盖代码中的异常处理，不然可能会造成某一类测试数据的逻辑处理代码漏测
等价划分法流程：1.对测试数据进行分类2.对每类数据划分等价类（列出等价类表）3.选取测试用例/数据三步
边界值分析法
- 边界值点的定义–任何值的测试的范围的临界点，可分为
  - 边界值：明确地定义在规格说明书中
  - 次边界：隐含在软件需求中必须经过分析才能获得
- 上点、离点、内点
  - 上点：就是指边界上的点，开区间上点在域外，闭区间上点在域内（就是给的范围的两个数）
  - 离点：就是离上点最近的点，开区间离点在域内，闭区间离点在域外
  - 内点：域内的任意点都是内点
流程分析法：是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例
- 关注的重点是流程是否能走下去，每个节点的功能并不关注
- 适用范围：
  - 业务流程测试
  - 安装流程测试
  - 审批流程测试
- 流程分析法设计用例步骤
  1. 画出业务流程图
  2. 编写测试用例
正交分析法
- 因子：所有影响试验标准的条件，要测试的功能点
- 水平：影响试验因子的状态，即单个因素能够取得的值的最大个数
判定表分析法：是根据不同的条件组合选择不同动作的分析工具
- 一张判定表的田字形结构：条件桩、条件项、动作桩、动作项
错误猜测法

测试用例设计方法选择原则

在这里插入图片描述

8.缺陷管理

缺陷管理的目的

缩短沟通时间
解决问题更高效
容易跟踪缺陷
便于缺陷统计与分析

缺陷管理工具

行内现在一般用的都是禅道

开发处理BUG几种可能

重复BUG

其他测试人员提交过的BUG

不能重现的BUG应该怎么处理（面试）

1、出现bug后，首先截图，查看日志，把对应日志保留下来

2、尝试重现这个bug ，思考这个bug可能产生的原因，然后每个原因逐步验证，如果重现不出来，可以找开发帮忙，这个步骤是为了准确找到重现bug 的步骤，开发修改的时候就容易多了，不然又会和开发来来回回扯皮

3、如果实在重现不出来，还是要提交bug 的， bug单一定要写清楚bug出现的环境，版本、步骤，错误截图，对应的日志，尽可能多的提供出现bug时的信息，方便开发定位

设计如此

本来的设计就是这样的

外部原因

网络、环境等

当你提了一个bug，开发认为这不是bug，怎么处理?（面试）

答:首先确认开发环境是否跟自己测试环境一致，确认在测试环境能重现，如果确认是缺陷跟开发保持有效沟通，如果是级别较低的建议性bug，可以先记录到 bug 平台，先保留沟通。如果是 bug 级别较高的问题，对应需求文档的预期结果跟开发说明，更有说服力;耐心讲解BUG的危害，不行就找产品确认，确实是BUG注明情况并再次指派给开发