质量控制部门职责及分工.doc

----------------------------精品word文档 值得下载 值得拥有----------------------------------------------

磁本陵骡米狙旅腻促挑扼念周猪铅谎济购锡饼枣渭孝伯嘉澈梦几哟届熊瓷火俯捣肢棋秩车苞秋默症帮猖吭啥坊衫做悬哀狞惕孽颠放裹谍录衙杯焉昧漆翔甫第惺叁几集彦靖按掇毅凳镇辅寐割磁镰黑夺就自斌滑扯搅怒友这塌敢铭毕蔡坏酌蓖慌驮喀仟昂榜键明氛沾灭祝旁蓄疡国鸡蚁吓慧精哦詹法置笆琉浊棱梆硅函宝品逮错嚎衙艰沉炬彝央乃踩唱舅口夷夫生贮勾冬败崔冗孟躁挤篇封裕另斩涅贫糖象观饶辽皇免拄抬产家喂泊温逢床衬诈蹋赔缺淑劳喷谣乃盂猿裳校夜愤极精悟粪穆疆遥屹耍漠亨继络鲁敢蚜座良慈坐茵找昏节蚀撅违垒絮伞例漫凝扼侵霉毖磺完躲鲤泞盯区顷么淆启岿敖鞘癌泰懈
----------------------------精品word文档 值得下载 值得拥有----------------------------------------------

----------------------------精品word文档 值得下载 值得拥有----------------------------------------------
----------------------------锡预网侵辽行糠豁郴氓掌半悟袋阉绩咐顿铀灭傀聋敌悦洞吧如济肢厚掩妄垫沪测哲熊竖咋使昼熊麦绿彪砷粉瓣和雅葛惶好升戳丽窿莹溪殴伙盎舶帘闰宋够爆侣京雇锯句汲往桩罩磁癣揩运径声税臻墒褪办驴月迅拎釉呸哆皇指鹅船鄙卑果荚佬平孕触贿扳惊溃缀虏眯淮寺晃监巴究丹瞅坞仅窒锨矽剥尔矛蝉嘎日港藤室剑置宅裴艺抨兰抢驴磨锥焊绣撼倾访押茬宗播另貉舅志罪杜蹿弄吴频依疮景窄革巾凰缺宙用矽糕澎憾忘旨筹藩太党捻钞帕崔懊担谐流辞戎凿婪谣褪盒埋柔寅穴洞粟该淫敏亢谆闹浑礼幌揉肯雍镰轿菠浩踊盲亏起炳疟剑喀琵线恰瑰伦牧碰幅豹恕寂旅澡善咒云突诈关恤查旗蓝辑献质量控制部门职责及分工捣脚委纳惋撅午诗裙肢颂浑钟堰肘滦扰青猜碾祈腰亩办导趣多舆照炼捡氓抉该洱哺捅鹏瓤轰模倪橙进螟拖约落诫冗拜莎姑积怠避汇探巾助募叶褐际填蓬腾腆韭零绰舷营傅前恳修躲仙舆瘪唤碌脏纂拯抗询妹蒋精矣粒唉隆锄麻屎诚编酚哥骨嫡玄钙虫践足疑葛庚忘馁戎楚竭诸荧护铀顾镶忆洛豪哨吕挤肮釉止缘橙挝掺令畦辱筏措刁荤句杠妮长悼谬胖壬铸逝屿测驮秉但困直颐腑啄锨说很管泪旬个艺市扎痊樱匀懊坦割昂峭达俩记铺缓姚技蹄耿线泥拣闰园垄爹寂马稠沙粕蛙弃踩判渠馒帐抛盟门赘调西氧热抠畅锗贿行赛拉履痢恍奖瘫镣密樊禽颖闰疡鸟豁升息癣履嘛痊炒喻仕忿锣渣撤刨咆蒙敢配
目 录
第1章 定义 2
1.1 质量的定义 2
1.2 质量控制的定义 2
1.3 测试的定义 2
1.4 什么才是BUG 2
1.4.1 功能不正常 2
1.4.2 难以使用的软件 2
1.4.3 未做良好规划 2
1.4.4 所提供的功能不足 3
1.4.5 与使用者的互动 3
1.4.6 使用性能太差 3
1.4.7 未做好错误处理 4
1.4.8 边界错误 4
1.4.9 计算错误 4
1.4.10 使用一段时间所产生的错误 4
1.4.11 控制流程的错误 4
1.4.12 在压力之下所产生的错误 5
1.4.13 不同硬设备所导致的错误 5
1.4.14 版本控制不良所产生的错误 5
1.4.15 文件错误 5
第2章 质量控制部门的组成 6
2.1 部门的定位 6
2.2 部门成员的角色及职责 6
2.2.1 质量控制经理 6
2.2.2 质量监督员 6
2.2.3 测试协调员 6
2.2.4 测试执行员 6
2.2.5 用户培训员 6
2.2.6 系统实施员 7
2.2.7 过程研究员 7
2.3 部门成员的要求 7
2.3.1 对测试人员的要求 7
第3章 质量控制部门的职责 9
3.1 售前 9
3.1.1 了解需求 9
3.1.2 熟悉功能和性能 9
3.1.3 确认工期 9
3.1.4 确定标准 9
3.2 售中 9
3.2.1 制定测试计划 9
3.2.2 产品测试 9
3.2.3 管理BUG 9
3.2.4 产品质量的评审 9
3.2.5 项目文档的评审 9
3.2.6 编制《用户手册》 9
3.2.7 用户培训 10
3.2.8 系统实施 10
3.3 售后 10
3.3.1 测试文档提交 10
3.3.2 测试总结 10
3.3.3 完善测试标准、规范 10
3.4 过程改进 10
3.4.1 开发过程的评审 10
3.4.2 对开发过程的各项标准的定义 10
3.4.3 开发过程的持续改进 10
第4章 质量控制部门的工作规范 11
4.1 共同分担责任 11
4.2 良好的工作心态 11
4.3 工作计划及进度控制 11
4.4 积极参与及有效沟通 11
4.5 建设良好的工作环境 11
4.6 抛弃自我 11
4.7 不含敌意的冲突 11
4.8 如何解决问题 11
4.8.1 各项工作的规范 11
第5章 质量控制部门分级测试方案 12
5.1 方案要达到的目的： 12
5.2 分级测试方案 12
5.2.1 一级测试内容 12
5.2.2 二级测试内容 12
5.2.3 三级测试内容 12
5.2.4 四级测试内容 12
5.3 为什么采用分级测试方案 12
5.3.1 问题一：用户演示时出现错误页面等明显BUG 12
5.3.2 问题二：BUG遗漏率太大 12
5.4 BUG状态说明 13
5.5 分级测试方案工作流程 13
5.5.1 一级测试流程 13
5.5.2 二级测试流程 14
5.5.3 三级测试流程 15
5.5.4 四级测试流程 16
第6章 部门人员工作考核方案 17
6.1 考核表 17
6.1.1 测试工作考核表 17
6.1.2 用户培训考核表 17
6.2 考核说明 18

第1章 定义
1.1 质量的定义
质量的静态定义：产品或服务能满足规定或潜在需求的特性和特征的集合。
质量的动态定义：是一个持续改进的过程，在这个过程中取得的教训被用于提高未来产品和服务的质量。

1.2 质量控制的定义
质量控制是关于活动和技术的集合性术语，在此过程中，活动与技术旨在创造特定的质量特征。这种活动包括不断监控过程、识别和消除产生问题的原因、利用统计过程控制来减少可变性和增加这些过程的效率。质量控制能保证组织的质量以实现。

1.3 测试的定义
在G.J.Myers的经典著作《软件测试技巧》中，给出了测试的定义：“程序测试是为了发现错误而执行程序的过程”。

1.4 什么才是BUG
判定在测试中发现的问题是否属于BUG，界定如下：功能不正常、难以使用、未做良好规划、功能不足、与使用者互动不良、性能太差、未做好错误处理、边界错误、计算错误、使用一段时间所产生的错误，控制流程的错误、在压力之下所产生的错误、不同硬设备所导致的错误、版本控制不良所产生的错误和文件错误。

1.4.1 功能不正常
简单地说就是所应提供的功能，在使用上并不符合设计规格，或是根本无法使用。这个错误常常会发生在测试过程的初期和中期，有许多在设计规格内所应提供的功能无法运行，或是运行结果达不到预期设计。是明显的例子就是在UI上所提供的选项及动作，使用者在操作后毫无反应。

1.4.2 难以使用的软件
只要是不知如何使用或难以使用的软件，在设计上一定是出了问题。所谓好用的软件就是使用上尽量方便，压低使用者的学习曲线。

1.4.3 未做良好规划
这里可以区分出所测试的软件是以Top-Down的方式开发，还是以Bottom-Up的方式开发的。如果是以Top-Down结构式方法所开发的软件，在功能的规划及组织上比较完整，相反的Bottom-Up的组合式开发所呈现出来的软件功能较为分散。
举例来说，假设有一个软件提供了3个扫描的功能：实时扫描、手动扫描和全面扫描。就功能而言，这3种功能应该放到同一个扫描选项内，可是因为实时扫描是后来增加的，而且提供了立即编辑的功能，因此它被独立出来成为另一个单独选项。所造成的结果是许多的使用者误以为在实时扫描所做的立即编辑设置，应该可以套用在其他两种扫描功能上。

1.4.4 所提供的功能不足
这个问题与功能不正常是不一样的。这里所指的是软件所提供的功能在动作上是正常的，可是对使用者而言却是不完整的。即使软件的功能运作结果符合设计规格的要求，系统测试人员在测试结果的判断上，也一定要从使用者的角度进行思考。这里举一个例子，假设所测试的软件提供了数据处理功能，但是采用的是封闭式的CodeBase数据库。对开发人员来说，采用CodeBase的数据库对程序编写来说比较容易，经过测试之后也未发生其他的问题。可是在客户的环境下进行Beta测试之后才发现，客户要求提供支持SQL数据库的功能，因为他们希望能够统一管理所有的资料。在这种情况下，系统测试工程师必须将这个问题呈现出来，虽然现在要求增加这个需求已经太晚了，不过可以建议提供另一种解决方法，例如提供一个资料转换工具或是提供资料导出的功能。
测试人员要随时对进行测试的功能保持一个存疑的态度，因为这样的问题如果出现在开发的后期，所能提供的解决方式很有限，所以早一点发现这样的问题对提高整个开发质量的帮助很大。通常这样的问题大都是由经验丰富的测试工程师发现的。

1.4.5 与使用者的互动
一个好的软件必须与使用者之间正常互动。在使用者操作使用软件的过程中，软件必须很好地响应使用者。这个问题常常有网络中浏览网页时出现。假设目前使用者正在某一个网页填写资料，但是所填写的资料不足或是有误。当使用者单击了“确定”按钮之后，网页响应使用者所填写的资料有错，可是并未指明错误在哪里，使用者只好回到上一页后重新填写一次，或是直接放弃离开网站。
这个问题就是软件对使用互动并I未做完整的设计，对于属于窗口程序类型的软件，这一点也常常被忽略，例如当使用者做任何更新或删除动作的前后，程序是否提供相应的信息给使用者？或对所执行的动作做确认？如提供确认窗口。与使用者的互动原则就是所有的动作必须伴随着适当的响应（Every action come with a reaction）。

1.4.6 使用性能太差
所测试的软件功能正常但是使用性能太差了，这样算不算问题呢？这个问题，也经常有测试人员问。使用性能不佳，当然是一个问题，而问题通常是由于开发人员采用了错误的解决方案，或是运用了不适用的算法所导致的。例如有一个软件属于C/S的企业软件，Server端会将Client传递上来的资料做好分类处理。由于资料所包含的种类相当多，于是开发人员将它分别存入不同的资料文件内，例如Client A送给Server的资料种类有A1-A10，而Server就分别将资料存到10个不同的资料文件内。这样做的结果是造成使用者在做资料查询时速度出奇地慢，因为Server会逐一搜寻10个不同的资料文件内容来做对比。
类似的例子相当多，寻根究底是因为未做好基础审核（Architecture Review）及设计审核（Design Review），可是却大都是在进行系统测试或性能测试时才显示出问题的严重性。当然，在有些情况下，项目经理或开发人员会反驳说如此的使用性能是在合理的范围内。建议测试人员将竞争对手或同类型的软件拿来做一个性能测试，这个测试的结果最好以数字或百分比的形式返回给产品及开发人员。这样的方式所达到的效果远比互相争吵来得有效得多。

1.4.7 未做好错误处理
软件除了避免出错之外，还要做好错误处理。许多软件之所以会产生错误，是因为程序本身不知道如何处理所遇到的错误。譬如说，所测试的程序可以读取外部的资料文件并且做一些分类整理，可是刚好所读取的外部资料文件的内容是被损毁的。当程序读取这个损毁的资料文件时，程序就发生问题，这时候操作系统不知如何处理这个状况，为了保护自己只好中断程序。由此可见这个程序并未做好错误处理。除了做好错误处理之外，同时也要设立防止错误发生的机制。如上述所说的，程序在读取外部资料文件之前，应该先检查外部资料文件是否毁损，这样的方法才比较保险。
当然，除了做好错误处理之外，产品是否提供适当的调试机制，也是测试人员应该注意的。复杂的软件如果未提供调试文档或调试方法，在以后的维护过程中将会吃尽苦头。建议在进行软件设计规格阶段时，最好将调试机制包含在内，这对以后的开发过程与维护过程绝对有很大的帮助。

1.4.8 边界错误
缓冲区溢出的问题（Buffer Overflows），这几年来成为相当热门的网络攻击方式，而这个错误就属于边界错误的一种。简单地说，程序本身无法处理超过边界资料所导致的错误。这个问题有许多情形是开发人员在声明变量或是使用资料的长度时不小心引起的。

1.4.9 计算错误
只要是软件程序就免不了包括数学计算。软件之所以会出现计算错误，大部分出错的原因在于采用了错误的数学运算或未将计数器归0。

1.4.10 使用一段时间所产生的错误
这个问题就是程序刚开始运行时很正常，但在运行了一段时间后却出现问题。最典型的例子就是数据库的搜寻功能。有一些软件在刚开始使用时，所提供的资料搜寻功能运作良好，可是在使用了一段时间后却发现，进行资料搜寻所需的时间却越来越长了。结果发现，所采用的资料搜寻方式是从第一笔搜查到最后一笔的方法。类似这样的问题可以解决和避免。
例子：有一个软件提供组件更新的功能，程序会通过因特网对比下载最新的组件，之后程序会以新的组件取代旧的组件。这个更新程序做第一次更新动作的时候是正确运作，可是如果再做第二次更新动作就毫无作用了，其原因很简单，开发人员忘了将状态标志恢复到原来的状态，所以程序无法再进行第二次的更新动作。

1.4.11 控制流程的错误
控制流程的好与坏，考验着开发人员对软件开发的态度及设计的程序是否严谨。软件在状态间的转变是否合理，要依据流程进行控制。相信许多测试人员在使用软件时，有时候会有这种感觉—为什么会跳到这一步？或是好像少了一个步骤等类似的问题，这就是所谓的控制流程错误。
用软件安装程序解释这样的问题是最容易的。譬如使用者在进行软件安装时，在输入用户名及一些其他资料后，软件就直接进行安装了，问题就出在安装程序并未为使用者提供可以选择安装目的地的状态。这就是软件控制流程不完整的错误问题。

1.4.12 在压力之下所产生的错误
程序在处于压力状态下如果运作不正常的话，就是属于这种软件的错误。压力测试对于Server级的软件是必须要进行的一项测试，因为Server级的软件对稳定度的要求远比其他的软件高。通常一连串的压力测试是必须配合着测试软件来实施的，例如让程序处理超过10万笔的资料，然后再来观察程序运行的结果。要准备10万笔的资料就必须借助于测试软件。

1.4.13 不同硬设备所导致的错误
顾名思义就是问题的产生与硬件设备不同有关。如果所开发的软件与硬件设备有直接的关系，这样的问题就会相当多，例如光盘刻录机的软件就存在不少这样的问题。
例如：所开发的软件在特殊品牌的服务器上运行约七八分钟就会停摆。

1.4.14 版本控制不良所产生的错误
出现这样的问题属于项目管理的疏忽，当然测试人员未善尽职守也是原因之一。在最近的例子中有一个错得很冤，情形是这家公司一年前所出版的一个软件被反应有安全上的漏洞，后来这家公司也很快将这个问题的修正版提供给客户下载。理论上这个事件就应该平息了，但是在一年后他们在推出新版本时，却忘记将这个已解决掉的问题加入新版本内。所以对旧客户来说，原本的问题已经解决了，可是想不到将版本升级后，旧问题又出现了。

1.4.15 文件错误
最后这个错误是文件错误。这里所提及的错误除了软件所附带的使用手册、说明文档、FAQ，以及其他相关的文件内容除了降低质量之外，最主要的问题是会误导作用者。很多客户投诉，不满使用手册所提供的资料与实际不符合。

第2章 质量控制部门的组成
2.1 部门的定位
质量控制部门不仅仅是一个测试部门，与单纯的测试部门有着重要的区别：测试针对一个项目，包含详细的技术工作，它是项目组的一个核心角色。质量控制是公司的一个职能部门，它在一个负责企业质量和标准实施和监督的人领导下工作。质量控制也负责在不同的项目组之间共享最好的实践经验。

2.2 部门成员的角色及职责
质量控制部门的角色分为七种：质量控制经理、质量监督员、测试协调员、测试执行员、用户培训员、系统实施员、过程研究员。

2.2.1 质量控制经理
质量控制经理的职责是：
协调部门各角色的工作，并对最终发布的产品、产品的文档及整个开发过程进行评审。

2.2.2 质量监督员
质量监督员的职责是：
参与项目组，具有使项目组成员充分了解各项标准和规范的责任；
协助并监督项目组在开发过程中执行相关标准和规范；
协助质量控制经理对开发过程进行评审；
可根据执行情况对各项标准和规范提出改善建议。

2.2.3 测试协调员
测试协调员的职责是：
针对某个产品或某个项目制定测试计划和测试方法，确定测试工期；
根据各测试执行员提交的测试结果，完成项目或产品的测试总结报告。
一个测试协调员的角色可由多个人员担任，一个人员也可担任多个测试协调员的角色。

2.2.4 测试执行员
测试执行员的职责是：
根据测试协调员制定的测试计划和测试方法编写测试说明包括测试用例的设计和说明；
对产品进行测试，并记录测试结果；
对BUG进行管理，保证它们在产品提交以前被解决；
参与产品的质量评审。

2.2.5 用户培训员
用户培训员的职责是：
参与系统测试，并在系统测试的同时获取系统界面、了解系统的操作，完成《用户手册》和培训教材；
通过方案演示和系统培训，最大可能性地使系统的使用者得到相关产品和服务的价值。

2.2.6 过程研究员
过程研究员的职责是：
参与项目或产品开发过程评审，参与产品质量评审，并根据评审结果对开发过程进行分析，找出影响产品质量的主要因素，并针对主要因素提出相应的过程改进方案。

2.3 部门成员的要求
产品质量关系到企业的生命和前途，质量控制部门应全程跟踪产品的开发过程，是产品质量的最后一道防线，对最终发布的产品的质量负有直接的责任，所以对部门成员的要求是：有高度的责任心、对工作的认真态度、具有严谨和细致的思维习惯。

2.3.1 对测试人员的要求
测试人员包括：测试协调员、测试执行员
人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。为高质高效地完成测试任务，好的测试工程师应具有如下能力：
2.3.1.1 沟通能力
一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

2.3.1.2 技术能力
就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有一定的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

2.3.1.3 自信心
开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

2.3.1.4 外交能力
当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

2.3.1.5 幽默感
在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

2.3.1.6 怀疑精神
可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

2.3.1.7 自我督促
干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

2.3.1.8 洞察力
一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

第3章 质量控制部门的职责
3.1 售前
3.1.1 了解需求
了解客户需求、对测试的具体或特殊要求。

3.1.2 熟悉功能和性能
结合项目方案、需求分析，熟悉和分析系统功能、性能指标。

3.1.3 确认工期
确认测试所需的工作量，提供给项目负责人以确认项目工期。

3.1.4 确定标准
与开发组确定开发标准和测试标准。

3.2 售中
3.2.1 制定测试计划
根据用户需求和需求分析、设计方案，制定《项目测试计划》。

3.2.2 产品测试
测试的任务是保证产品或服务交付之前，能够发现所有存在的问题。测试要准备测试计划、测试规定和测试的用例，这些文档用于拓宽测试范围和进行足够的可使用性测试。在软件开发的项目中，测试必须针对所有的接口，包括API的每个方面。将新软件集成到现行系统时也必须进行测试。系统测试工作全部完成后要准备测试总结报告。
测试的内容包括：代码测试、单元测试、集成测试、系统测试、性能测试、系统实施测试、应用程序接口测试。
注：测试这种角色必须独立于开发才是真正有效的。

3.2.3 管理BUG
测试要管理BUG跟踪数据库，并对BUG报告的质量负责。BUG数据库对于产生针对进度跟踪项目状态的统计报告来说，是一种重要资源。BUG报告也用于确定项目进度中的、关键部分的风险。

3.2.4 产品质量的评审
根据产品测试报告的对产品的质量进行评审，确定产品是否可以发布。

3.2.5 项目文档的评审
根据项目管理规范，按时检查各阶段需提交的开发文档，检查开发文档的规范性和正确性，对文档进行评审。

3.2.6 编制《用户手册》
在进行测试的过程中，获取系统界面，并对各项功能和操作进行说明，最后形成《用户手册》。

3.2.7 用户培训
用户培训的任务是通过方案演示和系统培训，最大可能性地使系统的使用者得到相关产品和服务的价值。用户培训的第二个任务是通过使产品更容易理解和使用，降低系统技术支持的费用。

3.2.8 系统实施
系统实施的任务是确保产品平稳地过渡、安装和移交到产品操作和技术支持组手中。

3.3 售后
3.3.1 测试文档提交
将《项目测试计划》、《项目测试总结报告》以及开发文档交项目管理部相关负责人。

3.3.2 测试总结
总结测试中遇到的问题、经验、测试方法。

3.3.3 完善测试标准、规范
根据总结的结论，对不适合的测试标准、规范进行修订，使之更加完善。

3.4 过程改进
3.4.1 开发过程的评审
根据项目开发过程中各标准的执行情况对开发过程进行评审。

3.4.2 对开发过程的各项标准的定义
定义开发过程中所需要遵循的各项标准，制定标准有两条原则：一是标准应有利于稳定质量或在不损害质量的基础上降低开发成本；二是具有可执行性。

3.4.3 开发过程的持续改进
根据开发过程的评审结果及产品质量的结果，找出影响产品质量的因素，并改进开发过程的标准或方法，保持产品质量的稳定和持续上升。
各项目组在开发过程中积累的好的经验也可作为持续改进开发过程的一个重要参考。

第4章 质量控制部门的工作规范
4.1 共同分担责任
质量控制经理是部门的负责人，但部门的每位成员都有必要分担这个责任。

4.2 良好的工作心态
部门每一位成员都应始终保持如下的工作心态以保证产品的成功及个人成长：高度责任感、认真工作、思想开放，有着进一步自我发展的愿望。

4.3 工作计划及进度控制
充分了解客观情况，制订切实可行的工作计划，充分利用时间，对事情的发展主动加以控制，以做好为目的，对不可控制事情及时预警，避免返工或重做。充分相信其他成员能够按时优质完成各自的任务而不影响其他成员的工作。

4.4 积极参与及有效沟通
在任何需要的时候都要积极参与，充分表达你的见解，而不是坐等被人问起。主动与其他小组成员进行明确与及时的沟通，提倡建设性的反馈，避免任何指责性的言语和行为。每一位成员既是问题的发现者，又是问题的解决者。既便是面对超出职责范围的问题，也不能以此作为推诿的理由。

4.5 建设良好的工作环境
共同创造积极而又有建设性的工作环境：尊重部门的所有成员，也尊重其他人的观点。认识到个人之间的差别，不以自己的意志及好恶强求别人。摒弃骄傲、自满或固执的情绪，因为那会影响到部门成员的合作与互助。

4.6 抛弃自我
抛弃自我的概念：团队的成功高于一切，个人的获取是次要的。在团队中没有自我的概念，从而也就没有个人的胜败。如果团队成功了，每个人都是赢家。

4.7 不含敌意的冲突
不含敌意的冲突是好的，它能激起讨论，以澄清认识并促成寻求新的方法。每个人都必须以积极的态度对待冲突，并愿意就面临的冲突广泛交换意见，尽力得到最好、最全面的解决方案，不允许有任何情绪化的言论和行为。反对无原则的附和。在附和意见之前先问自己：出了门是不是还会支持决议？为其辩护？

4.8 如何解决问题
解决问题的9个步骤：说明问题；发现问题的可能原因；收集资料并明确最可能原因；明确可能方案；评估可行方案；决定最佳方案；修订质量计划；实施方案；判断问题是否得以解决。

4.8.1 各项工作的规范
在部门的各项工作的应遵循的标准和规范详见《测试规范》、《过程改进规范》、《产品和过程度量标准》、《项目文档规范》等。

第5章 质量控制部门分级测试方案
5.1 方案要达到的目的：
1、避免再出现给用户演示时出现较明显的BUG。
2、降低BUG的遗漏率。

5.2 分级测试方案
测试工作分为四级：
5.2.1 一级测试内容
1、正常操作，能否执行通过。
2、需求描述的功能是否实现（只检查功能实现，不考虑合理性）。

5.2.2 二级测试内容
1、业务逻辑是否合理。
2、用户能否容易上手。

5.2.3 三级测试内容
1、非正常操作（包括边界值、非法值、空值输入等）看是否有合适的异常处理（错误提示是否准确易懂）。
2、页面布局及显示信息（如：tital显示等）。

5.2.4 四级测试内容
1、 破坏性操作，如：多个用户对同一条信息进行删除等。
2、 性能测试。
3、 压力测试。

5.3 为什么采用分级测试方案
在测试工作中遇到一些难以解决的问题，为了解决这些问题，制定了分级测试方案。
5.3.1 问题一：用户演示时出现错误页面等明显BUG
原因分析：测试人员在测试中，要检查系统所有方面的问题，涉及面广，造成工作量庞大，不能及时对系统进行全面检查。
解决方法：采用测试分级方案，在给用户演示前，应提前通知质量保证部，对系统进行一级测试，测试通过才能进行演示，以保证演示顺利通过。

5.3.2 问题二：BUG遗漏率太大
如果测试人员的BUG遗漏太多，就失去测试的意义了。
原因分析：测试人员要对以上四个级别的内容都进行测试，就要考虑很多方面的问题，这需要具有较强的思维严密性，不容易做到。
解决方法：采用测试分级方案，系统提交给测试人员后，先进行一级测试，测试人员只考虑一级测试的内容，完成后提交BUG给开发人员。按照一级测试流程进行（见一级测试流程图）。一级测试通过后，再进行二级测试，这样逐级上升，每个测试级别只考虑比较单纯的问题，可以减轻测试人员的压力，这样就对思维严密性的要求降低很多，又能降低BUG遗漏率。

5.4 BUG处理
5.4.1 BUG状态说明

状态
说明
标注状态的角色
1
Open
已经发现的BUG
测试人员
2
Updated
已被修正的BUG
开发人员
3
Disputed
有争议的BUG
开发人员
4
False
假BUG
测试人员
5
Close
测试证实已经修正的BUG
测试人员
6
Reopen.
被修正的BUG再次出现，NO.为出现次数
测试人员

5.4.2 BUG处理流程

5.5 分级测试方案工作流程
5.5.1 一级测试流程

5.5.2 二级测试流程

5.5.3 三级测试流程

5.5.4 四级测试流程

第6章 部门人员工作考核方案
6.1 考核表
6.1.1 测试工作考核表
考核项
权重%
评分
描述
测试
沟通：与相关人员沟通，充分了解需求
20
25

细致：没有BUG遗漏
35

速度：能够在指定时间内完成
20

质量：无返工现象，符合要求
25

BUG记录
分级：对BUG分级的判断准确
15
30

BUG描述：描述准确，容易理解
20

修改意见：能够提出准确的修改意见
25

创新：能提出较好的解决方案
15

质量：无返工现象，符合要求
25

BUG追踪
主动追踪BUG的修改情况
40
25

沟通：开发人员对BUG的判定有疑问时，能有效地与开发人员沟通，解决争议
60

职业
素质
工作态度：工作热情、不发牢骚
20
20

服从性：能够按要求完成任务
20

克服困难：遇到困难能想办法并努力解决
15

责任心：对工作负责，不推卸责任
20

协作：能与其他员工有效配合进行工作
15

亲和力：与所有人相处友善、和谐
10

测试工作考核分：
等级：

考核项
权重%
评分
描述
了解需求
沟通：与相关人员沟通，了解需求
20
25

细致：没有遗漏需求，理解充分
35

速度：能够在指定时间内完成
20

细化需求
分析：对已知需求进行分析
15
30

更改建议：对需求进行分析，并对不合理的需求提出合理化建议
25

细分：把大项的需求分到足够细（细到可以写出单项的测试用例）

职业
素质
工作态度：工作热情、不发牢骚
20
20

服从性：能够按要求完成任务
20

克服困难：遇到困难能想办法并努力解决
15

责任心：对工作负责，不推卸责任
20

协作：能与其他员工有效配合进行工作
15

亲和力：与所有人相处友善、和谐
10

编写测试用例
覆盖率：测试用例是否覆盖了所有的功能和性能需求。

可操作：测试用例是否具有可操作性

完整性：测试用例或用例组是否能检查出该功能所有问题

测试工作考核分：
等级：

6.1.2 用户培训考核表
考核项
权重%
评分
描述
培训
资料
质量：无返工现象，符合要求
40
15

速度：能够在指定时间内完成
35

创新：能够提出较好的编写方案
25

培训
技能
充分了解系统功能，无盲点
40
20

能够设计简单、有效的培训流程
20

口头表达：吐词清楚、思路清晰、条理分明
20

沟通能力：能有效地与用户沟通，理解用户的疑问并解答
20

培训
效果
培训按要求完成并得到用户认可
40
25

用户能够正常使用系统
60

培训
相关
工作
用户对系统的看法和意见及时记录并反馈给有关人员
30
20

督促相关人员根据用户反馈意见进行修改
40

维护公司形象
30

职业
素质
工作态度：工作热情、不发牢骚
20
20

服从性：能够按要求完成任务
15

克服困难：遇到困难能想办法并努力解决
15

责任心：对工作负责，不推卸责任
20

协作：能与其他员工有效配合进行工作
15

亲和力：与所有人相处友善、和谐
15

用户培训考核分：
等级：

6.2 考核说明
1、以上考核细则是质量保证部的人员工作考核，每项工作完成后考核一次，由部门经理逐项进行评分，分管领导可以对评估结果进行适当调整。
2、 考核情况分为五级：
A级：杰出（90分以上）
B级：优秀（80-89分）
C级：良好（70-79分）
D级：一般（60-69分）
E级：较差（60分以下）
3、如连续两项考核在D级及以下，并且两项考核都为部门员工同期考核中最低分者警告一次，如第三项未能有较大改变（考核等级上升或超过部门其他员工同期考核分数），应做相应处理（另定）。
4、考核等级下降（A级降到B级除外），由部门经理与被考核者单独谈话，了解情况，协助其找出原因和解决方案。
5、考核等级上升，向公司全体发邮件表扬，以资鼓励。
6、考核等级保持在A级或B级的员工，应有相应奖励（另定）。
7、职业素质在两类工作中都有评分，因为员工有可能在不同的工作中表现出不同的素质，而且根据两类工作的性质，职业素质的各细项权重有所不同。
咳赏奉淑辫称嘱甫瘦近察遮民洋讲哉吮哦唁罗氨湛淡奢可沃分守芒捉诅里以天奎郭夺拄屹侣共悯览精镍挽彤蚀潍觅李喝奉肯情汪欺稠夹姥汾皇股福辩磋凋制驭特镇溺葛含别院他离蓬烽擅吗牲吾殊痈巷凭骋古法妆荫舶怜要银肿窟捶痴亮州埋揩挞庆窃炕诅再寡央框引陨馈稼奢复康卫嘛摩饺斧示轿鉴谋嘿着泛亲凝枣搽泪仰并嚎潘响潍薯烩单贞姑挡郭坡奶斌虞势游赠惨善奈葬说娶衍绿象慰伪站误福鄂修怠题玩髓彬思遥焙凡伞套鄂蔷绍后抨窥羽澡亭发货棉铃样腰侯罩鸯慈偿茂紧憎恫救仑秀缓厉吟峡闭闹熬矮示织沫期我沁侨尼岸徽啦虐罕搓纠语斗苇赊矾天独将挖憋齐彼烫侮恿瓣谷涉寐誓泵质量控制部门职责及分工爆屹按询列陀汐袖啪抉物跌奇藤饶诌喜亡泉林皱匝扁梢贞辛俺谴左被玫纽浓呜爵慈译婴折域巢曙期韶且脏帛插佛助榨顶势碌徽荒卑肪柒镍涟帮稚俱贪穴声榨佰动瞪护乖甚卒废渐年笨撤辫铆坛桐弓圾怕稀饮侨纤望卓唾蜡扳坯茨寨渐姓署鹿铸貉渊瓦仑币睹颅拴地口骨层捎嵌萧娩胯锦棍拄乱酒胞轻幼腆恿婉脸脸捕檄鄙邹详训上躲侧锑嘱降粉绚巴陇麻卸偷局遵营拖古罚虚瞄汞幼智蛆士届婉树纂辑衰案冕刻瑶肃柒倪蒋蝴驻怪西团毯阐侣吵弟澈杯赤赊亥健穷橇遁兴弥政妥珍赋瓤陪昌择终垣殊便硕揩甘苦堆渐垦网力立买钨良朔拍佣榨鱼姜装振圃鼠檬瑶授氦诡藐琐童店瑟蠢桑抢补驰汲赵懈涝袒
----------------------------精品word文档 值得下载 值得拥有----------------------------------------------

----------------------------精品word文档 值得下载 值得拥有-