接口自动化
4.1 简单介绍下最近做过的项目¶
根据自己的项目整理完成,要点: 1)项目背景、业务、需求、核心业务的流程 2)项目架构,B/S还是C/s,数据库用的什么? 中间件用的什么?后台什么语言开发的? 是否有做App端,是否有H5是否开发小程序等等。 3)项目前端有哪些功能模块,后台有哪些功能模块?
4.2 拿一个你所负责的模块,讲下具体怎么测的?¶
根据自己的项目整理完成,核心要点: 1)拿一个你负责过的模块,核心业务模块讲解 2)业务流程是怎样的,需求怎么样,有什么规则没,规则简单介绍 3)你是如何分析的,讲明分析思路,测试点,主要怎么考虑测试的,主要核心测试重点在哪里, 用了什么测试方法等等。
4.3 你在这个项目里面主要做了些什么工作?¶
1)在这个项目中,主要是以功能测试跟后台接口测试为主,主要参加了需求评审会议,用例的编写, 参与用例的评审,执行测试。 2)协助开发定位问题解决发现的bug,编写测试报告,协助上线。 3)另外就是做了APP的一些相关项测试,像兼容性测试、稳定性测试、安装卸载版本覆盖测试和app性能都是有做过的,例外后期有做过接口自动化等。主要就是做了这些工作。 [这个具体根据你自己的简历上写的来说]
4.4 你们项目组有多少人、开发多少个、测试多少个?¶
[公司具体人数,可以不太清楚,项目组多少一定清楚] [这个一定要根据自己的简历项目大小来说,不能乱说] 产品1、项目1个、架构师1个、前端3个、后端5个、ios1个、Android 1个、 测试3个(测试主管,核心测试人员)、运维1个、UI一个
4.5 测试人员怎么分工的?¶
1)我们测试组3人,1个测试组长,2个测试,一般都是根据需求的复杂程度大小来, 尽量是自己熟悉哪个版块的就继续做那个版块。 2)比如:我这边主要是负责前端大部分的功能模块,还有接口测试跟ui自动化测试,另一个同事主要是功能测试这边,组长这边也负责一些功能测试,包括一些性能跟安全测试。 3)其实测试工作也划分的没有那么细,后期我们也会做交叉测试,相互测试功能,性能跟安全测试我也会参与一下。
4.6 项目的送代周期? 多久一选代? 一个版本你们发现多少bug¶
[切记工具自己所选择的项目来回答] 我们公司是这样的,迭代还是蛮快的,一般是两个星期一个迭代,迭代测试两轮。Bug的话不一定哦,关键还得看开发,哈哈,开发的版本质量好的话,BUG就会少些,整个版本比较好的情况下大概也就二十来个BUG,当然如果遇到开发是个新手,那么找到60-70个也是很常见的,比如之前的那个金融项目,足足发现了72个BUG,这样的情况下追踪BUG的工作量都比较的大,如果是版本选代的话,那么基本就不会出现多少BUG了。 参考答案2 因为我们项目的用户活动和三方合作平台比较多,一般半个月或者1个月肯定会有一个迭代版本, 假如用户或者合作方突然有很紧急的需求,那一般老大他们会向上发邮件和OA呈批给(产品经理,项目经理),如果通过了就会马上加急处理这个需求,测试完成直接上线。 现在都是维护为主,但新需求也不断有,一般一个版本上百个bug是有的。
4.7 你们整个项目写了多少用例,你负责的模块大概写了多少用例?¶
[切记己根据自己的项目及负责的模块来] 答:这个得根据项目的复杂程度,我们最近做的这个也还好,整个项目写了大概2干3百多条(有点多了),我负责的模块就写了一千多条(你要思考,你负责了哪些模块,大概评估下,不要乱喊)。 总结注意点:没有标准答案,先说你的前置条件,再说数据,只要你前置条件和数据匹配即可。
4.8 最近的版本写了多少用例?¶
(总结注意点:没有标准答案,先说你的前置条件,再说数据,只要你前置条件和数据匹配即可 特别注意:你如果是半个月的版本,一般给你两天写用例,你自己评估下写多少。 半个月的版本:1-2天需求分析,1-2天写用例,1天评审用例,其余的时间就是执行回归bug,编写测试报告) 最近的版本因为没有特别的用户活动,产品那边也没有给特别大的改动需求,我负责的 有5个模块吧,大概有180多条用例。
4.9 你的需求分析一般几天,用例大概写了多长时间?执行了多长时间?¶
如果按照2周一个版本来算的话,我们需求分析一般是由产品SE先组织我们开会,讲清新版本需求,然后我们再花1天到1天半时间去详细分析需求,另外有2天左右时间来写用例,写完用例会进行用例评审,后面的时间基本就是在执行用例,提bug,并跟进bug修复问题。
4.10 在uat测试的时候,突然客户临时要大量的数据¶
备注说明:uat:测试人员提供用例,uat环境已搭建好,他就开始来执行,如果发现问题, 需要协助,谁负责这个需求,就找对应的人,发现bug,提交到uat版本里面,修复完了, 客户需要回归验证的,我们公司只是辅助他去执行测试。 答案: 看他需要的数据能不能从上个版本,或者生产环境导入数据进来测试,如果没有,我们看能不能 批量修改数据去测试,如果不行,我们只能通过存储过程造数据了。
4.11 发现哪些映像比较深刻bug/经典bug?¶
根据自己的项目来准备,核心要点: 1)有哪些经典或者说影响比较深刻的Bug,最好是与业务相关的Bug,不要举例说前端的Bug 2)具体怎么分析,讲明你的分析过程。如何定位的...... 比如:业务逻辑漏洞; 支付功能: 1)商品选择支付的时候,实际已扣款成功,但是用户后台显示该商品没有付款, 导致不能使用该商品提供的服务。 2)商品所显示的价格是x元,但是实际支付的时候显示和扣款的价格是y元(x≠y) 找密码流程: 按照常规操作,会直接跳跃了某个必须的流程(流程缺失),但是通过url修改参数又可以访问到 该流程,存在安全和逻辑漏洞。 安全漏洞: 1)登录账户:退出or注销之后,浏览器返回键回退之后又可以回到已登录的页面继续操作,识 别用户身份的信息并没有失效,用登录后才能访问的url直接访问也可以登录,安全漏洞。 2)搜索功能:前端页面的搜索输入框中输入特殊敏感符号 (如script> alert(document.cookie)20M),较大分辨率(如:1600×1200),服务器没有相应的异常处理 机制,导致网站出现持续长时间的卡顿,影响后续操作。 2)上传的是非常规的文件,如js格式文件,程序无相关控制,直接将js文件上传到数据库, 前端页面访问时若不能解析则出现异常页面。 缺少非空判断,服务器报500错误: 1)编辑包含多个字段的页面时,有一些字段在程序中控制是必填的(事先未知),但是没有任何 说明提示,当不填写这些字段,直接保存时会出现服务器异常页面,报500状态错误。(特别 是在管理后台容易出现此场景) 2)在形如以下结构的if函数中,关系表达式的条件没有对某个变量(该变量因代码疏漏未作初 始化赋值)进行非空判断,就直接执行语句体,程序已空值null进行参与运算而出现异常, 如500错误if(关系表达式)样式导致异常。 3)某个功能(如:金额输入和统计)在A页面程序限制只能输入正整数,而在B页面却没有相应 控制,若不小心在B页面输入了非正整数,比方小数,A和B的数据分别传递到到同一个C 页面时数据处理会出现异常。 4)文章上传/图片上传:超长字符的文章内容or较大尺寸的图片上传,程序没有进行相关的压 缩和截取,直接完全调取到前端页面,导致浏览样式异常, App测试过程中常Bug: https:/www.cnblogs.com/123456ww/12198075.html [经典bug:前端申请借款中,用户没有信用额度或者借款金额超过了用户信用额度但是却能成功提交审核] [发现途径:我是在模拟借款人,借款金额提示我的可用额度为0,但是我输入5000的借款金额点击提交审核提示我提交成功,等待审核] [解决:首先我去数据库查找到对应的表,比对我的信用额度跟界面显示的数据是否一样,一样我就把数据库的记录,填写的借款信息和我借款成功的界面显示截图都保存好。之后提交这个bug,开发人员通过修改代码,我再复测,有没有重现bug] [还有一个就是在借款流程中,我们通过修改数据库中的数据,把借款时间修改了,制造出一个逾期未还款的数据,结果显示还款的金额比借款金额还少,而且管理要收得特别高,存在不合理性] [还有一个是在产品上线后,运维人员在统计数据时发现少了一条数据,我们去数据库检查发现0分0秒的数据没有统计,后来开发人员修改了代码之后就解决了] 1)服务费计算错误,计算公式开发这边写错,本来是利息0.3,写成003,开发修复bug。 2)退出用户,后退还可以进入到原来的登录完成操作后的界面,原始,退出用户,没有删除用 户对应的session,导致后退完成后,用户用户 cookie可以进行操作。 3)重新选择下拉框,输入信息全部清空,原因,修改类型,重新刷新界面,输入数据,并没有 保存缓存里面,导致一刷新,原来信息没有,解决,开发选择不同借款类型,不再进行刷新。 4)借款标题,输入xss攻击代码,导致接口所有的数据不存在显示,因为xss脚本,当然代码 处理,开发这边进行转义字符串。 5)谷歌浏览器登录不成功,显示验证码。
4.12 每个阶段测试开发在干嘛(比如你写用例的时候开发在干嘛?)¶
1)需求阶段,大家都在了解需求 2)测试准备, 测试编写用例,开发做概要设计,详细设计,然后就是编写代码,编写接口文档,设计文档。 3)测试执行阶段, 测试人员执行用例,发现bug、提交bug、开发修复bug(开发还有可能在开发未完成的功能)
4.13 你们公司是否敏捷开发¶
可以说是,也可以说不是。[具体看你了不了解敏捷开发模式] [问了我有没有做过敏捷测试] 扩展知识储备: 1、什么是敏捷开发 敏捷开发以用户的需求进化为核心,采用达代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试, 具语可视、可集成和可运行使用的特征,换言之,就是把一个大项目分为多个相互联系, 但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 2、敏捷开发优缺点: 特点: 1、能适应快速的客户需求变化,快速的交付,注重与客户的沟通。最优先要做的是通过尽早的、 持续的交付有价值的软件,把项目拆分成各个小的子项目,快速开发快速交付,有问题及时调整, 适合高风睑项目。 2、交付周期短,交付的时间间隔越短越好,一周一个迭送代,甚至有时候一周多个选代, 不过每个选代版本的需求不会太多,注重项目持续选交付。 3、整个项目开发期间,业务人员和开发人员必须天天都在一起工作,团队规模不能太大, 团队间强调面对面的交谈。 4、更关注可交付可以使用的软件,而非文档。 5、对团队技术要求高,能快速适应客户对需求的变化。 6、敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发,另外, 较短的迭代周期使团队成员能迅速进入开发状态。 *优点: 1、敏捷开发的高适应性,以人为本的特性,适应客户的更快需求变化,更快的交付成果。 2.更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。 缺点: 1、由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交 接的过程中出现很大的困难。 2.特别项目存在新手比较多时,老员工比较累.(对开发团队人员的技木要求高) 3、敏捷开发流程图:
4.14 你这个项目做了多久? 你这个项目现在的用户里有多少? 活跃量多少?¶
时间根据简历来 比如:一年时间,金融项目:100W用户2W活跃用户