你把你的 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 不知道有没有类似的命令，其他人知道的话也可以分享下。

赞同 2 楼观点。我们的编程题很简单，把一个字符串按指定的符号转换为字典这种数据结构，大部分人不至于没有任何思路。考察的其实就是编码熟练程度，以及思维是否足够严谨（比如一些判空的点会不会遗漏）。

再者，测试作为一个技术岗，掌握一些技术岗要掌握的基础知识（数据结构、算法），也挺正常的吧。虽说大部分算法都被基础库封装好了，但有些特殊场景的算法还是得自己写的。比如通过遍历 xmind 所有节点获取测试用例数及测试结果统计，就需要懂遍历算法。有时候开发可能也会用一些算法，你不懂可能就看不懂开发逻辑，可能设计的测试用例就会遗漏一些重要的场景。

从你这些回复看，你在测试这方面的工作经验接近于无，基本都是自学，没什么可列举的项目成果。

这种开发转测试，并且是通过找新工作转，是会很困难的。给几个小建议：

1、现有公司是否有机会转，有机会先在现有公司转，会方便许多。
2、稍微降低一些预期，外包也找个相对靠谱的去试试，先积累经验。一般非外包岗位，社招都是希望招到经验对标的、学习积极性强的，只有应届毕业生会相对不那么要求经验对标。没有实际工作经验和成果展示，这个始终是硬伤。
3、看你现有经历好像和图像识别算法之类的有关，如果确实有学到一定深度的话，可以项目里补充上你对这些算法的实际项目经验，试试一些大数据或者算法测试岗。这部分岗位有相关开发经验是很大的加分项。

问几个问题：
1、最终质量上，有因为时间被压缩导致的线上故障什么吗？——如果有，可以借这个对上级多说下，原因是因为时间被压缩太厉害
2、研发周期长，是指经常超时提测吗？超时率多高？——这个看是否有项管或者这类管理项目进度的角色，没有就相当于你和研发的上级在关注，可以向这些干系人多反映下。

这个情况我理解核心就是 1 楼说的，从上而下不重视质量这个观念是根本。多给上级和研发同级吹吹风，先思想上获得支持；然后是制度上，提测超时率（非需求变更引起）、提测打回率（提测后冒烟都跑不通的）统计一下，作为开发转正标准或者绩效的一部分，落到实处。

还有一个点，看研发团队里是否有一些比较有追求的人，自己会把控好自己工作的质量，这部分人可以多表扬，让大家多看到，让他们能发挥更大的影响力。

因为现在是理念上的差异，要改变要做好周期长、部分人消极应对、离职甚至反对的情况。所以得先和你的上级达成一致，才好继续往后推行。

这块没研究这么细。

最后的工作经历有点没看懂，你最近这份工作做的是开发还是测试？项目描述像是专业做测试，但工作经历主要说的是开发，有点对不上号。

难道性能测试只能通过工具来做？

大部分情况下，用工具做会简单很多。写代码也可以，但你要写不少代码，比性能自动化多不少。而性能测试对于工具的要求其实比较通用，所以大部分工具本身可以满足，不需要从零写代码。

另外，性能测试工具，一般指的是发起压力的工具（如 jmeter）。实际完成性能测试，还需要监控排查的工具（如 jprofile、grafana）。你说的死锁什么的，要通过监控工具来找。

性能测试需要掌握一些什么？

你这个要了解的是 “性能测试怎么做” ，相当于一些基本概念和理论。楼上说了不少文章，可以去看看。

作为一个突然被告知做接口的性能测试的小白，有点不知道怎么下手了

想系统入门一个东西，不要靠搜索引擎。搜索引擎可以找到的是最热门的，但不一定是最系统的。一般技巧都是热门，但概念理论都不热门。所以你需要的是找一些系统点的课程或者书去学习。

上次（2019 年）参加广州测试沙龙分享后最大的感触，就是大团队做的事情和我们小团队的很不一样

小团队做得好且愿意出来分享的真的很少。下半年广州计划再来一次沙龙，有兴趣来分享下么？

这个我觉得不用担忧，你有一线大厂背景，不至于找不到工作，只是怎么找到适合自己（特别是薪酬待遇和发展空间）得花点时间。只是提醒一个点，要留意下除了使用大厂的提供的工具外，也留意下，即使不使用大厂给的，自己用外部开源工具也可以搞起来就行。一般外面其它中小厂面试大厂出来的，会特别关注这个。

另外，你如果后面计划是转开发，建议一开始就做开发。测开和开发虽然都会做开发相关工作，但测开关注的是整体方案和是否满足团队需要，要能给几百上千的测试团队乃至研发团队提效，相对更偏广度；开发会面临更多的系统复杂度和业务频繁变化挑战，要给千万甚至过亿用户提供服务，做到高可用和高性能，偏深度。两者往后走差别会越来越大。有可能到时候你的测开经历，到时候找开发岗位，会不如走开发好找。

不知道你 offer 是否会参与业务测试，还是专注做工具平台。如果是后者，估计你找业务测试也不一定好找，因为这方面经验比较少。有机会还是尽量也参与下业务吧，业务才是根本。

从你的需求看，你不满足于模拟，对真实度要求很高。说实话，这么高的真实度，除了真实在那个地点有一个网点外，别无它法。然后手机能请求的，电脑一定也可以。这样就不局限于手机，可以看各家云厂商的机房都有分布在哪些城市的，在各个城市的机房都开一个虚拟机，当做当地网点。不过机房网络和移动网络的路由还是有差异的，无法真正做到一致。

但我觉得你是否可以换一个思路，不一定要主动发现（说实话，日活高的话，主动发现和监控发现差别也不过几十秒，甚至只要几秒。从发现问题角度，没啥差别，这几秒你也不可能完成回滚或者重新上线），而是在影响更小的情况下完成数据采集，以及快速响应解决问题？

如果按这个思路，数据采集可以这么做：
结合地域流量控制的灰度发布，只放指定城市（可以通过 ip 过滤）的 xx% 流量，看监控数据是否有波动预警

解决问题可以这么做：
多准备几家 CDN 厂商，发布时同时发布。日常流量策略优先给在当地表现好的厂商，少量给表现一般一些的（作为监控手段），如果发现监控有问题，立马调整流量策略，增大到其他备份 CDN 厂商的比例。