测试人员的考核制度如何设定？请目前已经有考核测试人员的公司谈谈！
谈谈你们公司的考核制度不合理性，并讲讲你的见解！ 测试人员的考核本身就是一件很困难的事，很多还是要靠考核人员的主观判断。我不赞成拿最后的结果来进行考核，比如发现的Bug数以及Bug重要程度等。因为不同的测试人员所面对的被测对象的质量不同、所分配的资源也不同。个人觉得可以从测试中的中间产品来进行考核，比如所编写的测试计划的质量、测试用例的质量、测试报告的质量、Bug 报告的质量等。个人观点，欢迎讨论。 我同意楼上的观点
应该从对整个软件测试流程的把握程度上去衡量一个测试人员的水平
而不是单纯的从BUG数量和BUG的严重程度上考虑. 如果你是在做管理或曾经做过测试管理，那么你会发现流程的把握公司只会前期很短的耐心时间等待你，实际公司原有的产品质量在你测试后是否能有期望中的提高，是否达到减少成本目的是公司最终衡量你的标准。
当只有存在一个达到了一定战绩和明显改善了公司产品质量的测试团队时，新成员的考核可以建立在此基础上。但新成员演变成了熟练技术员，衡量他的将是出去的产品用户反馈回的BUG幼稚程度。 是比较难的,应该从整体看的要 Originally posted by skinapi at 2004-10-29 11:23 AM:
测试人员的考核本身就是一件很困难的事，很多还是要靠考核人员的主观判断。我不赞成拿最后的结果来进行考核，比如发现的Bug数以及Bug重要程度等。因为不同的测试人员所面对的被测对象的质量不同、所分配的资源也 ...
对于测试计划的质量、测试用例的质量、测试报告的质量、Bug 报告的质量这些也只是一个总的概念，没有任何标准可以去衡量其准确的优秀与不合格，现在一定要脱离我们人为的去判断， 这份测试计划是优秀的。。。；主管没有太多的时间将所有的测试用例、或者测试计划都非常仔细的查看，然后去评定其好与坏；我想应该有一定的标准去量化。不知道我这样的想法你是否赞成？ 我觉得billrub的观点有一定的合理性，当对我们现有的公司执行性不是很好，不知道你们的公司是怎么样的，我说说我们公司的项目模式：项目立项－需求调研（需求文档成文）－开发设计编码－测试－项目实施－用户错误反馈。
用户错误反馈的时间非常长，用户如果没有很好的使用该项目软件，而反馈的回来的错误是断断续续的，会出现1个月、2个月、或者1年，因此用户的反馈错误是很难在短时间内进行有效统计（我们按月进行考核测试人员），对于测试人员的考核就很难当月实现。
不知道我这样的描述，各位是否能看得懂？ 呵呵，说到同感处，又情不禁再发表一点自己的观点：
测试大家都可以认同的一点是在成品测试阶段遗留的bug测试工作如果理想应该做到“查找到这些BUG的80%”，而且产品交付后再默许遗留的20%以下的BUG显然级别较高的数量应该是很少量；
因此公司如果够规范可以基于此做出绩效考核的几个指标来衡量测试人员的工作，显然如果在正式产品运行后用户反馈回级别较高的BUG教多，或级别不高但数量可观，那么我们认为测试的工作效率是比较低的。 billrub的观点可以理解，那么我们是否能估计到一个产品到底有多少错误总数呢？而80％的数量是如何计算出来的呢？ 在每次产品发布时，测试的程度和发布时间有直接关系，你的程度如果只有10％左右，那么错误数会留有多少没有测试呢？ 呵呵，这一点我们在上初中时老师就教会了我们如何计算一级方程式，我们设定现在我们测出的总有量为80%，那么我们可以得到一个假设的总值，当然也可以算出剩余的20%。
剩下我们需要去划定几个指标，就是超出20%的量有多少，质如何；可根据公司具体情况而定。 楼上如果真有这种情况我想你公司在近期内没再看到测试的效果，过了几个项目依旧是只有如你所描述的10%状况，那么公司马上会有反应，这种情况就没必要当前的测试过程继续运行；有两种情况会发生：
1、干脆取消专职测试；
2、重新组建测试。
如果你曾有测试管理的经历，那么你会深刻体会到效益对公司永远是在第一位。
[ Last edited by billrub on 2004-12-1 at 13:43 ] 测试覆盖面是有个度的，billrub你可能误解我的意思了。
也许对于用户使用来说，测试覆盖面只要达到10％就可以了；现阶段不可能用到60％或者30％的程度。
其实我们现有的测试部门非常好，得到项目部、开发部、上级领导的认可，如果不经过测试，他们都会不放心。另外我们公司的开发部的质量也是严格把关的，等级非常高。
我之所以提出来，我希望能做得更好，更能合理的进行考核测试人员，和激励测试人员。 到目前位置，我们公司有几个开发人员已经免测试，你可能会不认同。因为他们开发的项目质量已经得到了测试部门和用户的认可－测试问题问题基本没有（有，也是比较次要的问题），另外用户经常使用也没有出现问题。 呵呵，居然有金子招牌的的程序员，免检产品，这样的风险多大，是否考虑过呢？ 风险当然考虑过，如果没有得到用户认可，和测试部门对该开发人员所负责的多个项目的质量认同，那么这个制度不会执行；在某一个时期的，某一个开发模式非常成熟的基础上，某一个领域等多种情况下所产生的。我只是说：在一个软件的生命周期中，用户使用的质量程度能达到就可以了，没有必要测试的深度（广义的覆盖面）达到多么深。 我们的产品都是基于WEB，我们的客户群正在从不认识网络到认识网路，从了解网络到开始使用网络。。。现在也不断熟悉和重新认识,对于我们的产品也是如此，从排斥到接受，然后了解，再开始使用，然后再不断的提出他们的需求。。。。
现在我们的客户群属于最后两个阶段的，我们的产品比较成熟，很多功能客户开始使用，但还有很多没有使用起来。。。
所以我之前提出，程序员免测，那也是因为这一部分领域属于非常成熟的开发了。 anne01所在公司的这个做法有值得大家借鉴的地方
其中我想免测程序员是在他做完一块任务时在白盒单元测试阶段可以免检，即是通常的代码走查和代码审查阶段（如为做白盒测试，则等同为黑盒测试阶段的功能测试），是对他代码成熟度的信任；而且一个值得你信赖的好程序员是完全可以长期做到这一点。
但在我们集成及系统测试阶段有关他的数据流、安全、强度、压力及通信方面一定还是涉及到，还有回归测试过程也必然对此任务模块涉及，但此时需要向测试对象负责的人已经不是这个程序员，如果在回归测试阶段查看到免检程序出现了功能漏洞，那么我想漏洞达到一定度后anne01所在公司必然对此有相应的对“免检”的调整程序。
这一点可以在规范性不是很成熟的公司以另外一种形式借鉴：定期设立对完成高质量程序的程序员有相应的奖励，呵呵，当然这需要测试人员给予肯定。如果公司能允诺的奖励不会太多，那么可以减少奖励范围，比如两个月评一次并评一个，千万别大家同喝一锅粥，大家都有奖（大家都不在乎！）。必须体现出奖励的价值，能引得程序员的关注。
[ Last edited by billrub on 2004-12-4 at 22:15 ] 我们公司的处理方式：一个软件或者一个系统在两个版本测试之后，达到一个比较稳定的状态，如果负责系统某个模块测试的测试人员，在第二个版本测试已经不能提出质量较高的bug时，则进行交换，由其他的测试人员接手该模块，如果在版本没有更换的情况下，发现了级别较高的bug，那么我们会根据该bug的出现频率，出现时机判断是否应该更早提出，这样可以判断前一测试人员的工作效果，另外，我们还根据测试人员的沟通能力，工作速度，工作质量进行评判，还有一个长期的追踪就是客户反馈， 我们在出版本的时候，最终定版本的相关测试人员都要签字的，这样可以长期的跟踪测试人员的工作质量。
求助
我正在组建一个测试部门,对于如何考核测试人员,如何制定考核标准正犯愁呢,各位同仁,有没有现成的资料可供参考
页:
[1]
2
