软件测试的重要性课件

随着软件业蓬勃发展，各种软件需求纷繁而来，在潮起潮落的IT 洪流中，软件项目越来越凸现大型化、复杂化的发展趋势。几十人上百人的开辟团队、成千上万的模块与接口、跨地域、跨系统的使用用户等情况早已屡见不鲜，所有这些，对项目质量管理提出了更高要求，如何满足各方需求，做出更好的软件系统？测试管理逐渐成为了大家目光的焦点。

软件的质量靠什么，靠管理、靠各个软件过程的严密配合。但勿庸置疑，质量的守护是靠测试。它就象一只看门狗，认真守护着软件质量这个“家”。

测试是什么？测试就是对项目开辟过程的产品 (编码、文档等)进行差错审查，保证其质量的一种过程。

软件业的迅猛发展也就是近几十年的过程，时间虽短，但许多误解似乎已根深蒂固，对测试的偏见也是如此。“软件的重点在于需求、在于分析、在于设计、在于开辟，而测试，容易，没什么技术含量，找一些用户，对照需求竭力去测就行了；有时间多测点，没时间就少测点。”这种看法在许多项目经理、软件负责人的心中固守着，难以改变。

这种观念的结果有目共睹，是什么？很简单，是大量软件BUG、缺陷的“流失”，从测试人员手中悄然而过，流失到用户手中，流失进项目维护阶段。随之而来的，便是用户无住手的抱怨、维护人员无住手的“救火”、维护成本无住手的增加。这是软件人员的梦魇！

恶梦总有醒来时，经过无数教训的重击，在不堪回首而不得回首的经历中，软件业的管理者发现：是他们错了，软件测试是不可忽视的。

“所有这些问题，假如在项目中测试到的话，便不会有造成不可收拾的结果了。”――人们终于意识到测试简单而纯真的真谛。

软件测试

软件测试从直观上来讲是对测试对象进行检查、验证，似乎很简单，但实际不然，它是由许多处理环节构成的。根据测试目标、质量控制的要求，它被划分为以下各类环节 (如下图) ，并被设置了不同的准入、准出标准。

测试的主要过程及活动如上图所示，内容一目了然，在此就不一一详述了，只希翼通过对测试重点问题、关注热点的介绍，匡助大家对测试管理有一个总体的把握。

测试方式中普遍存在的问题与点评

谈到测试，我们无法回避的是当前软件过程普遍存在的测试问题：

1、手工过多，缺少测试工具，自动化测试方式缺失。

传统的项目测试还是以手工为主，测试人员根据需求规格说明书的要求，与测试对象进行“人机对话”。随着软件业的不断发展及软件规模的扩大，这种测试的弊端日益明显：

·大量的手工使项目人力成本、沟通成本居高不下；

·人工操作的低效率使项目耗时增加，带来进度风险；

·人员素质及其他不确定因素会影响手工测试的结果，导致差错率的增加。

·在测试过程中，需要对测试案例库进行统一配置管理，项目规模的激增使手工管理案例库的难度日益加大，特别是在需求变更、回归测试频繁发生的时候。

从古到今，当生产率妨碍了生产力的发展的时候，必然会引入更高级的生产工具及方式。项目测试也是这个道理，引入工具，引入自动化测试及管理，是项目测试的一大趋势。

2、缺乏文档测试、检查。

文档是项目的重要产品之一，产品需求、功能分析、架构设计、详细设计、用户手册、维护手册等等，对于项目的测试、上线、维护等过程起到至关重要的参考、指导作用，所以它们的质量应该是项目重点关注点之一。令人遗憾的是，许多软件项目对于文档的重视只停留在口头上，“编码第一”的观念似乎根深蒂固。

随着需求不断变更、补充，业务、技术人员忙于对付，无法腾出精力来进行文档内容的修改及完善，往往是将包含需求变更内容的工作联系单往需求文档后一附了事，而不去更新需求与其他相关文档；另一方面，项目变更管理还不够完善，管理重点往往集中于开辟，而轻蔑文档质量管理，未留出充分的文档更新时间，导致文档更新严重滞后于编码进度。为保证文档质量，必须定期进行文档测试，但测试要花成本，项目高层不愿意付此代价。

文档若可读性低，便会影响用户的理解；若与编码不一致，便起不到参考作用，编码测试就没有可靠的测试依据。路都看不清晰，怎么往前走呀？所以，强烈建议进行文档测试，并将其置于测试管理的首位。

当前文档测试的方法没有什么特殊的形式，还缺乏测试工具支持，通常是通过静态审查方

式――“走查”来进行的，主要查看文档的可读性，内容真实性、可靠性、全面性。此外，在项目里程碑时期召集相关领域专家对重要文档进行集中审核，也是一种检查方式。

3、单元测试应引入交叉测试方法；

单元测试是对软件基本组成单元进行的测试，测试对象是软件模块。通常，单元测试是由开发人员来完成，而且往往是各人测各人的。这存在问题隐患。

为什么呢，技术人员是软件模块的创造者，自己来测自己的软件的话，角色便从创造者变成了审查者，而前一个角色的目的是为了保证软件正确，后一个角色的目的是为了发现更多的缺陷，让一个人同时来扮演两种目的不同的角色，好比让他既当裁判员又当运动员，怎么能做好呢？

解决方法通常有两种，一种是：由测试人员来进行单元测试，这种方式要求测试人员要有较高的软件技术知识；另一种是：将软件人员分组，在模块开辟告一段落时进行交叉测试，这种方法只需要测试者了解被测方的软件需求，不需要此外的知识培训，而且测试出发点较为客观，所以被较普遍的推广使用。

4、测试在开辟基本完成才启动；

在传统的瀑布型开辟模式中，软件测试位于编码阶段之后，是作为一个独立阶段存在的，许多人便一刀切地认为应该将所有的测试工作在编码完成后再开始。这个观点要不得，原因有二：

首先，若将测试工作细分，有许多工作是可以提前先期执行的，如：需求书与设计书的学习、测试计划的制定、测试人员的培训、测试脚本的建立、测试资源的搭建、测试模板的创建、测试工具的选择等等，都是可以与其他阶段并行处理的，这将大大缩短项目开辟时间，为测试提供充分的时间保障，提高测试质量。

其次，软件缺陷发现的越晚，修改、补救所耗费的成本越高。引用Boehm 在《Software Engineering Economics》一书中的话――“平均而言，如果在需求阶段修证一个错误的代价是1，那末，在设计阶段就是它的3－6 倍，在编程阶段是它的10 倍，在内部测试阶段是它的20—40 倍，在外部测试阶段是它的30－70 倍，而到了产品发布出去时，这个数字就是40－1000 倍。”由此可见，测试目标的最佳定位应该是：在错误第一次浮现的时候就捕捉到它。所以，在尽可能的情况下，测试越早展开越好。