软件测试的真正价值并不体现在代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限，思路中的狭隘的技能方面的不足。--托尼·霍尔

　　前段时间在管理层的年度复盘会议上，提到了员工绩效考核的事情，绩效考核也是一个老生常谈的话题了，毕竟任何一个公司的晋升加薪或培养人才都要经过考核。那考评结果多数不尽人如意。如原先一个外包公司的年度考核是由人力资源部门来制订考核标准，整个技术部门的需求分析人员、产品人员、研发测试人员以及运维人员和运营人员汇报工作后相互打分，直接上级会增加权重，但最终的考核结果还是会令很多人失望，毕竟对于不同工种其给出的分数参考意义不大，甚至是更偏向于主观色彩；其二，人力资源部门的标准更过于数据化，无法真正结合技术角度来立体评估。当然，也不存在绝对公平，但作为直接上级，可以尽可能无限地趋于相对公平。

　　对于测试人员来说，写得一手漂亮的测试报告，覆盖完整且精准的测试用例与出色的缺陷报告数据，是必备的职业技能，也是一轮筛选的首要条件。但如果单单凭借这些文档或是缺陷数量来完全对一个测试人员考核认定的话，则测试人员所追求的也会是这些表层的漂亮数据。

　　同时，很多测试人员也会有疑惑，为什么明明自己提交Bug无论是从数量还是质量都要远远优于别人，但职业路径并不是很顺利；类似情况就要思考下是自己是否真正的输出了正向价值。

　　忘记了软件测试真正的价值，同时对于不了解技术实现的管理层来说，他们也不会关心这个过程中你提交了多少个Bug，写了多少Case，而是产品发布后，收到的正面反馈，满意度以及质量如何。

　　《探索式软件测试》一书中托尼·霍尔也提到了软件测试的价值，对于真正意义上的测试人员有着非常重要的参考意义 。

　　原话如下：软件测试的真正价值并不体现在代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限，思路中的狭隘的技能方面的不足。

　　所以，软件测试基本技能过关只是最基础的一步，技术技能的不断提升也是不断内化的过程；而真正可以外化并产生可持续性发展价值的是帮助编程人员从根本上解决问题，而解决问题的第一步就是问题分类，从统计数据中来抽取样本，加以分析，而这些也应该是项目复盘的必经环节。

　　以下是工作汇报评价表，表格内容是摘取管理工作汇报报表的模板，但是通用于各个岗位，其他岗位可以微调进行匹配岗位职责。其中，深层次分析和改善措施即是通过缺陷报告分析来进行外化的。

　　改善型总结不仅是提出问题，而是通过发现问题、提出问题进而解决问题并改善现状并持续运用于下一个项目的闭环性解决方案。缺陷报告深层次分析可以使用公司内部的项目管理平台进行自定义报表 ，也可以导出后制作成表格来展示（一般用于会议展示）

　　缺陷报告分析中，可以进行归类分析，如常见的用户操作类、前端、后端（这二者中又细分为数据库、接口等等）以及环境类，外部依赖等等。

　　第一层分类可以从大类中明确看到问题集中在哪里，如何避免，是重复性问题还是随机性问题。

　　第二层分类则可以从具体原因分析，如用户操作类中的误操作，如果是批量的误操作，要思考下是否产品设计问题，没有给出明确的提示或存在歧义，甚至是否是培训不足？如果是开发过程的问题，则要分析每次的发布后经常出现的问题，如某些开发人员经常忘记配置字典或执行脚本 ，菜单配置或是更新了错误的分支。每次发布后的自动化冒烟测试可以快速把这些问题反馈出来，并在发布完成后进行复盘，作为下次发布的准备须知。如此 ，也是一个完整的PDCA闭环了。

作者：M虫神    

来源：http://www.51testing.com/html/13/n-7796113.html