把登录写成类方法，每执行一个测试类 就执行一次登录接口，获取 token

消灭 bug

仅仅截图 不代表功能正常吧

这个结合你们公司的实际来做 一味的套搬别人的框架 无法落地反而会影响积极性。

看一下生成报告的插件，应该是时区的问题，根据你的描述来看，时间应该是获取的标准时间，咱们是东八区，差八个小时很正常，修改一下获取当前时间的方法就行了

语言、网络、当地的风土人情，其外国外的很多 APP 应该都是用了 GMS，这个国内的机型应该都是把这个功能阉割了

可以换成使用 text 定位

我一般的习惯是把 异常处理，日志打印等公共的方法做成一个修饰器，供 basepage 里面的方法调用，这样做的一个好处就是，公共组件都可以集成到修饰器里面

点击选择需要选择的区域，可能前端设置的 input 值变更的方法是通过 click 触发的

是不是没有调支付的回调，这个得看你支付的调用日志啊

这个真不错，作者有句话说的真对 非主流浏览器做兼容的时候真的是让人欲仙欲死，之前用 selenium 做自动化兼容测试的时候 就碰到过类似的问题

上拉是加载数据，不是刷新吧，加载动画是否正常加载，分页是否正常，请求分页接口是否正确，没有更多数据的时候是否会有提示，等等。。。。。。

线程数、启动时间、运行时间，同步定时器 这些需要根据实际的业务场景来设置，
此外最大的并发，要看你的想看什么情况下的最大并发，出现报错？超时？亦或是超过多少秒？
监控服务器指标的话，各大云服务器平台都有自己的服务器性能看板，想自己搭建的话可以试试 grafana+Prometheus

@TesterHome小助手 这个就是明细里面的，我兑换的是一个 0 积分的商品。按照常理来说既是显示记录应该显示的是 -0

Testerhome 十周年快乐！ 希望社区的朋友们，永远保持对技术的热爱，砥砺前行、不忘初心，祝 Testerhome 下一个十年更好，期待。

个人感觉橄榄型要比金字塔型的可实施性以及实用性更高

从项目根目录开始导入，然后把根目录通过 sys.path.append 加到环境变量里面

可以从实际中出发，因为单纯的去学，很容易产生疲倦性从而导致不想学，而从解决实际中的问题的话，就会既提升了自己，又看到了效果，比较好。

说实话确实挺浅显的，你这个只是压测流程中最基础的一步，设计压测脚本，后面还有系统监控，结果分析，等等，

问的还可以，不算是很偏

比如常用的 adb 操作，手机性能的监控，主要还是看自己公司的具体场景，从实际出发，解决痛点

这个可以监控手机的 cpu、内存等使用，当你们的 APP 没有占比的时候，很明显就是被干掉了

等到进入公司以后在看看需要学习什么，在实际中提升更有效果和成就感

推荐去招行，招行说实话还是比较接近互联网公司的

这种的话和传统的软件测试应该是相似的，都是进行操作看能否达到预期