能接地气的解决公司的测试需求问题就赢了

测试的目的是什么？初衷是什么来着？

是为了找到更多的问题。 用手工也好，用工具也好，都是手段而已。

我见过很牛的测开，但他是一个开发还是一个测试呢？我始终没有分的很清楚。
我也见过手工很牛的业务测试，他对于我来说更有价值，因为他靠分析和一些人工手段发现了更多的问题，是全局来考量的。
而那个测开，可能测试思路都是局限的，要么偏接口，要么偏前端 APM，找到的问题也都是局部的，不是全局来考量的。

管那些干什么， 在我们能力范围内，啥工资高干啥。

功能是有极限的，单纯的功能再现有的公司里基本上没有了吧。多少要懂得分析代码，抓接口都得会吧。

就是系统无论多烂，功能都没啥大问题。

还是需要看个人规划，我也有同事在我们公司做着侧开，换家公司后 去做手工测试 + 测开，手工测试偏多

你要知道 有很多 BUG 或者说很多测试场景 是功能测试满足不了的，再极致也是功能。 懂得越多会的越多也会事半功倍

基本看不到做到极致的人，所谓极致就得在一家公司死磕，现在新业务新功能迭代这么快，一旦有断层就玩完

能满足工作中各种测试需求就行。做测开工资也高些呀

我们这边的测开就是维护 ms 和 hr，偶尔写点小脚本，你跟他提需求基本上会被否掉。以前我们这边的测试经理是个技术大佬（现在去某个大公司做技术总监了），他要维护整个环境，排查问题，解决阻塞等等，这大概就是测开的终极形态了吧

metersphere 和 httprunner

过于理想，功能要测试好，离不开时间、经验，而时间基本上是不够的，有经验基本上就很难从一家公司跳槽了

需求刚出来时，心里就基本就知道需求的关键价值点在哪里；技术实现大概要怎么做，质量风险集中在哪里；大概要重点测试什么地方，非功能测试需要做哪些。环境出问题/出 bug，可以快速定位并解决，不被其阻碍太多时间。并行多需求测试时，可以 hold 得住不延期。

测试报告全绿。

场景 A：
测试经理：功能测试全通过，这个版本可以发布了。
项目经理 A：确定吗？可别像前几次啊，到客户那边就 bug 满天飞。

场景 B：
客户：测试是全通过了，产品功能确定没问题吗？
项目经理 B：嗯，确定。
客户：哦？那为什么有的产品还是 bug 满天飞呢？
项目经理 B：因为为他们产品做质量保证的不是我们的测试团队。

就是场景 B 这种样子吧！

目前我也是 5 年 10k（辽宁大连）
不过由于上家公司撤退（黄了），导致新换了一家公司
目前工作就是 基本的测试 + 运维的工作，感觉也是正常工作，学不到什么东西
但是疫情期间，感觉生活还可以过得去

让我们荡起双桨~

ms 和 hr 是啥？

二开能力很关键，找到痛点，用最简单的手法完成复杂的事，这才是能力。ms 毕竟已经开源，既然他先进，那就去学习。

metersphere 测试平台 和 httprunner 接口测试框架

那就寻求和其它平台的差异点，以及结合自己的业务痛点进行优化

早些年行业里面测试工具都是国外厂商，慢慢的国内厂商起来了，长远来看，团队作战才是王道

同是测开，最近一段时间也是做工具平台，但至少不会有这些疑惑。

因为一般顺序是：了解痛点/需求->调研业内相关解决方案（包括开源的、其他公司分享的）->没有/不完全适合，再内部自研/基于开源的进行二次开发

经过调研这一步，已经是确认外部的工具不完全满足需求，所以也没必要去纠结自己做的工具平台不如外部的。如果有这个困惑，可能是调研阶段没做好。

我在公司岗位也是测开，还天天做点点点呢，工具都大半年没写过了，只要工资按时发，无所谓了

ms 和 hr 是啥？
说实话，测开主要是解决问题，而不是非要自己去开发出一套新工具，哼哧哼哧搞半天还一堆 bug

如果是为写工具而写工具，的确会有这种困惑。可以想想你们公司中测试的痛点，然后从痛点入手解决。比如把开源的工具改得更适合公司业务，更方便使用。或者有些业务，开源工具测不了的，可以写工具。