好绩效！做回归测试也可以好绩效！做回归测试也可以

为什么要做回归测试

简单说就是为了找出新代码改动对原有功能造成的影响。
正是因为要测的是原有功能，所以在很多人眼里，回归测试的工作变成了「重复，重复，再重复」。往往也会把这种「重复」的劳动力，交给团队的新人去负责。
这样合适吗？嗯……确实是一个值得思考的问题。

回归测试难不难?

都说「做测试的门槛比较低」，其实这句我还算认同，但要做好，不容易。这就比如说，玩游戏的门槛比较低，但是你想做职业玩家，那可不是点点鼠标就能轻松完成的。
如果说做测试的门槛比较低，那么做「回归测试」的门槛恐怕更低，低到「只要按照写好的测试用例完全照做就好」。什么？看用例也不会做？差评，肯定是用例写得不好。
回归测试有相当大的一部分工作量就是重复之前的测试用例，日复一日，月复一月。有人把它当作新手练习，有人觉得无聊没技术含量，还有人认为是浪费时间浪费精力。如果你也这么想，那么说明你离一个测试工程师的路还很远，当前充其量顶多算是一个「测试用例的执行者」。
要想成为一个真正的回归测试工程师，得通晓整个产品，因为任何一个功能出现问题，都得有能力去定位分析。从这一点上讲，倘若没有一段时间的积累，是很难胜任的。

是执行者？还是测试者？

依葫芦画瓢，知其然而不知其所以然。回归测试之所以可以交给新员工做，也就仅仅因为它有现成的测试用例而已。倘若测试过程中没有发现产品缺陷，便会误以为自己做了无用功；一旦发现产品缺陷，自己又哑火，除了丢出来给资深工程师看，自身也再无价值。因此初级工程师往往又觉得这活儿没技术含量，殊不知自己仅仅停留在执行者阶段。
其实工程师应该自我进化，多学习理解产品，对大部分的功能都有所掌握，对回归测试中发现的产品缺陷先进行分析，甚至找出缺陷的根本原因，这才是一个完整的测试流程，此时，才能称得上是一个真正的测试者。
除此之外，一个有经验的测试工程师，还会针对当前出现回归缺陷的功能模块，扩大回归测试用例集，以保证回归测试有一个合理的覆盖范围和深度。

做回归测试如何给自己贴金

一个产品如果出现了非常多的回归性缺陷，说明产品还没到可以测试的阶段。所以真正到了测试工程师手上的时候，回归性缺陷不会特别多。那么问题来了：绩效考核怎么办？
【好绩效！做回归测试也可以】作为一个回归测试人员，不设计新的测试用例，发现产品缺陷数量有限，单靠执行用例数量，这绩效确实不好看呐！
其实要想把回归测试做出彩，前文也略微提到了，指导思想只有一个 —— 增值。
增强测试深度
当发现了一个回归缺陷的时候，在同一个功能模块里再次出现回归缺陷的概率是会增大的。此时工程师应该做的，是针对性加强回归测试深度，对常规回归测试用例集进行扩充。虽然未必能再一次发现新缺陷，但这对有助于增强产品交付时候的信心，无疑也是对自己工作的一个加分项。
提高测试效率
增强测试深度，多出来的测试用例要花时间测，时间哪里来？亦或者每个测试周期都重复执行，无聊到爆，熟练度更是令人发指到闭目盲操。
是该考虑通过自动化来代替这既奢侈又廉价的人力了。这也是一个提高测试效率的硬手段。
事实上，当预见到需要重复工作时，就应该考虑是否需要自动化方案了。当然这对工程师自身的要求就提高了，得会写代码。
有了自动化代码作为答卷，那么就可以按照开发工程师的绩效方式交卷了。
总结一份专业的报告
这一项增值技能往往会被技术人员忽视，其实这是一项非常重要的技能。
一切结果拿数据说话，回归测试不仅仅是告诉别人有没有发现问题，还得告诉别人我们测了什么，覆盖了多少内容，增强产品品质的信心，而不仅仅是一句「没发现回归性缺陷」。
其它的增值工作，也可以在此时的报告中有所体现。