摘 软件测试--晏宾

上一篇 / 下一篇  2011-04-14 18:51:14 / 个人分类:学习资料

第 1 章 软件测试简介
  作为该文档的开始,本章将对测试以及测试行业做一些简单的阐述,包括测试行业的前
景,测试人员的基本素质和注意事项等等。

                       第 1 节 测试行业简介
  软件测试在软件生命周期中占据重要的地位。 软件测试学在传统的瀑布模型中仅处于运
行维护阶段之前,是软件产品交付用户使用之前保证软件质量的重要手段。近来,软件工程
界趋向于认同一种新的观点,即认为软件生命周期每一阶段中都应包含测试,   从而检验本阶
段的成果是否接近预期的目标,尽可能早的发现错误并加以修正。   如果不在早期阶段进行测
试,错误的延时扩散常常会导致最后成品测试的巨大困难 。由于测试的重要性和复杂度,
它慢慢的独立发展成为一个行业,并且在迅猛发展。
  在典型的软件开发项目中,软件测试工作量往往占软件开发总工作量的 40%以上。而
在软件开发的总成本中,用在测试上的开销要占 30%到 50%。
?? 如何认识测试?
  测试正在迅速的发展;
  测试是一个方法论而不是一个技术;
  软件测试工程学或者质量工程学也应该诞生了,管理和技术并重。

                       第 2 节 软件测试的误区
?? 软件开发完成后进行软件测试。
?? 软件质量问题是测试人员的错误,软件发布后如果发现问题,那是软件测试人员的错。
?? 测试技术要求不高,比编程容易,随便找一个人就可以了。
   有编程经验对测试 BUG 的敏感性;需要编写自动化测试脚本的能力;除了技术还有管
理,谁都可以做,但是结果不一样。
?? 测试跟着开发动,有时间就多测,没时间就少测。
   必须有计划有组织。
?? 测试是测试人员的事,与开发人员无关。
   开发人员需要自测,还需要沟通协作。
?? 软件测试是没有前途的工作,只有程序员才是软件高手。
?? 测试是软件开发的后期活动;软件测试=程序测试。
   软件缺陷具有“生育能力”;需求测试和设计测试也是软件测试的一种;软件测试应该
涵盖整个软件生命周期;同时,软件测试本身也应被测试。
?? 测试要执行所有可能的输入。
   在实际测试中,穷举测试工作量太大,实践上行不通;一般采用等价类和边界值分析等
措施来进行实际的软件测试;   寻找最小最重要的用例集合成为我们精简测试复杂性的一条必
经之道。
?? 好的测试一定要使用很多的测试工具。
   工具所能发挥的作用依赖于使用工具的人。  因此,对工具的过分依赖将降低人的能动性 ,
                                                             版权所有??
Last saved by yanbin      ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                              Page 12   of   123
并最终使测试本身受到损害。适当的使用测试工具能够减轻测试人员的机械性工作,提高工
作效率,而滥用工具会降低测试的质量。并不是任何工作都适合自动化的,如何合理的自动
化测试,合理的选择适当的测试工具已经是研究人员感兴趣的一个课题。

                       第 3 节 测试工程师素质
1.3.1 基本素质
  概括的说,测试工程师需要重点培养:沟通能力、记忆力<挖掘以往错误>、怀疑精神、
洞察力<发现重点>、自信心、幽默感、耐心、自我督促等方面的素质。
?? 广泛的经验:有了工作经验的积累,会让工作变得更轻松、效果更好。
?? 交流技巧:表达能力、问题描述能力、会提问、会寻求正确的帮助。如果文字水平太粗
  糙,建议上一门创造性写作的课。
?? 逻辑思维能力:可以从容面对面对纷繁复杂的程序逻辑。
?? 团队协作能力: 测试工作不是一个组,一个人可以完成的。需要组内和组间的密切配合 。
?? 组织技能:处理日常事务的能力和处理突发事件的能力。 如果你在别人都头脑发昏的时
  侯保持清醒,你就可能是一个好的软件测试工程师。
?? 态度:需要理解和采取适当的态度去做软件测试。

1.3.2 专业素质
  软件测试工程师要掌握五大类的知识:技术、测试技巧/方法、测试计划、执行测试计
划、测试分析报告与改进。
  除了技术,还要求具有否定性的创造力;探测技巧;总体理解产品的能力;用客户的眼
光进行评估;怀疑的而不是敌意的态度;能经受得住坏消息而保持目标;拥抱新技术的热望
等特征。这些也都属于专业素质范畴。
  一般的说,技术上的问题都不是问题,目前的软件工程更需要行之有效的项目管理
?? 软件工程:必须了解软件工程(设计、开发和简单测试),应用,系统,自动测试编程,
  及操作系统数据库,网络系统和协议的设计和使用。
?? 系统需求:把握需求是第一位的。对产品熟悉,能够快速掌握新的产品需求, 很强的
  需求理解能力显得很重要;
?? 测试流程:明确测试流程中各个阶段的工作,对测试的认知程度,决定了测试流程管理
  的规范性,测试工作的质量;
?? 测试方案:测试方案的分析设计能力、测试案例的设计能力、测试案例的覆盖率、优先
  级、回归测试案例的选取等;
?? 测试工具的使用(包括测试管理和测试执行工具,也包括开发工具的能力);
?? 团队协作:与各个小组之间的沟通能力;
?? 测试管理:管理决定了工作质量。尤其是测试经理,需要管理团队测试的能力。
 

                                                             版权所有??
Last saved by yanbin      ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                              Page 13   of   123

                       第 4 节 测试工程师分类
  测试工程师一般分为两类:测试开发工程师和软件测试工程师。
??
  测试开发工程师:主要负责编写测试工具代码,并利用测试工具对软件进行测试;或者
开发测试工具为软件测试工程师服务。
  软件测试工程师:主要负责理解产品的功能要求,然后对其进行测试,检查软件有没有
错误,决定软件是否具有稳定性,并写出相应的测试规范和测试案例。
?? 按职位分类:测试部门经理、测试技术总监、测试主管、测试项目经理、测试设计人员 、
  测试开发人员、测试执行人员、测试协助员、技术支持;
?? 按测试类型分类:功能测试工程师、自动化测试工程师、性能测试工程师等;
?? 按测试对象分类:web 测试工程师、数据库测试工程师、C/S 测试工程师、个人软件测
  试工程师等。

                       第 5 节 测试工作的未来
    本节内容来源于网络
  测试工作未来预见
??
  更好的方法、对测试人员更好的培训、更好的工具将为软件产业带来变革。具体地说,
诸如可执行的说明书、基于模型的测试产生、BUG 预防、系统模拟等技术,将在这场演变
过程中扮演重要的角色。
?? BUG 预防和早期检测
  因为现在把重点放在产品交付的质量上来了(而不是在于找到了多少 BUG), 预防实践
和静态分析仪这样的检测工具将成为主流。
?? 仿真测试
  仿真工具变得很普遍,  使得仿造计算机环境变得容易起来。在开发过程的早期就可以进
行意外和错误流程的测试。代码稳定后,再用真实环境验证仿真是否准确无误。
?? 及时的测试用例
  庞大的测试用例管理系统将成为昔日的东西,  大量的测试用例生成了却没有被使用。 测
试用例将不再像腐烂的存货一样被收藏起来,因此,让测试用例保持最新变得容易起来。
?? 积极的方法
  误导人的方法,比如计算 BUG 的数量、计算测试用例的数量,将不复存在。有用的方
法,比如需求覆盖、模型覆盖、代码覆盖将驱动项目开发。
?? 更少更精的测试人员
  机器将代替测试人员做大部分他们以往创建测试所做的繁琐工作,  测试小组需要比以往
更少的测试人员, 留下来的测试人员将是经过更多高度培训过的。 他们所做的工作将更加有
趣,因为在测试中他们将致力于更大的问题,而不是在抱怨中艰难地开展工作。
?? 更多更好的测试
  测试人员将可以在一天中进行成千上万的测试,  所以,如何首先运行最有用的测试将成
为一大挑战。 相关的工具将允许测试人员为他们的测试区分优先级, 以及将测试目标放在那
些最易出现重大 BUG 的地方。
?? 测试人员的角色更换
  测试中界限模糊 ,在测试领域工作使得专职测试的人员和专职创建测试工具的人员界
                                                             版权所有??
Last saved by yanbin      ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 14   of   123
限模糊,一个既是“通过程序破坏事物的测试员”又是“创建程序用于破坏事物的程序员”
的专业出现了,                        新闻圈内的人们还在进行着无休止的争论 。
        ――关于如何称呼这个新的专业,
  测试与开发界限模糊, 测试人员与开发人员一前一后,共同创造可测试的、高质量的
代码。测试人员帮助开发人员消除需求中的问题,使得开发人员的工作更易完成,同时,开
发人员写出更清晰、可测性更高的代码,使得测试人员的工作更易完成。
  顾客反馈与测试合为一体 ,交付的产品质量更高。测试人员进行根本原因的分析,我
们会问比如“我们怎么会遗漏了这个 BUG 呢?”或者“我们将来如何防止这类 BUG?”这
些问题,我们的工作就是使顾客满意。
?? 新的挑战出现
  复杂和相互关联的计算机世界使得了测试安全这一类的新问题让测试人员不断努力工
作,但这没关系――因为这些挑战使测试人员精力充沛。
?? 测试人员获得尊重
  测试人员将不再是在最后时刻才被叫来“对产品狂轰烂炸”,他们将在整个软件开发过
程中提供一个可见的、重要的、增值的服务。人们意识到,测试是有益的、有趣的甚至富有
乐趣。
?? 测试变得流行
  软件测试人员开始扬眉吐气,而且,由于破坏事物至少可以带来创建事物一样的乐趣,
人们开始在开发和测试角色之间转换,所有的人将学到更多关于如何得到良好代码的知识。
?? 激情“吸毒者”继续存在
  新的过程运行得如此良好,使得需求撰写者,开发人员以及测试人员不再具有生命力,
这就使得那些在激情掌控的世界被提升的人惶惶不可终日,那样的世界意味着工作到深夜、
最后一刻测试才参与,     以及如同交战开火般的会议。     而这些人对于那些还没有受新的运行过
程控制的公司来说还具有吸引力。
?? 测试人员该怎么做
  不管我的预测是否成为现实,          未来也会按照它自己的方式到来,下面就是如何准备面临
未来的五个意见:
  ?? 不要接受测试的现状,四处看看,并且思考“我们在做些什么毫无意义的事情?”
  ?? 领悟如何更好的测试,         并且分享这些知识。 只有每一个人都试图使他所写的代码达
    到最佳状态时,整体质量才会改进。
  ?? 行业受软件测试的创新思维激发。用参加会议,加入邮件列表,网上冲浪,这些方
    式来解在测试前沿发生的一切。
  ?? 参加一个编程学习班,即使你不打算编写大量的代码。将学习班当作是在 BUG 领
    土上的一次侦察飞行。
  ?? PC 先驱 Alan Kay 所 言 :“预测未来的最好方式就是开创未来”。
 

                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 15   of   123
 
                第 2 章 软件质量体系
            第 1 节 软件能力成熟度模型:CMM
                  软件能力成熟度模型:CMM
  CMM 为企业的软件过程能力提供了一个阶梯式的进化框架,阶梯共有五级。第一级只
是一个起点,任何准备按 CMM 体系进化的企业都自然处于这个起点上,并通过它向第二
级迈进。除第一级外,每一级都设定了一组目标,如果达到了这组目标,则表明达到了这个
成熟级别,可以向下一级别迈进。
  从纯粹的个人行为发展到有计划有步骤的组织行为…
  第一级:初始级(Initial)
  第二级:可重复级(Repeatable)
  第三级:已定义级(Defined)
  第四级:受管理级(Managed)
  第五级:优化级(Optimizing)

2.1.1 初始级
  初始级的软件过程是未加定义的随意过程,项目的执行是随意甚至是混乱的。也许有些
企业制定了一些软件工程规范,但若这些规范未能覆盖基本的关键过程要求,且执行没有政
策、资源等方面的保证时,那么它仍然被视为初始级。
?? 关注点:
  工作方式处于救火状态,不断的应对突如其来的危机;
  工作组:软件开发组、工程组;
?? 提高:
  需要建立项目过程管理,建立各种计划,开展 QA 活动。

2.1.2 可重复级
   根据多年的经验和教训,人们总结出软件开发的首要问题不是技术问题而是管理问题。
因此,第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程,可
重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管
理、配置管理和子合同管理五个方面;  其中项目管理过程又分为计划过程和跟踪与监控过程 。
通过实施这些过程,从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
?? 关注点:
规则化
   引入需求管理、项目管理、质量管理、配置管理、子合同管理等;
   引入工作组:测试组、评估组、质量保证组、配置管理组、合同组、文档支持组、培训
组;
?? 提高:
   SEPG、建立软件过程库和文档库。
                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                            Page 16   of   123

2.1.3 已定义级
  在可重复级定义了管理的基本过程,  而没有定义执行的步骤标准。在第三级则要求制定
企业范围的工程化标准,  并将这些标准集成到企业软件开发标准过程中去。所有开发的项目
需根据这个标准过程,裁剪出与项目适宜的过程,并且按照过程执行。过程的裁剪不是随意
的,在使用前必须经过企业有关人员的批准。
?? 关注点:
  文档化、一致性;
  软件过程标准化文档化,质量可以得到控制;
  工作组: SEPG、软件评估组;
?? 提高:
  对软件过程定量分析,加强质量管理;

2.1.4 已管理级
   第四级的管理是量化的管理。所有过程需建立相应的度量方式,所有产品的质量(包括
工作产品和提交给用户的最终产品)需要有明确的度量指标。这些度量应是详尽的,且可用
于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。
?? 关注点:
   量化,可预测的;(自此,软件开发变成一种工业生产活动。)
   软件过程具有精确的评测方法,可量化地控制软件过程的产品和质量,可根据”意外情
况”确定出错的原因;
   工作组: 定量过程管理组;
?? 提高:
   防止和规避缺陷的能力,技术革新的能力,过程改进;

2.1.5 优化级
  优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反
馈信息来改善下一步的执行过程,即优化执行步骤。如果企业达到了第五级,就表明该企业
能够根据实际的项目性质、技术等因素,不断调整软件生产过程以求达到最佳。
?? 关注点:
  持续改善;
  工作组:缺陷防范活动协调组、技术改革管理活动组、软件过程改进组;
?? 改进:
  软件过程优化;

                       第 2 节 过程改进
  在一份非正式调查中,我们问题这样一个问题:
                      “作为一名软件测试人员,你认为什么
将最大成都地减轻你的工作?”答案如下:
                                                           版权所有??
Last saved by yanbin    ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 17   of   123
  改进了的系统需求文档:33%、软件测试方法/过程:31%、软件测试标准:16%、改进
了测试计划:13%、更充分的测试时间: 7%。
  可以看出,软件测试过程最亟待改善的是:软件需求、测试方法、测试过程。
 

                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                                 Page 18   of   123
 
                 第 3 章 软件生命周期
                        第 1 节 软件生命周期
3.1.1 需求管理(软件需求)Requirements Management
                Requirements
3.1.1.1 需求的内容规范

需求应当具有以下特点:
?? 完整性:每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现
  这些功能所需的所有必要信息。
?? 正确性:每一项需求都必须准确地陈述其要开发的功能。
?? 一致性:一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。
?? 可行性:每一项需求都必须是在已知系统和环境的限制范围内可以实施的。
?? 无二义性:对所有需求说明的读者都只能有一个明确统一的解释,由于自然语言极易导
  致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来。
?? 健壮性:需求的说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错
  处理。
?? 必要性:“必要性”可以理解为每项需求都是用来授权你编写文档的“ 根源 ”。要使每
  项需求都能回溯至某项客户的输入,如用例或别的来源。
?? 可测试性:每项需求都能通过设计测试用例或其它的验证方法来进行测试。
?? 可修改性:每项需求只应在需求文档中出现一次。这样更改时易于保持一致性。另外,
  使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
?? 可跟踪性:应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起
  链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好的方式编写并单独标明,
  而不是大段大段的叙述。
?? 优先级。

3.1.1.2 需求建模

    需求的建模包括把需求转换成图形模型或形式化语言模型。                         需求的图形化分析模型包括
数据流图( Data Flow Diagram , DFD ) 体 关 系 图( Entity-Relationship Diagram , ERD
                                      、实
 ) 状 态 转 化 图( State-Transition Diagram , STD ) 对 话 图( Dialog Map ) 类 图( Class
  、                                           、                   和
Diagram )。这些图形化模型一般都需要借助一定的工具。选择好的分析工具应该有助于获
得需求的质量特性,包括:有效性、一致性、可靠性、可存活性、可用性、正确性、可维护
性、可测试性、可扩展性、可交互性、可重用性、可携带性等。
 

                                                                 版权所有??
 Last saved by yanbin       ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 19   of   123

3.1.1.3 审查

  需求必须经过产品经理、软件经理、系统测试组、软件工程组、系统工程组、质量保证
组、软件配置管理组、文档支持组等小组的审查。
  通过静态手工方法进行需求测试中最常使用的手段是同行评审。

3.1.1.4 执行

        建立需求文档,分配需求(分配需求软件工程组制定软件计划的基础),修改需求。
    ??
        需求的管理需要在应用领域和软件工程方面经验比较丰富的人来担任。
    ??
        建议使用配套的需求管理工具
    ??
        除了建立相关文档,还需要对所有软件工程组人员进行项目应用领域的培训。
    ??

3.1.1.5 需求变更

变更审查:
?? 变更对现有约定的影响;
?? 提出需求变更引起的后续软件活动变更,评估风险,建立文档,全程跟踪。

3.1.1.6 交付工件

    程序陈述和需求说明说(包括用户需求和技术需求);
??
    需求文档的分类:用户需求 CR,技术需求 TR,项目需求 PR;
??
    需求的状态:已批准,已分配,已实现…
??

3.1.2 软件项目计划(Software Project Planning
             Software         Planning)
    为软件工程的运作和软件项目活动的管理提供合理的基础和可行的工作计划。

3.1.3 设计阶段
包括功能的描述和设计;
交付工件:设计说明书、功能说明书;

3.1.4 编码阶段
包括设计源代码,对目标代码进行单元测试
交付工件:软件、文档和产品信息;

                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 20   of   123

3.1.5 核实阶段
包括各种测试行为;

3.1.6 系统维护阶段
交付工件:基于设计和技术的或用户需求的测试说明、计划和结果等;

            第 2 节 软件开发过程中常见的问题
    需求说明差
??
    不切实际的时间表
??
    测试不充分
??
    不断增加功能
??
    交流问题
??

                   第 3 节 流程中的组及工作
3.3.1 流程中的组
   系统分析人员
??
   提出测试需求并跟踪,确定测试的对象/方法和范围。
?? 软件开发人员
   提供开发计划 SDP,参与制定和评审测试计划;
   提供软件功能需求规格/需求分析/测试建议等文档,参与制定和评审测试方案和案例;
   响应测试需求,跟踪解决缺陷。
?? 测试人员
   略
?? 配置管理人员
   对测试文档测试代码及相关配置项进行配置管理。
?? 质量保证人员
   质量保证,参与相关评审。由于质量保证和测试关系比较密切,多写一点。
SQA 的职责 :
   保障软件组织流程体系得到遵守、促使软件组织过程改进、指导项目实施流程、增加开
发活动透明度、评审项目活动、审核工作产品、协助工作产品问题解决、度量数据采集、分
析、提供决策参考、进行缺陷预防、实现质量目标。
   ?? 组织和协调产品开发组内部的软件技术和开发标准、流程的培训
   ?? 部门的和特定产品的软件开发过程度量( Metrics )以及软件产品质量的度量
     ( Metrics )
   ?? 指出产品开发过程中应该遵循的有关软件开发的标准和流程,   并监督开发过程对标
                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 21   of   123
      准和流程的符合度;
    ?? 软件质量管理,采用 Inspection、Review 和 Audit 技术
    ?? 通过软件开发流程及标准的推行以及对软件开发过程的不断总结和优化,           使软件开
      发过程得到持续不断的优化和提高
    其他人员
??
    如: PM/项目组/测试组/SQA/SEPG/SCM/售前/售后/市场/等等都要参与到项目中。

3.3.2 测试的组间协作
  测试人员,需求撰写人员和开发人员,都是软件流程中的一份子。
?? 测试人员帮助需求撰写人员
  测试人员与需求撰写人员共同工作,在需求完成以后,审查以及理解需求。早期的审查
以及建模可以暴露很多关于一致性、完整性和模糊性的 BUG,这个时候修补这些 BUG 付出
的代价还十分小。
?? 需求撰写人员帮助测试人员
  测试小组建造模型,用于产生对其产品行为的测试。需求撰写人员审查模型,以确保他
们充分覆盖了产品特征集。这样产生的测试模块将成为一个”可执行需求”。
?? 测试人员帮助开发人员
  因为需求清楚,毫不含糊,开发人员更好的理解了他们的代码将要完成什么。在正式的
将代码提交做测试之前, 测试人员提供给开发人员一些模型, 以便开发人员可以在自己的代
码中实现它们。
?? 开发人员帮助测试人员
  基于”特征对特征”这样的方式(防止以往的”后期才介入开发,一股脑找出产品问题”的
方式),开发人员和测试人员共同保证代码易于实施自动测试。开发人员的代码中处处都是
易测试性的开关,使得错误检测更加容易。
?? 测试人员帮助测试人员
  测试用一种高级语言来模拟,因此别的特征的测试小组(甚至别的产品的测试小组)可以
复查和改进测试模型。这就形成了一个测试专家的共同体。
 

                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                            Page 22   of   123
 
                第 4 章 软件测试基础
  一个测试人员或者一个测试团队的发展一般会历经几个阶段。第一个阶段,测试确认产
品中的缺陷。第二个阶段,除了发现缺陷以外,还进行对软件质量的度量。第三个阶段,为
了度量和提高被测试软件的质量,主动的设计、评审、优化软件测试流程中的各个因素,从
缺陷发生的源头来遏制它。
  本资料主要面向的是测试初做者或对理论掌握不够清晰的测试人员,所以本资料讲述的
内容更多集中在第一阶段。

                       第 1 节 测试理论
4.1.1 测试定义
  IEEE 中对测试的定义:使用人工或自动手段来运行或测定某个系统的过程,其目的在
于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

4.1.2 测试前提
    软件可测试性:是一个计算机程序能够被测试的容易程度。
??
    软件可测试性检查表:
??
    可操作性-运行地越好,被测试的效率越高。
??
    可观察性-所看见的,就是所测试的。
??
    可控制性-对软件的控制越好,测试越能够被自动执行与优化。
??
    可分解性-通过控制测试范围,能够更好地分解问题,执行更灵巧的再测试。
??
    简单性-需要测试的内容越少,测试的速度越快。
??
    稳定性-改变越少,对测试的破坏越小。
??
    易理解性-得到的信息越多,进行的测试越灵巧。
??

4.1.3 测试目的
    目的:发现程序中的错误,提高产品可靠性。

4.1.4 测试规律
    规律:木桶原理/八二原则。
 

                                                           版权所有??
Last saved by yanbin    ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                             Page 23   of   123

4.1.4.1 木桶原理

  产品质量的关键因素是分析、设计和实现,测试应该是融于其中的补充检查手段,其他
管理、支持、甚至文化因素也会影响最终产品的质量。应该说,测试是提高产品质量的必要
条件,也是提高产品质量最直接、最快捷的手段,但决不是一种根本手段。反过来说,如果
将提高产品质量的砝码全部押在测试上,那将是一个恐怖而漫长的灾难。

4.1.4.2 八二原则

   说法一:在分析、设计、实现阶段的复审和测试工作能够发现和避免 80%的 Bug,而系
统测试又能找出其余 Bug 中的 80%,最后的 5%的 Bug 可能只有在用户的大范围、长时间使
用后才会曝露出来。  因为测试只能够保证尽可能多地发现错误,       无法保证能够发现所有的错
误。
   说法二:80% 的程序缺陷常常生存在软件 20% 的程序空间里。

4.1.5 测试原则
    测试的工作是有计划的;
??
    zero-bug 是一种理想,good-enough 是我们的原则,应该在软件测试成本和软件质量效
??
    益两者间找到一个平衡点;
    不应测试自己开发的程序;
??
    尽早的进行,前期就要介入;<美国国防部(千行代码出错率小于 0。01) >
??
                  时期               缺陷百分比(单位%)
                  需求分析             9。0
                  概要设计             17。2
                  详细设计             21。6
                  编码和单元测试          16。4
                  集成测试             19。4
                  系统联调和系统测试        16。4
                  总计               100
    要尽早的发现缺陷和修正缺陷主要有以下原因:
    ?? 缺陷的修改成本随着阶段的推移将急剧上升,  在产品发布之后修正一个缺陷的成本
      将是需求阶段的 100 倍,甚至更高;
    ?? 缺陷具有放大的特点,  缺陷修改延迟几个星期甚至几个月将使得系统更容易出错
                                          (”
      软件缺陷具有生长和生育的能力。  ”);
    ?? 设计判定和一些小的代码限制及条件很容易被忘掉;
    ?? 尽早修正缺陷可以节省重新分析设计的时间;
    ?? 早期的问题反馈有助于防止类似错误的产生;
    ?? 大量的缺陷和问题跟踪工作将被减轻;
    ?? 如果必要的话,可以重新设计和编码,而这个工作越往后期越不可能;
    ?? 需求和设计时出现的缺陷占很大的比例。
                                                            版权所有??
Last saved by yanbin     ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                             Page 24   of   123
    测试都应追溯到用户需求。正如我们所知:软件测试的目标在于揭示错误。而最严重的
??
    错误(从用户角度来看)是那些导致程序无法满足需求的错误;
    测试设计和测试操作进行分离;
??
    软件缺陷具有免疫性,必须更换不同的测试方式和测试数据。在软件测试中采用单一的
??
    方法不能高效和完全的针对所有软件缺陷,因此软件测试应该尽可能的多采用多种途径
    进行测试;
    测试本身应该被测试;
??
    测试和质量关系密切,质量活动需要有规划和监控及明确的输出。
??

4.1.6 主要内容
    测试要考虑到所有的出错可能性。同时要做一些不是按常规做的、非常奇怪的事。
??
    除了漏洞之外,测试还应考虑性能问题,保证软件运行良好,非常快,没有内存泄漏,
??
    不会出现软件运行越来越慢的情形。
    测试要考虑软件的兼容性。
??

4.1.7 不利因素
测试可能存在的不利因素:
?? 没有得到足够的培训
?? 心里准备不足
?? 缺乏测试工具
?? 缺乏管理的标准和支持
?? 缺乏客户和最终使用者的参与
?? 没有足够的时间进行测试
?? 对于独立的测试人员过度信任
?? 版本改变的太快
?? 测试人员处于不受重视的情况中
?? 不能说不

                       第 2 节 测试生命周期
4.2.1 测试生命周期
    ?? 对测试人员进行业务培训
    ?? 测试需求分析
    ?? 编写测试计划
    ?? 编写测试案例
    ?? 测试执行(包括缺陷跟踪)
    ?? 编写测试报告
    备注:需要重视各步骤结束前的评审工作。
                                                            版权所有??
Last saved by yanbin     ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 25   of   123

4.2.2 流程中的文档

4.2.2.1 测试计划

  测试计划和产品开发紧密相关,   由多个部分组成。  所有大型的商业软件都需要完整的测
试计划,需要具体到每一个步骤,并且每一个部分都要符合规范要求。
  测试计划包括内容:1) 概述;2) 测试目标和发布标准;3) 计划将测试的领域;4) 测
试方法描述;5) 测试进度表;6) 测试资源;7) 配置范围和测试工具 。

4.2.2.2 测试规范

  测试规范是指微每一个在测试计划中确定的产品领域所写的文档,   用来描述该领域的测
试需求。编写测试规范,需要参照项目经理写的产品规范,开发人员写的开发计划。每个领
域都应该有一份详细的测试规范,所以还需要参照测试计划。
  测试规范包括的内容: 背景信息;2) 被测试的特性;3) 功能考虑;4) 测试考虑; 5)
            1)
测试想定 。

4.2.2.3 测试案例

  测试案例是指描述如何测试某一个领域的文档,这些文档符合测试规范中的需求说明。
根据测试规范的测试想定(scenario)开发,根据测试反馈信息,对于没有考虑到的新问题,不
断添加测试案例。 测试案例没有固定格式,只要清楚表明了测试步骤和需要验证的事实,
使得任何一位测试人员都可以根据测试案例的描述完成测试。

4.2.2.4 测试报告

   测试管理人员以测试报告的形式向整个产品开发部门报告测试结果及发现的缺陷或错
误。撰写测试报告的目的是为了让整个产品开发部门了解产品开发的进展情况,以使缺陷或
错误能够迅速得到修复。 测试报告的格式并无定式,要求能够完整、清楚地反映当前的测
试进展情况,要易懂,不要使人迷惑或产生误解。

4.2.2.5 缺陷或错误报告

    测试人员以缺陷或错误报告的形式向开发人员报告所发现的缺陷或错误。     撰写缺陷或错
误报告的目的是为了使缺陷或错误能够得到修复,       测试人员的缺陷或错误报告撰写的好坏会
直接影响到开发人员对缺陷或错误的修复。
    一份缺陷或错误报告应该包括的几个要点: 缺陷或错误名称;2) 被测试软件的版本;
                          1)
3) 优先度与严重性;4) 报告测试的步骤;5) 缺陷或错误造成的后果;6) 预计的操作结果;
7) 其他信息。
                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                              Page 26   of   123

4.2.3 软件开发测试模型
    常用 V 模型,对于 X、W 等模型没有做深入研究。

                       第 3 节 测试人员的责任
  测试人员的任务就是站在使用者的角度上,通过不断地使用和攻击刚开发出来的软件产
品,尽量多地找出产品中存在的问题。

4.3.1 测试启动需确定的工作

4.3.1.1 需求阶段

        确定测试策略;
    ??
        确定收集了足够的需求;
    ??
        产生功能性的测试用例;
    ??
        需要接收的资料
    ??
        需求规格说明书;
    ??
        产品文档等;
    ??

4.3.1.2 设计阶段

        确定设计和需求之间的联系;
    ??
        确定进行了足够的设计;
    ??
        产生结构和功能的测试用例;
    ??

需要接收的资料
    输入说明;
??
    过程说明;
??
    文件说明;
??
    输出说明;
??
    控制说明;
??
    系统流程图;
??
    硬件和软件的需求;
??
    操作手册说明书;
??
    数据保留的策略;
??
 

                                                             版权所有??
Last saved by yanbin      ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 27   of   123

4.3.1.3 编码阶段

        确定和设计之间的联系;
    ??
        确定拥有执行的足够条件;
    ??
        产生结构和功能的测试用例;
    ??

需要接收的资料
    编码说明书;
??
    程序文档;
??
    计算机程序列表;
??
    可执行的程序;
??
    程序流程图;
??
    操作介绍;
??
    单元测试结果;
??
    测试阶段
??
    确定设计了足够的测试用例;
??
    测试应用系统已经完成,并且可测;
??
    关键资源已经到位;
??

4.3.1.4 维护阶段

        缺陷的跟踪;
    ??
        新的版本测试;
    ??

4.3.2 测试需完成的工作

4.3.2.1 需求评审

确定需求是足够的;

4.3.2.2 制定测试计划

    ??   -确定测试需求
    ??   -评估风险
    ??   -制定测试策略
    ??   -确定测试资源
    ??   -创建时间表
    ??   -生成测试计划
                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                               Page 28   of   123

4.3.2.3 设计测试

    ??   -准备工作量分析文档
    ??   -确定并说明测试用例
    ??   -确定测试过程,并建立测试过程的结构
    ??   -复审和评估测试覆盖

4.3.2.4 实施测试

    ??   -记录或通过编程创建测试脚本
    ??   -确定设计与实施模型中的测试专用功能
    ??   -建立外部数据集
        执行测试
    ??
    ??   -执行测试过程
    ??   -评估测试的执行情况
    ??   -恢复暂停的测试
    ??   -核实结果
    ??   -调查意外结果
    ??   -记录缺陷

4.3.2.5 对测试进行评估

    ??   -评估测试用例覆盖
    ??   -评估代码覆盖
    ??   -分析缺陷
    ??   -确定是否达到了测试完成标准与成功标准

                        第 4 节 测试方法和分类
本节只做一个概括指出,下一章将详细讲解。

4.4.1 测试分类
    白盒测试
??
    黑盒测试
??

4.4.2 黑盒测试的测试用例设计方法:
· 等价类划分方法;
· 边界值分析方法;
                                                              版权所有??
 Last saved by yanbin      ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 29   of   123
·   错误推测方法;
·   因果图方法;
·   判定表驱动分析方法;
·   正交实验设计方法;
·   功能图分析方法 <流程场景(重要执行通路/出错处理通路) >;

4.4.3 系统测试类型
    恢复测试;
??
    完整>安全>性测试;
??
    强度测试<使资源出现短缺的情况,检查系统的应对>;
??
    容量测试;
??
    结构测试;
??
    性能测试<疲劳测试/压力测试/响应时间>;
??
    配置测试;
??
    安装、卸载测试;
??
    用户界面测试<界面友好性>;
??
    功能测试<正确性测试/容错性(健壮性)测试>;
??
    比较测试;
??
    可移植性<兼容性测试>;
??
    接口间测试;
??
    数据库测试。
??

                 第 5 节 软件产生错误的原因
4.5.1 程序开发产生缺陷的原因
    需求不清晰;
??
    软件复杂性;
??
    程序编码错误;
??
    需求变化;
??
    时间压力;
??
    代码文档贫乏;
??
    开发工具自身错误;
??

4.5.2 测试导致缺陷的原因
    测试目标定义错误;
??
    在开发生命周期中,错误的选择了测试介入时期;
??
    选择了低效的测试技术;
??
    测试人员专业知识培训不够,工作低效;
??
                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                            Page 30   of   123
?? 计划不够详细,测试的随意性很大;
?? 测试人员同开发人员沟通困难。

4.5.3 程序缺陷包含的因素
生产软件的最终目的是为了满足客户需求,       我们以客户需求作为评判软件质量的标准,软件
缺陷( Software Bug )的具体含义包括下面几个因素:
?? 软件未达到客户需求的功能和性能;
?? 软件超出客户需求的范围;
?? 软件出现客户需求不能容忍的错误;
?? 软件的使用未能符合客户的习惯和工作环境。

4.5.4 软件缺陷包含的因素
  软件缺陷不仅仅是包括程序运行时出现问题,还包括考虑到设计等方面的因素。 当 然 ,
软件缺陷还可以包括软件设计不符合规范,未能在特定的条件(资金、范围等)达到最佳等 。
  所以说,认为软件测试仅限于程序提交之后是错误的。

                       第 6 节 关于缺陷
4.6.1 常规测试点
    输入/输出的测试要点
??     /
    文件属性是否正确?
??
    打开文件语句是否正确?
??
    格式说明书与输入/输出语句是否一致?
??
    缓冲区大小与记录长度是否匹配?
??
    使用文件之前先打开文件了吗?
??
    文件结束条件处理了吗?
??
    输入/输出错误检查并处理了吗?
??
    输出信息中由文字书写错误吗?
??
    局部数据结构的测试要点
??
    错误的或不相容的说明
??
    使用尚未赋值或尚未初始化的变量
??
    错误的初始值或不正确的缺省值
??
    错误的变量名字(拼写错或截短了)
??
    数据类型不相容
??
    上溢、下溢或地址异常
??
    计算中的常见错误
??
    计算次序不对或误解了运算符的优先次序
??
    混合运算(运算对象的类型彼此不相容)
??
                                                           版权所有??
Last saved by yanbin    ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 31   of   123
    变量初始值不正确
??
    精度不够
??
    表达式的符号表示错误
??
    测试方案中的错误
??
    比较数据类型不同的量
??
    逻辑运算符不正确或优先次序的错误
??
    当由于精度问题两个量不会相等时,程序中却期待着相等条件的出现
??
    “差 1”错(即,多循环一次或少循环一次)
??
    错误的或不存在的循环终止条件
??
    当遇到发散的迭代时不能终止循环
??
    错误地修改循环变量
??
    评价出错处理时的常见错误
??
    对错误的描述是难于理解的
??
    记下的错误与实际遇到的错误不同
??
    在对错误进行处理之前,错误条件已经引起系统干预
??
    对错误的处理不正确
??
    描述错误的信息不足以帮助确定造成错误的位置
??

4.6.2 为什么缺陷很难找
    需求解释有错误;
??
    用户定义错了需求;
??
    需求记录错误;
??
    设计说明有误;
??
    编码说明有误;
??
    程序代码有误;
??
    数据输入有误;
??
    测试错误;
??
    问题修改不正确;
??
    正确的结果是由于其它的缺陷产生的。
??

4.6.3 缺陷的提交艺术
  Bug report 的核心是对错误的描述。编写好的 bug report 是一种好的艺术形式。采用以
下的 10 条技巧可以帮助你的小组提高编写 bug report 的质量:
?? 组织(Structure):测试人员应该采用深思熟虑的,小心谨慎的方法执行测试,并且做
  详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候,一
  个有组织的测试人员能够知道最早出现问题的地方。
?? 重现(Reproduce):测试人员在编写 bug report 之前必须在检查问题是否可重现。如果
  错误不可再重现,仍然应该写下来,但是必须说明问题的偶然性。一个好的处理原则就
  是在编写 bug report 之前反复尝试 3 次。
?? 隔离(Isolate):在尝试编写 bug report 之前,必须试着隔离错误。可以采用改变一些变
  量的方法,如系统的配置,它可能可以改变错误的症状。这些信息可以为开发人员着手
                                                          版权所有??
Last saved by yanbin   ??晏宾<xyanbin@gmail.com>2007
软件测试从这里开始                                           Page 32   of   123
    调试提供思路。
    归纳(Generalize):在测试人员发现了一个已隔离的,可重现的问题后,应该对问题进
??
    行归纳。    同一个问题是否出现在其他的模块或其他的地方?同一个故障是否有更加严重
    的问题?
    对比(Compare):如果测试人员以前曾经验证过现在出错的测试用例,那么他就应该
??
    检查以前的测试结果以检查相同的条件是否通过以前的测试。               如果是的话, 那么这个问
    题就象是一个回归的错误。        注意由于同一测试条件有可能出现在多个测试用例中,        这个
    步骤就不仅仅只是检查一个测试用例在以前的多个结果。
    总结(Summarize):在 bug report 的第一行写上错误的总结是非常关键的。测试人员要
??
    花些时间思考已发现的错误对客户有何影响。               这不仅仅要求测试人员编写的报告要能够
    吸引读者,使和管理层的沟通清晰,还要能够帮助设置错误修复的优先级别。
    精简(Condense):在 bug report 的初稿完成后,测试人员应该反复阅读它,集中剔除
??
    那些没有关系的步骤或词语。         隐含的或模糊的说明和那些由于对没有任何关系的细节或
    者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是 bug
    report 的目标。
    消除歧义(Disambiguate):测试人员在精简空话的同时或其之后随即应该再仔细检查报
??
    告是否有会产生误解的地方。         测试人员应该尽量避免使用模糊的,      会产生歧义的和主观
    的词语。目标是使用能够表述事实,清楚的,不会产生争执的词语。
    中立(Neutralize):如文中所述,作为坏消息的传递人,和善地提交消息是一个挑战。
??
    如同所有的错误总结一样,        独立的 bug report 在措辞方面应该保持公正。攻击开发人员 ,
    指责潜在的错误,企图诙谐或使用挖苦将引起开发人员的憎恶,并且使注意力从”提高
    产品质量”这个大的目标上转移开了。谨慎的测试人员只用 Bug report 来描述事实。
    检查(Review):一旦测试人员感觉 bug report 是他能够编写的最好版本,他应该将报
??
    告再给一个或多个同行进行检查。            他的同事们也应该给出一些建议,   为了澄清问题不断
    地提问,如果适当的话,甚至可以挑战”错误成灾”的结论。在允许的时间里,测试小组
    应该尽可能提交最好的 bug report。

4.6.4 衡量优秀的 bug report 的质量指标


TAG: 软件测试 资料

 

评分:0

我来说两句

日历

« 2024-03-23  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 7369
  • 日志数: 8
  • 建立时间: 2011-04-13
  • 更新时间: 2011-06-16

RSS订阅

Open Toolbar