软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场危机，软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况，那就是软件中有错误，正是这些错误导致了软件开发在成本、进度和质量上的失控。有错是软件的属性，而且是无法改变的，因为软件是由人来完成的，所有由人做的工作都不会是完美无缺的。问题在于我们如何去避免错误的产生和消除已经产生的错误，使程序中的错误密度达到尽可能低的程度。
给软件带来错误的原因很多，具体地说，主要有如下几点：
①、交流不够、交流上有误解或者根本不进行交流
在应用应该做什么或不应该做什么的细节(应用的需求)不清晰的情况下进行开发。
②、软件复杂性
图形用户界面(GUI)，客户/服务器结构，分布式应用，数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代软件开发经验的人很难理解它。
③、java/j2me/code/ target=_blank>程序设计错误
象所有的人一样，程序员也会出错。
④、需求变化
需求变化的影响是多方面的，客户可能不了解需求变化带来的影响，也可能知道但又不得不那么做。需求变化的后果可能是造成系统的重新设计，设计人员的日程的重新安排，已经完成的工作可能要重做或者完全抛弃，对其他项目产生影响，硬件需求可能要因此改变，等等。如果有许多小的改变或者一次大的变化，项目各部分之间已知或未知的依赖性可能会相互影响而导致更多问题的出现，需求改变带来的复杂性可能导致错误，还可能影响工程参与者的积极性。
⑤、时间压力
软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。
⑥、自负人更喜欢说:
没问题
这事情很容易
几个小时我就能拿出来
太多不切实际的‘没问题’，结果只能是引入错误。
⑦、代码文档贫乏
贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的保密(“写得艰难必定读的痛苦”)。
⑧、软件开发工具
可视化工具，类库，编译器，脚本工具，等等，它们常常会将自身的错误带到应用软件中。就象我们所知道的，没有良好的工程化作为基础，使用面向对象的技术只会使项目变得更复杂。 为了更好地解决这些问题，软件界做出了各种各样的努力。
人们曾经认为更好的程序语言可以使我们摆脱这些困扰，这推动了程序设计语言的发展，更多的语言开始流行，为了使程序更易于理解开发了结构化程序设计语言，如PL/1,PASCAL等；为了解决实时多任务需求开发了结构化多任务程序设计语言，如Modula，Ada等；为了提高重用性开发了面向对象的程序设计语言，如Simlasa等；为了避免产生不正确的需求理解，开发形式化描述语言，如HAL/S等，这使得建立基于自然语言的描述成为可能，人们以形式化语言来描述需求；为了支持大型数据库应用，开发了可视化工具，如Visual Studio、Power Builder等。程序语言对提高软件生产效率起到了一定的积极作用，但它对整个软件质量尤其是可靠性的影响，与其他因素相比作用较小。
可能是因为程序语言基于严格的语法和语义规则，人们企图用形式化证明方法来证明程序的正确性。将程序当作数学对象来看待，从数学意义上证明程序是正确的是可能的。数学家对形式化证明方法最有兴趣，在论文上谈起来非常吸引人，但实际价值却非常有限，因为形式化证明方法只有在代码写出来之后才能使用，这显然太迟了，而且对于大的程序证明起来非常困难。 受到其他行业项目工程化的启发，软件工程学出现了，软件开发被视为一项工程，以工程化的方法来进行规划和管理软件的开发。
针对需求不确定的应用，可以使用渐进和迭代类的开发模型。还可以采用快速应用程序开发(RAD)和协同应用程序开发（JAD）技术，由软件开发者和用户代表共同参与开发软件规范。RAD和JAD的基本思路是开发者和用户共同设计系统中的屏幕，开发者迅速地把实现这些屏幕的最基本功能编写好，然后把它们交给用户看，然后用户和开发者回顾这些屏幕以确认它们达到了用户的要求，这个周期一直持续到系统的基本部分定义完毕。一旦设计被用户接受，开发者将完成完全实现屏幕需要的代码。RAD和传统软件开发项目之间的一个基本区别是：应用程序RAD系统是按阶段发布的。传统项目一般一次发布，也叫“big bang”。RAD方法使用高效开发工具，开发者能够非常迅速地设计出系统的基本屏幕，允许用户在开发周期中很早就能见识到系统将来看起来怎么样，避免了在传统开发项目中长篇大论并且枯燥难懂的说明。
IBM的Dr.Harlan Mills提出了净室过程。净室过程组合了形式化程序验证和统计过程控制(SPC)。在这种方法中，首先用正确性数学证明预防缺陷发生，然后用MTBF度量软件质量。净室过程是一种相当新的软件开发方法，它要求软件开发在管理方式和技术方法上作重大改变，特别是要求SPC应用到软件的知识，这影响了其被广泛的接受。
硬件成本持续降低，可支持CASE工具运行的新的强大的工作站和网络已经成为软件工程使用的工作平台，CASE工具可完成一些特定的软件开发过程。这些工具提供给软件设计者以图形方式描述软件设计的能力，这样就易于维护、易于交叉检查、易于理解。许多人（尤其是CASE工具供货商）相信CASE工具扮演了解决软件危机和拯救软件工业的角色，但事实上我们看到的情形却是许多公司花了大量的金钱买回的CASE工具但很少使用，原因在于这些工具执行的过程与机构的软件设计过程不相适用。
在可以借助许多新的技术和工具进行软件开发的今天，软件开发过程的成熟性问题开始引起人们的重视。这种产品一致性问题的主要症结在于管理，因此人们将目标转向了管理的改善，一些以改进软件开发过程为目标的活动已经展示出积极的结果。
以下是一些比较典型的文本。
SEI SW-CMM
ISO SPICE(Software Process Improvement and Capability dEtermination)
Bootstrap
ISO-9000-3
TickIT
Trillium
事实上，对于软件来讲，还没有象银弹那样的东西。不论采用什么技术和什么方法，软件中仍然会有错。采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是不可能完全杜绝软件中的错误，这些引入的错误需要测试来找出，软件中的错误密度也需要测试来进行估计。 测试是所有工程学科的基本组成单元，是软件开发的重要部分。自有程序设计的那天起测试就一直伴随着。统计表明，在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40％以上。而在软件开发的总成本中，用在测试上的开销要占30％到50％。如果把维护阶段也考虑在内，讨论整个软件生存期时，测试的成本比例也许会有所降低，但实际上维护工作相当于二次开发，乃至多次开发，其中必定还包含有许多测试工作。因此，测试对于软件生产来说是必需的，问题是我们应该思考“采用什么方法、如何安排测试?”。
软件测试是软件质量保证的关键步骤。美国质量保证研究所对软件测试的研究结果表明:越早发现软件中存在的问题，开发费用就越低;在编码后修改软件缺陷的成本是编码前的10倍，在产品交付后修改软件缺陷的成本是交付前的10倍;软件质量越高，软件发布后的维护费用越低。另外，根据对国际著名IT企业的统计，它们的软件测试费用占整个软件工程所有研发费用的50% 以上。
相比之下，中国软件企业在软件测试方面与国际水准仍存在较大差距。首先，在认识上重开发、轻测试，没有认识到软件项目的如期完成不仅取决于开发人员，更取决于测试人员；其次，在管理上随意、简单，没有建立有效、规范的软件测试管理体系；另外，缺少自动化工具的支持，大多数企业在软件测试时并没有采用软件测试管理系统。所以对国内软件企业来说，不仅要提高对软件测试的认识，同时要建立起完善的软件测试管理体系。
让软件测试走向规范
建立软件测试管理体系的主要目的是确保软件测试在软件质量保证中发挥应有的关键作用：
软件产品的监视和测量 对软件产品的特性进行监视和测量，主要依据软件需求规格说明书，验证产品是否满足要求。所开发的软件产品是否可以交付，要预先设定质量指标，并进行测试，只有符合预先设定的指标，才可以交付。
对不符合要求的产品的识别和控制 对于软件测试中发现的软件缺陷，要认真记录它们的属性和处理措施，并进行跟踪，直至最终解决。在排除软件缺陷之后，要再次进行验证。
产品设计和开发的验证 通过设计测试用例对需求分析、软件设计、程序代码进行验证，确保程序代码与软件设计说明书的一致，以及软件设计说明书与需求规格说明书的一致。对于验证中发现的不合格现象，同样要认真记录和处理，并跟踪解决。解决之后，也要再次进行验证。
软件过程的监视和测量 从软件测试中可以获取大量关于软件过程及其结果的数据和信息，它们可用于判断这些过程的有效性，为软件过程的正常运行和持续改进提供决策依据。
建立测试管理体系
一般应用过程方法和系统方法来建立软件测试管理体系，也就是把测试管理作为一个系统，对组成这个系统的各个过程加以识别和管理，以实现设定的系统目标。同时要使这些过程协同作用、互相促进，从而使它们的总体作用大于各过程作用之和。其主要目标是在设定的条件限制下，尽可能发现和排除软件缺陷。测试系统主要由下面6个相互关联、相互作用的过程组成：
测试规划
确定各测试阶段的目标和策略。这个过程将输出测试计划，明确要完成的测试活动，评估完成活动所需要的时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制测试过程的活动。
测试规划与软件开发活动同步进行。在需求分析阶段，要完成验收测试计划，并与需求规格说明一起提交评审。类似地，在概要设计阶段，要完成和评审系统测试计划;在详细设计阶段，要完成和评审集成测试计划;在编码实现阶段，要完成和评审单元测试计划。对于测试计划的修订部分，需要进行重新评审。
测试设计
根据测试计划设计测试方案。测试设计过程输出的是各测试阶段使用的测试用例。测试设计也与软件开发活动同步进行，其结果可以作为各阶段测试计划的附件提交评审。测试设计的另一项内容是回归测试设计，即确定回归测试的用例集。对于测试用例的修订部分，也要求进行重新评审。
测试实施
使用测试用例运行程序，将获得的运行结果与预期结果进行比较和分析，记录、跟踪和管理软件缺陷，最终得到测试报告。
配置管理
测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象包括测试计划、测试方案（用例）、测试版本、测试工具及环境、测试结果等。
资源管理
包括对人力资源和工作场所，以及相关设施和技术支持的管理。如果建立了测试实验室，还存在其他的管理问题。
测试管理
采用适宜的方法对上述过程及结果进行监视，并在适用时进行测量，以保证上述过程的有效性。如果没有实现预定的结果，则应进行适当的调整或纠正。
此外，测试系统与软件修改过程是相互关联、相互作用的。测试系统的输出（软件缺陷报告）是软件修改的输入。反过来，软件修改的输出（新的测试版本）又成为测试系统的输入。
根据上述6个过程，可以确定建立软件测试管理体系的6个步骤：
识别软件测试所需的过程及其应用，即测试规划、测试设计、测试实施、配置管理、资源管理和测试管理；
确定这些过程的顺序和相互作用，前一过程的输出是后一过程的输入。其中，配置管理和资源管理是这些过程的支持性过程，测试管理则对其他测试过程进行监视、测试和管理；
确定这些过程所需的准则和方法，一般应制订这些过程形成文件的程序，以及监视、测量和控制的准则和方法；
确保可以获得必要的资源和信息，以支持这些过程的运行和对它们的监测；
监视、测量和分析这些过程；
实施必要的改进措施。
i-Test 2.0x打造测试管理体系
所谓工欲善其事，必先利其器，有了事半功倍的工具，自然能提高工作效率，软件测试管理系统就是建立软件测试管理体系、保证软件测试顺利进行的利器。i-Test 2.0是中科软件公司从软件测试的需求出发，按照国际质量管理标准研制的软件测试管理系统。
它采用B/S结构，可以安装在Web服务器上，项目相关人员可以在不同地点通过Internet同时登录和使用i-Test，协同完成软件测试，可减少为了集中人员而出差所产生的费用。它还提供相应的自动化功能，可高效地编写、查询和引用测试用例，快速填写、修改和查询软件缺陷报告，减少了人力投入。它自带的测试用例数据库和软件缺陷数据库，可以帮助项目成员更好地实施软件测试。
在具体的软件缺陷中，它将其生命周期分为6个生命状态：open、working、verify、cancel、close和defer，能详细记录、跟踪和管理每个软件缺陷的生命过程，直至排除这个缺陷。它还为软件缺陷设定了严重级别、优先级、缺陷类型等属性，可自动分清软件缺陷的轻重缓急，并能提供相关的分析和统计功能。
此外，除了可以监测和分析软件的质量，i-Test还可以自动统计程序员和测试人员的工作进度。它提供的测试文档模板，可以将测试文档及数据直接传送到MS Office，使排版、打印等操作更为便捷。
配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。在实际测试中，软件环境又可分为主测试环境和辅测试环境。主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。一般来说，配置主测试环境可遵循下列原则：
1.符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。
2.选用比较普及的操作系统和软件平台。例如，一个软件若声称支持“Windows9X/ME/NT Workstation/2000 professional”和“MS Office 97/2000/XP”，一般我们会采用如“Windows 2000professional+MS Office 2000”的流行环境。
3.营造相对简单、独立的测试环境。除了操作系统，测试机上只安装软件运行和测试必需的软件，以免不相关的软件影响测试实施。
4.无毒的环境。利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。
辅测试环境常常用来满足不同的测试需求或特殊测试项目：
兼容性测试：在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。
模拟真实环境测试：有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。
横向对比测试：利用辅测试环境“克隆”出完全一致的测试环境，从而保证各个被测软件平等对比。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
