你这里 i 等于 3，前面几页获取第 3(i) 行信息是没问题的，因为每页信息是 n(>3) 行。最后一页信息只有一两条，这时候脚本试图获取第 3(i) 行信息就会报错，因为提供的 index 超出范围，也就是 index error

没完全懂你想做什么，贴出来完整的测试用例吧，注意脱敏。

先在 A 机执行，再在 B 机执行

自动化不能验证移动的元素，可以验证元素所在模块在正确的位置。

参考下这篇文吧，python3 BeautifulReport 测试报告 及 报告中增加日志输出：
https://www.cnblogs.com/fcc-123/p/11382429.html

我明白这和具体业务强相关，就是你既然提到你们当时两种方式里压缩比是多大范围，所以也想知道消息剪裁的减小幅度。

消息剪裁时去除了不需要的字段，多大幅度减小了消息体的大小？能不能也给出个范围。

期待你在后续文章里着重描述下对计算结果的验证问题，相信这也是@rihkddd关注的问题。

但是没法解决 test oracle 的问题，例如研发、测试算出来的结果一致，而很有可能是他们都算错了。

深表认同。

看你代码里的逻辑，是 for 和 if 的多层嵌套。那么问下，你花了多久实现这个数据生成功能？如果测试需求变更，你需要多久维护？

他若回答你已经有 2000+ 用例在跑了呢？

看到你实现了接口数据的自动生成功能，能详细说下吗？你是怎么保证自动生成的数据符合测试需求的呢？

既然已经 “避开” 了问题，又何必苦苦探究如何 “解决” 问题呢？凡事不可太认真啊！

不同级别放入不同目录

输入是 A，期望输出是 E，开发的实现过程是 A—>B—>C—>D—>E。
开发的实现属于黑盒内部逻辑，测试要做的是输入 A，并检验实际输出是否为 E。
而不是检验如下中间过程：A—>B，A—>C，A—>D，B—>C，B—>D，B—>E，C—>D，……
把被测产品当做整体看待很重要，也是我们的测试目标。中间使用到的产品，都不是测试目标。目标要明确。

——由于 kafka 本身提供了这种特性所以要保证消息传送到 kafka 的数据一致性是比较容易的， 正因为很容易一般不容易出错所以很多团队都忘了去测试这个场景（有时候研发会忘了设置这个参数导致出现 bug，所以最好还是需要测一下）——
不是忘了，而是这种属于优先级很低的场景了。应该把有限的测试资源首先放在高优先级的测试场景上。

这种情况下重新运行脚本并通过就行了，不需要 investigate 某次运行具体出了怎样的异常。

获取不到说明不能使用 UI(自动化) 测试来做，应该使用别的方式达到验证目的，比如接口测试。
设计测试方案的时候，最重要的一个参考就是被测产品的设计。

这需要一个站在全局高度的人去管理协调，这个人既需要是个技术能力达到架构师水平的人，又需要他是个管理经验能力比较高的人。

这又是个测试用例设计的问题。
在 web 上操作设置后，使用 appium 获取 APP 上对应的链接属性，然后断言该链接跟 web 上设置的链接相符就可以了。不需要打开链接。

排查错误时运行自动化脚本不比看视频录像更直观吗？

视频是要录制自动化运行过程吗？录了干嘛？

稳定可靠的测试环境很重要。
要把异常场景的处理当做环境搭建的一部分。
搭建之前就应该考虑好大部分可能出现的异常场景并加以处理，比如删除不必要的闹钟。
然后在使用环境的过程中，逐渐加入其他没能考虑到的异常场景，比如如非必要则关闭短信功能。
最终就会得到稳定可靠的测试环境。

testNG

目前都不支持这样的 (奇葩) 需求