1、在项目中如何保证软件质量?
- 项目质量不仅仅是某个人或某个团队来保障的,而是整个团队一起努力的结果,因此,在公司级别需要 有一个规范的项目流程。
- 产品,保证迭代过程中的产品逻辑,对于可能的兼容,升级做出预判并给出方案
- 架构设计,满足产品表达的同时,保证设计的延续性
- 开发,产品细节的保证,技术方案选择要严谨,考虑兼容,性能,开发完成后要充分自测,严格遵循 开发规范操作
- 测试,验证产品逻辑,站在用户角度对交互设计进行系统验证,尽可能多的使用技术手段保证测试质量
- 运维,制定严谨的上线流程和权限管控,做好生产环境监控报警,出现事故后有应急预案
2、APP测试和web测试有什么区别
(1) 从系统架构来看的话:web端一般都是b/s架构,基于浏览器的,app是c/s架构,是有客户端的。
(2) 兼容性方面:Web是基于浏览器的,所以更倾向于不同浏览器(Chrome、firefox)的兼容;App测试则必须依赖于手机更关注系统版本、分辨率、屏幕尺寸等兼容性问题。
(3) 除了功能测试,APP端还需要额外关注一些专顶的测试,比如弱网测试、中断测试、安装/卸载测 试、流量/电量的测试,移动端性能测试等
3、怎么定位bug是APP端还是服务端的问题
(1)抓包分析,对接口进行抓包分析,如果请求里的参数出现错误,一般都是客户端bug;如果请求正常 而响应是错误的,那就是服务端的bug
(2)日志分析,还可以通过查看客户端/服务端的日志,分析有没有异常的日志信息,从而确定具体原因
4、讲一下你们的测试流程
1> 需求评审和分析
2> 制定测试计划
3> 根据需求文档编写测试用例
4> 测试用例评审
5> 提测后执行冒烟测试
6> 执行第一轮测试,找bug
7> 执行回归测试,验证bug
8> 执行第二轮测试
9> 部署项目到预生产环境
10> 预生产环境测试
11> 发测试报告
12> 项目上线
13> 线上验证(主流程、主功能点的验证)
5、当开发人员说不是 BUG 时,你如何应付
- 开发人员说不是bug,有2种情况:
- 需求没有确定,所以这个时候可以找来产品经理进行确认,需不需要改动,商量确定好后再看要不要改。
- 这种情况不可能发生,所以不需要修改,这个时候可以先尽可能的说出是BUG的依据是什么?如果 被用户发现或出了问题,会有什么不良结果?如果还是不行,那可以给这个问题提出来,跟开发经理和测试经理进行确认。如果最终bug被确定不改那么就要在测试报告里面记录一下,以便以后查阅
6、遇到概率性bug怎么办?
首先需要明确的是,该类bug也是需要提bug的,描述清楚当时操作环境、操作步骡、数据、并提供必要 日志,可备注上可能产生原因。然后耐心一点,运用排除法、错误推测找规律必要时找开发人员一起 定位分析讨论。如果最终仍未解决,那么需要在测试报告中体现,并分析可能造成的影响,大家一起权衡该bug是否可遗留。
7、如何提交一份高质量的缺陷跟踪单
首先要明确,缺陷跟踪单不仅仅是给自己看的,所以高质量的缺陷单,最主要的一条判断标准是,别人一看就懂,标题简洁明了步骤条理清晰。还需考虑缺陷的完备性,比如缺陷等级、所功能模块、版 本、复现步骤、预期结果、实际结果、产生原因、日志截图等。
8、Bug优先级和严重程度如何划分
- 严重(S):需要立即解决的问题,比如:死机、进程无响应、崩溃
- 高(A):软件的主要功能错误,或者引起数据丢失的缺陷
- 中(B):影响软件功能和性能的一般缺陷
- 低(C):对软件的质量影响非常轻微的缺陷,多为建议性或者U1层级的问题
9、做好测试用例设计工作的关键是什么(高频题目)
- 熟悉业务需求和用户使用场景
- 了解本次需求对其他系统的影响
- 了解开发技术实现和数据库设计
- 从不同的维度编写测试用例,功能、性能、安全、兼容等
10、给你一个项目,如何开展测试(低频题目)
- 查找需求说明、项目设计等相关文档,分析需求。
- 制定测试计划,确定测试范围和测试策略。
- 设计测试用例,包括功能、兼容、性能、安全等方面
- 开展测试执行
- 回归测试以及发送测试报告
11、bug的生命周期(高频题目)
- New:新发现的bug,指定给对应的开发
- Open:开发确认bug,并且认为需要进行修改
- Fixed:开发人员进行修改后标识成已修复状态,等待测试人员的回归测试验证
- Rejected:如果开发认为不是Bug,则拒绝修改Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改,并需要给出理由
- Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug
- Reopen:如果经验证Bug仍然存在,则需要重新打开Bug开发人员重新修改
- Later:延期修改(下一个版本修复)
12、测试报告里都包含哪些内容(中频题目)
- 测试范围,测试时间、参与人员、测试策略、BUG数量、上线风险、遗留问题、测试是否通过
13、如何提高用例的覆盖率,减少漏测(高频题目)
1、要根据需求文档来编写用例,确保每条需求都被对应的用例覆盖
2、要充分理解业务,挖掘隐形需求,并编写对应的用例
3、除了正常的业务场景,多考虑一些异常的场景和数据
4、要从多个维度对软件进行测试,功能、性能、安全等各方面来考虑
5、多站在用户的角度去思考问题,模拟用户的使用场景
14.如何确定是不是一个bug(高频题目)
1、看需求文档,是否有明确的要求
2、看下这个问题是否违反了正常人的行为习惯,或者行业的通用规范
3、可以找产品经理或者开发人员沟通确定是否为bug
4、对于无法打成一致的问题,可以组织相关人员开会,共同来决定是否为bug
15、没有需求文档,如何开展测试(高频题目)
- 没有需求文档不代表没有需求。
- 可以找相关人员进行沟通,获取需求,比如产品经理、开发人员可以参考同行业竞品,总结梳理需求可以根据用户的使用习惯和一些行业的规范,来总结一些功能需求
-
总结
如果你对此文有任何疑问,如果你也需要接口项目实战,如果你对软件测试、接口测试、自动化测试、面试经验交流感兴趣欢迎加入我们,加入方式在文章的最后面
自动化测试相关教程推荐:
2023最新自动化测试自学教程新手小白26天入门最详细教程,目前已有300多人通过学习这套教程入职大厂!!_哔哩哔哩_bilibili
2023最新合集Python自动化测试开发框架【全栈/实战/教程】合集精华,学完年薪40W+_哔哩哔哩_bilibili
测试开发相关教程推荐
2023全网最牛,字节测试开发大佬现场教学,从零开始教你成为年薪百万的测试开发工程师_哔哩哔哩_bilibili
postman/jmeter/fiddler测试工具类教程推荐
讲的最详细JMeter接口测试/接口自动化测试项目实战合集教程,学jmeter接口测试一套教程就够了!!_哔哩哔哩_bilibili
2023自学fiddler抓包,请一定要看完【如何1天学会fiddler抓包】的全网最详细视频教程!!_哔哩哔哩_bilibili
2023全网封神,B站讲的最详细的Postman接口测试实战教学,小白都能学会_哔哩哔哩_bilibili
总结:
光学理论是没用的,要学会跟着一起敲,要动手实操,才能将自己的所学运用到实际当中去,这时候可以搞点实战案例来学习。
如果对你有帮助的话,点个赞收个藏,给作者一个鼓励。也方便你下次能够快速查找。
如有不懂还要咨询下方小卡片,博主也希望和志同道合的测试人员一起学习进步
在适当的年龄,选择适当的岗位,尽量去发挥好自己的优势。
我的自动化测试开发之路,一路走来都离不每个阶段的计划,因为自己喜欢规划和总结,
测试开发视频教程、学习笔记领取传送门!!