小猪老师面试

一个需求,两个开发,一个运维,3个测试

项目上线后出现Bug:

首先项目组应该进行快速的响应并处理,首先应该积极协助开发重现bug定位问题。如果是严重问题的话需要更新版本。如果是不严重问题的话可以放到下个迭代版本中进行处理 接下来应该进行总结和反思bug出现的原因以及规避的方案。避免下次出现同样的问题。 常见线上bug出现的原因以及规避方案: 1.需求规格不明确,用户不可控的使用场景,导致漏测。增加测试用例 2.需求规格变更,测试用例未及时更新 3.测试时间不充足,导致一些次要功能点在测试过程中被忽略。规划测试时间,严格按照时间节点完成测试工作 4.测试环境或数据受限,导致测试不到位。可以进行一些mock测试,或是在真实环境下覆盖测试场景 5.开发修复bug 引发的bug。明确测试范围,尤其是代码修改的部分,另外在回归测试的时候,主流程是必须回归的,必须要去进行一个完成的流程

软件测试计划、方案:

我虽然没有自己编写过。但是有了解编写软件测试计划的一些内容和方法准则。目前常用的是5W1H准则。 why 是指软件测试的目标是什么。比如是新功能的测试,还是老功能的回归测试呢还是bug的验证。 what 是指测试什么,涵盖测试的范围,比如只做功能测试,安全测试,针对的是性能测试等等。 when 主要是对测试进度上的安排,如开始时间结束时间,什么时候开始编写和执行测试用例,什么时候完成等。 who 是对人员的安排和设备的分配,人员的安排包括人员的档期,工程师什么时候有时间,设备的配置像服务器,测试工具等 where 是指测试环境的问题,测试版本的问题,硬件设备的问题,软件配置的问题,还有测试的场所地点等 how 指解决如何去测的问题 :是对测试策略的拟定

软件测试的流程:

软件测试的流程目前常用的有两个模型。一个是传统的W模型。 这种就是开发V模型,测试V模型。主要流程是用户需求-需求分析-概要设计-详细设计-编码-集成-实施-交付 对应测试就是验收测试设计——系统测试设计——集成测设计——单元测试设计——单元测试——集成测试——系统测试——验收测试 开发那边早期做需求,做需求评审对应测试就是系统测试设计,

首先要做的就是参与需求评审,从中理解需求,进而分析发现需求中存在的问题,提交bug,预防缺陷,因为越早发现bug修复成本越低。 接下来就是测试leader测试计划的编写和测试人员测试用例的设计。

如果版本发布了,那首先我们要进行一个冒烟测试,看软件的主要功能是否正常实现,主要业务流程是否走通,是否符合进行大规模测试的前提。 接下来我们再进行新功能的测试和bug的提交以及缺陷的跟踪管理,直到该bug被解决。 最后我会在进行bug 的归纳的总结,对于其中通用型的问题我记录,形成自己的一个checklist,以便下次出现同等问题的时候可以直接调用,提高工作效率。

还有一个就是敏捷开发模型,它的特点就是快速迭代,可以用小步快跑来形容。我理解的就是敏捷模型也是以传统模型为原型基础,可以把传统模型比作是作为一个大的版本,而敏捷则是把一个大的版本切割为多个小的版本。每个小版本作为一个周期,每个周期里面做几个功能,做完之后就交付。

软件测试用例的设计:考察测试用例设计的方法

首先的话从需求出发,导入需求,可以根据需求文档、用户故事、环境作为用例依据。 第二步的话就是从软件的功能方面来开展。针对这方面的话,我会从以下几个点来着手:1.先考虑这个软件的特性,了解这个系统主要是涉及哪个领域。 2.了解了系统的特性之后呢,就可以从中分析出这个系统的用户角色有哪些,3. 然后再结合系统特性和用户两个方面分析用户主要用这个系统来做什么。再由做什么引出用户如何去做,会涉及哪些操作,从中就可以梳理出一个大致的业务流程以及核心功能模块。这样由面到点,层层梳理下来,就可以得出usercase,在整理测试点的数据的时候就会用到一些常用的测试方法,如等价类,边界值。

整理完功能相关的用例后,接下来就要考虑非功能相关的一些情况。比如UI界面,兼容性,易用

软件缺陷管理:考察bug的处理流程,如何确认bug

我们公司bug管理主要是通过禅道来进行管理的.我具体的工作是这样的:我们测试当中发现预期结果与实际结果不匹配的时候,先定为疑点,然后对这个疑点进行确认与分析,看到底是不是bug,避免Bug提交错。确认的话主要从这几个方面去分析,看我的测试版本有没有问题,测试数据有没有问题,有没有什么特别的操作等,确保bug可以复现后,在提交之前还要在系统查看是否有人已经提交过该bug,避免bug重复提交。然后就是提交bug,然后就是跟进bug,查看bug的状态,对bug进行跟踪管理,bug被修改后再根据修改记录进行返测,直到bug得到解决,然后关闭bug。 此外,如果有时间的话,我会再对bug产品的原因进行一个分析,看看这个bug 产品的原因是什么,是在需求阶段引入的呢还是在开发阶段引入的。对于一些通用型的公共型的问题进行归纳总结,避免下次再出现同样的问题,提高工作效率。

bug定位与分析:

考察点:有没有什么印象深刻的bug?你发现了bug会怎么办?你提交的bug 开发认为不是bug怎么办?一天能提交多少个bug?你在提交bug 的时候用到了什么工具? 1.首先要确认是bug,测试当中发现预期结果与实际结果不匹配的时候,先定为疑点,然后依据需求文档对这个疑点进行确认与分析,看测试版本有没有问题,测试数据有没有问题,有没有什么特别的操作啊,网络环境有没有问题等,确保bug可以复现,和开发沟通,确认这是一个bug。 2.定位bug:它是不是问题,它是什么问题,问题出在哪里

  • 通过控制变量法,排除法
  • 服务器日志log 3.到系统bug库,通过关键字搜索查看,之前有没有同事提交过了此bug 4.提交bug 5.跟踪bug状态

bug验证:分析bug出现的原因 回归测试:修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误 测试报告:

  • 1.测试设计:写了多少测试用例,用例覆盖了哪些方面,覆盖率达到多少,哪些功能点没有覆盖到。
  • 2.执行情况:
  • 3.bug情况:有多少bug,修了没有,状态怎么样
  • 4.项目质量描述:测完之后,整体给一个评估(测了多长时间,测了多少功能,主要功能情况有没有什么bug,问题最多的在哪里,问题最少的在哪里)

总结:

最后的问题:

1.咱们公司软件测试人员的组织架构是怎样的? 2.咱们公司软件测试的人员如何分工的?几个人做专项,安全,性能,接口 3.辛苦您花费这么多时间来进行这次的约谈,请问您对我这次的整体印象怎么样?可以对我表现不足的地方提供一些建议吗?

1、你是如何快速的熟悉-一个项目?

新项目和已经开展了一段时间的项目

  • S:当我加入项目组的时候,项目已经开展了一段时间的测试了,项目需求等文档不全面
  • T:要尽快熟悉项目的业务流程,并且开展系统测试
  • A: 1、把能找到的文档都收集起来,快速地过-遍,对产品的需求有个大概的了解 2、将自己转变为一名用户,以用户的思维和角度去使用本软件,在使用过程当中,提出疑问,并且找项目模块的开发或同事进行沟通。梳理用户核心场景,并关注各类异常的情况。 3、查看之前的测试用例,以便对当前系统有更深入的理解 4、查看之前的bug,以便对当前系统的缺陷分布有理解和掌握 5、尽早和开发交流,对于后续版本的需求分析和评审持续关注和参与 6、对于版本已有功能开展回归测试,对于新功能开展测试设计等。
  • R:我在1个月内就上手了项目的测试,融入整个项目团队。

提过bug吗?

提过,我是基于优先级和风险对当前项目进行测试,在测试过程当中,按照前面的优先级进行测试,这样可以优先发现系统严重和紧急的bug,一旦发现不过,我通常会记录当前的测试环境,系统截图,复现步骤,如果功能复杂,会及时联系开发,保留环境。并且提交到bug管理系统,跟踪直到问题得到 解决。

写过用例吗?

写过,我是根据用户场景来设计编写用例的,因为我测试的系统挺复杂的,使用用户场景方法设计的化,可以优先保障用户最关系,最频繁使用的功能不会出错,在时间充裕的条件下,对于关键的功能点和操作输入相关的,进行各种异常情形的测试。当完成了功能性用例的编写后,会进一步考虑非功能性,比如:兼容性、可靠性等的测试用例设计与编写。

项目的业务流程

项目相关:

您好,我叫史小娟,15年毕业,毕业后在深圳通拓科技从事客服QC工作。从2021年开始在西安通平网络科技从事软件测试工程师。之前参与的是一个eBay crm系统。这个系统是我们公司基于跨境电商B2C eBay平台的特性自主研发的一款专门用于eBay客服使用的web系统。客服可以通过这个系统查询,回复,站内信和平台消息,处理平台各大纠纷以及跟进用户评价。在这项目我主要负责消息、feedback以及纠纷这几个模块的用例设计以及功能测试。通常会用到fiddler 以及阐道缺陷管理工具

1.项目介绍:eBay CRM客服系统项目是属于电商领域为海外顾客提供B2C的跨境购物网站,这个项目是基于Linux+Nginx+MySQL+java环境下的。部署在阿里云ECS上面的。这个项目主要分为XXX个模块,我在这个项目担任XXX模块的功能测试。

2.定量问题:你一天平均执行多少用例、你一天提交多少bug、一个版本测试几周、一个测试团队多少人、测试覆盖率多少、平均bug修复时间多少。解题思路:不一定:定量

一天平均执行多少用例: 这个的话不一样,主要是要根据项目,系统的复杂度,还有版本以及用例的难度来,通常情况下功能简单的用例我大概执行50条。

一天平均执行多少bug: 这个也不一定,主要是要看bug的复杂度,正常情况下如果是版本初期的话问题比较多一些,每天提十来个bug,到后期的话,有时候一天可能一个bug都提不出来,因为到后期系统测试确实没有什么问题,提不了什么bug了。有的时候一天可能就提一个bug,因为我要去查看需求,去分析,我怕bug提错,比较谨慎一些,所以可能用的时间会稍微久一点。

web测试和app测试的区别

专项测试:

例如,App的电量测试、弱网测试、安装卸载、升级、中断测试、网络切换测试、访问权限测试以及用户体验测试等等。

安装、卸载、更新: Web测试是基于浏览器的所以不必考虑这些。而App是客户端的,则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件,更新的强制更新与非强制更新、增量包更新、断点续传、弱网,卸载后删除App相关的文件等等。

安装、更新、卸载需要考虑在不同的手机,不同系统版本上安装,从不同渠道进行安装,安装的时候出现异常,比如关机,断网,恢复后能不能正常安装,安装的时候内存不足,安装的时候手动取消后再安装,运行时覆盖安装。卸载需要考虑正常卸载,运行app时卸载,卸载时关机,卸载之后遗留数据检查等。app升级需要考虑临近版本升级,夸版本升级,还有不同渠道的升级,升级提醒成功。

功能测试:

在流程和功能测试上是没有区别的,系统测试和一些细节可能会不一样。Web和App的区别: Web项目,一般都是B/S架构,基于浏览器的,而App则是C/S的,必须要有客户端。在系统测试的时候就会产生区别了。 首先从系统架构来看的话,Web测试只要更新了服务器端,客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是App端是不能够保证完全一致的,除非用户更新客户端。如果是App下修改了服务端,意味着客户端用户所使用的核心版本都需要进行回归测试一遍

兼容性:

首先得话就是兼容性,Web是基于浏览器的,一般还是以浏览器为主,兼容性主要是考虑不同内核的浏览器为主,像谷歌,火狐,IE,苹果。APP的兼容性除了要考虑 分辨率:需要覆盖市面上主流设备的分辨率以及屏幕尺寸 屏幕尺寸 操作系统,像安卓和ios。 硬件设备:覆盖主流手机厂家及各种型号的产品。 网络:不同网络制式运营商下面去测试app是否能够正常运行。

性能测试:

Web页面可能只会关注响应时间,而App则还需要关心流量、电量、CPU、GPU、Memory这些了。

界面操作:

App产品的用户都是使用的触摸屏手机,所以测试的时候还要注意手势,横竖屏切换,多点触控,事件触发区域等测试。

ch14
JSRUN前端笔记, 是针对前端工程师开放的一个笔记分享平台,是前端工程师记录重点、分享经验的一个笔记本。JSRUN前端采用的 MarkDown 语法 (极客专用语法), 这里属于IT工程师。