没有产出，发现不了问题，这种状况的确很打击测试人。不过你可以从以下几个方面入手去改进你的测试方法。

第一，你提到 API 自动化测试在需求变更后需要投入维护，那么你可以尝试改进你的框架技术，让你的维护工作变得更加轻松顺利，比如说吧，一个需求改动，你要做的是新增一个类，而之前的代码不用动

第二，主动与开发，业务测试人员沟通，挖掘他们的痛点，作为你分析自动化的切入口，以此来开展你的工作

第三，现成的平台，系统使用的实现方式，完全有可能在某些方面不好用，比如编辑界面，报告界面，操作流程，等等，可以从这里入手，去开发一个比它更优的东西出来

能做的工作其实有很多，需要多思考，去发掘潜在的需求点。

提高效率，保证质量的事儿才有价值，脱离这两点都是耍流氓

怎么转？抓住一切可以的机会，比如，研发不愿意做的，你接过来做，慢慢的一点一点的揽研发的活，边角料的活，用代码解决。大概就可以达到你的目的了。我就是这么做的，发布代码，一开始就是把 war 包手动拖到服务器，频率很高，研发懒我说我来，然后我就慢慢的搞成了持续发布。谁说不可呢。加油

首先你为啥做了测试？是因为开发做不来还是因为开发做得苦？其次点点点和你在的公司很有关系，你得熬过了这个阶段，在过程中自学其他测试知识，才能受到重视，不然谁都不会重视懒的人。

有人没活儿干,有活儿没人干.
大多数人实际都是生产没用的东西，千万别自信饱满；

回报很少： 如果同样的手工回归回报也很少，是不是也会考虑不做呢？
API 自动化需要不断维护： 如果框架设计得好，能把维护的工作量降低， 就不成问题了。
改进： 建议你从懒人的角度去思考，就会发现很多可以改进的地方。

你可能有点误解了自动化，个人感觉自动化就是要不断维护的

已由测试技术转工程生产力，说白了就是所有能提升生产力的都做。。

你说的是很初级的自动化测试，楼主并没有误解
当然我相信，有效率、能发现问题的自动化测试迟早也会被你们改个名字换个新说法的，因为他已经明显不符合你们对自动化测试的预期了

你可能有点误解了自动化，个人感觉自动化第一要素是在稳定的功能上去自动化，主要是做质量保证和部分回归，如果要发现问题手工测试才是王道。文中表达的观点都是去发现问题，而你文中所述的平台都属提升测试效率和质量保证的，这本身没什么关系。

快转吧

有内部机会么？最好内部转

能转赶紧转，开发一定比测试好。

你喜欢就好

想转开发就能转？测试都做不好就能写好代码了？先具备转开发的能力再说吧，loser！

那也要看出发点对不对，楼主（摘抄别人的吧）这种心态就是做啥都不会做得好的那种

能做开发就不要做测试。

有想法就去实现，不要顾虑太多。可以一边工作一边学习开发知识，利用一切时间。就是找第一份开发工作有点艰难，入行就好了。

我公司就很重视测试啊，很有话语权。产品做不好，会被测试说、开发质量不高，会被测试说。他们都很欣然接受测试提出的建议。
你要让他们觉得给你测试质量很高，能够提升他们的工作质量，能指出他们工作的缺陷，起到一个 “控制质量” 的作用，别人就很敬佩你了。
说外界不好不好的时候，还是先看看自己的能力如何。

我和楼主在公司有同样的感觉，但是我觉得不是公司的问题，问题而在于自己，如果自己的技很牛逼，就不会有这种情况，做好功能测试也需要很多知识，还是安下心来多多学习技术很富自己吧

同意楼上，虽然我现在也偏功能啦~
但是接口啊，自动化啊，测试的一些工具都会一点啊，对工作帮助还是比较大的~

楼主目前看来是在一个很不规范的小公司工作，测试这个职位专业性很强，不是谁都能做好测试的，测试很重要的一点就是测试的全面性，敢问楼主如果不懂产品上线后的目标，不懂代码内部的实现，如果才能保证测试的全面性？功能测试表象是功能，但实际上需要对后端的设计有全局把控，对接口定义非常清楚，才能测试的全面，否则上线后肯定会有 bug 产生，楼主建议还是要端正心态，多学习，我司的功能测试工程师测试的内容绝不仅限于功能，在整个项目过程中都起到了一个关键性的作用，产品不合理的要求完全可以在需求评审时提出，开发的接口设计如果你足够经验丰富也可以给出建议和意见，总之 能做好功能测试也是不容易的

测试开发要求低吗？要怎样的水平哇

发一篇老鸡汤。常读常新。
https://www.cnblogs.com/skytraveler/p/3546703.html
btw，感觉有一句话特别重要：不要给自己设限，一切以解决问题出发。
长此以往，你就会做得很好，是不是 QA，无所谓了。

可以发个贴讲讲经验嘛