背景 年前老东家裁员，我了解到的是原来不跟业务，纯做
测试中台的几个同事基本都躺枪了，而
技术不太行但是业务比较熟练的同事都留下了。这一波去中台化就很明显了。 由于我在老东家也做测试中台，结合最近工作的感触，想聊聊这个事儿：测试到底需不需要中台？
测试到底是干什么的？ 我认为，测试工作的本质，就是平衡质量与效率。为了不出事故，总不能一点儿不测吧；为了能尽快发布，总不能事无巨细的测吧。执行质量和执行效率相同的前提下，用例越多，测试周期越长，质量越高。
但是问题在于，用户会在意产品质量是不是100分么？并不是！精致的用户在意体验，严谨的用户在意稳定，大部分用户只在意能不能用。用户普遍接受90分的质量。这90分里，通过项目流程、Code Review、RD自测保持到60～70分，剩下的20～30分就是QA的工作。这部分需要通过
需求分析、
用例设计、测试方案设计、测试执行等一系列工作来保证。
比开发更开发，比小白更小白 A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd. First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.-- Tweet QA作为一个“臭挑错的”，既需要了解自己面对的是什么，也要具备跳脱在外的能力。既可以用魔法打败魔法，也可以用热兵器打败魔法。 技术是对工程师的基本要求，而好多人忽略了测试工程师也是工程师。在面试的时候，经常会听到候选人说自动化、测试左移，但是却连需求的技术方案都说不清。如果方案选型都错误了，自动化全覆盖又能怎么样呢？还不是返工重做。一个合格的QA，需要具备一定程度的技术广度，与技术深度占有的RD形成互补。 但是测试作为进入IT行业的“捷径”，具备技术广度的QA非常少。
比产品更产品 我认为这是QA与RD最大的区别。RD的工作是可以脱离业务的，但是QA不可以。站在业务线的角度，需要QA用自己的技术能力快速高质量交付产品，而中台强调的是横向能力、业务无关，所以中台与测试在本质上就相悖。这种前提下拿出来的框架也好、平台也好，在业务里并不好用。我用Puppeteer / Selenium /
JUnit / XCTest就可以完成的自动化，为什么还需要你封装一层呢？这一层封装，对我的自动化、对我的业务有什么价值么？ 测试中台的成立，占用了技术型QA的HC，这其中又有多少人甘愿回归到枯燥的需求测试中呢？所以回到最开始的背景，如果需要我决定QA团队的裁员名额，虽然不忍心，但我也会把中台放在前面。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
权威发布，测试选择不纠结！第15届软件测试行业报告，直击行业发展，把握未来方向！
