代码改变世界

软件质量控制

2017-02-21 20:20  zouhui  阅读(3704)  评论(0编辑  收藏  举报

1、质量控制

  软件质量控制对开发过程中的软件产品的质量特性进行连续的收集和反馈,通过质量管理配置管理等机制,使软件开发过程向着既定的质量目标发展。质量控制是质量管理的的路标和动力,质量管理是质量控制的执行机制。

  问题1:软件质量控制应该注意哪些方面?

  建议:

  (1)在整个软件生命周期中都该进行质量控制;

  (2)不同阶段活动不同,应采用不同的技术;

  (3)综合使用“预防性”和“检测性”技术。

  问题2:软件质量控制技术有哪些类型?

  建议:

  (1)预防性技术:通过为过程、产品和资源设立标准等途径,来避免在产品开发过程中产生缺陷;

  (2)检查性技术:用于发现和纠正缺陷,甚至分析产生缺陷的原因。

  问题3:软件质量控制一般有哪些方法?

  建议:

  (1)目标问题度量法:通过确定软件质量目标并连续监视这些目标是否达到来控制软件质量;

  (2)风险管理法:设别和控制软件开发过程中对软件质量危害最大的因素;

  (3)PDCA质量控制法:PDCA是一个基于统计方法的迭代过程,已被作为国际标准。

  问题4:软件质量控制的准则有哪些?

  建议:

  (1)制定明确的改进质量目标,满足客户需要;

  (2)持续改进过程以提高质量和生产率,降低成本;

  (3)消除恐惧,让员工更有效地工作

  (4)消除领域障碍,建立团队精神;

  (5)不以口号要求零缺陷、高效率;

  (6)进行培训,为所有人建立学习和自我提高机制。

  2、质量目标

  为了达到质量控制,测试团队不但需要明确软件的功能,还要明确软件应达到什么样的质量标准,即制定软件的质量目标。为了达到这些目标,在开发过程的各个阶段进行检查和评价。在质量评价时,需要有对质量进行度量的准则和方法,但更重要的是,需要在软件生存期中如何使用这些准则和方法的质量保证步骤及提高该项作业生产率的工具。

  问题1:制定合理的质量目标需要从哪些方面考虑?

  (1)适应性:必须制定能适应各种用户要求、软件类型和规模的质量标准,并能够度量;

  (2)易学性:不需要特殊技术,软件技术人员人人都容易掌握;

  (3)可靠性:对同一个软件的评价,评价的人或场合可能不同,但评价结果必须一致;

  (4)针对性:不是在检查时才改进质量,而必须从设计阶段起就确立质量目标,在各个阶段实施落实;

  (5)客观性:要从各种不同角度加以评价,并将评价结果定量地表示,使得人人都能理解;

  (6)经济性:考虑如何才能把质量度量和保证所需要的费用控制在适当的范围内。

  问题2:测试团队,需要重点关注哪些质量指标?

  建议:

  (1)测试设计覆盖率

  (2)测试执行覆盖率

  (3)各阶段缺陷密度

  问题3:测试过程中,需要关注哪些测试缺陷密度?

  建议:

  (1)测试计划评审缺陷发现密度

  (2)测试策略/方案评审缺陷发现密度

  (3)测试用例评审缺陷发现密度

  (4)系统测试缺陷发现密度

  (5)集成测试缺陷发现密度

  (6)验收测试缺陷密度

  3、同行评审

  在软件开发过程中邀请同行对工作产品进行审查,以图尽早查找出工作产品缺陷,进行质量控制的一种质量活动。需要前期准备、计划,安排好时间进度表,而且越早开展对项目越有价值。

  问题1:常见的评审有哪些形式?

  建议:

  (1)审查:由公正的、接受过正式评审技术培训的组织者引导进行的同行检查;

  (2)走查:又称走读,由产品的设计者或开发人员引导开发组成员和其它相关组成员浏览软件工作产品;

  (3)分发:又称轮查,产品的设计者或开发人员将要评审的工作产品共享或分发,评审人员以修订标记或批注的方式将意见直接添加到工作产品或其复件上。

  问题2:评审过程中常见的问题?

  建议:

  (1)项目进度紧张,开发人员没有时间进行评审;

  (2)评审力度不够,评审发现的有效问题太少;

  (3)评审会议中过多争论占用大量时间;

  (4)评审专家与作者,或者多位评审专家之间的评审意见不一致;

  (5)评审发现问题修改后,评审人员跟踪不充分。

 问题3:项目进度紧张,专家没有时间进行评审怎么办?

  建议:

  (1)将评审活动的时间、需要的评审专家写入项目计划;

  (2)通过“正式渠道”协调评审专家资源,并得到承诺;

  (3)评审开始前提前1-2天通知评审专家。

  问题4:如何可以提高测试评审的效果,达到预期的效果?

  建议:

  (1)评审前可以使用Checklist、代码检视工具等进行自检活动;

  (2)考虑知识结构、观点角度等方面,选择合理评审专家;

  (3)必要时安排介绍会议,向相关专家介绍被评审对象;

  (4)充分安排好足够预审时间。

  4、漏测预防

  漏测是指软件产品的缺陷在某一阶段未被发现而遗漏到了后续阶段、经效果评估后,将有效的预防措施纳入到流程或相关预防平台中,制定改进措施和跟进实施。

  问题1:哪些环节容易发生漏测?

  建议:

  (1)需求分析,如需求分析遗漏、需求分析特性理解错误、需求变更未及时跟踪;

  (2)策略漏测,如组网考虑不全面、继承特性考虑不全、性能稳定性考虑不全面;

  (3)设计漏测,如用例描述不规范准确、用例观察点遗漏、功能交互遗漏、异常考虑不全面等;

  (4)执行漏测,如用例执行构造数据不全面、没有严格按步骤执行用例、测试技能或经验不足等。

  问题2:漏测分析需要做哪些工作?

  建议:

  (1)选择问题,选择有代表性的漏测问题;

  (2)分析根因,进行漏测问题的根因分析;

 (3)改进实施,制定改进措施并跟进实施;

  (4)补充测试设计,共性问题要跟踪多版本闭环;

  (5)成果固化,经效果评估后,将有效的预防措施纳入到流程或相关预防平台中。

  问题3:有哪些方法,可以进行漏测预防?

  建议:

  (1)测试策略和测试方案充分考虑各业务逻辑之间的交互和影响;

  (2)测试用例设计时,充分考虑功能点与其他模块之间的交互和影响;

  (3)充分考虑修改问题单、需求变更是否引入新的问题;

  (4)参考优秀实践和经验案例;

  (5)每次缺陷分析完要有总结,把容易漏测的形成测试经验checklist,并组织学习。

  5、发散测试

  发散测试,顾名思义就是不以某个标准或者框框作为约束的一种测试,发散测试准确来说应该叫具备发散思维的探索性测试。为了提高测试执行覆盖率,在严格按照用例测试执行后,通常需要进行发散测试,这里包括自由测试和交叉测试。

  问题1:发散测试,需要关注哪些方面?

  建议:

  (1)重点模块和核心流程,需要安排多人进行交叉测试;

  (2)根据2/8原则,对发现缺陷高的模块,需要重点安排人力交叉测试;

  (3)了解用户场景,按照用户常常使用的实际场景进行发散测试;

  (4)识别异常场景,模拟可能发生的各种异常场景进行发散测试;

  (5)遵循规范原则,根据规范组织测试,如协议规范、设计规范和接口规范等。