网上银行转账是怎么测的，设计一下测试用例。
回答思路：
宏观上可以从质量模型（万能公式）来考虑，重点需要测试转账的功能、性能与安全性。设计测试用例可以使用场景法为主，先列出转账的基本流和备选流。然后设计场景，最后根据场景设计数据。实际面试中需要举出具体的例子。
先检查界面。
再测试功能：
验证同行转账，跨行转账。
验证转账限额。
验证非法账户（挂失，冻结，锁定的账户）的转账。
再测试性能方面的。
测试工作的流程?缺陷状态有什么?设计测试用例有几种方法？
测试工程师的实际工作流程（以P2P中型版本为例，一个月一个版本）：
产品经理或者SR把需求书发下来给开发和测试
测试先看一遍，进行需求分析。测试组长编写测试计划，并且分配测试任务给测试人员（2天时间）（此时开发也在进行需求分析）
过了2天，产品经理再把测试和开发召集在一起，进行需求讲解（或者说需求评审），有问题可以直接问，如果发现需求有问题，也可以提出来，SR回去会修改。（需求讲解时间0.5天）
讲完需求后，测试同事要进行测试场景的梳理和案例的编写了（xmind和Excel就要用上了），一共5个工作日。（此时开发在编写代码）
之后就要进行案例评审了，评审时候有SR、测试同事、开发同事，评审时候一般SR、测试组长、对应模块的开发同事会提出一点意见，评审完之后，回去修改、补充一下案例。（案例评审0.5天）
修改完以后，有两种处理情况：
对大项目有时候要进行案例的第二次评审。
对小项目，在时间紧的时候，一般不会二审，但是要以邮件的形式把修改或者新增后的案例发出来，给领导看，并抄送给其他同事。（案例评审0.5天，修改案例0.5天，案例二审0.5天）
案例评审完就要开始测试了，一般测试环境开发搭建好（要说自己也会搭建，搭建流程背老师总结的）：
中型版本的测试一般分2轮：第一轮：5天；第二轮：3天；回归测试2天；（共10个工作日）。
回归测试完后，达到了上线标准，就会如期上线，一般当天晚上12点上线
缺陷状态：缺陷管理的流程图
在项目中找到的经典BUG是什么？
兼容性问题，在ie浏览器，提交订单按钮可以点击，到了谷歌，火狐就不能了。
查询订单页面，根据条件筛选的结果不是想要的结果，还有某些字段的值没有显示出来，或者显示错误。（因为开发从库表取值有误）
付款成功后，订单状态一直不翻转为交易成功。（因为代码没有正确获取库表中付款成功记录的状态码）
修改支付密码，新密码和原密码一致，也通过了，系统没有做新旧密码的校验。
付款时候的手机验证码，可以一直使用，没有成功做有效期控制。
手机app断开网络后，再去点击，没有友好的错误页面提示网络已断开，只有undefined返回
定期存款到期自动转存该怎么测？
回答思路：到期肯定会有边界，所以设计里面可以考虑边界值法。自动转存（首先要搞清楚什么是自动转存。）
存钱该怎么测，用什么测试方法？
准备思路：存钱要分类：活期、零存整取等（具体规则百度下），然后根据每类的业务规则选择合适的用例设计方法。譬如一次最少存入多少？最多一次能存入多少等。
你发现Bug后，应该怎么办？
首先咨询一下开发是不是bug，让他初步判断一下。
如果不是bug，开发给到理由也比较充分，确实自己也搞错了，也就算了。
如果开发也认为是bug，那就直接提了。
如果我怀疑开发的解答，我觉得是bug，开发坚持不是bug，我就要咨询我们组长或者开发组长，让他们判断一下。
假如发现了一个BUG，跟开发本身没什么关系，涉及到理念，需求问题，如何解决？
把问题暴露给测试组长和开发组长，咨询他们意见，组长们再知会开发分组经理和项目经理，然后大家和产品经理一起探讨解决，需要改需求的地方就要改了。
测试非常紧急过程中，遇到阻塞性问题，对应的开发没有时间解决，你如何推动问题解决？
首先判断问题的严重性，向对应的开发了解问题的原因。
然后再汇报给自己的测试组长和开发组长，让组长知情，咨询他们的意见，再把问题汇报给开发分组经理，让他们统一协调处理。安排经验丰富的其他高级开发人员来协助此开发解决问题，然后通过加班来完成问题解决和测试。
功能测试的BUG级别你们怎么划分？
bug严重程度：一般提L4 和L3，L2很少提，除非影响流程。L1这个是非常致命的bug，基本上不会提。
执行别人的用例，如果发现用例有错怎么处理？
首先咨询一下案例作者或者询问测试组长，确认一下，如果确实有误就要修正用例。
你们做过冒烟侧吗？冒烟测试是什么（理论）？
冒烟测试也叫预测试，就是正式测试之前的一种测试，为了确保主流程能走通。
可以回答没有冒烟测试，就说测试之前一般会要求开发自测，开发自测后（自测大概就是一天左右的时间），确保没有大的问题，再通知测试开始测试。
你们项目做了多久，共写了多少用例？项目多少人？
项目做了多久：（两种回答，建议选择第一种）
我进去的时候项目已经上线了，一直存在，然后就是版本的微小更新，小修改的话，大概半个月一个版本，中修改的话，大概一个月一个版本。每次版本更新，针对新的功能点或者修改点大概写了60条案例左右（一个月一个版本的例子）。
我进去的时候，一开始就参与这个项目（也就是需求分析开始），项目从零到有进行了半年左右，六个月内大概整个项目组写了900条案例左右。自己写了200条左右(共5个测试，包括组长)。
PS:如果大家说自己是从零到有参与的项目，那么6个月时间是从需求分析开始。需求书编写完成前，产品经理他们是要做很多前期准备工作，可能要花费3个月左右的时间。
那么测试6个月的实际工作时间内：
前期2个月：刚开始需求书的漏洞比较多，需求评审比较多，基本上每个星期一次评审。开发和测试都会参与，此时开发在进行代码设计，测试就在分析需求，看参考文档，用xmind梳理测试场景，提取测试点，开发经常和产品经理讨论需求，测试经常问开发和产品经理有关需求的疑问。大家一直碰撞，一步一步得出比较完美的逻辑。
中间2个月：开发设计完后，进行编码，我们测试就根据之前梳理的测试场景来编写案例，进一步优化。这个期间，需求书基本稳定，不会再改了。要改也就是把细化需求，把笼统的地方，描述的更详细，更让人易懂，功能点的大方向不会改。开发和测试在此期间有疑问，都会邮件或者电话联系产品经理。测试也会经常去问开发有关功能点的逻辑问题。
后面2个月： 执行案例工作开始进行，一般分为两轮st测试，第一轮1个月，第二轮半个月，回归测试半个月。Uat测试组在st测试第二轮时候，并行开始。Uat测试组有专门人负责，一般需要st测试组派一个人左右去支持，uat测试也有第一轮（半个月），第二轮（半个月）。
项目多少人：一个公司往往有很多项目，自己只是其中一个项目组的，我的P2P项目组大概20人，开发15个，测试5个。（大家把自己当成外包人员，在甲方工作，也叫驻场工作）
假如要你测试6个月期限的p2p借款产品，你应该怎么设计案例，说出测试点
（回答思路：1站在用户的角度测试，用户怎么用，你就怎么测试。2 一个人扮演多种角色测试。 3多想出一些异常场景。）
借款产品投标结束日T+7时，满标和不满标的情况。
借款产品投标结束日T+7前，产品提前满标情况
产品成立后，每个月还款日前，检查系统有没有发出邮件，短信，站内信通知借款人充值到平台账户。
在每月还款日，借款人充值用来还款时，充值资金足够、不足够、不充值情况，查看系统如何处理。充值资金不足或者没有充值时，系统应该有罚息。
借款人提前还清余款场景，有些产品不支持提前还款，有些产品要满一定期限才可以提前还款（提前还款有一定手续费）。这些都是要关注的测试点。（自己要扮演借款用户去操作提前还清余款，然后扮演后台管理员去审核，然后又扮演投资人用户去检查虚拟账户的资金到账情况）
最后一期借款人还清资金时，去后台页面查看借款产品状态，应该已正常结束。再去前台页面搜索，应该无该借款产品了。 （或者补充说：去数据库里查看此借款产品的状态）
你们这个P2P上线了吗？能查吗？项目花了多久时间，预计多久完成？
回答：两种方案：
还没上线，查不了，这个是新项目，计划半年时间完成，但是因为中途有出现一些问题没有解决完毕，所以现在还没有在预计时间内完成。
大家写的项目名在网上确实能查出来，就说上线了，能查到的。（面试官其实不一定会去查）
实名认证你们是怎么测得？调取什么平台的资料？
实名认证接口：
银行卡实名认证（调用银行接口，验证卡号，姓名，身份证号码，手机号码。需要利用到手机接收到的验证码）
身份证实名认证（全国公民身份证号码查询服务中心，或者直接说公安接口）
注册需要实名认证吗？
注册不需要实名认证：当购物时候需要实名认证。
P2P你们也测试后台管理吗？个人芝麻信用积分是调取哪里的资料？
测试后台管理：
后台也测，但是我主要测试前台，我的关注点是前台，后台只是拿来用，能配合前台正常走完流程就行。
后台主要对前台进行管理，主要有贷款管理，资金管理。
贷款管理：可以查看投资人的投资情况，也可以查看借款人的借款产品，对借款产品进行管理。比如审批，每期的还款提醒，预警等。
资金管理：管理查看用户的充值，审批用户的提现过程。
芝麻信用积分：调用的是支付宝的接口，芝麻信用：调用的是支付宝那边的接口（支付宝提供这样的芝麻信用服务，每查一次收取大概0.1元）
如果要测试后台删除用户，就是用户名后面一个删除按钮的情况，能写出哪些测试用例
删除一个用户的场景：点击删除按钮，页面自动刷新，此用户在该页面已查询不到。再去打开另外一个浏览器，在前台登录已删除的用户，页面提示该用户不存在。
同时删除多个用户的场景：利用复选框，测试多选，反选，全选删除用户的情况。删除后，被删用户在该页面已查询不到，同样要去前台登录已删除的用户，页面应该提示该用户不存在。
如果京东有一个购物网页给你，你要怎么进行测试？测试哪些主要功能？
首先进行需求分析，用xmind梳理测试点，再编写案例，之后就行案例评审，寻求他人意见。之后再完善案例，发出来给其他人检查。
测试点，首先是UI方面：美观度，和易操作型，易理解性型方面进行测试。
然后再考虑他的功能点，注册登录，添加购物车，下单，付款，发货，确认收货，评价。还有支付时候的绑定银行卡，实名认证
性能方面：打开网页，确认订单、付款的响应时间等等。
兼容性：支持各种主流浏览器，ie，360，火狐，谷歌等。
针对添加购物车这个测试点说一下你要怎么测试“添加购物车”
（增删改查的角度）
能否加入购物车，同一件商品能否再次添加到购物车。
购物车商品件数的上限限制（淘宝限制100件）
购物车是否可以正常移除商品，移除商品后，能否再添加回来。
添加的每种商品是否可以正常增减数量，数量大于0
退出购物车，再去查询购物车，商品正常。
购物车的商品可以全选，取消全选，可以复选，选中的商品和数量可以正常下单。
商品添加到购物车以后，已下架。购物车会提示此宝贝已失效。
商品添加到购物车以后，降价了，购物车会有降价提示。
商品添加到购物车以后，库存不足了。
P2P功能测试你们一般做几轮？
答：
中型版本（大修改，一个月上线一次）：测试一般分2轮：第一轮：5天；第二轮：3天；回归测试2天；（共10个工作日）。（一个月工作日22天，需求分析评审，编写测试用例等等一般占用整个版本时间的一半，或者少个几天）
小型版本（小修改，两个星期一次）：一轮测试3天，回归测试2天。
你们每次开会讨论的时候十几个开发都去开会了吗？
案例评审会：一般开发和测试、产品经理都会到场。（开发分组经理可能也会去）需求评审会：项目经理、开发分组经理、产品经理、测试、开发一般都会到。
如果是我们测试小组开会，一般都要到，各位测试同事报告自己的心得体会，汇报自己的进度和问题。
数据库查找两个表
回答思路：
多表查询，后面具体会学到：select 列1，列2 from 表1,表2 where 表1.列=表2.列 这样的格式要能说出来。
熟悉数据库吗？平时数据库用的多吗？
熟悉数据库吗：比较熟，比如DML语句有增删改查：（有序思维说出来）
1 insert into 表名 values（值1，值2，值3，…）
2 delete from 表名 where 条件
3 update 表名 set 列名 = 新值
4 select * from 表名
查询语句最长的是 select * from 表名 where 条件 group by 分组列名 having 分组后的条件 order by 列名。
平时数据库用的多吗（大概测试过程的1/4时间在查数据库）：还行，一般出现问题，遇到bug，就要去查询数据库，初步定为问题。开发会给到我们一个库表设计的excel（数据字典），里面有描述表名和表中的字段，我把交易过程的一些唯一标识，把他作为where条件去查询数据。初步分析后，再把问题暴露给开发。（比如淘宝支付时，输入支付密码后，已经返回了支付成功的提示信息，然后界面上的订单查询还是待付款，这个时候就要去查询订单表的数据，找到自己刚才做的交易的那一笔订单，去分析一下错误，再暴露给开发）
linux查看文件用什么命令，查看进程用什么命令
回答：
查看文件内容的命令有 more less head tail cat tac
查看进程：ps -ef | grep 进程号
查看日志文件常用:less、view
查看日志常用什么命令，主要查看什么内容
查看日志常用less命令或者view命令。
主要查看程序运行的记录，比如支付失败，后台就有报错信息打印到.log日志文件中，就可以通过分析日志信息来初步定为问题。（补充：同时也去查询数据库，分析订单数据，查看支付状态等等）
PS:日志就是.log的文本文件，和.txt一样属于文本文件。vi或者vim编辑器属于记事本软件，一般不会用来查看日志。
如何查找a.log日志文件的error字符串
第一种方式：（建议说第一种方式）
cat a.log | grep error;
第二种方式：
1 less a.log;
2 /error;
你所熟悉的linux命令
linux：cat,more,less,head -n，tail -n，find ,| grep,ps -ef,tar,gzip,mv,cp,touch,mkdir，vi,top
也可以结合搭建环境的过程说用到的命令。
你们测试用的测试环境是谁给的？linux怎么搭建测试环境？
一般开发搭建，但是我也会，我之前自己搭建过一个小项目（松勤学员参考考试系统的搭建流程）
流程大概是：
首次搭建：
通过winscp上传tomcat，MySQL安装包，JDK（Java开发环境工具包）到linux下
利用tar -zxvf解压缩包命令对jdk,tomcat，mysql进行解包、安装，再配置jdk环境变量。
把war包（web程序）放到tomcate指定目录webapps下，再启动服务器即可。（输入startup.sh的路径，直接回车即可运行）
非首次搭建：
把war包（web程序）放到tomcate指定目录webapps下（已经存在web服务器和数据库服务器的前提下），启动服务器即可。（输入startup.sh的路径，直接回车即可运行）
抓包工具使用：
就是打开fiddler工具后，再去浏览器打开网页，fiddler会自动抓包，抓取请求响应数据。他会自动设置为本地代理，还可以设置抓取https协议的包。
如果要抓取手机访问互联网数据包，就要在手机上的网络设置里，设置代理服务器。就是把fiddler作为代理服务器（fiddler自身要设置为支持远程连接），手机连接fiddler工具，所以手机代理服务器设置页面要输入打开fiddler工具的电脑的ip地址和fiddler的端口号8888，好让手机能连接fiddler，通过fiddler来访问互联网。
PS：浏览器都自带抓包工具，F12快捷键可以调用此工具，开发经常利用此工具来分析页面数据，通过分析页面数据来定位程序问题。
金融行业知识你了解多少
把以下老师整理的理解记忆一下：
如果领导分配你的任务超出负荷，领导高估了你的能力，怎么办
回答思路：
首先表达态度，态度上愿意通过加班来完成，还可以请求测试同事支援，让组长协调。
高估了能力，能力可以在工作中通过自己的努力来达到领导的要求
总而言之基本的思路是态度要端正。
不能直接拒绝任务。但也同时表达万一做不好还请领导包容。
假设你是组长，团队中有一个员工无法按时完成交付的任务，你如何处理；
回答思路：
首先先检讨自己是否任务安排超过了这个员工的能力。
如果没有超过，首先表示关心身体和状态，了解未及时完成任务的原因，如果原因是客观原因则一起加班跟员工来完成任务。
如果是态度原因，则指出利害关系，责令其通过加班来完成。
如果因为你的错误导致工作发生问题，你怎么办？
回答思路：
首先要表达在过去的工作中从未发生过类似事情，因为自己工作态度还是很端正的。
万一因为自己的错误导致工作发生问题，首先应该把问题上报给领导，争取把问题的影响降到最低程度。
给你一个模块测试，只有一个星期的时间你如何有效率地完成？
答：在有限的时间里，明确需求的情况下，制定工作计划，把每天任务细分，先保证重要功能，跟进修复情况，及时验证bug。每天发工作日报，汇报进度，如果遇到风险，及时汇报领导。
如果给你一个没有需求的app测试项目，你应该怎么测
老师建议：根据APP的 11大测试点：
权限测试
安装、运行、卸载测试
UI测试
功能测试
性能测试
中断测试
兼容测试
安全测试
回归测试
升级更新测试
用户体验测试
补充：根据自己的经验，制定测试计划，每天汇报自己的进度，发出测试日报。
测试过程有问题，及时上报，及时跟进bug，多和开发交流沟通，明确需求。
如果你和开发的意见产生分歧，你怎么处理？
回答思路：
大的原则是对事不对人。
另外我会首先尝试站在开发的角度接受对方的意见和建议，同时控制好自己的情绪，在对方情绪可控的情况下表达自己的意见。
如果你组长的用例写错了，但他认为是对的，你怎么处理？
回答：
通常情况下，领导看问题的角度会比我们更全面，所以我首先得确保领导的用例是否真的有考虑不到的地方。
我不会坚持自己的是对的，但会在合理的情况下表达自己的观点。
你同时负责功能和性能，你怎么做
先测成功能，保证功能的完成，再做性能，在提交bug后，开发还没改好时，可以准备性能测试，在工作时间很紧的情况下会主动加班
我们公司自动化测试用的语言是Java，Java你不会，该怎么办？
回答思路：
问到不会的标准思路：要么说会一点相关的内容，要么表达自己有不错的学习能力和很好的学习意愿和态度。
我们学了Java了就说会，知道面向对象的封装，继承，多态，知道多线程的两种创建方式（自定义子类继承Thread类，或者自定义子类实现Runable接口），还知道异常Throwable，Exception的格式，try catch finally。知道List， Set，Map集合。我可以很快的学会用Java做自动化。
以前的项目是怎么管理的？
回答思路：
我们以前的项目是用禅道来做测试的需求管理、用例管理、缺陷管理的。另外版本管理工具使用的是SVN。
以前的项目每天需要执行多少用例
回答思路：
正常情况一般每天执行20个左右的用例，刚开始测试的时候，bug比较多，需要很多时间和开发交流沟通
案例执行会比较慢。越到后面就越快了。
你们做回归测试的时候是否全部都做呢？
看时间，如果时间比较充足，会全部回归，回归时候因为自己操作比较熟练，然后系统基本上也没有bug。所以执行案例的速度会比较快。
如果时间比较紧，就会挑选重要模块来回归测试了。
PS:自己组织好语言。
你们怎么确保用例覆盖率？确保不重复？
利用判定表法的思想，先穷举，再挑代表。
然后，案例评审时候产品经理、开发组长、测试组长，还有对应模块的开发负责人也会把关，可以咨询他们意见，确保案例即覆盖完全，又没有多余的重复案例。
你们案例是怎么评审的?
评审时候有产品经理（SR）、测试同事、开发同事，评审时候一般产品经理（SR）、测试组长、对应模块的开发同事会提出一点意见，评审完之后，回去修改、补充一下案例。
修改完以后，有两种处理情况：
对大项目有时候要进行案例的第二次评审。
对小项目，在时间紧的时候，一般不会二审，但是要以邮件的形式把修改或者新增后的案例发出来，给领导看，并抄送给其他同事。（案例评审0.5天，修改案例0.5天，案例二审0.5天）。
视图是什么?
视图记录了一条SQL语句，当查询时才有数据返回。表就是一张具体的表。视图只能查询数据，表可以增删改查。
工作非常努力了，还是没有完成上级交代的任务，怎么办？
回答思路：
其实领导最喜欢的员工是：能力强、态度好的。领导招聘我们的目的是帮助他解决问题。
你工作非常努力，还是没有完成上级的任务，要分析原因，如果是能力不够的原因，则要表示愿意且一直在提高能力，希望领导能谅解。
如果是因为可能的领导安排的任务过多，则要委婉地表示自己的能力有限，不希望自己的能力影响项目的进度，另外也请领导多给点提高效率的建议。
你的职业规划是什么？
首先快速熟悉业务，熟悉环境，再主动研究，转组长，经理（突出自己的努力和稳定）
（切忌在功能测试的面试说自己要往自动化，性能发展。因为他怕你不稳定，以后会嫌弃他公司的功能测试。除非该公司以后会考虑使用自动化或者性能测试技术）
平时周末不上班都做些什么呢？
有空就会学习巩固技术知识，比如自动化，性能，还自学python和selenium
从上家公司学到了些什么？
从大家一起努力认真而有序的项目过程中，虽然辛苦，但是收获良多。我获得了测试的经验，业务的熟悉，技能的提升，以及团队配合协作的精神、坚持不懈的精神。
为什么从上家工资离职
面试官可能会说：你就实在和我说吧，不要说什么套话。
（还是选择说套话吧）首先感谢上家公司提供的提升自我工作经验的机会，之所以想离职是因为想积累不一样的经验，更进一步的学习，来提升自己。我觉得贵公司非常符合自己的要求。
你住哪里？
因为很多人离职时候，往往会以住的地方太远为借口来申请离职，所以面试官可能会问你住哪里，防止你以后入职不稳定。
回答：
住的比较远的同学就说住哪里哪里，上班比较近。（住的地方建议说成和上班的地方在1个小时路程以内）
离职时候工资多少？
说比现在期望薪资少500元。