现在对于测开而言，和传统测试最主要区别首先肯定是代码能力，因为不管是自动化脚本还是写工具平台，都需要这块能力，还有比如环境运维能力，排障能力，需要熟悉团队使用的各种中间件或工具平台等，有些甚至还要兼顾业务测试，但又不一定每个测开都是从传统业务测试成长上来，不少一开始就直接是做工具的了。都说测开是为测试服务的，然后测试又是要求需要熟悉业务的，熟悉业务的一个重要体现就是能针对业务需求设计有效测试用例并执行，所以是否测开也需同样具备业务和测试用例设计基础能力？如果是，其他测试工具链或测试框架支持能力的持续学习本身也是一块很大的投入，业务熟悉和技术产出如何有效去平衡？
不为业务服务的技术都是耍流氓。不懂业务的测开不是好测开。测开很重要的一个工作职责是发现和解决测试过程中的痛点，有可能是工具，有可能是业务，还有可有是其它。
不需要，老油条的我现在测试完全是先按自己对需求的理解来测，后面才对着需求和 UI 进行测试，完全不走用例
个人认为，是需要的。测试用例是测试思路或者测试思维的具象化体现。测试用例的作用更多的是增加你的测试的覆盖率，防止测试遗漏。如果觉得自己只凭经验或者自己的想法去测试，没有先整理出一套用例去保证覆盖率，我觉得只是一种投机取巧的行为。但是肯定不要过多的去投入用例上，可以体现你的测试思路并且可以对写出的用例进行查漏补缺就可以了。比如可以用脑图、因果图这些，效率更高一些。
个人观点：需要，但要求不会很高，能做就行，核心是要满足自己能设计自己开发的功能的测试用例这个场景的需要。
但又不一定每个测开都是从传统业务测试成长上来，不少一开始就直接是做工具的了。
这类测开一般也需要学习测试知识，甚至有需要的话到业务组轮岗做一下测试。只是技能点偏向于做工具开发，并不代表不需要具备测试用例设计能力。不真实了解和做过测试的测开，体会不到测试的痛，很容易跑偏。
看看你自己的方向，任何技术都是基于业务测试起来的，所以测试开发的岗位也是如此
测开还是要懂得测试相关的知识和思维，否则就不是测开，只是一个普通开发，而且技术能力还不一定有人家专职开发强。测开不仅要有测试相关能力，最好也要有产品思维，了解测试痛点，了解产品核心，以此为基础的测试开发。
本人观点：需要。测开交付的工具平台服务于测试与开发同学，最终是要用于支撑业务，保证质量，提升效率。所以对业务的理解与测试的设计都需要。否则开发出的工具平台不接地气，无法达到目标。