这个有点挑骨头了吧，而且作者明显还有下篇啊。
没必要这么评价别人的文章吧

理论上来说，JWT 机制可以取代 session 机制。用户不需要提前进行登陆，后端也不需要 Redis 记录用户的登陆信息。客户端的本地保存一份合法的 JWT, 当用户需要调用接口时，附带上该合法的 JWT，每一次调用接口，后端都使用请求中附带的 JWT 做一次合法性的验证。这样也间接达到了认证用户的目的

文章作者说的很清楚嘛

通过 Reporting hook 的 pytest_collectreport 方法来取

晕，改订单时间变成前一周的数据，然后不就能生成订单折线图了？至于要回归多少 case 这个问题，可以和你的测试 leader 讨论下。

还是修改时间啊

订单折线图：造一批订单数据数据并修改其时间。
在线教育课程：绕过中间最费时间的视频或音频播放，直接做题完成课程。如果要测视频或音频的另起 case 做。
BTW 这些问题的解决方案 leader 都不教的吗？

UI 测试个人觉得还是要看具体需求。
比如一些在线教育类就会比较注重 “用户体验” 这其实对前端的要求会很高，对应地对 UI 的测试需要也会更多。
而一些金融类的行业前端就相对后端就简单很多，所以 UI 的测试也就不会有太多的需要。
当然也有特例比如社交类的前后端要求都高，那接口和 UI 测试都要做的好。
其实根据实际情况去学习就好，不必抱着不放。

这个有些运气成分，并不是你答的越多越好，最好在回答的时候试探下是不是需要从一个点深入讲。更主动去和面试官互动，会比较好。

mountebank 了解下

import random
set([random.randint(1, 9) for i in n])

random.sample(range(1, 10), k=8)

其实 A 公司代码用正则写，可以省去很多用例。如果代码是正则写的话，我对楼主还是满意的。
小建议，如果感觉答的不好大胆开口问面试官答案

输出测试用例，目标用最少的测试用例发现产品的问题；

这句话有漏洞，将用例写的越粗就越能达到这效果。
个人理解，用例的覆盖率越高就越能体现其价值。

目测到一个问题 httpRequest 无法支持 params + data 或 params + json 的组合请求。

阿里人机验证

哎~~~postman 请求的是 query string，用 requests 时居然放到 json 里。。。。服！能不能好好看看 http 协议基础。

性能测试可以了解下

肯定没覆盖到咯，具体原因是另一回事。不老想翻身做 “主人” 就能 “为所欲为”，就是一个打工的想想怎么做好一个打工仔的本分就好了。

我猜你说的参数是 query string 吧 (这个样子的 /xxx?name=Michael)，如果是这样的话请用
requests.post(url='xxxxx.com', params={'name': 'Michael'})

一旦测试参与了产品多个环节，测试对产品的理解更深更细

这点我部分同意。

能够把控项目的进度、产品的业务风险

这点我就不同意了，这 2 点明显是老板们说的算啊，虽然测试能提供些建议但和 “把控” 没有一毛钱关系啊。

能够 hold 住全局？能不能不起飞脚踏实地？

base 在哪？

“深度 VS 广度” 这个题目确实会引发思考，但这 2 个名词也就看你从什么维度去理解和分析了。
思考是件好事，但这种思考拿来谈论最终就是清谈了。
如果想他人支持赞同你的立场和理念，更多要靠行动而不是靠 “谈”。

单元测试框架 是运行 case 的框架并提供必要的 utility。具体执行什么 case 还由编写 case 的人决定的。

没有最好，只有适合，先用 unittest 吧