软件测试面试问答

软件测试基础

什么是软件测试

通过使用软件，检验软件是否达到预期的标准，实际示预期结果和实际结果对比的过程

软件的生命周期

提出需求、需求的可行性研究分析、确认需求、设计结构，架构、开发编程、测试人员执行测试、测试通过后上线运营

测试方案的主要内容

测试环境（硬件设备（手机）、软件、搭建手册）、测试方法（黑盒+手工+动态）、测试工具、测试类型（功能测试、安全性测试、兼容性测试、易用性测试、安装适配测试、性能测试......）

设计文档

概要设计说明书、详细设计说明书、数据库设计文档、接口文档

怎样库快速熟悉业务

• 只有说明文档：如果需求不太稳定，要进行需求评审，明确需求问题；如果需求稳定，要粗度需求，边阅读编开展测试工作，比如编写测试范围列表。还可以寻找竞品软件初步了解主要功能和业务。
• 只有可运行的软件：搭建测试环境，边使用被测系统，遍绘制项目模块图，记录在使用过程中遇到的问题，找测试主管进行沟通确认。
• 有说明文档和被测软件：通过文档编写测试范围列表，对项目有整体认识。结合需求文档，使用被测软件，学习相关的业务，从而熟悉项目。

测试计划主要内容

明确测试对象、测试人员组织和职责、测试任务分配、测试进度安排、风险的防范措施、测试完成的标准、测试挂起和恢复

什么是测试用例

软件测试过程中执行测试的最小一个单位

什么是缺陷报告

在执行测试过程中，我们发现的实际情况和需求文档中的描述不一致，并针对这个问题的描述就是缺陷报告

瀑布模型的八个阶段

原始需求、项目计划、需求分析、概要设计、详细设计、编写代码、执行测试、上线运维

数据库与软件测试的关系

• 检查界面输入的数据是否正确存储到数据库中
• 检查界面不可见数据是否正确存储到数据库中
• 检查是否符合数据库事务的一致性：一个功能如果同时作用了多张表，这些表的变化要同时发生

缺陷管理跟踪流程

1、测试人员发现bug后，提交到禅道，将bug指派给相应的开发。开发登录禅道查看bug。

2、若接受bug，则修复bug，待修复bug后，会把bug分配给测试人员进行复测。

3、若复测通过，测试人员关闭bug，若复测没通过，让开发重新修复bug，直到关闭bug为止。

4、若开发不接受bug，则拒绝修复。要先找bug沟通，开发坚决不修复的话，再找产品确认。

怎样区分前后端bug

• 使用抓包工具抓取操作过程，对比说明文档，分析请求地址、请求参数是否正确，若请求有问题，说明是前端bug。
• 若请求正确，还要看响应结果。若响应结果错误，说明是后端bug。
• 还可以看状态码，若报4xx，说明是前端问题；若报5xx，说明是后端问题。

用例

用例设计的方法

等价类、边界值、判定表、正交试验法、流程分析法、状态迁移图法（广度优先，深度优先）、异常分析法、错误猜测法、输出域覆盖、输入域覆盖、因果图

• 判定表

  使用条件：输入的条件属于布尔类型

  

  

• 正交试验法

​ 使用条件：每个输入项必须选一个，且每个输入项之间没有逻辑关系

​ 使用方法：画出因子状态图，复制红框中的内容到a.txt文件，使用allpairs.exe工具，在cmd窗口中输入allpairs a.txt > b.txt，在b.txt中可查看生成的测试用例

测试范围列表

需求编号（项目简拼-测试阶段-需求缩略词+编号）、所属项目、需求名称、需求类型、需求优先级

测试用例八要素

用例编号、测试项目、测试标题、预置条件、优先级、输入数据、操作步骤、预期结果

参数分析表

参数名称、类型、长度、取值范围、其他规则、是否为空、是否重复

等价类边界值表

参数名称。有效等价类、有效数据、无效等价类、无效数据

缺陷报告

缺陷编号、缺陷标题、缺陷描述、缺陷严重程度、修复优先级、附件、用例编号、提交时间、提交人、指派人

测试报告

项目名称、测试时间、投入资源、测试模块、测试数据分析（用例分析、缺陷分析）、覆盖浏览器、风险评估（评估上线出问题的概率）、测试结论

怎么把用例写全

我认为想把用例写好,首先要理解和弄懂需求,在参与项目中,参加各种需求讨论会和需求评审会,还会把需求评审会议录制下来,找时间反复多次学习,确保把需求学透了。然后再根据需求特点选择合适的方法设计用例。还会从界面测试,功能测试,非功能测试多个方面进行分析。最后,用例写完后,参加用例评审,通过团队的力量,一起对用例进行把关,及时完善和补充用例。只有经过这些过程,才可能把用例准备充分。

禅道

建用例

所属产品、所属类型、用例类型（功能测试、性能测试、配置相关、安装部署、安全相关、接口测试、其他）、适用阶段（单元测试阶段、功能测试阶段、集成测试阶段、系统测试阶段、冒烟测试阶段、版本验证阶段）、用例标题、优先级、前置条件、用例步骤（步骤、预期）、关键词、附件

提BUG

所属产品、所属模块、所属项目、影响版本、当前指派、Bug类型（代码错误。界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题、标准规范、测试脚本、其他）、操作系统、浏览器、Bug标题、严重程度、优先级、重现步骤（步骤、结果、期望）、相关需求、相关任务、抄送给、关键词、附件

BUG的一生

由谁创建、影响版本、解决者、解决版本、解决方案、由谁关闭、关闭日期

BUG解决方案

• 设计如此：对设计文档或需求文档进行静态测试，确认需求是否存在缺陷
• 重复BUG：提交缺陷时需要先进行去重处理
• 外部原因：公司或项目组外的原因引发的问题，可以直接关闭
• 已解决：测试人员进行回归测试。如果回归通过，将缺陷的状态改为已关闭，并填写BUG备注，说明BUG回归的结果。如果回归失败，将缺陷的状态改为激活
• 无法重现：测试人员发现缺陷后，不能马上提交缺陷报告。再构造三到五组数据进行复测，保证缺陷百分百重现。如果在复测过程中，无法重现，找到开发人员进行沟通。向开发描述发现的问题，由开发从代码层面进行分析定位。直到开发确认缺陷，在提交缺陷报告。
• 延期处理：测试人员需要评审/判断缺陷的严重程度、影响范围，如果缺陷影响范围比较大或影响用户使用体验的，不能延期处理。如果缺陷不严重，影响面积小，对用户使用影响也比较小，可以同意，明确延期的时间
• 不予解决

接口测试

http和https的区别

• HTTP 协议传输的数据都是未加密的，也就是明文的，因此使用HTTP 协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（SecureSockets Layer）协议用于对HTTP 协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS 协议是由SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比http 协议安全
• https 协议需要到CA申请证书，一般免费证书较少，因而需要一定费用
• http 是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl/tls 加密传输协议
• http 和https 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
• http 的连接很简单，是无状态的；HTTPS 协议是由SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比http 协议安全

get和post的区别

• get请求和post请求本质上没有区别，只是在协议规定上的区别
• 参数的位置不同：get请求没有消息体，所有的参数都是通过网址传递；post请求可以将参数放在消息体进行传递
• 安全性不同：对于用户来讲，post请求比较安全，参数放在消息体里，更好的保护用户的隐私；
• 对于服务器来讲，get请求会比较安全，get请求一般用于查询操作，不会为服务器引来脏数据；post一般用于添加操作，可能会为服务器引来无意义的数据
• 参数的长度限制不同：get请求的参数放在网址中, 网址的长度是有限的,一般不超过1000个字符, 所以一般不用get请求上传大文件；post请求的参数放在实体中, 参数的长度由服务器决定, 一般可以认为是没有上限
• 发包次数不同：get请求向服务器发一次包, 只需要发请求行和信息头；post请求向服务器发两次包，第一次发请求行和信息头，服务器返回状态码100，客户端接收到100状态码后, 再发送请求实体，所以, 一般get请求的速度比post请求快
• 对于手工测试的影响：get请求可以存放到历史记录和收藏夹中，get请求在浏览器中点击回退, 不会重新向服务器发请求；post请求在浏览器中点击回退, 会重新向服务器发请求

Postman和Jmeter的区别

• Postman的请求的url地址是一个整体，Jmeter把网址分5部分：协议，域名，端口号，路径，参数
• Jmeter更适合做参数化，测试数据文件和测试计划可以保存在一起，Postman每次执行都需要手工加载数据文件，不方便
• jmeter功能更强大，支持更多的协议
• 单次测试Postman操作更简单，如果需要频繁的回归测试，Jmeter维护更简单
• Postman自带断言函数，但Jmeter自带断言组件，操作更简单，断言更丰富，并且支持正则表达式
• Jmeter可以更好的保存测试结果
• Postman比较适合手工做接口测试，适合第一次测试，操作简单，善于找bug；Jmeter更适合做自动化接口测试，适合做回归测试和冒烟测试，保证产品质量

cookie和session的区别

• cookie可以存储在浏览器或者本地，session只能存在服务器中
• cookie只能存储String类型的对象，session能够存储任意的java对象
• session比cookie更具有安全性(cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击)
• session占用服务器性能，session过多，增加服务器压力
• 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，session是没有大小限制和服务器的内存大小有关

APP测试

APP项目的类型

APP原生框架、APP混合框架（原生+H5页面）、H5页面、小程序

安卓的四层框架

• 最顶层；应用程序层
• 第二层：应用程序框架层（支持应用程序层中软件的运行）
  • Activity Manager:活动管理，用来管理
    应用程序并提供常用的导航退回功能
  • Window Manager:管理所有的窗口程序
  • ......
• 第三层：安卓运行环境
  • 系统库
  • 运行环境
• 第四层：Linux内核层（提供各种驱动程序）

安卓四大组件

• Activity（活动）：展示一个界面并与用户交互
• Service（服务）：在后台执行一系列的任务
• BroadcastReceiver（广播接收器）：在不同的组件或不同的应用之间传递消息
• ContentProvider（内容提供器）：向其他应用或其他组件共享数据

APP稳定性测试目的

APP在长时间(2H)运行下是否会出现崩溃(CRASH)或无响应(ANR)的情况

怎样分析monkey日志

• 打开monkey日志，搜索CRASH和ANR

• 如果没有搜索到相关日志信息，则说明未发现异常问题，测试通过

• 如果搜索到相关的错误信息，找到发生错误的页面，模拟monkey发送的事件，或再次执行带seed值monkey命令

• 如果发现的是ANR的问题，还需要把/data/anr/traces.txt文件与monkey日志一起做为附件发送给开发

APP性能测试目的

APP在运行过程中对手机的CPU、内存等资源占用情况

APP兼容性测试

兼容性测试是指测试软件在特定的硬件产台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能很好地运行的测试。简单的说，兼容性测试是指测试某新开发的软件在某一特定环境下与各种软件的协调性，软件之间能否很好的运作。

• APP兼容性测试点：主要测试内部和外部兼容性，如系统版本、不同的ROM、屏幕分辨率
  • 与本地及主流的APP是否兼容（微信、QQ、支付宝等）
  • 基于开发环境和生产环境的不同，检验各种网络连接下，APP的数据和运用是否正确
  • 与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，各种行为是否一致
  • 用不同的支持语言验证APP行为
  • 新旧版本在功能、逻辑层面的兼容测试，同一个APP在不同系统版本运行，以及在不同机型这间的适配测试
  • 接口、协议的兼容性测试，能够保证大部分的功能完善
  • 不同操作系统的兼容性，是否适配
  • 不同手机屏幕分辨率的兼容性
  • 不同手机品牌的兼容性
  • APP在不同系统版本上保证运行适配性

APP中断交互性测试

针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。如；App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。

• 交叉事件测试非常重要，能发现很多应用中潜在的性能问题。
  • 多个 App同时运行是否影响正常功能
  • App运行时前/后台切换是否影响正常功能
  • App运行时拨打/接听电话
  • App运行时发送/接收信息
  • App运行时发送/收取邮件
  • App运行时切换网络（4G、5G、WIFI）
  • App运行时浏览网页
  • App运行时使用蓝牙传送/接收数据
  • App运行时使用相机、计算器等手机自带设备

APP安装/卸载测试

安装测试点

• 软件在不同操作系统下安装是否正常
• 软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里
• 软件安装各个选项的组合是否符合概要设计说明
• 软件安装向导的 UI测试
• 软件安装过程是否可以取消，点击取消后，写入的文件是否正确处理
• 软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）
• 安装空间不足时是否有相应提示
• 安装后没有生成多余的目录结构和文件
• 对于需要通过网络验证之类的安装，在断网情况下尝试一下
• 还需要对安装手册进行测试，依照安装手册是否能顺利安装

卸载测试点

• 直接删除安装文件夹卸载是否有提示信息
• 测试系统直接卸载程序是否有提示信息
• 测试卸载后文件是否全部删除所有的安装文件夹
• 卸载过程中出现的意外情况的测试（如死机、断电、重启）
• 卸载是否支持取消功能，单击取消后软件卸载的情况
• 系统直接卸载：UI测试，是否有卸载状态进度条提示

运行测试点

• 软件安装后需要检查应用是否能正常运行
• APP安装完成后，是否可以正常打开
• APP的速度是否可以接受，切换是否流畅
• 网络异常时，应用是否会崩溃
  • 在请求超时的情况下，如果程序逻辑处理的不好，就有可能发生crash

权限测试

• 权限提示选择
  • 多种权限组合测试：不选、全选、每个权限单独选择是否能用、选择某些（最多全组合去重复--正交或少的情况可以决策表）
• 首次启动APP询问是否同意启用权限
• 消息权限开启时，消息推送是否正常接收
  • IOS系统应用启用和后台关闭时都应该可以收到
  • Android系统在后台关闭进程后就不会推送
  • 消息权限关闭后，APP客户端接收不到消息推送
• 位置权限开启时，APP可定位到当前用户位置；位置权限关闭后，APP需定位才可用的功能，是否有提示引导用户开启权限
• 网络权限关闭时，APP是否有提示：“服务器或网络错误，请稍后重试”，是否有提示引导用户开启权限

APP升级/更新测试

• 当客户端有新版本时，有更新提示
• 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动 app时，仍能出现更新提示
• 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示
• 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新
• 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本
• 当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。
• APP更新后版本号应有更新，更新后，要保证旧的数据能正常使用
• 删除APP后更新

APP易用性测试

UI测试

• 测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足客户要求、文字
• 是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。
• UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。
• 确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

导航测试

• 按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航
• 是否易于导航，导航是否直观
• 是否需要搜索引擎
• 导航帮助是否准确直观
• 导航与页面结构、菜单、连接页面的风格是否一致

图形测试

• 横向比较。各控件操作方式统一
• 自适应界面设计，内容根据窗口大小自适应
• 页面标签风格是否统一
• 页面是否美观
• 页面的图片应有其实际意义而要求整体有序美观
• 图片质量要高且图片尺寸在设计符合要求的情况下应尽量小
• 界面整体使用的颜色不宜过多

内容测试

• 输入框说明文字的内容与系统功能是否一致
• 文字长度是否加以限制
• 文字内容是否表意不明
• 是否有错别字
• 信息是否为中文显示
• 是否有敏感性词汇、关键词
• 是否有敏感性图片，如：涉及版权、专利、隐私等图片

用户体验测试

• 是否有空数据界面设计，引导用户去执行操作。
• 是否滥用用户引导。
• 是否有不可点击的效果，如：你的按钮此时处于不可用状态，
  那么一定要灰掉，或者拿掉按钮，否则会给用户误导
• 菜单层次是否太深
• 交互流程分支是否太多
• 相关的选项是否离得很远
• 一次是否载入太多的数据
• 界面中按钮可点击范围是否适中
• 标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换
• 操作应该有主次从属关系
• 是否定义 Back的逻辑。涉及软硬件交互时，Back键应具体定义
• 是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计

APP手机特性

手机按键测试

• 手机开锁屏对运行中的 App的影响
• 切换网络对运行中的 App的影响
• 多个运行中的 App的切换
• App运行时关机
• App运行时重启系统
• App运行时充电
• 在所有界面执行锁屏操作，解锁后观察是否正常运行
• 在所有界面，和所有过程，按home键切后台，再切回时观察是否正常
• 在所有的loading过程中，按back键
• 在所有的loading过程中，按home键
• 界面切换动画时尝试多次按back键

屏幕旋转

• 确认哪些界面是需要允许横屏或者禁止横屏的
• 将屏幕锁定为竖屏或者横屏，在几个界面跳转，界面是否正常
• 当适应横屏时，是否对横屏进行了适配

WEB测试与APP测试的区别

相同点：测试流程方面基本是类似的

1. 获取项目相关资料，快速熟悉项目
2. 进行具体的需求分析，提取测试点
3. 进行用例评审，保证测试的全面性
4. [搭建测试环境]，执行用例，将测试过程中发现的缺陷提交给开发并进行跟踪管理
5. 对已修复的缺陷进行回归测试
6. 达到测试标准后，结束测试，编写测试总结，支持项目上线

不同点

性能测试

• WEB：测试的是服务器端的性能，包括响应时间、并发测试、负载测试、压力测试等
• APP：除了服务器端性能之外 ，还要测试APP运行时对手机的CPU、内存等资源占用

兼容性测试

• WEB：不同品牌、不同版本浏览器
• APP：不同的操作系统、不同手机品牌、同一品牌的不同手机

安装卸载测试

• WEB：不需要用户安装，直接使用浏览器访问项目
• APP：
  • 下载渠道：应用商城、官网、第三方应用
  • 安装方式：apk方式、扫码、手机管家
  • 运行、卸载、覆盖安装

升级测试

• WEB：只需要更新服务器，用户就可访问最新的程序
• APP：不仅要更新服务器程序，还需要更新客户端应用
  • 强制更新
    • 版本已经低于最低的运行版本
    • 提示更新，不能关闭
    • APP无法使用
    • 更新链接正确，可以直接更新
    • 更新程序后，旧数据可以正常使用
  • 非强制更新
    • 版本低于最新版本
    • 提示更新，可以关闭
    • APP可以正常使用
    • 更新链接正确，可以直接更新

网络测试

• WEB：只考虑有网和无网的情况
• APP：
  • 不同的网络情况
    • 好网：3G/4G/5G/WIFI/热点
    • 无网：飞行模式、网络盲区
    • 弱网环境
  • 不同网络切换