05软件测试面试题汇总

测试计划包括测试目标，测试范围、测试环境的说明、测试类型的说明、测试工具、模块的划分、测试负责人、测试轮次的安排，相关文档在文档管理库中的位置，测试的风险，其中模块划分需要根据测试人员对于业务的熟悉程度及个人能力进行分配、工作量的估算需要根据以往测试时的经验，结合本次需求的修改，可以大致估算出测数量。测试报告：项目概述：介绍测试的项目名称、背景、目标；测试时间、测试环境；测试过程（评审记录，测试范围、测试用例）；功能实现清单（列出是否已经按照测试计划实现功能）；缺陷统计（测试bug统计，测试用例执行通过率统计）；测试情况统计（资源统计、执行情况、问题统计、问题列表、遗留的问题）；测试总结（测试结论是否通过、bug的解决程度）

分页查询：select* from table LIMIT 0，10;从第1（0+1）行开始，累加10条，数据为1-10

select* from table LIMIT 10,10;从第11（10+1）行开始，累加10条，数据为11-20

登陆

功能方面的测试：1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录，能否能跳转到正确的页面2.输入错误的用户名, 验证登录失败，并且提示相应的错误信息3.输入错误的密码, 验证登录失败，并且提示相应的错误信息4.用户名为空, 验证登录失败，并且提示相应的错误信息5.密码为空, 验证登录失败，并且提示相应的错误信息6.用户名和密码都为空，点击登陆7.用户名和密码前后有空格的处理

性能方面:1.打开登录页面，需要多长时间2.输入正确的用户名和密码后，登录成功跳转到新页面，需要多长时间

安全性:1.密码是否在前端加密，在网络传输的过程中是否加密2.错误登陆的次数限制（防止暴力破解）3.是否支持多用户在同一机器上登录4.一个用户在不同终端上登陆5.用户异地登陆

用户体验测试：1.页面布局是否合理，输入框和按钮是否对齐2.输入框的大小和按钮的长度，高度是否合理3.是否可以全用键盘操作，是否有快捷键4.输入用户名，密码后按回车，是否可以登陆5.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用

兼容性BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。APP架构：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等

支付

功能方面：a.正常完成支付的流程；b.支付中断后继续支付的流程；c.支付中断后结束支付的流程；d.单订单支付的流程；e.多订单合并支付的流程；f.余额不足；金额的最小值 ：如0.01；金额为0；金额为负数g.未绑定银行卡；h.密码错误；i.密码错误次数过多；j.找人代付；k.弱网状态下，连续点击支付功能功能，会不会支付多次；l.有优惠券、折扣、促销价进行结算是否正确；m.不同终端上支付：包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；n.不同的支付方式：银行卡网银支付、支付宝支付、微信支付等；o.支付失败后，再次支付。

性能方面a.多个用户并发支付能否成功；b.支付的响应时间；

安全性a.使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号(下两个订单A,B，付款时拦截订单B，并把订单B的订单号改为A订单的订单号)无法完成支付；

用户体验a.是否支持快捷键功能；b.点击付款按钮，是否有提示；c.取消付款，是否有提示；d.UI界面是否整洁；e.输入框是否对齐，大小是否适中等。

兼容性BS架构:不同浏览器测试。APP:不同类型，不同分辨率，不同操作系统的手机上测试  

购物车

功能测试a未登录时1.将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加。

b登录后1.所有链接是否跳转正确；2.商品是否可以成功加入购物车；3.购物车商品总数是否有限制；4.商品总数统计是否正确；5.全选功能是否可用；6.删除功能是否可用；7.价格总计是否正确；8.商品文字太长时是否显示完整；9.购物车中下架的商品是否有标识，是否还能支付；10.新加入购物车商品排序（添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品）；11.商品删除后商品总数是否减少；12.收藏功能是否可用。13.购物车结算功能是否可用；14.同时在不同终端进入购物车后，进行下单付款，检查会不会重复付款。

兼容性测试BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等

用户体验测试1.是否支持快TAB、ENTER等快捷键；2.删除商品是否有提示；3.是否支持快捷键功能；4.是否有回到顶部的功能；5.商品过多时结算按钮是否可以浮动显示；6.购物车有多个商品时，能不能只对单个商品结算；7.界面布局、排版是否合理；8.文字是否显示清晰；9.不同卖家的商品是否区分明显。

性能测试1.打开购物车页面要多长时间（一般响应时间符合3、5、10原则）

微信红包

功能1.在红包钱数，和红包个数的输入框中只能输入数字2.红包里最多和最少可以输入的钱数 200 0.01

3.拼手气红包最多可以发多少个红包 100，3.1超过最大拼手气红包的个数是否有提醒4.当红包钱数超过最大范围是不是有对应的提示5.当发送的红包个数超过最大范围是不是有提示6.当余额不足时，红包发送失败7.在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，7.1是否可以输入它们的混合搭配8.输入红包钱数是不是只能输入数字9.红包描述里许多能有多少个字符 10个10.红包描述，金额，红包个数框里是否支持复制粘贴操作

12.红包描述里的表情可以删除13.发送的红包别人是否可以领取13.1发的红包自己可不可以领取 2人14. 24小时内没有领取的红包是否可以退回到原来的账户14.1 超过24小时没有领取的红包，是否还可以领取15.用户是否可以多次抢一个红包16.发红包的人是否还可以抢红包 多人17.红包的金额里的小数位数是否有限制18.可以按返回键，取消发红包19.断网时，无法抢红包20.可不可以自己选择支付方式21.余额不足时，会不会自动匹配支付方式22.在发红包界面能否看到以前的收发红包的记录23.红包记录里的信息与实际收发红包记录是否匹配24.支付时可以密码支付也可以指纹支付25.如果直接输入小数点，那么小数点之前应该有个026.支付成功后，退回聊天界面27.发红包金额和收到红包金额应该匹配28.是否可以连续多次发红包29.输入钱数为0，"塞钱进红包"置灰

性能1.弱网时抢红包，发红包时间2.不同网速时抢红包，发红包的时间3.发红包和收红包成功后的跳转时间4.收发红包的耗电量5.退款到账的时间

兼容1.苹果，安卓是否都可以发送红包2.电脑端可以抢微信红包

界面1.发红包界面没有错别字2.抢完红包界面没有错别字3.发红包和收红包界面排版合理，4.发红包和收到红包界面颜色搭配合理

安全1.对方微信号异地登录，是否会有提醒 2人2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加3.发送红包失败，余额和银行卡里的钱数不会少4.红包发送成功，是否会收到微信支付的通知

易用性1.红包描述，可以通过语音输入2.可以指纹支付也可以密码支付

水杯功能测试1.水杯是否可以装液体，能否装其他液体（酒精、甲醇）2.水杯是否可以正常喝水3.水杯是否有盖子，盖子是否可以正常盖住，并且保证水倒不出来4.水杯是否有保温功能，保温功能是否可以正常保温5.水杯是否会漏水，盖住盖子拧紧后是否会漏水

性能测试1.水杯能装多少L的水2.水杯是否耐热耐寒保温3.水杯能够使用的最大次数4.水杯盖子拧多紧不会漏水5.水杯掉在地上不易摔碎6.水杯长时间放置是否漏水

界面测试1.水杯外观是否简单美观2.水杯大小是否与产品规格说明书描述一致3.水杯是否有缺口，容易弄伤嘴巴

兼容性测试1.水杯能否盛放果汁、碳酸饮料2.水杯能否盛放硫酸、酒精、汽油3.水杯能否盛饭有毒物质4.水杯能否在夏天和在冬天使用

安全性1.水杯材质是否有毒或者是敏感物2.水杯盛放热水后是否会释放毒性3.水杯盛放冷水后是否释放毒性

易用性测试1.水杯是否有刻度表2.水杯喝水是否方便3.水杯拿起放下是否方便4.水杯装水是否方便5.水杯携带是否方便6.水杯是否具有防滑功能7.水杯装有低温或者高温水时，是否会让手感到不适

乐拍商城项目是一个B/S架构的电商分销管理系统，分为前台模块和后台模块，前台模块有店铺首页，购物车，会员中心等，后台模块有店铺管理、订单管理、发货管理等，在后台可上架新的商品，设置店铺活动，管理订单等，用户可以在前台注册成为会员，然后登录系统，搜索上架的商品，将商品加入购物车之后进行结算下单，或者直接进行结算下单，下单后在用户的‘我的订单’能看到该订单信息，订单状态为待发货状态，卖家就可以进行发货，买家收到产品后进行确认，评论

安安宠物医院项目是一个B/S架构的宠物医疗服务管理系统。用户可以注册登录，为宠物选择医疗服务项目、进入商城购物、浏览介绍文章，如有疑问可以向官方留言、还可以查看关于宠物的记录信息，如：看病记录、预约记录、疫苗注射记录等。后台面向的是医院管理人员，可以进行商品订单管理、医疗项目管理、权限、资源管理等模块。

管家APP是一款基于C/S架构的物业管理系统的app。主要模块为注册、登录、管家、生活、社区等，主要是物业跟住户、访客之间建立社区服务的作用。项目的主要流程为：住户注册账号后登录系统，添加所居住的房屋信息后，可进行一键开门、乘坐电梯、物业报修、物业缴费等服务。

一、web测试和app测试的相同点和区别？

相同点：都离不开测试的基础知识和测试原理。具体包括以下几个方面。

测试用例，均使用边界值分析法，等价类划分法等。

多数采用黑盒测试，来验证业务功能是否能得到正确的应用。

需要检查界面布局，风格，按钮是否美观、简洁，是否统一。

测试页面载入和翻页的速度、登录时长、内存是否溢出等。

测试应用系统的稳定性。

不同点：相对于web测试来说，app测试要考虑手机本身固有的属性，所以app测试还需要注意以下几点。

中断测试（来电去电，短信，蓝牙，NFC支付，闹钟，数据线插拔，锁屏，断电，关机重启等）

安装卸载测试（全新安装，新版本覆盖旧版本，卸载旧版本安装新版本，卸载新版本安装旧版本）

外在因素测试（网络切换，硬件按键，不同分辨率，兼容性，系统，系统版本）

web测试更多的是考虑自身功能和浏览器兼容。

二、如何测试一个App的登录场景？

APP登录场景大体从以下几个方面进行：

页面基本元素的操作。

大量字符，特殊字符，边界值，必填项校验。

注册手机号的特殊性验证，注册邮箱的格式验证。

密码大小写是否敏感，密码是否加密展示，密码是否有可见按钮功能，密码框能否使用复制粘贴。

验证码校验：必填项，过期，错误，无网络时获取验证码，多次获取，超过获取次数，输入验证码后，修改手机号。

登录时与系统的交互：锁屏，蓝牙，home，后退，横竖屏，修改字体字号。

逆向思维：已注册账号注册，未注册账号忘记密码，未注册账号登录，注册过程中退出再次注册。

输入法交互，切换输入法，切换输入模式，手写/九宫格。

登录账号的多样性：多个账号轮流登录，同一个账号多角色登录。

第三方登录验证：账号授权，信息正确，取消授权。

登录页面跳转，返回，登录成功及其他页面跳转。

手机兼容性测试：分辨率兼容，系统兼容，系统版本兼容，App版本兼容。

网络切换，网络断开，弱网。

三、Push消息如何测试？

Push消息的测试可以从以下几个方面进行：

检查Push消息是否按照指定的业务规则发送。

检查不接收推送消息时，用户不会再接收到Push消息。

如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到Push。在非免打扰时间段内，用户能正常收到Push。

当Push消息是针对登录用户的时候，需要检查收到的Push与用户身份是否相符，没有错误的将其他人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。

测试Push时，在开关机、待机状态下执行推送，消息及其推送跳转的正确性。

push消息时，会有红点展示，推送消息阅读前后数字的变化是否正确；

应用在开发、未打开状态、应用启动且在后台运行的情况下是push显示和跳转是否正确。

多条推送的合集的显示和跳转是否正确。

四、App的闪退通常是什么原因造成的？

APP闪退的原因可能是：

缓存垃圾太多，Android系统的特性，如果长时间不清理垃圾文件，会导致越来越卡，甚至闪退。

运行程序太多，导致内存不足。

应用版本兼容问题，分辨率兼容问题。

APP中访问网络的地方，组件能否正常下载并显示。

APP的SDK与手机系统不兼容。

系统升级后，新版本不兼容老版本的API，返回对象失败，报空指针。

软件权限未开放。

五、测试过程中遇到app出现crash或者ANR，你会怎么处理？

APP出现Crash或ANR，可以从以下几个方面处理：

可以先把日志过滤出来：adb logcat | findstr xxxxx(过滤日志信息) ；

然后再搜索其中的关键字，比如：  exception、crash，看看是哪些方法或者异常导致了问题；

初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复。

六、你平常会看日志吗, 一般会出现哪些异常（Exception）?

这个主要是面试官考察你会不会看日志，是不是看得懂Java里面抛出的异常，一般面试中Java Exception（runtimeException ）是必会被问到的问题，app崩溃的常见原因应该也是这些了。常见的异常列出四五种，是基本要求。

常见的几种如下：

NullPointerException - 空指针引用异常

ClassCastException - 类型强制转换异常

IllegalArgumentException - 传递非法参数异常

ArithmeticException - 算术运算异常

ArrayStoreException - 向数组中存放与声明类型不兼容对象异常

IndexOutOfBoundsException - 下标越界异常

NegativeArraySizeException - 创建一个大小为负数的数组错误异常

NumberFormatException - 数字格式异常

SecurityException - 安全异常

UnsupportedOperationException - 不支持的操作异常

七、APP 测试的内容主要包括哪些，如何开展？

APP测试的进行，可以从以下几个方面展开：

功能测试：

业务逻辑正确性测试：依据产品文档->测试用例编写。

兼容性测试：

1.系统版本：Android:官方版本,定制版本;IOS：官方提供版本。

2.分辨率：720 * 1280 1080* 1920。

3.网络情况:2g 3g 4g 5g Wi-Fi。

异常测试：

1.热启动应用:应用在后台长时间待机;应用在后台待机过程中，手机重启。

2.网络切换和中断恢复:网络切换;中断恢复。

3.电话信息中断恢复。

升级，安装，卸载测试：

1.升级测试：临近版本升级(1.0->1.1);跨版本(1.0->…->2.2)。

2.安装测试：首次安装;覆盖安装(同版本，不同版本覆盖);卸载后安装。

3.卸载测试：首次卸载;卸载安装后再卸载。

健壮性测试：

1.手机资源消耗：cpu，内存。

2.流量消耗：图片，数据，视频。

3.电量测试。

4.崩溃恢复。

八、APP性能测试关注点及常见APP性能测试工具

1、性能关注点

包体大小：

包体大小能被列为性能指标，是从APP性能指标及运营两个维度考虑的，用户是更希望包体小的同时性能要好，有时它们会是一个互相取舍的关系。

启动时长：

移动应用的启动时间是用户体验的一个重要方面，IOS一直建议尽可能的缩短启动时间，防止用户不愿意使用它们。对于浏览器而言，由于程序启动时还会有教育页和闪屏的下发，因此启动时间的获取显得尤为重要。

启动时间分为冷启动时间和热启动时间，所谓的“冷启动”，就是一个完全没有运行的应用的启动时间，与热启动（应用已经在后台运行，某个事件将其带至前台）相比，由于此时系统尚未建立缓存，因此冷启动往往要较平时（热启动）耗费更长的时间。

内存使用：

在Android系统中，每个APP进程除了同其他进程共享(shared dirty)外，还独用私有内存(private dirty)，通常我们使用PSS(=私有内存+比例分配共享内存)来衡量一个APP的内存开销。移动设备的内存资源是非常有限，为每个APP进程分配的私有内存也是有限制。一方面我们要合理的申请内存使用，以免导致频繁的GC（垃圾回收机制）影响性能和大对象申请发生内存溢出；另一方面，我们要及时释放内存，以免发生内存泄漏。

CPU占用率：

一般情况下，用主流手机使用APP20%-40%的CPU占用率算是合理的，当然这个数值随着近年来手机硬件配置的提高，会略微下降，如果CPU占用率超过80%就非常值得我们去关注了。

图片处理器每秒刷新的帧数(FPS)：

可用来指示页面是否平滑的渲染。手机APP帧率FPS，30-60都可接受，上了60对于人眼主观感受差别就不大了。对于移动应用开发而言，并不是FPS越高就一定越好，FPS取决于显卡，其次是内存、CPU，然后是网络。故综合APP其他性能指标，选择一个适合的FPS即可。

电量：

相对于PC来说，移动设备的电池电量是非常有限的，保持持久的续航能力尤为重要。另外，android的很多特性都比较耗电(如屏幕，GPS，sensor传感器，唤醒机制，CPU，连网等的使用)，我们必须要慎重检查APP的电量使用，以免导致用户手机耗电发热，带来不良体验。

流量：

目前的网络类型包含2G\3G\4G\5G\wifi，其中还有不同运营商的区分，我们在APP的使用中经常遇到大资源，重复请求，调用响应慢，调用失败等各种情况。在不同的网络类型之下，我们不仅要控制流量使用，还需要加快请求的响应。另外，对于需要联网的手游来说，部分游戏对不同联网方式的网络类型采用了不同的流量消耗策略，主要分为wifi环境和蜂窝网络环境。所以针对不同的游戏，我们统计流量消耗时，可能要连接不同的网络进行测试。

2、app性能测试工具

GT和iTest，Emmagee APT ，DDMS ，手机自带开发者选项中的工具，也可以通过adb命令来查看等

九、如何对app进行弱网测试

一款APP针对不同网络情况下都需要保证不会崩溃，同时尽可能做到在弱网情况下也能达到功能正常使用，或者使用体验达到最佳。弱网测试可以测试APP的加载时间、可用性、稳定性和健壮性。这时我们就可以借助工具来模拟不同的网络状况，模拟2G、3G或弱网情况进行测试。工具可以选择Fiddler也可以选择Charles也可以选择其他工具。

十、常见的 adb 命令

注：adb 使用的端口号是5037，以下总结工作中常用到的adb命令。

1.查看帮助手册列出所有的选项说明及子命令：

adb help

获取设备列表及设备状态：

adb devices

3.安装应用：adb install 路径\xx.apk, 安装应用；adb install -r 重新安装

adb install

adb install -r

获取设备的状态，设备的状态有 device , offline , unknown3种，其中device：设备正常连接，offline：连接出现异常，设备无响应，unknown：没有连接设备。

adb get-state

5.卸载应用：adb uninstall <包名>, 后面的参数是应用的包名，区别于 apk 文件名。

adb uninstall

6.将 Android 设备上的文件或者文件夹复制到电脑本地：adb pull <远程路径> <本地路径>, 如复制 Sdcard 下的 pull.txt 文件到 D 盘：adb pull sdcard/pull.txt d:\，重命名：adb pull sdcard/pull.txt d:\rename.txt。

adb pull

7.推送本地文件至 Android 设备：adb push <本地路径> <远程路径>, 如推送 D 盘下的 ITester.txt 至 Sdcard：adb push d:\ITester.txt sdcard/ （注意sdcard 后面的斜杠不能少）。

adb push

8.结束和启动adb服务：adb kill-server /adb start-server , 结束 adb 服务/启动 adb 服务，通常两个命令一起用，设备状态异常时使用 kill-server，运行 start-server 进行重启服务。

adb kill-server

adb start-server

9.打印及清除系统日志：adb logcat , 打印 Android 的系统日志 ；adb logcat -c,清除日志。

adb logcat

adb logcat -c

10.查找包名/活动名

adb logcat | findstr START

11.生成bugreport文件：adb bugreport , 打印dumpsys、dumpstate、logcat的输出，也是用于分析错误，输出比较多，建议重定向到一个文件中，如adb bugreport > d:\bugreport.log。

adb bugreport

重启 Android 设备：adb reboot , adb reboot recovery，重启到Recovery界面； adb reboot bootloader，重启到bootloader界面。

adb reboot

adb reboot recovery

adb reboot bootloader

13.获取 root 权限：adb root , adb remount,可以直接获取 root 权限，并挂载系统文件系统为可读写状态。

adb root

adb remount

14.返回设备序列号SN值：

adb get-serialno

15.获取设备的ID：

adb get-product

16.进入设备shell

adb shell

17.列出所有的应用的包名：

adb shell pm list package

18.截屏并保存至 sdcard 目录：

adb shell screencap -p /sdcard/screen.png

19.录制视频并保存至sdcard：adb shell screenrecord sdcard/record.mp4,执行命令后操作手机，ctrl + c 结束录制，录制结果保存至 sdcard：

adb shell screenrecord sdcard/record.mp4

20.获取设备分辨率：

adb shell wm size

21.列出指定应用的 dump 信息，adb shell pm dump 包名。

adb shell pm dump

22.列出对应包名的 .apk 位置，adb shell pm path 包名。

adb shell pm path

23.查看当前终端中的进程信息：

adb shell ps

24.monkey测试：adb shell monkey –p 程序包 –v 测试次数 ,比如“adb shell monkey –p com.htc.Weather –v 20000”意思是对com.htc.Weather 这个程序包单独进行一次20000次的monkey测试。

adb shell monkey –p 程序包 –v 测试次数

25.显示所有程序包：

adb shell ps | grep [process]

26.根据进程pid或包名查看进程占用的内存：

adb shell dumpsys meminfo<pid>

adb shell dumpsys meminfo<package_name>

27. APP 启动：

adb shell am start -n packageName/activity

APP 关闭：

adb shell am force-stop 包名

29.监控 APP 启动时间：

adb shell am start -W packageName/activity

一，手机功能测试

1.1 启动： APP安装完成后，是否可以正常打开，稳定运行， APP的速度是可以让人接受，切换是否流畅

 网络异常时，应用是否会崩溃:在请求超时的情况下，如果程序逻辑处理的不好，就有可能发生Crash。

1.2 注册、登录：正向：输入正确的账号密码、Enter键，可正常注册和登录

逆向：输入的数据前存在空格；用户名、密码错误或漏填；已注册用户；是否允许多次非法登录；是否限制次数；未注册用户登录；删除或修改后用户登录；是否有注销按钮；逆向：密码更改后，登录时是否做到了有效数据的校验：修改前的密码失效；逆向：未登录时对一些页面的操作，是否做了控制逆向：密码“****”展示（安全性）逆向：账号输入框对最大长度和格式应有校验（比如邮箱账号需要邮箱格式等）逆向：账号或密码输入错误时建议提示“账号或密码错误”，而不是“账号错误”或“密码错误”逆向：登陆后，页面中登陆信息是否正确；逆向：不输入用户密码或者是重复点击“确定/取消”按钮，是否允许登陆；逆向：支持自动登录（记住密码）的应用在进行数校验时，检查系统是否能自动登录成功并且数据操作无误逆向：考虑无网络情况下能否正常进入免登陆状态。逆向：检查用户主动退出登录后，下次启动APP，应停留在登录页面。逆向：登录超时时处理是否合理逆向：页面中是否有注销按钮；逆向：密码是否加密传输（可抓取请求查看）逆向：切换账号登录，检验登录的信息是否做到及时更新逆向：对于多个端都进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新逆向：台式机和手机的同时登录同一账号，多台手机的同时登录同一账号（检查是否将原用户剔除）

1.2.2 手机号注册登录：手机号输入框格式校验检查 验证短信的接收是否及时； 用验证码可正常登录； 验证码错误时，登录失败+友好提示 验证短信文案是否符合所测APP； 重复发送验证码，前一个验证码正常失效 频繁操作验证码发送，应有操作限制 检查对登陆超时（验证码不能用）的处理。 验证码有效期校验（超过有效期无法登录）

1.2.3 注册

 表单编辑页面测试；用户名密码长度；注册后的提示页面； 前台注册页面和后台的管理页面数据是否一致

 注册后，在后台管理系统中的页面提示以及数据库中的用户信息是否正常；

1.3 所有功能是否能正常运行

 业务逻辑测试：主要测试客户端业务是否正常完成

 功能点测试：主要测试客户端功能点是否可以正常使用，对具体功能点逐一测试，确保每个点都能正确实现相应功能。

 关联行测试：主要测试客户端与PC端的交互，客户端处理完后，PC端与客户端数据一致

1.4 应用的前后台切换是否正常

 APP切换到后台，再回到APP，检查是否停留在上一次操作界面。

 APP切换到后台，再回到APP，检查功能及应用状态是否正常。

 APP切换到后台，再回到APP前台时，注意程序是否奔溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。

 手机锁屏解锁后进入APP注意是否会奔溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。

 当APP使用过程中有电话进来中断后再切换到APP，功能状态是否正常。

 当杀掉APP进程后，再开启APP，APP能否正常启动。

 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。

 对于有数据交换的页面，每个页面都必须要进行前后台切换、锁屏的测试，这种页面最容易出现奔溃的现象。

1.5 数据更新

更新后功能是否正常，更新的功能点能否正常使用。1.6 离线浏览

 在无线网络情况下可以浏览本地数据。

 退出APP再开启APP时能正常浏览本地数据。

 切换到后台再回到前台可以正常浏览本地数据。

 锁屏后再解锁回到应用前台可以正常浏览本地数据。

 手动刷新时，是否有对连接网络的提示

1.7 定位，照相机服务等等

1.8 时间测试

1.9 Push测试

 检查push消息是否按照指定的业务规则发送。

 检查不接收推送消息时，用户不会再接收到push消息。

 如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到push消息；

 在非免打扰时间段内，用户能正常接收到push消息。

 当push消息是针对登录用户的时候，需要检查收到的push消息与用户身份是否相符。

 不打开应用时，能否接收消息

 打开应用时，能否接收消息

 登录与不登录情况下，接收消息是否有区别

 精确推送，是否只推送给指定用户

1.10 界面测试

1.窗体

测试窗体的方法: a，窗体大小，大小要合适，控件布局合理;

 b，移动窗体.快速或慢速移动窗体，背景及窗体本身刷新必须正确;

 c，缩放窗体，窗体上的控件应随窗体的大小变化而变化;

 d，显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;

进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效，是否与菜单懒中图标显示一致;错误信息内容是否正确，无错别字，且明确等等;2.控件

月份和日期对应（比如2月有28天，7月31天）

闰年2月，应有29天

跨年时，年份应有增加。

测试方法: a，窗体或控件的字体和大小要一致;

 b，注意全角，半角混合

 c，无中英文混合.

菜单，进行测试时要注意： a，选择菜单是否可以正常工作，并与实际执行内容一致;

 b，是否有错别字:

 c，快捷键是否重复;

 d，热键是否重复;

 e，快捷键与热键操作是否有效；

 f，是否存在中英文混合；

 g，菜单要与语境相关，如，不同权限的用户登陆一个应用程序，不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;

 h，鼠标右键快捷菜单；

 g，手机拍照功能可以正常显示；

3. 文本框、按钮等控件测试

文本框的测试 a，输入正常的字母或数字。

 b，输入已存在的文件的名称;

 c，输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入256个字符，检查程序能否正确处理;

 d，输入默认值，空白，空格;

 e，若只允许输入字母，尝试输入数字;反之;尝试输入字母;

 f，利用复制，粘贴等操作强制输入程序不允许的输入数据;

 g，输入特殊字符集，例如，NULL及NOW等;

 h，输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示;

 i，输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

在测试过程中所用到的测试方法：1，输入非法数据;2，输入默认值;3，输入特殊字符集;4，输入使缓冲区溢出的数据;5，输入相同的文件名;按钮控件测试

4.1 命令按钮控件的测试

 a，点击按钮正确响应操作。如，单击确定，正确执行操作;单击取消，退出窗口;

 b，对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31;

 c，对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会;

4.2 单选按钮控件的测试

 a，一组单选按钮不能同时选中，只能选中一个。

 b，逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”;

 c，一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空;

5. up-down控件文本框的测试

 a，直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10;

 b，利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1;反之亦适用;

 c，直接输入超边界值，系统应该提示重新输入;

 d，输入默认值，空白。如，“插入”数目为默认值，点击“确定”;或，删除默认值，使内容为空，单击“确定”进行测试;

 e，输入字符。此时系统应提示输入有误。

6.组合列表框的测试

 a，条目内容正确，其详细条目内容可以根据需求说明确定;

 b，逐一执行列表框中每个条目的功能;

 c，检查能否向组合列表框输入数据;

7. 复选框的测试

 a，多个复选框可以被同时选中;

 b，多个复选框可以被部分选中;

 c，多个复选框可以都不被选中;

 d，逐一执行每个复选框的功能;

8.列表框控件的测试

 a，条目内容正确;同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误;

 b，列表框的内容较多时要使用滚动条;

 c，列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况;

9.滚动条控件的测试

测试要点： a，滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间;

 b，拖动滚动条，检查屏幕刷新情况，并查看是否有乱码;

 c，单击滚动条;

 d，用滚轮控制滚动条;

 e，滚动条的上下按钮。

各种控件在窗体中混和使用时的测试 a，控件间的相互作用;

 b，tab键的顺序，一般是从上到下，从左到右;

 c，热键的使用，逐一测试;

 d，enter键和esc键的使用;

在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

ps:密码输入框测试时要特别注意进行字母大写输入的测试。

二、UI测试

 原型与效果图对比（导航测试） 图形测试 内容测试

三、兼容性测试（比如testin云测平台）

 与本地以及主流APP是否兼容 不同操作系统的兼容性，是否适配 不同手机屏幕分辨率的兼容性

四、交叉测试

冲突测试，即一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试

五、安装，升级，卸载，更新

5.1 安装、卸载测试

正向：应用是否可以正常安装(命令行安装；apk/ipa安装包安装 )(有网、无网是否都正常)正向：APP的速度是否流畅逆向：应用是否可以在IOS和Androoid不同系统、版本、机型上进行安装逆向：是否可以正常删除（三方软件删除；命令行删除；桌面删除）逆向：APP安装完成后，是否可以正常打开，稳定运行逆向：安装过程中断网或网络不稳定的情况下，是否有相应提示逆向：网络异常时，应用是否会崩溃：在请求超时的情况下，如果程序逻辑处理的不好，就有可能发生crash逆向：卸载过程中出现死机、重启，断点等意外情况，待环境恢复后是否可以继续正常卸载逆向：卸载是否支持取消功能，单击取消后软件卸载情况是否正常逆向：安装过程中是否可以暂停，再次点击，是否可以继续安装逆向：安装空间不足时如何表现，是否有相应提示，提示是否友好逆向：安装过程中断网或网络不稳定的情况下，是否有相应提示逆向：安装在手机卡上或SD卡上（不同的IOS和安卓版本）5.2 升级测试

5.3 更新测试

正向：客户端有新版本时，有更新提示逆向：取消版本后，老版本可以正常使用逆向：当版本为非强制升级时，用户可以取消更新，老版本能正常使用。用户在下次启动APP时，仍出现更新提示逆向：APP更新后新增功能和老功能是否可以正常使用逆向：当版本为强制更新升级时，用户没有做更新，退出客户端，下次启动APP时，仍出现强制升级提示（且无法关闭），点击更新是否正确调整到后台配置的更新页面逆向：APP更新后检查版本号应该有更新逆向：当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新逆向:当客户端有新版本时，在本地不删除客户端的情况下，更新后的客户端功能是否是新版本功能逆向：当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否有正常更新最新版本逆向：升级安装意外情况的测试（如死机、断电、重启）逆向：强制更新（APP开启后，自动更新APP，否则无法使用APP），多次关闭和打开APP后是否正常跳出更新弹窗，且无法关闭；点击更新是否正确跳转至后台配置的更新页面逆向：非强制更新（只提示一次更新）：可以正常关闭弹窗；重启APP更新提示按照需求再次显示或者不再显示；点击更新是否正确跳转至后台配置的更新页面逆向：当有新版本时，不删除客户端的情况下，直接更新是否成功逆向：升级安装意外情况的测试（如死机、断电、重启）逆向：允许内网访问的APP，在连接到外网时是否有友好提示

六、用户体验测试

整体产品或服务的舒适度

七、安全测试

 敏感信息是否加密，用抓包工具分析 密码是否过于检查检查 重要数据，如支付密码会不会保存到设备 同一账号在不同终端登陆，是否有提示 异地登录是否有提示 系统会否运行多次非法登陆，是否有提示 限制或者允许使用手机某些功能 注册的验证码是否重复使用，是否有超时限制 协议抓取，反编译

八、性能测试

服务器的性能测试和手机端的性能测试

比如：CPU、内存、上传流量、下载流量、电量使用情况等 极限测试 响应时间 压力测试 耗电量测试 电量流量测试 CPU、内存消耗 app使用占用的CPU和内存 app启动时长 app启动需要的时间 crash率 奔溃率 内存泄露一般CPU使用率与手机端电量使用率成正比，CPU使用率不能超过10%以上，流量不要超过10M以上，可以通过android手机端一些监控软件获取数据

android的程序由Java语言编写，所以android的内存管理与Java的内存管理相似。程序员通过new为对象分配内存，所有对象在java堆内分配空间，然而对象的释放时有垃圾回收器完成的。

android的虚拟机是给予寄存器的Dalvik,它的最大堆大小一般是16M，有的机器为24M。

Adb：1.查看帮助手册：adb help、2.获取设备列表及设备状态：adb devices

3.安装应用：adb install 路径\xx.apk, 安装应用；adb install -r 重新安装。adb install，adb install -r

4.获取设备的状态，设备的状态有 device , offline , unknown3种，其中device：设备正常连接，offline：连接出现异常，设备无响应，unknown：没有连接设备。adb get-state

5.卸载应用：adb uninstall <包名>, 后面的参数是应用的包名，区别于 apk 文件名。adb uninstall

6.将 Android 设备上的文件或者文件夹复制到电脑本地：adb pull <远程路径> <本地路径>, 如复制 Sdcard 下的 pull.txt 文件到 D 盘：adb pull sdcard/pull.txt d:\，重命名：adb pull sdcard/pull.txt d:\rename.txt。

7.推送本地文件至 Android 设备：adb push <本地路径> <远程路径>, 如推送 D 盘下的 ITester.txt 至 Sdcard：adb push d:\ITester.txt sdcard/ （注意sdcard 后面的斜杠不能少）。adb push

8.结束和启动adb服务：adb kill-server /adb start-server , 结束 adb 服务/启动 adb 服务，通常两个命令一起用，设备状态异常时使用 kill-server，运行 start-server 进行重启服务。adb kill-server，adb start-server

9.打印及清除系统日志：adb logcat , 打印 Android 的系统日志 ；adb logcat -c,清除日志。

10.查找包名/活动名adb logcat | findstr START

11.生成bugreport文件：adb bugreport , 打印dumpsys、dumpstate、logcat的输出，也是用于分析错误，输出比较多，建议重定向到一个文件中，如adb bugreport > d:\bugreport.log。

12.重启 Android 设备：adb reboot , adb reboot recovery，重启到Recovery界面； adb reboot bootloader，重启到bootloader界面。

13.获取 root 权限：adb root , adb remount,可以直接获取 root 权限，并挂载系统文件系统为可读写状态。adb root

14.返回设备序列号SN值：adb get-serialno

15.获取设备的ID：adb get-product

16.进入设备shell：adb shell

17.列出所有的应用的包名：adb shell pm list package

18.截屏并保存至 sdcard 目录：adb shell screencap -p /sdcard/screen.png

19.录制视频并保存至sdcard：adb shell screenrecord sdcard/record.mp4,执行命令后操作手机，ctrl + c 结束录制，录制结果保存至 sdcard：

20.获取设备分辨率：adb shell wm size

21.列出指定应用的 dump 信息，adb shell pm dump 包名。

22.列出对应包名的 .apk 位置，adb shell pm path 包名。

23.查看当前终端中的进程信息：adb shell ps

24.monkey测试：adb shell monkey –p 程序包 –v 测试次数 ,比如“adb shell monkey –p com.htc.Weather –v 20000”意思是对com.htc.Weather 这个程序包单独进行一次20000次的monkey测试。

25.显示所有程序包：adb shell ps | grep [process]

26.根据进程pid或包名查看进程占用的内存：adb shell dumpsys meminfo<pid>，adb shell dumpsys meminfo<package_name>

27. APP 启动：adb shell am start -n packageName/activity

28.APP 关闭：adb shell am force-stop 包名

29.监控 APP 启动时间：adb shell am start -W packageName/activity

1. 请问你们公司是如何做接口测试的？答： 接口测试实际跟一般测试不同就是测试用例的设计部分。

①获取接口规范；

②设计接口测试功能用例（主要从用户角度出发看接口能否实现业务需求）；

③各种入参验证（正常情况，异常情况包括输入参数个数不对，类型不对，可选/必选，还 有考虑参数有互斥或关联的情况）；

④接口返回值各种验证（符合接口文档需求）；

⑤了解接口实现逻辑，实现逻辑覆盖（语句/条件/分支/判定/…）；

⑥接口能并发执行吗、安全吗，性能满足要求吗；

⑦采用工具或者自写代码来验证；

⑧发现问题跟功能测试一样，该报 bug 报 bug，该跟踪状态的跟踪状态；

2. 怎么设计接口测试用例？答： 通常，设计接口测试用例需要考虑以下几个方面：

①是否满足前提条件 有些接口需要满足前提，才可成功获取数据。常见的，需要登录 Token 逆向用例：针对是否满足前置条件（假设为 n 个条件），设计 0~n 条用例；

②是否携带默认值参数 正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值， 其他不填写，设计 1 条用例；

③业务规则、功能需求 这里根据时间情况，结合接口参数说明，可能需要设计 N 条正向用例和逆向用例；

④参数是否必填 逆向用例：针对每个必填参数，都设计 1 条参数值为空的逆向用例；

⑤参数之间是否存在关联 有些参数彼此之间存在相互制约的关系；

⑥参数数据类型限制 逆向用例：针对每个参数都设计 1 条参数值类型不符的逆向用例；

⑦参数数据类型自身的数据范围值限制 正向用例：针对所有参数，设计 1 条每个参数的参数值在数据范围内为最大值的正向用例；

3. 你做接口测试，测什么。答：可用性测试 根据约定的协议、方法、格式内容，传输数据到接口经处理后返回期望的结果：

①接口功能是否正确实现；

②返回值测试 - 返回值除了内容要正确，类型也要正确，保证调用方能够正确地解析；

③参数值边界值、等价类测试； 错误和异常处理测试；

④输入异常值（空值、特殊字符、超过约定长度等），接口能正确处理，且按预期响应；

⑤输入错误的参数，接口能正确处理，并按预期响应；

⑥多输入、少输入参数，接口能正确处理，且按预期响应；

⑦错误传输数据格式（如 json 格式写成 form 格式）测试； 安全性测试，主要指传输数据的安全性：敏感数据（如密码、秘钥）等是否加密传输；

⑧返回数据是否含有敏感数据，如用户密码、完整的用户银行账号信息等；

⑨接口是否对传入的数据做安全校验，如身份 ID 加 token 类似校验；

⑩接口是否防止恶意请求（如大量伪造请求接口致使服务器崩溃）；

⑪性能测试，如接口的响应时间、并发处理能力、压测处理情况：并发请求相同的接口（特别为 POST 请求），接口的处理情况（如插入了相同的记录导致 数据出错，引发系统故障）；

⑫接口响应时长在用户可忍受的范围内；

⑬对于请求量大的接口做压测，确定最大的瓶颈点是否满足当前业务需要；

4. 平常用什么工具测接口的？答：常用 http 协议接口测试工具，如：postman、fiddler、jmeter；webService接口用SoapUI、 jmeter 等。

5. 没有接口文档，如果做接口测试？答：用抓包工具把接口抓取处理，然后针对性进行测试；接口中字段信息不清楚的，找时间集中寻求开发解答。（常用抓包工具 Fiddler、Charles 等）

6. 接口测试中，依赖登录状态的接口如何测试？答：依赖登录状态的接口的本质上是在每次发送请求时需要带上 session 或者 cookie 才能 发送成功，在构建 POST 请求时添加必要的 session 或者 cookie

7. 你平常做接口测试的过程中发现过哪些 bug?

答：常规错误:接口没实现，没按约定返回结果，边界值处理出错等。 输入异常值（空值、特殊字符、超过约定长度等），接口抛错，没做封装处理；输入错误的参数、多输入、少输入参数，接口可能出现的错误；安全性问题，如明文传输、返回结果含有敏感信息，没对用户身份信息做校验，没做恶意请 求拦截等；性能问题，如接口并发插入多条相同操作，响应时间过长，接口压测出现瓶颈等；

8. 当一个接口出现异常时候，你是如何分析异常的？答：先抓包，用 fiddler（charles）工具抓包，或者浏览器上 F12 调试工具；APP 上的话，那就 用 Fiddler 做代理，通过手机设置代理去看请求和返回报文； 查看后端日志，如 Linux 系统通过 xhell 连上服务器，查看接口日志，查看是否有报错信息 （命令：tail -f 日志文件）；

9. 如何分析一个 bug 是前端还是后端的？答：先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就 是前端发的数据不对； 请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题。

讲一下从你提交 bug 到最后 bug 被关闭都经过哪些环节

回答思路：一个 bug 的声明周期：提交-确认- 已解决- 已关闭

参考回答：在项目测试过程中如果发现了 bug ，首先确认出现 bug 时的操作步骤，测试时使 用的数据以及需求文档中的描述。确认后在禅道中提交 bug ，需要写清楚测试环境、测试账 号、操作步骤截图或录屏，将 bug 提交给开发后，开发解决 bug ，bug 被解决后会流转到测 试，测试去验证 bug 是否被修复完成，如果修复完成就将 bug 关闭，如果没有通过验证，就 打回给开发

4.7  你在之前的工作中都提交过哪些类型的 bug

回答思路：bug 的常见类型，可以参考禅道中的 bug 类型

参考回答：在之前的项目中，自己提交的 bug 主要是软件功能方面的，比如界面问题、数据 问题、设计缺陷等，当然也有版本引入 bug

4.8  你觉得提交一个清晰完美的 bug 需要包含哪些信息

回答思路：提交 bug 的要素：标题、测试环境、测试账号、操作步骤、bug 截图、期望结果 参考回答：提交 bug 时需要把发现 bug 时使用的环境信息、数据信息、操作步骤的截屏或录 屏，同时要描述 bug 现象，以及期望结果等信息

4.9  有没有写过测试计划，一份测试计划都包含哪些内容

回答思路：测试计划主要关注时间进度、人员的安排

参考回答：我们公司的测试计划都是跟开发计划一体的，在排好开发周期后，将测试所需要 的时间加在整个版本计划中，需求评审完后会根据版本需求中的功能点来预估工作量和测试 时间，所以测试计划主要包含的就是测试时间安排、人员安排这些信息

4.10  有没有写过测试报告，一份测试报告都包含哪些内容

回答思路：测试报告是本次测试的工作量汇总，主要包含用例执行情况、提交 bug 情况、是 否达到上线要求等信息

参考回答：在每个版本测试结束后会写测试报告，我们之前写的测试报告用的是公司的模板， 只需要将本次测试的数据更新到模板中，测试报告中包含本次迭代的用例执行情况、提交 bug 数量、bug 的类型分布、bug 等级分布、是否存在遗留 bug 、是否达到上线标准等信息

4.11  用例评审需要哪些人来参与，以什么样的方式展开用例评审

回答思路：用例评审时，由测试人员讲解用例，需要相关的产品经理及开发参与

参考回答：在用例写好后会邀请相关的产品经理和开发参加用例评审，一般是在会议室现场 评审或者腾讯会议在线评审的模式，评审用例时需要由测试人员讲解用例，开发和产品分别 在各自的角度提出用例的设计不足，并由测试在会议后去完善用例，用例评审是提升用例覆 盖率的有效方式

4.12  一个版本需要经过几轮测试，有什么区别

回答思路：一个版本一般需要三轮测试：第一轮功能测试、第二轮集成测试、第三轮 uat 测 试

参考回答：我们之前公司使用的是敏捷开发的模式，一个版本要经过三轮测试：第一轮功能测试，需要执行所有的用例，提交 bug ，在 bug 全部被解决后进入第二轮集成测试，第二轮 测试关注本次迭代的功能与主线版本功能是否存在业务冲突，第二轮测试通过后发布到 uat 环境，由测试与产品经理或客户执行第三轮 uat 测试，uat 测试通过后安排发版上线

4.13  你们项目要上线，上线的标准是啥，有没有量化指标

回答思路：项目上线前需要保证本次迭代中的功能全部实现、用例全部执行通过、没有遗留

ug回答：我们项目的上线标准是版本迭代中的功能全部实现、用例全部执行通过、没有遗 留 bug，但是如果项目紧急上线，并且还存在没解决的 bug，需要评估遗留 bug 的风险等级， 如果是影响较小的 bug ，可以放到下个版本解决，如果是影响较大的 bug ，需要全部解决后 才可以上线

4.14  说一个你之前工作中印象最深的 bug

回答思路：1.token 更新后之前的token 还可以用，2. 同一个账号在不同浏览器无法同时登录 参考回答：1.在园区管理项目中测试接口时发现，重新登录获取token 后，之前获取的token 还可以用，开发排查代码后发现没有将生成的token 保存到数据库中，导致出现继续使用之 前 token 的情况

2.在小区物业管理项目中发现同一个账号在不同浏览器无法同时登录，经排查发现，在其他 客户端登录时重新获取了token 信息，导致之前用户的 token 变为过期状态，刷新页面时会 自动退出

4.15  如果你提了一个 bug ，但是开发不认可你会怎么办

回答思路：首先排除自身的原因，确认是 bug 后可以直接提交，如果开发认可，需要找产品

参考回答：发现 bug 时首先确认自己对产品业务的理解是正确的，提交 bug 后，如果开发不 认可，那可以找产品经理确认，结合产品经理的意见再转述给对应的开发，如果开发还是拒 绝修改，可以直接发邮件给开发并抄送给测试组长、产品经理、开发负责人。

5. 测试设计相关问题

测试点问题回答思路：如果是测试一个功能

，如

：微信发红包、注册、登录

，那可以按照功 能的业务流程、操作步骤来分析测试点

，然后再考虑是否需要关注兼容性、性能、安全等方 面。如果是一个独立的个体。如

：电梯、水杯、一个 APP

，那可以站在更高的维度来分析测 试点，从功能性、兼容性、性能、易用性、安全几个方面来考虑

5.1  有一个搜索场景，包含两个下拉框和一个搜索框，设计测试用例

5.2  有一个登录场景，需要用户输入用户名和密码，设计下测试用例

5.3  我们平时用的微信发红包场景，你来整理下都有哪些测试场景

5.4  微信发朋友圈怎么测试，说一下自己能想到的测试点

5.5  商城中的提交订单功能，你来说下需要测试哪些场景

5.6  支付宝扫码付款用过吧，让你来测试，你会想到哪些测试场景

5.7  你们之前项目中最难测试的场景是什么，你是怎么解决的

5.8  如果让你独立负责一个项目，你觉得能不能胜任，你会怎么做

5.9  一个 qq 的聊天框，上限 100 字，你会怎么测试

5.10  有一支笔，你会想到哪些测试点

5.11  电梯怎么测试

5.12  现在有一个杯子，你会想到哪些测试点

5.13  如果有一张数据报表，你要怎么测试6.2    有没有使用过抓包工具，在什么情况下会使用抓包工具

回答思路：抓包工具用来分析定位 bug 时使用，常用的抓包工具 fiddler 、charles

参考回答：在测试的时候经常使用抓包工具来分析定位问题，常用的抓包工具 Charles ，比 如测试的时候发现页面上的数据存在异常，可以通过抓包工具抓取对应的请求，查看请求中 的发送的数据和返回的数据，来对 bug 进行分析定位

6.3    当你测试时发现一个问题时，怎么判断是前端问题还是后台问

题

回答思路：使用抓包工具分析，查看接口返回数据

参考回答：  1.如果接口返回数据错误或与数据库不一致，那可以确认是后台 bug 。2.如果接 口返回数据正确，但页面中的数据与接口返回数据不一致时，，那可以确认是前端 bug

6.4    使用 fiddler 时怎么设置过滤

回答思路：fiddler 可以设置过滤，用来查看指定项目的请求

参考回答：在使用fiddler 抓包时，可以使用过滤设置只查看某个 host 地址的请求，比如设 置 www.baidu.com,为过滤条件，这样可以只查看百度网站的请求

6.5    使用fiddler 时有没有用过断点重传，怎么设置

回答思路：断点重传分为：请求前的断点、请求后的断点

参考回答：断点重传分为请求前的断点、请求后的断点，请求前的断点为请求前打断点，可 以在发送请求前截断请求，可以修改请求发送的数据，重传修改后的请求。比如前端页面对 某个输入数据做了条件限制，请求前的断点可以绕过前端限制，发送不符合要求的数据，测 试系统的健壮性。请求后的断点就是在请求响应后打断点，可以在服务器响应后截断请求， 修改服务器返回的数据。比如要测试个人账户余额显式 9999999999 时的页面显示，但是无 法修改数据库，可以通过断点修改请求返回的数据，模拟服务器返回的数据

6.6    使用抓包工具时怎么找接口请求

回答思路：1.查找接口链接，链接中的关键词对应接口的功能 2.查看接口发送的参数、返回 的数据，判断对应界面哪个功能

参考回答：1.在抓包之前可以清空抓包工具列表中的请求，然后在浏览器中正常操作，查看 抓包工具中的请求，可以通过接口链接中的关键词来判断接口对应的界面功能，也可以通过 接口发送的参数、返回的数据，来判断接口对应的界面功能

6.7    都用过哪些抓包工具，各有什么优缺点

回答思路：Fiddler：功能强大

，抓取的请求比较多，不好查看；Charles：界面简洁、容易查

找请求

参考回答：之前用的抓包工具是 Charles 、Fiddler ，Charles 抓取的请求是以文件夹结构方式 来查看，找到项目的主机地址后，可以查看当前项目下的所有接口请求，而且不同功能、不 同模块的接口会放到不同的文件夹下，方便查看。Fiddler 的功能比较强大，除常规的抓包 外，还可以设置断点、设置网络传输速度实现弱网测试，但是抓取的请求较多并没有分类，使用过滤后仍然不好查找某个功能对应的请求。

6.8    使用的项目管理软件是什么，作为测试主要使用哪些功能

回答思路：禅道、TAPD(腾讯旗下的项目管理软件，类似禅道) 、Teambition(阿里旗下的项目 管理软件) 、简单云(一个免费的项目管理软件)

参考回答 1 ：之前公司使用的项目管理软件是禅道，我们主要用禅道中测试模块的功能，比 如：用例管理、bug 管理等，也可以在禅道中查看版本需求、版本计划

参考回答 2 ：之前公司使用的项目管理软件是禅道，我们主要用禅道中测试模块的功能，比 如：用例管理、bug 管理等，也可以在禅道中查看版本需求、版本计划

6.9    有没有用过版本管理工具，在什么时候用

回答思路：svn 、git 都是版本管理工具

参考回答：我们测试用到版本管理工具的机会并不多，开发会使用版本管理工具 git 来管理 代码、同步代码。我们公司之前使用 svn 来管理测试文档、需求文档和一些其他工作文档， 使用版本管理工具可以同步文档，团队协作，保持文档的一致性。但是后面使用较多的是腾 讯在线文档、在线文档可以多人编辑，也能实现团队协作

6.10    抓包工具的原理是什么

回答思路：抓包工具是作为代理服务器，来抓取客户端与服务器之间的请求

参考回答：抓包工具作为代理服务器，相当于在客户端与服务器之间加了一层代理服务器， 可以记录客户端与服务器之间的 HTTP 请求

7. 计算机网络相关问题

7.1    说一下从你在浏览器中输入地址到页面加载出来都经过了哪些

流程

回答思路：填写 url

->

dns 解析地址 ->  服务器接收到请求 ->  服务器处理请求 ->  返回数据 参考回答：在浏览器中填写 url 地址后，首先会从本地 host 文件中查找域名对应的服务器 IP， 如果 host 文件中没有对应 IP，则会通过 DNS 服务器查找到对应 IP。然后向服务器发送 HTTP请求，服务器中的 web 服务器 ( apache/tomcat) 接收请求后，会分辨请求的类型，如果是 访问网页的请求，则把对应的网页资源返回给浏览器。如果是处理数据的请求，比如接口， 会调用业务代码 (java/php) ，通过代码获取数据库 ( mysql) 中的数据并处理后，经 web 服务器返回给浏览器。HTTP 请求传输的数据格式为 json。

7.2    HTTP 协议是什么？和 HTTPS 协议有什么区别

回答思路：HTTP：超文本传输协议、HTTPS=HTTP+SSL ,SSL:安全访问通道加密协议

参考回答：HTTP 是超文本传输协议，约定了浏览器与服务器之间发送 HTTP 请求时使用约定 的数据格式, 比如 HTML 、json ，相当于浏览器与服务器之间的约束。HTTPS 是一种更安全的 加密传输协议，在原有 HTTP 的基础上加入了 SSL ，通过双向的数字证书加密传输的数据， 客户端发起请求时，服务器会将 SSL 证书返回给客户端，建立加密传输通道，提升传输数据 的安全性

7.3    有没有了解过 TCP 协议三次握手

回答思路：TCP：传输控制协议，两个电脑使用TCP 三次握手建立连接，使用 TCP 四次挥手 断开连接

参考回答：TCP 是传输控制协议，两个电脑建立连接时使用。第一次握手时，电脑 A 向电脑 B 发送建立连接的请求时会同步发送 syn 包(seq=j)到服务器，并等待服务器确认。第二次握

手，服务器需要确认客户端的 syn 包，会将包中的一个变量 ack 的值设置为 j+1(即 ack=j+1)，然后服务器向客户端发送数据并携带一个 syn 包(seq=k) ，并等待客户端确认。第三次握手， 客户端收到服务器发过来的 syn  包后，会向服务器发送确认包(ack=k+1)，然后服务器与客户 端建立连接成功，完成三次握手。

7.4    说一下 IP 地址的原理

回答思路：IP：Internet Protocol  网络协议，IP 地址全称为网络协议地址，IP 地址约定了参 与网络的每台设备需要使用独一无二的地址，IP 地址相当于网络世界中的门牌号，通过 IP 地址可以找到目标计算机

参考回答：IP 地址是 4 组 8 位二进制组成的，比如常见的 192.168.3.4 ，换成二进制表示就 是：11000000.10101000.00000011.00000100，所以 IP 地址中的四个数字的取值范围都是 0-255， 目前我们用的 IP 地址都是 IPv4

7.5    讲一下 OSI 七层模型都有哪些层，HTTP 协议作用在哪一层

回答思路：osi(open system interconnection)  开放系统网络连接协议，将网络连接分为七层抽 象模型

参考回答：osi 七层模型从底层往上分别是：物理层->数据链路层-> 网络层->传输层->会话层 ->表示层->应用层。其中应用层的网络协议有：HTTP、SMTP、FTP 等，传输层的协议有：TCP、 UDP 等，网络层的协议有：IP  (IPv4 IPv6)

7.6    HTTP 常见状态码有哪些

回答思路：200：通信正常 ok       404  ：地址错误    500：服务器异常

参考回答：

2xx

成功：2 开头的状态码都代表成功，比如 200。

3xx

重定向：3 开头的状态码代表重定向，比如 304 代表该请求的资源在缓存中。

4xx

客户端错误：4 开头的状态码代表客户端错误， 比如 404 not found  代表客户端请求地 址找不到

5xx

服务器错误：5 开头的状态码代表服务端错误，比如 500 服务器响应异常、502 代理服 务器异常

7.7    有没有了解过请求头参数，举例说明下

回答思路：一个 HTTP 请求分为请求头 header 和请求体 body ，post 请求发送的参数在请求 体中

参考回答：一个完整的 HTTP 请求包含请求头与请求体，请求头中有 URL 、请求方式、请求 头中的参数， 比如 User-Agent :请求来自哪个客户端，refere:请求来自哪个页面，cookie:  请 求发送的 cookie 信息， 以及我们项目中使用的 token ，也是在请求头中发送的，参数名为 Authorzation。

7.8    讲一下 token 、session 、cookie 的区别和共同点

回答思路：token

：用户令牌，；session

：服务器与浏览器之间的一次会话值；Cookie

：服务 器生成，保存在用户浏览器中的数据，一种缓存技术

参考回答：token 就是一个用户令牌，用户使用账号密码通过身份验证后，获取到服务器返 回的 token，token 相当于一个信息的集合，token 中包含了用户信息、登录时间、签名。session： 服务器与浏览器之间的一次会话值，客户端访问服务器时，服务器会返回一个包含用户信息 的 session 值，客户端向服务器发送的请求中都会携带 session 值，服务器会通过 session 值 验证用户的身份。Cookie ：服务器生成，保存在用户浏览器中的数据，一般会保存在浏览器 指定目录下，类似与 txt 文件，是一种缓存技术。

在进行用户验证时，token 比 session 更可靠、更安全。

Cookie 与 session 的区别：cookie 保存在客户端、session 保存在服务器，cookie 的安全性没

有 session 高

Token 与 cookie 相比，cookie 不允许跨域访问，token 可以跨域访问，只要获取到 token 值， 就可以使用token 值在其他客户端访问项目中的接口

7.9  讲一下 B/S 架构和 C/S 架构各有什么优缺点

回答思路：B/S 是浏览器/服务器架构，比如网站程序。   C/S 是客户端服务器架构，比如 APP 参考回答：B/S 架构为浏览器/服务器架构，不需要安装客户端程序，只需要在浏览器打开即 可，使用门槛较低，项目更新时只需要更新后台代码，在浏览器中刷新页面后可以看到更新 后的功能。

C/S 架构为客户端/服务器架构，需要安装客户端程序，使用门槛较高，项目更新时需要更新 后台代码和客户端程序

7.10  有没有了解过微服务架构

回答思路：微服务就是在原来基础 B/S 或 C/S 架构的基础上加上了服务层

参考回答：传统的软件开发模式是：后台开发设计接口，前端开发负责页面及数据展示。随 着项目中的功能越来越丰富，发现有很多基础的数据处理、业务处理功能是通用的，所以开 发人员就将这部分接口设计到微服务层，微服务层都是一些提供底层数据处理的接口

，比如 用户账号、数据处理等功能。以微服务层为基础，在上面定义业务层接口，用来满足项目中 的各种功能

8. Linux 基础相关问题

8.1  在之前的工作中什么时候会用到 linux

回答思路：搭建环境、查看日志、查看服务器运行状态

参考回答：上一家公司的团队中有运维的同事，所以用 linux 的情况并不多，在之前的工作 中也有用到 linux ，比如在测试的时候发现项目运行异常，可以在服务器中查看项目运行的 日志。 自己也在 linux 中搭建过测试环境，按照开发给的搭建环境文档，一步一步操作。有 时候项目运行比较卡的时候，自己也会去服务器中查看硬件的使用情况，比如 CPU 使用率、 内存使用率等

8.2  说一下自己最常用的 linux 命令

回答思路：操作文件类命令、用户权限类命令、查看系统资源类命令

参考回答：之前工作中用到比较多的命令有文件操作类命令，比如：查看文件使用 cat、more、less 、head 、tail ，编辑文件使用 vi ，还有移动文件 mv 、复制文件 cp 、删除文件 rm 、tar 打 包等。用户权限类命令：chmod  可以修改文件的权限、chown 可以修改文件的所属用户。 查看系统资源类命令：top 查看服务器 CPU 使用情况、free -m 查看内存使用情况、ps-ef  查 看进程运行情况、netstat -ano  查看网络端口使用情况。

8.3  如何在 linux 中查看日志

回答思路：实时查看日志文件内容使用tail -f

参考回答：在 linux 服务器中查看日志信息时首先要找到日志文件保存的位置，然后使用命 令 tail

-f  日志文件名来实时查看日志文件中的内容，或者使用tail

- 10

文件名来查看日志文 件的后 10 行。当然也可以将日志文件下载到本地后再去查看，更方便。我们公司运维使用 elk 来作为日志的收集平台

8.4  有没有搭建过测试环境，怎么搭建的

回答思路：1.参考文档手工搭建   2.运维负责  3.使用jekins 调用 docker 一键部署环境   参考回答：上一家公司有运维的同事，所以服务器环境这一块都是运维来负责的，所以搭建 环境做的不多。

自己之前在工作中也搭建过测试环境，按照开发给的文档，在 linux 系统中一步一步操作， 安装数据库、web 服务器、代码执行环境后，需要修改软件配置和修改环境变量后，再将项 目源码包放到 web 服务器指定目录下，修改配置后，在浏览器中访问项目地址，查看是否 搭建成功。3.运维在 jekins 上配置了 docker 一键部署环境，每次测试前需要在 jekins 上点击 构建环境。

8.5  你们用的是什么连接工具，什么版本的 linux 系统？

回答思路：连接工具：xshell       linux 版本：ubuntu

参考回答：我们使用的服务器版本是 ubuntu ，工作中使用的链接工具是 xshell

8.6  有没有写过 shell 脚本

回答思路：测试人员工作中基本不需要编写 shell 脚本

参考回答：shell 脚本就是 linux 系统中的批处理执行脚本，相当于 windows 中的 bat 脚本。 Shell 脚本就是在 linux 常用的命令的基础上加入了判断和循环，实现命令的批量执行，自己 在工作中用的比较少，有了解过，但是没有在工作中实际使用过

8.7  现在有一个目录/opt ,你来查询该目录下名字以 test 开头的文件，

使用的命令

回答思路：查找文件使用find

参考回答：使用命令 find -name test* /opt

8.8  如何查询端口号 8080 的使用情况

回答思路：查询端口使用 netstat

参考回答：使用命令 netstat -ano | gre0

8.9  如何结束 mysql 进程

回答思路：先查询出 mysql 的进程号

再使用 kill

-9

结束进程

参考回答：使用命令 ps -ef | grep mysql  查询出 mysql 的进程号，再使用 kill -9  进程号，结 束 mysql 进程

8.10  现在有一个文件 user.log ，如何在该文件中查找所有的 error 关

键词

回答思路：在前面的命令后面加上管道 grep ，可以在前面命令执行的结果内执行查询

参考回答：使用命令 cat

user.log

|

grep

error       意思是使用 cat 查看文件全部内容，然后在 文件内容中搜索 error 关键词

8.11  有一个实时更新的日志文件，将日志文件的内容写入到另一个

文件中

回答思路：使用tail

-f

实时查看日志文件，使用 >>  追加写入到另一个文件中 参考回答：使用tail -f   日志文件 >>  文件名

8.12 linux 中打包和压缩有什么区别，参数的含义是什么

回答思路：打包是将散乱的文件打成一个文件包，压缩是打包后压缩文件的存储空间

参考回答：打包使用命令 tar -cvf  包名 文件名  其中 c 代表 create 创建，v 代表打印出打包 的过程信息 ，f 代表列出包中的文件

压缩使用 tac -zcvf  在原来打包的基础上增加了 z ，其中 z 代表 gzip  是 linux 中压缩文件的格 式

9. 数据库操作相关问题

重点：1.mysql/oracle 为数据库管理软件，管理一个一个独立的数据库文件

2.

Sql 语句全称为结构化查询语句

，sql 语句与数据库软件是相互独立的

，不同的数据 库管理软件能运行的 sql 语句语法大致相同

3.

Mysql 一般用于中小型项目(免费) 、oracle 一般用于大型项目(收费)

9.1  你们之前的项目使用的是什么数据库，在什么样的情况下自己会

用到数据库

回答思路：我们项目使用的是 mysql 数据库，在定位问题时会查看数据库中的数据

参考回答：在测试的过程中如果发现页面展示的数据是错误的，或者发现接口返回的数据也 是错误的，可以去查看数据库中的数据

，定位问题。有时候也需要修改数据库中的数据进行 测试，比如在理财项目中，需要修改借贷产品的开始还款时间，来测试还款逾期的情况。某 些场景下还需要在数据库中插入测试数据进行测试，比如在数据库中添加测试账号数据

9.2  测试发现 bug 的时候怎么判断是不是数据问题

回答思路：只有数据错误类的 bug 才需要查看数据库

参考回答：发现 bug 时，可以查看数据库中的数据，如果数据库中的数据是正确的，但接口 返回数据错误，那可以认为是接口代码问题。如果接口代码没问题，但是页面展示的数据是错误的，那么数据库表中的数据应该就是错误的，需要去检查数据的来源。

9.3  有没有用过多表查询，举例说明

回答思路：两个表关联查询、三个表关联查询

参考回答：工作中用到数据库的时候，如果查询的数据在一张表中，那可以使用 Navicat  自 带的数据筛选功能，如果查询的数据在多张表中，那可以使用多表查询。多表查询的方式有

很多种，比如等值连接查询、关联查询等

外关联分为左关联和右关联，左连接是以左表为主表，展示左表中的全部数据

右连接是以右表为主表，展示右表中的全部数据

9.4  有没有用过分组查询，举例说明

回答思路：分组查询一般用于做数据统计，使用 group

by

参考回答：分组查询一般用于做数据统计，查询某组数据的最大值、最小值、平均值等，例 如查询学生表中男生的平均成绩、女生的平均成绩

Select sex,avg(score) from student group by sex

需要注意，使用分组查询时，select 后面只可以跟组名或者分组函数

9.5  多表查询时，左连接和右连接有什么不同

回答思路：左连接以左表为主表，右连接以右表为主表

参考回答：使用连接查询时，一般会使用等值连接，等值连接的原理就是通过两个表中某两 列的值相等，将两个表中的数据一起查询出来，这样就会漏掉不满足条件的数据

使用左连接或右连接时，左连接是以左表为主表，展示左表中的全部数据 右连接是以右表为主表，展示右表中的全部数据

9.6  如何查询一张数据库表的前 10 行

回答思路：mysql 分页查询使用 limit,oracle 分页查询使用伪列 rownum

参考回答：mysql :    select * from  学生表 limit 10

Oracle:    select * from  学生表 where rownum <=10

9.7  创建表时都有哪些约束

回答思路：六大约束：主键、唯一、非空、检查、默认、外键

参考回答：创建表时会为某列设计约束，设计约束是为了在插入数据时只插入符合条件的数 据，数据库中有六大约束，分别是：主键约束、唯一约束、非空约束、检查约束、默认约束、 外键约束。其中主键约束：设定该列为主键，该列的数据不可重复，不可为空

唯一约束：该列数据不可重复

非空约束：该列数据不可为空

检查约束：设定条件，该列数据只能插入符合条件的值，比如 check(sex=男 or sex=女) 默认约束：当该列数据为空时，使用默认值

外键约束：A 表中的部门编号列设置为外键，引用 B 表中的部门编号列，向 A 表中插入数据 时，插入的部门编号值只能是 B 表中存在9.8  数据类型中 char 和 varchar 有什么区别

回答思路：char 是定长字符，varchar 是可变长度字符

参考回答：char 的长度是不可变的，而 varchar 的长度是可变的

Char(2)表示可以存储两个字节的字符，例如“男”，但如果只存储了一个字节的字符，那还 是会占两个字节长度

varchar(10)表示最长可以存储 10 个字节字符，如果只存储了 5 个字节，那就只占五个字节 的长度

9.9  模糊查询时，常用的通配符有哪些，分别表示什么含义

回答思路：模糊查询使用的通配符有两个：

%

_

参考回答：模糊查询使用的通配符有两个：%  可以匹配任意长度的字符，_可以匹配任意单 个字符，如果要查询名字以刘开头的学生可以使用：

Select name from student where name like “刘%”

如果要查询名字以刘开头且名字长度为 3 的学生可以使用：

Select name from student where name like “刘__”

9.10  如果想在数据库中插入 1 万条数据，你会使用什么方法

回答思路：1.使用 python 连接 mysql 数据库，再使用循环执行插入语句，循环 10000 次

2.使用jmeter 连接 mysql 数据库，配置 sql 语句请求，配置循环次数为 10000 次

参考回答：可以采用代码的方式，使用 python 连接数据库，再使用循环执行插入语句

2.使用 jmeter 连接 mysql 数据库，配置 sql 语句请求，配置循环次数为 10000 次

10.11  有没有使用过 union 组合查询

回答思路：union 是组合查询，可以将两个查询语句的结果进行组合

参考回答：比如学生表中有学生姓名，课程表中有课程名，现在想查询每个学生学习每门课 的组合情况，可以使用组合查询：

select student_name from student union select class_name from class ，查询结果为学生名称和 课程名称的组合

Union 是默认去重的，如果想展示所有的组合结果，可以使用 union all

10.    APP 测试相关问题

9.1 APP 测试的主要测试点有哪些，请分别举例说明

回答思路：APP 的功能、UI 、兼容性、UE(交互) 、推送、权限、安装卸载更新、弱网等等  参考回答：测试 APP 时首先关注 APP 的业务功能，测试业务功能是否与产品文档一致。测 试 APP 的兼容性，需要测试 APP 兼容性：APP 在 IOS 、安卓两个系统平台以及不同品牌手机 中运行时的界面、功能、体验是否一致。

测试 APP 的 UI 界面：测试 APP 的界面是否与 UI 设计稿设计的一致。

测试 APP 的 UE(用户交互) ：测试 APP 是否兼容全屏手势操作、左滑返回操作、下滑或上滑 操作。

测试 APP 的推送：测试 APP 是否可以及时收到推送消息、推送消息内容是否正确合理、点 击推送可跳转到对应的 APP 界面上。

测试 APP 的权限：测试打开或关闭 APP 的某个权限时，APP 是否可以正常使用，关闭 APP 某个功能时是否有提示。

测试 APP 的安装卸载更新：测试 APP 的安装、卸载，APP 更新前后的数据是否一致，更新 前账号数据自动备份等

测试 APP 的弱网：测试 APP 在网络较差时的界面提示，数据加载时的动画，APP 的功能是 否可用

9.2 APP 测试的兼容性怎么测试，测试哪些平台

回答思路：兼容性测试：测试 APP 在不同系统、不同品牌的手机中，功能是否一致

参考回答：兼容性测试就是测试 APP 在不同系统、不同品牌的手机中，功能是否一致。我 们之前会测试 APP 在 IOS 、安卓两个平台的功能是否一致，并且会挑选安卓平台中的常用品 牌 ， 比如 OPPO 、vivo 、华为、小米等品牌的手机、挑选 IOS 平台中的常用机型 ， 比如 IPhone11, IPhone11pro 进行兼容性测试。测试兼容性时除了关注功能一致，还要关注用户的 使用体验，尽量保证不同平台的用户使用 APP 时的体验是一样的。

9.3 APP 测试中经常遇到的问题有哪些

回答思路：测试 APP 时需要在真机上测试，遇到的兼容性问题会比较多

参考回答：1.测试 APP 功能时，需要重点测试兼容性的问题，要考虑 APP 在不同系统、不同 品牌手机中的运行情况，所以要尽可能的覆盖到最新的手机、最全的品牌，但是在测试的时 候没有条件，所以有些品牌的手机无法去测试兼容性问题。2.现在安卓阵营的手机很多异形 屏，比如水滴屏、刘海屏、挖孔屏等等，测试 UI 时要尽可能多的考虑到不同屏幕形状下的 APP 运行情况。3.APP 的运行速度会受到手机本身配置的影响，如配置较低的手机运行不太 流畅，可能会影响用户的使用体验。

9.4 APP 的推送怎么测试，需要关注哪些测试点

回答思路：正常收到推送的情况，无法收到推送的情况

参考回答：1.测试能不能及时收到推送  2.测试推送消息内容的准确性  3.测试推送消息的 格式是否争取   4.测试点击推送消息能不能跳转到对应页面上 5.测试关闭推送权限后能不能收到(角标 悬浮框)    6.测试在结束这个程序的后台进程后能不能收到推送

9.5 APP 怎么抓包，抓包主要看哪些数据

回答思路：使用抓包工具抓取 APP 中的请求

参考回答：测试 APP 时可以使用抓包工具抓取 APP 中的接口，首先保证 APP 和电脑在同一 个网络下，在 Fiddler 或者 Charles 中设置允许抓取其他客户端的请求，在手机的 wifi 设置中 设置代理，将抓包工具所在电脑的 IP 设置为代理服务器地址，然后可以在抓包工具中查看 来自 APP 的请求。如果请求头中 user-agent 参数的值为手机系统名称，则可以证明这条请求 来自手机，再查看请求地址中的 host ，判断该请求来自哪个 APP。

抓取到对应的请求后，可以查看请求中发送的参数，服务器返回的数据。

9.6 APP 、小程序、公众号 H5 测试有哪些相同点和不同点

回答思路：APP 、小程序、公众号 H5 都属于移动端的测试

参考回答：APP 、小程序、公众号都属于移动端的测试，都需要测试业务功能、UI 界面、兼 容性。小程序是运行在微信或支付宝平台的程序，公众号 H5 本质上是一个网页，只不过是 在微信中打开的网页。测试公众号 H5 网页和 web 网页类似，都是关注页面的功能是否正常， 页面展示是否与 UI 设计一致。测试 APP 和小程序类似，除了需要关注正常的功能、界面之

外还需要重点测试兼容性。测试 APP 在不同系统中功能是否一致，测试小程序在不同版本 的微信、支付宝中运行时功能是否一致。

9.7 APP 弱网测试有没有做过，怎么做

回答思路：使用工具或软件模拟网络较差的环境，测试 APP 在网络较差时的功能是否正常 参考回答：执行弱网测试时，需要模拟出一个网络较差的环境，比如在路由器中给手机限网 速；或者在手机中设置只使用移动网络，然后去电梯楼道这种信号较差的地方；当然也可以 使用fiddler 来设定 APP 发送数据的带宽，实现弱网效果。工作中常用的就是使用fiddler 来 设定网络速率，测试 APP 在网速较差时的加载动画、数据显示、功能是否正常。

9.8 APP 自动化测试有没有做过，怎么做

回答思路：APP  自动化测试在项目中用到的比较少

参考回答：APP  自动化测试在项目中用到的比较少，实现 APP  自动化测试的方式与 web  自 动化测试类似，可以使用 python+appium+unittest 来实现，其中 appium 中提供了控制 APP 的方法。可以说自己没有在工作中做过，对这方面了解的不多。

9.9  有没有用过 monkey ，说一下常用的 monkey 命令

回答思路：monkey 是安卓系统自带的一种操作模拟工具，可以在 APP 界面上模拟用户的随

机操作

参考回答：在之前的工作中，当 APP 要发版上线前，可以使用 monkey 模拟一些随机操作， 查看 APP 在大量随机操作时会不会出现崩溃的情况。使用 monkey 时可以用 adb 命令来发起， 常用的 monkey 命令比如：adb shell monkey -p app 包名 -v -v -v --throttle 1000 --pct-touch 100 其中-p  后面为包名，-v 代表日志的级别，三个--v 代表打印详细的日志信息，--throttle  为操 作的延迟，单位是毫秒，这里代表每操作一次，间隔 1s,--pct-touch 代表操作的百分比，其 中 touch 为触摸屏幕事件，可以换成其他事件，比如滑动。

9.10  有没有用过 adb ，说一下常用的 adb 命令

回答思路：adb:Android debug bridge   中文为安卓调试桥，是电脑与安卓系统之间的调试桥 梁

参考回答：我们在工作中用到的 adb 命令并不多，常用的比如 adbdevices  查看当前连接电 脑的设备；

adb shell  进入安卓后台；adb reboot  重启设备；adb install  安装包：在手机中安装 app；  adb uninstall  包名:卸载 app；adb push  本地文件 手机存储路径：将手机中的文件下载到本 地；adb pull  本地文件 手机存储路径：将本地的文件上传到手机

9.11  有没有用过 sdk ，用到了 sdk 中的哪些功能

回答思路：安卓 SDK 是安卓的开发套件，SDK 中包含了很多开发工具

参考回答：之前在测试 APP 时，偶尔会使用一些 ADB 命令，或者使用 monkey 模拟无序操 作来测试 APP 的稳定性。测试时也会用到 sdk 的 ddms 工具，可以查看系统运行的日志

9.12  有没有做过 APP 性能测试，怎么做

回答思路：APP 的性能测试分为两个方面：1.APP 本身的运行情况。2.APP 调用接口的性能 参考回答：测试 APP 的性能需要关注两个方面：1.APP 需要调用后台接口，可以使用jmeter 测试后台接口的性能，测试接口在多用户并发访问时的响应时间是否满足需求，以及服务器 的处理能力。2.APP 本身的运行情况，测试 APP 的启动时间、中断、耗电量、APP 运行时占 用手机的内存、CPU 情况。但是由于手机机型不同、配置不同，所以 APP 的性能测试最重要 的是测试后台接口的性能11.     自动化测试相关问题

11.1  介绍下在哪个项目中做了自动化，使用的是什么框架？

回答思路：金融类项目不适合做自动化测试，自动化测试一般都是数据管理类项目，比如园 区管理系统

参考回答：我在园区管理项目(物业小区项目)中有做过自动化测试，当时因为版本更新一段

时间后，有很多功能已经趋于稳定了，所以把一些稳定的功能用采用了自动化测试的方式

， 在每次开发转测试后，或者版本上线前会去执行自动化测试

我们使用的是 python 中自带的单元测试框架 unittest。我们使用的代码框架是

：基于 unittest 与 DDT 设计的代码框架，实现了数据驱动测试 ddt、元素统一管理(ini) ，统一执行生成报告、

定时执行、 日志记录等功能，代码中主要有：1.配置部分 2.测试用例 3.基础方法 4.执行模 块 5.测试数据几个模块

11.2  说一下你们的自动化测试是怎么做的(如果把自动化测试交给你，

你能不能做)

回答思路：先了解项目能不能做自动化测试，再讲怎么去做，讲的时候加上语气词 参考回答：1.首先了解下项目的类型，项目的开发阶段                         2.如果项目已经上线很长时间且处于稳定阶段，并且不是金融类项目             3.我之前是这么来写自动化测试脚本的：

1.首先会挑选出可以被代码实现的测试用例(自动化测试的覆盖率 50%左右)                        2.设计代码框架，将代码分层管理，并封装需要用到的操作方法比如：selenium 中的点

击、输入、获取文本等；获取 ini 配置文件数据的方法；打印日志的方法 3.将页面元素定位信息收集到 ini 配置文件中                            4.按照功能测试用例的步骤编写自动化测试用例，设计断言              5.在测试用例中加入 ddt,实现用例的参数化，读取 excel 中的测试数据     6.编写统一执行的脚本，批量执行用例并生成报告

11.3  你对 python 语言了解到什么程度，Python 中的数据类型有哪些

回答思路：对基础语法比较熟悉，常用数据类型：整型、浮点型、字符串、布尔型、列表、 元组、字典、集合

参考回答：python 中常用的数据类型有：整型、浮点型、字符串、布尔型、列表、元组、 字典、集合。常用的数据类型是字符串和列表

11.4  说一下列表的切片、排序、反转，元素重复次数、列表长度

回答思路：需要熟悉列表的操作方法

参考回答：列表的切片就是使用索引获取列表中的片段，排序列表可以使用 sort() ，反转列 表使用 reverse()

获取元素的重复次数使用 count() ，获取列表的长度使用 len()

11.5  说一下元组跟列表有什么区别

回答思路：元组不可修改

参考回答：元组使用圆括号，列表使用方括号，列表可以随意修改，元组不可以修改，元组 一般用来保存不可修改的数据

11.6  字典有什么特点，怎么向一个字典中新增一个键值对

回答思路：字典是键值对

参考回答：字典的特点是键值对，一个键对应一个值，和接口中的数据请求为 json 格式一 致。向字典中插入数据时可以直接向列表中写入键值对，如果字典中没有存在这个键，那字 典就会新增一个键值对

比如：字典 a = {} , 向字典中插入数据使用 a [‘name’]=’jack’

11.7  什么是封装方法？都封装过哪些方法

回答思路：封装：将实现某段功能的代码封装到一个方法中

参考回答：封装就是将实现某段功能的代码封装到一个方法中，通过调用这个方法名来执行 这段代码。在我们之前写的自动化脚本中也使用过封装，比如封装点击元素的方法、输入文

本的方法、获取页面文本的方法

，获取 ini 配置文件的方法、获取 excel 数据的方法、打印日

志的方法等

11.8  Python 中初始化方法是怎么用的？

回答思路：初始化方法：相当于类的初始化，使用类时的准备工作

参考回答：Python 中的初始化方法一般定义在类中，相当于类的准备工作，为这个类创建 对象时会自动执行初始化方法，初始化方法中定义的参数，也需要在创建对象时传参。有点类似 java 中的构造方法。

11.9  Python 中类里面的 self 参数有什么作用？

回答思路：self:代表自己，可以理解为类自身

参考回答：self 的意思是自己，代码中可以理解为类自身，在定义类时，可以使用 self参数 调用同一个类中的属性

，使用 self参数调用同一个类中的其他方法。代码执行时，self 的值 是对象名

11.10  在使用 Python 封装方法时，方法中参数带一个星号和带两个

星号的区别

回答思路：一个星号：传入多个参数值；两个星号：传入键值对参数

参考回答：在定义方法时，如果参数名前面带一个星号，调用该方法时，可以为参数传入多 个参数值，并且参数值会被自动保存为元组。如果参数名前面带两个星号，调用方法时，可 以为参数传入键值对参数

11.11  有没有了解过继承和多态，请解释一下

回答思路：继承

：子类继承父类的属性和方法，多态

：子类中的方法与父类中的方法名一致

，

但功能不同

参考回答：Python 中定义类时，子类可以继承父类中的属性和方法名，如果子类中的方法 名和父类中的方法名一致，但代码和功能不一致，可以称为方法的重载或多态。

11.12  selenium 实现 web 自动化的原理

回答思路：selenium 是一个代码库，提供了控制浏览器的方法

参考回答：1.使用 python 编写脚本时调用 selenium 中控制浏览器的方法；2.执行脚本时通 过浏览器驱动程序(chromedriver.exe)将指令发送给浏览器；3.浏览器会按照脚本中编写的步 骤执行

11.13  介绍常见的元素定位方法，id,name 等等

回答思路：id

>

name

>

xpath

>css_selector

>

class_name

>link_text

>tag_name

局部定位(二次

定位)

参考回答：常用的元素定位方法有：

id > name > xpath >css_selector > class_name >link_text >tag_name  局部定位(二次定位)。

其中 id 、name 、xpath 、css_selector 常用来做精确定位，用于定位某个元素。Class_name、 link_text 、tag_name 常用来做模糊定位，可以一次定位多个元素。还可以使用局部定位，先 定位到某个元素，再从这个元素的范围内进行第二次定位

11.14  如果定位元素时，一个元素的 id经常变化需要怎么定位

回答思路：id 如果变动，那就使用其他定位方式

参考回答：如果 ID 出现变动时，那就采用其他元素定位方式，可以看下有没有不变的元素 信息，比如 css_selector ，或者使用 tag_name 标签名称,模糊定位，或者使用分层定位，先定 位到这个元素的上一层，再使用 class_name 或者 tag_name 执行第二次定位

11.15  说一下你在写脚本时遇到过哪些问题

回答思路：脚本编写时的问题，元素定位不到的问题

参考回答：1.浏览器自动升级与使用的浏览器驱动版本不匹配；2.元素定位不到的问题(嵌套 网页、相同的 id 属性，变动的 id 属性)

11.16  元素定位失败有哪些常见的原因

回答思路：变动的 id 属性、元素在嵌套网页中

参考回答：1.等待时间，需要等待浏览器把页面加载出来

2.使用的元素定位方式不正确

3.相同的 id 属性，变动的 id 属性

4.存在嵌套网页

5.元素没有显示在页面中

11.17  unittest 中用到了哪些功能

回答思路：测试用例、测试套件、执行器

参考回答：unittest 是 python  自带的单元测试框架，我们使用 unittest 来实现 UI  自动化测试， 会用到 unittest 中的三个功能，TestCase 测试用例、TestSuit 测试套件、TestRunner 测试执行 器。首先将测试的步骤按照 TestCase 的方式编写，然后将需要执行的用例添加到测试套件中， 最后使用执行器来执行测试套件，实现用例的批量执行

11.18  unittest 在脚本中起到了什么作用

回答思路：脚本中加入 unittest 后可以让脚本变成真正的测试用例

参考回答：1.什么是框架：一整套代码结构

，写代码时使用框架中的结构

，可以使用框架中

已有的功能

2.脚本中加入 unittest 带来了两个变化 1.可以把之前的脚本变成测试用例；2.可以实现用例 的批量执行

首先将测试的步骤按照 TestCase 的方式编写，然后将需要执行的用例添加到测试套件中，最 后使用执行器来执行测试套件，实现用例的批量执行

11.19  执行自动化怎么生成测试报告

回答思路：使用第三方脚本：HTMLTestRunner.py

参考回答： 我们编写 自动化时 ， 为了生成比较美观的报告 ，使用了一个第三方脚本 HTMLTestRunner.py ，这个脚本中的执行器可以替代 unittest 中自带的执行器，并且执行测试 后可以生成比较美观的 html 格式的报告。如果使用 pytest 测试框架，可以使用 allure 生成 专业的测试报告

11.20  执行自动化怎么设置定时执行

回答思路：编写脚本实现定时执行

参考回答：编写脚本，使用循环获取当前系统时间，判断系统时间是否等于测试开始时间， 如果等于测试开始时间，则调用统一执行的脚本来执行所有用例并生成测试报告，如果不等 于测试开始时间，则继续等待

11.21  介绍下 python 中的包和模块

回答思路：包

：类似一个文件夹

，是脚本的集合。模块

：一个脚本文件

，管理脚本中的类和

参考回答：Python 中将脚本所在的文件夹当做包 package ，需要调用其他脚本时，需要从包 开始，一层一层引入。模块 module ：一个脚本文件，用来管理脚本中的类和变量

11.22  能不能用 python 写一个冒泡排序或者选择排序

回答思路：Python 中的冒泡排序，使用双层循环，外循环控制排序次数， 内循环控制排序 顺序

参考回答： 冒泡排序：相邻两个元素比较大小后换位置

选择排序：让每个元素与列表中的其他元素比较大小后换位置

11.23  你认为自动化测试有哪些优缺点

回答思路： 自动化的优势：节省测试时间。

劣势：测试不全面

参考回答：1.优点：节省测试时间，可以在较短时间内执行更多的测试用例

2.缺点： 自动化测试覆盖率不高，有些测试场景无法使用自动化测试

自动化测试很难发现 bug

在版本功能变更后， 自动化测试用例需要进行维护修改

11.24  你在之前做自动化测试的过程中有无发现 bug,请举例

回答思路： 自动化测试也是功能测试，所以发现的 bug 就是普通的功能 bug

参考回答：1. 园区管理项目：新建楼栋信息时，提交一条数据后，发现数据的展示页面由原 来的倒序，变成了正序，原来默认展示最新的记录，现在最新的记录到了最后一页

2.   关于上传文件的功能，执行自动化时，使用 send_keys 上传文件时没有选择文件的弹框， 上传超过了页面上限制的较大文件时，也可以上传成功。

11.25  说一下搭建自动化测试环境的步骤

回答思路：1.安装 Python 。2.安装 selenium。3.部署浏览器驱动

4.安装浏览器

5.写脚本测试

参考回答： 1. 首先安装 Python 代码运行环境，并配置 Python 环境变量 。2. 使用 pip 安装 selenium 包 ， 通过 selenium  可 以导入控制浏览器 的方法 。 3. 部署浏 览器驱动程序 ， chromedrvier.exe/geckdriver.exe，浏览器驱动程序所在的文件夹可以添加到环境变量 path 中。 4.安装浏览器，浏览器的版本需要与浏览器驱动程序的版本一致。5.可以编写简单的脚本测 试一下，比如百度页面

11.26  请以手写的方式写一个百度页面的点击

回答思路：这个是在考验自动化脚本的基本功

参考回答：1.导入 selenium 中控制浏览器的方法

2.   创建浏览器对象(打开空白浏览器窗口)

3.   Driver.get(‘ https://www.baidu.com’)  打开网址

4.   在网页中查找 name=wd 的元素，并输入文本“huawei ”

5.   在网页中查找 id=su 的元素，并点击元素

11.27  做过多长时间的自动化，写了多少条自动化用例，哪个项目

回答思路：  工作中以功能测试为主， 自动化测试为辅

参考回答：我在园区管理项目(物业小区项目)中有做过自动化测试，当时因为版本更新一段

时间后，有很多功能已经趋于稳定了，所以把一些稳定的功能用采用了自动化测试的方式

， 在每次开发转测试后

，或者版本上线前会去执行自动化测试

，自动化测试占工作比例在 30%

左右。从最开始的封装基础操作脚本到写用例，总的自动化测试用例数量在 200-250 之间

11.28  我们这边是用 java 做自动化，你觉得你能胜任吗

回答思路：Python  自动化的思路与java  自动化类似

参 考 回 答 ：  我 们 公 司 之 前 使 用 的 是 Python   写 脚 本 来 实 现 自 动 化 测 试 ， Python+selenium+unittest ，因为 Python 编写自动化脚本相对来说容易一些，所以没有用过 java ，据我了解，现在只有部分大公司才会使用 java 来去编写自动化，消耗的时间比较长， 使用的是 java+selenium+testNg(测试框架) 。虽然之前没写过，但是如果有机会、有时间去学 习的话，相信自己也可以写，因为代码思路都是类似的。

11.29  什么叫数据驱动测试，你们是怎么做的

回答思路：ddt

：data

driver

test

数据驱动测试

参考回答：我们写自动化用例时，可以在用例中加入 ddt，ddt 是 unittest 测试框架的补充功 能，可以实现测试用例的参数化，我们使用ddt 来为测试用例方法传人参数。

Ddt 是一个装饰器，使用ddt 装饰测试用例方法，可以在测试用例原有功能的基础上添加参 数功能，向测试用例方法传入参数。当传入多个参数时，需要使用 unpack 进行拆包，具体 使用参考代码：

12.    性能测试相关问题

12.1    说一下你在之前的项目中是怎么做性能测试的

回答思路：结合项目回答性能测试流程

参考回答：1.什么情况下执行性能测试

1.1  新项目上线前，可以通过压力测试找到当前项目能够承受的最大并发(吞吐量最大值)

1.2  项目运营中

，在推出某些活动或新功能之前

，通过压力测试找到项目能够承受的最大并 发

1.3  项目交付给客户

，客户有明确的性能需求

，需要通过性能测试

，判断当前项目能否满足

1.4  项目运营中，生产环境出现性能问题，需要通过性能测试复现当时的场景 2.如果有性能需求，需要根据需求估算性能指标，比如根据订单量计算 TPS      3.设计测试方案、准备测试数据、测试环境、测试工具

4.录制并调试脚本，选择项目中的核心功能、用户使用较多的功能                      5.按照测试方案执行测试，添加监控，记录每组并发用户对应的响应时间、吞吐量、TPS、 服务器资源使用情况等数据

6.分析测试结果，可以得到满足用户性能需求时对应的并发数(最优并发),也可以得到吞吐量 最大值时对应的并发数(最大并发) ，判断是否满足用户性能需求，不满足性能需求时与开发 一同分析问题产生的原因

7.将数据整理到测试报告中，报告中使用表格描述本次的所有数据，测试结论以及性能调优 建议12.2    介绍下常见的性能指标以及含义

回答思路：常见的性能指标：并发数、响应时间、TPS 、吞吐量、HPS 、连接数等

参考回答：常见的性能指标有并发数、响应时间、TPS 、吞吐量、HPS 、连接数等，响应时 间反映了服务器处理请求的快慢；TPS 为每秒事务数反映了服务器每秒处理事务的数量，吞 吐量为服务器处理的数据量，HPS 为每秒点击量可以理解为每秒发送的请求数，连接数为客 户端与服务器之间的连接数量

通过并发数与事务响应时间可以推算出 TPS ，当事务响应时间较短时，服务器每秒处理的请 求数越多，每秒钟处理的数据量也越大，所以响应时间是性能测试中最重要的指标

12.3    做性能测试一般关注服务器哪些硬件指标

回答思路：服务器三大硬件：CPU  硬盘 内存

参考回答：测试时主要关注服务器 CPU 使用率、内存使用率，磁盘 IO 使用率等，CPU 使用 率较高时，服务器处理性能会下降，所以在测试时需要记录服务器的硬件使用情况

12.4    loadrunner 用的哪个版本，使用过程中遇到过哪些问题

回答思路：loadrunner12 版本使用试用版，试用版只能并发 50 个用户，loadrunner11 可以 破解，破解后可以并发 1000 个用户

参考回答：自己在之前的工作中没有专门负责性能测试，也是在工作空闲的时候去学习，用 的是 loadrunner12 的试用版，loadrunner12 录制脚本时支持的浏览器版本较高，但是只能设 定 50 个并发用户，loadrunner11 可以破解，支持的并发数较多，但是录制脚本时支持的浏 览器版本较低，使用试用版 loadrunner 时有时候会遇到无法生成脚本的问题，就需要重新安 装了

12.5    你之前测试时得到项目的最大并发是多少

回答思路：最大并发用户数是吞吐量最大值或硬件使用率最大值对应的并发数，如果对性能 测试比较自信，可以说具体的测试过程，如果对性能测试不自信，可以说自己是在工作空闲 时间去学习的性能测试

参考回答 1 ：在之前的工作中， 自己利用项目空闲时间学习性能测试，在智慧园区项目(可 以换其他项目)中执行了压力测试，通过不断的增加并发数，在吞吐量最大时观察得到的并 发数是 160 个，由于园区项目在实际的使用中，用户并发的场景较少，所以并没有去做性能 优化

参考回答 2 ：在之前的工作中，在 P2P 项目(可以换成其他项目)的一次大版本上线之前执行 了压力测试，通过不断的增加并发数，在并发到 160 个用户的时候发现系统 CPU 使用率达 到了 99% ，得到最大并发数为 160 个

12.6    之前遇到过哪些性能问题，举几个例子

回答思路：我们做性能测试时能发现的问题大多数是和硬件相关的

参考回答：

1. 内存泄漏问题。原因：程序结束后没有正常释放之前占用的内存空间，导致内存使用率越 来越高。解决办法：检查代码中的进程结束机制，优化内存占用方案。测试方法：使用同样 的并发数，测试多次，检查内存使用率是否存在一直增加的现象

2.服务器资源使用率较高导致响应时间长的问题。原因：CPU 使用率高，导致处理效率变低

解决办法：提升服务器硬件配置，或优化代码，减少对 CPU 的消耗

测试方法：执行测试时监控服务器硬件资源使用率，CPU 使用率超过 80%时，CPU 的处理性 能会下降

3.服务器连接数配置不足导致事务响应时间长的问题，web 服务器连接数或数据库连接数不 足，在多用户并发访问时，需要等待导致事务响应时间长

测试方法：执行测试时添加服务器监控，如果发现用户量上升时连接数无法继续上升可以确 定服务器连接数不足

解决办法：提高服务器/数据库连接数配置

12.7    性能测试的方法有哪些，负载测试和压力测试的区别是什么？

回答思路：列举出自己了解的性能测试方法

参考回答：

1.负载测试：不断增加并发数进行测试，加到响应时间或 TPS 满足性能需求为止可以得到最 优并发用户数

2.压力测试：不断增加并发数进行测试，加到服务器资源使用率达到最大，或吞吐量达到最 大为止，可以得到最大并发用户数

3.基准测试：设定一个用户循环执行场景，观察响应时间，相当于性能测试中的冒烟测试

4.疲劳测试(稳定性测试) ：测试系统在有负载的情况下长时间运行是否出现性能劣化

5.单一场景测试：测试单个场景

6.混合场景测试：同时测试多个场景，按照业务百分比分配并发用户数

12.8    loadrunner 参数化是怎么设置的，都用过哪些类型的参数？

回答思路：loadrunner 中添加参数化是为了让脚本运行的更接近真实使用情况

参考回答：loadrunner 在脚本中设置参数化是为了让脚本运行的更接近真实使用情况，常用 的参数类型有随机数、 自定义参数等，参数一般设置为顺序取值、每次迭代更新

12.9    loadrunner 脚本中检查点的作用是什么？

回答思路：检查点就是脚本中的断言，用来判断事务是否执行成功

参考回答：脚本中加入检查点可以自动判断事务是否执行成功，尤其是并发执行脚本时，因 为执行的次数较多，没办法手工判断，事务中加入检查点后可以统计事务的通过率

12.10    Loadrunner 中有没有用过关联函数，是怎么设置的？

回答思路：关联函数可以使用手动关联和 自动关联两种方式

参考回答：关联函数就是将服务器返回的动态数据获取到，保存到参数中，在其他方法中使 用这个参数。我们之前的项目中，打开首页后服务器会返回一个动态的 session 值，在登录 时需要将 session 值传给服务器，所以使用关联函数来处理这个动态的 session 值。可以使用 自动关联，在脚本录制结束后，自动扫描出需要关联的参数。也可以使用手动关联，去查找 返回动态值的方法，在该方法前添加一个关联函数，设置动态值的左右边界、参数名，在其 他方法中引用这个动态参数。回放脚本后查看是否成功。

12.11    执行测试后你怎么判断有没有存在性能问题

回答思路：判断得到的数据是否满足性能需求

参考回答：我们执行的性能测试是一个过程，设定不同的并发用户，比如 20 、40 、60 、80等，记录每组并发用户测试时得到的事务响应时间、TPS 、吞吐量、硬件资源使用率等指标， 判断得到的数据能否满足性能需求。假设客户性能需求为：满足 200 个用户并发访问的同时， 各个事务的响应时间在 2s 以内，如果得到的事务响应时间及并发数可以满足性能需求，那 就说明没有明显的性能问题；如果响应时间及并发数无法满足客户需求，那就需要去分析定位原因，优化系统性能。通过测试，可以得到吞吐量/TPS 最大时对应的并发数，就是系统 能够承受的最大并发，可以得到满足用户性能需求时对应的并发数，比如响应时间为 2s 时 对应的并发数，就是最优并发。

12.12    你自己有没有定位过性能问题，定位的思路是什么

回答思路：从脚本、负载机、网络、服务器硬件、服务器软件配置、代码等方面考虑 参考回答：1.脚本的原因：事务中包含集合点、等待时间、检查点

2. 负载机的原因：2.1  负载机资源充足的情况下优先使用进程的方式执行脚本，2.2  负载机 所处的网络环境较差 3.服务器的原因：1.硬件资源使用率较；2.服务器带宽配置(服务器每秒 传输的数据) 3.检查服务器的连接数配置；4.代码相关的原因：1.代码逻辑设计、代码执行效 率低 2.sql 语句性能低，数据量大时影响查询效率

12.13    性能指标中吞吐量与点击量、TPS 与响应时间的关系是什么

回答思路：响应时间越长，说明服务器处理性能变差，TPS 、吞吐量、点击量都会下降

参考回答：测试时关注最多的性能指标就是响应时间，响应时间变长时，说明服务器处理性 能下降，导致服务器每秒处理的事务数(TPS)下降，吞吐量下降，点击量下降，所以响应时 间和其他指标都是反比关系，只要响应时间在可控范围内，其他性能指标也会在正常值范围 内

12.14    如果服务器连接数不足会引起哪些方面的问题？

回答思路：连接数不足时，会导致响应时间边长

参考回答：我们一般关注的连接数是数据库连接数和 web 服务器连接数，mysql 默认最大连 接数为 150 个，web 服务器的最大连接数(apache)一般也是 150 个(tomcat75 个) ，用户访问 项目时都需要与服务器建立连接

，所以当访问量变多时

，会导致连接数不够用

，导致用户等 待时间变长，反馈到页面上就是页面的加载时间变长

12.15    测试结束后发现事务响应时间较长时，可能的原因有哪些

回答思路：从脚本、负载机、网络、服务器硬件、服务器软件配置、代码等方面考虑 参考回答：1.脚本的原因：事务中包含集合点、等待时间、检查点

2. 负载机的原因：2.1  负载机资源充足的情况下优先使用进程的方式执行脚本，2.2  负载机 所处的网络环境较差

3.服务器的原因：1.硬件资源使用率较高：CPU   内存 硬盘                       2.服务器带宽配置(服务器每秒传输的数据)                                                 3.检查服务器的连接数配置 ：apache 默认最大并发的连接数：150

mysql 默认的最大并发连接数：151 4.代码相关的原因：1.代码逻辑设计、代码执行效率低2.sql 语句性能低，数据量大时影响查询效率

12.16    脚本中加集合点的作用，思考时间的作用

回答思路：集合点是为了实现绝对并发，思考时间是为了模拟用户真实操作

参考回答：脚本中加入集合点是为了实现绝对并发，在某个操作的前面加入集合点，虚拟用 户在执行到集合点时会等待所有用户一起后再去执行下面的步骤，可以实现绝对并发。脚本 中加入思考时间可以模拟用户的真实操作，我们一般采用录制的时间，并在录制的时间基础 上加入随机比例

12.17    怎么选择需要做性能测试的场景

回答思路：选择用户使用较多的场景、项目核心功能、对性能要求较高的功能

参考回答：执行性能测试时，不需要测试项目中的全部功能，只需要挑选用户使用较多的场 景、项目核心功能、对性能要求较高的功能就可以。比如商城项目，用户用的最多的功能就 是搜索商品、浏览商品详情、添加购物车、提交订单、支付、查看物流信息等，这些功能刚 好也是商城的核心功能，也是对性能要求较高的功能12.18    怎么测试数据库的性能

回答思路：测试数据库执行 sql 语句的响应时间

参考回答：如果想测试数据库的性能，可以使用 jmeter 创建 sql 语句的请求，配置并发线程 数与持续时间，观察聚合报告中 sql 语句执行的响应时间，通过响应时间的长短来判断数据 库在受到并发访问时 sql 语句的执行情况

12.19    测试时怎么监控服务器硬件资源

回答思路：1.使用 loadrunner  自带的监控

2.使用 spotlight 监控服务器资源

3.在服务器中使

用 top 命令查看

参考回答：做性能测试时需要实时监控服务器的硬件使用情况，我们一般使用 loadrunner 自带的监控，在 controller 中添加资源监控，可以将监控的数据与测试数据保存到一起，是 最好的服务器资源监控方式。也可以使用 spotlight 来监控服务器资源或者使用连接工具， 连接服务器，在服务器中使用 top 命令来查看服务器资源使用情况。但是后两种方法的缺点 是没办法自动保存监控的数据。

12.20    做性能测试前为什么需要估算并发数，怎么估算

回答思路：如果没有明确的性能需求时，需要估算测试时使用的并发数

参考回答 1 ：比如一个农贸商品的买卖平台，经统计发现一天产生的订单量为 5 万单

需要测试当前项目能否满足该订单量下的用户性能需求，用户需求为每个请求响应时间不超 过 2s

二八原则：80%业务量会在 20% 的时间段内产生

假设用户一般会在早上 9 点到下午 5 点之间使用网站下订单

50000*80%

计算每秒钟产生的订单量= — — — — — — — — — = 7 (TPS)

8*3600*20%

2.如果系统处理提交订单请求的响应时间为 2s,那一个用户使用提交订单时，系统每秒处理 的订单量为 0.5 个

3.所以要达到系统 TPS=7 ，需要 14 个用户同时提交订单，得到的并发用户数 14 个，这个 14 仅仅是执行测试时的并发数参考值

4.最后得到：我们的测试目标是，系统 TPS 达到 7 时，响应时间是否在 2s 以内，所以从 14 个并发数开始测试，逐渐增加用户数，直到 TPS 达到 7

参考回答 2 ：可以通过分析数据库中的用户访问记录或者日志记录，得到用户同时在线的峰 值，比如 1500 ，那测试时可以使用最高峰在线人数的 10%作为并发用户的参考值

13.    接口测试相关问题

13.1    在哪个项目中做过接口测试，都有哪些接口

回答思路：园区项目/物业项目中的接口，页面上每个和后台数据交互的功能都会对应一个 接口，比如新建楼栋，会调用新建楼栋接口、查询楼栋会对应查询楼栋接口

参考回答：在之前的园区项目/物业项目是采用前后端分离的模式开发的，前端页面只负责 页面展示，后台开发会提供业务接口，获取数据库中的数据并处理后通过接口返回给前端页 面。当时测试时因为后台开发进度较快，后台开发已经写好了接口，但是前端页面还没有开 发好，所以先测试了接口。

13.2    说一下你之前在项目中是怎么开展接口测试的

回答思路：1.拿到接口描述 2.编写接口测试用例 3.使用 postman 或 jmeter 测试接口

参考回答：在之前的项目中测试接口是因为后台开发先写出了接口，所以去测试接口的功能， 保证接口的返回数据是正常可靠的。1.测试前需要拿到接口文档，了解接口的访问方式。2. 根据接口文档编写测试用例，测试接口在传入不同参数时的返回数据 。3. 使用jmeter 或 postman 测试接口。4.将测试结果反馈给开发

13.3    接口测试工具中 Jmeter 与 Postman 哪个更好用，有什么区别

回答思路：jmeter 可以设置线程数进行性能测试，postman 主要用来测试接口的功能

参考回答：jmeter 功能更强大，除了可以测试接口的功能之外，还可以设置并发数测试接口 的性能。如果只是为了测试接口的功能，那 postman 更好用，界面简洁，功能简单。

13.4    测试过哪些类型的请求，怎么设计接口测试用例

回答思路：测试过 HTTP 协议的接口，设计接口测试用例从返回数据、传入参数、业务逻辑 几个方面设计

参考回答：之前物业项目中的接口都是 HTTP 请求，测试接口时从返回数据、传入参数、业 务逻辑几个方面考虑，1.测试接口传入正确的参数时，接口的返回数据是否正确(1.接口返回 数据格式与文档一致，2 返回数据与数据库中一致),2.测试接口传入的参数值不符合逻辑要 求时，比如传入的手机号不符合格式要求，接口的返回数据是否正确。3.测试接口传入参数 格式错误时(参数名错误、缺少参数) ，接口的返回数据是否正确。                       3.接口使用了其他请求方法时，比如接口文档说明要使用 get,测试时使用 post,查看接口返回 数据。4.测试接口的 token 问题，缺少 token 、token 过期、token 验证失败问题

13.5    Http 接口常见的方法有哪些

回答思路：get 、post 、put 、delete

参考回答：常见的请求方法有 get/post/put/delete,其中 get 一般用户获取资源、查询，post 一般用于提交数据、更新数据，put 一般用户提交数据、新增数据，delete 一般用于删除操 作。http 请求方法有很多，最常用的是这四个

13.6    Http 请求方法中的 GET 和 POST 有哪些区别

回答思路：请求方式、传参方式、安全性三个方面的不同

参考回答：1.get 请求一般对应获取数据的功能，例如查询、列表等功能，post 请求一般对 应提交、修改数据的功能，例如新增、编辑数据功能

2.get 请求发送的数据在 url 中，post 请求发送的数据在请求体中(json 格式)             3.post 请求发送的数据量比 get 请求多，并且相对于 get 请求，post 请求安全一些

13.7    使用过 Jmeter 中的哪些功能，举例说明一下

回答思路：jmeter 常用的插件

参考回答：jmeter 常用的插件有 HTTP 请求默认值、信息头管理器、断言、提取器、参数化 插件、聚合报告等。可以使用断言来判断接口返回数据是否符合预期，使用json 提取器提 取接口返回数据中的某个数据，在聚合报告中查看接口响应时间等

13.8    Jmeter 参数化怎么用

回答思路：在文件中设置参数值，使用 csv 数据文件设置来配置参数

参考回答：如果想测试接口传入不同参数值时的返回数据，可以设置参数，通过 csv 数据文 件设置来配置参数的取值

13.9    Jmeter 怎么设置接口关联

回答思路：json 提取器、正则表达式提取器，提取登录接口返回的token

参考回答：我们之前的园区项目中，访问接口时需要在请求头中传入 token 信息，使用jmeter 时，需要先配置登录接口，然后在登录接口中添加正则表达式提取器或者 json 提取器，提 取登录接口返回的 token 信息，然后将获取到的 token 配置到请求头管理器中给其他接口使 用

13.10    Jmeter 怎么设置断言，断言的作用是什么

回答思路：json 断言、响应断言

参考回答：jmeter 中设置断言可以使用json 断言或响应断言，通过断言可以自动去判断接 口是否返回了预期的数据

13.11    Postman 怎么设置环境变量和全局变量

回答思路：使用环境变量时需要选择环境，使用全局变量时不需要选择，可以直接使用    参考回答：设置环境变量时，需要先添加环境，在环境中添加变量，测试集中的接口请求在 使用这个变量时，需要在右上角选择对应的环境。设置全局变量时，可以直接设置变量名、 变量值，postman 中的所有接口都可以使用全局变量，我之前使用 postman 时

，会把服务器

的地址、token 的值设置为环境变量

13.12    之前测试的项目中一共有多少个接口，写了多少接口测试用

例

回答思路：园区项目中的每个跟数据相关的功能都有对应的接口，整个项目有 200-300 个接 口

参考回答：之前测试的园区管理项目采用的是前后端分离的方式开发，前端负责页面展示效 果，后端通过接口将数据库中的数据返回给前端，所以园区项目中每个跟数据相关的功能都 有对应的接口，整个项目经过不断的更新迭代，有 200 多个接口。设计接口的功能测试用例 时需要考虑正例与反例，正例就是测试接口在传入正常参数时接口的返回数据是否正确，反 例则需要考虑接口传入异常参数时，比如参数值不符合要求、参数格式错误时的接口返回数 据，还需要考虑token 用户验证。但是并不是每个接口都写了全部的测试用例，只写了主要 的接口，在园区项目中写的接口测试用例有 500 多条。

13.13    接口测试一般关注哪些测试点

否完善

参考回答：1.接口传入正确的参数时，观察接口的返回数据是否正确(1.接口返回数据格式与 文档一致，2 返回数据与数据库中一致) 。2.关注接口传入的参数值不符合逻辑要求时，接口 的返回数据是否正确。3.接口传入的参数格式错误时，比如缺失参数、格式错误，测试接口 的返回数据是否正确。4.测试接口在使用不同的请求方法访问时，get/post ，接口的返回数 据是否正确。5.关注 token 问题，测试 token 过期、失效、验证失败的问题

13.14    如何使用 jmeter 做接口的性能测试

回答思路：1.设置并发  2.添加监控  3.执行测试，设置不同的并发数并收集结果 参考回答：

1.在接口功能正常的前提下，可以在线程组中设置线程数对接口执行性能测试     2.在线程组中设置并发线程数、线程递增时间、测试持续的时间                 3.根据需要添加事务、定时器(集合点) 、服务器资源监控、聚合报告、TPS                    4.执行测试、记录每组并发线程数对应的响应时间、TPS 、服务器资源使用率等数据 5.结合测试结果，判断当前接口的性能是否满足需求                            6.可以在测试结果中分析得到：1.TPS 最大值对应的并发数

2.满足用户响应时间需求时对应的并发数

3.达到用户并发数要求时对应的响应时间

13.15    执行接口性能测试时主要关注哪些指标，怎么判断是否存在

性能问题

回答思路：软件指标：响应时间、TPS 、HPS 。硬件指标：CPU 使用率、内存使用率、硬盘 IO

使用率

参考回答：使用 jmeter 测试接口性能时需要设置不同组并发线程数，记录每组并发数对应 的响应时间、TPS 、HPS 、CPU 使用率、 内存使用率、磁盘 IO 使用率等等。其中最关注的就 是响应时间，当我们的性能需求是满足 200 用户并发时响应时间在 200ms 以内，通过测试 可以得到 200 个用户并发时的响应时间，也可以得到响应时间在 200ms 时对应的并发数， 从而判断当前接口的性能是否满足了用户需求。在测试后也可以得到 TPS 最大时对应的并发数，就是接口能承受的最大并发数。测试后可以得到每组并发数对应的服务器资源使用率， 可以判断接口在承受并发访问时，服务器的硬件资源使用情况是否正常。

13.16    Jmeter 怎么监控服务器硬件资源使用情况

回答思路：使用jmeter 中的性能采集器，需要在服务器中启动 severAgent 来采集服务器的 资源使用情况

参考回答：使用 jmeter 监控服务器资源使用情况时，需要在服务器中启动 severAgent 来采 集服务器的资源使用情况，在 jmeter 中添加性能采集器，配置监控服务器的 IP 地址，端口 号，需要监控的硬件后，开始执行测试，可以在性能采集器中看到服务器资源的实时使用情 况

13.17    当测试接口时，发现接口返回数据与预期不一致，要怎么做

回答思路：返回数据与预期不一致基本都是接口代码问题

参考回答：测试接口如果发现返回数据与预期不一致时，首先检查传入的参数是否错误，如 果参数传入正常的情况下，接口返回数据与预期的不一致时，可以检查下数据库中数据，当 数据库中的数据也是正常的，则可以将接口返回数据异常的问题反馈给开发人员

13.18    你们之前的项目是用什么方式管理接口的

回答思路：可以使用接口管理工具比如简单云、Yapi 、swagger 、或者腾讯文档

参考回答：我们公司之前使用腾讯文档来管理接口，将接口的地址、请求方式、请求参数、 返回结果写到接口文档中，这种方式效率较低，所以引入了简单云作为接口管理平台，简单 云作为一个项目管理平台，可以管理项目中的接口

13.19    有没有做过接口自动化测试，怎么做的

回答思路：三个脚本+一个 excel 表

参考回答 1 ：1.首先封装发送 HTTP 请求的方法，例如：get/post 。2.封装读写 excel 数据的方 法。3.在 excel 中设计接口测试用例(请求地址、请求方式、请求参数、请求头、预期结果)。

4. 设计统一执行的脚本，可以循环执行 excel 中的每一行用例，并可以将结果写入到 excel 文件中。这是我设计框架的雏形，后面为了去处理一些接口的依赖关系，接口的数据问题， 还写了一些其他脚本。

参考回答 2 ：接口自动化测试，利用工具或代码在较短时间内执行更多的测试都可以称为自 动化测试。

将需要测试的接口添加到 postman 中，保存到同一个测试集合中，每个接口添加断言，使 用 runner 执行一个测试集，可以得到接口的测试情况

将需要测试的接口添加到 jmeter 中，保存到同一个线程组中，每个接口添加断言，批量执 行线程组下的每个接口，可以得到接口的测试情况。或者使用 ant 调用 jmeter 执行脚本，实 现接口的批量执行并生成测试报告

我叫×××，今年24岁，20年我毕业于山东科技大学，21年初在成都天佑创软科技公司担任测试这一岗位，主要做过功能测试、兼容测试，接口测试和简单的压力测试方面的工作。对数据库、linux、fiddler、postman，jmeter的使用都比较熟悉，了解HTML前端知识和python语言。最近做的这个项目是乐拍商城项目，在项目中负责测试用例的编写评审以及执行还有BUG的这个提交、管理。在平时工作中会积极和同事沟通完成工作。以上是我的自我介绍。

项目测试流程

首先是熟悉需求，之后我们组长会定计划、进行分工，我们就进一步的熟悉功能需求，然后设计用例，设计用例的时候使用等价类、边界值、判定表、业务场景提取测试点，依据测试点完成测试用例；

测试用例完成后一般都会有两轮的测试用例评审。第一轮评审完，修改完成之后，还再做第二轮评审。评审完成后就开始用例的执行工作，执行的时候先准备环境做基本功能的验证，然后正式执行，总共执行4轮，第一轮：负责自己模块的功能、界面相关测试；第二轮：负责自己模块的兼容性、易用性等方面测试；第三轮：做一下交叉互测；  第四轮；做整体的回归测试，随机测试等。

执行结束之后，我们组长会汇总相关用例，缺陷等数据，来编写测试报告。

讲下你的项目，怎么开展的，你负责哪块，用到什么测试方法，具体的业务流程讲讲

能简单讲下你负责的模块的测试用例吗

你怎么保证测试用例的覆盖率

这面我觉得我之前的项目组做的挺好的，首先，在项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，

小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；

用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。

接口测试做过吗，用什么工具，关联接口怎么做

讲下你常用的linux命令和mysql命令（左关联、右关联），什么时候会用到，列举一下？

例如：

 chmod 赋权限； rpm 安装； mkdir 创建目录， cd 进入目录；  ls查看目录下的东西； tar 打包 ， gzip 压缩命令；  pwd查看当前目录位置；  mv 移动； cp复制，  vi 编辑， cat查看文件内容；rm 删除目录文件， ps查看进程, ifconfig查看ip地址，配置ip地址 等等

查找一个日志的某个字段，怎么查

测试用例的元素，你写测试计划和测试报告吗，包含哪方面

印象最深的bug，开发人员不认为这个是bug你怎么做

遇到过这种情况，当时我们的处理的是这样的： 如果发现的bug开发不认，会先确认到底是不是bug，是bug的话，会跟开发进行沟通，说明bug的现象，以及判定是bug的依据原因是什么； 如果沟通之后开发还是不认，会直接将这个bug提交到缺陷管理系统上，同时告知自己的组长，让领导去协调。

性能测试做过吗，自动化那些的，python熟悉吗，到什么程度了

Fiddler抓包的原理，你怎么做的，具体看什么参数，除了抓包还能用来干嘛，postman也问

接口测试你怎么做的，怎么确定这个接口是通过的了，后面迭代版本的接口测试也要一个个来测试吗？只有前端做好了，后端还没做好，那怎么测数据？

如果登陆的时候有验证码，那你是怎么去做接口测试的？

怎么判断前后端bug

手机抓包怎么做的

ADB命令熟悉不

http和https的区别？web和APP的区别？session、cookie、token的区别？

手机端你主要测试哪方面

你们公司上线的一个标准，如果上线后出现bug了怎么办？

你了解过数据库吗，你工作需要对数据库效验接口内容吗，什么时候需要效验，怎么效验，利用python代码怎么效验

版本多久迭代一次，每次迭代测试用例都要跑一遍吗？

测试人员有多少，开发呢？

测试用例

1、编写测试用例的具体方法

等价类、边界值、场景法、因果图、正交表

2、现场设计测试用例的策略

3、测试用例的分类

4、测试用例的内容

用例编号、实现步骤、输入参数、预期结果

接口测试用例，用例编号，接口名称，URL地址，请求参数，请求头，预期结果，实际结果

5、编写测试用例需要哪些文档？

6、用什么方法覆盖所有的测试点和边界点？

7、一天写几个测试用例，执行多少天？

  

实际让你写测试用例

1、如果京东有一个购物网页，你要怎么进行测试，测试哪些主要功能？

2、网上银行转账是怎么测的，设计一下测试用例？

3、定期存款到期自动转存应该怎么测？

4、微信朋友圈点赞

5、微信红包怎么测

6、支付功能测试？

7、登陆页面的测试用例bug

1、你印象中最深的bug？

2、在你发现的bug中，最严重的的bug是什么？

3、当开发不认为你提的bug不是bug的时候，你是如何解决的？

4、对于遗漏的bug你们是怎么解决的？

5、你是如何对BUG进行跟踪管理的？

6、上线后发现了BUG应该怎么处理？

7、遇见了不可复现/随机BUG应该怎么处理？

8、你是怎么区别BUG的优先级和重要级的？

9、你们的项目BUG有多少？

10、bug管理工具，禅道？

11、bug的生命周期

测试环境

1、你们公司都有哪些测试环境？

2、你们公司怎么搭建测试环境的？

3、你们有几台服务器，怎么部署的？

4、测试用的是什么环境？

5、开发环境、测试环境、生产环境到底是什么？

6、tomcat的默认端口号是多少？你是如何解决端口号冲突的问题的？在那修改端口号？

7、nginx的作用有了解么？负载均衡了解么？

HTTP 协议相关的

1、什么是http协议？

2、http和https有什么不同？

3、https是什么原理呢？

4、get和post的区别？

接口测试

1、为什么要做接口测试？

2、接口测试你为什么要参数化？

3、常见的错误码和含义？

4、接口用例的设计？

接口测试-jmeter工具

1、接口测试用的是哪些工具？

2、你会用jmeter来录制吗？

3、jmeter能在linux中使用吗？

4、接口get方法怎么添加参数，get和post方法的区别？

5、用jmeter如何做关联接口？

6、对jmeter怎么做性能测试？

接口测试-postman工具

1、Postman的常用接口类型，有那四种？Get，post，put，delete 查询 创建 更新 删除

2、postman怎么上传文件、图片？：post-body-form-data——键值对输入file：选择文件类型，点击上传

3、postman怎么测接口，登录功能怎么测？（先创建集合collection（项目）--》创建文件夹（folder接口）--->创建请求（request，用例）-->填写接口地址，选择请求方式 ，填写输入参数，  -->添加断言Tests, 前置脚本  --->点击send  --->等待接受响应，查看测试结果

4、postman的基本用法？

抓包测试-fiddler抓包

1、抓包的流程？

2、熟悉哪个工具？详细讲讲？

3、APP是怎么抓包的？

4、fiddler有几种方法可以修改http请求或响应？

5、fiddler怎么捕获https？

2、APP和web的测试区别？

3、APP测试用到的工具？

4、APP的抓包详细过程，分安卓和苹果叙述？

5、说说弱网测试？兼容性测试？

6、讲讲monkey测试？

7、如何测试APP的稳定性？

人事相关问题

1、我的职业规划？：往自动化方面去学习和发展。比如可以先学习python，然后学习一个主流的自动化测试框架，有计划有步骤的提升自己技能。

2、你还有什么问题想问吗？无

3、为什么离职:上一家写的成都公司，希望回杭州发展，并且杭州软件行业发展比较好

4、你的期望薪资：8k,

5、对加班什么看法：首先不排斥加班，如果工作需要我肯定会加班，同时工作中我会提有效率的完成工作

第一次面试

2.开发认为不是bug你会怎么办？

首先需要把你觉得是bug的问题，让开发给你解释，记录下来，看看是不是这种方案也是可以的。不管是否可以，也要把开发给的问题内容整理下问业务，问业务看看这个问题是不是行的通的，如果业务认为可以，那就不是bug，如果业务说这个是有问题的，不行，那就让开发根据业务的方式改，把问业务的信息转发给开发。开发看了如果说改的话有点难，或者这样改是不合理的，让开发自己去问业务，开发和业务商量怎么处理。

3.linux常用的基本命令有哪些？

pwd  ls cd touch mkdir rm cp mv clear

4.你对学习能力是怎么 看待的？

评价一个人学习能力的高低，主要是看一个人会不会学，掌握到学习的方法没有。有些人天天抱着书啃，晚上躲在被窝里看书，并没有实质性的提高。有些人经常参加体育锻炼，社团活动，同学聚会，学习却一点没落下。这就是学习效率的问题，也是学习方法。主要心思放在学习上，掌握好学习的技巧，认真专研，就能事半功倍。(百度)

5.如果给付交付文档的那个人给了你文档，但是文档不清晰，你无从下手，但你又不能问交付给你文档的那个人，这时候你会怎么做？

主要考的是团队的力量问题，首先可以自己先找资料查阅看能不能解决或者能不能缩小难度的范围，然后也可以问与文档内容相关的公司人员解决。

6.说下你公司的测试流程？

一、 一般情况是项目开始阶段产品经理会写一个产品需求文档和以产品原型图， 然后会开一个需求评审会，讨论下需求的合理性，根据团队技术情况，对需 求中的缺点及风险进行评估（小公司可能直接产品经理出需求，然后评审会 也不开，低头就是干。）

二、 需求最终确定后，我们测试组会熟悉产品需求（熟读深刻认识产品），leader 根据项目排期写测试计划，同时leader会给我们3个人分出来所测试的测 试模块，然后我们写自己对应的模块的测试用例，写完了交给你同事或者 leader 给你评审下，看看有没有漏测的、不合理的情况，然后改下就好了 （咱们是在 excel里写，有的在缺陷管理工具或其他工具）。

三、 根据项目整体计划排期，我们写测试用例的时候开发也在开发软件，开发出 来的模块会进行提测。然后大家一起根据同事写的测试用例进行测试就行了。 （这里部分共可能在没有UI页面的时候需要测试进行接口测试，这个会稍 后点，因为会根据开发写的接口文档写测试用例进行测试，我们接口只测试 正向数据） 不断的测试提bug，回归测试经历很多轮的测后项目会从模块测试（单元测 试）进行到集成测试、系统测试阶段。

 四、 进入集成测试、系统测试阶段，项目模块与模块之前会进行关联组成一个完 整的系统。所有测试用例还是要重新在测试一遍（当然了，重点留意的地方 应该是在之前测试中发生过bug的功能）。开发改 bug，测试回归测试进行 N轮后。bug全部修改完毕了。

五、 进行到验收测试阶段，验收测试没问题了项目就可以上线了。 (尼古拉四面试题)

第二次面试

2.你的职业规划是？

想提高自己的技术能力，向往自动化发展，web自动化-->app自动化>性能相关的测试。让自己有能独立 主导一个项目测试的能力

3.验证码怎么处理返回给用户登录

验证码是不需要前端处理的，是后台编写程序，随机生成的，只需要在前台页面展示即可。(cookie或session)

4.adb命令

adb install安装 adb uninstall卸载  adb  devices查看用设备信息  adb start-server启动adb服务  adb kill-server关闭adb服务   adb push上传  adb pull下载  adb  logcat查看日志

5.为什么来深圳

因为深圳相对来说发展空间比较大，深圳国内IT行业发展是挺快的，所以我想来这里谋求发展，学习更多的新技术，能够带来自我的提升。

6.给你两个表，你怎么去建立连接查数据？

考的表连接查询需要的数据

7.linux命令复制文件到另外一个文件夹的命令

cp 要复制的文件 另外一个文件（目标文件）

8.你还有什么要问我的吗

技术面试：那你就问问项目组人员情况？项目目前处于什么阶段测试情况？都做哪 些方面的测试？

人事HR：问问五险一金的基数？公司加班多不多？上下班时间弹性么？多久涨薪 一次？

可以问“贵公司对新入公司的员工有没有什么培训项目，我可以参加吗？或者说贵公司的晋升机制是什么样的？”

9.fiddler如何定位前后端问题

前端BUG 界面相关 布局相关 兼容性相关

后端BUG 业务逻辑相关 性能相关 数据相关 安全性相关

（1）首先打开抓包工具，然后提交正常的表单，看是调用后台接口的时候传递的参数时候和之前填写的一致， 比如表单填的是数字，而接口需要传的是字符串，那么前台传的有问题，如果一致说明不是前台的问题，继续 往下查。 

（2）需要一方面继续看抓包的数据，接口返回的错误是什么，如果能明确看到错误原因的消息，也就定位到了 问题，如果不能看到则要继续连接测试服务器查看日志，看程序处理到哪一步有问题

（3）如果从程序的角度发现没有问题，那继续往下查，看是否连接的数据库不对，亦或是超过数据库字段限制 的长度等等。就这样追寻着程序执行的轨迹一步一步去排查，终基本都能定位到问题。

10.弱网测试怎么测的

弱网测试：就是测试app在网络状态非常差的情况下，app的运行 状态。

目的：就是为提高用户的体验。

弱网测试需要助于抓包工具：fiddler、Charles

前提条件：app手机的网络与安装了fiddler电脑的网络要在同一个 局域网。

打开fiddler，然后进行相关的设置。

需要确认fiddler所使用的代理端口（默认为8888）,如果该 默认端口被占用，那么需要去修改默认的端口。

需要确认启动fiddler电脑的IP地址。（在dos下输入ipconfig 进行查看）

在fiddler当中，选择“rules”菜单下的“Customize rules”，会 打开一个java的代码窗口

在打开的窗口中，按ctrl+f搜索300，回车就可以看到以下的代码信息。

如果要做弱网测试，建议这两个值给2500和1500左右。

修改对应的值之后，按ctrl+s保存代码文件。

再在“rules”菜单中选择“perfomance”--“simulate modem speeds”.

设置运行app的手机代理

点击“设置”选择“WLAN”

在WLAN的窗口当中长按 已连接的WIFI名称，选择“修改网络”

在弹出的修改网络窗口当中，将代理设置选 择 “手动”

在代理服务器主机名中输入fiddler电脑的IP地址

在代理服务器端口号 中输入fiddler的代理端口

点击“保存”  

打开被测试的app，然后在弱网环境下进行相关的业务功能测试。

11.git代码版本管理工具怎么使用jenkins集成

以接口为例

0.导出Postman脚本、环境变量、全局变量等到指定的文件夹

1.在公司远端的代码管理平台新建一个仓库，复制仓库链接，进到指定的文件夹，右击打开git bash here，克隆远端仓库下来 git  clone  url

2.查看版本库状态： git status

3.将修改提交至暂存区: git add 文件名

4.将修改提交至Git库: git  commit -m "提示消息"

5.拉取远程仓库: git pull

6.推送远程仓库: git push

7创建Jenkins任务并进行设置

8. 查看Jenkins持续集成效果

12.teardown的作用是什么？比如登录进去，teardown是哪一个操作

程序结束的时候自动调用，销毁动作  退出浏览器的作用

13.adb查看日志的命令

adb logcat

14.你的代码，和远端仓库的代码不一样，你会怎么操作

在push代码之前，先从服务器pull最新的项目代码后，在push本地解决冲突后的代码到服务器

15.人员配比

测开比例1比4，3个测试12个开发，前端5个后端7个

16.python框架是自己建的还是用的之前的，jenkins是经常用吗？

不是,我是调用以前同事的，我要用就直接创建一个job持续集成就行，接口是可选步骤。

17.用什么方法把2到2000中2字开头的数字获取到？代码题

18.怎么解决手机号重复注册的问题

1.通过一个函数来生成唯一的手机号码       会导致数据库存在更 多的脏数据

2.可以通过备份和还原数据库的方式来保证脚本可重复执行。    如果数据库当中的数据过多的情况，会导致还原数据库时间比 较长。

3.可以直接在数据库当中清除注册的用户信息。     需要对数 据库的业务非常熟悉，必须知道添加的用户信息分别增加到哪 个表里面

第三次面试

1.用例八要素是那些？

用例级别，用例编号，用例标题，功能模块，测试输入，执行步骤，预置条件，预期结果

2.web.app.微信小程序之间的区别

app和小程序的区别

app要经过应用商店下载，而小程序直接微信扫码或搜索就可获得，

app需要安装在手机上，有图标，而小程序用完即走，没有新的图标。

app会占用大量的内存，而微信本来有严格的小程序内存管理体制，所以小程序不用什么内存，

app会有给用户推送消息，造成用户困扰，而小程序不允许有推送消息，只能回复模板信息，

app开发成本比小程序高，周期长

app的发布上线时间比小程序长

app面向所有智能手机用户，而小程序面向所有微信用户，

app可以实现完整的功能而小程序仅限于微信释放的新能力和接口功能。

app需要用户主动下载注册，推广难度大，而小程序只需要扫二维码或搜索多个入口，推广成本低

app有专项测试，小程序没有。

app用的python加selenium做的ui自动化测试，而小程序用的postman工具和微信开发者工具做的接口测试

app和web的区别

app属于cs架构，必须要有客户端，web属于bs架构，基于浏览器。

app前后端交互的数据格式以json为主，web前后端交互的数据以html为主

web的兼容主要是火狐谷歌ie浏览器，app有专门的专项测试。（兼容性，安装升级卸载等）

app一般使用appium做自动化测试，而web使用selenium做自动化测试

app一般用jmeter做性能测试，web一般用LR，jmeter做性能测试。

3.你觉得你做测试的优势在哪？

学习能力，细心，耐心，沉着冷静、条理清楚、立场坚定、顽强向上、乐于助人和关心他人、适应能力和幽默感、乐观和友爱。

4.你觉得你做web测试解决问题最难忘的时候是怎样的情景

问题1：在浏览器上点击下载 一直没反应；

解决：点击浏览器上面的网站组织弹出框 打开弹出框 允许，下面这个是火狐浏览器，每个浏览器位置不一样 但是方式一样的

问题2：web系统 点击登录 一直没反应

方案：1，点击浏览器右上角 设置按钮，点击”兼容性视图设置  2，出现如下图，把网站 添加 ，重新打开ie 登录页面试试  

5.怎么想到转行来做测试呢，怎么会离职，原因是什么？

转行原因：毕业实习的时候我的本专业不是很好找工作，加上我也不是很想从事我这个专业的 工作，然后家里有个哥哥是做软件的，公司正好招聘测试工程师，然后就介绍我我过去了，我想着有人带就失足进入了IT行业。一呆就是三年了。

离职原因：之前公司比较小，不太利于自己的技术成长，想来深圳提高下自己的技术，因为深圳的it发展比较快，发展空间比较大。

6.你有什么要问我的吗？

技术面试：那你就问问项目组人员情况？项目目前处于什么阶段测试情况？都做哪 些方面的测试？

人事HR：问问五险一金的基数？公司加班多不多？上下班时间弹性么？多久涨薪 一次？

可以问“贵公司对新入公司的员工有没有什么培训项目，我可以参加吗？或者说贵公司的晋升机制是什么样的？”

7.你一开始工作最近的一个项目是？是不是培训岀来的？

菜大王商城，是一个微信小程序。  没培训过，简历照网上做了参考

8.python中你用到的第三方工具有哪些？

selenium appium requests unittest pytest pymysql allure urllib3

9.python熟悉吗？性能的压测和负载测？

熟悉

负载测试：确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系 统各项性能指标的变化情况。

 压力测试：通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的 最大服务级别的测试。

10.接口测试用到的工具有？

postman工具，如果是测试微信小程序，会用到微信开发者工具。

11.你觉得测试用例怎么样才是好的测试用例？

别人能够看得懂，能够指导测试的执行，用例完全覆盖测试点的用例才是好的测试用例。

12.你平时的测试流程是怎样的(从开始到上线，要说与会人员)？

--系统分配任务，从系统上下载需求文档，开发需求需求说明书，自己阅读文档，熟悉业务流程，自己先使用开发的功能流程，向开发，业务了解不清楚的需求内容点，开始测试，测出问题后记录bug和让开发修改，最后总结测试过程，写测试文档，上传测试文档，业务人员重测使用功能，业务人员感觉有问题了会重新让开发修改，测试再跟测，一直到业务认为功能没问题了，在系统上验收结果通过，发送给产品经理审批，产品经理审批通过后再给上一级经理审批签字，通过后则可以上线。

13.你是怎样测web的，要说一下从兼容这块，质量模型来说，我说了定位元素这些，其实不是，应该说从哪方面考虑测来说

1.  功能测试

2.  性能测试（包括负载/压力测试）

3.  用户界面测试

4.  兼容性测试

5.  安全测试

6.  接口测试

1.  功能测试

7，链接测试

14.你认为怎么样的bug情况才能说上线？

--不管什么bug，级别很轻，不严重不影响上线的，都要经过业务或者是产品经理的确认，让业务和产品经理商量是否保留bug，他们说不影响，那就可以上线。

15.你们接口是怎样判断才知道没问题的？

主要看请求和响应，查看返回状态码：如：200 请求成功，500表示内部错误  502 网关错误  404 页面或者地址不存在 ，304 缓存问题

如果发送的数据是正确的，但是后台反馈的数据是不符合需求的，那就是后台的问题；

如果前端没有请求接口，或者请求的时候发送数据与需求不符，那这个时候就是前端的问题了。

如果发送的数据是正确的，后台反馈的数据正确，前端提示错误，也是前端的问题。

16.测试的分类有哪些

1、按测试阶段划分：单元测试、集成测试、系统测试、验收测试

2、是否覆盖源代码：黑盒测试、白盒测试、灰盒测试

3、是否自动化：人工测试、自动化测试

4、是否运行：静态测试、动态测试

5、其他：回归测试、冒烟测试、随机测试

17.问了响应状态码有哪些？

1XX：请求需要继续处理

2XX：成功，200/201/204等

3XX：重定向，301/302等

4XX：客户端存在问题，404/401/403等

5XX：服务器存在问题，500/502等

如：200 请求成功，500表示内部错误  502 网关错误    504代表服务器端超时，没返回结果 404 页面或者地址不存在   401代表访问的页面没有授权，403表示没有权限访问这个页面  304 缓存问题

第四次面试

1.小程序和app的区别

app和小程序的区别

app要经过应用商店下载，而小程序直接微信扫码或搜索就可获得，

app需要安装在手机上，有图标，而小程序用完即走，没有新的图标。

app会占用大量的内存，而微信本来有严格的小程序内存管理体制，所以小程序不用什么内存，

app会有给用户推送消息，造成用户困扰，而小程序不允许有推送消息，只能回复模板信息，

app开发成本比小程序高，周期长

app的发布上线时间比小程序长

app面向所有智能手机用户，而小程序面向所有微信用户，

app可以实现完整的功能而小程序仅限于微信释放的新能力和接口功能。

app需要用户主动下载注册，推广难度大，而小程序只需要扫二维码或搜索多个入口，推广成本低

app有专项测试，小程序没有。

app用的python加selenium做的ui自动化测试，而小程序用的postman工具和微信开发者工具做的接口测试

2.微信红包测试点

功能

1.在红包钱数，和红包个数的输入框中只能输入数字

2.红包里最多和最少可以输入的钱数 200 0.01

3.拼手气红包最多可以发多少个红包 100

3.1超过最大拼手气红包的个数是否有提醒

4.当红包钱数超过最大范围是不是有对应的提示

5.当发送的红包个数超过最大范围是不是有提示

6.当余额不足时，红包发送失败

7.在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，

7.1是否可以输入它们的混合搭配

8.输入红包钱数是不是只能输入数字

9.红包描述里许多能有多少个字符 10个

10.红包描述，金额，红包个数框里是否支持复制粘贴操作

12.红包描述里的表情可以删除

13.发送的红包别人是否可以领取

13.1发的红包自己可不可以领取 2人

14. 24小时内没有领取的红包是否可以退回到原来的账户

14.1 超过24小时没有领取的红包，是否还可以领取

15.用户是否可以多次抢一个红包

16.发红包的人是否还可以抢红包 多人

17.红包的金额里的小数位数是否有限制

18.可以按返回键，取消发红包

19. 断网时，无法抢红包

20.可不可以自己选择支付方式

21.余额不足时，会不会自动匹配支付方式

22.在发红包界面能否看到以前的收发红包的记录

23.红包记录里的信息与实际收发红包记录是否匹配

24.支付时可以密码支付也可以指纹支付

25.如果直接输入小数点，那么小数点之前应该有个0

26.支付成功后，退回聊天界面

27.发红包金额和收到的红包金额应该匹配

28.是否可以连续多次发红包

29.输入钱数为0，"塞钱进红包"置灰

性能

1.弱网时抢红包，发红包时间

2.不同网速时抢红包，发红包的时间

3.发红包和收红包成功后的跳转时间

4.收发红包的耗电量

5.退款到账的时间

兼容

1.苹果，安卓是否都可以发送红包

2.电脑端可以抢微信红包

界面

1.发红包界面没有错别字

2.抢完红包界面没有错别字

3.发红包和收红包界面排版合理，

4.发红包和收到红包界面颜色搭配合理

安全

1.对方微信号异地登录，是否会有提醒 2人

2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加

3.发送红包失败，余额和银行卡里的钱数不会少

4.红包发送成功，是否会收到微信支付的通知

易用性(有点重复)

1.红包描述，可以通过语音输入

2.可以指纹支付也可以密码支付

。。。。。

3.adb启动手机如何启动的？

adb start-server启动adb服务

4.一年就做一个岀行项目？

是的，项目一直在迭代。大胆回答，不要怂

5.app测试了多久？迭代了多少个版本？

测试了差不多3个月 迭代了8个版本

6.appium测试app框架？

base # 封装PO基类

├── page # 封装PO页面对象

├── script # 定义测试用例脚本

├── data # 存放测试数据

├── report # 存放生成的测试报告

├── log # 存放日志文件

├── screenshot # 存放截图

├── config.py # 定义项目的配置信息

├── utils.py # 定义工具类

└── pytest.ini # pytest配置文件

7.app做性能测试不同机型是指哪些？

不同的品牌手机  比如华为，小米，vivo，oppo这些等

8.GT做性能测试关注的点有哪些？怎么测的，指标是多少？

主要关注的点有cpu，内存

启动GT工具，在AUT界面选择被测的app

在aut界面勾选CPU指标选项

切换参数页面勾选对应的CPU参数

在参数页面点击 启动 按钮

切换到日志界面，开启 logcat

返回到aut界面，点击 running或者启动，启动被测的app

对app进行相关的业务操作

返回到GT工具当中，查看CPU性能数据。同时可以获取对应的数据到本地。

cpu的指标不能超过75%-85%

内存的指标是不能超过70%

9.安装卸载升级是怎样去测的？

安装测试关注点:

正常场景:

1、在不同的操作系统版本上进行安装

2、从不同的安装渠道进行安装

3、在不同的品牌手机上安装

4、不同的安装路径（安装到手机还是安装到sd卡）

异常场景:

5、安装时出现异常，恢复后能否继续安装

6、安装时存储空间不足

7、安装时取消安装，再次安装能否成功

8、覆盖安装app能否成功（app运行或者不运行）

9、低版本覆盖高版本安装

10、卸载后进行安装

卸载测试的关注点：

正常卸载：（手工卸载、工具卸载）

异常：  运行时卸载、取消卸载、卸载时关机、卸载后数据是否 留存

升级测试关注点：

正常情况：从低版本升级到最新的高版本、从不同的渠道来进 行升级

异常情况:  进行跨版本升级、强制升级、提示升级

第五次面试

1.你的测试流程是怎样的？

--系统分配任务，从系统上下载需求文档，开发需求需求说明书，自己阅读文档，熟悉业务流程，自己先使用开发的功能流程，向开发，业务了解不清楚的需求内容点，开始测试，测出问题后记录bug和让开发修改，最后总结测试过程，写测试文档，上传测试文档，业务人员重测使用功能，业务人员感觉有问题了会重新让开发修改，测试再跟测，一直到业务认为功能没问题了，在系统上验收结果通过，发送给产品经理审批，产品经理审批通过后再给上一级经理审批签字，通过后则可以上线。

2.给你一个杯子你要如果测试？

功能度：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

3.接口测试的框架是怎样的？

data                  -- 管理测试数据的文件夹

report               -- 管理测试结果报告的文件夹

api                     -- 封装被测试系统的接口

scripts               -- 测试用例脚本

lib                       -- 第三方工具包管理

app.py               -- 配置信息文件

run_suite.py     -- 测试用例执行入口

utils.py              -- 自定义工具类

4.app做得多还是web做得多？

web

5.介绍下你熟悉的web项目流程？

把后台web项目介绍一遍

6.你有没有做过自动化？如何做？然后就是问项目里的东西

有做过，从功能测试用例里挑选合适的正向的业务流做自动化

1.需求分析

2.挑选合适的功能开展自动化

3.设计测试用例

4.搭建自动化测试环境

5.设计自动化测试项目框架

6.编写用例代码

7.执行用例脚本

8.生成测试报告分析结果

第六次面试

2.支付怎么写测试用例

支付的余额小于待支付的钱

调起支付输入密码框后，不进行输入密码，是否会生成订单

调起支付输入密码框后，输入错误密码，是否会生成订单，是否会重试

点击立即付款，通过fiddler抓包工具，把金额改成1元，看是否能够支付成功

微信/支付宝进行支付时，在未安装微信/支付宝的情况下，能否进行支付？

重复支付，是否会出现问题

连续快速点立付款，是否会出现多次扣款的情况，一般只扣一次

多设备同时登陆，同时付款，是否会出现问题

点击立即付款，然后退出app，看能否会生成待付款订单

点击立即付款，然后中断网络，流程中断，随即联网，看是否会刷新页面

点击立即付款，输入密码的时候，中断网络，是否会生成支付成功的订单

点击立即付款，输入密码的时候，中断网络，随即联网，看是否会刷新页面

弱网的环境下，造成请求超时，查看支付情况

弱网的环境下，付款成功后，返回app过程中造成网络超时，查看支付情况

支付成功/失败后，返回app，页面刷新是否正常

多设备同时登陆时，一个设备支付成功，另一个设备的刷新情况

3.库存是哪里设置的？库存与购物车怎么交互？

后台

生成订单时锁定库存应该是要好于购物车锁定库存，加入购物车没有产生实际的购买行行为；

加入购物车，验证一下库存是否超过；

预下单时，验证一下库存是否超过；

创建订单时，验证一下库存是否超过；同时扣减库存！如果库存不足，提醒用户，或者无法进行结算！

超过一定时间未支付，取消订单，并恢复库存！如果已支付，就不在返回库存！

拍下减库存的，未付款订单交易关闭后，商品库存即刻恢复;付款后减库存的，付款后退款导致的订单关闭，库存不会自动恢复。

生成订单时锁定库存应该是要好于购物车锁定库存，加入购物车没有产生实际的购买行行为，对于库存量较少或者购买量比较大的商品，如果只是假如购物车就减少库存，会影响其他用户的购买体验。至于是下单后锁库存还是付款后锁库存，提供可选择的方式比较好，这样可以根据商品的实际库存量以及实际情况来进行调节

4.介绍一下微信小程序和后台管理系统的项目

5.物流是怎么设置的？项目中你是怎么支付的？

后台设置的 通过公司充钱进测试账号然后一分钱支付

6.你还有什么要问我的吗？

7.你的学历是全日制的吗？你学的专业是什么呢？

8.如果用户这边看商品是1元，加入购物车是2元，支付是3元，你要怎么处理？

程序是否出现问题了，商品属性，支付数量，邮费方面来考虑

9.如果是降价了，客户买了和加入购物车两种情况，你会怎么处理？

客户购买就要确定用户的购买时间 没问题就退差价

加入购物车还没有买的情况下，那购物车就要有降价的提示，显示的金额是降价的金额

10.自动化你懂吗？懂

第七次面试

2.python的调试方法

一，断点打印

二，断言assert

三，logging日志输出文件

四，调试器pdb pdb.set_trace()

五，IDE调试

3.unittest的原理

首先是要写好TestCase

然后由TestLoader加载TestCase到TestSuite

然后由TextTestRunner来运行TestSuite，运行的结果保存在TextTestResult中

整个过程集成在unittest.main模块中。

4.小程序的订单和物流

物流在后台设置，订单单接口参数化

5.小程序和app的区别

app要经过应用商店下载，而小程序直接微信扫码或搜索就可获得，app需要安装在手机上，有图标，而小程序用完即走，没有新的图标。app会占用大量的内存，而微信本来有严格的小程序内存管理体制，所以小程序不用什么内存，app会有给用户推送消息，造成用户困扰，而小程序不允许有推送消息，只能回复模板信息，app开发成本比小程序高，周期长，app的发布上线时间比小程序长，app面向所有智能手机用户，而小程序面向所有微信用户，app可以实现完整的功能而小程序仅限于微信释放的新能力和接口功能。app需要用户主动下载注册，推广难度大，而小程序只需要扫二维码或搜索多个入口，推广成本低，app有专项测试，小程序没有。app用的python加selenium做的ui自动化测试，而小程序用的postman工具和微信开发者工具做的接口测试

6.app不要写gt，但可以不写gt，比如安卓用哪个？苹果用哪个？

安卓：procrank工具

苹果：instrument工具

7.测试流程

--系统分配任务，从系统上下载需求文档，开发需求需求说明书，自己阅读文档，熟悉业务流程，自己先使用开发的功能流程，向开发，业务了解不清楚的需求内容点，开始测试，测出问题后记录bug和让开发修改，最后总结测试过程，写测试文档，上传测试文档，业务人员重测使用功能，业务人员感觉有问题了会重新让开发修改，测试再跟测，一直到业务认为功能没问题了，在系统上验收结果通过，发送给产品经理审批，产品经理审批通过后再给上一级经理审批签字，通过后则可以上线。8.接口测试框架？

data                  -- 管理测试数据的文件夹

report               -- 管理测试结果报告的文件夹

api                     -- 封装被测试系统的接口

scripts               -- 测试用例脚本

lib                       -- 第三方工具包管理

app.py               -- 配置信息文件

run_suite.py     -- 测试用例执行入口

utils.py              -- 自定义工具类

9.接口依赖是怎样解决的？比如？

postman工具做的接口测试，把他放到环境变量中，需要用的时候直接调用就行

比如小程序的员工管理添加员工的前提条件是要登录成功，登录时会产生一个token值，添加员工会产生一个员工id，查询员工需要添加员工的员工id以及登陆时候的token值，修改员工信息，删除员工信息也是一样依赖这两个值才能成功

10.你有什么要问我的不？可以问面试相关的，但不要问人员配比了

11.介绍下你的项目。项目你不要只熟悉小程序，其他的也要熟悉。项目不熟。app专项这方面多熟悉。

12.cpu的标准是多少才正常？你怎么测的cpu，什么工具？具体怎么测？

75%-85%之间  用的GT工具测试的   

启动GT工具，在AUT界面选择被测的app

在aut界面勾选CPU指标选项

切换参数页面勾选对应的CPU参数

在参数页面点击 启动 按钮

切换到日志界面，开启 logcat

返回到aut界面，点击 running或者启动，启动被测的app

对app进行相关的业务操作

返回到GT工具当中，查看CPU性能数据。同时可以获取对应的数据到本地。

13.工作中你遇到过哪些困难呢

之前有过一个情况，项目急着上线，但是项目还没有测完，人手又不够，向项目经理这边申请外援人手过来，当时外援没有，就有想叫项目团队其他人来帮忙测了，开发，产品这些。当时他们的事也挺多的，最后是自己加班完成的测试，时间挺紧急的，但自己能加班完成，也是满满的欣慰感

时间上不允许进行全部测试的时候，很多时候会减短测试时间，那么我们应该对测试任务按照优先级来划分，重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作，其目的就是尽最大努力来提高质量。因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。 只有积极的面对问题，才能更好的解决问题。

1.提测质量差

问题描述：第一个提测版本差，有些均未通过冒烟测试

问题分析

A.版本提测质量差，但基于发布时间已在，因此。在提测差时就开始测试提测质量差的点：基于每项功能的完成度都不高-有些功能均未实现

B.新的团队，团队处于磨合期

C.在提测时，对提测要求不明确，在时间点到后，匆忙提测

解决方式：

明确版本提测要求，并且开发得到了足够的时间。

3.功能反复

问题描述：在上一个版本是OK的功能，在新版本中功能失常

功能反复分两点：一是大功能反复，二是小功能（如：某个bug）反复

问题分析：

大功能反复：情况主要发生项目前期和中期

A.功能为完成，在完善功能时，未考虑与该功能相关的点

B.在提测之后，发现一些问题，导致了整个模块重构，重构后导致了问题的反复

小功能反复：这个情况主要发生在项目中后期

A.因为项目里的部分开发是外援的，在项目中期时，撤出了团队，新接手的人员，对代码不熟悉，在修改代码bug 时，经常出来顾此失彼

B.开发小一在修改代码时，动到了小二的代码，导致了小二出了问题

解决方式：

对大功能反复，是这么处理：冒烟测试由开发来完成，冒烟测试通过后，再交由测试

对小功能反复，没有有效的处理方式，测试这边可以做的是，加强测试，这个问题，在发布前夕好了很多，但问题任然存在

14.哪个情况下要版本兼容呢

有新的版本要迭代的时候

15.bug报告中包含的哪些内容？

所属模块  优先级 严重程度 bug的类型 bug的状态 缺陷标题 预置条件 重现步骤 期望结果 实际结果

第八次面试

1.说下最近一个公司做项目的情况

2.学历问题问了下？如实回答了

3.什么原因转行？

转行原因：毕业实习的时候我的本专业不是很好找工作，加上我也不是很想从事我这个专业的 工作，然后家里有个哥哥是做软件的，公司正好招聘测试工程师，然后就介绍我我过去了，我想着有人带就失足进入了IT行业。一呆就是三年了。

4.在测试过程中业务最复杂的逻辑点是什么？业务过程中反复反复测还是测不到它的点上的逻辑点？

订单系统，订单设计到很多的数据，比如金额，订单时效，商品数据，订单状态，优惠券。业务逻辑复杂

5.web端的项目介绍？项目中那个业务是最复杂的？主要想知道你对业务的熟悉程度。比如下单比较复杂，为什么？理由。

订单系统，订单设计到很多的数据，比如金额，订单时效，商品数据，订单状态，优惠券。业务逻辑复杂

6.商城有商家入驻的情况，比如萝卜是A商户的，青菜是B商户的跨商户买菜的情况是要怎么处理？有多少商户采购？回答100多个

 拆单（用户来说是一笔订单只想付一个邮费，平台来说就是两个包裹两次邮费，退款的时候单方面只想退一个）自营不存在这种情况

7.app是自用的，反馈的线上bug比较多的是什么？(收到线上反馈的异常主要来源于哪一方面？)

我之前遇到过有闪退 还有数据不停步  排行榜有人刷榜

第一二个问题要说先自己排查 然后找开发跟产品重新发版本

排行榜的这个要找后台的人看  这个关乎到数据库的了

7.1有没有遇到线上反馈然后又特别难搞的客户，是怎么处理这个用户的问题的？

叫开发解决这个问题，解决完之后，自己验证一下没有这个问题之后，单独给这个用户更新，只更新这个用户的。

8.公司人员配比？我回答3个测试，10个开发

9.app是否有做自动化测试？我回答正向的就做自动化测试。

10.你会python吗？我回答会

11.对于python，在做哪方面的深入学习？我回答在网上看视频学习

12.用git提交代码的吗？我回答是的,出行的路线那里用git提交代码。Jenkins持续集成

13.mysql熟悉吗？我回答主要查询

14.在测试过程中都会去看后台数据吗？我回答会去看

15.你还有什么要向我了解的吗？

第九次面试

2.你的专业是什么？为什么选择做软件测试？（转行原因）

3.编程语言掌握哪些？数据库用过哪些？数据库有写过存储过程吗？

python  主要查询  没有

4.离职原因是什么？

5.测试案例设计方法有哪些？

等价类，边界值，判定表，场景法，流程图，因果图，错误推断法。

6.接口测试和功能测试的侧重点是哪些？

接口测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

功能测试的重点在于检验软件产品说明书上面的功能是否实现、是否达到规格说明书的要求

7.你的优点是什么？你的缺点是什么？......

8.问题和风险是怎么区分？

风险就是可能不能如期交付，是一种预测的，问题是已经产生存在的

9.你在项目中有遇到过什么风险吗？

一些你认为可能影响用户体验的问题，或者一样随机闪退的问题没有解决，但是双方协议下来，因为发版本的时间比较紧急。只能延后到下一个版本来改，那么这个就是风险

技术风险（安全）  找外包或者人培训

人力风险：请假      提前培养新人

10.测试计划主要包括哪些？

明确的测试目标与测试范围

执行计划的角色与职责

任务的进度安排与资源分配

风险估计与应急计划

测试的准入准出标准

11.测试过程中有发生过哪些经典的缺陷吗？

测试app过程中，快速进入退出商品详情页，页面崩溃

首页轮播图点击图片进去，图片不显示

进入app，第一次退出app，会闪退，再进入再退出，能正常退出。

12.你对软件测试这个岗位怎么看？

测试是一个软件不可或缺的一部分，没有经过测试的软件是一个无法保证产品质量 的产品。

认知：通过手工操作或工具使用对项目开发过程的产品（编码、文档等）进行差错 审查验证，保证其质量的一种过程。

行业发展：个人认为软件测试逐渐正规化，不是随便找个人点点就完事的时代了， 更加规范化，同时在技术上也更加专业化，比如要求会编程语言做自动化测试，未来自 动化测试会是一个大趋势。

13.你的职业规划是什么？.......

14.你有什么问题想向我了解的？.......

第十次面试

1.自我介绍

2.项目介绍，接口框架  .......

3.创建订单的一个参数思路  .....

4.功能测试和接口测试怎么做的？  流程

5.微信小程序登陆这块详细地描述一下怎么设计测试用例，不会结合一些网络情况去设计测试用例吗？正常和异常，单接口和多接口

6.什么情况用postman和什么时候用python+requests？

一开始我们公司是用postman工具做的接口测试

后来单接口的时候会用postman工具，因为工具比较简单快速

多业务需要多接口依赖的时候就会用python+requests自动化，因为代码比工具灵活

7.功能测试和接口测试的顺序流程怎么样的？流程

8.什么时候用的接口自动化？项目人员有多少人？多接口（比如整个正向的业务流程）

9.测试怎么分工的？有没有主动承担过分配任务的工作不？

3个测试12个开发  5个前端7个后端   之前工作没有

12.环境部署或优化的点主动帮你测试经理承担的或者测试流程优化的？

13.职业规划？

14.之前有尝试过主导一个项目的动作吗？ 有  公司查阅资料 或者网上查找资料

15.一个项目交给你，你会从哪个角度去设计它的测试方案？

16.测试方案的内容？

测试策略

测试环境的规划

测试工具的设计和选择

17.你还有什么要问我的吗？   ......

18.接口结果的正确性你如何去校验，只看响应不看数据库吗？都要看

19.怎么解决接口之间的依赖？

环境变量

20.接口测试用例是根据什么来设计的？用什么来编写测试用例？

api文档  excel表

第十一次面试（现场面试）

1.思维导图(流程图)提测试点

2.接口测试框架是自己搭建的吗？不是的   调用之前老员工的

3.说下最近的项目的业务流程？其他的分支？测试时候遇到的印象比较深刻的问题？（经典缺陷）

4.你的优点是什么？.......

5.为什么转行？.......

6.你还有什么要问的吗？........

第十二次面试（电话面试）

1.自我介绍

2.介绍下就近的一个项目？

3.什么原因转行？

4.你测试所用到的工具有哪些？

Postman,fiddler,微信开发者工具,python等等

5.你如何使用fiddler协助开发定位bug的问题？

这种情况很容易判断，先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对

请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题咯

6.接口测试返回看什么确定成功？响应是否和api文档一样

7.工作中提的bug多吗？分模块看情况

8.测试方法有哪些？如何尽可能的覆盖需求？

9.一个链接点金去领红包的测试点有哪些？

10.编程语言熟悉吗？自动化做的什么测试？项目中有写过ui自动化不？怎么做的？框架是自己搭的吗？

11.接口测试是怎么做的？举例子说明下？

12.一个bug提交要注意的点是哪个？bug单的内容？

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

14.测试更偏向哪种测试？

15.你的职业规划？

16.你能接受加班吗？

17.你还有什么要问的吗？

第十三次面试

1.自我介绍

2.商城主要的功能是什么？

3.小程序都有哪些测试点？

4.小程序测试和pc端测试有什么区别？

5.购物车的测试点有哪些？

6.接口测试你是怎么做的？

7.登录接口怎么设置接口测试用例？

8.小程序测试和app测试有什么区别？

9.Jenkins持续集成怎么做？

10.项目上线的标准是怎么样的？

11.Linux用得多吗？一般用来做什么的？查看日志的命令是什么？

12.文件传输的命令是什么？scp

13.对什么编程语言比较熟悉？python用得多吗？用python做过什么？做的什么自动化？自动化做了多少的测试用例？

14.你还有什么问题要问的吗？

第十四次面试

1.最近一个项目的介绍（微信小程序）

2.购物车的测试点

3.腾讯视频下载播放的测试点（下载分正常和异常）

4.小程序需要测一下他的商品类型吗？

5.公司做自动化吗？有要求吗？怎么做的？app的

6.自动化其他框架的优缺点？有遇到什么问题吗？

7.还有什么要问的吗？

第十五次面试

1.自动化真正使用使用了多久？

2.你最熟悉的一个项目是什么？画下业务主流程图？

3.你加入购物车提交订单进行支付成功预期结果要检查哪些东西确保这笔交易这功能是ok的？

自己做的就看数据库和UI支付是否一样，日志上有支付成功提醒，然后去数据库核对金额和信息，看后台库存是否减少，看订单状态，订单信息有交易快照，订单编号，下单时间，付款时间，商品数量，属性，总金额，左上方应该有买家已付款标语，优惠券，返点

4.你还有什么要了解的吗？

第十六次面试

对薪资的要求大概如何？你还有什么要问我的吗？第十七次面试

打开一个网站，页面提示http的404的错误，作为测试点，如何复现解决问题？

一、需求分析

1.需求文档有/无：

1)有需求文档：根据需求文档直接提取测试点，重点关注输入数据的约束、数据的流向等

2)没有需求文档：根据系统现有的功能进行提取测试点，重点关注数据的约束、数据的流向等。

2.需求分析怎么做（*****重点*****）

由产品经理召开需求澄清会议，对本次发布的功能需求进行讲解，测试人员利用思维导图工具对需求点进行细化和分解，

为编写测试用例提供准备。

"""

功能需求文档：包含每个版本要实现的功能、流程图、原型图、页面的交互、功能的约束等等

接口需求文档：包含接口对应的功能、接口的地址、请求方式、请求参数、参数的约束、返回的报文、错误码解释、接口和接口有依赖的说明等等

性能需求文档：性能测试点、并发用户数、绝对并发用户数、通过指标：cpu 内存 IO 平均事务响应时间、事务通过率、90%事务响应时间、吞吐量TPS 等等;

"""

#########################测试计划#########################

二、测试计划

1.编写者：有经验的测试工程师(测试组长或者测试经理、协助组长收集数据整理、自己也可以独立编写)

2.测试计划内容：目的（对项目做出评估）、测试背景、范围、测试策略、软硬件环境、开始和结束条件、进度安排、测试风险

#########################测试用例#########################

三、测试用例设计

1.谁写的：测试工程师

2.测试用例设计方法：等价类（一分钟验证码）、边界值（输入年龄18-60岁范围）、错误推测法

(多个人同时修改同一条数据、空数据验证、SIM卡无效、时间控件：活动开始时间 小于 活动结束时间)、判定表（组合查询）、场景法（业务流程）

3.测试用例的构成：用例编码、用例标题、优先级、预置条件、操作步骤、预期结果、实际结果

4.用例的执行状态：未执行、通过、失败、阻碍、观察中

5.用例的颗粒度：颗粒度大，用例总数少，颗粒度小，用例总数多

6.如何写好用例/评审用例从哪些地方考虑/怎么从用例的角度覆盖需求（*****重点*****）

参考答案：

一般来说，有以下几点，比如：

1)覆盖用户需求（要满足用户需求、比如开发功能符合用户的预期）

2)从正常和异常的用户使用场景来设计用例(举例：登陆功能)

3)用例的颗粒度大小尽量均匀（不能全部写的太细  或者 太粗 ）

4)测试用例的要素要齐全，优先级安排合理（主要功能、次要功能）

5)容易被其他测试人员友好的执行（通过标题就知道用例干嘛）

7.测试人员写用例需要多久/一个版本写多少/团队输出用例的总数（*****重点*****）

#########################案例分析#########################

web项目测试周期：按照一个月来算，3~4周，大约22个工作日

1天  ---  需求分析

1天  ---  测试计划

5  6  7天  ---  测试用例

14 13 12天 ---  测试执行

1天  ---        测试报告

测试人员平均每天大概：50-60条

测试团队输出用例总数：3-4人    （3*50*7 ~ 4*60*7（1000或者1500条左右）

你一个版本写多少用例：1*7*50 = （400条左右）app项目测试周期：比如: 1~2周  按照2周算，10个工作日

1天     ---   需求分析

1天     ---   测试计划

2 3天   ---   测试用例

5 4天   ---   测试执行     

1天     ---   测试报告

测试人员平均每天大概：50-60条

测试团队输出用例总数：3-4人    （3*50*2 ~ 4*60*2 （300~500条左右））

你一个版本写多少用例：1*2*50 = （100~200条左右）#########################测试执行#########################

三、测试用例执行

1.测试用例谁执行

参考答案：一般都是由我们测试工程师来执行3.Bug状态有哪些（*****重点*****）

参考答案：一般我们发现bug首先要到禅道上提交，此时的状态是新建（new），

开发过一段时间打开bug这个时间状态就打开（open），开发人员确定一下是不是bug，如果是就进行修复(fixed)

如果不是，就拒绝修复。当开发修复完成，我们会重新打开这个bug，这个时候状态叫（reopen），让回归测试验证

通过以后，我们就关闭（closed）。4.Bug构成或者Bug要素有哪些（*****重点*****）

参考答案：一般来说，bug的构成主要包括以下内容：

Bug标题、严重级别、影响版本、所属模块、复现步骤、预期结果、实际结果、相关日志、截图、抓包 5.你们项目上提交Bug管理工具用的是什么？

参考答案：我们之前项目上用的最多的就是: 禅道

当然，同类型的管理工具，我也有了解过，比如： Jira、TD 、Bugfree、Tower、Bugzllia等6.Bug生命周期(你发现bug以后一般如何进行缺陷跟踪？) （*****重点*****）

参考答案：当发现缺陷后，我们要在禅道上提交问题单给开发并每隔一段时间

(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，

如果没及时处理，就要提示开发，让开发及时修复问题；

问题修复后，要及时进行回归测试，如果回归通过，就关闭缺陷，如果不通过，就返回给开发继续修改。7.开发不改Bug如果解决（当我们认为某个地方是bug，但开发认为不是bug，怎么处理）（*****重点*****）

参考答案：在之前的项目中，一般我们先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；

有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。

如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，

测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。8.在项目中，遇到偶然性Bug一般如何处理（*****重点*****）

参考答案：一般来说，在之前的项目中，我们通常的手段是：

1)在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保存证据；

2)确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位；

3)如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低；

提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；

4)如果这些不可复现的Bug是很严重的Bug;

比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，

最后还要写到测试报告中，说明出现了什么现象，但无法再现.9.产品上线，被用户发现Bug如何处理或者漏测怎么处理（*****重点*****）

参考答案：这个情况，我们之前处理的比较好，我们测试人员首先：

1)测试人员在测试环境，复现问题后，提交问题单进行跟踪；

2)评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；

3)问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；

4)总结经验，分析问题发生的原因，避免下次出现同样问题。10.Bug等级如何划分（*****重点*****）

参考答案：一般分为四种吧，致命的，严重的，一般的，轻微的，那么：

致命一般包括：系统崩溃、导致程序重启,死机或非法退出、数据丢失或异常等；

严重一般包括：阻碍系统流程、金额计算错误等；

一般一般包括：删除提示、刷新没反应等；

轻微一般包括：界面错别字、按钮颜色、界面布局等；11.一天找多少Bug/你一个版本找多少Bug/团队一个版本找多少Bug（*****重点*****）

参考答案：这个不一定。要看需求实现难易程度，数量多少、开发编码质量(技术水平)、设计测试用例质量。

就拿我上一个项目，一天大概能找10-20条；一个版本大概能找100条；

如果问到团队一个版本可以找到多少个BUG？

如果要说的，大概100左右、 150左右、200左右都可以说。

12.(预测试) 冒烟测试怎么做

参考答案：针对每个版本或每次需求变更后，在正式测试前，对产品或系统的一次简单的验证性测试。

一般测试的是主流程的验证，比如针对一个电商系统，那么注册-登录-下单-支付测试流程一定是必须通过的。13.之前公司有多少人/研发部门开发多少/测试多少/组织架构（*****重点*****）

参考答案：

公司规模：40人左右

研发部门(开发&测试&产品)：    

Java后端开发人员：20个左右(写后台业务逻辑、开发接口)      

（html+css+js)前端开发人员(写前端界面)：1个人     

测试人员：3个人

产品部：产品经理 1人

其他(boss、hr、财务、销售等等)： 10多个######################### 项目篇 #########################

1、你在项目中负责什么(意思就是，你在项目中参与了哪些事情，你的工作职责)（*****重点*****）

参考答案：在工作中我主要负责功能测试，接口自动化测试，还会参与性能测试等。

在项目中主要参与了需求分析和需求评审，负责收集项目资料协助上级完成测试计划的编写、

编写测试用例并评审，测试环境的搭建以及测试执行和编写测试报告等工作。2、怎么保证覆盖用户需求（*****重点*****）

参考回答：这面我觉得我之前的项目组做的挺好的，首先，在项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，

小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；

用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。3、一般测试过程中出现问题，你是怎么定位的（*****重点*****）

参考答案：一般在测试过程中遇到问题，我首先先会：

1)检查测试环境配置是否有问题

端口占用、防火墙没有关闭、开发没有在后台加路由等 http://192.168.0.151:83/ecshop/user.php

测试数据是否有问题（不要使用旧数据测试）

2)用Fiddler抓包，分析请求和响应数据是否存在问题

3)查看应用服务器的日志 （tail -f  catalina.out）  

4)然后再查看数据库的数据是否存在问题

（比如在前端界面，新增了一条订单，那么数据库订单表orders表应该也有数据并且数据库数据正确性和前端界面数据保持一致）4、测试结束的标准是什么（*****重点*****）

参考答案：一般会参考用例执行率100%，缺陷遗留率小于10%，需求覆盖率100%这几个维度去参考。5、你会编写测试计划吗？

参考答案：我们之前的测试计划都是测试组长写的，我们只是负责收集数据，协助组长完成测试计划的编写，

测试计划的内容还是知道的，有测试范围、测试方式/策略、测试资源、测试开始和结束条件、

进度安排、测试组织等，如果以后有机会让我来编写测试计划，我觉得我没问题。-----(回答的时候，要自信。)

6、那你负责的项目中带过几个测试

参考答案：之前的项目上，加上我，就三个吧。

7、你们是怎么分配工作的（*****重点*****）

参考答案：我们都参加需求评审，会后我会把模块中功能的部分分给其他两个，他们对接口测试不是很懂，这个部分我负责，

当然他们功能测试中遇到问题都会来问我，我也会及时解决。我有些不懂的也会问开发和测试经理。

有问题就立即提出，尽量快速解决。工作之外我也会和组员交流经验，也给他们讲一些接口的知识。8、印象最深的bug有哪些（*****重点*****）

参考答案：比如：之前的项目一，我们当时是申请退费100，但是实际退费了双倍，退费金额就直接被改了。

但是仍然是一次请求。原因：客户申请退费的时候，系统弹出确认退费对话框的同时，前端把退费金额发给了后台的一个变量，

用户点击取消按钮，变量的值没有清空；用户再次退费的时候，就退了双倍。9、测试一般做几轮

参考答案：一般是三轮，先做冒烟测试，冒烟测试通过之后，进行SIT（集成）测试，然后做UAT（用户验收）测试。10、工作中遇到过什么困难，是怎么解决的（*****重点*****）

参考答案：太大的困难倒没有，不过在上个项目我遇到过一个比较紧急的问题，当时我们的测试环境有问题，

在界面上构造不了数据，导致测试堵塞了，项目赶着上线，领导一直在催，为了解决这个问题，当时我找到开发和运维的同事，

让他们帮忙从生产环境上把数据导到测试环境上来测试，因为要协调其他部门的同事，所以印象比较深。

关于项目是否上线，也可以这样回答：

面试官：项目是有在上线做运营了是吧？

参考答案：嗯，是的，上家公司是接项目做的，会交付给客户自己去运营的。

面试官：项目线上现在是可以访问得到的

参考答案：是可以访问到的。

11、你们的项目做了多久/一直在做/你负责哪些模块

参考答案：这个项目到现在还一直在做，已经做了1年多了。

前期需求比较多，迭代的版本多一些，到后期项目基本稳定了，需求变化不大；

我们会被调去做其他项目，这个项目后期如果需求发生变化，我们还是要负责测试。

所以，在上家公司基本每个人都会跟着几个项目。

提示：回答负责哪些模块的时候，一定要说到8个模块以上，比如，前台的xxx模块，后台的xxx模块。

一定不能只说 注册

一定不能只说 注册

一定不能只说 注册

如果是App的项目，就回答：App这个项目，所有模块都是我负责的，我们是按机型分工的，负责安卓机型的测试，

有华为，vivo，oppo，小米这些机型(负责的机型，可以灵活修改)。12、那你们用例执行后bug占整体的百分比（比例）

参考答案：这个具体没有算过，一般是10~20%左右14、问题：当用户需求变更时，你会怎么做？（*****重点*****）

参考答案：

这个会经常遇到的，一般如果是小的需求变更，合理的话，能改的，经理会让开发直接改，然后测试再测一下就好了；

如果是涉及到比较大的改动的话，我们会开会讨论一下会影响到的模块，经理会计算一下修改的成本，一般会建议放到下一个版本再修改；

如果必须要改的话，开发就会改的，测试也 会重新修改一下测试用例，把可能会影响到的模块再测一遍。15、面试官：支付功能怎么测试(+++++特别重要++++++)（*****重点*****）

参考答案：

1）从功能方面考虑

a.正常完成支付的流程；

b.支付中断后继续支付的流程；

c.支付中断后结束支付的流程；

d.单订单支付的流程；

e.多订单合并支付的流程；

f.余额不足；金额的最小值 ：如0.01；金额为0；金额为负数

g.未绑定银行卡；

h.密码错误；

i.密码错误次数过多；

j.找人代付；

k.弱网状态下，连续点击支付功能功能，会不会支付多次；

l.有优惠券、折扣、促销价进行结算是否正确；

m.不同终端上支付：包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；

n.不同的支付方式：银行卡网银支付、支付宝支付、微信支付等；

o.支付失败后，再次支付。

2）从性能方面考虑

a.多个用户并发支付能否成功；

b.支付的响应时间；

3）从安全性方面考虑

a.使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号(下两个订单A,B，付款时拦截订单B，并把订单B的订单号改为A订单的订单号)无法完成支付；

4）从用户体验方面考虑

 a.是否支持快捷键功能；

 b.点击付款按钮，是否有提示；

 c.取消付款，是否有提示；

 d.UI界面是否整洁；

 e.输入框是否对齐，大小是否适中等。

5）兼容性

BS架构:不同浏览器测试。

APP:不同类型，不同分辨率，不同操作系统的手机上测试  

15、购物车怎么测试(+++++特别重要++++++)（*****重点*****）

参考答案：我以购物车为例，说一下我测试的关注点。

1）功能测试

a）未登录时

1.将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加。

b）登录后

1.所有链接是否跳转正确；

2.商品是否可以成功加入购物车；

3.购物车商品总数是否有限制；

4.商品总数统计是否正确；

5.全选功能是否可用；

6.删除功能是否可用；

7.价格总计是否正确；

8.商品文字太长时是否显示完整；

9.购物车中下架的商品是否有标识，是否还能支付；

10.新加入购物车商品排序（添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品）；

11.商品删除后商品总数是否减少；

12.收藏功能是否可用；

13.购物车结算功能是否可用；

14.同时在不同终端进入购物车后，进行下单付款，检查会不会重复付款。

2）兼容性测试

      BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。

      APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等

3）用户体验测试

1.是否支持快TAB、ENTER等快捷键；

2.删除商品是否有提示；

3.是否支持快捷键功能；

4.是否有回到顶部的功能；

5.商品过多时结算按钮是否可以浮动显示；

6.购物车有多个商品时，能不能只对单个商品结算；

7.界面布局、排版是否合理；

8.文字是否显示清晰；

9.不同卖家的商品是否区分明显。

  

4）性能测试

1.打开购物车页面要多长时间（一般响应时间符合3、5、10原则）16、登陆功能怎么测试(+++++特别重要++++++)（*****重点*****）

参考答案：

1）功能方面的测试：

1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录，能否能跳转到正确的页面

2.输入错误的用户名, 验证登录失败，并且提示相应的错误信息

3.输入错误的密码, 验证登录失败，并且提示相应的错误信息

4.用户名为空, 验证登录失败，并且提示相应的错误信息

5.密码为空, 验证登录失败，并且提示相应的错误信息

6.用户名和密码都为空，点击登陆

7.用户名和密码前后有空格的处理

2）性能方面的测试:

1.打开登录页面，需要多长时间

2.输入正确的用户名和密码后，登录成功跳转到新页面，需要多长时间

3）安全性方面的测试:

1.密码是否在前端加密，在网络传输的过程中是否加密

2.错误登陆的次数限制（防止暴力破解）

3.是否支持多用户在同一机器上登录

4.一个用户在不同终端上登陆

5.用户异地登陆

    

4）用户体验测试：

1.页面布局是否合理，输入框和按钮是否对齐

2.输入框的大小和按钮的长度，高度是否合理

3.是否可以全用键盘操作，是否有快捷键

4.输入用户名，密码后按回车，是否可以登陆

5.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用

    

5）兼容性测试

    BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。

    APP架构：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等18、你们项目是怎么分工（*****重点*****）

参考答案：

如果你回答的是App的项目

就说：我们这个App是按机型分工的，负责安卓机型的测试，有华为，vivo，oppo，小米这些机型(负责的机型，可以灵活修改)；

如果你回答的是WEB端的项目

就说：我们这个项目是按模块分工，我负责前台的xxx模块，后台的xxx模块(至少说5个模块以上)19、你之前公司的项目是什么类型的？（*****重点*****）（你们之前公司最好做什么类型项目的？）

参考答案：我们公司属于项目外包类型的，公司接到什么项目就做什么项目。20、验收测试(UAT测试)怎么做

参考答案：

在UAT测试之前，我们会制定测试方案，选择基线用例，即级别高的用例，在UAT测试环境上进行测试；

如果测试通过，验收测试就通过了。21、如果一个项目给你负责，你会怎么做（*****重点*****）

参考答案：我简历上的APP这个项目，就是我独立负责的，我当时是这样做的：

需求分析：

首先，要去熟悉这个项目的需求，业务流程，将测试功能点列出来，把不明白的地方提取出来，和开发、产品经理确认清楚;

测试计划：然后根据项目的迭代周期确定一个测试计划

测试用例：接下来开始编写测试用例并叫上开发、产品经理进行评审；

接口测试：在项目开发阶段，开发人员把接口代码编写完成后，我会对接口进行测试，保证底层接口的质量；

开发转测：等所有代码都编写好了，开发转测后，进行冒烟测试，冒烟测试通过了，

功能测试：接下来进行系统的功能，安全，兼容性，性能等类型的测试，发现bug就提交bug单给开发人员修改，跟踪并做好回归测试；

验证测试：这些测试完成后，挑选一些级别高的测试用例，在UAT环境上进行验收测试，验收测试通过后，编写测试报告，项目就可以上线了。

上线后的总结：项目上线后，可能还会出现一些遗留的问题，所以还要分析研究怎样做才能避免这类bug的遗漏。#################发散性问题#################

1、如果项目很赶，经理安排一个项目要三周内完成，你知道你完成不了，你怎么办（*****重点*****）

参考答案：

一般我会先和经理说明，时间太短，存在风险；

然后，将任务划分优先级，先完成优先级高的任务 ，保证项目的主要功能没问题；

然后，时间允许的话，再做优先级稍微低的；

在这个时间段内，每天向 上级报告工作的进度，让领导知道现在的工作进展和存在的风险。2、你xxx这个项目，最近更新的需求是什么（*****重点*****）

参考答案：最近项目更新的需求，就是对购物车页面的UI设计的重构、代码的重构，我们一般主要测试功能和接口;

比如：购物车我们会从功能：xxx，  性能：xxx, 用户体验：xxx, 兼容性：xxx3、业务流程梳理（*****重点*****）

正常场景：

仅退款的退货单：

1).待收货状态的订单提交退货申请，生成退货单，退货单状态为：待审核

2).待审核的退货单审核通过后，退货单状态为：待收货

3).后台确认收货，退货单状态为：待退款

4).后台确认退款，退货单状态为：退款完成

退货退款的退货单：

1).待收货状态的订单提交退货申请，生成退货单，退货单状态为：待审核

2).待审核的退货单审核通过后，退货单状态为：待用户发货

3).待用户发货的退货单前台操作发货后，退货单状态为：待收货

4).后台确认收货，退货单状态为：待退款

5).后台确认退款，退货单状态为：退款完成，订单状态为:已取消

异常流程：

1).待审核的退货单审核驳回后，退货单状态为：拒绝退货

2).待审核的退货单前台取消，退货单状态为：取消

3).待审核的退货单两天内未处理，退货单状态为：待用户发货

4).待用户发货的退货单前台取消，退货单状态为：取消

5).待用户发货的退货单三天内未发货，退货单状态为：取消

6).待收货的退货单后台七天内未确认收货，退货单状态为：待退款

7).待退款的退货单后台三天内未确认退款，自动退款，退货单状态为：完成

8).已换货的订单申请退货，生成退货单成功

订单状态变更：

正常场景：l

1).选择商品创建订单，订单状态更改为：待付款状态

2).待付款订单进行支付，订单状态更改为：待发货状态

3).后台选择待发货状态的订单填写快递公司、快递单号进行发货，订单状态更改为：待收货状态

4).前台点击确认收货，订单状态更改为：待评价状态

5).前台提交评价，订单状态更改为：已完成状态

异常场景：

1).待支付的订单超过三天未支付，订单状态更改为：已取消状态

2).待支付状态的订单后台操作取消订单，订单状态更改为：已取消状态

3).待支付状态的订单前台修改订单信息，修改成功

4).待发货状态的订单后台操作取消订单，订单状态更改为：已取消状态

5).待发货状态的订单前台修改订单信息，修改成功

6).待收货状态的订单操作退还货，生成退还货单

7).待收货状态的订单超过15天未确认收货，订单状态更改为：待评价状态

8).待评价的订单超过七天未评价，默认好评，订单状态更改为：已完成状态

9).待评价状态的订单操作退还货，生成退还货单

10).已完成状态的订单操作退还货，生成退还货单测试报告的内容

0.报告名称

1.测试结论：测试通过/不通过

2.送测情况说明

   正常/延期x天

  送测延期天数：x天

  计划送测次数：1次

  实际送测次数：x次

3.测试进度说明

   是否正常，延期了情况说明

4.测试执行情况说明

    测试（冒烟测试、系统测试、子系统测试、组件测试）计划执行用例数，实际执行用例数，成功用例数，失败用例数，阻塞用例数。

    本次测试回归缺陷情况：关闭x个，重打开x个

5.送测版本质量情况

    版本新发现的缺陷总数

    版本重打开缺陷总数

    遗留缺陷总数

    按严重程度分布：严重、一般、轻微、建议

    按功能组分布：

    按引入方式分布：系统遗留、项目引入

6.风险和问题

   测试版本存在的问题导致测试不能执行、测试版本的质量问题等等

7.测试内容：

   测试范围

   测试内容及执行情况

    功能

    优先级

    变更类

    测试通过情况

    测试人员

    备注

   

二、介绍一下测试方法

按阶段： 单元测试、集成测试、系统测试、验收测试

按手段： 黑盒测试、白盒测试、灰盒测试

其他： 冒烟测试、回归测试

四、印象深刻的一个bug？

隐藏得比较深的bug、影响比较大的bug、处理过程比较曲折的bug。

如何发现的、如何处理、影响、结果、反思。

举例说明：

升级版本兼容性问题、

接口安全性问题、

数据库安全性问题、

服务器资源占用溢出问题、

代码逻辑问题等

七、你们原来项目的测试流程是怎么样的？

我们的测试流程主要有三个阶段：需求了解分析，测试准备和测试执行

1需求了解分析阶段

我们的SE会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求澄清会议，我们会把不明白不理解的需求在会议上说出来，包含需求的合理性、还有需求的可测性等，产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致；

２测试准备阶段

会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块，然后我们就根据自己负责的模块用xmind（思维导图）进行测试需求分析，分析测试点，以及编写测试用例。之后我们会在自己的组内先进行评审，评审修改之后还会在我们的项目组评审。评审完后进行修改测试用例；

３测试执行阶段

开发人员编写好代码之后，我们会把代码包部署到测试环境中进行SIT测试，在正式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测。在执行测试的过程中，我们如果重现有bug就会用禅道记录并且提交bug，也会进行回归测试，一直到没有重现bug达到上线为止，每一轮测试结束之后我们都会写一个测试报告。一般情况下，测试2-3轮之后会达到上线要求。上线前我们会做UAT测试，当达到上线的标准后，测试报告会认为测试通过，由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告，总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进。产品迭代几次后，我们会跑自动化用例来测试所有的功能模块;

八、你介绍下，你最熟悉的项目？

根据自己项目来

九、你们原来项目的主要的功能模块有哪些，你主要负责哪些模块？

根据自己实际项目说

十、产品是怎么上线的？

一般我们会选择晚上上线，开发测试还有客户产品全部到场，进行上线测试。

1）首先，开发将代码打包到生产环境的服务器中，把代码包替换到服务器的目录中。如果数据表有变化，开发就会运行sql脚本，创建表，修改表的操作；

2）接着，我们测试就开始先测试主体业务功能以及新增的功能模块；测试通过之后，我们会在界面上把上线测试的数据删除，在规定的日期正常上线。

3）如果发现bug，开发人员当场修复bug，修复成功之后我们测试再复测，通过就可以正常上线。

4）如果发现了bug开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性，如果严重就延期上线，或者迭代到下一个版本中。如果我们是迭代版本的话我们还需要版本回滚。如果不严重，产品跟客户觉得可以上线，就正常上线。

十一、你提交的bug，开发不认可怎么办？

首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug；

如果是bug再去让身边的同看看听下他们的意见，然后自己先再三确去复测，并且保存好截图和日志，确定这是一个bug之后我就去跟开发说明白，并且给他看bug重现的截图以及日志。

如果开发还是不认可的话我就跟产品或项目经理说明白情况，

十二、对于无法重现bug，应该怎么处理？

首先，我会多测几次，测了好多次都无法重现的话我就先把bug挂起。并且留意一下，看看往后的测试中会不会重现类似代码的bug，因为有些是偶现bug。如果在后面的测试中重现bug就激活。如果经过几个版本都还没发现的话就关闭bug

十三、 原来项目有遇到哪些经典的bug，你是怎么发现的，最后怎么解决的？

1、经典bug：1.在理财中心的赚取小金库中，投资人投资收益为负数

发现途径：我是在模拟投资人，输入投资金额的时候，显示出来的收益为负数

解决：首先我去数据库查找到对应的表，比对结果跟界面显示的数据是否一样，一样我就把数据库的记录和界面显示截图都保存好。之后提交这个bug，开发人员通过修改代码，我再复测，没有重现bug

2、还有一个就是在借款流程中，我们通过修改数据库中的数据，把借款时间修改了，制造出一个逾期未还款的数据，结果显示还款的金额比借款金额还少，而且管理费收得特别高，存在不合理性。

3、还有一个是在产品上线后，运维人员在统计数据时发现少了一条数据，我们去数据库检查发现0分0秒的数据没有统计，后来开发人员修改了代码之后就解决了

十四、linux你是怎么用的？

（1）在测试执行的过程中，我们发现的bug，有时候需要定位bug，协助开发修复bug时

tail -200 或tail -500查看当天的日志的后面多少行或者前面多少行定位bug，

tail -f来查看日志里的关键字exception(异常)、error(错误)或用重定向（ls -la > ls.txt）把信息保存起来再用vi命令进入信息里然后打开搜索命令shift + ：/进入文件定位模式搜索error,fatal（致命）,或者exception等

（2）后台程序运行久了会对系统造成卡顿等诸多隐患或我们做性能测试的时候。

Ps -ef(显示所有进程)

top(监控程序执行状况)

free -m(显示内存使用情况)来查看系统资源

如果服务器出现故障时我们也会用(service httpd status)看下服务器是否启动

ps -ef|grep httpd查看apache进程是否启动

ps -ef | grep java查看jdk进程是否启动。

如果服务器起不来，常见的问题有端口可能被占用，用netstat -an | grep 8080 查看端口是否已被占用。

（3）搭建测试环境的时候我们在是在linux下进行的

搭建LAMP时在线用命令yum install安装apache，php以及mysql；

或通过xshell来导入需要的环境包来搭建LTMJ（Tomcat、Mysql、jdk）

十五、数据库原来工作当中是怎么用的？

原来我们数据库用的比较多的，就是数据结果检查，测试一些数据准备，性能测试造大量数据

(1)测试执行到的结果，我们需要通过sql语句select来查找数据库对应的表，看看数据库信息跟我们执行的结果是否一致；

比如：生成申请订单后，我们会去数据库里面去检查下，数据库中数据是否跟申请订单数据一致。

(2)我们在测试执行时需要做一些测试数据准备，我们就用insert into输入数据或（者 update set 修改数据），我们需要到数据库查看有没有相关记录保存，保存的数据跟我们输入或者修改的记录是否一致；

比如：原来我们一个初审功能里面有个分页功能，测试分页功能，需要100条数据，我们就通过数据库操作添加100，可以用insert into。

(3)还有在做性能测试时，模拟用户场景时需要用到大量的数据，这时就需要我们到数据库中制造大量的数据出来。

比如说，测试充值，需要大量用户数据，充值表中大量数据，比如10W条数据，我们就用存储过程去造。

delimiter //

create procedure 存储过程名(n int)

BEGIN

declare  i int default 0;

while i <= n do

Insert into 表名 values(值1，值2,.......);

set i=i+1;

end while;

end //

delimiter ;

call 存储过程名(数据量（n）);

十六、你想问什么问题？

1，公司现在做什么项目

2，公司目前做哪方面测试

3，公司这边测试人员分配比例

4，进入公司，我这边大概的工作安排

5，公司这么后续发现机会还有培养

十七、自我介绍（参考）

从业时间 、教育背景、工作经验 、项目经验 、擅长技能、你的性格，尽量与个人简历相一致

你好，我叫XX，来自XXXX，在XXX学院计算机专业毕业，从毕业至今在XXX公司从事软件测试工作1年半。

我们做的项目主要是XXX，是一个XXX的系统平台，涉及模块主要是XXX。项目中我负责过web及app功能测试、接口测试、压力稳定性测试。（跟简历项目一致）、能独立搭建测试环境。

熟悉测试工具jmeter、soapui、loadrunner Fiddler Appium Monkey Postman…等的使用。

也有过开发的经验，擅长shell、python编程语言（有该项经验就补充）

我是一个耐心认真的人，有很大的信心做好测试的工作（可说可不说，影响不大）。

十八、说一下你项目的测试流程？

首先会召开需求分析会议，参加人员有产品、开发和测试，主要是探讨需求主要的一些功能点。

完了之后，开发就排期进行开发，主管开始编写测试计划，对我们进行任务分配。

我们参考需求规格说明书及原型图编写测试用例，写完之后会进行用例评审，有评审修改的就修改整理形成最终的用例版本，之后开发人员版本编译完成后，我们会先进行预测，主要对主功能业务进行测试。

如果主业务流程不通过，直接返回给开发进行修改。预测通过，依据测试用例进行系统测试，测试过程中，提交bug，跟踪bug，进行回归测试直至不存在严重bug，满足用户需求，测试完后编写测试报告，发布上线后，关注web是否正常运行。

十九、介绍下你最近做的一个项目？

项目陈述可以先整体后局部，整体可量化（项目规模、时间成本、人力成本），然后测试环境（知道的就说）、然后是角色职责。

这个XXX项目，是一个XXX的系统平台，主要业务范围是XXX。项目模块主要是XXX。项目从今年3月份（时间按简历时间更改）开始进入立项、设计开发，到6月底（时间按简历时间更改）完成测试发布上线。

我们测试这边是3个人负责这个项目，需求评审完成后老大给我们测试任务，编写测试用例。我主要负责哪些模块（按你具体的情况说明）。

第一轮测试用了一周的时间执行完，整个项目测试了将近1个多月，总共测试了4轮，前1轮发现了将近100个左右的bug.（项目上线前遗留了几个Bug是什么程度的，最后是怎么处理的（这句有准备就说））

二十、对于复现率不高的bug怎么处理？

先在出现问题的环境上尽量重现，保持浏览器环境、出现问题的特定账号等的一致，多次尝试仍然不能重现，也要记录到bug平台。

将出现问题的特征步骤尽量描述清楚，附带问题截图及日志截图，注明偶现；如果项目时间允许，bug等级高，需要开发协助重现；如果时间不允许，记录到bug平台后续再跟进。

二十一、您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？

我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。

最擅长的是功能测试、接口

• 学到：

• 1.测试技能的提升2.沟通表达能力，及时汇报工作中的进度3.提高解决问题的能力，遇到难点的解决方法。3-5规划：在软件测试测试行业3年的时间、然后包括技术还需要提升和沉淀包括自动化性能和测开这个方面、另外一个方面也希望自己做一个有责任心的人敢于去承担然后往管理方向也做一些尝试、对于未来3-5年的规划我自己就是这些、当然了我目前觉得假如进新的公司还是要从贵公司的业务开始做起、因为业务是一个项目最根本都东西、只有在完全了解了公司业务的情况下才能深入其他的。

• 自我介绍：

• 我叫***，今年岁，20年毕业于******，上家公司是在##公司从事软件测试工作，主要负责的是观影类的项目。在工作中会从业务功能/UI/性能功耗/稳定性/安全/兼容/这些方面进行测试，进行接口测试，python自动化脚本编写及适配。熟悉数据库、linux，在工作中会使用postmanJmeter做接口相关测试，进行返回值的校验和性能测试，使用fiddler进行抓包及弱网测试，使用pytest测试框架进行自动化脚本编写及适配。之前做过商城项目，是乐拍购物商城项目，乐拍项目主要分前台和后台，前台面向用户，用户可以注册登录，搜索商品，加购后下单支付，支付成功后可以进行订单查看及物流查询。我负责的主要是前台的模块，后台模块是面向商家，商家可以进行店铺及订单管理。在项目中在工作中比较认真负责，对问题会积极去沟通，工作中会提高效率完成工作，以上是我的自我介绍。

• 测试流程：

• 首先是熟悉需求文档，产品会和测试、开发进行需求评审，之后我们组长会定计划、进行分工，我们就进一步的熟悉功能需求，提炼功能点，然后设计用例，设计用例的时候使用等价类、边界值、判定表、业务场景提取功能点，依据功能点编写测试用例；测试用例完成后对测试用例评审。开发转测后开始执行测试用例，过程中会提交bug跟踪问题进行回归测试，测试完成后编写测试报告。

• 测试计划、报告

• 乐拍商城是一个B/S架构的电商分销管理系统，分为前台后台模块，负责的模块是前台的首页门户，商品搜索，注册登录，购物车，支付，评论，帮助中心等模块。前台模块有店铺首页，购物车，会员中心等，后台模块有店铺管理、订单管理、发货管理等。用户可以在前台注册成为会员，然后登录系统，搜索商品，将商品加入购物车之后进行结算下单，或者直接进行结算下单，下单后在用户的我的订单能看到该订单信息，订单状态为待发货状态，卖家就可以进行发货，买家收到产品后进行确认，评论
• 要问：人员架构，团队规模怎么样，再结合公司找一个问题。
• 测试工作中遇到最困难的事？太大的困难倒没有，不过在上个项目我遇到过一个比较紧急的问题，当时我们的测试环境有问题，在界面上构造不了数据，导致测试堵塞了，项目赶着上线，领导一直在催，为了解决这个问题，当时我找到开发和运维的同事，让他们帮忙从生产环境上把数据导到测试环境上来测试，因为要协调其他部门的同事，所以印象比较深。
  • 8要素：用例级别，用例编号，用例标题，功能模块，测试输入，执行步骤，预置条件，预期结果
  • 测试用例方法：等价类。边界值。业务场景法，等价类是有效等价和无效等价，选取代表性的数据
  • 测试用例覆盖：1.开始测试之前可以先分析业务场景，这样能够让自己更好的理解产品需求。2.写完用例后可以邀请产品经理和相关开发进行用例评审，他们可以站在各自的角度去发现用例中设计不足的地方，来提升用例的覆盖率。3.可以记录之前版本或项目出现过的漏测问题，在后续中减少漏测，提升用例覆盖率
  • 没有需求文档：1、尽量去找找其他相关文档。比如开发的一些设计文档（概要设计、功能设计、详细设计等等）；2、尽可能多的参加内部讨论会议，进一步理解需求；3、如果项目是基于旧版开发的，多去使用旧版，自己摸索需求，也可以看看历史bug库、测试用例；4、参考同行或竞争对手的类似产品，从中理解项目需求；5、最后，根据上面了解到的，梳理需求点，然后和测试小伙伴碰一下，进一步查缺补漏，更正某些错误的需求；6、接下来就是根据自己整理的已确定的需求，整理出一份评审过的测试需求点，最后进行测试用例设计。
  • bug不认：开发不认可，首先自己先同环境复现一下bug，然后步骤截图，日志截图，然后再提再跟开发沟通，看他不认同的点在哪里。确定异议点查看需求文档，如果需求文档理解不一样找产品确认，解决问题。
  • 印象最深的bug：我们的项目涉及到支付模块，我当时是申请退费100，但是实际退费了双倍，退费金额就直接被改了。但是仍然是一次请求。原因：客户申请退费的时候，系统弹出确认退费对话框的同时，前端把退费金额发给了后台的一个变量，用户点击取消按钮，变量的值没有清空；用户再次退费的时候，就退了双倍。
  • linux：查看文件cat、more、less、head、mkdir创建目录，cd进入目录；ls查看目录下的东西；tar打包，gzip压缩命令；free-m查看内存，pwd查看当前目录位置；mv移动；cp复制，vi编辑，cat查看文件内容；rm删除目录文件，ps查看进程,ifconfig查看ip地址，配置ip地址等等，lsof -i:端口号 查看某一端口的占用情况，netstat -tunlp |grep端口号，用于查看指定的端口号的进程情况
  • Adb：adb devices查看设备，adb install.uninstall安装卸载应用，adb pull，push下载上传adb logcat 抓取日志adb shell monkey 100稳定性测试手机上随机点100

  • 测试环境：

  • 运维人员会给我们部署文档，文档中有步骤和注意事项：安装软件，如tomcat、jdk、mysql等；上传项目包，如war包，放到tomcat的webapps目录下，解压war包的命令：unzip xxx.war；修改配置，根据文档中说明修改tomcat、数据库等配置信息，项目的配置文件一般在项目名/WEB-INF/classes/这个目录下；启动数据库，一般开发会给出初始化sql脚本；重启tomcat服务。查询相应的进程：ps-ef| grep tomcat7杀掉进程：kill 进程编号，重启tomcat：执行tomcat/bin下的./shutup.sh停止，再输入./startup.sh重新启动。能搭建的出来。
  • 之前做的项目开发团队规模，迭代周期web项目测试周期：测试团队输出用例总数：4人 （3*50*7 ~ 4*60*7（1000或者1500条左右）。按照一个月来算，3~4周， 1天---需求分析 1天  ---  测试计划 5  6  7天  ---  测试用例 14 13 12天 ---  测试执行 1天  ---  测试报告测试人员平均每天大概：50-60条
  • 测试用例大概会写多少条，测多长时间：你一个版本写多少用例：1*7*50 = （400条左右）
  • 前端还是后端bug：使用抓包工具，查看接口返回数据，1.如果接口返回数据错误或与数据库不一致，那可以确认是后台bug。2.接口返回数据正确，但页面中的数据与接口返回数据不一致时，那可以确认是前端bug
  • 使用fiddler过滤：可以使用过滤设置只查看某个 host 地址的请求，比如设 置 www.baidu.com,为过滤条件，这样可以只查看百度网站的请求
  • 具体的状态码：2xx成功：3xx重定向4xx客户端错误5xx服务器错误301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址
  • Get，post：get请求查询，post 请求提交、修改，新增、编辑数据功能2.get请求数据在url中，post请求数据在请求体中3.post请求发送的数据量比get请求多，相对于get请求，post请求安全一些
  • HTTP请求报文请求行+请求头+空行+请求体组成，请求行：请求方式 请求url 请求协议/请求头：客户端浏览器告诉服务器一些信息：User-Agent浏览器版本信息Accept客户端接受类型的响应Referer当前请求从哪里来/请求空行：分割POST请求的请求头和请求体/请求体：封装POST请求参数的，GET无请求体
  • 请求头：Accept：可接受的相应内容类型(Content-Type)；Accept-Language：可接受响应内容的语言列表；Accept-Charset：可接受的字符集；Accept-Encoding：可接受的响应内容的编码方式；Accept-Datetime：用于表示HTTP协议中需要认证资源的认证信息；Cache-Control:用来指定当前的请求、回复中是否使用缓存机制；Connection：keep-alive/Upgrade客户端（浏览器有限使用的连接类型）Cookie:用于服务器与客户端间的通讯；Content-Length:以8进制表示的请求体的长度；Content-Type：请求体的MIME类型（用于POST和PUT请求中）Content-type：application/x-www-form-urlencoded;Date:发送该消息的日期和时间；Expect：表示客户端服务器做出特定的行为；Referer：表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面。Referer其实是Referrer这个单词，但RFC制作标准时给拼错了，后来也就将错就错使用Referer了。User-Agent：浏览器的身份标识字符串2、常用的相应头Access-Control-Allow-Origin：指定哪些网站可以跨域源资源共享Accept-Ranges：服务器所支持的内容范围Age：响应对象在代理缓存中存在的时间，以秒为单位Cache-Control：通知从服务器到客户端内的所有缓存机制，表示它们是否可以缓存这个对象及缓存有效时间。其单位为秒Connection：针对该连接所预期的选项Content-Disposition：对已知MIME类型资源的描述，浏览器可以根据这个响应头决定是对返回资源的动作，如：将其下载或是打开。Content-Encoding：响应资源所使用的编码类型。Content-Language：响就内容所使用的语言Content-Length：响应消息体的长度，用8进制字节表示；Content-Location：所返回的数据的一个候选位置；Content-Range：如果是响应部分消息，表示属于完整消息的哪个部分Content-Type：当前内容的MIME类型Date：此条消息被发送时的日期和时间(以RFC 7231中定义的"HTTP日期"格式来表示)ETag：对于某个资源的某个特定版本的一个标识符，通常是一个 消息散列；是否更新；Expires：指定一个日期/时间，超过该时间则认为此回应已经过期Set-Cookie：设置HTTP cookieServer：服务器的名称
  • 接口测试怎么做：在之前的项目中测试接口是后台开发先写出了接口，去测试接口的功能，保证接口的返回数据和接口文档中一致。1.测试前需要拿到接口文档，了解接口的访问方式。2.根据接口文档编写测试用例，测试接口在传入不同参数时的返回数据。3.使用jmeter或postman测试接口。4.将测试结果反馈给开发。

  • Postman：

  • 先创建集合项目--创建请求-填写接口地址，选择请求方式-填写输入参数，添加断言-前置脚本-点击send-查看测试结果

  • Jmeter：

  • 建立线程组添加HTTP请求，在http请求界面，输入IP，端口号http80，请求方法、输入路径，添加参数及值、添加对应断言、添加监听器察看结果数，查看运行结果。在测试环境下，添加线程组、添加http请求、聚合报告，添加用户，设置50线程，压5分钟看聚合报告的指标，错误率，吞吐量，然后压到100，300，然后增加到5000就是单接口的性能压力测试。
  • jmeter接口关联：提取登录接口返回的token，我们之前的项目中，访问接口时需要先配置登录接口，然后在登录接口中添加正则表达式提取器，左右边界一同复制，（.*?）代替提取登录接口返回token信息，用${引用名称}然后将获取到的token配置到请求头管理器中给其他接口使用
  • 登录接口：测试的时候我先冒烟，看这个接口通不通，然后我们再进行接口的功能测试。一般我会采用等价类、边界值、场景分析、等基本方法去考虑，比如说：参数的必填、参数的组合、测试的类型和长度，以及参数为空、为空格、为特殊字符的校验，同时我们不仅要看接口的请求地址、请求方式、请求参数、和响应结果是否正确、还有关注业务逻辑的校验。查询接口要考虑数据返回的是否完整，并与数据库进行对比。比如说提交订单时，在传递商品价格参数时，修改商品价格，就要看后端有没有验证了。或者我支付时，抓个包，修改订单金额，如果能以我修改后的金额支付，那么这个接口的问题就严重了)。以及信息是否加密。
  • 接口测试软件，一般怎么用，怎么判断接口测试结果：postman 主要用来测试接口的功能，jmeter 可以设置线程数进行性能测试，
  • Jmeter怎么做：1.设置并发2.添加监控3.执行测试，设置不同的并发数并收集结果回答：1.在接口功能正常的前提下，可以在线程组中设置线程数对接口执行性能测试2.在线程组中设置并发线程数、线程递增时间、测试持续的时间3.根据需要添加事务、定时器(集合点)、服务器资源监控、聚合报告、TPS4.执行测试、记录每组并发线程数对应的响应时间、TPS、服务器资源使用率等数据5.结合测试结果，判断当前接口的性能是否满足需求6.可以在测试结果中分析得到：1.TPS最大值对应的并发数2.满足用户响应时间需求时对应的并发数3.达到用户并发数要求时对应的响应时间
  • 数据库多表查询：分为内关联与外关联，内关联(inner join)，外关联分为左关联和右关联，左连接是以左表为主表，展示左表中的全部数据右连接是以右表为主表，展示右表中的全部数据。SELECT * FROM emp e INNER JOIN job j ON e.job_id=j.id;
  • 自我介绍
  1. 在测试过程中遇到哪些困难？是怎么解决的？前面总结有列举
  2. 怎么判定它是不是一个bug？谁去做决定它是不是一个bug.把自己的证据拿岀来，开发拒绝你这不是一个bug你会怎么办？需求决定是不是bug，一个项目一般是由产品来主导
  1. 测试用例的设计有看过一些书吗或者往更深的系统学习？
  2. 财务转测试是通过自学的吗？（转行原因）
  3. 说下登录的功能如何设计测试点？除了功能的还考虑其他的类型测试吗？对开发的代码你覆盖了哪些内容？登陆账号和登录信息有没有关注进入db里面的过程或者安全方面的
  4. Linux的常用命令和linux是用来做什么的？
  5. 日志查看用什么命令？查看日志文件的最后100行怎么查？
  6. 搭建环境你是怎么搭建的？
  7. 环境变量是怎么修改的？用什么命令？
  8. Jdk的搜索路径如何通过环境变量来修改？
  9. 数据库在你工作中涉及到哪些操作？什么情况会用到查询数据库？
  10. 有没有基于数据库的修改做一些测试？
  11. 那你的订单状态不需要需改订单状态测试更加简洁吗？
  12. 有支付的订单信息的时候没有通过db改状态跑异常测试吗？
  13. 有写过python的脚本吗？Python的了解有多少？
  14. 列表跟元组的区别？
  15. Python中对列表进行排序有哪些方式？
  16. Python字符串的相连有哪些方式可以实现？+号
  17. 你之前有过的python版本是哪个版本？
  18. 用fiddler用来做什么的？是做的手机端的抓包吗？
  19. 怎么通过fiddler把移动端的请求转到pc的后台服务？
  20. 怎么通过git和Jenkins进行持续集成？对持续集成的理解？
  21. 提交代码完成以后，有对持续集成有做一些验证吗？
  22. Js的前端代码你读得懂吗？有了解过吗？
  23. 最近的公司遇到的工作中最大的问题是什么？
  24. 加班大概持续多长时间？当时加班加了多久？
  25. 怎么样的测试效率才算快？
  26. 测试用例会做交叉执行吗？
  27. 从事测试行业自己的优点和缺点？
  28. 在上一家公司，你觉得对自己个人的能力而言，哪些能力有比较大的增长和进步？
  29. 你们之前测试有多少个人？
  1. 自我介绍
  2. 软件测试的目的是什么
  3. 测试用例的方法有哪些？
  4. 数字为7按照边界值来写测试用例有几个？
  5. 一包纸巾如何测试？