每到年底的时候，不管是个人还是团队，总是避免不了要对这一年的工作成果进行总结和汇报。而对于测试开发岗位来说，通常会面临一个共性的问题：做了这么多事情，究竟产出了多大的业务价值？
在很长一段时间内，我对这个问题也是非常困惑。困惑的原因倒不是觉得工作内容没有价值，而是对于测试开发类的工作，通常没有明确的业务需求方，对于工作成果度量也没有统一的方式。
为什么测试开发岗位会面临这个问题呢？
这应该和测试岗位的职责和工作内容有很大的关系。关于测试开发工程师的定义，在《Google 测试之道》一书中已经有了很全面的解释，我也很是认同。测试开发工程师（SDET，Software Development Engineer in Testing）首先应该是开发角色，只是相比于业务开发工程师，他们的目标用户更多的是公司内部的测试人员（也包括其他岗位的项目组成员），而核心工作内容就是提供通用测试技术解决方案，开发实现测试工具或平台，协助测试人员更好地完成测试工作和项目交付，而效率和质量也是他们最为关注的方面。
从岗位职责和工作内容可以看出，测试开发通常不会直接参与业务交付，并且他们通常也不会隶属于具体的项目组，因此对于他们的工作到底产出了多少实际的价值收益，在上面的领导或老板看来就不是那么明确，最终他们面临价值产出度量的问题也就在所难免了。
本文就围绕测试开发价值产出度量的问题，谈下我的一些思考和建议。
何为业务价值？
我们总是在说业务价值，那业务价值究竟指的是什么？为什么同样是写代码开发系统平台，大家通常会觉得开发电商、售后平台是产出业务价值，而开发测试工具平台就不产生业务价值呢？这种想法是否正确？
其实当我们回归商业的本质，就会得知问题的答案了。对于商业公司来说，通常是以盈利为目标的，而为了达成这个目标，就需要通过业务手段，对用户提供价值，最终获得用户的买单。从这个角度来讲，决定是否对公司产生业务价值与岗位类型无关，也与开发实现了什么系统或平台无关。例如，对于提供测试类服务的公司或项目组来说，例如听云、WeTest，开发出的测试工具平台就直接面向客户，并以此获得盈利，那么参与该类项目的测试开发工程师就直接产出了业务价值。而在绝大多数非测试服务类商业公司中，测试工具平台更多是提供一种辅助手段，帮助项目组更好更快地完成业务需求交付，而并不直接创造业务价值。当然，这个问题不仅在测试开发岗位上存在，对于某些开发岗位也是同样存在的，例如开发公司内部即时通讯工具、流程审批工具、消息网关、中间件等等。
因此，对于测试开发岗位来说，不必揪着 “业务价值” 不放，我们完全可以从其它角度来对工作成果产出进行度量和展现。
节省人天数？
那要使用什么度量指标呢？
在很多时候，大家可能会想到使用 “节省人天数” 这样一个指标。因为测试开发的主要职责之一就是提升测试效率，那如果能度量出在使用测试工具平台后减少了多少人力投入，那么就能很好地体现该工具平台的价值。
那么要怎么计算 “节省人天数” 呢？之前我们使用过的方式如下：
- 统计出项目的回归测试场景，以及在固定周期内的发版次数（假设为 N 次）；
- 估算出通过人工去执行这些测试场景的耗时（假设为 M 人天）；
- 统计出工具平台执行测试的耗时（通常该耗时可忽略不计）；
- 那么节省的人天数就为：N * M
乍一看，这个思路没啥问题，也能计算出具体的节省人天数。但在实际项目中尝试运作之后，我们发现该计算方式存在比较大的漏洞。
例如，某测试工具平台在 A 项目组投入使用后，通过计算，每月节省了人力 10 人天。可是，A 项目组的发版频率并没有改变，项目组人员编制也没有缩减，甚至根据招聘需求，人员编制还出现了增长的情况。那在这种情况下，通过计算得出节省的人力去哪儿了？
对此我们并不能给出很好的回答。事实上，测试人员借助测试工具平台从之前的重复手工工作解放出来后，他们可能花了更多的时间在需求分析上，也可能花了更多的时间在测试策略设计上。这都是我们所期望的结果，但问题在于，这些内容我们并不能很好地去统计和量化。这也就导致我们统计出的 “节省人天数” 缺乏说服力。
而且从更宏观的层面来看，度量项目组的质量情况时，更多是会关注交付效率和线上质量（漏测率）两个维度。交付效率，可以通过 “交付需求数/投入人天数” 进行计算，而线上质量（漏测率），可以通过 “线上 bug 数/测试发现总 bug 数” 得出。可以看出，线上质量（漏测率）与 “节省人天数” 基本没有关系，而交付效率方面，除非项目投入人天数真的减少了（通常不大可能），那么交付效率也很难通过 “节省人天数” 提升。
因此，“节省人天数” 并不是一个可行的度量指标。
建议的方案
那有没有其它更合适的度量指标呢？其实我也没法给出绝对正确的答案。
针对这个问题，我也请教了多位测试行业大佬，收获了诸多不错的建议。
其中，茹炳晟给出的一个观点给了我比较大的启发。我们可以反过来看，现在有了这些测试工具平台各个项目组可能都在用，那假如没有了这些测试工具平台会怎么样？是毫无影响？是变得有点不大方便？还是无法正常开展工作？问题越严重，说明工具平台本身的价值就更大。这也可以作为我们不断自我衡量工作成果产出价值大小的一种思路。
但要更好地进行量化，用户使用率会是一个比较不错的度量方式。
回归工具的属性，假如一个工具真的能帮助项目组带来价值，不管是效率优化还是质量提升方面，那么项目组成员肯定会更多地使用该工具；否则，项目组成员完全没有理由在这些测试工具平台上投入时间，因为使用也是有人力时间成本的。特别是在没有强制要求项目组使用的前提下，最终工具的覆盖用户范围和使用频率更能充分说明问题。这和当前各商业工具平台追求的用户数和日活数也是同样的思路。
因此，在 2019 年，我们也打算改变下思路：
1、在质量部总体层面，不再对各项目组制定自动化测试覆盖率的目标要求，对于项目组测试人员的考核方式也不再关注测试工具平台使用的情况，最终只重点关注交付效率和线上质量两大维度（统计方式同上）。
2、对于测试开发团队，测试工具平台的价值展现将更多地通过覆盖用户范围和使用频率进行展现；若要更多的提升用户范围，那么就需要更主动地去挖掘业务项目组的痛点，让开发出的工具平台能帮助更多的人（目标也不再局限于测试人员）解决实际工作中遇到的问题；而要达到比较高的使用频率（日活数），那么就势必要提升平台的可靠性，对问题反馈进行更快地响应，以及进行更多的宣传和推广。
当然，除了用户使用率（覆盖使用人数、日活数）这一类最核心的指标，我们也会关注其它的一些指标，包括：故障响应效率、平台可靠性、发现问题数、口碑评价反馈、响应需求数等。总之，这些指标都是可以明确度量和展现的，并且所有指标最终都将指向用户的实际使用情况（Adoption Rate）。
写在最后
有时候我不禁在想，做测试开发这个岗位也真挺不容易的。我们不仅需要负责需求规划和交互设计（想清楚要做什么），然后是开发和测试（将想法实现落地），并且要花费较多的时间和精力去进行推广（获取反馈及时调整），最后还要对工作成果进行度量和展现（收获价值认可，获得更多资源），只有我们开发出的工具平台最终在各业务项目中得到了很好的应用，才能说明我们的工作成果产出了价值。
这个过程跟创业真的挺像的，我也一直都是希望我所在的测试开发团队能更多地用创业的心态来对待我们的工作，而整个经历的过程，也许就是最大的乐趣所在吧。
讲的不错很在理，在绩效制定的时候，我们设定的绩效指标，文章都提到了，文章还提到了我们没有考虑到的指标，有帮助
也是一种思路，学习了
当我们做的任何东西在业务线都推广不下去的时候，就想着要放弃了，2017、2018 年两年做的东西基本都没有落地，现在是基本走到头了，各方面原因吧，测开搞得真是心累
最近我们也在从服务测试的角度转向去服务更多的不同职位的人员，从而去开发更多适合并能实际解决用户群体痛点的平台。
首先点个赞，发表一下拙见，个人觉得不管是项目组测试人员还是测试开发，统一的目标都是提高产品质量，可能测试开发还要注重效率多点，那么关注点就应该是质量，可以统计下该项目组在使用回归工具之前的漏测率和使用工具之后的漏测率来对比作为测试开发的度量指标（可能实现起来不太现实），而用户使用率，不能直接的反映出回归工具的价值，因为可能存在工具不好用，或者测试人员使用工具已经成为一种惯性的因素
我个人理解：
开发单元自测、集成测试不到一定的级别，整体的质量要求不会太高。
那么整体的质量驱动研发的程度就会下降。
你做更高的通过工具驱动质量提升就是空中楼阁，很难见效的。
毛驴
回复
嗯，总体目标是一致的，就是业务交付效率和线上质量情况。这里制定的指标其实也是相互依赖的。
对于项目组测试人员来说，要想达到更高，肯定就得借助一些技术的手段，可以选择使用我们测开提供的工具平台，也可以选用别的，没有限制。对于我们测开来说，要达到更大的用户覆盖率和日活率，就得多考虑怎么给项目组提供更合适的工具，让他们对我们的工具平台有更多的依赖。
对于你说的因为惯性，即使工具不好用也还持续使用的情况，在没有对项目组测试进行强制要求的情况下应该是不会存在的，因为他们一方面不会有工具使用方面的考核压力（目标导向，做不做自动化和技术建设都完全没关系），另一方面他们也完全可以去选择使用其它的外部工具。
学习了，想到了几点：
- 测试开发价值产出平台呼之欲出：两种方式都要有，1 是节省人天数的计算，2 是使用率的计算，这两种方式都需要算法来落地，而算法的原理需要达到测试部门的共识。同时其中讨论的东西相当多，如项目特别重要则使用率即使很低，但是权重很高，得分也应该很高；项目特别紧急导致的使用率密集，但是全年长时间段平均较低，这种得分也要有考虑；项目人数基数大，使用的人多，等等，要覆盖全面要思考的太多。
- 如何记录使用率和节省人天数，平台要有各个接入 API，适合各个语言的，所以这个平台是个大项目，未来肯定是分布式异地多活的（数据重要丢失损失 KPI），设置大数据延时统计数据展示的。
- 大疆的人真的辛苦（想到了猝死的哈工大学生，惋惜）。
其实我觉得，测开往往就是一个兼职的岗位，平时的主要工作还是各种实际落地的测试任务，测开的工作往往是测试人的锦上添花，因为你脱离了测试任务和全职测开可能会造成闭门造车的尴尬。
同时全职的测开岗位还需要有产品经理吧，是整个一套的项目开发流程的，评价全职测开的 KPI 就和评价开发的 KPI 几乎一样了。
这也分岗位分工的。
zyanycall
回复
你提到的这几点我们有些在做了，但不会搞得那么复杂。
数据度量机制肯定是有的，我们会明确每一个指标的计算方式，达成共识后固化到平台，自动采集并进行展示。在项目人员角色上，我们也会增加工具产品类的角色，负责需求规划和版本管理方面的工作。
但权重方面的话我们就不会考虑了，会引入太多主观因素，凭空增加了复杂度，最终可能也很难具有说服力。
至于 KPI，其实我们这里是没有 KPI 的，做这些东西更多还是为了更好地度量我们的工作成果产出，进而指导我们的工作优化。
magicyang
回复
质量保证是整个项目组的事情，不能单纯靠测试人员。所以我们在开发测试工具平台的时候，目标用户也要拓展到整个项目组成员，除了测试外，开发、产品、运维等角色都是要考虑进去的。
zyanycall
回复
个人觉得测开还是开发，只是客户是测试甚至是研发团队，需要熟悉业务，知道痛点，思维和业务开发不同，要具有测试和开发双重思维
就是因为测试很难衡量价值，所以跑去做开发了，就是头顶有点凉
首先测试开发他是一名测试 (懂开发也许能胜任测开,不懂测试的很难胜任测开); 将测试开发及测试区分开,单独成立服务团队,对于很多项目团队不现实 (大厂除外),个人所接触的都是在测试岗位兼职搞…其次测开’ 辅助位’,不经辅助的是测试’AD’,后期团战时辅助的是团队,打得好坏并不是看他的人头数,而且抗了都少伤害,补了都少漏兵,救了几次队友,插了多少眼位 (这个很重要);领导关注多的可能是人头数,经济,推塔数,伤害输出…这种思维很难被更改.可能这也是为什么大家不喜欢拿辅助位的原因吧.
其实不仅仅是测试开放，跟测试相关的职位都很难去度量价值。作为测试开发，如何去度量价值？当然作者提到的我都同意，但有时跟具体做什么东西关系很大。 例如我曾经给某团队做了个工具，让团队测试从抽测到全测。 也写过某个类似爬虫平台，公司每年省下 $30W+ ，这些也都是可以去度量的价值。
在做研发效能提升的工作之前，是要明确结果度量指标的，这方面需要与业务的同学达成一致。一方面是能够与业务同学在做研发效能改进方面的目标达成一致（落地推进相对容易），另一方面从最终的结果数据中可以度量业务改进的效果，进而可以对后续的改进优化工作有相对明确的指标指引。
能不能考虑这些指标呢, 持续集成通过率，每次发布补丁数，每次发布耗时，线上故障剖尸分析
国文
回复
你的意思是测试平台作为一个对外服务的平台，从平台本身的角度去考虑这些指标么？
我的感觉如果是这样的话，项目组可能不大关注平台本身的这些数据。
国文
回复
落地业务团队指的是业务测试同学么，也就是这些测试平台的终端用户？
针对这块儿我们是去度量平台的稳定性方面，包括服务可用时间、线上 bug 数；以及对于问题的及时响应度，例如 bug 修复响应时长这些。
我一直觉得测开首先应该是测开，现在要看公司对测开的定位。
- 工具平台的测开，首先是开发，业务领域是测领域能力的理解和积淀。就像开发是支付的开发一样，对支付领域的业务理解很深。
- 测试组的测开，首先是测试，这是本职工作，是一个岗位，业务是对所做的产品的业务领域能力的理解。
我个人看法，也是目前再做的。测试开发==开发，只是定位不同，测试开发主要完成的产品是测试使用的平台或者提高测试效率的工具，而不是对外，持续不断的满足测试业务需求和测试平台是测开主要工作。对于衡量，其实也可以从版本发布周期，比如我们开发的一个自动化测试工具，可以原本测试内容常规测试，直接去掉，这个就可以算做测开的产出，设备共享平台，有使用率，使用分数，使用量，然后对比目前市场调试的 1 分钟多少钱，就可以知道省了多少成本，这也是测开的产出，小工具，平常是怎样花多少时间，目前有了这个工具，省了多少时间。至于有了测试工具及平台，有的不一定就能省测试周期，其实这个就是自动化的目的，老板也许认为有了自动化工具，就等于可以减少人，加快工期，其实不是的，测试自动化是提高效率跟保证效率手段，让人工释放出来，想更多的事，做之前没有考虑，来提高项目质量，至于项目质量也是不好评估是因为了这个来提高，但可以从发现的 Bug 来做标记，也是一方面的体现。我感觉是挺多可以衡量测开的价值，重点一开始就是你怎么看测开，怎么评估产出。一开始没有数据，用内容来说是很正常的~
如果考虑到效率和使用率，也为了自己； 测试开发的工具 开始就是将他开源，一部分面对内部用调整，一部分面对市场用户调整，同事吸收外界工具优化自身；证明自己的价值，便捷的就是得到外界的肯定，同事开源的工具也可以给好的拓宽自己的眼界；
比较赞同，我们目前基本也是这个思路在做，Case 覆盖率，节省人天确实都是伪指标。另外一点，我们目前还会重点看自动化在 CI 管道中的有效性和效率，主要目的是推动项目团队整体效率提升。包括 CI JOB 执行频次、JOB 失败恢复平均时长，JOB 成功率（这个太高、太低都值得关注）等。
写的挺不错的
让测开独立推动产出就是耍牛氓，测开背后要有一个懂产品的测试经理，共同规划及推动～
首先要问一个问题，为什么要测试开发，才有了测试开发的重要性。
一直挣扎在业务测试与工具开发之间，羡慕大佬们的公司还能给个明确的定位。
提升效率，减少缺陷，也就这两个环比指标比较靠谱了。
团队都被带废了，测试开发的价值那么多，竟然度量不出来。。
分析的很透彻，测试效率提升和质量衡量，指标太细实际执行起来很困难，具体还要看公司的产品形态很所处阶段。
对楼主大部分观点都比较赞同。补充谈点感想。
首先，任何工作的开展都是围绕价值，更确切的说是给客户带来的价值，包括短期和长期的。
其次，测试开发，围绕的价值还是测试质量和效率的提升。例如我们做 UI 测试自动化更多的是起到核心功能回归测试的作用，也就是投产质量看守的作用。那么首先对核心功能的判断、其次覆盖率的度量还是有必要的。
另外，一个外行看似简单的产品，内在功能和逻辑在懂行的人眼中还是非常多的。具体核心功能的判断，建议还是基于测试理论中的 RBT 理论进行筛选。
第 N 次拜读此文，每当做测开迷茫的时候，就看看
个人觉得所谓测试开发 SDET 的概念是从微软来的，而这个概念也已经有很多年了，未必符合目前的实际情况。
在微软的角度上其实就是开发，为满足测试的效率上的需求提供支持。这个职位需要开发技能且和测试相关。
但是还有一个职位也需要开发技能和测试技能，那就是自动化测试工程师，而该职位以测试为根本，通过开发来提高效率和质量为完成测试的目标。
所以两者的考核目标不应该一样。
仅仅从测试开发（非自动化测试）的角度来说楼主的观点是很有效的。
magicyang
回复
不一定的，我现在在新加坡一家互联网公司，一些本地毕业一两年的开发同学（中国人）代码质量吊打之前在大厂的某些五年开发，因为资源有限也没多少时间做单元测试，集成测试之类的，但要做的时候也做得很快。我想还是跟个人综合能力有关吧。你的观点应该建立在同样能力的人做与不做的区别上。
赞一个，节省人天有时候很片面和主观。
不过我想到一个观点：让所有的测试变成测试开发，测试开发为自己服务。两者合一的产出大家都看得见。测开的产出，自己能感受到。这样可行吗？
Ouroboros
回复
现在很多大厂（典型的如阿里、七牛）不招测试岗，招的岗位都叫测试开发；既要做工具（质量团队内部会有一些分工和侧重），也要负责工具应用，质量提升。
debugtalk
回复
那就不纠结了，自己家的刀，好不好使自己最清楚。做出来的工具，一定要好用才行，感觉很多测开都没考虑这一点。
赞一个
写在最后的内容，同感同感
有收获