1、黑盒测试、白盒测试、灰盒测试的区别黑盒测试黑盒测试就是不看程序源代码根据需求文档进行功能测试验证输入输出是否符合预期结果常用的方法有等价类、边界值、场景法白盒测试白盒测试也称为结构测试根据代码内部逻辑设计测试用例检查代码有没有漏洞、逻辑错误常用方法有代码检查法、逻辑覆盖法、基本路径测试等灰盒测试介于黑盒测试和白盒测试之间不关注前端页面源码和底层代码实现主要围绕接口和数据库开展测试。测试时通过调用接口传入参数校验接口返回数据同时核对数据库落地数据是否正确。常用于接口测试和集成测试。2、单元测试–集成测试–系统测试–验收测试参考文章https://blog.csdn.net/qq_41539778/article/details/131087735https://www.cnblogs.com/R-bear/p/17786698.html单元测试就是测单个函数、单个方法白盒测试开发自测代码集成测试模块和模块之间靠接口传数据集成测试主要就是测接口大多数基于灰盒测试系统测试全模块拼好业务功能测试基于黑盒测试方法。验收测试是以用户为主的测试软件开发人员和质量保证人员也应参加由用户参加设计测试用例使用用户界面输入测试数据并分析测试的输出结果。3、如何定位前后端bug参考文章https://blog.csdn.net/weixin_40772077/article/details/1380487781、前后端bug特点前端bug界面相关、布局相关、兼容性相关、交互相关后端bug数据相关、安全性下相关、逻辑相关、性能相关2、前后端bug区分如果是抓不到请求或者是请求参数有误–则是前端bug如果抓到请求并且请求正确但是没有响应或者相应错误 --则是后端bug如果抓包有响应并且响应正确但是页面显示报错 --则是前后bug3、后端bug定位查看报错日志通过日志进行分析问题点查看数据库确认数据是否正确查看缓存是否正确4、B/S架构和C/S架构参考文章https://blog.csdn.net/Zhang5801/article/details/104416812B/S架构全称Browser/Server架构也就是浏览器/服务器结构将应用程序的核心功能和数据处理逻辑放在服务器端用户则通过浏览器来访问和使用这些功能此时浏览器充当了客户端。C/S架构全程Client/Server架构即客户端/服务器结构App安装在手机上就是一个客户端它向后台服务器请求数据、提交信息。比如电脑版 QQ、桌面端进销存软件、PC 客户端游戏软件安装在本地设备负责页面展示 大部分业务逻辑胖客户端大量业务代码、页面渲染逻辑全写在客户端安装包里面APP / 桌面程序体积大客户端既要画界面又要算业务规则还要拼接 SQL 和数据库打交道C/S 是两层客户端服务器架构分为客户端、服务端服务端分数据库直连、Socket 通信两种属于胖客户端架构绝大多数业务逻辑、界面都在客户端实现客户端通过 SQL 或 Socket 和服务端交互数据。python中数据类型——可变/不可变变量的类型可变、不可变可变表示内存中的数据可以修改列表list字典dict集合set不可变表示内存中的数据不允许被修改数字类型int、float、bool字符串str元组tuple集合和元组的区别元组不可变、有序、可重复、支持索引集合可变、无序、自动去重、不支持索引TCP和UDP的主要区别是什么区别TCP面向连接、可靠、有序、有流量控制UDP无连接、不可靠、无序、但效率高。TCP面向连接、可靠、有序、较慢用在需要数据完整、准确、不丢失的地方网页浏览HTTP/HTTPS网页内容必须完整加载不能缺图片或文字。电子邮件SMTP/POP3/IMAP邮件内容不能丢。文件传输FTP、SFTP文件少一个字节都可能损坏。数据库连接MySQL、PostgreSQL等查询结果必须准确。远程登录SSH、Telnet每一条命令都要正确执行。微信/QQ的文字聊天、文件发送消息不能丢顺序不能乱。UDP无连接、不可靠、无序、但速度快、延迟低用在允许偶尔丢包、但要求实时性高的场景实时音视频通话微信语音/视频、Zoom、Skype偶尔卡一下或雪花点可接受但延迟必须低。直播抖音、B站直播、斗鱼丢掉几帧画面观众基本无感但卡顿会导致体验差。在线游戏FPS、MOBA类如《英雄联盟》《绝地求生》玩家位置、射击等操作必须快速送达偶尔丢一个位置包可以预测补偿。DNS域名解析查询一个域名发一个UDP包如果没回应就重试简单快速。SNMP简单网络管理协议监控设备状态允许少量丢失。DHCP动态获取IP地址电脑开机时广播请求IP用UDP效率高。补充有些软件会两者结合微信/QQ文字消息用TCP可靠语音/视频通话用UDP实时。BT下载控制信息用TCP实际数据传输有时用UDP如µTP协议。TCP要完整不着急网页、邮件、文件。UDP要快不怕丢语音、视频、游戏。TCP/IP协议参考文章https://blog.csdn.net/weixin_53186633/article/details/120514627TCP/IP协议主要由网络层的IP协议 和 传输层的TCP协议组成 。TCP负责发现传输的问题一有问题就发出信号要求重新传输直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台联网设备规定一个地址。TCP协议TCP协议是传输控制协议工作在传输层。提供面向链接的可靠的传输服务三次握手四次挥手面向链接数据传输之前客户端与服务器之间要建立连接才可以传输数据可靠的数据传输是有序的要对数据进行校验数据不会丢失UDP协议UDP协议用户数据报协议提供的是不可靠的面向无连接的传输服务只有数据的发送方和接收方面向无连接传输方和接收方不需要建立连接在传输数据之前没有明确的连接链路即不是所有的数据都是通过一条链路传输不可靠因为数据的传输不是通过一条链路完成的因此接收方接收的数据不一定按照发送数据的顺序接收这样就可能造成数据包的丢失传输方和接收方不需要建立连接用于对数据实时性和安全性不高的场合。可以用于视频会议。5、项目临上线发现影响体验的bug开发没时间、PM不在怎么办答案参考https://blog.csdn.net/qd_lifeng/article/details/1469851711.立即确认和复现bug记录详细的信息2.评估bug的优先级和严重性影响核心功能如无法发送消息vs 轻微体验如按钮颜色不对。若致命bug必须推迟上线。bug严重级 - 致命级如崩溃、数据丢失、核心功能失效必须修复可能需延迟上线。 - 严重级非核心功能异常评估修复时间和风险。 - 一般级UI问题、边缘场景权衡是否紧急修复或后续处理。 - 风险评估修复该BUG是否会引入新风险是否有临时规避方案3.同步信息如果产品经理不在可以找产品或者上级进行沟通开发没有时间如果对bug评估后需要紧急修复的就和开发沟通是否能协调时间先修复bug4.配合修复与验证开发修复完bug之后对bug进行回归测试确保bug完全修复5.事后复盘与改进为什么会出现这种情况是否用测覆盖不全6.项目上线前3天每天写一篇风控报告怎么写风控报告 识别质量风险 给出应对措施 跟踪风险状态。我会按时间递进来写。第一天风险识别与基线报告标题《XX项目上线前72小时质量风控报告 v1》内容当前bug情况严重bug数量、待修复列表、解决率趋势测试完成度功能覆盖率、场景覆盖率、自动化通过率、性能测试结论高风险点比如支付模块改动、第三方SDK升级、弱网场景未覆盖建议措施冻结非紧急需求合入对高风险模块安排专人专项回归准备降级/回滚预案风险等级高/中/低给出评估依据第二天风险状态更新与应对进展新增前一天遗留bug的修复情况新增bug数量重点回归结果高风险模块是否通过新发现风险比如性能压测发现某个接口在峰值下延迟超标调整措施增加灰度范围、建议后端扩容给决策者PM/技术负责人的建议是否如期上线或需要部分功能降级第三天最终上线前风险评估内容所有阻塞级bug已清零已知遗留低概率或轻微体验问题清单附上原因和用户影响评估线上监控方案是否就绪关键指标、报警阈值、日志紧急联系人名单、回滚方案确认最终结论可上线 / 有风险但可控需伴随灰度 / 建议延期上线后24小时内的跟进计划关键每天报告要简洁、有数据、有结论、有可执行的下一步而不是流水账。7. 从用户角度测试抖音视频播放体验、交流互动、内容推送、性能与资源流量、电量、无障碍、关爱模式8.如果发现领导给的流程不太合理你会怎么办我会先确认自己是否完全理解了流程背景。如果确实不合理就基于数据评估问题如耗时、效率、质量影响准备对比分析和改进建议找合适时机与领导沟通先肯定初衷再提议小范围试运行。如果领导坚持我会先执行同时持续记录痛点后续再用数据推动优化并在自己权限内做局部微调。9.了解过自动化测试吗了解PO模式吗了解并且在web项目测试中落地实现了PO模式是UI自动化测试中的一种设计模式即页面对象设计模式它的核心思想是将页面封装成类页面上的元素定位和操作方法都封装在该类中。这样做的好处是可维护性高页面元素一旦发生改变只需修改对应的page类复用性强多个用例可以共享同一个页面的操作方法可读性好测试用例只调用方法清晰易懂10.测过APP吗APP测试和web测试的区别简单测过区别在于框架不同APP使用的是C/S框架、WEB使用的是B/S框架传输数据不同APP前后端交互的数据格式是以json为主的而WEB前后端交互的数据格式为JSON/HTML等都有测试范围不同app测试还有专项测试安装卸载更新、手机型号、版本兼容性测试、push消息推送、交叉事件、用户体验等、web测试还有浏览器兼容性测试、易用性测试等11.一个流程如何去设计测试用例以账号密码登录流程为例简单说明梳理流程打开登录页→输入账号密码→点击登录→跳转首页分支清空输入、输错信息、网络断开、点击返回等。拆分节点账号输入框、密码输入框、登录按钮、返回按钮。设计用例正向输入正确账号密码正常登录反向账号 / 密码为空、输入超长字符、错误账号密码流程异常点击登录中途断网、输入一半返回上一页、连续多次点击登录按钮。12.如何处理临时新增的紧急需求第一先快速对接产品、开发吃透新增需求明确改动点、关联模块、预期上线时间评估测试范围和工作量。第二梳理自己手上正在进行的任务分清优先级和组长沟通协调把非紧急任务延后集中精力处理新需求。第三测试时抓重点优先测核心功能、改动点以及受影响的关联模块用例侧重主流程和高频异常精简冗余用例提升效率。第四测试完成后及时同步结果若时间紧张会和团队确认风险、做好备注。上线之后我也会重点做线上巡检一旦发现问题立刻跟进修复。13.bug开发没有进行修复但是着急上线怎么和开发沟通先明确bug等级和影响面。然后找开发沟通用事实说话“这个bug影响用户支付成功率约5%如果不修上线后预计每天造成xxx单失败。”给出折中方案能否加配置开关临时屏蔽该功能或者后端hotfix或者在前端加提示/降级方案确认时间问他最快多久能修如果1小时内能修我等他再回归。风险共担如果实在不修我会要求开发签字确认风险并在上线报告中注明已知问题同时建议灰度发布、加强监控。沟通时保持尊重目标是解决问题不是指责。14.需求怎么划定测试范围先精读需求明确新增、修改的功能点再顺着业务和数据流向找出联动的模块、接口。区分必测、选测和无关模块最后和产品、开发确认范围避免漏测或重复测试。15.偶发性bug怎么处理记录现场立刻截屏、录屏、抓日志、记下操作步骤和环境信息时间、网络、设备、账号。尝试复现大概定位范围、记录出现频次并评估重要程度提bug清晰描述bug信息可以找开发查看日志记录分析bug信息再次出现时保留现场让开发进行解决如果在上线前无法解决需要想项目负责人抛出风险评估之后决定是否上线如果决定上线那么将风险点在测试报告上详细说明并跟踪手机上线后的情况信息如果决定先修复再上线那么提交bug后指配给开发进行修复16. HTTP中4开头的状态码和5开头的状态码介绍4xx请求信息错误400请求参数错误401登录失效/未登录403登录了但是没有权限访问404资源不存在405请求方式错误预期是get方式实际用成了post429请求过多5xx服务器端错误500通用服务器错误例如后端代码出错502网关错误503服务不可用例如过载、维护504网关超时17.Linux怎么修改权限777是什么意思使用chmod命令777分别代表文件所有者、用户组、其他用户的权限7表示4读r、2写w、1执行x18.selenium元素定位方式ID、NAME、CSS_SELECTOR、LINK_TEXT、CLASS_NAME、XPATHxpath定位方法绝对路径相对路径属性//标签[属性‘值’]文本匹配//*[text()‘内容’]19.使用id定位无法定位到元素可能的问题xpath定位页面修改后无法成功定位如何解决id定位失败没有切换iframe页面未渲染完成有遮罩层点击后toast弹窗遮挡id是动态生成的每次刷新发生变化xpath定位避免使用绝对路径使用相对xpath例如//div[class‘content’]使用更稳定的属性组合使用css_selector代替xpath通常更稳定20.缺陷提交到平台之后是有哪几种状态修改为fixed之后在确认的时候发现还是有bug那这时候状态要怎么修改缺陷提交后常规流转状态主要有新建、指派、修复中、已修复、重新打开、关闭还有延期、作废这类辅助状态。当开发修复完成将 bug 状态改为 Fixed 后我会执行复测。如果复测发现问题依然存在不会直接关闭而是把缺陷状态重新打开详细备注复测情况和问题现象再重新指派给开发让其继续处理。等后续彻底修复、复测通过后再把状态改为关闭。
知识点/面试题总结
1、黑盒测试、白盒测试、灰盒测试的区别黑盒测试黑盒测试就是不看程序源代码根据需求文档进行功能测试验证输入输出是否符合预期结果常用的方法有等价类、边界值、场景法白盒测试白盒测试也称为结构测试根据代码内部逻辑设计测试用例检查代码有没有漏洞、逻辑错误常用方法有代码检查法、逻辑覆盖法、基本路径测试等灰盒测试介于黑盒测试和白盒测试之间不关注前端页面源码和底层代码实现主要围绕接口和数据库开展测试。测试时通过调用接口传入参数校验接口返回数据同时核对数据库落地数据是否正确。常用于接口测试和集成测试。2、单元测试–集成测试–系统测试–验收测试参考文章https://blog.csdn.net/qq_41539778/article/details/131087735https://www.cnblogs.com/R-bear/p/17786698.html单元测试就是测单个函数、单个方法白盒测试开发自测代码集成测试模块和模块之间靠接口传数据集成测试主要就是测接口大多数基于灰盒测试系统测试全模块拼好业务功能测试基于黑盒测试方法。验收测试是以用户为主的测试软件开发人员和质量保证人员也应参加由用户参加设计测试用例使用用户界面输入测试数据并分析测试的输出结果。3、如何定位前后端bug参考文章https://blog.csdn.net/weixin_40772077/article/details/1380487781、前后端bug特点前端bug界面相关、布局相关、兼容性相关、交互相关后端bug数据相关、安全性下相关、逻辑相关、性能相关2、前后端bug区分如果是抓不到请求或者是请求参数有误–则是前端bug如果抓到请求并且请求正确但是没有响应或者相应错误 --则是后端bug如果抓包有响应并且响应正确但是页面显示报错 --则是前后bug3、后端bug定位查看报错日志通过日志进行分析问题点查看数据库确认数据是否正确查看缓存是否正确4、B/S架构和C/S架构参考文章https://blog.csdn.net/Zhang5801/article/details/104416812B/S架构全称Browser/Server架构也就是浏览器/服务器结构将应用程序的核心功能和数据处理逻辑放在服务器端用户则通过浏览器来访问和使用这些功能此时浏览器充当了客户端。C/S架构全程Client/Server架构即客户端/服务器结构App安装在手机上就是一个客户端它向后台服务器请求数据、提交信息。比如电脑版 QQ、桌面端进销存软件、PC 客户端游戏软件安装在本地设备负责页面展示 大部分业务逻辑胖客户端大量业务代码、页面渲染逻辑全写在客户端安装包里面APP / 桌面程序体积大客户端既要画界面又要算业务规则还要拼接 SQL 和数据库打交道C/S 是两层客户端服务器架构分为客户端、服务端服务端分数据库直连、Socket 通信两种属于胖客户端架构绝大多数业务逻辑、界面都在客户端实现客户端通过 SQL 或 Socket 和服务端交互数据。python中数据类型——可变/不可变变量的类型可变、不可变可变表示内存中的数据可以修改列表list字典dict集合set不可变表示内存中的数据不允许被修改数字类型int、float、bool字符串str元组tuple集合和元组的区别元组不可变、有序、可重复、支持索引集合可变、无序、自动去重、不支持索引TCP和UDP的主要区别是什么区别TCP面向连接、可靠、有序、有流量控制UDP无连接、不可靠、无序、但效率高。TCP面向连接、可靠、有序、较慢用在需要数据完整、准确、不丢失的地方网页浏览HTTP/HTTPS网页内容必须完整加载不能缺图片或文字。电子邮件SMTP/POP3/IMAP邮件内容不能丢。文件传输FTP、SFTP文件少一个字节都可能损坏。数据库连接MySQL、PostgreSQL等查询结果必须准确。远程登录SSH、Telnet每一条命令都要正确执行。微信/QQ的文字聊天、文件发送消息不能丢顺序不能乱。UDP无连接、不可靠、无序、但速度快、延迟低用在允许偶尔丢包、但要求实时性高的场景实时音视频通话微信语音/视频、Zoom、Skype偶尔卡一下或雪花点可接受但延迟必须低。直播抖音、B站直播、斗鱼丢掉几帧画面观众基本无感但卡顿会导致体验差。在线游戏FPS、MOBA类如《英雄联盟》《绝地求生》玩家位置、射击等操作必须快速送达偶尔丢一个位置包可以预测补偿。DNS域名解析查询一个域名发一个UDP包如果没回应就重试简单快速。SNMP简单网络管理协议监控设备状态允许少量丢失。DHCP动态获取IP地址电脑开机时广播请求IP用UDP效率高。补充有些软件会两者结合微信/QQ文字消息用TCP可靠语音/视频通话用UDP实时。BT下载控制信息用TCP实际数据传输有时用UDP如µTP协议。TCP要完整不着急网页、邮件、文件。UDP要快不怕丢语音、视频、游戏。TCP/IP协议参考文章https://blog.csdn.net/weixin_53186633/article/details/120514627TCP/IP协议主要由网络层的IP协议 和 传输层的TCP协议组成 。TCP负责发现传输的问题一有问题就发出信号要求重新传输直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台联网设备规定一个地址。TCP协议TCP协议是传输控制协议工作在传输层。提供面向链接的可靠的传输服务三次握手四次挥手面向链接数据传输之前客户端与服务器之间要建立连接才可以传输数据可靠的数据传输是有序的要对数据进行校验数据不会丢失UDP协议UDP协议用户数据报协议提供的是不可靠的面向无连接的传输服务只有数据的发送方和接收方面向无连接传输方和接收方不需要建立连接在传输数据之前没有明确的连接链路即不是所有的数据都是通过一条链路传输不可靠因为数据的传输不是通过一条链路完成的因此接收方接收的数据不一定按照发送数据的顺序接收这样就可能造成数据包的丢失传输方和接收方不需要建立连接用于对数据实时性和安全性不高的场合。可以用于视频会议。5、项目临上线发现影响体验的bug开发没时间、PM不在怎么办答案参考https://blog.csdn.net/qd_lifeng/article/details/1469851711.立即确认和复现bug记录详细的信息2.评估bug的优先级和严重性影响核心功能如无法发送消息vs 轻微体验如按钮颜色不对。若致命bug必须推迟上线。bug严重级 - 致命级如崩溃、数据丢失、核心功能失效必须修复可能需延迟上线。 - 严重级非核心功能异常评估修复时间和风险。 - 一般级UI问题、边缘场景权衡是否紧急修复或后续处理。 - 风险评估修复该BUG是否会引入新风险是否有临时规避方案3.同步信息如果产品经理不在可以找产品或者上级进行沟通开发没有时间如果对bug评估后需要紧急修复的就和开发沟通是否能协调时间先修复bug4.配合修复与验证开发修复完bug之后对bug进行回归测试确保bug完全修复5.事后复盘与改进为什么会出现这种情况是否用测覆盖不全6.项目上线前3天每天写一篇风控报告怎么写风控报告 识别质量风险 给出应对措施 跟踪风险状态。我会按时间递进来写。第一天风险识别与基线报告标题《XX项目上线前72小时质量风控报告 v1》内容当前bug情况严重bug数量、待修复列表、解决率趋势测试完成度功能覆盖率、场景覆盖率、自动化通过率、性能测试结论高风险点比如支付模块改动、第三方SDK升级、弱网场景未覆盖建议措施冻结非紧急需求合入对高风险模块安排专人专项回归准备降级/回滚预案风险等级高/中/低给出评估依据第二天风险状态更新与应对进展新增前一天遗留bug的修复情况新增bug数量重点回归结果高风险模块是否通过新发现风险比如性能压测发现某个接口在峰值下延迟超标调整措施增加灰度范围、建议后端扩容给决策者PM/技术负责人的建议是否如期上线或需要部分功能降级第三天最终上线前风险评估内容所有阻塞级bug已清零已知遗留低概率或轻微体验问题清单附上原因和用户影响评估线上监控方案是否就绪关键指标、报警阈值、日志紧急联系人名单、回滚方案确认最终结论可上线 / 有风险但可控需伴随灰度 / 建议延期上线后24小时内的跟进计划关键每天报告要简洁、有数据、有结论、有可执行的下一步而不是流水账。7. 从用户角度测试抖音视频播放体验、交流互动、内容推送、性能与资源流量、电量、无障碍、关爱模式8.如果发现领导给的流程不太合理你会怎么办我会先确认自己是否完全理解了流程背景。如果确实不合理就基于数据评估问题如耗时、效率、质量影响准备对比分析和改进建议找合适时机与领导沟通先肯定初衷再提议小范围试运行。如果领导坚持我会先执行同时持续记录痛点后续再用数据推动优化并在自己权限内做局部微调。9.了解过自动化测试吗了解PO模式吗了解并且在web项目测试中落地实现了PO模式是UI自动化测试中的一种设计模式即页面对象设计模式它的核心思想是将页面封装成类页面上的元素定位和操作方法都封装在该类中。这样做的好处是可维护性高页面元素一旦发生改变只需修改对应的page类复用性强多个用例可以共享同一个页面的操作方法可读性好测试用例只调用方法清晰易懂10.测过APP吗APP测试和web测试的区别简单测过区别在于框架不同APP使用的是C/S框架、WEB使用的是B/S框架传输数据不同APP前后端交互的数据格式是以json为主的而WEB前后端交互的数据格式为JSON/HTML等都有测试范围不同app测试还有专项测试安装卸载更新、手机型号、版本兼容性测试、push消息推送、交叉事件、用户体验等、web测试还有浏览器兼容性测试、易用性测试等11.一个流程如何去设计测试用例以账号密码登录流程为例简单说明梳理流程打开登录页→输入账号密码→点击登录→跳转首页分支清空输入、输错信息、网络断开、点击返回等。拆分节点账号输入框、密码输入框、登录按钮、返回按钮。设计用例正向输入正确账号密码正常登录反向账号 / 密码为空、输入超长字符、错误账号密码流程异常点击登录中途断网、输入一半返回上一页、连续多次点击登录按钮。12.如何处理临时新增的紧急需求第一先快速对接产品、开发吃透新增需求明确改动点、关联模块、预期上线时间评估测试范围和工作量。第二梳理自己手上正在进行的任务分清优先级和组长沟通协调把非紧急任务延后集中精力处理新需求。第三测试时抓重点优先测核心功能、改动点以及受影响的关联模块用例侧重主流程和高频异常精简冗余用例提升效率。第四测试完成后及时同步结果若时间紧张会和团队确认风险、做好备注。上线之后我也会重点做线上巡检一旦发现问题立刻跟进修复。13.bug开发没有进行修复但是着急上线怎么和开发沟通先明确bug等级和影响面。然后找开发沟通用事实说话“这个bug影响用户支付成功率约5%如果不修上线后预计每天造成xxx单失败。”给出折中方案能否加配置开关临时屏蔽该功能或者后端hotfix或者在前端加提示/降级方案确认时间问他最快多久能修如果1小时内能修我等他再回归。风险共担如果实在不修我会要求开发签字确认风险并在上线报告中注明已知问题同时建议灰度发布、加强监控。沟通时保持尊重目标是解决问题不是指责。14.需求怎么划定测试范围先精读需求明确新增、修改的功能点再顺着业务和数据流向找出联动的模块、接口。区分必测、选测和无关模块最后和产品、开发确认范围避免漏测或重复测试。15.偶发性bug怎么处理记录现场立刻截屏、录屏、抓日志、记下操作步骤和环境信息时间、网络、设备、账号。尝试复现大概定位范围、记录出现频次并评估重要程度提bug清晰描述bug信息可以找开发查看日志记录分析bug信息再次出现时保留现场让开发进行解决如果在上线前无法解决需要想项目负责人抛出风险评估之后决定是否上线如果决定上线那么将风险点在测试报告上详细说明并跟踪手机上线后的情况信息如果决定先修复再上线那么提交bug后指配给开发进行修复16. HTTP中4开头的状态码和5开头的状态码介绍4xx请求信息错误400请求参数错误401登录失效/未登录403登录了但是没有权限访问404资源不存在405请求方式错误预期是get方式实际用成了post429请求过多5xx服务器端错误500通用服务器错误例如后端代码出错502网关错误503服务不可用例如过载、维护504网关超时17.Linux怎么修改权限777是什么意思使用chmod命令777分别代表文件所有者、用户组、其他用户的权限7表示4读r、2写w、1执行x18.selenium元素定位方式ID、NAME、CSS_SELECTOR、LINK_TEXT、CLASS_NAME、XPATHxpath定位方法绝对路径相对路径属性//标签[属性‘值’]文本匹配//*[text()‘内容’]19.使用id定位无法定位到元素可能的问题xpath定位页面修改后无法成功定位如何解决id定位失败没有切换iframe页面未渲染完成有遮罩层点击后toast弹窗遮挡id是动态生成的每次刷新发生变化xpath定位避免使用绝对路径使用相对xpath例如//div[class‘content’]使用更稳定的属性组合使用css_selector代替xpath通常更稳定20.缺陷提交到平台之后是有哪几种状态修改为fixed之后在确认的时候发现还是有bug那这时候状态要怎么修改缺陷提交后常规流转状态主要有新建、指派、修复中、已修复、重新打开、关闭还有延期、作废这类辅助状态。当开发修复完成将 bug 状态改为 Fixed 后我会执行复测。如果复测发现问题依然存在不会直接关闭而是把缺陷状态重新打开详细备注复测情况和问题现象再重新指派给开发让其继续处理。等后续彻底修复、复测通过后再把状态改为关闭。
