你说的这种领导，已经是很好的领导了。。。

空闲时间搞，主管应该不会反对的。他应该只是担心没有产出，影响到部分绩效。但你空闲时间搞，先不要大张旗鼓到处说，没有理由反对的啊。等做出来第一个 demo，看下效果，再决定要不要投产呗。
而且你写自动化，和自动化能不能投产，这中间有很多技术难题要攻克，是一个漫长的过程。你只有先动手做起来，才有机会接触这些。

哈哈哈 我理解你 我带的也是这样的

期待你想明白了的回复啊～

我觉得你的思路没问题啊，测试时间只有几天，就应该用一些巧妙的方法去完成测试任务啊～如果原来已经有类似的表做出了类似的统计，直接拿来对比 是一目了然的呀～如果没有类似的，那就在合理的范围内将底层数据简化，看 1+1=2 肯定比看 1.13 + 2.24 更简单吧？
至于 pandas 那些方法，如果函数熟悉，代码又写的快，那确实好用的。

我明白的，其实测试的地位也是靠自己一步一步去争取的，到新公司后，一开始我说要 codereview 人家开发是明显抗拒的。后来发现，我能帮他们找 bug，就一发不可收拾了。现在不管测不测，都要带着代码来，和我说上几句

听上去你们应该加强开发合并代码的能力（开发的基础能力），有些开发遇到冲突时，喜欢强制合并冲突，而不是选择解决冲突。不知道是不是内心想着：反正后面有测试呢。或者根本没想过测试的问题。然后发现了之后，道个歉就没了。。。一点也不重视

你们开发用的是 java 语言吗？直接看他们写的代码啊，每次迭代上线了什么东西，组织大家 codereview，开发养成习惯以后，就会每次都叫上你 review 了。读着读着就可以直接从代码层面找到 bug 了

是有这种可能性的。但是遇上混日子的开发，写一行代码出一个 bug 的，修一个 bug 引发另外一个 bug 的情况下，可能测试也就是在搞车轮战去做回归测试了。而没有精力投入到更有价值的测试点上去（如挖掘更深层次的业务，探索，专项，统一标准等）。

没有哦，其实我测试做的很好，比让我去当开发有天赋多了。。。

一般大公司，安全都是专门的人做的（一般是运维岗），漏洞扫描等等，一些不该对外暴露的接口，目录权限等等。还有是否需要走专线，权限隔离等等。这些基本上不属于测试的范围了。。。
白盒的话，主要还是对代码的解读，逻辑上，是否是按照业务要求实现的代码，写作上命名是否合理，函数的定义和 return 是否合理，（开发命名和函数 return 的不是一个东西，这种都是有的。），边界条件通过代码去检查也是很快很好的方法
sonar 其实也是个很好的辅助手段，在引入 sonar 后，我们开发的创作习惯明显变好了。因为他会建议我们改掉很多不推荐的用法。

我是游戏测试转行软件测试的，其实我个人感觉，软件测试行业让我成长很多，远远超过游戏公司。为什么呢？大的游戏公司，很讲究代码保护，我在做游戏测试的时候，是看不到代码的，而且内外网隔离（1 人 2 台电脑），永远都是手工测试（通过小退，大退等来确认是服务器问题，还是客户端问题）。当然了我很欣赏游戏公司的某些优点，真的做到了用 “好的流程保护了我们这些新人不发生生产事故”。我在游戏公司度过了快乐的 3 年时光后，找熟人从 0 做起，进入了软件行业。第一天就让我部署服务器（从 php 到 python），从 mysql 到 redis,自学了各种测试工具，15 年就写了人生中的第一段 PHP 代码，开始接触自动化测试（不是做平台）。学到现在 10 年了，每天都能感觉到自己的进步。当然了，我年纪大了（超过 35 了），感觉这个行业已经不怎么欢迎我了，但实打实的进步，是可以感受到的。陪伴了这 10 年的每一天。

软测也是累的，大环境都不好，现在应该很少能找到活少钱多的公司了吧。

好用

我刚试了一下 我的 mac 电脑不能用，执行的时候 说 交互失败（具体记不清楚，大概是这个意思，已经确认过非权限问题），我后来发现有网上的资料说，mac 已经不推荐这个 cron 的方法了。。。

这是 chartGPT 给的方案哈

设计如此 - 也需要考虑是否设计合理的。如果你把你的度量和产品经理/或者研发设计者沟通过后，人家可能会觉得你更合理呢？
重复 bug-我们这边以前多个人交叉测试的时候，确实遇到过这类问题，因为你不知道别人也报了这个 bug。但单人的时候不会，一般测试也具备一些 bug 定位能力的，开发动到了全局的组件之类的，可能会引起多个地方出现 bug，这种我们一般都是做一个 bug 来报（也是避免理念差异上的扯皮，毕竟开发也有绩效，同时也体现出测试的专业性。开发会更愿意相信你报的是 bug）

是的，所谓并行，很多时候都是以牺牲质量为前提的。因为人类只有 1 个大脑。。。。不过领导的意思是不是，一个项目 block 的间隙（比如开发修比较大的问题），有一些的碎片的时间做一点小的需求的测试呢？我觉得这个还是可行的。

数据库测试不是 dba 要做的事情吗？技术选型（测试哪种数据库更适合公司现有的产品方案，高并发的速度级别，落库准确性，选的时候就直接测了），数据库容灾方案预演（也是一种测试），还有一些技术指标，提供建表方案，sql 方案，索引方案等。基本的分析指令。一般测试哪里会接触这些？

我觉得你们领导没问题啊～只是说有个前提，开发提交给测试的分支/或 tag 要稳定可部署的（比如：编译成功 + 正常启动，）。而你说的 “以前开发写完代码一合并，就会触发自动构建。开发构建完自己一看失败了自己就去解决了。”，这个是开发在开发环境要做的事情。开发自测完毕后，给出对应的分支或 tag，让你来部署测试环境，你在稳定的测试环境中完成测试。这个应该是你们领导的初衷。

你是不是开了代理？抓包工具打开的情况下 好像也会影响到程序执行

主要就是 5 楼说的原因，所以一定要做接口测试～而且不能单单只做你说的无参和多参。。。

怎么感觉 你们的测试和开发用的是一套环境？尽早能有 cicd 流程搭建属于自己的测试环境，目测是可以让你摆脱尴尬的处境的。。。而且我感觉楼主应该是爱学习的人，不妨着手和同样热爱学习的同事们，探讨一下。。。

2 楼的建议不错的，但可能不太适合敏捷开发。实际上构建的频率没有统一标准的。一般 block 流程的 bug，在修复以后肯定是要赶紧部署的。非阻塞流程的 bug（小小的交互问题，UI 问题，精度问题，数值错误），你慢点部署慢点验都是 ok 的。但如果数据本身严重影响到下一步的正确性。那在有 bug 的情况下，测了也是浪费资源的一种行为。综上所述，并没有硬性指标规定部署频率和时间，而是根据测试实际情况做调整的。

先了解 nginx 的作用是什么啊？你们公司用他主要是干什么呀？比如说权重，那就高并发去压，最后看是不是按照权重去了对应的服务？比如说代理功能，那就测试他是不是真的转发到了对的地方。是否用到了队列，用到了哪些参数配置？跟开发沟通清楚。总的来说，还是要根据实际用到的功能，去测的。因为 nginx 支持的参数有很多的，但实际上每个公司用到的 可能就是其中的一部分而已。

我觉得 2 种方案都没问题，如果第一种里面设计的 case 是完善且合理的，那使用哪种方法不重要。（第二种其实就是冒烟 + 测试用例执行，说白了，如果你的冒烟用例选的不好，那这个策略就谈不上好了，她比较依赖测试人员本身的 “鉴赏” 能力），如果第一种方法里面设计的 case 本身不完美，但在执行过程中你又找到了好的测试点，那完全可以补充进来放到第二步里面去执行。还有就是第一步发现的 bug，分析一下影响范围，适当的筛选第二步的 case，节省时间。那如果都做不到，就只能按照你说的第一种方案（再找个高手做用例评审，适当规避问题），一个脚印一个脚印来了。