一、自我介绍
二、项目
一般都是问最近的项目或者让你选择一个最熟悉的项目讲流程或提问。
三、测试基础
-
get与post区别
- GET请求只能进行url编码，而POST支持多种编码方式
- GET请求在URL中传送的参数是有长度限制的，而POST么有
- 对参数的数据类型，GET只接受ASCII字符，而POST没有限制
- GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息
- GET参数通过URL传递，POST放在Request body中
- GET在浏览器回退时是无害的，而POST会再次提交请求
- GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留
GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同
-
http 与https 的区别
- http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
- https协议需要到CA申请证书，一般免费整数较少，因而需要一定费用。
- http是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL/TLS加密传输协议。
- http的连接很简单，是无状态的；https协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
-
常见状态码
-
B/S与C/S测试的区别
-
cookie和session的区别
- cookie数据保存在客户端，session数据保存在服务器端。
- cookie返回字符串，session返回对象
- 单个cookie大小在客户端的限制是3k，session没有明显限制
- cookie存放在本地，其他人可以分析进行cookie欺诈，考虑到安全应当使用session。
- session保存在服务器上。当访问增多，就会比较占用服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
-
印象最深刻的bug
我在weimi商城项目中新增商品信息的时候，遇到过这样一个印象深刻的BUG，我填写了相关信息，但是有一栏是空的，点击取消，反而显示新增成功。之后我们定位这个BUG，发现是前端调用接口错误，后端新增接口没有做验证，便返回新增成功。之后我们前端重新调用新增接口，后端重新修改新增接口的验证逻辑，便修复成功
-
软件测试流程
首先参与到项目的需求评审，然后在需求评审的阶段性提出问题，然后进行需求的整改，整改之后复评审，复评审之后确定到需求定稿通过之后，结合到需求中项目实现的技术内容 来制定一个完整的测试报告，定义好我们测试的工作内容，定义完成之后，我们会根据需求文档来进行测试用例的编写，编写完测试用例之后，我们会发起一个测试评审，测试评审中，我们会叫上产品经理，开发等相关人员以及测试的参与人员，我们会一起来做这个测试评审，由各方维度来评估我们的测试用例的覆盖面是否完整，以及说明业务流程是否能够很好的覆盖。覆盖完之后之后，我们会等待到开发提交版本，提交初版，我们接受初版之后会进入到系统测试。（系统测试之前会进行冒烟测试，来评估基础功能或者流程是否能够实现，通过就进入系统测试，不通过就返回给开发，让他们修改，提升代码质量），进入到系统测试之后吗，结合到之前定义的测试用例，对我们这个系统进行一个完整版本的测试，测试完成之后，我们在遇到了缺陷，就会把它记录到缺陷管理工具里面去，记录之后会追踪开发督促、修改和跟进缺陷的修复进度，修复完成之后，对于新版本再做迭代，再做迭代，再做迭代，我们不停的做迭代，一般迭代3-4个版本让我们的系统功能稳定下来，然后再通过一两个小的版本的迭代，最终定义好我们软件的质量，基于最终的测试结果，我们会生成测试报告，测试报告生成之后，我们就会来评估这个系统是否能够达到我们发布的标准，如果达到了我们的发布标准，测试通过，我们的系统就上线。
-
测试结束的标准是什么？
- 全包测试用例执行完成
- 测试报告编写完成
- 测试收尾工作结束
- 测试总结完成，项目处于试运行或上线阶段
-
什么是ＢＶＴ？冒烟测试？版本验证测试？怎么测？
也称冒烟测试、版本验证测试、小版本验证测试、版本构建测试、冒烟测试用例是一组想先运行以确定这个给出的小版本是否可以测试的测试用例。冒烟测试主要测试软件的基本功能，以判断整个软件值不值得进行大规模测试。通常由一个人进行1－2小时的测试，一般不测试次要功能和各种错误。
-
怎样根据线下环境评估线上环境的性能
- 首先线下必有有专门的性能测试环境
- 线下环境单台机器配置和线上不能相差很大，可以通过单台的机器性能推算出多台机器性能
- 如果线下机器配置很差，只能测算出程序有无性能问题，这样线下测试出来的数据对线上没有太大的参考意义
-
如何准备性能测试数据
- 调用业务接口去构造数据，一般适用于数据逻辑比较复杂的情况下
- 存储过程构造数据，一般适用于数据量巨大且数据逻辑较简单的情况
- 导入sql，一般用于数据安全级别较低且数据巨大的情况
-
你们的并发用户数是怎么确定的？
- 如果是已在线上运行的系统，会根据ＰＶ数据来确定
- 如果是新系统，根据需求文档来确定
-
性能测试的流程是什么？
- 性能需求的分析
- 搭建性能测试的环境（系统放在虚拟机还是服务器上面）
- 脚本编写
- 准备数据
- 执行测试
- 回归测试
- 测试报告
-
简单说一下对冒烟测试/集成测试的了解
-
冒烟测试
- 也称为小版本验证测试
- 对软件基本功能的验证
- 通过对软件基本功能的测试，确定是否进行后续大规模的测试，如果冒烟测试通过，则后续可以进行大规模测试，否则将软件打回给开发
- 一般，冒烟测试由一个人进行，通常消耗1-2小时
- 不同测试类型的冒烟测试可能会有不同，比如性能测试的冒烟测试需要的人力和时间会拉长
-
集成测试
-
主要是测试软件多个单元合并到一起时需要的测试
-
通常测试软件各部件之间的接口和交互
-
一般由多个懂开发的测试人员进行
-
-
给你一个网站，你如何测试？
- 首先，查找需求说明、网站设计等相关文档，分析测试需求
- 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能测试、界面测试、性能测试、数据库测试、安全性测试、兼容性测试
- 设计测试用例
-
功能性测试可以包括，但不限于以下几个方面
- 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回
- 提交功能的测试
- 多媒体元素是否可以正确加载和显示
- 多语言支持是否能够正确选择的语言等
-
界面测试可以包括但不限于以下几个方面：
- 页面是否风格统一，美观
- 页面布局是否合理，重点内容和热点内容是否突出
- 控件是否正常使用
- 对于必须但未安装的控件，是否提供自动下载安装的功能
- 文字检查
-
性能测试一般从以下两个方面考虑
- 压力测试，负载测试
-
数据库测试要具体决定是否需要开展
- 数据库一般需要考虑连接性，对数据库的存取操作，数据内容的验证等方面
-
安全性测试
- 基本的登陆功能的检查
- 是否存在溢出错误，导致系统崩溃或者权限泄漏
- 相关开发语言的常见安全性问题检查，例如SQL注入等
-
兼容性测试
- 浏览器的兼容性
- 操作系统的兼容性
- 软件平台的兼容性
- 数据库的兼容性
-
开展测试，并记录缺陷
- 合理安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）
-
定期评审，对测试进行评估和总结，调整测试的内容
-
- 软件测试的目的
- 验证软件是否满足各类文档说明书等规定的软件质量要求
- 找出软件缺陷
- 为软件产品的质量测量和评价提供数据
- 帮助开发改进开发流程
- 上一份工作中中每天执行多少测试用例
- 回答思路：正常情况一般每天执行20个左右的用例，（细分可以有很多），刚开始测试的时候，bug比较多，需要很多时间和开发交流沟通，案例执行会比较慢，越到后面就越快了。
- 你们回归测试的时候是否所有用例全部执行了呢？
- 看时间，如果时间比较充足，会全部回归，回归时候因为自己操作比较熟悉，然后系统基本上也没有bug，所以执行案例的数度会比较快。
- 如果时间比较紧，就会挑选重要模块来回归测试了。
四，接口自动化测试
-
网络协议
- 没必要了解 RPC ，微服务，restful这些知识，因为测试用不上
- 当你的薪资超过一定数额之后，你的知识体系的完整性就很重要了
- HTTP/ HTTPS —鉴权机制（cookies、session、token）一次接口请求的原理
- HTTP 1.0 的无状态连接和长连接
- 访问登陆接口，访问个人信息接口—用户未登陆（需要带上cookies）
- 一定要搞懂分布式服务、微服务框架这一类的内容是什么
-
接口关联
接口自动化测试不是单接口测试即可。接口关联的模块在自动化测试领域中是非常非常核心的模块
- 鉴权机制的处理（登陆是用cookies还是session），关联数据信息的传递方式（基于系统的业务流程和框架的设计上来进行定义）
- Mock
-
自动化测试框架的设计与配置：
-
框架的设计：
- 测试工具：是基于特定的场景所针对性研发的小软件
- 测试框架：基于系统来实现的完整自动化测试框架
- 测试平台：测试开发是开发测试平台的，自动化测试是做测试框架的。测试平台本身的研发在行业内属于极其小众的。（平台相当于一个web系统，平台只是用来忽悠不太懂）
什么叫自动化测试，什么叫测试开发？
- 自动化测试
- 用例的维护
- 自动化测试执行
- 自动化的结果分析
- 测试开发
- 研发测试框架
- 维护测试框架
- 研发测试工具
-
框架的配置：
- 环境配置：可以满足快速维护和一键切换
- 日志配置：
- 持续集成：邮件信息、内容模板、报告模板等
-
-
什么情况下要做关联，关联是怎么做的？
- 当脚本的上下文有联系，就用关联
- 如商品需要id，登陆需要cookies
-
一个好的测试用例，有哪些特定
- 用例要完整，简介，一致
- 用例要表面测试目的
- 用例覆盖程度要高
- 用例能够使工作最小化
- 用例描述正确、规范
- 用例的分类以及描述要清晰
- 用例要具有可测性
- 测试用例易于维护（如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢？）
- 可重复性，可追踪性
四，数据库方面
数据库：
① 索引
1. create unique index index-name on 'table-name' (字段名(length));（唯一索引）
2. create index index-name on 'table-name'(字段名(length));（普通索引）
②存储过程以及增删改查、子查询、多表连查。
存储过程思想上很简单，就是数据库 SQL语言层面的代码封装与重用。
create procedure mypro (in a int,in b int,out sum int)
begin
set sum = a+b; //需要执行的代码
end;
五、python自动化；代码熟悉程度
- get与post区别
六，测试用例
测试用例：
-
微信发红包设计测试用例；
主要从两个大的方面来说：功能性测试和非功能性测试
功能性测试可分为三种情况：一对一发红包，群发红包，一对一和群发的通用测试
功能性测试
一对一发红包：红包最大，最小的金额（边界值测试0.01,1,5,10,99,101,199,200,201）
群发红包：
（1）红包个数：拼手气红包最多可以发多少个，超过最大个数是否有提醒
平均红包，每个人领的是否一样多
专属红包，给指定的人发红包
（2）红包金额：最大20000
（3）发送红包是否成功
（4）抢红包：拼手气红包每个人抢的钱数不一样
发送的红包未被领取完，24小时是否退回原账户（零钱，银行卡，零钱通）
自己是否可以领取自己发的红包
一个人是否可以多次领取红包
如果群里有50人，发了100个红包会是什么样子
一对一和群发的通用测试:
红包封面：不选择会有默认封面
选择之后是否会有专属封面
红包描述：在红包描述中是否可以添加文字，英文，表情，数字，动态表情（是否可以输入他们的 混搭）添加之后是否可以正常删除
红包描述中最多可以输入多少个字符
红包描述中发出的描述抢红包的人是否能看见
红包金额：在红包金额的框中只能输入数字
超过最大输入金额是否会有提示
发出的金额和收到的金额是否匹配
发红包的扣款顺序：默认顺序：零钱，当零钱余额不足时，看哪一种方式付钱比较充足
主动设置优先级
确认的时候，自己选择付款的方式
支付验证的方式：密码，指纹，人脸识别，免密
取消发送：返回键可以取消发送红包
发送红包：发出去之后不能撤回
红包记录：在发红包界面能否看到以前的收发红包记录
是否可以连续多次发红包
电脑端是否可以抢红包
非功能性测试：
性能测试：断网时，是否还能抢红包
不同网速抢红包，发红包的时间
收发红包的耗电率
收发红包的跳转时间
兼容性：不同系统下（iOS，安卓），同一系统下的不同版本是否都能收发红包
安全性：红包发送后，发送人的金额会减少，接受人的金额会增多
给陌生人发红包时，是否会收到安全提醒
易用性：红包描述，金额，红包个数框中是否支持复制粘贴
红包描述是否支持语音输入
是否可以通过指纹支付，免密，人脸识别
-
朋友圈点赞设计测试用例；
-
朋友圈评论测试测试用例；
-
微信发图片设计测试用例；
-
支付宝充值话费/微信充值话费设计测试用例