4软件质量保证--测试管理

《4软件质量保证--测试管理》由会员分享，可在线阅读，更多相关《4软件质量保证--测试管理（5页珍藏版）》请在金锄头文库上搜索。

1、一一信息系统协会中国分会第一届学术年会二- 二_ 二I 一软件质量保证测试管理木何玉洁，牛蓓，金颖，方美琪( 中国人民大学经济科学实验室，北京1 0 0 8 7 2 )文摘：在信息系统项目的开发中，软件工程逐渐成为热门话题，软件开发过程向规范化发展，软件的质量越来越成为人们关注的焦点，。软件质量保证”的概念正是在此环境下诞生的。本文主要针对软件质量保证体系中最重要的组成部分软件测试进行分析，通过总结目前流行的测试方法，从如何提高软件质量的角度出发，归纳了软件测试的分类，描述了如何规范软件测试流程，如何提交高质量的错误报告，如何管理提交的错误状态，如何评定测试人员的绩效，从而得出了一套软件测试管

2、理规范。关键词：软件工程；软件质量保证；软件测试；测试用例；软件缺陷1 软件质量保证1 1 软件质量管理 质量是产品或服务的生命线，正如商品有质量 控制，建筑有质量监理，软件的开发也有“质量” 的概念。在信息系统建设发展最初期，质量的问题 并没有得到足够的重视，直到2 0 世纪6 0 年代的“软件危机”爆发后，软件质量、效率、成本等问题暴露出来，信息系统开发者终于意识到软件质量控制 的重要性，把对软件质量的管理引入到软件开发的流程中。全面质量管理( T o t a lQ u a r r yM a n a g e m e n t ) 的 概念来源于2 0 世纪6 0 年代的美国，其含义是指为提供

3、使用户的满意的产品，组织各部门全员参与， 对影响产品质量的全过程进行系统控制的质量管 理形式。对于软件产品，为了生产出能够满足用户需求的高质量的软件，也同样需要对软件开发的全过程进行有效控制，实行“全面质量管理”。 评价软件的质量要看它是否符合软件设计要求，是否能够按照预期的时间和成本提交给用户，并能够按照预期要求正确工作。按照软件工程的思 想，软件开发可以分为需求分析、规格定义、设计、编码、测试、实施和维护这几个阶段。在软件开发 过程中推行规范化的开发流程，制定程序的标准规 范，这些既有利于程序的修改，也有利于程序员之间的交流，为今后的错误带来方便；在软件开发过程中应用知识管理工具，可以提高

4、项目团队成员的 知识，通过知识共享来增进软件开发的效率，也是确保软件质量的一个有效手段。如使用版本管理软 件对源代码进行管理，确保所开发源代码的“安叶乍者简介t 何玉洁( 1 9 8 1 ) 。女( 汉) 天津 U g W , K 人：方美琪。教授，B m m ：珊j 细喀 删M k h u 峨船全”，常见的版本管理软件有V i s u a lS o u r c eS a f e ，C V S ，S t a rT e r m ，S u b v e r s i o n 等等。1 2 软件质量保证与软件测试 尽管通过各种方法能够在开发过程中规范化 软件开发流程，使用各种辅助开发工具可以控制、 提高

5、软件质量，软件的错误仍然是不可避免的。要确保软件产品达到用户满意的水平，软件测试是必 不可少的一项工作，它是软件质量保证过程体系中的重要组成环节，是软件质量保证的重要手段。S Q A ( S o f t w a r eQ u a l i t yA s s u r a n c e ) ，即软件质 量保证，它是为了确保软件开发过程和结果符合预 期的要求，而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果的评价。进行S Q A 工作的人，一般被称为Q A 。Q A 并不等同于T e s t e r ( 测试人员) ，Q A 的工作不仅仅是测试，Q A 要对整 个软件开发生命周期进行管理，

6、着眼于全过程的质量控制。Q A 所需要掌握的软件技能远多于测试人 员。评价软件的质量是看软件是否符合定义的功能 和需求的程度，以及能否按照预期的时间和成本提 交给用户，并能够按照预期要求正确工作。2 软件测试近些年来，软件测试作为软件开发中的一个重 要环节，越来越受到重视。软件开发往往要历经几个版本，在每个版本的生命周期中软件测试都是必 须要进行的任务。软件测试是需要测试人员与开发人员共同完成的一项工作，测试工程师越早介入项 目、熟悉项目越有利于软件测试工作的顺利进行。 2 1 软件测试分类按照不同的分类方法，软件测试划分为不同的信息系统协会中国分会第一届学术年会种类。( 1 ) 按测试范围分

7、可以分为单元测试，功能测 试，集成测试和系统测试。单元测试通常是由程序 员完成程序编写后自己进行的。目的在于测试单个最小运行模块是否可正常运行，对程序接口、数据 结构、边界等进行测试。功能测试是为了保证单个 功能的完整性与正确性而进行的测试。而集成测试 是当各个模块根据设计说明书集成为一个整体时进行的。集成测试可以由程序员进行，也可以由专门的测试人员进行。软件只是计算机系统中的一个 组成部分，在全部开发完成后还要，结合计算机硬件，外围设备等系统环境进行全方厩的测试，即系统测试。( 2 ) 按对测试人员对代码的熟悉程度可以分为 自盒测试，黑盒测试，和灰盒测试。白盒测试又叫结构测试或逻辑驱动测试，

8、是已知软件产品的内部 工作过程而进行的测试，这种测试方法要求测试 人员必须对代码非常熟悉。通常单元测试阶段由程 序开发人员采用白盒测试的方法进行。黑盒测试又叫功能测试或数据驱动测试，它是 在完全不考虑程序内部结构和内部特性的情况下， 检查程序是否能按照输入而产生正确的输出。这种 测试方式下，测试人员需要对于需求非常熟悉，了 解各种输入相对应的输出情况。在集成测试阶段和系统测试阶段，通常采用黑盒测试的方法。 灰盒测试介于白盒测试与黑盒测试二者之间，既关注输出对于输入的正确性，同时也关注内部表现。 ( 3 ) 按测试方法来分软件测试可以分为人工测 试和自动测试。从名称上可以显而易见，人工测试 是指

9、不依靠测试工具丽直接由人进行的测试，这种 测试方法往往可以发现自动测试中无法发现的错 误。使用自动测试工具可以进行压力测试等无法手 工完成的测试方式，对软件的整体性能进行分析，提高测试效率。 ( 4 ) 按照软件测试的阶段，可以把测试分为P r e A l p h a 测试，A l p h a 测试，P r e B e t a 测试以及B e t a测试。A l p h at e s t i n g 他测试) 是指由一个用户在开发 环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。B e t at e s t i n g ( 1 B 测试) 是软件的多个用户在一个或多个用

10、户的实际使用环境下进行的测试。 2 2 软件测试管理软件测试中发现的错误被称为b u g ，即软件中的 “臭虫”，有时称作d e f e c t ( 缺陷) 或e r r o r ( 错误) ， 软件测试人员的工作正是要如同除虫一样把软件中的错误挑出来。软件错误的范围既包括软件编程错 误带来无法运行的出错情况，也包括软件功能与软件设计文档不符的情况，还包括软件的性能效率、 易用性等问题，总而言之，从客户的角度出发，一切与软件功能不符，不满足用户需求的情况都可以称之为b u g 。 2 2 1 测试流程 正如同软件开发有其生命周期，在各个版本的 软件生命周期中的软件测试活动也有其完整的生命周期。

11、 ( 1 ) 确定测试范围，明确测试需求。软件测试人员得到测试任务后，首先要了解项 目，可以通过阅读项目文档，试用软件，开发人员讲解等方式达到对需要测试软件功能、特性的全面 了解。应该明确的是，软件测试人员也需要有一定的技术背景，具有技术背景的测试人员更容易熟悉 项目，更容易与开发人员沟通，也更容易发现软件中的错误。而随着对测试自动化要求的提高，软件 测试人员的技术要求实际上是和开发人员相同的。 ( 2 ) 编写测试用例。 测试人员在熟悉了项目之后就需要为测试编 写测试用例( t e s tc a s e ) ，一个完整的测试用例应该包括：( a ) 测试环境，指为进行此用例测试需要配置的软、

12、硬件环境； ( b ) 测试目的，对该用例想要测试的内容进行 描述( c ) 测试步骤，详细设计测试步骤，作为实际测试时的依据。应该注意的是，在实际测试中，进行测试的人员常常并不是测试用例的作者，因此， 为了让测试用例能够被更好地理解，测试步骤必须要清晰地描述出来。( d ) 期待结果，即执行测试步骤后应得到的输 出值。期待结果正是测试人员判断执行此测试用例是否成功的评判标准。 对于测试人员来说，测试用例( t e s tc a s e ) 的编 写，就如同程序员编写代码一样。每个测试人员会写出不同的测试用例。测试的质量需要测试团队和 开发团队共同保证。测试用例的测试范围是根据待 测试版本的软

13、件设计说明书来限定。为了编写高效 准确的测试用例，编写用例人员的经验也是非常重要的。 ( 3 ) 测试及错误提交。测试用例经过确认后， 就可以进行测试了。在测试中，如果发现错误，就需要提交错误报告并标记此测试用例测试失败。否 则标记该用例测试通过。( 4 ) 错误跟踪确认。该版本软件阳例测试完成 后，测试人员还要对本版本中已经修正的上一版本的错误进行确认，确保上一版本中所提交的更改需求已经正确修改。信息系统协会中国分会第一届学术年会 _ _ - _ _ - - - _ - - _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ - - - - _ 一一一 2 2 2 规范错

14、误报告测试人员在发现软件中的错误后。错误的提交 可以通过规范的软件进行，以提高错误的提交效 率。各个开发团队可能使用不同的错误提交软件或工具来进行，而规范的测试报告便于开发人员重现 报告的错误，分析错误原因，以更容易地定位软件中的错误所在。因而，报告软件测试错误的基本要 求是准确、简洁、完整、规范。测试人员必须明确 指明错误发生时的环境，操作，即向开发人员详细交待重现错误的步骤，指明错误发生的位置。为使 开发人员更加清晰迅速的认识错误，在提交错误报 告时可以附加错误发生时的截图来帮助开发人员更加形式化的了解错误。总体来说，衡量有效的错误报告可以从以下四方面进行： ( 1 ) 认清报告的对象。在

15、错误报告提交到软件开发团队后，阅读错误报告的人有两种，决定该错 误是否需要修改，以及实际修改错误的开发人员。 测试人员在书写错误报告时应该从开发者的角度 来看，什么样的错误需要修改? 错误应该定义成什么级别?( 2 ) 标题简洁明了。错误在提交后，开发团队 一般会举办错误讨论会之类的活动来决定所提交错误的解决办法，而提交的错误报告标题可以让阅读者迅速掌握报告内容，判断错误的严重程度。 ( 3 ) 步骤清晰。清晰明了，不带冗余的操作步 骤可以帮助处理错误者以及将来进行错误修改确认的测试人员。 ( 4 ) 明确错误影响。为了帮助开发团队确定错 误的级别，测试人员在提交错误报告时应尽量明确错误的影响

16、范围。2 2 3 不可重现错误处理 在测试的过程中经常会发现一些不可重现的错误，即当测试人员发现后，此错误却再也不出现 的情况。对于这些不可重现的错误是否要置之不理 呢? 显然，置之不理不是一个好的错误处理方法， 这样的结果是给软件的质量带来了隐患，一旦在用户那里再次出现b u g ，不仅为开发团队带来很坏的 影响，同时也提高了b u g 修复的成本。因为正如我 们所知道的，错误越早，其修改成本越低，解决的代价越小。对于发现不可重新的b u g ，测试人员首先应该 尽量去重现错误，如果实在无法重现，也要发送错 误报告。因为程序员对程序比测试人员熟悉的多，提交错误后，程序员很可能可以找到错误的原因，即使无法重现，程序员也会了解问题所在。另外， 这种错误也许是由于测试中的操作错误造成的，既然测试人员犯错误，用户也可能会犯同样的错误，可能在软件的容错程序编写上存在问题，同时，不可重现的错误有可