字节面试题:在线表格功能怎么实现?怎么测?

最近有小伙伴私信问我怎么不更新了,期待更新,甚是感动。
简述下自己近况:
还在干测试,最近忙活的事情大概是自动化测试、性能测试以及业务等等,主打一个啥活都干。
业余时间,尝试在短视频赛道搞一些个人兴趣领域的创作,所以博客不太更新,想分享的东西还是有的,后续仍然会记录一些工作心得,感谢新老盆友的关注!

正文:

前阵子看到老张写的关于面试的文章,我突然想起来,我多年前面试字节时候,遇到的一个面试题,关于如何测试用例的。

印象中好像第一次参加字节的面试,也没刷题练习,所以开始的算法题就没做好,导致后来的表现都不太好,所以这个设计用例的题目,也没回答好;

今天当做是重新归纳总结一下。

一、面试题

面试官问是否用过在线表格之类的功能,知道这种功能系统背后是怎么实现的吗?如果让你测试在线表格,你怎么设计测试用例?

我当时的作答就不赘述了,如果现在让我重新作答,我大概会这样说。

二、关于系统实现

涉及到支持多人实时操作一个文档,其实背后大多是基于WebSocket协议来实现,而不是我们最熟悉的http协议。就像是即时聊天工具。

WebSocket 是一种协议,它允许客户端和服务器之间进行双向通信,非常适合实时应用。

我们通过浏览器打开在线表格,就会跟服务器建立一个持续通信的通道。然后我们在表格里做的一个个操作都会发送到服务器,然后服务器再把这些操作传给其他一起编辑的用户。实现实时更新功能。

但是这种功能有一个特别重要的问题要处理:解决冲突。

具体处理算法咱就不知道了,反正核心思路就是要把不同用户的编辑操作进行整合,来确保最终的文档一致。

从用户体验上来讲,可能还会涉及到本地缓存的设计,保证用户编辑后的结果在自己界面上是实时显示的,然后再将这些操作同步到服务器,当碰到网络波动或者延迟的时候,用户感知也不会很明显。而且用户就算断网了也不怕编辑的数据丢失。

从提升性能、降低成本角度来看,端上与服务器之间的通信,传输文档应该也大多使用差异更新,而不会每次都传输整个文档内容过去,可以减少传输量,提高速度。

以上大概是现在的回答,因为从开发实现角度,以及使用飞书在线文档的使用经验来看,差不多如此。

另外,面试官问你如何设计的问题,大概率也是考察你的知识拓展面如何,或者应对新系统的分析能力。

三、如何设计测试

如果真的接手这样的系统,那么了解背后设计原理,服务架构,测试是一定要做的,这样才能更好的帮助自己设计测试用例。

面试官问这种问题,主要还是看你的测试思路,所以千万不要想到一点说一点。

那么结合在线表格这种功能特性,就需要分析基本功能测试、实时同步、冲突处理、并发、负载测试、兼容性、权限控制、数据安全等方面了。
可以先说下考虑到的这些方面,然后每个方面逐步介绍重要测试点,很多常规的测试点可以快速带过。

1.基本功能测试

  • 创建和保存文档
  • 单元格编辑
  • 单元格输入
  • 单元格公式计算
  • 单元格拖动
    ...

2.同步测试

  • 多个用户实时编辑同一个表格
  • 多个用户实时编辑同一个单元格
  • 冲突处理后最终一致性

3.性能和负载测试

  • 高并发同时打开在线文档,响应时间
  • 同时编辑表格保存
  • 表格内容巨多,打开文档的加载时间
  • 高负载情况下,系统的CPU和内存使用情况。
  • 高负载情况下,压力持续,验证系统稳定性。

4.安全性测试

  • 权限控制
  • 测试不同权限级别的用户操作,验证权限控制是否有效
  • 测试在文档编辑和保存过程中,数据是否能够正确加密传输。

5.兼容性测试

  • 跨浏览器兼容性
  • 跨操作系统兼容性
  • 移动web端

6.用户体验测试

  • 用户体验测试
  • 界面易用性
  • 界面的布局和设计是否合理
  • 错误提示是否清晰明了
  • 对于网络中断、服务器错误等异常,是否友好处理

其实这也就是在这写文有时间细想,可以整理这么多,实际中不用说这么细问题也不大,但是考虑的面还是要尽量全。

不要小看用例设计的面试题,如果你能快速抓住功能的核心点,能有条不紊的作出总结,既反应出了你的思维能力,也反应出了你在这行是否有了对应的沉淀。

如果写了测试5年经验,但是一讲用例,东一榔头,西一棒槌,那自然就没好印象了,直接印象就是:基本功不扎实;

还是那句话,核心还是业务,其他的一切技能都是为了更快更好的完成业务来服务的,不能本末倒置,现在环境这么差,行业又这么卷,业务和技术一定得两手抓才可以。

posted @ 2024-07-10 19:50  把苹果咬哭的测试笔记  阅读(21)  评论(0编辑  收藏  举报