质量控制部门职责及分工

上传人:re****.1 文档编号:431950435 上传时间:2023-09-18 格式:DOCX 页数:20 大小:172.25KB
返回 下载 相关 举报
质量控制部门职责及分工_第1页
第1页 / 共20页
质量控制部门职责及分工_第2页
第2页 / 共20页
质量控制部门职责及分工_第3页
第3页 / 共20页
质量控制部门职责及分工_第4页
第4页 / 共20页
质量控制部门职责及分工_第5页
第5页 / 共20页
点击查看更多>>
资源描述

《质量控制部门职责及分工》由会员分享,可在线阅读,更多相关《质量控制部门职责及分工(20页珍藏版)》请在金锄头文库上搜索。

1、编号:时间:2021年x月x日书山有路勤为径,学海无涯苦作舟页码:第1页 共1页目 录第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第1章 定义1.1 质量的定义质量的静态定义:产品或服务能满足规定或潜在需求的特性和特征的集合。质量的动态定义:是一个持续改进的过程,在这个过程中取得

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

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

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

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

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

10、放弃离开网站。这个问题就是软件对使用互动并I未做完整的设计,对于属于窗口程序类型的软件,这一点也常常被忽略,例如当使用者做任何更新或删除动作的前后,程序是否提供相应的信息给使用者?或对所执行的动作做确认?如提供确认窗口。与使用者的互动原则就是所有的动作必须伴随着适当的响应(Every action come with a reaction)。1.4.6 使用性能太差所测试的软件功能正常但是使用性能太差了,这样算不算问题呢?这个问题,也经常有测试人员问。使用性能不佳,当然是一个问题,而问题通常是由于开发人员采用了错误的解决方案,或是运用了不适用的算法所导致的。例如有一个软件属于C/S的企业软件,

11、Server端会将Client传递上来的资料做好分类处理。由于资料所包含的种类相当多,于是开发人员将它分别存入不同的资料文件内,例如Client A送给Server的资料种类有A1-A10,而Server就分别将资料存到10个不同的资料文件内。这样做的结果是造成使用者在做资料查询时速度出奇地慢,因为Server会逐一搜寻10个不同的资料文件内容来做对比。类似的例子相当多,寻根究底是因为未做好基础审核(Architecture Review)及设计审核(Design Review),可是却大都是在进行系统测试或性能测试时才显示出问题的严重性。当然,在有些情况下,项目经理或开发人员会反驳说如此的使

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

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

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

15、的组件,之后程序会以新的组件取代旧的组件。这个更新程序做第一次更新动作的时候是正确运作,可是如果再做第二次更新动作就毫无作用了,其原因很简单,开发人员忘了将状态标志恢复到原来的状态,所以程序无法再进行第二次的更新动作。1.4.11 控制流程的错误控制流程的好与坏,考验着开发人员对软件开发的态度及设计的程序是否严谨。软件在状态间的转变是否合理,要依据流程进行控制。相信许多测试人员在使用软件时,有时候会有这种感觉为什么会跳到这一步?或是好像少了一个步骤等类似的问题,这就是所谓的控制流程错误。用软件安装程序解释这样的问题是最容易的。譬如使用者在进行软件安装时,在输入用户名及一些其他资料后,软件就直接进行安装了,问题就出在安装程序并未为使用者提供可以

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 建筑/环境 > 施工组织

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号