如何衡量测试人员的价值

引子

相信大多数的测试人员都是从做业务或者技术产品的测试工作开始的，那么你们知道如何提升自己的价值吗？
衡量业务测试人员的指标一般有下面几个：

1. 提交bug数
2. 测试周期
3. 漏测
4. 业务case自动化程度
5. CI
6. 自动化case的代码覆盖率、分支覆盖率
   加分项：
7. 跨部门沟通、协作
8. 平台化
9. 测试环境相关
10. on call
    以上仅限于我写文章打字的时候，临时想到的一些点，如果后续我有其他的思考，我再补充进来

提交bug数

做手机测试的朋友，我相信他们提交的bug数一定比做技术产品测试的要多多，记得我在百度负责一款叫做天眼的产品的手机测试的时候，几乎每天我都要进行一轮的测试，第二天，我要一早把前一天发现的bug提交到好像叫做icafe（我们一般叫爱咖啡，做这系统的，我想他干活的时候，应该经常冲速溶咖啡，因为当时在百度大厦工作，我还没有见过咖啡机）的系统，有一次我从早上10点，加上中午吃个饭，最终下午2点才提交完。
首先，我想说，开发的质量真的不咋地。还有就是，我当时也真的在手机测试方面，更多的进行的是黑盒测试。
因为是临阵抱佛脚去支持做手机测试，对android、ios的底层不甚了解，当发现多个问题的时候，没办法去分析他们在底层上是不是因为同一个问题导致的。
还有就是不善言辞，手机测试的bug，要有详尽的描述、截图，app的交互路径是怎样的、什么手机型号、什么版本的系统、网络情况怎样、异常现象的截图、抓包数据、为什么认为这不对（要拿出产品的prd去对预期），有的时候甚至要标注下，自己神奇的操作手势等等，是不是感觉很崩溃？但是如果你不这样做，开发会跟你说，我复现不了，你来，你还要屁颠屁颠的跑过去，秀一遍操作~
说这些其实主要是想说，这个bugs数指标其实不是很合理，因为如果一个测试能力一般的人可能会提交很多的bug，有可能是重复的，也可能是无效的。而一个能力不错的测试人员，提交bug的质量很高，但是数量就很尴尬了。
我的一个建议是，要做一个能发现问题，合并问题，并能高质量的交付bug的测试人员。这是对开发人员的负责，同时也是对自己的负责，因为你不会一直在初级测试这块儿混，树立良好的口碑、提高自己的分析能力，远远比加班测试，提bug重要的多。

测试周期

互联网的项目多数都是敏捷项目，快速迭代、快速试错。
多数的项目都会有pm或者pmo去催项目，前提就是我们要要一个项目的排期。
传统的瀑布式的项目排期会有：需求沟通确认、概要设计、详细设计、开发、测试、预上线、预上线验证、灰度上线、全量上线。从这里我们可以了解到，测试一般是滞后于开发的，经常会出现的问题就是，开发提测延期，上限日期没变，测试排期被压缩，我们就不得不去周六日加班来追项目进度。
我记得我再百度的时候，有专门的内部系统去支持部分的项目流程，如：项目经理立项、开发提测、测试测试、提交测试报告等。从系统上是可以看到开发的提测时间点的。
直观上看，开发提测延期没关系，我们的系统是可以看到项目delay是由于开发延期导致的。但是具体操作的时候，你就会发现，很多的开发都带赶这个提测时间点，开发时按照排期提测的，但是可能碰到一下情形：

1. 提测时间虽然是在规定的提测日期，但是可能是当天的下午或者晚上（相信我，开发的世界里只要是那天就行，但是在测试的世界，我们评估的测试周期可能就这么被悄悄的消耗掉了）
2. 开发提测的质量很差，可能有以下具体的现象：提测代码无法编译、打包；服务启动就退出；输入无法被正常处理；输出信息与预期相差甚远；我们对测试的排期预期有一个比较隐晦的前提，就是开发的提测项目质量要有底线，具体表现形式：代码能编译、服务能部署、对于基础的case流程能跑通、基本符合预期。

我们主要对上面的提到的开发提测质量很差的场景做应对。
1、提测要有准入，测试人员对于测试周期大于1天的项目（具体项目具体分析，这里的1只是一个大概的值），要提前介入项目，在开发提测之前就要去了解需求、开发的设计等，提前与开发进行沟通，确立相应的准入case，开发必须进行自测并验证通过准入case，才可以进行提测，否则准入不过的直接打回，不要让一个准入case都不过的项目占用我们的测试周期。
2、即使准入过了，但是开发提测代码质量依旧很差，可能的现象是提测反复被打回，一个bug总是没有彻底解决，或者修复了一个问题，有连带导致以前测过的case失败了！针对这些情况我们首先要有快速的确认开发提测代码有问题的方法，一个维度就是”快“！，有相应的自动化回归方案、熟读开发代码（能快速定位是开发的问题）或深知需求（快速验证不符合需求预期）等，另一个维度就是”抛“，不是甩锅哈，是抛出问题，因为开发的提测质量较差，项目可能延期，这个”抛“的方法手段很多，一是要让开发的相关负责或者pmo了解到，还有就是要让测试leader或者测试组长了解到该问题。
当然我们以上主要说的是开发这头可能是一个黑洞问题，其实我们测试人员也可能会有我们自己的问题，如：

1. 错误的评估了测试周期，评估短了！
2. 没有将code review的时间预留出来，或者压根就没准备看代码！
3. 项目冲突或者插入！
4. 开发在提测过程中追加了需求！
5. 没有提早的介入需求评审、概要设计、详细设计、code review，导致需求、实现理解不充分！
   …

我们应该怎么去规避上面的问题呢？
首先，在项目立项后的各个阶段都要参与进去，参与需求的讨论、开发的概要设计、详细设计，对于有异议的地方及早的提出，一定要做code review，我的忠告是，测试人员不要把自己定位成就是黑盒测试人员，相信我，很多外包在黑盒测试这点上，比我们干的可能更优秀！你去了解开发的代码设计的时候，其实就是在锻炼自己的coding、架构、设计思维，同时这也是决定你是否能设计出很棒的测试用例基础！
其次，面对突发状况，如：追加需求，这个要评估项目排期是否收影响，并周知相关人员（pmo、开发leader、测试leader等），可以是通过邮件、钉钉、项目管理工具等形式，一定要持久化，别到时候因为这个导致延期，找不到相关的证明，你就会背锅。。对于项目冲突的问题，这个要提前做预防，了解自己近期一周，甚至一个月得相关项目排期情况，防止放生冲突！记住，只有你自己能对自己真正的负责！
啰嗦了这么多，大家能看出，测试周期要考虑的事情，真的不是一个简单的表格~

漏测

漏测就是测试人员应该覆盖到，但是没有覆盖到，还导致了线上问题！
我们先说说漏测产生的原因，人员能力问题这方面咱就不聊了，聊聊其他的。

项目测试排期紧张

抛开线上灰度、自动化回归等手段，人少、工作量大、测试周期短，即使线上出现问题，我认为是无可避免的。那怎么能缓解问题呢？
首先，要尽早的参与到项目生命周期的各个阶段，吃透需求、实现，测试case设计要弄到点上！用最少的case覆盖最多的场景、代码，实现最大的业务价值。我的一个习惯就是，我会看反复确认产品需求细节、吃透开发的架构代码设计，用尽量少的case覆盖核心功能，做多维度的测试（如：高可用、容错、健壮性等方面）。
其次，确认边界，我从开始做测试，我就总会去想一个问题，同样的系统，另一个人测，过程和结果会跟我有多大的不同，我想这个是一个很有意思的问题。至少目前，层次高一些的测试人员，我认为一大优点就是，知道何时该"停手"、何时该"出手"，不同的人对测试边界的理解是不同的，有的开发会说“我做了性能优化，你回归下”、“我做了xx改动，给我做个压测”，你如果真听了这些不负责任的要求，在不你迟早就要累shi，在不你迟早要背锅。我的一个习惯就是，当需求很急或者排期时间不够用的情况，我会跟开发、产品确认，最低交付标准是什么，如：要覆盖哪些功能、异常场景、是否需要做性能测试等。不是要开发、产品告诉你这些事情，是你去argure并确认这个事情。

业务case自动化程度

首先我想说，业务case自动化程度可能并不与工作效率直接挂钩。
一个和谐、美好的工作场景应该是这样的，测试人员只需要关注新功能特性，进行功能验证，同时点一下jenkis的自动化回归构建，就完成了所有历史功能的回归验证～
然后理想总是丰满的，现实总是惨不忍睹。
现实的场景，测试人员执行回归测试构建，测试case大面积失败，各种稀奇古怪的错误：网络异常、某某断言失败、未经捕获的异常满屏飞。结果反而要花大量的时间去定位、分析可能不是问题的问题。
导致这个问题的原因一般有两个：环境问题、case设计问题。
先说说环境问题，自动化回归一般是在测试环境进行的，测试环境的稳定性与自动化case执行的稳定性息息相关，解决方案要看具体情况，如：执行时环境独占，测试环境数据执行之前进行数据清理、重制，有重试机制等。
再来说case设计问题，比较常见的就是case设计不够健壮，过于理想化，没有考虑各种的异常情况进行兼容，还有就是assert设置的有问题，举个例子：断言判断响应中的某个会随着场景、升级可能变化文案字段，这就是典型的干活没干到点上，断言设计应该是那些明确的、稳定的，或者有规律可循的点。
总结一下，case自动化程度要建立在case执行环境稳定、case设计合理、健壮、易于维护的的基础上，不然自动化并不一定会提高效率。

未完待续！