2022质量控制部门职责及分工VIP

1、第 PAGE32 页 共 NUMPAGES32 页2022质量控制部门职责及分工目 录第1章定义21.1质量的定义21.2质量控制的定义21.3测试的定义21.4什么才是BUG21.4.1功能不正常21.4.2难以使用的软件21.4.3未做良好规划21.4.4所提供的功能缺乏31.4.5与使用者的互动31.4.6使用性能太差31.4.7未做好错误处理41.4.8边界错误41.4.9计算错误41.4.10使用一段时间所产生的错误41.4.11控制流程的错误41.4.12在压力之下所产生的错误51.4.13不同硬设备所导致的错误51.4.14版本控制不良所产生的错误51.4.15文件错误5第2章质

2、量控制部门的组成62.1部门的定位62.2部门成员的角色及职责62.2.1质量控制经理62.2.2质量监视员62.2.3测试协调员62.2.4测试执行员62.2.5用户培训员62.2.6系统施行员72.2.7过程研究员72.3部门成员的要求72.3.1对测试人员的要求7第3章质量控制部门的职责93.1售前93.1.1理解需求93.1.2熟悉功能和性能93.1.3确认工期93.1.4确定标准93.2售中93.2.1制定测试方案93.2.2产品测试93.2.3管理BUG93.2.4产品质量的评审93.2.5工程文档的评审93.2.6编制用户手册93.2.7用户培训103.2.8系统施行103.3售

3、后103.3.1测试文档提交103.3.2测试总结103.3.3完善测试标准、标准103.4过程改良103.4.1开发过程的评审103.4.2对开发过程的各项标准的定义103.4.3开发过程的持续改良10第4章质量控制部门的工作标准114.1共同分担责任114.2良好的工作心态114.3工作方案及进度控制114.4积极参与及有效沟通114.5建立良好的工作环境114.6抛弃自我114.7不含敌意的冲突114.8如何解决问题114.8.1各项工作的标准11第5章质量控制部门分级测试方案125.1方案要到达的目的：125.2分级测试方案125.2.1一级测试内容125.2.2二级测试内容125.2

4、.3三级测试内容125.2.4四级测试内容125.3为什么采用分级测试方案125.3.1问题一：用户演示时出现错误页面等明显BUG125.3.2问题二：BUG遗漏率太大125.4BUG状态说明135.5分级测试方案工作流程135.5.1一级测试流程135.5.2二级测试流程145.5.3三级测试流程155.5.4四级测试流程16第6章部门人员工作考核方案176.1考核表176.1.1测试工作考核表176.1.2用户培训考核表176.2考核说明18 定义质量的定义质量的静态定义：产品或效劳能满足规定或潜在需求的特性和特征的集合。质量的动态定义：是一个持续改良的过程，在这个过程中获得的教训被用于进

5、步将来产品和效劳的质量。质量控制的定义质量控制是关于活动和技术的集合性术语，在此过程中，活动与技术旨在创造特定的质量特征。这种活动包括不断监控过程、识别和消除产生问题的原因、利用统计过程控制来减少可变性和增加这些过程的效率。质量控制能保证组织的质量以实现。测试的定义在G.J.Myers的经典著作软件测试技巧中，给出了测试的定义：“程序测试是为了发现错误而执行程序的过程”。什么才是BUG断定在测试中发现的问题是否属于BUG，界定如下：功能不正常、难以使用、未做良好规划、功能缺乏、与使用者互动不良、性能太差、未做好错误处理、边界错误、计算错误、使用一段时间所产生的错误，控制流程的错误、在压力之下所

6、产生的错误、不同硬设备所导致的错误、版本控制不良所产生的错误和文件错误。功能不正常简单地说就是所应提供的功能，在使用上并不符合设计规格，或是根本无法使用。这个错误常常会发生在测试过程的初期和中期，有许多在设计规格内所应提供的功能无法运行，或是运行结果达不到预期设计。是明显的例子就是在UI上所提供的选项及动作，使用者在操作后毫无反响。难以使用的软件只要是不知如何使用或难以使用的软件，在设计上一定是出了问题。所谓好用的软件就是使用上尽量方便，压低使用者的学习曲线。未做良好规划这里可以区分出所测试的软件是以Top-Down的方式开发，还是以Bottom-Up的方式开发的。假如是以Top-Down构造

7、式方法所开发的软件，在功能的规划及组织上比拟完好，相反的Bottom-Up的组合式开发所呈现出来的软件功能较为分散。举例来说，假设有一个软件提供了3个扫描的功能：实时扫描、手动扫描和全面扫描。就功能而言，这3种功能应该放到同一个扫描选项内，可是因为实时扫描是后来增加的，而且提供了立即编辑的功能，因此它被独立出来成为另一个单独选项。所造成的结果是许多的使用者误以为在实时扫描所做的立即编辑设置，应该可以套用在其他两种扫描功能上。所提供的功能缺乏这个问题与功能不正常是不一样的。这里所指的是软件所提供的功能在动作上是正常的，可是对使用者而言却是不完好的。即使软件的功能运作结果符合设计规格的要求，系统测

8、试人员在测试结果的判断上，也一定要从使用者的角度进展考虑。这里举一个例子，假设所测试的软件提供了数据处理功能，但是采用的是封闭式的CodeBase数据库。对开发人员来说，采用CodeBase的数据库对程序编写来说比拟容易，经过测试之后也未发生其他的问题。可是在客户的环境下进展Beta测试之后才发现，客户要求提供支持SQL数据库的功能，因为他们希望可以统一管理所有的资料。在这种情况下，系统测试工程师必须将这个问题呈现出来，虽然如今要求增加这个需求已经太晚了，不过可以建议提供另一种解决方法，例如提供一个资料转换工具或是提供资料导出的功能。测试人员要随时对进展测试的功能保持一个存疑的态度，因为这样的

9、问题假如出如今开发的后期，所能提供的解决方式很有限，所以早一点发现这样的问题对进步整个开发质量的帮助很大。通常这样的问题大都是由经历丰富的测试工程师发现的。与使用者的互动一个好的软件必须与使用者之间正常互动。在使用者操作使用软件的过程中，软件必须很好地响应使用者。这个问题常常有网络中阅读网页时出现。假设目前使用者正在某一个网页填写资料，但是所填写的资料缺乏或是有误。当使用者单击了“确定”按钮之后，网页响应使用者所填写的资料有错，可是并未指明错误在哪里，使用者只好回到上一页后重新填写一次，或是直接放弃分开网站。这个问题就是软件对使用互动并I未做完好的设计，对于属于窗口程序类型的软件，这一点也常常

10、被忽略，例如当使用者做任何更新或删除动作的前后，程序是否提供相应的信息给使用者？或对所执行的动作做确认？如提供确认窗口。与使用者的互动原那么就是所有的动作必须伴随着适当的响应Every action e with a reaction。使用性能太差所测试的软件功能正常但是使用性能太差了，这样算不算问题呢？这个问题，也经常有测试人员问。使用性能不佳，当然是一个问题，而问题通常是由于开发人员采用了错误的解决方案，或是运用了不适用的算法所导致的。例如有一个软件属于C/S的企业软件，Server端会将Client传递上来的资料做好分类处理。由于资料所包含的种类相当多，于是开发人员将它分别存入不同的资料

11、文件内，例如Client A送给Server的资料种类有A1-A10，而Server就分别将资料存到10个不同的资料文件内。这样做的结果是造成使用者在做资料查询时速度出奇地慢，因为Server会逐一搜寻10个不同的资料文件内容来做比照。类似的例子相当多，寻根究底是因为未做好根底审核Architecture Review及设计审核Design Review，可是却大都是在进展系统测试或性能测试时才显示出问题的严重性。当然，在有些情况下，工程经理或开发人员会反驳说如此的使用性能是在合理的范围内。建议测试人员将竞争对手或同类型的软件拿来做一个性能测试，这个测试的结果最好以数字或百分比的形式返回给产品

12、及开发人员。这样的方式所到达的效果远比互相争吵来得有效得多。未做好错误处理软件除了防止出错之外，还要做好错误处理。许多软件之所以会产生错误，是因为程序本身不知道如何处理所遇到的错误。譬如说，所测试的程序可以读取外部的资料文件并且做一些分类整理，可是刚好所读取的外部资料文件的内容是被损毁的。当程序读取这个损毁的资料文件时，程序就发生问题，这时候操作系统不知如何处理这个状况，为了保护自己只好中断程序。由此可见这个程序并未做好错误处理。除了做好错误处理之外，同时也要设立防止错误发生的机制。如上述所说的，程序在读取外部资料文件之前，应该先检查外部资料文件是否毁损，这样的方法才比拟保险。当然，除了做好错

13、误处理之外，产品是否提供适当的调试机制，也是测试人员应该注意的。复杂的软件假如未提供调试文档或调试方法，在以后的维护过程中将会吃尽苦头。建议在进展软件设计规格阶段时，最好将调试机制包含在内，这对以后的开发过程与维护过程绝对有很大的帮助。边界错误缓冲区溢出的问题Buffer Overflows，这几年来成为相当热门的网络攻击方式，而这个错误就属于边界错误的一种。简单地说，程序本身无法处理超过边界资料所导致的错误。这个问题有许多情形是开发人员在声明变量或是使用资料的长度时不小心引起的。计算错误只要是软件程序就免不了包括数学计算。软件之所以会出现计算错误，大局部出错的原因在于采用了错误的数学运算或未

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

15、所以程序无法再进展第二次的更新动作。控制流程的错误控制流程的好与坏，考验着开发人员对软件开发的态度及设计的程序是否严谨。软件在状态间的转变是否合理，要根据流程进展控制。相信许多测试人员在使用软件时，有时候会有这种感觉为什么会跳到这一步？或是好似少了一个步骤等类似的问题，这就是所谓的控制流程错误。用软件安装程序解释这样的问题是最容易的。譬如使用者在进展软件安装时，在输入用户名及一些其他资料后，软件就直接进展安装了，问题就出在安装程序并未为使用者提供可以选择安装目的地的状态。这就是软件控制流程不完好的错误问题。在压力之下所产生的错误程序在处于压力状态下假如运作不正常的话，就是属于这种软件的错误。压

16、力测试对于Server级的软件是必需要进展的一项测试，因为Server级的软件对稳定度的要求远比其他的软件高。通常一连串的压力测试是必须配合着测试软件来施行的，例如让程序处理超过10万笔的资料，然后再来观察程序运行的结果。要准备10万笔的资料就必须借助于测试软件。不同硬设备所导致的错误顾名思义就是问题的产生与硬件设备不同有关。假如所开发的软件与硬件设备有直接的关系，这样的问题就会相当多，例如光盘刻录机的软件就存在不少这样的问题。例如：所开发的软件在特殊品牌的效劳器上运行约七八分钟就会停摆。版本控制不良所产生的错误出现这样的问题属于工程管理的忽略，当然测试人员未善尽职守也是原因之一。在最近的例子

17、中有一个错得很冤，情形是这家公司一年前所出版的一个软件被反响有平安上的破绽，后来这家公司也很快将这个问题的修正版提供应客户下载。理论上这个事件就应该平息了，但是在一年后他们在推出新版本时，却忘记将这个已解决掉的问题参加新版本内。所以对旧客户来说，本来的问题已经解决了，可是想不到将版本晋级后，旧问题又出现了。文件错误最后这个错误是文件错误。这里所提及的错误除了软件所附带的使用手册、说明文档、FAQ，以及其他相关的文件内容除了降低质量之外，最主要的问题是会误导作用者。很多客户投诉，不满使用手册所提供的资料与实际不符合。质量控制部门的组成部门的定位质量控制部门不仅仅是一个测试部门，与单纯的测试部门有

18、着重要的区别：测试针对一个工程，包含详细的技术工作，它是工程组的一个核心角色。质量控制是公司的一个职能部门，它在一个负责企业质量和标准施行和监视的人领导下工作。质量控制也负责在不同的工程组之间共享最好的理论经历。部门成员的角色及职责质量控制部门的角色分为七种：质量控制经理、质量监视员、测试协调员、测试执行员、用户培训员、系统施行员、过程研究员。质量控制经理质量控制经理的职责是：协调部门各角色的工作，并对最终发布的产品、产品的文档及整个开发过程进展评审。质量监视员质量监视员的职责是：参与工程组，具有使工程组成员充分理解各项标准和标准的责任；协助并监视工程组在开发过程中执行相关标准和标准；协助质量

19、控制经理对开发过程进展评审；可根据执行情况对各项标准和标准提出改善建议。测试协调员测试协调员的职责是：针对某个产品或某个工程制定测试方案和测试方法，确定测试工期；根据各测试执行员提交的测试结果，完成工程或产品的测试总结报告。一个测试协调员的角色可由多个人员担任，一个人员也可担任多个测试协调员的角色。测试执行员测试执行员的职责是：根据测试协调员制定的测试方案和测试方法编写测试说明包括测试用例的设计和说明；对产品进展测试，并记录测试结果；对BUG进展管理，保证它们在产品提交以前被解决；参与产品的质量评审。用户培训员用户培训员的职责是：参与系统测试，并在系统测试的同时获取系统界面、理解系统的操作，完

20、成用户手册和培训教材；通过方案演示和系统培训，最大可能性地使系统的使用者得到相关产品和效劳的价值。过程研究员过程研究员的职责是：参与工程或产品开发过程评审，参与产品质量评审，并根据评审结果对开发过程进展分析p ，找出影响产品质量的主要因素，并针对主要因素提出相应的过程改良方案。部门成员的要求产品质量关系到企业的生命和前途，质量控制部门应全程跟踪产品的开发过程，是产品质量的最后一道防线，对最终发布的产品的质量负有直接的责任，所以对部门成员的要求是：有高度的责任心、对工作的认真态度、具有严谨和细致的思维习惯。对测试人员的要求测试人员包括：测试协调员、测试执行员人是测试工作中最有价值也是最重要的资，

21、没有一个合格的、积极的测试小组，测试就不可能实现。为高质高效地完成测试任务，好的测试工程师应具有如下才能：沟通才能一名理想的测试者必须可以同测试涉及到的所有人进展沟通，具有与技术开发者和非技术人员客户，管理人员的交流才能。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈一样的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须可以同等地同用户和开发者沟通。技术才能就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可

22、信度就会立即被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有一定的编程经历，前期的开发经历可以帮助对软件开发过程有较深化的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。自信心开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。假如容许别人对自己指东指西，就不能完成什么更多的事情了。外交才能当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。假如采取的方法过于强硬，对测试者来说，在以后和开发部门

23、的合作方面就相当于“赢了战争却输了战役”。幽默感在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。疑心精神可以意料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持疑心直到他自己看过以后。自我催促干测试工作很容易使你变得懒散。只有那些具有自我催促才能的人才可以使自己每天正常地工作。洞察力一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的才能，强烈的质量追求，对细节的关注才能。应用的高风险区的判断才能以便将有限的测试针对重点环节。质量控制部门的职责售前理解需求理解客户需求、对测试的详细或特殊要求。熟悉功能和性能结合工程方案、需求分析p ，熟悉和分析

24、p 系统功能、性能指标。确认工期确认测试所需的工作量，提供应工程负责人以确认工程工期。确定标准与开发组确定开发标准和测试标准。售中制定测试方案根据用户需求和需求分析p 、设计方案，制定工程测试方案。产品测试测试的任务是保证产品或效劳交付之前，可以发现所有存在的问题。测试要准备测试方案、测试规定和测试的用例，这些文档用于拓宽测试范围和进展足够的可使用性测试。在软件开发的工程中，测试必须针对所有的接口，包括API的每个方面。将新软件集成到现行系统时也必须进展测试。系统测试工作全部完成后要准备测试总结报告。测试的内容包括：代码测试、单元测试、集成测试、系统测试、性能测试、系统施行测试、应用程序接口测

25、试。注：测试这种角色必须独立于开发才是真正有效的。管理BUG测试要管理BUG跟踪数据库，并对BUG报告的质量负责。BUG数据库对于产生针对进度跟踪工程状态的统计报告来说，是一种重要资。BUG报告也用于确定工程进度中的、关键局部的风险。产品质量的评审根据产品测试报告的对产品的质量进展评审，确定产品是否可以发布。工程文档的评审根据工程管理标准，按时检查各阶段需提交的开发文档，检查开发文档的标准性和正确性，对文档进展评审。编制用户手册在进展测试的过程中，获取系统界面，并对各项功能和操作进展说明，最后形成用户手册。用户培训用户培训的任务是通过方案演示和系统培训，最大可能性地使系统的使用者得到相关产品和

26、效劳的价值。用户培训的第二个任务是通过使产品更容易理解和使用，降低系统技术支持的费用。系统施行系统施行的任务是确保产品平稳地过渡、安装和移交到产品操作和技术支持组手中。售后测试文档提交将工程测试方案、工程测试总结报告以及开发文档交工程管理部相关负责人。测试总结总结测试中遇到的问题、经历、测试方法。完善测试标准、标准根据总结的结论，对不合适的测试标准、标准进展修订，使之更加完善。过程改良开发过程的评审根据工程开发过程中各标准的执行情况对开发过程进展评审。对开发过程的各项标准的定义定义开发过程中所需要遵循的各项标准，制定标准有两条原那么：一是标准应有利于稳定质量或在不损害质量的根底上降低开发本钱；

27、二是具有可执行性。开发过程的持续改良根据开发过程的评审结果及产品质量的结果，找出影响产品质量的因素，并改良开发过程的标准或方法，保持产品质量的稳定和持续上升。各工程组在开发过程中积累的好的经历也可作为持续改良开发过程的一个重要参考。质量控制部门的工作标准共同分担责任质量控制经理是部门的负责人，但部门的每位成员都有必要分担这个责任。良好的工作心态部门每一位成员都应始终保持如下的工作心态以保证产品的成功及个人成长：高度责任感、认真工作、思想开放，有着进一步自我开展的愿望。工作方案及进度控制充分理解客观情况，制订实在可行的工作方案，充分利用时间，对事情的开展主动加以控制，以做好为目的，对不可控制事情

28、及时预警，防止返工或重做。充分相信其他成员可以按时优质完成各自的任务而不影响其他成员的工作。积极参与及有效沟通在任何需要的时候都要积极参与，充分表达你的见解，而不是坐等被人问起。主动与其他小组成员进展明确与及时的沟通，提倡建立性的反响，防止任何指责性的言语和行为。每一位成员既是问题的发现者，又是问题的解决者。既便是面对超出职责范围的问题，也不能以此作为推诿的理由。建立良好的工作环境共同创造积极而又有建立性的工作环境：尊重部门的所有成员，也尊重其别人的观点。认识到个人之间的差异，不以自己的意志及好恶强求别人。摒弃骄傲、自满或固执的情绪，因为那会影响到部门成员的合作与互助。抛弃自我抛弃自我的概念：

29、团队的成功高于一切，个人的获取是次要的。在团队中没有自我的概念，从而也就没有个人的胜败。假如团队成功了，每个人都是赢家。不含敌意的冲突不含敌意的冲突是好的，它能激起讨论，以澄清认识并促成寻求新的方法。每个人都必须以积极的态度对待冲突，并愿意就面临的冲突广泛交换意见，尽力得到最好、解决方案，不允许有任何情绪化的言论和行为。反对无原那么的附和。在附和意见之前先问自己：出了门是不是还会支持决议？为其辩护？ 如何解决问题解决问题的9个步骤：说明问题；发现问题的可能原因；搜集资料并明确最可能原因；明确可能方案；评估可行方案；决定最正确方案；修订质量方案；施行方案；判断问题是否得以解决。各项工作的标准在部

30、门的各项工作的应遵循的标准和标准详见测试标准、过程改良标准、产品和过程度量标准、工程文档标准等。质量控制部门分级测试方案方案要到达的目的：1、防止再出现给用户演示时出现较明显的BUG。2、降低BUG的遗漏率。分级测试方案测试工作分为四级：一级测试内容1、正常操作，能否执行通过。2、需求描绘的功能是否实现只检查功能实现，不考虑合理性。二级测试内容1、业务逻辑是否合理。2、用户能否容易上手。三级测试内容1、非正常操作包括边界值、非法值、空值输入等看是否有适宜的异常处理错误提示是否准确易懂。2、页面布局及显示信息如：tital显示等。四级测试内容破坏性操作，如：多个用户对同一条信息进展删除等。性能测

31、试。压力测试。为什么采用分级测试方案在测试工作中遇到一些难以解决的问题，为理解决这些问题，制定了分级测试方案。问题一：用户演示时出现错误页面等明显BUG原因分析p ：测试人员在测试中，要检查系统所有方面的问题，涉及面广，造成工作量庞大，不能及时对系统进展全面检查。解决方法：采用测试分级方案，在给用户演示前，应提早通知质量保证部，对系统进展一级测试，测试通过才能进展演示，以保证演示顺利通过。问题二：BUG遗漏率太大假如测试人员的BUG遗漏太多，就失去测试的意义了。原因分析p ：测试人员要对以上四个级别的内容都进展测试，就要考虑很多方面的问题，这需要具有较强的思维严密性，不容易做到。解决方法：采用

32、测试分级方案，系统提交给测试人员后，先进展一级测试，测试人员只考虑一级测试的内容，完成后提交BUG给开发人员。按照一级测试流程进展见一级测试流程图。一级测试通过后，再进展二级测试，这样逐级上升，每个测试级别只考虑比拟单纯的问题，可以减轻测试人员的压力，这样就对思维严密性的要求降低很多，又能降低BUG遗漏率。BUG处理BUG状态说明状态说明标注状态的角色1Open已经发现的BUG测试人员2Updated已被修正的BUG开发人员3Disputed有争议的BUG开发人员4False假BUG测试人员5Close测试证实已经修正的BUG测试人员6Reopen.被修正的BUG再次出现，NO.为出现次数测试

33、人员BUG处理流程 分级测试方案工作流程一级测试流程 二级测试流程 三级测试流程 四级测试流程 部门人员工作考核方案考核表测试工作考核表考核项权重%评分描绘测试沟通：与相关人员沟通，充分理解需求2025细致：没有BUG遗漏35速度：可以在指定时间内完成20质量：无返工现象，符合要求25BUG记录分级：对BUG分级的判断准确1530BUG描绘：描绘准确，容易理解20修改意见：可以提出准确的修改意见25创新：能提出较好的解决方案15质量：无返工现象，符合要求25BUG追踪主动追踪BUG的修改情况4025沟通：开发人员对BUG的断定有疑问时，能有效地与开发人员沟通，解决争议60职业素质工作态度：工作热情、不发牢骚2020服从性：可以按要求完成任务20克制困难：遇到困难能想方法并努力解决15责任心：对工作负责，不推卸责任20协作：能与其他员工有效配合进展工作15亲和力：与所有人相处友