人生赢家~

反手让 AI 生成了几个，大家看看有没有违和感。

很多计划踏入或者刚刚涉足数据分析领域的朋友，经常会问 “数据分析好找工作吗？”“数据分析难学吗？”“做数据分析薪酬如何？”、“数据分析有发展潜力吗？”。
我刚涉足这个行业时也有同样的疑问和迷茫。一个根本的规律是，数据分析这个职业的价值取决于其能为企业和市场带来的价值。有价值，自然就有回报，也有成长空间。从各大招聘网站的数据来看，数据分析师的岗位需求和薪资水平都相当可观，这就证明了其价值。至于能达到什么高度，就取决于个人的努力和才能了。

很多对 UI 设计感兴趣或者刚开始 UI 设计生涯的朋友，常常问 “UI 设计好就业吗？”“UI 设计容易上手吗？”“做 UI 设计收入怎么样？”、“UI 设计未来有前景吗？”。
我刚开始时也遇到过同样的问题和顾虑。一个基本的认识是，UI 设计的工作机会和待遇是由其在产品设计中的重要性决定的。重要，自然就有机会，也有钱途。从设计行业的发展趋势和设计类职位的招聘情况来看，UI 设计师的需求和薪酬都处于上升趋势，这证明了其重要性。至于能否成为顶尖的设计师，就取决于个人的设计天赋和不懈努力了。

很多准备踏入或者刚刚开始网络营销领域的朋友，常常会问 “网络营销好找工作吗？”“网络营销好学吗？”“做网络营销能挣到钱吗？”、“网络营销有前途吗？”。
我刚入行时也有类似的困惑和疑虑。一个核心的观念是，网络营销的价值在于其为企业带来的流量和转化效果。有效果，自然就有市场和未来。从网络营销岗位的需求量和从业者的收入来看，这个行业是充满机遇的。至于能在这个领域取得多大的成就，就完全取决于个人的创意、执行力和对市场的敏感度了。

AI 在知识搜索、问题排查、简单功能实现等方面提效还是很明显的。

但是 AI 代替测试，以我浅薄的认知来看，短时间内做不到。

也就能达到个增效提质不降本的目的。

我大乐透五块都没中过

行业前几都这么艰难。。。

很棒，这才是生活

没经验、没有相关技术强人带、没算力，还是老老实实调 API 吧

以业务为锚，辅以代码走查进行评估。
另外回归测试吧，不存在无意义，至少证明某种场景是成功的。

为啥靠前 30cm 呀，前面凸出来咋整。。。你要是停个迈巴赫或者尊界这种长车，不得把路挡完~~

L034 能入绝对第一选择，独立车位谁用谁爽。
其他就 35 36 77 76 吧

让开发把测试环境调用拍照的方法改成读取指定的照片

兄弟，你 ID 暴露了公司，你是真不怕 charles 给公司发律师函呀

别焦虑，死亡的方式很多种，食品安全是其中起效最慢并且可以避免的一种，健康过好每一天比担心十年之后好。

1. 测试要对整个产品的质量负责，而不是针对某一个需求（甚至是未经评审的需求）。
2. 做好需求评审，避免出现没在需求内的功能点。
3. 做好和产品、开发的沟通工作。

多打几个日志就看出来了吧。

不过像这种查询没出过问题，提交数据有问题来看，可以考虑以下几个方面：

1. 存数据库的逻辑是不是有硬伤，未处理的异常、死锁、死循环啥的
2. 量，是不是写入量太大了，导致服务器或者数据库资源瓶颈
3. 其实和 2 也差不多，一个从客户端考虑，一个从服务端考虑。不响应时看下服务端负载
4. 浏览器（或者前端软件）本身兼容性或者其他问题

仅供参考。。。

以现在的国际形势，不考虑生命安全的话，雇佣军很缺人。

你年测 300 万行代码，年看 300 万字的小说，年产生 3000 万的价值，为 3W 亿的负债贡献过，世界因你更加和平。

没发现 BUG 或者发现的少，正常的老板也会认为有价值的。但是 BUG 少=你价值低，这一座大山是所有非测试人员的共识。

只要自己觉得合适，你用 txt 管理都行

偶尔借出->频繁借出->组织重新划分,合并到项目组->测试边缘化

友情提示，fiddler 自己学倒是没啥，公司或者企业使用有可能被发律师函~

供参考哈，仅个人思路。

1. 先明确业务问题

下架报异常导致的下架失败，是真失败还是假失败，这条数据还展示的 c 端商品列表，是应该展示，还是不应该展示。

如果下架接口报异常，但是实际是成功的，比如数据库状态发生变更等，理论上 c 端商品列表不应该展示，那就结合代码或者开发人员去定位问题，此时应该要去定位三个问题，a.下架接口报异常的问题 b.下架接口报异常，但是却成功下架的问题 c.下架接口报异常，但是成功下架，C 端商品列表还展示的问题

如果下架接口报异常，实际也是失败的，这条数据应该展示在 c 端商品列表，那么就需要看下架接口为什么报异常。是环境问题还是需要定位的缺陷

1. 再回到自动化测试本身

从得到的信息看，是接口自动化测试，那么以上场景应该划分到下架接口，还是展示的 c 端商品列表接口（比如下架失败，展示商品列表接口的用例），应该有明确的规范，避免用例重复覆盖。

另外，这条用例失败后，会不会影响自动化测试稳定性，自动化到这里就不再执行了，还是说就是普通的一个用例失败，也是需要考虑的。

自动化测试用例，很多时候因为各种原因，不会覆盖异常、失败的场景，此时是否需要把这些场景支持或者用手工测试覆盖，也是需要考虑的。

研也匆匆 测也匆匆 恨不能想疯
改也匆匆 上也匆匆 一切都随风
狂测一轮 延期一轮 快上一轮
背锅一轮 谁与我生死与共

有，如果看不了代码，会给工作增加很多困扰和不确定性

窮