面试题总结

测试分类

按阶段划分：单元测试 集成测试 系统测试 验收测试
按是否运行程序划分: 静态测试  动态测试
按是否查看源代码划分：白盒测试 黑盒测试-功能测试（逻辑功能测试 界面测试 易用性测试 安装测试 兼容测试）性能测试（一般性能测试 稳定性能测试 负载测试 压力测试）  
其他：回归测试 冒烟测试 随机测试

软件测试流程 开发流程

从产品立项开始,我们(项目经理产品经理开发人员测试等)内部会开立项会在立项会中进行对需求进行
评审,制定需求文档,前端进行设计页面开发人员根据需求文档进行编码,测试需要制定测试计划,已经对
需求进行颗粒划分，不同的测试人员根据自己的任务编写测试用例,然后对用例进行评审,开发提交代码
后执行冒烟测试，如果冒烟测试结束后执行用例如果发现 bug则提交bug,让开发人员进行修改，修改后
进行二次验收，bug修改正确后关闭该bug,如果没有重新打开并进行跟踪bug，项目结束后需要进行编写
测试报告。

开发模型 V W

V模型：用户需求-需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试
W模型：需求分析-概要设计-详细设计-编码实现-模块集成-系统构建-系统安装
      需求测试-概要设计测试-详细设计测试-单元测试-集成测试-系统测试-验收测试
      W模型 是由两个V模型组成，分别代表测试和开发的过程，表示 测试和开发是同时进   行的。相对于V模型，增加了软件开发阶段中应同步进行的 验证 和 确认 活动。

测试过程中各个阶段的需要的文档和测试产物

需求阶段       输入需要的文档                      输出文档
设计审查       测试计划测试用例                    测试用例和测试环境
单元测试       源码程序设计文档                    缺陷报告 跟踪报告 完善用例
集成测试       集成测试规格说明书和程序设计文档       缺陷报告 跟踪报告 集成测试分析报告
功能验证       软件包 文档                        缺陷报告 功能验证测试报告
系统测试       修改后的,软件包 系统测试用例 测试计划   缺陷报告 缺陷状态报告 阶段性报告
验收测试       规格说明 预发软件包 确认测试用例      用户验收报告 缺陷报告 版本审查 最终测试报告
版本发布       软件发布包 发布检查清单              当前已知问题清单 版本发布报告

测试原则 用例评审的标准/结束

原则：1.测试证明软件存在缺陷
     2.不能执行穷尽测试
     3.缺陷存在群集现象
     4.某些测试需要依赖特殊的环境
     5.测试应尽早介入	
     6.杀虫剂现象
标准：完整性 正确性 可行性 一致性 无二义性 健壮性 必要性 可测试性 可修改性 可跟踪性 一共十个

你在上一个项目中的印象最深bug是什么？ 怎么发现的？ 怎么解决的？

1. 查询订单页面，根据条件筛选的结果不是想要的结果，还有某些字段的值没有显示出来，或者显示
错误。（因为开发从库表取值有误）
2. 修改支付密码，新密码和原密码一致，也通过了，系统没有做新旧密码的校验。

开发不认为是bug的时候你怎么办？

1.尝试多种测试环境和测试步骤来验证BUG是真实存在的，详细记录bug的复现步骤
2.需要根据bug的严重程度找项目经理或测试主管进行验证确定是否为bug
3.可以找产品根据需求文档对bug进行验证
4.需要将bug在测试报告中进行解释说明留下备份，防止后期版本迭代的时候产生问题

项目上线后发现bug你怎么办？

一. 第一步 — 评估bug的影响范围
（1）分析bug影响的用户数量
检查bug是否业务核心环节的功能问题，是的话则影响的用户量比较多
（2）分析bug影响的严重程度
检查bug是否涉及到用户的个人信息泄露、资金财产损失等比较敏感的功能，涉及的话则
认为bug比较严重
对于bug影响范围的评估，必须尽可能的快速且准确，因为影响范围和程度会随着时间不
断扩大，及时了解目前的bug影响，可以为后续解决问题提供最适合的指导意见。
二. 第二步 — 解决线上问题
针对线上问题最重要的是要解决，在评估完影响范围后，就需要制定对应的措施来解决问 题并恢复系统的正常使用。
（1）影响范围比较小的bug
了解bug出现的场景，业务操作，努力复现bug
测试人员结合bug出现时的各种日志（系统日志、数据库日志、操作日志、debug日
志），定位bug产生的原因
按照项目规划的发布/升级的时间节点，将bug修复的代码发布到线上，bug解决
（2）影响范围比较大的bug
bug影响范围比较大时，如果还是通过修复bug的方式来解决，对用户的影响或者公司的
损失无法把控，此时最重要的是：将问题范围降到最低。无法明确问题引入原因时，可
以通过回滚版本的方式来规避。部分用户功能可以通过后台配置的方式将功能降级或关
闭，如果是资源不足等性能问题时，可以通过重启系统或者扩容的方式解决，再进一步
观察，以上几种规避问题的方法只是帮助我们争取到时间，规避问题后还是要按照之前
修复bug的方式来定位问题，修复问题，并将修复的代码发布线上，将bug彻底解决。
在实际工作中，我们需要根据bug的影响范围来选取最适当的解决方法，目的只有一个：
将问题影响范围降到最低。
三. 第三步 ——回溯线上问题
当线上问题解决后，我们还需要对问题进行总结回溯，避免同样的问题再次发生。线上
问题回溯主要从如下几个方面进行：
（1）检查其他的业务是否有同类型的问题
有问题的话提前解决，避免遗漏上线
（2）分析bug的根本原因，考虑如何避免此类问题再次发生
分析bug是在哪个阶段引入？是设计阶段、开发阶段、测试阶段？
分析bug引入的原因是什么？是流程问题、技术问题、管理问题？

你是否有独立编写过测试计划,测试计划中有哪些内容？

根据需求，产品原型图编写测试计划  测试背景、工期评定、人员安排、进度安排、测试轮次

你在项目中用到的测试方法有哪些以及对应场景 ？

1.等价类划分法：多用于输入框 登录注册
2.边界值分析法：和等价类划分结合使用，有边界限制的，注册密码的长度
3.错误推测法：基于经验和直觉推测程序中可能发送的各种错误，有正对性的设计，用于使用同类产品
4.因果图法 判定表 正交表：适合检查程序输入条件的各种组合情况（自动贩卖机）
5.场景法：从基本流开始，再将基本流和备选流结合起来，可以确定用例场景（银行取钱）

用例提取点 功能 性能 易用 安全 界面 网络 （ 如：微信发好包 视频播放 水杯 购物车 朋友圈点赞 上传文件）

包的测试用例？
1. 功能：
a)在红包钱数，和红包个数的输入框中只能输入数字
b)红包里最多和最少可以输入的钱数 200 0.01
c)拼手气红包最多可以发多少个红包 100
d)超过最大拼手气红包的个数是否有提醒
e)当红包钱数超过最大范围是不是有对应的提示
f)当发送的红包个数超过最大范围是不是有提示
g)当余额不足时，红包发送失败
h)在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，
i)是否可以输入它们的混合搭配
j)输入红包钱数是不是只能输入数字
k)红包描述里许多能有多少个字符 10个
l)红包描述，金额，红包个数框里是否支持复制粘贴操作
m)红包描述里的表情可以删除
n)发送的红包别人是否可以领取
o)发的红包自己可不可以领取 2人
p)24小时内没有领取的红包是否可以退回到原来的账户
q)超过24小时没有领取的红包，是否还可以领取
r)用户是否可以多次抢一个红包
s)发红包的人是否还可以抢红包 多人
t)红包的金额里的小数位数是否有限制
u)可以按返回键，取消发红包
v)断网时，无法抢红包
w)可不可以自己选择支付方式
2. 兼容：
a)苹果，安卓是否都可以发送红包
b)电脑端可以抢微信红包
c)界面
d)发红包界面没有错别字
e)抢完红包界面没有错别字
f)发红包和收红包界面排版合理，
g)发红包和收到红包界面颜色搭配合理
3. 安全：
a)对方微信号异地登录，是否会有提醒 2人
b)红包被领取以后，发送红包人的金额会减少，收红包金额会增加
c)发送红包失败，余额和银行卡里的钱数不会少
d)红包发送成功，是否会收到微信支付的通知
4. 易用性(有点重复)：
a)红包描述，可以通过语音输入
b)可以指纹支付也可以密码支付

你在上一个项目中你写了多少用例以及你每天能写多少用例 50-80

每天写用例50-80个

用例中的栏位 测试计划 缺陷报告

测试用例栏位：用例编号 所属模块 执行条件 执行步骤 预期结果 实际结果 用例是否通过 测试人 版本 备注
缺陷报告：缺陷ID 测试用例ID 缺陷描述 重现缺陷操作 缺陷严重程度  状态  发现日期 测试者
测试计划：根据需求，产品原型图编写测试计划  测试背景、工期评定、人员安排、进度安排、测试轮次         
缺陷报告：
1. Bug的优先级
2. Bug的严重程度
3. 开发的接口人员，与Bug产生对应的软件版本
4. Bug可能属于的模块。如果不能确认，可以由开发人员来判读
5. Bug标题，需要清晰的描述现象
6. Bug描述，需要尽量给出新的Bug步骤
7. Bug附件中能给出相关的日志与截图

编写用例的维度

1. 覆盖用户的需求；
2. 从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
3. 通常，一个测试用例对应一个场景；
4. 用例各个要素要齐全，步骤足够详细，容易被其它测试工程师读懂，并能顺利执行；
5. 做好用例评审，及时更新测试用例。

某个功能点测试用例

未登录时：
点击购物车，页面跳转到登录页面，登录成功后，页面跳转到购物车页面
点击商品，加入购物车，页面弹出登录窗口，登录成功后，商品加入购物车成功
登录后：
增：
点击商品详情页，点击加入购物车，商品是否加入成功
对同一商品多次添加，购物车界面如何显示
添加不同属性的同一商品，购物车界面如何显示
添加同一店铺的不同商品，购物车界面如何显示
添加不同店铺的商品，购物车界面如何显示（排序）
添加商品成功后，购物车数量是否显示正确
购物车添加商品是否有数量限制
购物车页面打开的同时，在其它页面添加了商品，刷新购物车页面，新的商品是否显示
删：
单个删除：
选择商品，点击删除，商品是否成功删除
点击商品后的删除，商品是否成功删除
不勾选商品时，页面底端删除，移入收藏夹，分享是否可用
批量删除：
点击全选按钮，点击删除，购物车是否被清空
有失效宝贝，点击清除失效宝贝按钮，是否能清除失效宝贝
改：
在购物车页面中，可以对添加商品信息做信息的修改，并自动保存成功
卖家在线时，旺旺图标高亮显示
购物车列表为空时，全选，结算按钮是否可用
未勾选商品时，结算按钮为灰色
购物车中的降价商品，库存紧张商品是否成功分类
购物车商品降价时，购物车是否显示降价信息
购物车商品有优惠时，购物车是否显示优惠信息
所有界面链接正常，可以跳转到正常页面
对于失效商品，购物车是否有提示
购物车不为空时，点击全选按钮，商品是否被全选，价格是否正确，结算按钮变高亮
购物车商品降价时，购物车是否显示降价信息
购物车商品有优惠时，购物车是否显示优惠信息
所有界面链接正常，可以跳转到正常页面
商品名过长是否显示完整
商品后移入收藏夹，相似宝贝是否可用

如何保障测试用例的最大覆盖度？

项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面。来讲解一下自己对测试点的理
解，用例编写完之后，再进行用例评审，看看测试点有没有遗漏，测试场景是否完全覆盖。

你们测试组是如何分工的

一个测试经理，3个测试组长，每个组有5个测试人员：包括自动化测试、，功能测试、性能测试等的测试工程师

开发环境 测试环境 生产环境的区别

开发环境：是在编码阶段，一般我们的代码基本上都是在开发环境中，不会再生产与测试环境，如操作系统，web服务器，语言环境，php,数据库等等。
测试环境：项目完成后，找Bug,以及修改Bug。
生产环境：项目数据前后端已经疏通，部署到阿里云上有客户去使用以及访问，网络正常运行就好了。

给你web、app端项目你如何展开测试?

web端(京东购物网页)：1. 首先要先进行需求分析，xmind梳理测试点，编写案例，案例评审，寻求他人意见，再完善案例，交给其他人检查。
2. 测试点：如UI，美观度，易操作型，易理解型方面进行测试。
3. 在考虑功能点，如登陆注册，添加购物车，下单，付款，发货，确认收货，评价。
4. 性能方面：如打开网页，确认订单，付款的响应时间等。
5. 兼容性：如支持各种主流浏览器，如（IE,360，火狐，谷歌等）。
app端：1.根据原型图进行UI页面设计
       2.根据需求文档进行功能测试
       3.拉取代码打包进行安装，卸载，软件升级等测试
       4.考虑对应安全权限问题
       5.正常网络的消息推送
       6.在弱网或无网的情况下进行测试
       7.app在不同的手机品牌不同的手机版本不同安卓版本以及不同分辨率上的使用
       8.app在电流 电压 流量的损耗
       9.app在系统资源的损耗（cpu 内存 io）
       10.app的前后台切换以及多进程的时候
       11.app的稳定性测试

bug的状态和bug的生命周期

生命周期：新建 确认 解决 重新验证 关闭 重新打开
状态：new open fixed pendingReset closed Reopen