【面经】2024春招-后端开发工程师3（运营，安全，测开）

本文主要是介绍【面经】2024春招-后端开发工程师3（运营，安全，测开），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

主要是面试前准备的相关材料与网络上的面经，个人不透露面试题目哈～

文章目录

- - 岗位与面经
  - 基础1：测试 & 测开

岗位与面经

1、腾讯云CSIG
星星海实验室2、小鹏汽车
【24届校招】后端研发工程师（销服方向）
广州正式研发 - 后端开发
职位描述
岗位职责：
1、负责集团核心业务系统的软件架构、系统分层、关键构件、接口设计及代码实现，解决系统性能、安全、可靠、稳定性等方面的问题；
2、参与业务梳理、需求分析，做好领域设计和建模；
3、参与互联网化的企业级业务系统创新研究，及系统中技术难点的原因分析和解决。
任职要求：
1、计算机相关/软件工程/信息工程/数学系等相关专业，本科或以上学历，具备一定Java项目实习/实战开发经验。
2、了解Spring MVC、Spring Cloud、Mybatis等开发框架，了解Mysql、Redis、ES和Kafka等中间件，有应用经验者优先。
3、了解分布式、延展性、高可用架构设计，具备高容错、复杂业务场景的系统设计和开发经验者优先；
4、参与如CRM、ERP、OMS和电商系统等系统开发经验者优先；具备一定海外规模系统项目经历者优先；汽车行业经验额外加分。
5、热爱软件开发，追求极致，思路清晰，善于思考，有上进心和很强的学习能力，责任心强，具备良好的团队合作精神。
30多分钟，飞书会议，一点都没准备
没有算法题，主要挖两个项目，八股基本结合着项目问，然后适当拓展，就mysql & redis， ds & cn这些。3、深信服
深信服是一家专注于企业级安全、云计算及IT基础设施的产品和服务供应商，拥有深信服智安全、信服云和深信服新IT三大业务品牌，致力于让每个用户数字化更简单、更安全。
深信服24届校招-测试开发工程师
深信服科技/全职/本科
工作地点：深圳市（80%在深圳）、长沙市
岗位描述：
负责深信服集团母公司旗下虚拟化、云计算、安全、企业级移动应用产品的软件测试和质量建设工作；
在这里，您可以深度参与到工程生产力团队里面，开发平台和工具，让测试工作更轻松，让研发过程更高效；您可以审查代码，发现深层次的逻辑问题，指导白盒测试，帮助软件开发过程持续集成；在这里您可以成为测试开发专家，工具开发专家，自动化测试高手，测试架构师，有胆你就来！
岗位要求：
1、本科及以上学历，专业不限；
2、掌握C/C++/Python/JAVA/PHP/GO/Shell中的一门或多门语言，有基础的编码能力。
3、有较强的思维能力，学习能力。
4、喜欢钻研技术，有广泛的技术视野，具备很强的学习能力和解决问题的能力。
线下

基础1：测试 & 测开

测试理论

1、介绍一下软件测试方法？
- 白盒测试：根据软件内部代码的逻辑结构分析来进行测试。单步调试很好用。测试用例设计方法：逻辑覆盖、循环覆盖、基本路径覆盖、判定覆盖。
  
  缺点：系统庞大时测试开销很大，难以测试所有运行路径。
- 黑盒测试：测试用例设计方法：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试法、场景法。
  - 等价类划分：将全部输入数据合理划分成若干个等价类，在每一个等价类中取一个数据作为输入条件，就可以用少量代表性测试数据取得较好的测试结果。分为有效等价类（合理、有意义的输入数据构成的集合）和无效等价类
  - 边界值分析法：大量错误是发生在输入输出范围的边界上，选定测试用例时应该选取正好等于、刚刚大于、刚刚小于边界值的值作为测试数据，而不是选取等价类中的任意值，作为对等价类划分的补充
  - 错误猜测法：基于经验和直觉推测，列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些情况选择测试用例
  - 因果图法：考虑输入条件之间的相互组合，也考虑输出结果对输入条件的依赖关系。原因即为输入条件或者输入条件的等价类，结果即为输出条件，把因果转换为决策表，为决策表中的每一列设计测试用例。
  - 场景分析法：根据用户场景来模拟用户的操作步骤
  - 大纲法：着眼于需求。将需求转换为大纲的形式，大纲表示为树状结构，在根和叶子节点之间存在唯一路径，大纲为每条路径定义了一个特殊的输入条件集合，用于测试用例。
  - 随机测试法：不考虑任何用例和需求，完全站在用户的角度对产品进行测试
- 动态测试：
  
  实际运行被测程序，输入相应的测试用例，检查运行结果与预期结果的差异，从而验证程序的正确性、有效性和可靠性，并且分析系统运行的效率和健壮性。
- α测试：一个用户在开发环境下的受控测试，模拟实际操作环境
- β测试: 多个用户在实际使用环境下进行的测试，如一些软件的公测
- 冒烟测试：在大规模测试之前，先对软件的基本、核心、主要功能进行测试，节省资源
- 回归测试：开发修正完代码后再回过头来做测试
- 随机测试：跳出思维的限制，没有思想、没有步骤地随机进行测试
- 探索测试：有思想，有步骤地测试一些复杂的、不常用地功能
2、设计一些测试用例？
- 登录测试（功能）：
  - 输入已注册的用户名和正确的密码，验证是否登录成功；
  - 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
  - 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
  - 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
  - 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
  - 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
  - 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。
  - 用户名和密码是否大小写敏感；
  - 页面上的密码框是否加密显示；
  - 后台系统创建的用户第一次登录成功时，是否提示修改密码；
  - 忘记用户名和忘记密码的功能是否可用；
  - 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
  - 刷新页面是否会刷新验证码；
  - 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
  - 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
  - 不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
  - 页面默认焦点是否定位在用户名的输入框中；
  - 快捷键Tab 和Enter等，是否可以正常使用。
- 登录测试（安全）
  - 用户密码后台存储是否加密；
    
    用户密码在网络传输过程中是否加密；
    
    密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
    
    不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；
    
    密码输入框是否不支持复制和粘贴；
    
    密码输入框内输入的密码是否都可以在页面源码模式下被查看；
    
    用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；
    
    用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改；
    
    连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
    
    同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
- 登录测试（性能）
  - 单用户登录的响应时间是否小于3秒；
  - 单用户登录时，后台请求数量是否过多；
  - 高并发场景下用户登录的响应时间是否小于5秒；
  - 高并发场景下服务端的监控指标是否符合预期；
  - 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
  - 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
- 登录测试（兼容性）
  - 不同浏览器下，验证登录页面的显示以及功能正确性；
  - 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
  - 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
  - 不同分辨率的界面下，验证登录页面的显示以及功能正确性。
- 微信红包测试：
  - 单个红包：
    - 红包金额为空、0、0.01、200.00、200.01、199.99、200
    - 留言输入数字、字母、汉字、特殊字符
    - 留言长度
    - 留言复制粘贴
    - 表情选择收藏表情、其他表情
    - 删除表情、重新选择表情
    - 选择支付方式零钱、银行卡、添加新卡支付。其中钱数<红包钱数、其中钱数=红包钱数、其中钱数>红包钱数
    - 使用指纹确认付款（正确的、错误的指纹）
    - 使用密码确认付款（正确的、错误的密码）
  - 群发红包-普通红包：（只写了与单个红包不同的地方）
    - 红包个数为空、0、001、100、99、101
    - 红包拆开每个金额一样均为发红包时设置的单个金额对应的钱数
    - 红包被拆时，有相应提示
    - 发红包者自己领红包
    - 红包24小时内未被拆完，剩余钱被退回，相应支付方式中钱数增加
  - 兼容性测试：
    
    兼容性： 安卓、苹果不同型号版本手机
    
    UI测试： 界面无错别字，风格统一
    
    中断测试： 不同应用之间切换、断网、来电、短信、低电量、手机没电
    
    网络测试： 2g/3g/4g WiFi 移动联通电信弱网无网
- 测试百度搜索
- 测试记录框

测试工具

1、介绍一下自动化测试？参考
- 优点如下：
  - 节约成本和时间：
  - CI和DevOps，提高开发效率
  - 准确性和可靠性，降低人因风险
  - 性能测试，压力测试
- 自动化测试框架：
  - Junit（白盒测试、API自动化、UI自动化）、Selenium（Web自动化、爬虫，Selenium不支持桌面软件的自动化测试，Selenium是根据网页元素的属性才定位元素，而其他桌面软件自动化测试工具是根据桌面元素的位置来定位元素，当然现在也有根据桌面元素的属性来定位的。）、
    
    TestNG（白盒测试、API自动化、UI自动化）、pytest（白盒测试、API自动化、UI自动化）、ATX（移动端的UI自动化测试） GoogleTest编写测试用例。 面向测试编程，先写测试用例。
    
    Jmeter：接口测试，性能测试。
    - 一个比较成熟的测试框架通常会包含 4 个部分，分别为基础模块，管理模块，统计模块和运行模块。
    - **管理模块：**管理模块就仿佛是车中的内饰，它对测试框架的使用操作体验有着直接的影响，分为测试数据管理和测试文件管理。测试数据一般是测试用例用到的各种测试数据，他们是为了验证业务正确性而构造，每一组的测试案例通常会对应一对或多对测试数据。测试数据的创建又分为实时创建和事先创建。测试文件管理就仿佛是车子的外观，给人第一印象。一个测试用例通常需要包含三个文件，分别是Page类文件，测试类文件和对象库文件。
  - **运行模块：**运行模块为测试框架的发送机，用于测试用例的组织和运行，通常包含下面几个部分：测试用例调度，驱动机制，错误恢复机制。测试框架应该具有一定的错误恢复机制，测试案例执行过程中，可能出现代码运行错误或环境导致的错误。测试框架应该能够和 CI 系统低成本集成，包括通过用户输入参数指定运行环境、测试结束后自动生成测试报告等。（流水线）
    - CICD：：持续集成（Continuous integration，简称CI），简单来说持续集成就是频繁地（一天多次）将代码集成到主干。每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。
2、BUG描述、评级
- 对bug的描述尽量简短但要求清晰，对bug出现的条件进行详细的描述，包括输入的测试用例、使用的环境、有没有和其他软件同时运行，以及需要写清bug出现的位置，帮助开发更好定位。
  
  按照用户体验（bug是否很严重的影响用户体验）、影响系统的程度进行评级。
- 一条bug记录的组成
  - bug内容
  - bug发现时间
  - 测试条件（系统配置信息、环境、软件版本、浏览器版本…）
  - 预期结果和实际结果的对比，相关的分析
  - 如何重现这个bug的步骤
  - 这个bug的严重性（会多大程度的影响系统或用户使用）
  - bug发生的位置
- QPS和TPS的区别
  
  TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。
  
  QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
  
  用来衡量服务器的机器性能。
  
  是软件测试结果的测量单位。
3、分析报告：
- 1、【xx测试环境】日报，质量数据，业务可用性，xx个指标，达标xx个，达标率xxx。
- 2、【KV运行状况】日报
- 3、【质量月报】概述，故障情况，用例可用率，质量管理。。主要是各个分类的目标和完成情况。
- 4、【故障报告】故障主题，发现途径，发生时间，影响时长，影响说明，最终定级（核心功能影受影响比例，影响时间数量比例，投诉等）原因分析，改进措施，修复方法，处理过程。
- 5、【风险周知】影响范围，风险级别，修复建议，修复方式，修复情况，操作指引