⾦融⾏业软件测试⾯试题（含答案）
⽹上银⾏转账是怎么测的，设计⼀下测试⽤例。
回答思路：
宏观上可以从质量模型（万能公式）来考虑，重点需要测试转账的功能、性能与安全性。设计测试⽤例可以使⽤场景法为主，先列出转账的基本流和备选流。然后设计场景，最后根据场景设计数据。实际⾯试中需要举出具体的例⼦。
先检查界⾯。
再测试功能：
验证同⾏转账，跨⾏转账。
验证转账限额。
验证⾮法账户（挂失，冻结，锁定的账户）的转账。
再测试性能⽅⾯的。
测试⼯作的流程?缺陷状态有什么?设计测试⽤例有⼏种⽅法？
测试⼯程师的实际⼯作流程（以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点上线
缺陷状态：缺陷管理的流程图
在项⽬中到的经典B UG是什么？
兼容性问题，在ie浏览器，提交订单按钮可以点击，到了⾕歌，⽕狐就不能了。
查询订单页⾯，根据条件筛选的结果不是想要的结果，还有某些字段的值没有显⽰出来，或者显⽰错误。（因为开发从库表取值有误）
付款成功后，订单状态⼀直不翻转为交易成功。（因为代码没有正确获取库表中付款成功记录的状态码）
修改⽀付密码，新密码和原密码⼀致，也通过了，系统没有做新旧密码的校验。
付款时候的⼿机验证码，可以⼀直使⽤，没有成功做有效期控制。
⼿机app断开⽹络后，再去点击，没有友好的错误页⾯提⽰⽹络已断开，只有undefined返回
定期存款到期⾃动转存该怎么测？
回答思路：到期肯定会有边界，所以设计⾥⾯可以考虑边界值法。⾃动转存（⾸先要搞清楚什么是⾃动转存。）
存钱该怎么测，⽤什么测试⽅法？
准备思路：存钱要分类：活期、零存整取等（具体规则百度下），然后根据每类的业务规则选择合适的⽤例设计⽅法。譬如⼀次最少存⼊多少？最多⼀次能存⼊多少等。
你发现B ug后，应该怎么办？
⾸先咨询⼀下开发是不是bug，让他初步判断⼀下。
如果不是bug，开发给到理由也⽐较充分，确实⾃⼰也搞错了，也就算了。
如果开发也认为是bug，那就直接提了。
如果我怀疑开发的解答，我觉得是bug，开发坚持不是bug，我就要咨询我们组长或者开发组长，让他们判断⼀下。
假如发现了⼀个B UG，跟开发本⾝没什么关系，涉及到理念，需求问题，如何解决？
把问题暴露给测试组长和开发组长，咨询他们意见，组长们再知会开发分组经理和项⽬经理，然后⼤家和产品经理⼀起探讨解决，需要改需求的地⽅就要改了。
测试⾮常紧急过程中，遇到阻塞性问题，对应的开发没有时间解决，你如何推动问题解决？
⾸先判断问题的严重性，向对应的开发了解问题的原因。
然后再汇报给⾃⼰的测试组长和开发组长，让组长知情，咨询他们的意见，再把问题汇报给开发分组经理，让他们统⼀协调处理。安排经验丰富的其他⾼级开发⼈员来协助此开发解决问题，然后通过加班来完成问题解决和测试。
功能测试的B UG级别你们怎么划分？
bug严重程度：⼀般提L4 和L3，L2很少提，除⾮影响流程。L1这个是⾮常致命的bug，基本上不会提。
执⾏别⼈的⽤例，如果发现⽤例有错怎么处理？
⾸先咨询⼀下案例作者或者询问测试组长，确认⼀下，如果确实有误就要修正⽤例。
你们做过冒烟侧吗？冒烟测试是什么（理论）？
冒烟测试也叫预测试，就是正式测试之前的⼀种测试，为了确保主流程能⾛通。
可以回答没有冒烟测试，就说测试之前⼀般会要求开发⾃测，开发⾃测后（⾃测⼤概就是⼀天左右的时间），确保没有⼤的问题，再通知测试开始测试。
你们项⽬做了多久，共写了多少⽤例？项⽬多少⼈？
项⽬做了多久：（两种回答，建议选择第⼀种）
我进去的时候项⽬已经上线了，⼀直存在，然后就是版本的微⼩更新，⼩修改的话，⼤概半个⽉⼀个版本，中修改的话，⼤概⼀个⽉⼀个版本。每次版本更新，针对新的功能点或者修改点⼤概写了60条案例左右（⼀个⽉⼀个版本的例⼦）。
我进去的时候，⼀开始就参与这个项⽬（也就是需求分析开始），项⽬从零到有进⾏了半年左右，六个⽉内⼤概整个项⽬组写了900条案例左右。⾃⼰写了200条左右(共5个测试，包括组长)。
PS：如果⼤家说⾃⼰是从零到有参与的项⽬，那么6个⽉时间是从需求分析开始。需求书编写完成前，产品经理他们是要做很多前期准备⼯作，可能要花费3个⽉左右的时间。
那么测试6个⽉的实际⼯作时间内：
前期2个⽉：刚开始需求书的漏洞⽐较多，需求评审⽐较多，基本上每个星期⼀次评审。开发和测试都会参与，此时开发在进⾏代码设计，测试就在分析需求，看参考⽂档，⽤xmind梳理测试场景，提取测试点，开发经常和产品经理讨论需求，测试经常问开发和产品经理有关需求的疑问。⼤家⼀直碰撞，⼀步⼀步得出⽐较完美的逻辑。
软件测试app
中间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⽇志⽂件的e r r or字符串
第⼀种⽅式：（建议说第⼀种⽅式）
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环境变量。