转开发。
在资源有限的时候，领导们必然高举 “开发优先” 的旗帜的。

先把数据分类，其实有些导不导都没啥必要，有些又要脱敏，有些可能必须得没版本更新。不能一概而论。

哈哈 也可能回滚了

感觉自己能，和实际深入做过，是两码事，别被自己骗了。

“会做一些 Selenium 和 Appium 的 UI 自动化测试框架 Demo，用上了 PO 模式或者是数据驱动，能使用 Python、Postman 或 Jmeter 进行接口自动化，但去面试大脑就一片空白吹不起来”。
——我也曾有过这种感觉。现在回过头看，原因是学是学了，但是也就是个模仿着会的阶段，看见新的技术，就想去学下，但是浮躁让我从没有认真从头到尾实践过几次，没有总结，也对实践没有自己的要求和思考，说实话，跟没学差不多。

做开发不香吗

是没有环境，还是说要做自动化测试？
如果仅仅没有环境，是受限于资源，还是权限。没资源就本地搭个，没权限就申请。实在不适合就放弃。

“无自动化测试环境，搭建升级到自动化测试”，按需求来看，是有歧义且不明确的。

1. 先定目标——你想去哪家公司，就去看他们招聘信息的要求，去自己学相应内容。
2. 打基础——自动化方向，就把编码基础打好
3. 实践——能借助工作资源的，就用工作资源做，不能的自己用开源的。

需求不清，打回重写

嗯，而且我没想明白他那个通过计算覆盖距离优先是基于啥条件来说的。。。总之这个需求有点模糊，不符合准入条件，哈哈

现在的电梯基本都是那种可以看到电梯停留层数的吧。。。不然初始状态都不好了解。。。
转化一下问题，应该就是
输入：B1 按上 1 按上 1 按下 1 按上并且按下
输出：
A 停 B1 A 停 1 A 停大于 1
B 停 1 B 停大于 1
需求：测试下电梯调度算法

不知道是不是这个意图

我们是先约定了一个共识的覆盖率（40%），然后再根据实际情况增加或者减少覆盖率的要求，涨超过 5% 的有奖励。
最终的现象是好的稳定的团队（也可能是闲的），这个一直涨到 60-70% 左右就没涨了，当然也有原地踏步的团队（人员流动很大），以前是 0%，后面是 40%，万年不动。

2 年前做过，当时想的是给自动化回归测试当补充。后面弃用了。一个是用例规模不大，没这必要，全跑也多不了多少时间；另外就是用例质量不高，自动化测试覆盖都没到位，搞这个不合时宜。再后来公司搞开发优先，测试有点技术的要么干开发，要么跑路，已经没做下去的必要了。

大概方法是，在已经建设好自动化测试跑一遍，通过 javaagnt 把用例和用例覆盖的代码（到方法级）保存到数据库，然后提交代码的时候去拉取要跑的用例，达到精准测试的目的。

嗯代码还在内部 git 上

100+ 表格，要疯。。。

代码中限制某个 IP 和用户能访问。明天就是那些 IP 和用户。

如果靠预知，请告诉我明天的彩票号码

不准备感觉答不对几道。。。

teardown 吧。teardown 的时候把你排查的时候要看的东西记录下来就行。
现在做的接口项目，我把重试机制直接干掉了，感觉没啥必要。如果报错，肯定是哪里有了问题，没必要重试。（当然不同项目可能不一样）
PS：接口测试，默认稳定。

找好赛道，测试不虚菜鸟开发的。

时刻准备拥抱变化，比如末日降临

我就喜欢这种前端校验的系统，轻松越过验证，可以搞一堆问题出来。

就是搜索框把九宫格键盘调出来，同时按三个键，多点几次就闪退了。
也不一定要同时，反正就瞎点个十几下~

试了下，IOS13.7 上也重现了。

我目前也在用这个，没有对 agileTC 做啥改动（就加了个按 F2 的快捷键修改主文件夹目录名）。
大的测试集，通过左边主文件夹给拆分了，所以一般测试集就一个人的（团队规模小也是一个原因）。缺点就是主文件夹有点多，空了把他这个自动展开全部给改改，这个功能我有点受不了。

测试地位严重依赖产品或者项目。
项目和产品越重要，他的测试越受重视。
出个问题都没人关心的项目，拿测试来有啥用呢？
相反，出个问题损失商誉，直接金钱损失，甚至直接导致拳头产品失败的项目，要是老板不重视测试，就等着现实教做人吧。

工资 2000 的，培训班不屑于介绍。。。

楼上的大叔们，我觉得我永远 18 岁。