品质管理质量控制质量控制部门职责与分工

《品质管理质量控制质量控制部门职责与分工》由会员分享，可在线阅读，更多相关《品质管理质量控制质量控制部门职责与分工（16页珍藏版）》请在金锄头文库上搜索。

1、最新卓越管理方案您 可自由编辑 最新卓越管理方案您 可自由编辑 目录目录 品质管理质量控制质量控 制部门职责与分工定义 品质管理质量控制质量控 制部门职责与分工定义 1.1 质量的定义1.1 质量的定义 质量的静态定义：产品或服务能满足规定或潜在需求的特性和特征的集合。 质量的动态定义：是一个持续改进的过程，在这个过程中取得的教训被用于 提高未来产品和服务的质量。 1.2 质量控制的定义1.2 质量控制的定义 质量控制是关于活动和技术的集合性术语，在此过程中，活动与技术旨在创 造特定的质量特征。这种活动包括不断监控过程、识别和消除产生问题的原因、 利用统计过程控制来减少可变性和增加这些过程的效

2、率。质量控制能保证组织的 质量以实现。 1.3 测试的定义1.3 测试的定义 在的经典著作软件测试技巧中，给出了测试的定义：“程序测试是为了 发现错误而执行程序的过程”。 1.4 什么才是1.4 什么才是 判定在测试中发现的问题是否属于，界定如下：功能不正常功能不正常、难以使用难以使用、未 做良好规划 未 做良好规划、功能不足功能不足、与使用者互动不良与使用者互动不良、性能太差性能太差、未做好错误处理未做好错误处理、边界 错误 边界 错误、计算错误计算错误、使用一段时间所产生的错误使用一段时间所产生的错误，控制流程的错误控制流程的错误、在压力之下所 产生的错误 在压力之下所 产生的错误、 不同

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

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

5、问题与功能不正常是不一样的。这里所指的是软件所提供的功能在动作 上是正常的，可是对使用者而言却是不完整的。即使软件的功能运作结果符合设 计规格的要求，系统测试人员在测试结果的判断上，也一定要从使用者的角度进 行思考。这里举一个例子，假设所测试的软件提供了数据处理功能，但是采用的 是封闭式的数据库。对开发人员来说，采用的数据库对程序编写来说比较容易， 经过测试之后也未发生其他的问题。可是在客户的环境下进行测试之后才发现， 客户要求提供支持数据库的功能，因为他们希望能够统一管理所有的资料。在这 种情况下，系统测试工程师必须将这个问题呈现出来，虽然现在要求增加这个需 求已经太晚了，不过可以建议提供另

6、一种解决方法，例如提供一个资料转换工具 或是提供资料导出的功能。 测试人员要随时对进行测试的功能保持一个存疑的态度，因为这样的问题如 果出现在开发的后期，所能提供的解决方式很有限，所以早一点发现这样的问题 对提高整个开发质量的帮助很大。通常这样的问题大都是由经验丰富的测试工程 师发现的。 1.4.5与使用者的互动1.4.5与使用者的互动 一个好的软件必须与使用者之间正常互动。 在使用者操作使用软件的过程中， 软件必须很好地响应使用者。这个问题常常有网络中浏览网页时出现。假设目前 使用者正在某一个网页填写资料，但是所填写的资料不足或是有误。当使用者单 击了“确定”按钮之后，网页响应使用者所填写的

7、资料有错，可是并未指明错误 在哪里，使用者只好回到上一页后重新填写一次，或是直接放弃离开网站。 这个问题就是软件对使用互动并 I 未做完整的设计，对于属于窗口程序类型 的软件，这一点也常常被忽略，例如当使用者做任何更新或删除动作的前后，程 序是否提供相应的信息给使用者？或对所执行的动作做确认？如提供确认窗口。 与使用者的互动原则就是所有的动作必须伴随着适当的响应（a）。 1.4.6使用性能太差1.4.6使用性能太差 所测试的软件功能正常但是使用性能太差了， 这样算不算问题呢？这个问题， 也经常有测试人员问。使用性能不佳，当然是一个问题，而问题通常是由于开发 人员采用了错误的解决方案，或是运用了

8、不适用的算法所导致的。例如有一个软 件属于的企业软件，端会将传递上来的资料做好分类处理。由于资料所包含的种 类相当多，于是开发人员将它分别存入不同的资料文件内，例如 A 送给的资料种 类有 A110，而就分别将资料存到 10 个不同的资料文件内。这样做的结果是造成 使用者在做资料查询时速度出奇地慢，因为会逐一搜寻 10 个不同的资料文件内 容来做对比。 类似的例子相当多，寻根究底是因为未做好基础审核（）及设计审核（）， 可是却大都是在进行系统测试或性能测试时才显示出问题的严重性。当然，在有 些情况下，项目经理或开发人员会反驳说如此的使用性能是在合理的范围内。建 议测试人员将竞争对手或同类型的软

9、件拿来做一个性能测试，这个测试的结果最 好以数字或百分比的形式返回给产品及开发人员。这样的方式所达到的效果远比 互相争吵来得有效得多。 1.4.7未做好错误处理1.4.7未做好错误处理 软件除了避免出错之外，还要做好错误处理。许多软件之所以会产生错误， 是因为程序本身不知道如何处理所遇到的错误。譬如说，所测试的程序可以读取 外部的资料文件并且做一些分类整理，可是刚好所读取的外部资料文件的内容是 被损毁的。当程序读取这个损毁的资料文件时，程序就发生问题，这时候操作系 统不知如何处理这个状况，为了保护自己只好中断程序。由此可见这个程序并未 做好错误处理。除了做好错误处理之外，同时也要设立防止错误发

10、生的机制。如 上述所说的， 程序在读取外部资料文件之前， 应该先检查外部资料文件是否毁损， 这样的方法才比较保险。 当然，除了做好错误处理之外，产品是否提供适当的调试机制，也是测试人 员应该注意的。复杂的软件如果未提供调试文档或调试方法，在以后的维护过程 中将会吃尽苦头。建议在进行软件设计规格阶段时，最好将调试机制包含在内， 这对以后的开发过程与维护过程绝对有很大的帮助。 1.4.8边界错误1.4.8边界错误 缓冲区溢出的问题（），这几年来成为相当热门的网络攻击方式，而这个错 误就属于边界错误的一种。简单地说，程序本身无法处理超过边界资料所导致的 错误。这个问题有许多情形是开发人员在声明变量或

11、是使用资料的长度时不小心 引起的。 1.4.9计算错误1.4.9计算错误 只要是软件程序就免不了包括数学计算。软件之所以会出现计算错误，大部 分出错的原因在于采用了错误的数学运算或未将计数器归 0。 1.4.10 使用一段时间所产生的错误1.4.10 使用一段时间所产生的错误 这个问题就是程序刚开始运行时很正常， 但在运行了一段时间后却出现问题。 最典型的例子就是数据库的搜寻功能。有一些软件在刚开始使用时，所提供的资 料搜寻功能运作良好，可是在使用了一段时间后却发现，进行资料搜寻所需的时 间却越来越长了。结果发现，所采用的资料搜寻方式是从第一笔搜查到最后一笔 的方法。类似这样的问题可以解决和避

12、免。 例子：有一个软件提供组件更新的功能，程序会通过因特网对比下载最新的 组件，之后程序会以新的组件取代旧的组件。这个更新程序做第一次更新动作的 时候是正确运作，可是如果再做第二次更新动作就毫无作用了，其原因很简单， 开发人员忘了将状态标志恢复到原来的状态，所以程序无法再进行第二次的更新 动作。 1.4.11 控制流程的错误1.4.11 控制流程的错误 控制流程的好与坏，考验着开发人员对软件开发的态度及设计的程序是否严 谨。软件在状态间的转变是否合理，要依据流程进行控制。相信许多测试人员在 使用软件时，有时候会有这种感觉为什么会跳到这一步？或是好像少了一个步 骤等类似的问题，这就是所谓的控制流

13、程错误。 用软件安装程序解释这样的问题是最容易的。 譬如使用者在进行软件安装时， 在输入用户名及一些其他资料后，软件就直接进行安装了，问题就出在安装程序 并未为使用者提供可以选择安装目的地的状态。这就是软件控制流程不完整的错 误问题。 1.4.12 在压力之下所产生的错误1.4.12 在压力之下所产生的错误 程序在处于压力状态下如果运作不正常的话，就是属于这种软件的错误。压 力测试对于级的软件是必须要进行的一项测试，因为级的软件对稳定度的要求远 比其他的软件高。通常一连串的压力测试是必须配合着测试软件来实施的，例如 让程序处理超过 10 万笔的资料，然后再来观察程序运行的结果。要准备 10 万

14、笔 的资料就必须借助于测试软件。 1.4.13 不同硬设备所导致的错误1.4.13 不同硬设备所导致的错误 顾名思义就是问题的产生与硬件设备不同有关。如果所开发的软件与硬件设 备有直接的关系，这样的问题就会相当多，例如光盘刻录机的软件就存在不少这 样的问题。 例如：所开发的软件在特殊品牌的服务器上运行约七八分钟就会停摆。 1.4.14 版本控制不良所产生的错误1.4.14 版本控制不良所产生的错误 出现这样的问题属于项目管理的疏忽，当然测试人员未善尽职守也是原因之一。 在最近的例子中有一个错得很冤，情形是这家公司一年前所出版的一个软件被反 应有安全上的漏洞，后来这家公司也很快将这个问题的修正版

15、提供给客户下载。 理论上这个事件就应该平息了，但是在一年后他们在推出新版本时，却忘记将这 个已解决掉的问题加入新版本内。所以对旧客户来说，原本的问题已经解决了， 可是想不到将版本升级后，旧问题又出现了。 1.4.15 文件错误1.4.15 文件错误 最后这个错误是文件错误。这里所提及的错误除了软件所附带的使用手册、 说明文档、，以及其他相关的文件内容除了降低质量之外，最主要的问题是会误 导作用者。很多客户投诉，不满使用手册所提供的资料与实际不符合。 第2章第2章质量控制部门的组成质量控制部门的组成 2.1 部门的定位2.1 部门的定位 质量控制部门不仅仅是一个测试部门，与单纯的测试部门有着重要

16、的区别： 测试针对一个项目，包含详细的技术工作，它是项目组的一个核心角色。质量控 制是公司的一个职能部门，它在一个负责企业质量和标准实施和监督的人领导下 工作。质量控制也负责在不同的项目组之间共享最好的实践经验。 2.2 部门成员的角色及职责2.2 部门成员的角色及职责 质量控制部门的角色分为七种：质量控制经理、质量监督员、测试协调员、 测试执行员、用户培训员、系统实施员、过程研究员。 2.2.1质量控制经理2.2.1质量控制经理 质量控制经理的职责是： 协调部门各角色的工作，并对最终发布的产品、产品的文档及整个开发过程 进行评审。 2.2.2质量监督员2.2.2质量监督员 质量监督员的职责是： 参与项目组，具有使项目组成员充分了解各项标准和规范的责任； 协助并监督项目组在开发过程中执行相关标准和规范； 协助质量控制经理对开发过程进行评审； 可根据执行情况对各项标准和规范提出改善建议。 2.2.3测试协调员2.2.3测试协调员 测试协调员的职责是： 针对某个产品或某个项目制定测试计划和测试方法，确定测试工期； 根据各测试执行员提交的测试结果，完成项目或产品的测试总结报告。 一