我问个几个问题啊。
1。
我最近问我徒弟，你怎么看自动化，自动化的本质是什么？
我徒弟经过 2、3 年的几家公司洗礼后，回答 “本质是压缩成本”。
你怎么看这事？最终技术会不会让测试只能留下极少数的人，剩下的多数都是点工。同时大部分测试技术只会在一线城市的小范围内存在。
2.
工业界，我个人认为核心在于解决未知和已知的边界。
因为我人在二线城市，技术能力整体偏弱，测试不添乱就不错了。
比如说偏预研性质的团队，有没有测试参与，如何参与？
3.
DEVOPS 可能是趋势。
我狭隘的会认为环境治理的本质还是资源调度，资源流转才是真金白银。
支撑业务，维护大环境肯定是非常有价值，我不太懂，所以想请教一下，在这块有没有什么例子可以证明测试在 DEVOPS 中起了哪些价值？我也想了解了解。

这几个是我一直有的疑问。。。

https://www.zhihu.com/question/458099750/answer/2651545696,正好看到这篇。
哎，人都想有特效药，难啊。

怎么说呢。。。
你的经历我很难看出亮点，我觉得你现在所处的状态和你的经历基本匹配。
那么你焦虑的点在哪里呢？

你说你不够努力，那怎么才是努力，你觉得咋做才合适呢？你问别人，别人永远给不了你答案。
为什么要强迫自己打开眼界？打开眼界，没有执行力，最后变成人菜瘾大，不是更痛苦？

用不上他们说的技术点很正常啊，很多需要环境支撑的，我自己看了以前也用不上，这跟你个人关系其实并不大。
回到原点，还是你想做什么样的自己，愿意付出哪些努力，这才是最根本的事情。。。

你先把你想做的列出来，然后逐条分析一下，哪些是紧急重要的，先 DO IT。
但是这并不解决你的焦虑，根本解决之道还在于要让自己更强大。怎么强大都得靠自己。

翻译了这么多，那么楼主自己的观点是什么？
怎么左移？有没有实践？

嗯，这就需要小闭环了，要让上层阶段性的看到价值。
通过小部分实验的价值，去建立信任度，从而有试错的机会，才会有机会去做长期重要的事情。

嗯，回答的很好了。~
我自己会多想一层，什么是业务价值，什么样的业务才有价值。
这可能也和行业有关，AI 落地目前是 AI 最大的问题，场景、成本、价值等等。。。
目前在思考” 以终为始 “，但什么是终，没想明白。分享一下~

互联网会慢慢变成传统行业。
首先
国家层面意识到互联网的发展不解决卡脖子的问题，同时实际上减少了就业机会和人口。维持住现有行业就不错了。
粗放的靠资本跑马圈地的时代过去了，靠商业模式就能财富自由，概率只会越来越低，从上到下开始要求自主创新。这点可以从目前的各家创始人看出，越来越多的技术背景，尤其是北美背景的人开始创业，普通人基本没有机会了。

其次
对于码农来说，整体今年可能是未来最好的一年，但也必须认识到胜者为王，你能坚持下来，等从业人数慢慢变少，只要你比其他从业者性价比高就没有太大风险。但实际上不可能，相比其他行业，还是高薪，门槛并不算高，只会有越来越多的人想进来。

再次
我们的整体技术层次比较低，得益于人数的优势，可以加班，内卷，大量重复试错。还是 1 的原因，未来会进入深水区，以往的互联网经验将无法复制。部分大龄中 P 连转型的机会可能都不会有。

说到卷，昨天听个新闻，十年前教师资格考试的大概是 10W 这个数量级，今年是 1000W 的数量级，医师公比想象的还要卷。（教师资格考试报名人数由最初的 17.2 万人次跃升至今年的 1144.2 万人次）目前不是普通人能参与卷的。

最后
对个人，居安思危，尽量掌握核心资源，同时该卷卷，该挑战自己，挑战自己。大部分情况下需要靠自己，指望公司带你成长，条件过于苛刻，有机会，但是也要你能抓的住。

😓，我是纯软件的，也不会自己造硬件，硬件都是拿来主义。
这么说吧，就只讨论 CPU，应用层主要是调度。
如何合理的利用线程资源，线程资源是否独立，线程访存的数据独立性。
能否使用 VECTOR 向量，如 SSE,NEON 等进行加速？
这些都是软件范畴。
只能这么说吧，通常意义上的多数应用软件，其实并没有那么高的实时要求，所以对计算性能要求并不高。
也不会需要用性能优化方法去尝试优化包括底层通用库，因为对人，对成本都是考验。

但是你得这么想啊，你如果只能跑过三方工具，给个报告，这事和点点点区别又有多大呢。。。至少也得有我通过工具可以测试什么，关注点是什么，怎么闭环推动研发改进，如何改进吧。

我是做这个方向的。所有才有这样的疑问。
计算机组成原理的基础主要包括核心的几部分：

1. CPU 的流水线设计，通常我们所说的 5 级流水线。这里面不同的指令，操作的内容不同。
2. 内存的多级设计，包括 L1,L2,L3 的设计，为什么要设计多级缓存？芯片内部的缓存寻址策略。

回到软件层面上，目前通用的并行手段，CPU 级别主要是多线程，管程，SIMD 向量指令。
在计算层面，主要是 SIMT 的框架，如 CUDA。
不同的代码编写方式，使用不同的软件框架，可能会有数 10 倍的性能差距。
如果做到一定程度，需要有编译器的知识，理解如何去合理利用寄存器，利用图算法去减少指令，利用依赖分析去并行分发指令，等等。

回到内存的话题来，内存是需要严格控制的，对我们来说要严格控制 HOST<->DEVICE 间的内存 COPY 次数，尽量重复使用片上内存。同时程序设计时，需要用好 L2 内存，尽量在多 THREAD 情况下，减少 BLOCK 的内存读写次数。做深还需要考虑如 GPU 内部的线程调度方式，L2 的内存也要针对的做一定修改。

我说这些的意思就是就算我写出来的程序在 IO 上跑不到极限，也不是测试能测得出来的。

然后你说性能越来越弱，这个是事实，至少目前性能是需要给功耗让位的。但我觉得我们说的应该不是一个点，你说的弱，主要还是没人会改。现在开源的复杂度，能改的确实没几个，而且为了通用性一定会牺牲性能。我说的观点是能耗相对性能更重要，同时国内底层软件栈的人稀少，做通用更难，性价比也偏低。

好巧不巧，我好像昨天看到 NVIDIA 有做这部分性能测试的职位，所以才有一问。

从我的角度来看，这篇文章更值得去反思。
性能测试的路会不会开始就是错的？
工具应该仅仅是手段，而不是目的。当个体只能使用工具，却无法对工具进行针对修改的时候，人会更多的被工具限制。
从楼主的介绍来说，可能随便一个本科的课程都比楼主说的详细。
楼主提的问题，其实我想问楼主，你的答案呢？然后你的答案又从何而来？哪些是你自己的东西？

不是为了引战，只是在想，未来技术只会越来越深，这种对技术的粗浅理解，真的太容易被替代了。
PS：当然也可以说我只要比别人跑的快，死道友不死贫道，怕啥。。。

你要换位思考。作为测试 LEADER，如果只考虑我做了哪些，我有哪些苦劳，话语权肯定不太够。你话语权不够，为下面人就更难争取利益。
从老板/小老板角度看重什么？
一般有几个点：

1. 产品质量。
2. 在压缩生产周期的情况下，至少保证产品不拉跨。
3. 核心指标测试。
4. 工程部署

测试本身就是偏服务性质的研发职位，你要去实时关注老板预期，这几项哪个是最重要的，哪个是核心问题，并尝试去解决。
长期的 UI 测试平台，只能解决 5%-10% 的问题，长期老板肯定是不会满意的。

PS：这种吐槽，我都听习惯了。。。这里其实你自己和团队都应该有点危险感。。。

未来会有更多的中小企业主会尝试减少研发投入。
尤其是低端重复研发的投入。
转嫁到个体上，希望底层一个人可能干两个人的活，或者让你受不了自己走人。
竞争会越来越大，不突破自己，很难有机会。
但是如何突破，除了自己又没其他人能给你答案。。。
最后怕是都得回到人情/价值交换上。
PS：哎，越来越悲观了。但其实跟我又关系不大。。。

我还是 30 以后才开始蹦跶的。35 之后蹦跶越来越多。
其中心酸只有自知啊。
算是挺过来了，但是就算现在我也不敢躺平啊，技术进步太快了。
马上 40 了，基本上每周还在 LEETCODE 周赛。。。

我转过一些技术方向，有些事情需要说明一下：

1. 自学学历很重要，尤其是自学。
2. 自学的方向也很重要，至少应该是市场上比较缺少的，这样初学者才有机会。
3. 就算自学，也得给自己定个目标，比如 1 个月，2 个月，3 个月，如果你自己无法制定目标，这事基本就很难达成。
4. 技术作深都难，从来都没有什么所谓的学会了某个点就打通任督二脉的说法。只有真正理论结合实践才行。

B 站上会有一些教学视频，自学的关键在于摈弃自我安慰。
不要因为学会一个小点就沾沾自喜，这样只会裹足不前，等到几个月之后才发现懂得都是皮毛，这样是不行的。

投诉的频率是多少？
价值有多大？
用什么方法可以解决？
成本是多少？

如果真想解决问题，正确的解决方法是通过更高级的主管，拉通相关的利益部门，统一制定一个规则，有意见就当面提出来。
而不是通过一个最底层的员工去倒推流程。
又想有话语权，还想不得罪人。有事让下属扛事的人，注定走不远。

1. 权责分明是项目经理要考虑的事，因此按理来说测试应该评估的是测试时间，不了解功能，不知道如何测试，这个说不过去。
2. 说什么倒逼开发，社畜何必难为社畜，工时评估更多的应该是合作而不是 PUSH 这种。只靠 PUSH 其实是大部分小公司的做法，那就看开，该躺就躺。
3. 越是小的庙，破事越多，但是和你有半毛钱关系？你评估你的时间，至于开发时间那不是你该考虑的。提测时间是项目经理去协商，我就只反馈我要多久，提测晚了，压缩我时间，我该 DELAY 我就 DELAY。

不存在又高效又全面的东西，工程本身就是各种妥协。
有的时候有问题总要有人背锅，问题多了，是得想办法，本质还得看投入产出比。

先说结论：很难。
SDK 作为通用组件，对于业务方来说只是组成部分，对于 SDK 来说，你业务通常只是调用 SDK 的一个应用。
通常的做法都是业务去适配 SDK。
适配 SDK 的主要在于适配的成本，兼容性影响，SDK 的兼容性设计会成为瓶颈。
SDK 适配，对开发来说都是拉扯扯皮的麻烦事，沟通成本不会太低，对于更下游的测试，想测试 SDK 只会更加困难。
通过一些应用场景去覆盖 SDK 的功能，这可能是比较容易落地的。想根本改善 SDK 适配现状，这不是测试能解决的。

怎么说呢，这怕已经是你最好的选择了。
那就先苟着发育。
你去尝试做你能改变的事情，小公司测试就是打杂，如果你代码能力还行，人也机灵，做事靠谱，不会让你一直做测试的。
但如果这就是份工作，也是你能力上限，建议还是稳点。
作妖一般不会死，作死是一定会死的。

对人：
有能力就去做能决定工程效能的职位。
不想折腾就做好本职工作，有口饭吃也不错。
最怕的是井底之蛙，能力稀碎，还觉得自己都对。。。

对事：
只论质量重不重要，质量在特定情况下，确实能把产品从生干到死。
但是更多的情况下，产品还没脱离 DEMO 阶段，质量重要么？

请大概描述一下，你的产品？GCC,CLANG 你能测啥？你们硬件跑不跑的起来？
那不得研发或者架构师先做调研么？

太贵。
本质。
测试是个烧钱的必要保障，所以测试的使命，就是低成本地尽可能保障质量底线。
测试开发就是，当测试平台不完备的时候，用来补充的。

其实这才是我觉得答主有意思的地方，算是一种思考吧，下面的评论没什么意思。。。😓

呃。没看懂你想表达啥？
开发也很 LOW，数据和功能都没法解耦？

UI：变的最快，投入产出比低到爆表。
SDK：大部分不还是接口测试？往下做那不是和开发一样了？
芯片：吃饭的家伙拿出来说，这不是憨。