软件测试评语.docVIP

软件测试评语 测试人员绩效评价方法 由安博测试空间技术中心 /提供 版本记录： 1编写目的 本文档是对独立测试人员的绩效考核从测试能力方面进行考核的依据，其它考核的标准参照支持服务中心的部门考核大纲，该标准仅作为整体考核标准中的综合考核的一部分。 2适用范围 本标准适用于软件测试人员的考核。 3 评价标准与原则 3.1提交BUG的数量和执行测试用例的数量 测试中发现的BUG数量: 1)同一个项目组内，提交bug数 2)每人日提交的bug数 3.2测试人员发现的问题的本身价值 1)Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。 2)Bug的双方面评判，对于bug的价值开发人员在另外一个角度上进行评判。 3.3、测试文档的质量 测试文档的质量往往是测试人员的测试水平的反映，只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质量 3.4 测试技能水平 1）测试用例设计水平 2）测试工具掌握使用水平 3）测试结果分析判断水平 3.5测试技能以外的综合能力 考察一个测试人员的责任心，如果一个测试人员工作不符责任，随意敷衍，即使提交的问题单数量多，也不能证明他测试的质量高。其次积极的工作态度是提高测试质量，和整体团队风气的关键，沟通能力直接影响测试的工作效率与不同部门间的合作分工。 1）工作态度 2）沟通能力 3）钻研能力 4）团队合作能力 4考核办法一览表 注：缺陷分类算法： A*(1+加权系统)/(A+B+C+D+E)*20 B*(1+加权系统)/(A+B+C+D+E)*20 C*(1+加权系统)/(A+B+C+D+E)*20 D*(1+加权系统)/(A+B+C+D+E)*20 E*(1+加权系统)/(A+B+C+D+E)*20 篇二：对软件测试的认识 我对软件测试的认识 软件测试，简单的说就是找Bug，说正规点就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估，执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。 就公司而言，在没有正式购买产品时要试用。其实这就是一个测试。要测试首先要有对象，比如这里的产品。要有用户，要么是个人要么是公司。还要有标准，比如个人的感受，比如公司的一套套评判准则，有试用评估报告，有试用报告。当然对个人而言就简单的合适就好。当然如何解释合适两个字就变得如此的困难。简单而言，所有的测试都有一个目标导向。这里的合适就好，其实就是一个目标导向，当然这个导向的目标越是明却，那么测试可能就越精确。测试出来的效果就越好。 在我的理解中，软件测试是这样的：“以客人的需求为标准，找出与之相符的部分，确认与之相符的程度，找出与之不符的部分，确认是否为客人的隐性需求，是否与客人习惯，客户行业规范相关；以客人的角度理解使用软件，找出操作上困难，界面上难看的，以及影响工作进度的部分，并不断的分析历史报告，图表等，以此来不断提高自身及团队的测试水平，以此不断精进整个软件测试流程来为其他相关软件开发中的团队提供服务。” 篇三：做好软件测试工作的19条建议 提高软件测试能力的19条建议 原文地址: Cheezburgers and Testing Advice 作者：Alan Myrvold，软件安全高级测试工程师 译者注: 本文主要面向软件测试的初入门者，但对有经验的软件测试工程师也应有益。 我起初准备自己写10条建议给刚入门的软件测试员们。但之后我看了 lolcats/icanhascheezburger 上的名人Ben Huh的一段演讲。Ben指出，有了互联网，信息成了免费资源，但组织，编辑，以及表达却都需要技巧。受Ben和cheezburger网站的启发，我请求60名成功的软件测试工程师每人为刚入门的测试人员提出三条建议。其中的40多名答复了我，使我最终有了一个长达100条的建议列表。 出于保护他们的隐私，我不会原封不动的把这些建议罗列出来。但是有趣的是，我发现他们的建议中有很多共同的地方，而所有这些建议加起来要比我原先自己想到的好得多了。 我把这些我搜集的建议总结成以下19项： 1. 想客户之所想 在测试的过程中时刻想着用户。培养自己对用户需求的共鸣。和用户沟通并且观察他们怎们样使用你的软件。 2. 多读Bug 如果你和一个团队的软件测试工程师一起工作，那么请阅读 他们每天发的Bug， 特别是那些针对你的测试部分的Bug 。你可以从别人如何找到Bug中学到很多东西。 3. 多读代码 找到你测试的那部分功能的代码。虽然写代码并不是你的事，