软件测试工程师绩效评估表正式版

1、软件测试工程师绩效评估表正式版软件测试工程师绩效评估表软件测试工程师职责：1 与软件产品部配合完成软件需求分析讨论， 并根据需求说明书制定 项目测试 （计划） 方案；编写测试用例 ；建立测试环境；2 负责研发部门各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改 软件的模块测试和系统测试；建立、推广并维护实施软件版本管理系统；3 负责推广实施软件开发文档规范化工作，管理研发产品相关文档；4 负责配合软件研发部门等对于新项目软件或修改升级项目软件的测试工作， 并提供测 试报告；5 负责监督软件开发流程的执行， 并负责提出软件开发过程改进建议， 提高软件产品质 量。6 与开发工程师和研发

2、部门交流报告任务进展情况，并提出最近的测试需求；7 测试部负责制订测试计划、 测试用例和测试实施方案， 项目主负责人安排测试与对应 的开发人员交流完成测试执行工作；及时提交准确、完整的项目测试报告 ；8 项目主负责人负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之 外的部门定期交流掌握下周或近期可能测试任务；9 外部接口都由测试部主管负责完成，与其他项目组和产品部门协调项目进度；软件测试的不确定性：1 软件测试的目的就是使软件的错误不断趋进于零，但软件的错误是永远找不完的；2 开始测试时，可能软件使用 1 个小时就出现 10 个错误；测试修正后 1 个小时出现一 个错误，继续修正

3、，继续测试，直到约一个月出现一个错误。这时这个出错几率已 经通过终结评审可以接受了。那么测试就结束了。移植成功之后测试工作由开发部 门来维护。3 测试一些成熟的游戏或应用，测试过程中很难发现大量的缺陷；而测试一些不成熟 的游戏或应用，在测试前期，会出现大量的问题；这样就导致不同的工程师发现不 同数量的 bug；4 软件测试的进度首先会按照测试计划逐步进行， 但是在测试过程中， 测试进度会随研 发部门的进度而调整； 所以积极的与研发部门交流、 协调测试中的问题是相当必要的。三测试工作最低成功标准及测试工程师考核内容： 测试工作的最终目标就是发现客户可能发现的所有错误。 如果移植测试在使用第一天

4、就发现了你没测试出来的错误， 那测试是失败的。 如果使用了很久 （如几个月）才出 现错误，那说明测试还是成功的 。测试工程师考核内容：1 测试工程师比开发工程师更了解产品； （产品各模块总体把握能力）2 测试工程师能从客户的角度来检测软件的功能； （用户身份）3 测试工程师获取资料，使得编制的测试用例更切合测试的重点、难点以及关注点；（编写测试用例）4测试工程师比开发工程师更容易发现产品的问题；（不同的思维模式）5测试工程师总是不断的发现问题，验证问题；（提交bug数量、bug质量）6测试工程师按照测试计划完成各自工作；（测试计划的执行能力）7测试工程师以操作员的角度测试产品；（Free测试能

5、力）8测试工程师及时与开发工程师沟通、交流解决问题；（部门间的工作协调能力）9测试工程师及时提交测试报告；（报告的及时性、准确性）10测试工程师之间处理问题；（共同完成任务）11测试工程师协助开发工程师，了解开发流程等信息；（学习能力）四软件测试人员工作业绩评估的误区：1不能仅从提交的问题数量、测试执行用例数量来判断测试人员的好坏；模块A很不稳定，潜在的问题数可能有100个，由测试人员甲负责测试，他一个月执行300个用例，提交50个问题单，发现30个有效问题，有10个严重问题；模块B比较稳定，潜在的问题数可能有20个，由测试人员乙负责测试，他一个月执行100个用例，提交20个问题单，发现18个

6、有效问题，有8个严重问题；从上述测试执行结果来看，甲提交的问题单数量和执行用例数量都要远远高于乙，但是从测试的质量来看，模块 B的遗留问题显然少于模块 A,甲执行测试的充分性显然不如 乙，从问题单质量来看，甲提交的问题单虽然很多，但近半数是非问题，做了无用功， 还影响到开发人员对问题的定位所消耗的时间。因此，必须要走出用问题单数量、用例数量评价测试人员的误区。2对软件人员发现的问题的价值没有进行评估；发现一个系统架构设计方面的缺陷和隐患远比发现几个普通界面显示问题的价值大的多；3不重视测试文档的质量；测试文档的质量往往是测试人员测试水平的反映；只有对系统进行了统分的、深入的测试人员才能写出高质

7、量的测试报告；4不重视测试人员的综合能力；责任心、积极性、创造性以及沟通和协调能力附：软件测试工程师业绩评估模板：（满分：100分）软件测试工程师业绩评估模板：（满分：100分）类型评定参数参数值说明提交有效问题数量单位（个）最基本的考核指标问题(35%)提交的非问题数量单位（个）需要测试人员意识到处理非问题影响测试、开发的工作效 率；测试主管必须严格审核测试人员提交的bug提交问题的规范性优秀良好普通 不合格问题描述是否清晰；相关trace文件是否齐全； 问题等级、版本等信息是否正确； 问题跟踪是否到位；严重问题所占比例单位（%）（严重问题/问题总数）*100%提交问题的质量非常好很好一般

8、良好 低综合评定测试人员提交问题的质量； 测试人员发现问题的深入程度；工作效率提交bug验证bug优秀 良好 普通 不合格对自己所提交问题的多版本跟踪；Check他人bug的程度；不同模块功能的理解程度；测试用例（20%）执行用例覆盖率开发用例难度困难 普通 容易编写测试用例质量用力的难度直接反映测试人员的测试能力；并影响测试效率；FREE TEST用例外，测试发现问题的能力新增测试用例价值新增测试用例质量文档（15%）测试报告质量优秀良好 普通 不合格测试报告的规范化程度； 及时性； 准确性；内部测试文档、测试 经验的交流及共享经常偶尔从不测试工作的协调； 经验的交流； 问题的确定；等等态度

9、（30%）工作积极性优良中差主动解决测试中遇到的问题；沟通能力根据实际情况，分析评价；学习能力不断的提高工作效率；项目了解（主动性）对项目总体的把握；测试计划的执行执行计划；部门间团结协作各部门相互配合解决问题；上级主管综合评定及意见综合评定：部门经理给岀测试人员考核评定及意见附：软件测试工程师业绩评估模板评估类型绩效指标评价标准分值软件测试绩 效工作态度严格遵守各项工作制度和岗位要求。工作认真负责，责任心强。能够主动进行工作沟通、交流。主动发现问题，并且跟踪解决。积极参与测试组各项活动，能够主动承担组内工作。16-20 分1、工作制度2、工作认真3、工作积极4、沟通、交5、主动性、遵守各项工

10、作制度和岗位要求。 工作认真负责，责任心强。能够主动进行工作沟通、交流。主动发现问题，基本能做到跟踪解决。参与测试组各项活动，能够承担组内工作任务。11-15 分遵守各项工作制度和岗位要求。工作认真负责，责任心强。能够进行工作中基本沟通、交流。发现问题，缺少跟踪解决。参与测试组各项活动，能够承担组内工作。6-10 分测试用例测试BUG有督导情况下基本能遵守各项工作制度和岗位要求。能基本按要求完成任务。进行基本工作沟通、交流。发现问题，缺少跟踪解决。基本能参与测试组各项活动，不能够承担组内工作严格按照用例模版编写用例根据需求设计有效用例，覆盖所有的需求点。 用例描述准确、简洁、清晰，评审通过率高

11、。按计划执行用例并且能够及时补充用例保证用例完 整性，对于无法执行或不具备环境不能法执行用例 及时沟通，并且测试结果中具体说明。能够按照用例模版编写用例根据需求设计有效用例，基本覆盖所有的需求点。 用例描述比较准确、简洁、清晰，评审通过率高。按计划执行用例并且能够及时补充用例保证用例完 整性，对于无法执行或不具备环境不能执行用例及 时沟通。并且测试结果中具体说明。在有人员指导情况下达到以下标准或者个人独立工 作达到以下要求能够按照用例模版编写用例根据需求设计有效用例，基本覆盖主要功能的需求 点。用例描述基本准确、简洁、清晰，通过评审可以达 到要求。基本按计划执行用例并且基本能及时补充用例保证

12、用例完整性。对于无法执行或不具备环境不能执行 用例基本做到及时沟通，并且测试结果中具体说明基本能按照用例模版编写用例根据需求设计有效用例，没有覆盖所有的需求点。 用例描述基本准确、简洁、清晰，通过评审可以达 到要求。不能按计划执行用例并且能够及时补充用例保证用 例完整性。对于无法执行或不具备环境不能执行用 例基本做到及时沟通能够按照规定的流程提交并跟踪BUG的全过程BUG描述语言简洁、准确。BUG再现步骤清晰、条理性强，易于再现。依据需求提交相应 BUG没提交错误BUG 能够分析和定位产生的原因，并能根据BUG的产生0-5分9-10 分6-8分3-5分0-2分9-10 分1、2、3、4、5、6

13、、1、2、3、4、5、测试用例 设计有效 用例描述 用例评审 用例执行 用例及时工作能力趋势做岀有效的质量和风险风析能够按照规定的流程提交并跟踪BUG的全过程。BUGB述语言较简洁、较准确。BUG再现步骤较清晰、条理性较强，易于再现。 依据需求提交相应 BUG很少提交错误 BUG 能够完成基本分析和定位产生的原因，基本并能根 据BUG的产生趋势做岀有效的质量和风险风析。 在有人员指导情况下达到以下标准或者个人独立工 作达到以下要求：基本能够按照规定的流程提交并跟踪BUG的全过程BUGB述语言基本完整。BUG再现步骤基本清晰、条理性不强，可以再现。 依据需求提交相应 BUG岀现提交错误 BUG

14、能够协助开发再现，定位 bug。对bug进行基本总结。能够按照规定的流程提交并跟踪BUG的全过程提交的BUG有三分之一描述语言不准确BUG有三分之一出现步骤不清晰、条理性差，难于再现。依据需求基本能提交相应 BUG岀现错误BUG 能够按时或提前完成工作计划，并且内容有效、准 确、合理，使人能清楚地把握工作进展和动态。能够按时或提前完成任务，并且按要求完成各项分 配的工作，工作成果符合要求，准确率高。能够通对过程和执行结果的分析、评估，形成准确 的测试报告。善于沟通，能自发与人合作，积极配合，容易和他 人达成工作默契。熟练掌握测试基本技能，技巧，熟练掌握项目业务、 了解业务领域知识，对测试需求把

15、握到位，能够独 立承担完整的测试工作。6-8分3-5分0-2分16-20 分1、计划能力2、执行能力3、分析、总4、沟通、交5、业务能力试技能）工作改进能够按时完成工作计划，并且内容较有效、较准确、 较合理，使人能比较清楚地把握工作进展和动态。 能够按时并且按要求完成各项分配的工作，工作成 果比较符合要求，准确率较高。能够通对过程和执行结果的分析、评估，形成较准 确的测试报告。具有团队意识，乐于与人沟通协调，顺利达成组织 任务。熟悉掌握测试基本技能，技巧，熟悉项目业务、了 解业务领域知识，对测试需求把握比较到位，能够 独立承担完整的测试工作。11-15 分基本能够按时完成工作计划，并且内容基本

16、有效、 基本准确、基本合理，使人能基本清楚地把握工作 进展和动态。基本能够按要求完成各项分配的工作，工作成果基 本符合要求，准确率较高。能够通对过程和执行结果的分析、评估，形成测试 报告。有一定的团队意识，能够维护团队形像，尚能与人 合作，达成共同目标。熟悉掌握测试基本技能，技巧，熟悉项目业务、了 解业务领域知识，对测试需求把握比较到位，能够 独立承担完整的测试工作。6-10 分很少能够按时完成工作计划，并且内容有效、不准 确、不合理，使人不能清楚地把握工作进展和动态。 很少能够按要求完成各项分配的工作，工作成果基 本符合要求。能够通对过程和执行结果做简单分析、评估，形成 测试报告。团队合作意

17、识不强，工作配合中存在较多不足，协 调不善，致使工作推进缓慢掌握一些测试基本技能，技巧，了解项目业务、了 解业务领域知识，基本能把握测试需求，在他人指 导下能够承担部分的测试工作。0-5分积极发现工作过程中存在的问题，提出改进方法， 能够解决问题（涉及团队）主动学习新的工具和新的知识改进测试工作，提高工作效率，改进工作产品质量（涉及团队）主动开展专项培训，分享学习和研究成果，帮助团 队其它成员提高。9-10 分1、共享、培2、新知识、3、工具学习4、工作效率5、工作质量积极发现工作过程中存在的问题，提出改进方法， 能够解决问题（个人相关工作）主动学习新的工具和新的知识。改进测试工作，提高工作效

18、率，改进工作产品质量。（个人相关工作）主动开展专项培训，分享学习和研究成果，帮助团 队其它成员提高。6-8分作为交办的事情愿意做如下改进：发现工作过程中存在的问题，提岀改进方法，能够 解决问题。学习新的工具和新的知识。改进测试工作，提高工作效率，改进工作产品质量。 开展专项培训，分享学习和研究成果，帮助团队其 它成员提高。3-5分墨寸成规或没有意识做如下改进：发现工作过程中存在的问题，提岀改进方法，能够 解决问题。学习新的工具和新的知识。改进测试中存在的问题，提高工作效率，改进工作 产品质量。主动开展专项培训，分享学习和研究成果，帮助团 队其它成员提高。0-2分说明：共5项，每项10分，共70

19、分 备注：1. 尽量对交付物进行评估，保持相对的客观性;2. 评估以季度为单位；3. 奖励评估结果为 A B的员工；4. 人员在试用期不参与该评估；电气工程师考核评分表（月度）考核期间：年月姓名岗位任 务 绩 效序 号考核项目具/、体工作权重指标要求评分等级得分自 评上级结果1进度控制详 见 工 作 分 析 表的具/、 体 工 作10%严格按照施工总 进度计划中分部 分项工程的重要 节点（线管预留 预埋、室内穿线 安装、外网工程） 完成情况考核1、节点提前完工或通过 提前纠偏达到控制要求，10分2、主要节点考核每出现 1 次延误，扣1分；3次0 分3、延误后无可行的纠偏 落实方案，1次扣1分4

20、、严重影响工程进度造 成工程延误0分2质量控制10%电气工程施工质 量达到省优标 准；单项验收及 综合验收合格通 过1、按要求完成10分2、非一次性通过验收， 每项每次扣2分3、达不到标准0分3安全文明施工管理10%达到市文明施工 要求标准，无重 大安全事故1、按要求完成10分2、市安全文明施工检查 不通过，5分3、一般安全事故一次扣 1 分，重大安全事故 0分4材料、设备 检验10%材料进场检验合 格率在98%上; 设备检验合格100%1、达到要求10分2、主要材料进场后抽验 一次不合格扣1分； 工作失误未检、漏检 一次扣1分，不合格 材料进场并使用0分3、检验不合格的设备进 场并使用，0分

21、5成本控制10%严控现场签证 单、技术核定单， 确保成本控制目 标得到优化。1、原成本控制目标实现10分；2、合理建议或技术优化 降低成本10分；3、每出现一次不合理的 现场签证扣1分6隐蔽验收、 技术问题 处理10%隐蔽验收及时、 准确、资料完备； 设计变更落实； 技术、质里方面 问题处理及时准 确；1、达到要求10分；2、每失误1次扣1分7工程例会 落实10%会议纪要逐项落 实并反馈1、达到要求10分2、落实不了又不及时上 报，每项扣1分8开工前期 协调5%达到顺利开工条件1、积极参与协调5分2、每项工作不积极主动 每扣1分9外部配合5%配合职能部门1、积极参与配合5分2、不配合职能部门0

22、分10内业工作5%内业完整，施工 日记工整清晰1、达到要求5分2、检查不合格一次扣0.5复查不合格一次扣1分11集团配合5%积极参与并完成1、达到要求5分2、不积极主动参与，接 到投诉每次扣1分12内部配合5%专业上积极主动 配合其他工程师 工作1、达到要求5分2、不积极主动配合，接 到反映每次扣1分13维修协调5%积极配合物业处 理维修投诉1、达到要求5分2、不积极主动配合，接 到反映每次扣1分加权合计行 为 考 核序 号行为指标权重指标说明考核评分自 评上 级结果1承担责任25%1级：承认结果，而不是强调愿望 2级：承担责任，不推卸，不指责 3级：着手解决问题，减少业务流程 4级：举一反三

23、，改进业务流程5级：做事有预见，有防误设计1级5分2级10分3级15分4级20分5级25分2主动性25%1级：等候指示2级：询冋有何工作可给分配3级：提出建议，然后再作有关行动4级：行动，但例外情况下征求意见5级：单独行动，定时汇报结果1级5分2级10分3级15分4级20分5级25分3学习力25%1级 2级3级4级5级:有学习意识但无仃动:主动学习:自费学习并得到技能:学习后用于实践:学习后实践并得到良好效果1级5分2级10分3级15分4级20分5级25分4团队合作25%1级意见2级团队3级使自4级:尊重他人，耐心倾听，接纳不同，合理和包容:直言，分享他们的观点和信息使 前进:支持团队（领导者

24、）的决定，即 己有不同意见:愿意提供即使是不属自己日常工1级5分2级10分3级15分4级20分5级25分作职责范围的帮助5级：跨边界建立关系以发展非正式及 正式工作网络加权合计总 分总分=业绩考核得分X %+行为考核得分X %=考核人签字：年月日软件测试的起源与发展软件测试的概念与定义软件测试是伴随着软件的产生而产生的。早期的软件开发过程中，那时软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于 调试”目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进

25、行测试。直到1957年，软件测试才开始与调试区别开来，作为一种发现软件缺陷的活动。由于一直存在着为了让我们看到产品在工作，就得将测试工作往后推一点”的思想，潜意识里对 测试的目的就理解为使自己确信产品能工作 ”测试活动始终后于开发的活动，测试通常被做为软件生命周期中最后一项活动而进行。当时也缺乏有效的测试方法，主要依靠错误推测Error Guess in g”来寻找软件中的缺陷。因此，大量软件交付后，仍存在很多问题，软 件产品的质量无法保证。到了 20世纪70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考软件开发 流程的问题，尽管对 软件测试”的真正含义还缺乏共识，但这一词条已经频繁出现

26、，一些软件测试的探索者们建议在软件生命周期的开始阶段就根据需求制订测试计划，这时也涌现出一批软件测试的宗师，Bill Hetzel博士就是其中的领导者。1972年，软件测试领域的先 驱 Bill Hetzel 博士（代表论著The Complete Guide to Software Testi ng），在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。在1973年，他首先给软件测试一个这样的定义：就是建立一种信心，认为程序能够按预期的设想运行。Establishconfid ence that a program does what it is supposed to do.

27、后来在 1983 年他又将定义修订为：评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。Any activities aimed at evaluati ng an attribute orcapability of a program or system.在他的定义中的 设想"和 预期的结果"其实就是我们现在所说的用户需求或功能设计。他还把软件的质量定义为符合要求”。他的思想的核心观点是：测试方法是试图验证软件是工作的”所谓 工作的”就是指软件的功能是按照预先的设计执行的，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。

28、软件测试业 界把这种方法看作是的软件测试的第一类方法。Gle nfordJ.尽管如此，这一方法还是受到很多业界权威的质疑和挑战。代表人物是Myers （代表论著The Art of Software Testi ng）。他认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后用逆向思维去发现尽可能多的错误。他还从人的心理学的角度论证，如果将验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：测试是为发现错误而执行的一个程序或者系统的过程。The process of execut ing a program or

29、systemwith the intent of finding errors.这个定义，也被业界所认可，经常被引用。除此之外,Myers还给出了与测试相关的三个重要观点，那就是:1、测试是为了证明程序有错，而不是证明程序无错误；2、一个好的测试用例是在于它能发现至今未发现的错误；3、一个成功的测试是发现了至今未发现的错误的测试；这就是软件测试的第二类方法，简单地说就是验证软件是不工作的”或者说是有错误的。Myers认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。这就如同一个病人（假定此人确有病），到医院做一项医疗检查，结果各项指标都正常，那说明该项医 疗检查对于诊断该病人的病情是

30、没有价值的，是失败的。Myers提出的 测试的目的是证伪”这一概念，推翻了过去 为表明软件正确而进行测试 ”的错误认识，为软件测试的发展指出了 方向，软件测试的理论、方法在之后得到了长足的发展。第二类软件测试方法在业界也很流 行，受到很多学术界专家的支持。然而，对 Glenford Myers先生 测试的目的是证伪"这一概念的理解也不能太过于片 面。在很多软件工程学、 软件测试方面的书籍中都提到一个概念：测试的目的是寻找错误，并且是尽最大可能找出最多的错误”这很容易让人们认为测试人员就是挑毛病”的，而由此带来诸多问题。大家熟悉的Ron Patt on 在软件测试（中文版由机械工业出版

31、社出版，此书是目前国内测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：软件测试人员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。”这样的定义具有一定的片面性，带来的结果是：1、若测试人员以发现缺陷为唯一目标，而很少去关注系统对需求的实现，测试活动往往会存 在一定的随意性和盲目性；2、 若有些软件企业接受了这样的方法，以Bug数量来做为考核测试人员业绩的唯一指标，也 不太科学。总的来说，第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行 软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过， 如果不相符则视为Bug。这一过程的终极目标是将软件的

32、所有功能在所有设计规定的环境全部运行，并 通过。在软件行业中一般把第一类方法奉为主流和行业标准。第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。而第二类测试方法与需求和设计没有必然的关联，更强调测试人员发挥主观能动性，用逆向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统各种的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问 题。这种方法往往能够发现系统中存在的更多缺陷。到了上世纪80年代初期，软件和IT行业进入了大发展

33、，软件趋向大型化、高复杂度， 软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将 质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证（SQA ）的主要职能，包含软件质量评价的内容，Bill Hetzel在软件测试完全指南（Complete Guide ofSoftware Testi ng） 书中指出： 测试是以评价一个程序或者系统

34、属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义至今仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。软件测试已有了行业标准(IEEE/ANSI ) , 1983 年IEEE提出的软件工程术语中给软件测试下的定义是：使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之 间的差别”这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。它再 也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。软件测试成

35、熟度随着软件产业界对软件过程的不断研究，美国工业界和政府部门开始认识到，软件过 程能力的不断改进才是增进软件开发组织的开发能力和提高软件质量的第一要素。在这种背景下，由美国卡内基-梅隆大学软件工程研究所(SEI )研制并推出了软件能力成熟度模型 SW-CMM，CMM逐渐成为了评估软件开发过程的管理以及工程能力的标准。从80年代中期开始，软件生产开始进入以个体软件过程PSP(Personal Software Process)、过程成熟度模型CMM和群组软件过程 TSP(Team Software Process) 为标志的、以过程为中心 的第二阶段。但是令人遗憾的是，CMM没有充分的定义软件测

36、试，没有提及测试成熟度的概念，没 有对测试过程改进进行充分说明，在KPA中没有定义测试问题，与质量相关的测试问题如可测性，充分测试标准，测试计划等方面也没有满意的阐述。仅在第三级的软件产品工程(SPE)KPA中提及软件测试职能，但对于如何有效提高机构的测试能力和水 平没有提供相应指导，无疑是一种不足。为此，许多研究机构和测试服务机构从 不同角度出发提出有关软件测试方面的能力成熟度模型，作为SEI-CMM 的有效 补充，比较有代表性的包括：美国国防部提出一个CMM软件评估和测试KPA建 议；Gelper 博士提出一个测试支持模型(TSM)评估测试小组所处环境对于他 们的支持程度；Burgess/

37、DrabickI.T.I.公司提出的测试能力成熟度模型(TestingCapability Maturity Model )则提供了与 CMM 完全一样的 5 级模型。Burnstein 博士提出了测试成熟度模型(TMM )，依据CMM的框架提出测试 的5个不同级别，关注于测试的成熟度模型。它描述了测试过程，是项目测试部分得到 良好计划和控制的基础。TMM测试成熟度分解为 5级别，关注于5个成熟度级别递增：Phase 0:测试和调试没有区别，初了支持调试外，测试没有其他目的Phase 1:测试的目的是为了表明软件能够工作Phase 2:测试的目的是为了表明软件不能够能够正常工作Phase 3:

38、测试的目的不是要证明什么，而是为了把软件不能正常工作的预知风险降低到能够接受的程度Phase 4:测试不是行为，而是一种自觉的约束(me ntal discipli ne)，不用太多的测试投入产生低风险的软件上的。软件测试模型的演变软件测试模型与软件测试标准的研究也随着软件工程的发展而越来越深入，在2 0世 纪8 0年代后期 Paul Rook提出了著名的软件测试的 V模型，旨在改进软件开发的效率和 效果。V模型反映出了测试活动与分析设计活动的关系。在图1-1中，从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各

39、阶段的对应关系。图1-1V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。Evolutif 公司针对V模型的缺陷，相对于 V模型，提出了 W模型的概念， W模型增 加了软件各开发阶段中应同步进行的验证和确认活动。如图1-2所示，W模型由两个 V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并

40、行关系。W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设 计等同样要测试，也就是说，测试与开发是同步进行的。W 模型有利于尽早地全面的发现问题。例如，需求分析完成后， 测试人员就应该参与到对需求的验证和确认活动中，以尽早 地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。但W模型也存在局限性。在 W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。软件测试工具的发展进入上世纪90年代，软件行业开始迅猛发

41、展，软件的规模变的非常大，在一些大型软 件开发过程中，测试活动需要花费大量的时间和成本，而当时测试的手段几乎完全都是手工测试，测试的效率非常低；并且随着软件复杂度的提高，出现了很多通过手工方式无法完成测试的情况，尽管在一些大型软件的开发过程中，人们尝试编写了一些小程序来辅助测试， 但是这还是不能满足大多数软件项目的统一需要。于是，很多测试实践者开始尝试开发商业的测试工具来支持测试， 辅助测试人员完成某一类型或某一领域内的测试工作，而测试工具逐渐盛行起来。人们普遍意识到，工具不仅仅是有用的， 而且要对今天的软件系统进行充分 的测试，工具是必不可少的。 测试工具可以进行部分的测试设计、实现、执行和

42、比较的工作。通过运用测试工具， 可以达到提高测试效率的目的。测试工具的发展，大大提高了软件测试的自动化程度，让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。采用自动比较技术， 还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现“夜间测试”和“无人测试”。在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测 试，在执行相同数量测试时节约测试时间。而测试工具的选择和推广也越来越受到重视。在软件测试工具平台方面，商业化的软件测试工具已经很多，如捕获/回放工 具、Web测试工具、性能测试工具、测试

43、管理工具、代码测试工具等等，这些都 有严格的版权限制且价格较为昂贵，但由于价格和版权的限制无法自由使用，当 然，一些软件测试工具开发商对于某些测试工具提供了 Beta 测试版本以供用户 有限次数使用。幸运的是，在开放源码社区中也出现了许多软件测试工具，已得 到广泛应用且相当成熟和完善。校园招聘系统测试总结报告文档标识：当前版本：当前状态：草稿发布日期：发布修改历史日期版本作者修改内容评审号变更控制号目录1. 测试概述 211.1 编写目的 211.2 测试范围 211.3 参考资料 222. 测试计划执行情况 222.1 测试类型 222.2 进度偏差 232.3 测试环境与配置 242.4

44、测试机构和人员 242.5 测试问题总结 253. 测试总结 253.1 测试用例执行结果 253.2 测试问题解决 273.3 测试结果分析 28 覆盖分析 28 缺陷分析 284. 综合评价 294.1 软件能力 294.3 建议 301. 测试概述1.1 编写目的对 MicroMOe 项目中所有的软件测试活动中，包括测试进度、资源、问题、风险以及测试 组和其他组间的协调等进行评估，总结测试活动的成功经验与不足，以便今后更好的开展测试 工作。本系统测试总结报告的预期读者是：? 开发部经理；? 项目组所有人员；? 测试组人员；? SQA人 员；? SCM人 员；以及B公司授权调阅本文档的其他

45、人员。1.2 测试范围MicroMOe 项目因其自身的特殊性， 测试组仅依据用户需求说明书和软件需求规格说明书以 及相应的设计文档进行系统测试，包括功能测试、性能测试、用户访问与安全控制测试、用户 界面测试以及兼容性测试等，而单元测试和集成测试则由开发人员来执行。主要功能包括： 前台个人求职功能注册新用户登录系统找回密码更改密码填写简历信息预览简历信息修改简历信息查询职位浏览职位应聘职位浏览公告信息浏览申请记录招聘企业管理后台登录系统修改注册信息修改密码职位管理用户管理申请查询浏览通知信息 申请表详情系统提供商管理后台管理员登录系统查询简历简历详情发布公告信息1.3参考资料资料名称版本作者是否

46、经过评审备注校园招聘系统 MicroMOe软件开发计划.doc2.0已评审校园招聘系统 MicroMOe系统测试方案.doc1.1已评审校园招聘系统 MicroMOe测试计划.doc1.1已评审校园招聘系统MicroMOe测试进度表.mpp1.1已评审2. 测试计划执行情况2.1测试类型测试类型测试内容测试目的所用的测试工 具和方法功能测试个人前台：注册新用户、登录系统、找回 密码、更改密码、填写简历信息、预览简历 信息、修改简历信息、查询职位、浏览职位、 应聘职位、浏览公告信息、浏览申请记录企业后台：登录系统、修改注册信息、修 改密码、职位管理、用户管理、申请查询、 浏览通知信息、申请表详情

47、核实所有功能均已正常实现，即可按每 个用户的需求定制不冋的申请表及招 聘流程（筛选、笔试、面试）。1 业务流程检验：各个业务流程符合 常规逻辑，用户使用时不会产生疑 问。2、数据精确：各数据类型的输入输出 时统计精确。采用黑盒测试， 使用边界值测 试、等价类划 分、数据驱动等 测试方法，进行 手工测试；管理后台：管理员登录系统、查询简历、简历详情、发布公告信息用户界面1.导航、链接、Cookie、页面结构包括菜核实各个窗口风格(包括颜色、字体、WEB测试通用方法(UI)测试单、背景、颜色、字体、按钮名称、TITLE、提示信息、图标、TITLE等等)都与基手工测试提示信息的一致性等。准版本保持一

48、致，或符合可接受标准，2.友好性、易用性、合理性、一致性、正能够保证用户界面的友好性、易操作确性等，(详性，而且符合用户操作习惯。见:sepg-sever/TDBIN/start_a.htmProject:PRJ_MicroMOe , UserName:guest )安全性和访1.密码：登录、企业用户、个人用户、管1应用程序级别的安全性：核实用户黑盒测试、测试手工问控制测试理员用户；只能操作其所拥有权限能操作的功能。2.权限限制；2 系统级别的安全性：核实只有具备3.通过修改URL非法访问；系统访问权限的用户才能访问系统。4.登录超时限制等等；兼容性测试1.用不同版本的不同浏览器：NetSca

49、pe、核实系统在不同的软件和硬件配置中黑盒测试、测试手工MylE、 Tecent,IE5.5,IE6.0,分辨运行稳定率：800*600、1024*768,操作系统：WIN2000 Server 、WIN2000Professional 、WIN XP分别进行测试。2.不同操作系统、浏览器、分辨率和各种运行软件等各种条件的组合测试。性能测试1.最大并发数；核实系统在大流量的数据与多用户操LoadRunner 8.0自动化测试2.查询职位、简历时，注册新用户时以及作时软件性能的稳定性，不造成系统崩登录时系统的响应时间；溃或相关的异常现象2.2进度偏差测试活动计划起止日期实际起止日期进度偏差备注制

50、定测试计划待SDP评审完毕测试计划等待和 SCMP SQAF评审同时评审分解测试需求测试需求Review选定测试范围编写测试万案测试方案评审待测试用例设计完毕后评审设计测试用例根据需求变更修改用例测试用例评审测试执行测试移交延迟一天测试总结2.3测试环境与配置资源名称/类型配置测试PC机（4台）P4,主频1.6G以上，硬盘 40G内存512M本要求是最小 配置。TD7.6服务器，DB服务器（同1台）PC Server : 512M内存、40G SCSI 硬盘数据库管理系统SQL Server2000应用软件MICROSOFT OFFICEVISIO、VISUAL SOURCESAFMicrosoftProject客户端前端展示IE6.0负载性能测试工具Loadrunner8.0 ;功能性测试工具MANUAL测试管理工具TestDirector7.62.4测试机构和人员测试阶段测试机构名称负责人参与人员所充当角色系统测试测试组测试人员2.5测试问题总结在整个系