[开发测试]软件测试知识点和面试题--手工测试篇（功能测试）

熟悉项目

熟悉新项目
1.根据项目的UI界面和需求文档，使用思维导图整理项目的组织结构架构图（页面级别）
    目的：了解页面实现的功能
2.根据整理的架构图，针对于每一个页面对于每一个功能去点击；梳理项目的核心业务流程，以文字的形式去描述业务流程
    哪个系统－哪个页面－哪个按钮
3.结合架构图+核心业务流程＝项目的核心功能模块（实现核心业务流程需要使用到功能模块），在X-Mind使用小旗子标识出核心功能模块

项目介绍

一、业务特性(项目是干什么的？)
二、项目结构(组成的子系统，使用方和作用)
三、项目的核心模块(你负责测试的模块)
四、项目的核心业务流程(重点)
五、项目技术架构

软件质量模型

双V模型（测试阶段对应的文档）

测试分类?

1）根据测试方法来划分

黑盒测试：最基础的功能测试，不关心内部的代码实现，而仅验证输入输出的正确性。
白盒测试：基于逻辑驱动或者基于代码测试，打开代码内部的实现，去研究源代码中的接口或者具体实现的正确性。
灰盒测试：介于二者之间的一种测试。

2）根据测试目标来划分

功能测试：对产品和模块的各个功能进行测试
性能测试：对系统的各项性能指标进行测试
压力测试：测试软件或系统的负载能力，挖掘隐患
兼容性测试：对产品和软硬件之间的兼容性进行测试，比如软件在各种不同安卓机型上的兼容性。
安全性测试：通过不同方法发现软件的安全性问题，比如信息泄露、非法使用、恶意破坏等等。
其他专项测试：比如弱网络测试、耗电量测试、流畅度测试等等

3）根据软件开发阶段来划分

单元测试：对程序中的独立模块进行白盒测试，目的是检验软件基本组成单位的正确性
集成测试：通过对单元模块进行组合测试，目的是验证单元模块之间的接口是否正确
系统测试：对整个系统进行完整测试，验证整个系统的正确性与合规性
回归测试：当软件发生变更的时候，对这次变更可能受影响的功能模块进行验证
验收测试：测试的最后一个阶段，软件发布或者上线前确保软件质量

4）其他常用测试概念

冒烟测试：冒烟测试是对软件最基本的功能进行简单测试，低成本的判断软件是否可测
    冒烟测试来源于硬件的测试，当电路板做好后，首先会进行一次加电，如果没有冒烟才会开始进行接下来的测试，否则说明产品没有达到最基本的质量要求，需要重新制作。
?
探索性测试：探索性更多的依赖测试人员的个人经验或者特长，依靠的是测试人员的主观能动性。
    探索性测试的重要性可以参考游戏测试领域，千千万万的玩家会在各种意想不到的环境下以意想不到的方式来进行游戏，所以游戏的测试者不仅要掌握系统的测试方法论、先进的测试工具以外，还要有丰富的游戏经验和探索的测试思维。

α 测试和β 测试

测试流程

需求评审

测试计划和方案

用例设计和评审

?用例执行

缺陷管理

测试报告

白盒测试

覆盖率从高到低：
    路径覆盖--要把每一条路的每一种组合都走一遍
    条件组合覆盖--每个判断中的每个子句的组合都要覆盖
    条件判断覆盖--条件覆盖和判断覆盖组合
    条件覆盖--每个判断中的每个子句的不同TRUE、FALSE都要取一次
    判断覆盖--能够在每个判断取至少一个TRUE，和至少一次FALSE
    语句覆盖--条件和执行语句覆盖到

面试题

优惠券的测试点

1.叠加能不能使用
2.是否重复使用
3.过期能否使用
4.有效时间能否使用
5.发行100张优惠劵的话，超过一百张优惠劵还能继续领
6.同类型优惠劵同一个人是否可以多次领取，如果一个人多次领取，用完一张，数量要减一等
7.用了优惠劵，超时付款后，如果优惠劵在有效期内，能原路退回，还能继续使用
8.如果优惠劵在退回的时候已经过期，这就要根据需求来显示，并且无法再次使用
9.过期的优惠劵，在待使用优惠劵列表中不能显示

如何测试支付业务？

基于之前项目中做支付场景,当时测试的时候分成两种方式进行测试。由于我们的支付渠道:微信、支付宝、银行任意选，没有开通测试接口，只能进行真实支付。所以采用的第一种方式:在确认订单后修改订单金额为1分钱,测试支付成功后的跳转。其它异常情况正常测试即可:如余额不足、密码错误等。 基于接口测试层面,采用mock模拟接口的方式，模拟银行各种异常返回，检查我们系统对应响应处理是否正确即可。

给你一个网站你如何开展测试工作？

1.首先查找需求说明、网站设计等相关文档，分析测试需求；

2.制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测，试界面测试，性能测试，数据库测试，安全性测试，兼容性测试；

3.设计测试用例：
- 功能性测试可以包括，但不限于以下几个方面：
    链接测试：链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等；
    提交功能的测试；多媒体元素是否可以正确加载和显示；
    多语言支持是否能够正确显示选择的语言等；
- 界面测试可以包括但不限于一下几个方面：
    页面是否风格统一，美观；
    页面布局是否合理，重点内容和热点内容是否突出；
    控件是否正常使用；
    对于必须但为安装的空间，是否提供自动下载并安装的功能；
    文字检查；
- 性能测试：
    压力测试，负载测试，强度测试
- 数据库测试：要具体决定是否需要开展
    数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
- 安全性测试：
    基本的登录功能的检查；
    是否存在溢出错误，导致系统崩溃或者权限泄露；
    相关开发语言的常见安全性问题检查，例如 SQL 注入等；
    如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持。
- 兼容性测试：
    根据需求说明的内容，确定支持的平台组合：浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性。

4.开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）；

5.定期评审，对测试进行评估和总结，调整测试的内容；

没有需求文档，你会如何执行测试？

假如没有需求文档我会从以下一些方面着手:
1.根据客户的功能点整理测试需求追朔表
2.根据开发人员的Software Specification List整理我们的功能测试点
3.开展项目跨部门讨论会
4.测试人员整理用例需求疑问递交项目组和客户代表回复
5.项目内部用例评审
6.邮件和客户代表确认部分争议问题
7.项目Demo和部分已开发系统
8.参考同行业和竞争对手的类似产品
9.交叉模块的测试要注意
10.咨询客户部分需求疑问

给你一个物件（杯子、花瓶、笔、桌子）你怎么测试？

无论是哪个物件,都从以下几个维度出发设计:
1、UI
2、功能
3、性能
4、安全
5、接口
6、易用性

举例，面试官问给你一个杯子你怎么测，至少写出20条测试用例：
1.功能测试：
主要关注水杯基本功能
    1.1 水杯是否可以正常装水
    1.2 水杯是否可以正常喝水
    1.3 水杯是否有盖子，盖子是否可以正常盖住
    1.4 水杯是否有保温功能，保温功能是否正常保温
    1.5 水杯是否会漏水，盖住盖子拧紧后是否会漏水
2.ui测试：
主要关注水杯外观、颜色、设计等方面
    2.1 外观是否完整
    2.2 外观是否舒适
    2.3 颜色搭配及使用是否让人感到舒适
    2.2 杯子外观大小是否适中
    2.3 杯子是否有图案，图案是否易磨损
3.易用性测试：
主要关注水杯使用是否方便
    3.1 水杯喝水时否方便
    3.2 水杯拿起放下是否方便，这里会衍生到水杯形状的测试
    3.3 水杯装水是否方便
    3.4 水杯携带是否方方便
    3.5 水杯是否有防滑功能
    3.6 水杯装有低温或者高温水时，是否会让手感到不适
4.性能测试：
    4.1 水杯装满水时，是否会漏出来
    4.2 水杯最大使用次数
    4.3 水杯的保温性是否达到要求
    4.4 水杯的耐寒性是否达到要求
    4.5 水杯的耐热性是否达到要求
    4.6 水杯掉落时，是否可以正常使用
    4.7 水杯长时间放置时，是否会发生泄露
5.安全性测试：
主要关注水杯外观和各种异常条件下是否释放有毒物质等
    5.1 当水杯装满热水时，水杯是否会烫手
    5.2 当水杯装上水后，是否会产生有毒物质
    5.3 把水杯放在零下环境时，是否会产生有毒物质
    5.4 把水杯放在高温环境时，是否会产生有毒物质
6.兼容性测试：
主要关注水杯是否可以装其他液体，如果汁、汽油、酒精等
7.可移植性测试：
主要关注水杯放置环境等
    7.1 将水杯放在常温环境中，使用是否正常
    7.2 将水杯放在零下的环境中，使用是否正常
    7.3 将水杯放在高于正常温度的环境中，使用是否正常

如何执行的兼容性测试？-web兼容和app兼容

（1）Web 兼容性测试
①首先开展人工测试，测试工程师测试主流浏览器和常用操作系统测试主流程和主界面，看看主流程和主界面是否有问题，如果存在问题，那么记录下 bug 情况，以及浏览器型号和版本，以及操作系统，准确定位 bug 产生的原因，提交 bug，告知开发人员修改。所有的主流设备都需要进行测试，只关注主流程和主界 面，毕竟每个系统主流程和主界面不是很多，所以这个工作量还是可以承受的。

（2）APP 兼容性测试
①：APP 的兼容性测试和 Web 测试类似，首先开展人工测试，测试工程师借助测试设备对主流程和主功能，主界面进行测试；收集所有的能收集到的不同型号的测试设备测试主流程和主界面，看看主流程和主界面 是否有问题，如果存在问题，综合考虑设备的使用率等因素，看看是否需要调整，如果需要，那么记录下 bug 情况以及测试设备的型号和操作系统，准确定位 bug 产生的原因，提交 bug，告知开发人员修改。

②其次借助第三方测试工具，对于 APP 的兼容性测试，推荐的是百度众测平台和云测平台，我经常使用的是云测平台，这两款测试工具里面包含了安卓和 iOS 的测试；测试很齐全，包括功能测试、深度兼容测试、性能测试、网络环境测试，还可以模拟海量用户测试，，还可以导入自己编写的测试用例进行功能测试，里面还包括测试专家的测试，当然了找专家是要花钱滴。基本进行兼容性测试是不需要花钱的；测试工程师把打包好的 apk 或者 IPA 文件，上传到测试平台，选择需要测试的设备型号，开始任务即可；等待一段时间，在等待的时间你是不需要盯着的，你可以做其他的工
作。测试完成后会生成一份测试报告，可以查看错误页面和错误日志，如果需要调整，那么提交 bug，告知程序员修改即可。

需求发生变化，你会如何处理？

分两种情况
1、本次需求变更的内容对应模块还没有进行测试
    1.1 评估需求变更对应功模所带来的工时是否大于原来该模块的测试工时
    1.2 如果超过原有模块的测试工时，影响测试计划则需要考虑以下几点，看是否的能在原计划的范围内内部消化：加班、协调资源、根据现有测试过的模块情况来分析是否可以调整一些测试时间、如果所有方式都已经考虑则反馈给测试负责人或项目经理来进行协商
2、本次需求变更的内容对应模块已经完成了测试

多久做一次版本迭代？如何进行回归测试？

一般分大版本和小版本，大版本主要是产品规划的新功能、新业务，小版本主要是一些历史功能优化和缺陷修复版本。
大版本一般2-3个月一次。小版本每周都会有。
1、缺陷回归：触发缺陷查看缺陷是否已经修复；
2、历史功能回归：跟项目经理以及开发确认本次版本迭代影响的功能范围，对于影响的功能范围以及核心业务流程、关键点，挑选正向的用例进行回归测试；同时利用版本迭代的空闲时间，对历史功能回归测试实现UI自动化

提交了一个缺陷开发不认为是缺陷你会如何处理？

个人在以前的测试过程中,很少出现这种问题。一般情况下我提交缺陷前都会反复的确认,也会尽量的保障缺陷额有效率和清晰度。

如出现该情况，首先我会找到对应的开发人员，询问对方拒绝或不认为是缺陷的理由。

如在对方的描述过程中发现明显的问题，且有明确的证据情况会摆明需求甚至当场重新给其确认。

如在其阐述理解的过程中没有问题，或者说其在对于需求的理解中也没有明确的错误，那证明对于需求的理解出现的了歧义，直接找产品或项目经理确认达成共识即可。

测试时间不够了，项目又必须上线，你会如何处理？

这里测试时间不够了，可能导致原因有很多,如开发或缺陷修复质量不高，导致无法顺利执行测试。
另外需求的变更导致计划控制不合理等等，但是不管那种原因，客观时间不够了是事实。

那我的话一般会做如下方式来进行处理:
第一迅速盘点剩余测试工作量,是否可以通过加班或协调资源的解决问题，保障项目上线。
第二是否可以根据项目，各个模块的现有测试情况，来调整原有测试计划的分配工。如部分模块无较大问题，是否在风险可控的情况。减少测试工时。
第三是否可以借调产品和开发分摊部分简单的测试任务
第四原有复杂的业务功能是否有替代上线方案
第五是否可以占用部分产品验收时间
第六是否可以裁剪部分功能

如何保障测试用例的覆盖率？

1.编写测试用例前，先熟悉项目，看看相关需求文档是否有问题（功能描述不清，设计逻辑缺陷），如有问题找相关设计或者开发问清楚。
2.采用测试用例设计方法:如判定表、等价类、边界值、流程图等
3.组织用例评审，进行查漏补缺

生产环境中有没有出现比较严重的问题？如果有的话有什么的方法可以降低带来的风险？

1.在之前的项目测试经验中,线上暂时没有出现过比较严重的问题。
2.如果出现严重的缺陷的话,我会思考一下的一些问题,看是否能降低风险:
    第一:先确认导致问题出现的原因,如果是代码逻辑错误,证明漏测-则需要加强测试力度、加强测试用例评审力度
    第二:如果是遗漏代码,测试后提交,加强代码封板把控，而上线前必须同步最新代码，测试确认。
    第三:如是需求实现错误,加强需求评审力度。
    第四:采用灰度上线,大型版本先只对部分用户开放，稳定后再全面升级。

你们有多少个测试环境，分别有哪些？

之前的项目中有三个测试环境三个，测试环境，回归环境，预发布环境。

测试环境，也就是我们测试同学干活的环境啦，一般会由测试同学自己来部署，然后在此环境进行测试。bug修复后，需要发版更新测试环境来回归bug。

回归环境，回归bug的环境，其实就是我们的测试环境，在测试环境上测试、回归验证bug。

预发布环境，测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量，软件测试环境包括硬件环境和软件环境，

有没有部署过测试环境，简单的描述下如何部署的？

检查服务器》安装中间件》上传版本包》数据库初始化》修改配置文件》重启服务

在之前的项目中,我们的系统使用的应用服务架构是:Linux+Nginx+Tomcat+Mysql。

在进入测试前,开发已经将整套的服务器架构都已经搭建好，所以对应的中间件和工具环境不需要再重新部署。
当时我去部署的过程,主要是更新一些新的测试版本。会从git上面获取到开发的源代码到我的本地电脑,并使用开发提供的编译打包命令，进入到源码所在路径,执行mvn clean install即可获取得到一个可部署的源码包,(TARGET)*****(可以自己起名,例如叫自己的项目的英文缩写).war文件。通过SSH远程连接工具MobaXterm将源代码上传到Linux测试服务器。停止测试环境tomcat服务,备份原测试war包。将刚上传的***.war移动至tomcat指定的项目部署目录webapps,重启通过tomcat/bin目录下的startup.sh启动服务器。最后到本地机器访问测试域名地址，如能成功访问则代表部署成功了。

另外我还了解过jenkins可以执行持续构建部署方式.如有需要可以进行简单运用。

Fiddler主要用来做什么？如何分析抓取的数据信息是正确的？如果是加密的内容你怎们处理？

1、分析缺陷是前端的问题还是后端的问题。
例如:提交订单的请求地址：
① 界面组织提交订单商品数据，点击【提交订单】，触发发送请求
② 后台代码进行处理，处理完成之后，返回订单相关数据。返回的数据由开发者来决定（需求来决定到底返回哪些数据）订单编号、订单金额
例如订单金额在界面显示错误，抓取提交订单响应数据，查看接口返回信息中订单的总额是否是正确。如果接口中订单总额正确，则是前端的问题，如果是响应信息中订单总额是错误，则是后端的问题。

2、前端对于输入信息做了对应限制，不代表后端代码也做了限制，每个请求地址对应懂IT的人的来讲都是能够直接跳过前端页面进行操作的。验证后端对于异常输入的是否也有做对应限制。

3、接口测试测试每个请求的实现情况。部分公司的开发没有编写接口文档，则可以通过抓包工具获取到具体接口地址。

4、做手机端弱网测试

有没有做过弱网测试，简单的说下？

首先让手机和Fiddler连接同一个网络；
接着手机设置代理，代理服务器IP为电脑IP，端口号为FIddler的默认端口8888，如果是HTTPS协议的，手机需要安装Fiddler的证书；
然后Fiddler开启弱网相关的设置，Rules->Performance->勾选 Simulate Modem Speeds，在Rules—>Cutomize Rules设置上传和下载的参数，从而可以进行弱网测试；

Fiddler如何抓取苹果手机包？描述下过程？

基于苹果手机抓包:
1、在Fiddler配置项中要设置勾选抓取HTTPS，自动下载HTTPS证书
2、开启网络服务监听端口:勾选Allow remote computers to connect，端口号可默认为8888
3、打开iphone浏览器，在地址栏输入http://ip(电脑的ip):8888(fiddler中默认的端口)，点击“FiddlerRoot certificate”安装证书
4、设置iphone代理:手机连接wifi后，打开wifi详情，滑动至屏幕底部的http代理，点击进入修改成“手动”，设置ip（电脑的ip）及端口(fiddler中的8888)后保存启用证书方法：设置——通用——关于本机——证书信任设置

有没有制定过测试计划？测试计划包含什么内容？依据什么来制定的测试计划？

在我们的项目中测试计划主要涵盖:测试范围、测试资源、任务分配、阶段任务完成时间节点，偶尔会加上风险评估、测试环境等相关说明。

一般情况下会依据需求文档，确认测试范围的测试点，拆解文案、开发计划文档、产品/运营的目标上线时间，以及当前测试人力资源情况，来制定测试计划。

你们公司是如何管理的缺陷？缺陷处理的过程是怎么样的？

1.测试人员发现并确认缺陷，在禅道记录缺陷，将其指派给指定模块开发人员。如优先级或缺陷等级比较高，同时会直接通知对应开发人员尽早修复。

2.开发人员到禅道领取缺陷，分析缺陷并进行处理。当开发人员进行处理并认为已经解决之后，就可以将这个缺陷的状态设置为:已修复，并将其返还给测试人员。

3.测试人员进入系统查看缺陷，并测试验证缺陷。如果经过再次测试发现缺陷仍然存在的话，测试人员将缺陷再次传递给开发人员，并将缺陷的状态设置为“重新打开”。如果测试人员经过再次测试确认缺陷已经被解决，就将缺陷的状态设置为“已关闭”。

4.如果测试经理收到某缺陷被拒绝通知，验证该缺陷，如果确实不能算作缺陷，关闭缺陷，将缺陷状态设置为“已关闭”。如果认为的确是一个缺陷，修改缺陷描述，并将其重新指派给开发经理，并将缺陷的状态设置为“新建”。

如何评估缺陷的优先级和严重级别？

优先级:指开发修复缺陷的先后顺序,严重级别:指发现的缺陷对产品质量影响的严重程度
（要注意的是，开发会根据优先级来进行参考，决定修复先后顺序.所以高优先级不一定就是致命的缺陷）

优先级：
高（P1）：缺陷严重，影响测试或产品目的，需优先考虑。
    如：产品的版权未更正、技术性的不正确内容等。应用程序包版本不对、无法安装导致无法测试、闪退、崩溃等
中（P2）：对产品来说不是那么关键的场景或特性。
    如：在小标题上发现的错误、从历史版本中来的遗留bug等。
低（P3）：对产品使用没有太大影响。
    如：在低使用频率页面中发现的bug、很少被使用的功能等。文字重叠、错别字等UI方面的缺陷，不易操作等。

严重级别：
    A类-致命缺陷（Fatal）：造成系统或应用程序崩溃、死机、或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。
    B类-严重缺陷（critical）：系统的主要功能部分丧失、数据不能保存。如致命的错误声明，程序接口错误等约束条件
    C类-一般缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间等，
    D类-轻微缺陷（Minor）:使操作者不方便，但它不影响功能过的操作和执行，如错别字、界面不规范
    E类-意见优化（Enhancemental）：由问题提出人对测试对象的改进意见。

版本测试通过的标准是什么？

1、需求规格说明书中的需求必须全部实现并测试通过
2、测试用例执行率100%
3、无一般、严重、致命等级缺陷
4、遗留缺陷和产品或项目经理沟通可以延迟处理

生产环境发现缺陷你会如何处理？

⑴ 在公司的缺陷管理系统（如：禅道）中记录该缺陷
    1.bug等级
    2.提供必要的截图和日志log信息(tail -200f log.txt)
⑵ bug信息定位（前端bug还是后端bug，sql问题？）—— 缩小问题的范围
⑶ 在测试环境去复现bug
    1.不能复现：可能是版本升级导致的，（联系运维、产品）是否需要需要回退到上一个安全稳定的版本
    2.能复现：召集开发、产品、运维预估bug解决时间
    3.解决时间短：尽快修复，尽快回归，尽快线上验证
    4.解决时间长：联系运维回退到上一个安全稳定的版本
⑷ bug分析总结
    1.测试不到位（更新测试用例）
    2.紧急变更（争取测试资源包含测试时间）
    3.环境软硬件差异性（增加线上回归测试用例）

在你的项目（基于自己的项目）中编写了多少条测试用例？发现了多少缺陷？

1年左右的项目:在上一个项目里我一共是编写1300多条测试用例，其中一共是发现了300条左右的bug

如何评估一个项目或版本的质量好坏？项目上线的标准是什么？

从功能性、易用性、可靠性、兼容性、可维护性、可移植性，这几个维度来判定软件质量的好坏

上线标准
(1) 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
(2) 在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准
(3) 所有测试项没有残余紧急、严重级别错误。
(4) 需求分析文档、设计文档和编码实现一致。
(5) 验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析报告，待验收的软件安装程序。）

在你们公司是如何执行的需求评审工作？有没有提出过问题？需求评审过程中测试人员应该注意什么？

- 会议前, 先明确参与会议的时间,地点和人员, 并进行通知, 开发和测试需提前熟悉需求,标记不清楚, 疑问, 建议的地方, 等待会议时一并提出, 提高会议效率。
- 会议中, 提出对需求的疑问和建议, 并对提出的问题做记录,以免遗漏, 按需采纳修改建议,保证参与人员对需求理解一致. 当存在的异议点较多时, 考虑是当下解决还是例外安排会议进行解决.
- 会议后, 产品按评审意见对需求文档进行修改, 最后形成统一的、标准的需求文档发出来确认. 若评审不通过，那么可能就要修改后进行二次评审，保证需求的完整性、准确性、理解一致性.
- 要保证会议的高效进行，注意控制会议时间、讨论重点等，以免进度拖沓，重点问题得不到有效解决。

在测试环境出现偶尔出现的BUG，你会如何处理？

- 当bug出现时,抓取log或截图,视频留下证据
- 记录前置环境,操作步骤,和使用过的数据, 尝试重现bug
- 分析问题严重级别,以及同步开发进行分析修复时长,测试评估测试时长。如果影响范围大且修复时间较长，则建议回滚代码.否则直接修复验证并重新发布
- 若无法重现, 则找开发人员协助重现; 在开发人员的协助下仍未能重现, 则考虑bug的实际影响定义bug的严重级别, 是否能延迟到以后的版本再来修复

测试右移和测试左移，分别用了哪些技术？

左移的话更多的是让测试工作提前,同时对于技术的要求，和对开发服务架构的认知要更加深刻，如接口测试技术、单元测试技术等，
同时基于质量体系中，项目前面的阶段把控要更加深入:深刻理解需求，保障需求高质量，
对于开发质量交付也需要更加严格，如开发自测、开发过程交付物的产出质量：接口文档、设计文档。
右移的话个人觉得可以是UI自动化技术、发布风险控制(灰度上线和测试)、版本差异化检查等等技术。
无论是左移和右移都是为了项目质量来保障，基于个人的话现在对于***移投入的学习时间更多。

有没测试过后台，简单说下？

这个问题很多同学遇到过，首先做一个明确。后台分系统前端和业务后台，以及技术实践后台(实际也就是应用服务器层面)。

说白了这里面试官想问的无非是对于后台服务的测试，那涵盖的面就很广了，接口、性能、单元测试、数据库、缓存、搜索引擎等等的测试，都属于该范畴，而很多碰到这种问题就不知道如何回答，实际从中提取两个拿手或掌握的内容进行说明即可。

封测、内测、公测

封测只有技术人员针对技术方面进行测试；

内测的参与人员大部分是游戏制作人员，运营商和与制作及运营游戏的商家，及一部分普通玩家，普通玩家的账号需要特殊申请或者邀请，而且不保存id等数据；

公测游戏处于免费阶段，一般人都可以玩 帐号不限量，公测一般不删号；公测完后就要收费正式运营了