秋招历险记-测试篇

测试相关

测试分类：

是否考虑内部结构：

• 白盒测试：逻辑驱动测试，按照程序内部逻辑、编码结构，设计测试数据并完成测试。

• 黑盒测试：数据驱动测试，根据程序功能的需求考虑，确定测试用例、推断测试结果的正确性。

• 灰盒测试：综合测试

是否执行代码：

静态测试：不运行被测程序本身，分析和检查程序的语法、结构、接口等检查程序的正确性。

动态测试：运行程序本身，检查运行结果与预期之间的差异，分析运行效率、正确性等指标。

开发过程级别：

1. 单元测试：是对软件中最小可测试单元(人为规定的最小必测功能模块)进行检查和验证。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
2. 集成测试：也叫组装测试或联合测试。在单元测试的基础上将所有模块按照要求设计组装成为子系统或系统，进行集成测试。
3. 系统测试：对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不复合系统说明书的地方。系统测试可以发下系统分析和设计中的错误。
4. 验收测试：是部署软件之前的最后一个测试操作。在上述步骤完成之后，产品发布之前所进行的测试活动。验收测试是技术测试的最后一个阶段，也称交付测试。目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
5. 回归测试：修改了了旧代码之后重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

1、白盒测试常用的方法

静态白盒测试：不执行代码的情况下有条理地审查软件设计、体系结构和代码，从而找出软件缺陷，有时也称为结构化分析，可以较早地找到缺陷

动态白盒测试：结构化测试，查看并使用代码的内部结构来设计和执行用例。

覆盖测试

原则：

• 保证一个模块中的所有独立路径至少被执行一次
• 所有逻辑值均需测试真和假两种情况
• 检查内部数据结构，保证结构的有效性
• 上下边界和可操作范围内运行所有循环

控制流图CFG：简化的程序流程图，包括节点和控制流线或弧（带箭头 ）。有唯一的源节点和汇节点。如果节点之间没有分支可以合并为一个节点。若判断中的条件表达式是复合条件时，需要改复合条件为一系列只有单个条件的判断。（大于等于要分成大于和等于）

分类：

• 语句覆盖：设计若干用例，每个可执行语句至少被执行一次。用例数目越少越好。充分必要条件是：覆盖控制流图中的所有节点。

  优：可以很直观地从源代码得到测试用例，无须细分判定条件。

  缺：是最弱的逻辑覆盖。

• 判定/判断/分支覆盖：每个判断条件的真值分支和假值分支至少被执行一遍。用例数目越少越好。必须覆盖控制流图中的所有边。

  优：比语句覆盖强；和语句覆盖一样，无须细分每个判定就可以得到测试用例。

  缺：忽略了每个条件的取值情况，仍然是弱的逻辑覆盖。

• 条件覆盖：每个判断条件中的每个条件可能取值至少被执行一遍。用例数目越少越好

  

  优：增加了对条件判定情况的测试

  缺：条件覆盖不一定满足判定覆盖

• 判定-条件覆盖：判断条件中的所有条件可能至少执行一次取值，同时判断的所有可能结果至少执行一次。

​ 优：同时满足判定、条件两种覆盖标准

​ 缺：未考虑条件的组合情况

• 条件组合覆盖：每个判断条件的内部判断式的各种真假组合可能都至少被执行一遍。即所有可能的条件取值组合至少执行一次。

  

  优：同时满足判定覆盖、条件覆盖、判定-条件覆盖

  缺：线性地增加了测试用例的数量

• 路径覆盖（做不到全路径覆盖）：覆盖所有可能的执行路径

  优：覆盖面广

  缺：工作量巨大

  

路径测试

检验程序的每一条语句，从而达到语句覆盖。

执行该基本集所生成的测试用例保证程序中的每一条语句至少执行一次。

独立路径是任何贯穿程序的、至少引入一组新的处理语句或一个新的条件的路径。 从控制流图来看，一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径。路径 可以用控制流图中的节点序列来表示

圈复杂度：是一种描述程序逻辑复杂度的标准，运用基本路径方法，给出了程序基本路径集中的独立路径条数，提供了保证可执行语句被执行一次所需测试数量的上限

​ 计算公式：

• V(G)=E-N+2 E：边的数量，N：节点的数量

• V(G)=P+1 P：判断节点的数量

• V(G)=A A：区域的数量

主路径：在所有路径中找到一条最复杂的路径作为基础路径。

​ 要包含尽可能多的判定节点；尽可能复杂的判定表达式；对应尽可能高的执行概率；包含尽可能多的语句–>采用深度优先策略，遇到判定节点，遵循先false再true分支

路径选取的一般原则：

• 必须满足逻辑覆盖的最低标准：语句覆盖+判定覆盖

• 对单循环、嵌套循环、串接循环、不规则循环给出相应的路径选择原则

  单循环（最小0最大N次的情况）：0，负数，一次通过，典型的循环次数，N-1次、N+1次

  嵌套循环：从最深层开始，外层都设最小值；测试最小值、最小值+1、最小值-1、典型值、最大值-1、最大值+1、最大值；设定内循环在典型值处，按前一规则测试外层循环，直到覆盖所有循环。

  串接循环：如果相互独立，采用简单循环方式；如果不独立，使用嵌套循环的方式

  不规则循环：设计为结构化的再进行测试

• 选取最简单的、具有一定功能含义的路径

• 由简到繁，若有可能，先考虑不含循环的测试路径 ，然后补充对循环的测试

• 尽可能选取短路径

• 选取没有明显功能含义的路径，此时要研究这样的 路径为什么存在，为什么没有通过功能上合理的路径 得到覆盖

2、黑盒测试常用的方法有哪些？

• 等价划分法
• 边界值法
• 判定表法
• 因果图法
• 正交实验法
• 状态图迁移法
• 场景法
• 错误推断法

等价划分法

在所有测试数据中，具有共同特征的数据子集。分为有效等价和无效等价类。

每个部分选取少数/一个代表性数据作为测试用例。

• 有效等价类：对程序规格合理、有效的输入数据的集合；程序可以正确计算和执行。
• 无效等价类：不合理、无效的输入数据的集合；程序接收到之后，会给出错误提示，或者不允许输入。

线性情况：可以根据需求划分找到分界点

非线性情况：难以找到分界点

可以根据输入数据类型划分：数据个数、集合、符合某些规则的输入、取值范围、布尔值。

步骤：

• 分析需求，确定数据类型
• 根据数据类型划分等价类
• 设计用例，覆盖有效等价类（一条用例尽可能多覆盖有效等价类）
• 设计用例，覆盖无效等价类（一条用例只能覆盖一个无效等价类）

边界值分析法

大量的错误都是发生在输入输出的边界上。选等于、大于、小于边界值的点。

主要是对“输入”、“输出”的边界值进行测试。它是等价划分的补充方法，不是选择等价类的任意元素，而是选择等价类的边界元素。

步骤：

• 找到等价类的边界点
• 选择边界点和两边的点，单独设计测试用例进行测试

1.需求分析，确定输入类型	地区码：3/4位号码 电话号码：7/8位号码
2.根据输入规则，划分有效等价类和无效等价类	长度 集合 组成规则 3/4 数字 以0开头 7/8 数字 以非0非1开头
3.确认上点、离点、内点	有效等价类 无效等价类 1.以0开头的3位数字 3.以0开头的小于3位的数字（2位） 2.以0开头的4位数字 4.以0开头的大于4位的数字（5位） 5.以0开头的包含非数字的4位字符串 6.以非0开头的4位数字 7.以非0非1开头的7位数字 9.以非0非1开头的小于7位数字（6位） 8.以非0非1开头的8位数字 10.以非0非1开头的小于8位数字（9位） 11.以非0非1开头包含非数字的8位数字 12.以0开头的8位数字 13.以1开头的8位数字
4.设计测试用例，覆盖有效等价类
5.设计测试用例，覆盖无效等价类

判定表法

使用等价类方法时对输入区域及输入区域存在关联时无法覆盖

• 分析需求，确定条件桩和动作桩

条件桩：输入条件

动作桩：结果

• 设计优化判定表（全组合），得到条件项（N条件数，2^N条件项）

条件项：输入条件全组合

• 根据条件项，填写动作项

动作项：对应条件项的结果

• 简化判定表

每一列代表一种情况/规则/用例。

输入手机号	1	1	1	0	1	0	0	0
输入电子邮箱	1	1	0	1	0	1	0	0
输入验证码	1	0	1	1	0	0	1	0
填写账户信息	不存在	不存在	T	T
报错L							L	L
报错M					M	M		M

最终用例是后6条

因果图法

考虑了所有输入输出条件的相互制约关系及组合关系、输入条件之间的依赖关系，再将关系转化为判定表的规则。

条件与结果之间的关系：恒等、非~、或v、与^

条件与条件之间的关系：互斥（最多一个）、包含（至少有一个）、屏蔽（如果a成立那么b不成立）、唯一（有且只有一个）、要求（有a一定要有b）

步骤：

• 分析需求，获取条件和动作
• 分析条件和动作、条件和条件之间的关系
• 画出因果图
• 因果图转化为判定表
• 将判定表中的每一列作为依据，设计测试用例

第一项手机号	0	X	1	0
第一项邮箱	0	X	0	1
第二项正确验证码	X	0	1	1
报错L	L
填写账户信息			T	T
报错M		M

状态迁移图

适用于状态较多的情景，多用于协议测试。

• 分析需求，找到所有的状态

• 分析各个状态之间的转换条件和转换路径，画状态迁移图

• 画状态迁移树

• 转化为测试用例（树根倒到树叶的路径）。

树根：只有输出

树叶：只有输入

树干：状态转化之间的路径

测试用例：从树根到树叶

场景法

软件都是用时间来触发控制流程的，事件触发时的情景就行成了场景（流程的开始到流程的结束），同一时间的不同触发顺序就会形成事件流。

• 分析需求，确定基本流和备选流
• 根据基本流和备选流生成场景
• 根据场景生成用例

一定要把所有的路径覆盖到，例题中的前五个场景。

基本流：输入正确用户名、正确的验证码，填写账户信息

备选流1：用户名填写错误，报错L

备选流2：验证码填写错误，报错M

正交实验法

多用于配置测试。

测试多条件多输入的测试用例方法，从大量的数据中挑出适量的有代表性的点，从而合理安排实验的一种科学设计方法。

因子：条件

水平：取值

• 分析需求，获取因子和水平
• 根据因子及水平选择正交表
• 替换因子水平，获取试验次数
• 细化测试用例

4因子3水平–>查正交表(如果没有正好符合的，就找一个比它略大的)—>替换因子与水平

错误推断法

根据以往的测试经验和对系统内部知识的了解，列出系统中可能有的错误和容易发生错误的特殊情况，根据它们设计测试用例。

经验+直觉

3、软件测试的基本流程

• 需求分析阶段：
  • 阅读需求，理解需求，主要就是对业务的学习，分析需求点
• 计划阶段：
  • 主要任务是编写测试计划，参考软件需求规格说明书，项目总体计划，测试范围，进度安排， 人力物力的分配，整体测试策略的指定，和风险的评估与规避措施有一个指定，一般有测试 主管编写，当然我们也会参与相关的评审工作。
• 设计阶段：
  • 主要任务是编写测试用例，会参考需求分析、概要设计、详细设计等文档，有不明确的也会及时和开发、产品经理沟通。用例编写完成后会进行评审。
• 执行阶段：
  • 首先搭建测试环境，执行预测，以判定当前版本可测与否，如果预测通过，正式进入系统测试，遇到问题提交bug到缺陷管理平台，并对bug进行跟踪，知道被测软件达到测试需求 要求，没有重大bug，测试结束。
• 评估阶段：
  • 出测试报告，对整个测试的过程和版本质量做一个详细的评估。

情景问答

1、XXXX怎么测试？

电梯：

• 主要是查看是否具有测试思维，看在没有需求文档的情况下是否可以设计测试用力。
• 首先，可以反问这个属于什么类型XXX(电梯可以分为旅游电梯和正常电梯，笔可分为钢笔和圆珠笔，伞可以分为太阳伞和遮雨伞)
• 然后尝试从功能测试、界面测试、易用性测试、兼容性测试、安全测试、性能（压力）测试等方面进行展开:下面以电梯为例：
  • 功能测试：
    • 电梯的所有按钮是否正常工作（包括报警按钮等）
    • 电梯内部的灯工作是否正常
    • 电梯的显示屏是否正常显示楼层信息
    • 电梯门口的红外检测设备是否正常工作，对于物体的灵敏度是否正常
    • 电梯在上行过程中，经过的楼层有人向下是否正常运行，这些逻辑功能测试。
    • 电梯快超载的时候，在运动过程中有人按下按钮，是否还会开门。
  • 界面测试：
    • 查看电梯是否符合消防标准
    • 外观是否美观，内部是否合理等
  • 易用性测试：
    • 小朋友或者老人是否可以方便使用电梯
    • 是否提供语音楼层播报功能
    • 是否有针对有无障碍扶手等
    • 电梯内部的照明、通风、空调、信号是否正常
  • 兼容性测试：
    • 电梯的输入电压是否符合标准
    • 针对电梯中可能存在的其他电器，他们的电压等会不会相互干扰
  • 安全测试：
    • 超载发生时，是否提醒乘客。
    • 电梯下坠过程中，是否出发紧急制动
    • 电梯是否具备其他备用电源
    • 电梯内部是否存在电线裸露等安全隐患
  • 性能测试（压力）：
    • 电梯带人后上行速度是否正常
    • 长时间的工作是否出现异常情况
    • 电梯的真实称重范围

搜索框

• 功能测试

  • 搜索内容为空，验证系统如何处理
  • 搜索内容为空格，验证系统如何处理
  • 边界值验证：在允许的字符串长度内外，验证系统的处理
  • 输入超长字符串，系统是否会截取允许的长度来检验结果
  • 输入合法长度的字符串之后，加空格验证搜索结果
  • 在多个关键字中间加入空格、逗号、Tab验证系统的结果是否正确
  • 验证每种合法的输入，结果是否正确
  • 是否支持检索内容的复制、粘贴、编辑等操作
  • 是否支持回车键搜索
  • 多次输入相同的内容，查看系统的检索结果是否一致
  • 特殊字符、转义字符、HTML脚本等需要做处理
  • 输入敏感词汇，提示用户无权限等
  • 输入的内容是否支持快捷键操作等
  • 只能输入允许的字符串长度等
  • 输入链接是否能够正常跳转
  • 搜索的历史记录是否显示在下面
  • 搜索内容有没有联想的功能
  • 是否可以输入数字、中文、英文
  • 是否可以混合输入数字、英文、中文
  • 输入拼音也可以进行检索
  • 语音搜索的内容是否匹配
  • 断网时，无法搜索
  • 进行图片搜索时可以选择拍照或从相册种选取图片
  • 如果从相册种选取图片进行搜索，图片的大小是否有限制，最大为多少
  • 搜索框边上有相机图片，便于图片搜索
  • 单击清空历史记录，搜索框是否会清空历史记录
  • 能否识别图片中的内容
  • 单击搜索，显示搜索界面

• 界面测试

  • 查看UI是否显示正确，布局是否合理
  • 是否有错别字
  • 搜索结果显示的布局是否美观
  • 已查看的结果链接，链接的颜色是否灰化处理
  • 结果数量庞大时，页面的分页布局是否合理
  • 界面的颜色搭配是否合理

• 安全性测试

  • 脚本的禁用
  • SQL的注入，检索SQL SELECT语句等
  • 敏感内容的检索是否禁止
  • 特殊字符的检索
  • 被删除、加密、授权的数据不允许被查出来
  • 是否有安全设计控制

• 兼容性测试

  • 多平台Windows、Mac
  • 移动平台 Android、IOS
  • 多浏览器火狐、Chrome、IE等

• 性能测试

  • 搜索页面的链接打开的时间
  • 搜索出结果的消耗时间
  • 弱网时搜索的响应时间
  • 不同网速下搜索时的响应时间，例如3G、4G、5G、WIFI

• 易用性

  • 有联想功能
  • 搜索内容与搜索结果匹配程度
  • 支持拍照搜索、语音搜索等

2、一个旧的项目如何测试？

3、对自动化测试的理解？

什么时候需要进行自动化测试

1. 任务测试明确，不会频繁变动
2. 每日构建后的测试验证
3. 比较频繁的回归测试
4. 软件系统界面稳定，变动少
5. 需要在多平台上运行的相同测试案例、组合遍历型的测试、大量的重复任务
6. 软件维护周期长
7. 项目进度压力不太大
8. 被测软件系统开发比较规范，能够保证系统的可测试性
9. 具备大量的自动化测试平台
10. 测试人员具备较强的编程能力

4、 如测试出来的问题，开发人员不认可怎么办？

5、 项目上线前测不完怎么办？

​ 第一选择就是delay，但会查看本次delay原因：比如开发提测时间比正常晚了x天或者虽然准时提测但出现大量严重bug单阻塞测试。如果测试开发产品三***得可以delay,最好按照提测晚的时间或者严重单阻塞的时间作为delay多长时间的依据。如果该本次迭代已经提前规定了上线时间，且公告上去无法delay，那么需要首先保证本次迭代新增主功能不阻塞，同时上线后正式环境回归，保证用户使用不会被阻塞。