思步网

标题: 软件质量保证过程 [打印本页]

作者: Scott 时间: 2008-4-13 19:45
标题: 软件质量保证过程
1、前言
1.1 范围
本文对软件质量保证活动中涉及到的人员提供指导，使得软件开发中不同的角色清楚自己在什么时间做什么事情。

1.2 目的
本文的目的是描述软件质量保证的所有活动。文档中涉及到的角色均以粗体表示，以便各角色更明确自己的工作。本文档可以帮助我们规范化公司的软件质量保证过程。

1.3 文档概述
第一部分：描述本文档的范围和目的，以及SQA过程涉及到的角色。
第二部分：培训。
第三部分：详细描述质量保证过程的活动。
第四部分：附录。
1.4 有关的角色及职责
      角色                   职责描述
项目设计师                组织和进行Quality review
开发人员                   单元测试，alpha 测试
测试负责人                制定测试计划，确保测试过程正常进行
测试人员                   Beta测试，性能测试

2、培训
对相关人员进行软件质量保证过程的培训，培训包括两部分：
1、软件质量保证过程。
2、过程用到的工具，包括Bugzilla, Junit, Jmeter，Webtest等

3、软件质量保证活动
软件质量保证是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。软件的质量保证活动和一般的质量保证活动一样，是确保软件产品从诞生到消亡为止的所有阶段的质量的活动，即是为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。
质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。这种观点也适用于软件的质量保证。

软件质量保证的主要手段是检验，检验有两种方式：
·Quality review，检查阶段产品是否与要求一致，防止软件差错到下个过程被放大。一般在各阶段的中途或向下一阶段移交时进行的检查。因为这时候还没有结果产品，所有的检查都是通过评审的形式实现的。（Verification）
·测试，检验开发出来的软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到，所有的文档都是正确的且便于使用。检查方式是由测试人员对产品结果进行正式全面的测试。（Validation）

另外，为了保证程序源代码的可维护性，公司有严格而合适的编码规范以约束程序员的编码习惯。其中借助工具Checkstyle来检查java程序的编码规范。

3.1 Quality review
3.1.1 Quality review 概述
目的：确保开发的过程结果的质量。
时间：每个主要阶段上至少要进行一次Quality Reviews。可以根据工作和进程的需要安排Quality Reviews。它可以持续几天时间。
形式：会议形式。由项目主管或设计师来发起和主持，一般要求项目主管或设计师提前将会议邀请发给需要参加会议的人。必要时需要将会议的内容大体介绍给大家，以便他们做好准备。
参加人：团队中与本技术有关的所有人员和邀请的项目组之外的其他人员。该类会议一般会邀请有关领域的专家。
活动：
·讨论被审核对象的有关问题
·深入地审核系统的体系架构和所使用的技术
·确认技术过程（Build/Release，源码控制，等）

会议记录：由设计师或指定他人在当天将会议的内容整理出来并置于配置管理之下。

原则：
　　·某阶段未通过阶段评审不得进入下一个软件研制阶段；
　　·评审时对事不对人，评审的是产品，而不是评审生产者；
　　·评审就要挑刺，找问题、缺陷和隐患；
　　·评审组的人员面越广越好；
　　·评审组不作无休止的争论和辩驳，将争论点记录下来，供以后甄别；
　　·评审只是提出问题，没有解决问题的任务；
作用：
　　·技术把关，避免软件人员的想当然；
　　·概念沟通，吸收用户和总体人员参加，审查软件人员理解的正确性；
　　·集思广益，吸收有关的分系统人员参加，从不同侧面确认软件的协调性；
　　·总结汇报，使实时控制系统总指挥。设计师了解软件的进度、问题和要求，作出新的部署。

3.1.2 Checklist
为了确保Quality review的质量，需要列出软件开发不同阶段上的Review内容。利用这个Checklist，设计师根据项目的具体内容安排合适的Quality review。
公司给出了一个可参考的checklist，可以用来指导Quality review，也可以用来跟踪Quality review的执行。

3.1.3 通过准则
软件质量保证工作是开发团队整体的工作，只有每个人都将自己角色所涉及的工作质量把握好，才能保证项目整体的质量。这里将针对开发过程给出每个阶段的退出标准。即，只有达到了某个要求才可进入下个阶段。项目主管和设计师以此来推进项目的进度。

2.1.4 Review notes
为了更有效地开展Quality review工作，公司给出了一个可参考的review notes。利用这个表格，设计师可以更好地把握会议的重点。

3.2 测试
在分析、设计等各个开发阶段结束之前，对软件进行了严格的Quality review，但由于人们能力的局限性，审查不能发现所有的错误，而且在编码阶段还会引进大量的错误。软件测试就是在软件投入运行之前，对需求分析、设计规格说明书和编码的最终复审，是软件质量保证的关键步骤，是为了发现错误而执行程序的过程。

测试不仅仅是运行程序，然后将发现的问题记录下来的过程。他的真正目的是想以最少的时间和人力找出软件中潜在的各种错误和缺陷。

软件测试在软件生存期中横跨两个阶段：通常在编写出一个模块之后就对它做必要的测试（称为单元测试），编码和单元测试属于软件生存期中的同一个阶段。在结束这个阶段之后，对软件系统还要进行各种综合测试，这是软件生存期中的另一个独立的阶段，即测试阶段。它主要包括功能测试、性能测试、用户接受性测试。从测试方法上来讲，单元测试属于白盒测试；测试阶段的测试属于黑盒测试。

对功能测试，又分为alpha测试阶段和beta测试阶段。Alpha测试由开发人员来做，Beta测试由专门的测试人员来做。

测试阶段的测试，是在模拟的环境（可能就是开发环境）下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。

由测试负责人负责制定测试计划，确保测试过程正常进行。

3.2.1 单元测试
定义
单元测试集中检验软件设计的最小单元----模块。测试之前必须先通过编译程序检查并改正所有语法错误，然后用详细设计描述做指南，对重要的执行通路进行测试，以便发现模块内部的错误。

单元测试要求开发人员来编写测试用例并执行测试。

测试内容
针对一个模块进行五方面的检查：

·模块接口测试。这方面的错误如，调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；输出给标准函数的参数在个数、属性、顺序上是否正确；全局变量的定义在个模块中是否一致，等。
·局部数据结构测试。这方面的错误如，不正确或不一致的数据类型说明；使用尚未初始化的变量；错误的初始值或错误的缺省值；变量名拼写错或书写错，等。
·路径测试。这方面的错误如，不正确的逻辑运算符；关系表达式中不正确的变量和比较符；错误的或不可能的循环终止条件，等。
·错误处理测试。这方面的错误如，出错的描述难以理解；出错的描述不足以对错误定位，不足以确定错误的原因；显示的错误与实际的错误不符，等。
·边界测试。数据流、控制流中刚好等于、大于或小于确定的比较值时出现的错误。
测试方法
通常有两种测试方法：
·单元静态检查，不要求实际执行所测程序，而是以一些人工的模拟技术和一些类似动态分析所使用的方法对程序进行分析和测试。
·单元动态测试，通过执行程序来测试有没有问题。

测试工具
使用Junit工具来帮助实施单元测试，也包括Junit工具的扩展Cactus等。

作者: Scott 时间: 2008-4-13 19:46
bigtree

有两个问题
1、这儿的“alpha测试阶段”和“beta测试阶段”是不是对应软件质量保证过程（二）中的“集成测试”和“功能测试”
2、“代码检查”又放在了哪儿呢？

作者: Scott 时间: 2008-4-13 19:46
steplv

楼上的这位朋友，alpha测试和beta测试的具体概念你可能理解的跟文章中的有些出入，这个要结合＂软件质量保证过程（二）＂一起来看．

作者: Scott 时间: 2008-4-13 19:51
3．2．2 集成测试
定义
集成测试是为了确保测试用例能够正常运行而由开发人员来执行的测试

测试内容
测试软件或系统的全部流程、用例是否可以正常运行。

测试方法
首先需要制定测试计划，规定要做测试的范围，要求，方法等。还需要制定一组测试步骤，描述具体的测试用例，用例应该可以遍历到全部的流程。

3.2.3功能测试
定义
为了保证软件能满足功能要求而做的测试。功能测试是由专门的测试人员对系统进行的有组织的详细全面的测试。

测试内容
软件的所有功能。

针对公司Java开发Web测试的特点，需要额外注意以下几方面的测试：
·操作系统+ 浏览器兼容性测试：在不同操作系统 (win,mac,unix)和不同版本的浏览器（IE4.0,IE5.0,IE5.5,NN6,NN4.5）组合情况下web应用能否正确执行；
·可用性测试：主要从使用的合理性和方便性等角度对软件进行检查，是专为“对用户友好”的特性进行测试；
·超链接检查：检查是否页面上所有的连接都正确链接，是否存在broken links；
·图形显示检查：检查是否所有的图片都被正确装载，在不同的浏览器、分辨率下图片能否正确显示（包括位置、大小）；
·分辨率检查：在不同分辨率设置情况下，窗口的滚动条能够正确滚动，屏幕刷新是否正确；
·调整窗口检查：在调整浏览器窗口大小时，屏幕刷新是否正确；
·外部网络访问检查：从外部网络拨号访问web应用以验证连接、功能和性能；

测试方法
首先需要制定测试计划，规定要做测试的范围，要求，方法等。还需要制定一组测试步骤，描述具体的测试用例，旨在说明软件与需求是否一致。

测试方案
测试方案包括预定要测试的功能，应该输入的测试数据和预期的结果。设计测试方案的目标是，确定一组最可能发现某个错误或某类错误的测试数据。

几种主要的黑盒测试的设计技术有：
·等价类划分。将所有可能的输入数据，即程序的输入域划分为若干部分，然后从每一部分中选取少数。不光考虑输入等价类，有时还需要考虑输出等价类。
·边界值分析。对等价类划分的补充，不是从等价类中随便选一个数据作为代表，而是选几个特定值，如等于、刚刚大于、刚刚小于边界值。
·其他方法。

回归测试
当软件经过测试发现错误，程序员对一个错误的修改可能会引起另外的错误出现，所以，在修改之后还要进行测试，这种测试就叫回归测试。

在整个产品提交之前要进行正式的回归测试，有必要给出回归测试的要求：
·每次测试需要将所有的功能都走一遍；
·对不同状态的bugs要求check一遍，重新定他们的状态，特别关注状态改变的bugs。
·check Bugs时，注意走一下与此Bug 有关联的功能，以及与此Bug相类似的功能。

为了更快更有效地进行回归测试，借助自动测试工具Webtest来完成部分的回归测试工作。

3.2.4性能测试
定义
为了保证软件能满足性能要求而做的测试。本部分测试由专门的测试人员来设计和执行

测试内容
本着公司Web testing的特点，只提出下面三方面的测试：
·安全测试：安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。
·负载测试：通过模拟大批量用户的并发请求，给系统施加较大的负载，这时检测整个系统处理交易的能力。
·压力测试：在反常数量或资源（使用的容量达到规定的极限）的情况下执行应用程序，检测中间件系统在长时间、高负载情况下的运行处理能力，从而检验系统的稳定性。测试方法设计测试用例，模拟错误数据和软件界面可能发生的错误，测试各项性能是否达到预期的指标。

测试工具
使用Jmeter等工具来帮助测试系统的负载。

3.2.5 用户接受性测试（UAT）
定义
验收测试的目的是向未来的用户表明系统能够象预定要求那样工作。要求必须有用户积极参与，或者以用户为主进行，测试人员来协助。

测试内容
主要对功能要求、性能要求、和文档的完整性进行检查。这里强调下面几点：
1、主要使用生产中的实际数据进行测试
2、对用户特别感兴趣的功能，需要增加一些测试
3、需要按照用户的使用步骤设计一些用例
4、可能会忽略一些纯技术性的特性

测试方法
一般使用黑盒测试方法。

3.2.6 Bug管理
管理内容
Bug管理解决下面几个问题：
1、开发人员按照Bug的等级优先修复严重的问题
2、开发人员和测试人员之间的协作沟通方便有效
3、测试人员的Bug录入要方便有效
4、开发人员定位自己的Bug
5、 Bug的跟踪
6、 Bug的查询方便有效
7、方便准确地进行Bug统计

Bug等级（Severity）
This field describes the impact of a bug.
·Blocker - Blocks development and/or testing work.
·Critical - Crashes, loss of data, severe memory leak.
·Major - Major loss of function.
·Normal - This is the run of the mill bug.
·Minor - Minor loss of function, or other problem where an easy workaround is present.
·Trivial - Cosmetic problem like misspelled words or misaligned text.
·Enhancement - Request for enhancement.

Bug管理工具
借助Bugzilla来管理Bug。Bugzilla是一个Bug跟踪工具，主要功能包括报告Bug、查询Bug记录并产生报表、Bug统计、权限管理等。

3.3 编码规范
在多个开发人员共同写作的情况下，必需建立一个合适的编码规范。这不仅仅是为了开发效率来考虑，而且也是为了后期维护考虑。定义规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。

作者: Scott 时间: 2008-4-13 19:52
timlq

感觉文档里着重谈了软件质量保证在工程上的应用，对过程方面谈的比较少。

作者: Scott 时间: 2008-4-13 19:52
bigtree

的确，刚开始看的时候还以为是过程定义，仔细看了一下，和PPQA的过程定义不一样。
如果要想直接在工程上应用的话，还要进一步细化才行，不过文档的总体思路还是不错

作者: Scott 时间: 2008-4-13 19:52
SG6681

是啊，这不是CMMI提到的PPQA概念吧，文章着重描述了测试的工作。

作者: ivan_d 时间: 2008-5-23 14:22
的确，刚开始看的时候还以为是过程定义，仔细看了一下，和PPQA的过程定义不一样。
如果要想直接在工程上应用的话，还要进一步细化才行，不过文档的总体思路还是不错

作者: shadowcetco 时间: 2008-5-28 10:19
好东西，好好学习啊:lol :lol :lol

作者: xiaopohai1801 时间: 2008-7-29 09:51
非常不错，学习学习中

作者: xiaopohai1801 时间: 2008-7-29 10:00
正在学习中，非常不错，慢慢理解

作者: 黑白琴键弹 时间: 2014-5-20 08:17
向楼主学习

作者: 萧风 时间: 2014-10-15 17:51
顶不错支持下

作者: 活雷疯！ 时间: 2014-12-30 09:12
前排支持下了哦~

作者: 黑的彻底╰ 时间: 2015-11-3 09:21
以我的经验来看，楼主的想法是可以执行的~

作者: 名侦探天天。 时间: 2015-11-7 11:17
好帖是需要鼓励的~

作者: 佳薪 时间: 2017-9-21 08:45
路过的帮顶

欢迎光临思步网 (http://www.step365.com/)