有自己内部平台，基于 agiletc 做的，也是 xmind 形式写用例。

xmind 优点是编写简单，缺点是别人相对没那么容易看懂（也有办法优化，写细一些，有问题能问人就行），适合经常有新功能要写用例，且大部分用例其实不会换着人重复执行的场景。互联网大多是这种，就算是发版固定要跑的场景，xmind 写细点其实也够用。

excel 优点是很规范容易统一，缺点是写起来的成本比 excel 高，适合写完基本就不怎么会改，且会需要换着人执行的情况。只是互联网现在这种情况太少了，所以用得很少。

至于你提到的 excel 听说很多大厂都用这种 ，建议细问下是大厂的啥业务，啥场景（比如给流动性很高的外包纯执行用）？不能听到大厂就直接追随，大厂通常有很多不同类型的业务，不同业务差异还是很大的。

想问下，这个是稳定重现么？好慢具体是多慢（多少秒，浏览器开发者工具里，network 部分截个图看看就最好了）？完整的操作步骤发一下？

我这试了几次，都挺快的，基本 1 秒不到就加载完了，没法重现，所以也没法了解到你具体的情况。需要你多提供点信息。

3 年还年轻，多看看外面的世界吧。

另外，提了离职就不要考虑回头路了，你的上级都知道你的心不在这，就算你留下了也不一定会主力培养你。何况你也说了，已经没太多成长，为了这 1K 放弃后面更大的成长（前提是你确认新岗位真的能成长更多，这点你可以找你未来 leader 多聊聊），不大值得。

可以具体说下什么项目，安装不了是报什么错？

个人经验，开源项目的作者对项目太熟悉，有些细节可能会遗漏写到文档里。而且也不一定有条件在各种环境下安装，所以大家实际在其他环境下安装，可能会出现一些作者不会遇到的问题。需要自行踩坑填坑一下。

有问题安装不了，更建议大家社区发帖咨询沟通哈，安装文档都是需要大家持续反馈，持续迭代更新，才会越来越好的。说不定作者也在社区，这样交流起来也更便捷。

哈哈，感谢支持。当时其实也是刚入门接口测试，会有挺多困惑的，所以写下来也是为了帮助自己更好总结理解。

后面你对这个自动化意义有新的感悟，也欢迎来社区分享哈。学习了很多东西后，个人感觉，对术（怎么做、遇到的典型问题可以怎么解决）了解多了后，总结成道（能做什么不能做什么，什么时候适合什么时候不适合），会更容易记忆和应用，也避免跑偏用错，产生负效果。

那么基于场景得接口自动化意义在哪里？

个人理解主要有几个意义：
1、能高频跑，更早发现问题。我们之前最高频率是每 30 分钟跑一次，失败立马预警，开发立马修复。这个换成人力跑成本太高了，而且有些核心问题如果到末尾回归再发现和修复，时间会很紧，改过的代码多，找问题原因也会更加费时费力。
2、减少人工测试要跑的场景数量。主流程人工过一遍这个省不了，但工作量比全部过一遍要少不少了。
3、如果自动化校验点足够齐全（包括数据库校验等所有人工测试会验证的都有验证到），且修改点确认只有服务端，不涉及其他端，那我觉得跑完直接上线是没问题的。

例如一个支付接口他需要先添加购物车 =》下单 =》支付，那么在测试下单接口得时候，是把前两个接口都调用一遍获取订单信息再作为参数给到支付这里，还是直接在数据库里构造这部分信息测试支付呢？

建议是都调用一遍，主要是从可维护性角度考虑。一般服务提供的接口，会保障向下兼容，且保障按顺序调接口没问题的。至于插库，这个特别姿势一般不会保障，意味着需要测试自己保障；而且这部分也是很可能会改动的，依赖的数据不一定都来自数据库，也可能是第三方服务什么的，那这个方式就行不通了。

利用随机生成（0，1）方法随机生成 0~1000 的数

我看到第一反应也是 random.random()*1000 ，日常写代码要取某个范围内的随机正整数就是这么写的，random.random() 生成的是大于 0，小于 1 的随机数。但这里有两个不确定的点：

1、随机生成 (0, 1)，不知道是指只会随机生成 0 或者 1，还是生成 0-1 这个范围内的数字。
2、生成 0~1000 的数，不知道 0-1000 是范围还是啥。

客气啦，最终还是你自己找到原因和解决的。我平时用 allure 也不多，也只是临时现找一些，给点思路。

你把你的 jenkins 打包 html 报告那部分配置截图发下？

我记得 html publisher 这个插件是把配置了的目录内所有内容都拷贝一份进行存档的，具体配置不大记得了。报错的那个 C:\DumpStack.log.tmp 应该不属于你 html 报告的一部分吧？如果不属于，说明你配置有问题，把一些无关的文件也纳入了。

必应搜索了一下：https://cn.bing.com/search?q=allure+Behaviors+404&FORM=BESBTB&sp=-1&pq=allure+behaviors+404&sc=0-20&qs=n&sk=&cvid=191BE4F77E1D4B82A52481F85FA23E98&ensearch=1

找到 1 个看起来有关的官方 issue ，大概指引是有垃圾数据导致：
https://github.com/allure-framework/allure2/issues/1174

另外，看官网，配合 pytest 生成报告的命令好像不是你发的那个，而是 allure serve /tmp/my_allure_results 。你可以换这个命令试试？
https://docs.qameta.io/allure/#_pytest

然后 allure 提供的 BDD 相关注解，官网没提到 @allure.epic ，你截图里有写。不知道有没有关系？
https://docs.qameta.io/allure/#_bdd_markers

个人观点：
1、既然有这想法了，可以考虑出去面试一下，了解下行情，也是对自己能力水平的一种校验。担心直接投简历会被 hr 发现的话，可以找朋友内推试试。
2、即使继续留这家公司，也可以争取向上走，比如带带团队、做些公司核心项目什么的，让自己变得更核心，能力更强。

有时候，焦虑源于你对现有工作太过游刃有余，所以有太多时间去思考。当你在持续上升，保持着优势时，你就不会那么焦虑了。

从截图上看，你 Archiving 的第二个是把整个 C:/ 都打包记录到指定目录，这范围太大了吧？

C 盘会有 windows 操作系统的很多相关文件，其中不少文件都是有进程长期占用的，所以遇到这个报错不奇怪。根本原因是你范围有问题，不应该打包整个 C 盘的内容到报告目录里。

人工查看是否有重叠等现象，场景比较多的时候，这块的工作任务会比较重

之前 mtsc 大会有见到过这方面的议题，通过把值设定为所有语言下翻译的最大长度 + 页面自动遍历 + 图像重叠检测来处理。具体的你可以到公众号发送 ppt ，找到存历年 ppt 的网盘，搜索 全球化 这类关键词

你这块是排查定位所需数据的聚合方面的问题了，如果前后端本身有日志聚合服务（如 ELK ），记录下时间段，上去取即可。如果没有，只能因地制宜自己想办法弄。

前端到后端的，4 楼已经说了，就不重复了。
后端内部的，做个脚本 ssh 到各个服务器一个个去捞也是一种办法，当然直接聚合到 ELK 是最好的。

本质上还是，作为一个人要从哪些地方定位，那就把那些地方的信息都聚合起来。这样聚合后，自动化或者手工测试，定位问题效率都能提高不少。

所以走查询接口在能查到需要字段的情况下，我觉得是更符合业务测试场景的一种方式

这里有一个点，校验数据库数据 != 不测试查询接口逻辑。只是把 写接口->读接口 ，进一步拆细为 写接口->数据库验证， 数据库数据->读接口验证 。拆细的好处校验的内容更独立，失败时排查范围也更小（读 + 写 fail 时，你还得通过查库来排查是写的问题还是读的问题）。

所以在符合业务测试场景方面，两个是没差别的，差别只是要不要多做数据库校验这一步。

在手工校验的阶段，是会人工去数据库比对一下数据的，但是写自动化脚本时还有没有这个必要

这个说实话，看实际业务和自动化脚本可以投入的成本有多少。从最严谨的角度说，查库会比不查库更独立，适用范围也更广（特别对于查接口没有那么完备，或者写和读并非一一对应的情况下），问题定位也更高效（比如 fail 时，可以把范围缩小到只是写接口有问题）。但如果说可投入成本有限，且查的接口也确认可以满足，外部业务都只会通过接口而不会通过数据库获取数据，那仅在接口层面确保写和读保持一致，不校验数据库的实际数据情况，也是可以的。

写自动化脚本有没有必要做数据库校验，取决于你是否信任没有校验数据库的脚本的执行结果，是否可以明确认为写 + 读组合逻辑的正确就可以认为功能正确。如果能信任，那就没问题。

个人理解：

1、根据你这个业务描述，mysql 和 es 都分别有存储，而查询接口很可能只是查其中一个库，另一个有可能就没提供查询接口？这种情况下，只通过查询接口，校验会不够完整。

2、我们以前是因为有一些入库操作是没有直接的查询接口可查的（比如日志表、流水表），或者查询接口查出来的不一定全（比如一些非业务系统用到，但大数据要用到的审计字段，创建时间、创建人之类的），所以要做数据库校验。

3、最主要的点，是数据库校验是对写接口逻辑最直接的校验方式，毕竟写接口的逻辑本质就是在写入数据库，而查询接口已经是另一段和写无关的读逻辑了，为了性能有可能先读缓存，后读库。在极端情况下有可能两个都错在一个位置（比如代码逻辑都映射为 1=false，实际数据库定义 1=true），反而最后看起来是对的结果。这种情况下可能会导致基于数据库数据进行处理的下游应用（比如大数据报表）出问题。

挺好，perfdog 付费了，这个也可以顶上。如果能附上完整的源代码，整个方案就更易用了。

问卷末尾有提到，如果有 ppt，ppt 可以单独提交邮件到 topic@testerhome.com 邮箱，邮件名为 公司 + 议题名称 。

有点没看懂，这个文章想表达什么？职场 DIY 是啥意思呢？

好有才

我理解不是过度神话，可能是有很多人把它当做银弹了。把提高效率=自动化，没有根据实际项目去评估投入产出比。

其实视野大了后，提高效率的手段会多很多。比如多用靠谱的代码自动生成工具，有效减少手写代码的 bug，测试用例也可以精简不少；架构设计上减少重复，减少变更后要验证的范围，也能提高效率。只是确实会有一部分测试，视野只看到手工测试，提效想法就会局限在怎么让手工测试执行得更快，自然就会觉得能让执行速度大幅度提升的自动化非常好了。

我觉得不如楼主补充下，为何会觉得自动化被过度神话？是看了哪些资料产生这个感觉？

PS：金字塔的图印象中 2-3 年前已经改为菱形了，因为绝大部分互联网公司是不可能做那么完善的单测的，投入产出比相对高的是接口层的自动化。不知道你看的是什么时候的文章？

嗯嗯，明白你的目的。从目前工具上，暂时没接触过有这样功能的工具。

建议你可以换一下思路，用类似 page object 的模式写用例。每个页面用到的元素记录到 page object 里面。你写用例的时候直接用就是了，也不用用例里各种 find element 。

从功能上，你把 dump 下来的页面结构 + 截图保存起来，使用时代替实际实时抓取的值，发给元素抓取工具，是可以做到的。只是这个功能可能并不是核心功能，所以一般工具没做。

看下你环境变量里，JAVA_HOME 配置的到底是啥？appium 都是问系统拿的值，这个值不是凭空出来的，一定是某个地方配置出来的。

另外，也说明下，经过命令行敲 java 和 javac 命令可以直接调用对应程序，是通过 PATH 这个环境变量来实现的。这个和 JAVA_HOME 这个环境变量是完全独立的，没有强依赖关系。java -version 调用到的 java ，不一定是 JAVA_HOME 配置的 java 。举个 linux 里面写法的例子（忘记 windows 下环境变量的表示方式了）：

export JAVA_HOME=/user/jdk16
export PATH=$PATH:/user/jdk1.8

这样配置下，你用命令行调用 java 命令，用的是 1.8 的（PATH 里面配置的值），所以 java -version 也是 1.8 的。但 JAVA_HOME 却是 16 的。虽然很多教程都会教配置时 PATH 里面不要配置绝对路径，应该配置 PATH=$PATH:$JAVA_HOME 来引用 JAVA_HOME ，但如果是程序自己配置或者其他人配置的，这个就没法保障了。以前用 jdk8 的官方安装程序，貌似只会自动配置 PATH ，但不会配置 JAVA_HOME 的。其他版本的 jdk 没怎么用过，不清楚。

shell 下面通过 env 命令就可以列出所有环境变量的名称和值了，我排除环境变量的值是否有错误，经常用这个（shell 在不同运行模式下加载环境变量的顺序和位置都会有差异，命令行能正常调用的命令，jenkins 的 shell 下就是提示找不到，这个非常常见，需要用这个 env 命令列出所有环境变量的值供排查）。windows 不知道有没有类似的命令，其他人知道的话也可以分享下。