老兄是要质问你们的测试部？

可能在编写者角度，对于项目业务本身的测试是基本工作目标，不需要特别提出。
反向其实还需要看项目本身对测试是否足够重视了，如果项目只求稳定、能用、基本符合需求就行，测试很多细节或者业务逻辑的实现是测不下去的，容易失去对业务、项目的执着。这部分需要产品、开发共同配合推动。
「玩点花样」是指接口自动化、UI 自动化么？ 这不算花样吧，对于已经固定下来的交互自动化是很有好处的，这也算是项目本身有益的事情。当项目功能模块增加，每次迭代都需要人工回归测试不是一个好事，自动化有助于提高测试效率，更多时间专注在新功能的测试。
不 “玩点花样”，老老实实测项目～项目稳定运行，实现需求，这不就是个好成绩了么？但是又会被认为没什么成绩？

挣钱不寒 chan，真的

按照我们公司的情况，目标分为门槛目标、基准目标、挑战目标，完成项目的基本测试工作属于门槛目标，是公司对部门的要求，完成了才有工资钟的绩效工资部分；基准目标、挑战目标就是部门对公司的承诺，完成这个承诺，公司支付响应的奖励。
所以完成项目测试和其他的超越项目的工作是不冲突的。

换个角度。
两个问题：
1.你说你为了质量做了很多事情，如何量化？
2.怎么证明质量的提升是测试的主要改进，而不是开发架构的改进？
这种问题在我看来就别多想，既然做了测试，简单点好，领导要干嘛咱就干么。

有没有一种可能，所谓的不关注项目本身是因为他们是专职弄效能的同事，或者是已经完成项目的基本功能测试想要追求效能提升。

有目标不可怕，可怕的是为了达成目标 “不折手段”
不惜投入大量人力资金，结果只为实现阶段性目标这种就很吓人了。

不过，对于底下干活的人也有好处。就是能有让你试错的机会，达成你自己的阶段目标。
不管怎么说，做多少说积累经验。

测试本质就是保质量，质量出问题一样背锅，所以其实写不写项目测试都差不多，这是本职工作，如果用 OKR 的话一个 O ，KR 里列出几个需要重点投入的项目足矣。
其他的无非就是围绕着质量领域的效率提升和成本降低。一般首先被关注到的，无非是流程优化、各个端的功能自动化、性能/安全等专项测试工具能力、监控建设、反馈跟进……说白了就是造框架、工具、平台、方案。
只要不是本身就对测试部门有怨气，其实是不会理解歪的。这个场景我觉得应该是测试部门之前做得不好，让楼主觉得这个目标是不务正业吧 。

测试项目本身是本职工作，做的自动化这些，不就是为了项目本身做的嘛。

也要看绩效的导向是什么，如果本职工作做得再好，也比不上整花样的，他们这么做我觉得人之常情。

另外对项目本身来说，可能有些属于样子货范畴，但是对人来说，他们有自我实现的需要，有想进步，想不被淘汰，保持竞争力的需要，有技术储备的需要，花一些成本在上面，我觉得也是可以的，理想的情况是能落地，能验收，能持续用起来并进行改进，并且项目因此而受益。

个人觉得可以不用关注他们玩什么花样，只要对项目有益，关注这些花样落地、效果、持续改进方面即可。

我想反问一下，项目立项的时候，没有效能的要求吗？如果有，那做效能相关的目标就是有益项目的。如果没有，这个项目居然能立项。。。

测试是一个矛盾的职业。拿我朋友（无中生友技能发动）的一个公司举例：这哥们是测试主管，第一年的 OKR 写的是，从 0 到 1 成功组建测试团队，规模从 1 人到 10 人 blabla，第二年 OKR，通过技术研究降本增效，成功将人力成本降低 90%……是的，他又成光杆司令了 一个不可能三角就是：测试全面 vs 测试迅速 vs 测试成本低

目标是追求你希望达到的，已经达到的是继续保持

人力成本降低 90%，那我想问，开去的另外 9 个人的工资都给你朋友了吗？如果没有，那他这么做的意义何在？

是他把人裁了还是跑路了

通常对测试来说，KPI 或者 OKR 里面首先最重要的是测试达成情和测试质量管控（一般有些可测性、测试完成性完整性、质量达标情况）；然后是追求效率为主的易测性，追求测试深度（主要针对一些疑难杂症问题）的测试专项建设，属于锦上添花，很明显自动化测试什么的属于这块内容；再就是追求测试影响力（如测试右移左移建设）、测试成长，有些偏向测试知识库的建设、测试人员培养，小组、部门甚至行业测试方案、专利等；

再说说自动化这个事情，应该是个非常实事求是的工作，对它有个清醒认识非常重要。实施自动化的被测对象是什么，为什么实施自动化，在什么时候实施自动化，怎么实施自动化，自动化方案选型，人员培养，自动化维护等都很重要。现在业界很多公司都做自动化，但是真正把自动化做好的非常少，尤其在 UI 自动化方向很多公司都踩了不少坑，最后不了了之，至少我待过的三家大厂都这样（包括某 A，某 B）；但是说回来，对个人来说折腾折腾总归是没有错的，起码换个厂面试的时候可以很体面（手动狗头 +_+）。