联想软件测试理论与实践.doc

资源描述

联想软件测试理论与实践２５８联想软件测试理论与实践联想软件测试中心序《联想软件测试理论与实践》终于完成了，欣喜之余，回想起软件测试中心这几年在测试技术和流程管理方面取得的巨大进步，真是令人感到骄傲和自豪。当然，软件测试工作持续改进是我们永恒的目标，所以随着我们对软件测试理论认识和实践经验不断深化，本书也会陆续做一些修订和补充。本书主要是联想软件内部使用，为软件测试中心人员提供测试技术指导和测试实施指南，对测试新员工尤为适用。同时联想其他同仁也可阅读此书，以了解软件测试知识和我们实际工作情况。本书安排由浅入深，从软件基础开始讲解，重点讲解了软件测试技术、软件测试类型、软件测试管理等几方面，同时也对软件质量、测试持续改进、测试自动化也做了介绍。对于软件测试新员工，可以按顺序学习，对于有一定测试经验或对软件测试比较了解的同仁，则可以直接选择自己所关心的章节进行阅读和参考。另外，本书并没有提供很多测试实例，大家可以到软件测试中心的技术构架中去获取。由于本书遵从联想软件研发规范，遵从联想软件设计中心的过程改进方针。所以阅读本书前，需要大家对软件工程和联想软件研发规范有一定的了解。本书采用的术语与联想软件设计中心研发规范相一致，同时在很大程度上把软件测试工作描述得更为深刻，有些目标和标准甚至是我们目前还没有开展实施的，并包含了作者个人的一些观点，所以可能会有不科学、不实用之处，敬请各位同仁多多指正和包涵！很多人为本书的编写虽然付出了很多时间和心血，但仍感觉完成得较为仓促，所以请大家在阅读本书的同时，多多提出宝贵的意见和建议，谢谢！本书是在联想助理总裁联想软件设计中心总经理韩振江的关心下完成的，这里要向所有关心本书和关心软件测试工作的领导和同仁们道谢！作者于２００２年12月目录序２目录３前言９第一章：软件测试概述１３第一节：什么是软件测试１４第二节：软件测试的目的１４第三节：对软件测试的理解１６第四节：软件测试的原则１８测试技术和策略方面１８测试管理方面１９ “好”的测试的一些属性１９第五节：测试用例介绍２０对测试用例的理解２０测试用例设计生成的基本原则２０第六节：软件测试模型２１ V模型２１ h模型２１ Shewwhart循环模型２３模型小结２６第七节：确认和验证２７第八节：软件测试流程概述２８软件开发流程概述２８软件测试流程概述２９测试工程师的职责３１第九节：测试人员的素质要求３２测试人员的技术素质要求３２测试人员的非技术素质要求３３第十节：如何做好软件测试工作３５第二章：软件质量与测试３５第一节：软件质量的重要性３６第二节：软件质量问题的原因３７第三节：对软件质量特性的理解３８软件质量内涵３８软件质量特性定义３９软件质量特性之间的关系４２软件质量的观点４２软件质量特性对于测试人员的意义４４第四节：基于软件质量特性的测试４４功能性测试４４可靠性测试４５易用性测试４８兼容性测试５５第三章：软件测试技术和方法５８第一节：静态测试和动态测试５９静态测试６０动态测试６１第二节：黑盒和白盒测试概述６１第三节：黑盒测试技术６２等价类划分６３边值分析６４特殊数据分析６６因果图法６８第四节：白盒测试技术６９白盒测试概述６９程序结构分析７０逻辑覆盖７３最少测试用例倒数计算７７测试覆盖准则７７程序中的错误分类（Wowden）７７域测试（Domain Testing）７８划分分析的过程７８域测试与划分分析的比较７９符号测试７９路径分析８０程序插装（Program Instrumentation）８０程序变异（Program Mutation）８０第五节：BUG分析技术８１ BUG引入原因８１ BUG分析要考虑的问题８２ BUG修改后的分析８２ BUG分析技巧８３第六节：软件应用通用测试方法８５ WEB站点测试技术与方法８６软件测试环境配置方法８６日期时间相关应用的测试方法８６数据库应用测试方法（Microsoft SQL Server）８６第七节：其他测试技术和方法８７文档测试８７语言测试８７软件安全性测试８７第八节：测试技术和方法的应用原则与技巧８７应用原则８８第四章：软件测试类型８８前言８８第一节：单元测试８９第二节：集成测试９１集成测试的概述９１集成测试的策略和方法９３联想软件的集成测试工作９７第三节：确认测试１０２确认测试概述１０２确认测试策略与方法１０４确认测试设计方法１０４确认测试的其他有关内容１１３第四节：系统测试１１５系统测试概述１１５系统测试内容１１６系统测试的技术与工具应用１１９第五节：验收测试１１９第六节：封样测试１２０封样测试概述１２０封样测试过程１２１封样测试注意事项１２３第八节：特殊测试类型１２３回归测试１２３用户反馈测试１２７第五章：软件测试经验与策略１２８第一节：到底什么时候开始软件测试工作？１２８第二节：测试资源不充分的测试策略１２９第三节：如何应对没有文档化的需求１３０第四节：影响测试工作量的因素１３０附件01：软件测试术语定义１３２附件02：SEI/CMM 所提议的软件评估与测试KPA １３７介绍１３７软件评估与测试的定义１３７把验证和测试作为一个独立的KPA的理由１３９加速软件文化的转变１３９评估与测试在项目跟踪方面的作用１４１评估与测试占项目花费中的比例１４２评估于测试对项目开发进度和项目花费方面的影响１４２缺陷的花费１４３评估与测试KPA的内容：１４４建议的评估/测试KPA １４４目标：１４４执行的委托１４４执行的能力１４６执行的活动１４７测量和分析１５２验证实施：１５２与现有CMM的KPA相协调１５３把软件评估和测试KPA融于整个CMM之中１５３重新组织现有KPA的建议１５４附件03：WEB站点应用测试技术与方法１５５ WEB站点应用测试基础知识１５５ HTML １５５ WEB页面错误提示释义１５６ IE浏览器１５６ ASP １５７ IIS １５７服务器性能１５７ WEB站点应用测试原则１５８ WEB站点应用测试标准１６０ WEB站点应用测试细则１６７ WEB页面测试１６７多用户测试：１７０性能测试１７０压力测试１７０ WEB事务处理能力测试１７０ WEB安全测试：１７１产品交互测试１７１产品输入/输出测试１７１ WEB站点应用测试的BUG分析１７２链接１７２ ASP １７２关于本文档：１７３附件１７４附件1：ASP常见问题１７４附件2 ASP错误一览表１７８附件3 ：IE5.0快捷键１８５附件4 ：Jscript错误及相应解释１８７附件5：VBScript错误代码及对应解释１８９附件6：HTML状态代码及含义１９３附件04：软件测试环境配置方法１９６测试环境配置步骤１９６测试环境配置的原则１９８配置主测试环境遵循原则：１９８配置辅测试环境遵循原则１９８测试环境配置缺陷分析和修改１９８附件一：电子教室测试环境配置方法１９９附件二：B/S结构产品测试环境配置方法２０２附件05：日期时间相关应用的测试方法２０７日期时间应用标准２０７ 1、日期和时间的格式２０７ 2、日期和时间的输入２０７ 3、日期和时间的存储２１０ 4、日期和时间的逻辑２１１日期时间与质量特性２１１功能性２１１可靠性２１２易用性２１２效率２１２可维护性和可移植性２１２日期时间与测试环境配置２１３日期时间一些具体应用情况与测试方法２１３附件06：数据库应用测试方法２１５前言：２１５四、SQLServer测试方法２１６ 4.1数据库应用安装测试、安全性测试及软件结构测试２１６ 4.2数据库应用性能测试２２１附件２２３附件07：测试说明同行评审２２５测试说明检查内容２２５测试说明同行评审注意问题２２７附件08：面向对象软件的测试２２８面向对象测试模型（Object-Orient Test Model）２２９面向对象分析的测试（OOA Test）２３０面向对象设计的测试（OOD Test）２３３面向对象编程的测试（OOP Test）２３５面向对象的单元测试（OO Unit Test）２３６面向对象的集成测试（OO Integrate Test）２３８面向对象的系统测试（OO System Test）２３９附件9：语言测试２４１语言翻译问题２４１外国语言测试要考虑的因素２４１ 1、文本扩展２４２ 2、 ASCII、DBCS和Unicode ２４２ 3、热键和快捷键２４３ 4、扩展字符２４３ 5、字符计算２４３ 6、阅读方向２４４ 7、图片中的文字２４４ 8、文字脱离代码２４４ 9、本地化测试２４４使用环境和兼容性问题２４５附件10：文档测试２４６软件文档包括的内容２４６文档测试标准２４７文档测试方法２４８文档测试原则２４８文档测试细则２４９文档测试要考虑的因素２５０附件11：软件安全性测试２５１安全性测试概述２５１安全性测试要考虑的问题２５１两个常见到安全性错误２５１安全性测试设计２５２安全性测试其他问题２５５软件的安全目标２５５缓冲区溢出２５６软件安装安全性测试２５６十条安全法则２５６前言目前，越来越多的软件组织开始重视软件测试工作，联想软件设计中心更是如此。因为大家都已意识到：软件测试在开发过程中的作用越来越重要，而且软件测试本身就是一门学科，测试人员的技术和经验水平会直接影响软件产品质量和用户满意度。不过，仍有很多人对软件测试不以为然，觉得“就是那么回事儿”，在开发过程中并不重要，而且技术含量不高。那么希望本书的介绍会使这些人改变这种态度。此篇只是介绍性讲述软件测试的大致情况，如果您对软件危机和软件测试发展有简单的了解，可以跳过此章。为了更好的了解软件测试，首先让我们来回顾一下软件危机及软件测试的发展。计算机硬件的飞速发展和普及，促使软件产品能应用和普及到社会的各个领域，软件产品的质量状况也理所当然成为大家共同关注的焦点之一。不论软件的开发/销售组织还是软件的使用者，为了在日趋激烈的竞争环境中生存，为了使自己的软件占有市场，必须把软件质量作为企业的重要目标之一，以避免被竞争对手淘汰出局。用户为了保证自己业务的顺利完成，当然希望选用优质实用的软件。质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅度增加，还可能会产生其他的责任风险，造成公司信誉和品牌形象的下降，继而影响软件组织的发展前途甚至是生存。软件危机曾经是软件界甚至整个IT业最热门的话题。为了解决这场危机，软件管理者、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况，那就是软件中有缺陷，正是这些缺陷导致了软件开发在成本、进度和质量上的失去控制和平衡。大家已经意识到，软件中存在缺陷是不可避免的，问题在于我们如何去尽量避免缺陷的产生和消除已经被发现的缺陷，使程序中的缺陷密度达到尽可能低的程度，降低软件的质量风险。很多人曾经认为更好的程序语言可以解决软件缺陷的困扰，这就一度推动了程序设计语言的发展，更多的语言开始流行：结构化程序设计语言、面向对象的程序设计语言、形式化描述语言、可视化工具…… 程序语言对提高软件生产效率起到了一定的积极作用，但它对整个软件质量尤其是可靠性的影响还是比较小的。受到其他行业项目工程化的启发，软件工程学出现了，软件开发被视为一项工程，以工程化的方法来进行规划和管理软件的开发。针对需求不确定的应用，可以使用目前很流行的迭代开发模型，还可以采用快速应用程序开发（RAD）和协同应用程序开发（JAD）技术；IBM的Dr.Harlan Mills提出了净室过程，净室过程组合了形式化程序验证和统计过程控制（SPC），它是一种相当新的软件开发方法，特别是要求SPC应用到软件的知识，这影响了其被广泛的接受；硬件成本持续降低，可支持CASE工具运行的新的强大的工作站和网络已经成为软件工程使用的工作平台，CASE工具可完成一些特定的软件开发过程。这些工具易于维护、易于交叉检查、易于理解。许多人相信CASE工具是解决软件危机的“拯救者”，但事实上我们看到的情形却是许多公司花了大量的金钱买回CASE工具，但很少使用，原因在于这些工具执行的过程并不适用于机构的软件开发过程。虽然软件新技术和新工具层出不穷，但一直没有解决软件开发过程的成熟性问题，即软件工程能力需要增强，其核心在于“管理”，因此人们将目标转向了管理的改善，一些以改进软件开发过程为目标的活动已经展示出积极的结果。可喜的是，联想软件设计中心的软件开发过程采用目前非常流行的基于SW-CMM1.1的过程改进方法（CBA-IPI），通过了CMM２和CMM3的认证，并正逐步把研发管理水平提高到CMM5水平，软件工程水平已经走在了国内软件企业的前列。联想软件建立了专门的过程改进和质量管理部门，出台了一系列过程改进方针，软件研发规范不断推陈出新，使软件开发过程越来越成熟和规范。但事实上，对于软件来讲，不论采用什么技术和什么方法，软件中仍然会有缺陷。采用新的语言、先进的开发方式、完善的开发过程，可以大大减少缺陷的引入，但是绝不可能完全杜绝软件中的缺陷，这些缺陷需要在测试阶段来发现并改正，而对软件质量的评估也需要通过分析测试结果得出。“亡羊补牢，犹未为晚”，既然“亡羊”不可避免，那么“补牢”就是非常关键的措施；“补牢”实施得越好，“亡羊”的数量就会大大减少。软件测试是所有软件工程学科的基本组成单元，是软件开发的重要阶段。统计表明（外部资料得到的数据），在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40％以上。而在软件开发的总成本中，用在测试上的开销要占30％到50％。如果把维护阶段也考虑在内，讨论整个软件生存期时，测试的成本比例也许会有所降低，但实际上维护工作相当于二次开发，乃至多次开发，其中必定还包含有许多测试工作。因此，测试对于软件开发来说是不可替代的，问题是我们应该思考“采用什么方法、如何安排测试？”——本书就要回答这些问题。很多人认为，软件测试是比较容易的工作。的确，很多软件开发公司雇佣了能力较低或是非专业的技术人员做软件测试工作，这是不争而令人遗憾的事实。但是，从联想软件测试中心四年来的实践证明，如果测试人员的能力和技术水平很低时，测试阶段投入的工作量往往得不到预期的效果，即投入的工作量越多，对项目的负面影响越大——既加大了项目投入，又影响了项目进度，但软件质量提升却不大；而只有测试人员的技术能力达到一定水平后，测试投入对项目的积极效果会显著增加。（见下图）图0-1，测试资源投入参考图从项目花费角度来看，在项目工作引入和加强测试，会大大减少项目后期的维护费用，这里有一个公式已经为软件业所公认： C3>C1+C2 其中： C3＝没有执行软件测试活动的维护花费； C1=软件测试活动的维护花费； C2=软件测试没有发现缺陷的维护花费。由此可见，缺少了测试活动，虽然会减少项目前期的费用和投入，但对于联想软件的后期维护和长期发展是有百害而无一利的。联想软件设计中心对软件测试工作非常重视，无论是从资源投入还是测试流程规范推广上，都为软件测试工作提供了很大的支持，使得软件测试队伍成长愈来愈快，规模愈来愈大，并且朝着健康方向不断前进。另外，联想软件测试中心做为一个独立测试机构，这种独立测试机构设置有许多好处。由于心理学上等因素的影响，软件开发者很难以客观、准确地测试自己的软件，而找出那些因为对问题的误解而产生的缺陷就更加困难。测试中心作为一个独立的行政组织与核算中心，可以避免软件开发者测试自己开发的软件或者软件开发机构测试自己的软件，这样就能够更有效地发现软件中的缺陷。还有，软件产品的开发过程受到进度、成本和质量三者的制约，进度和成本指标易于度量，而质量却很难量化度量，因此，在软件开发过程中，当进度、成本和质量三者发生矛盾时，质量最容易被忽视，如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试质量大大降低。由于测试中心做为一个独立组织平台这种方式，无论在技术上还是管理上，对提高软件测试质量和软件质量都有着积极的意义，具体说来，包括以下方面： a) 资源保证性。测试中心的主要任务是进行独立测试工作，这使得测试工作在费用、人力投入和计划实施方面更有保证，不会因为开发工作量的增加而减少对测试的投入，降低测试阶段的作用，可以避免开发部门“重开发，轻测试”这种心态对测试工作产生不利的影响。 b) 工作客观性。测试人员能够对软件中的缺陷抱着客观的心态，这种心态可以解决测试中的心理学问题。这样，既能够进一步发现软件中更多的缺陷，又能不受发现的缺陷状况的影响。而经济上的独立性使测试工作有更充分的资源和条件，能够按测试计划和流程来完成。 c) 技术专业性。测试人员把测试工作本身作为自己本职工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行测试实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效度的必然途径。 d) 结果可信性。由于专业优势，独立测试工作形成的测试结果更具信服力，对软件质量的估计更科学。而且，测试结果常常和对软件的质量评价联系在一起，通过专业化的测试中心的评价，结果会更客观、公正和具有权威性。软件测试中心不断发展壮大的同时，也带来了越来越多的挑战和压力。例如：如果更好地分配资源？如果组织测试实施，才能取得最大化的效度，降低软件质量风险？如何进一步提高测试人员的技术水平？如果进一步扩大测试在整个研发过程的作用？…… 以上所有问题的解决不能单靠本书来解决，而需要整个测试工作的持续改进才能逐渐来解决，需要测试中心每位员工的努力和支持。所以，希望本书在尽可能为软件测试同仁提供技术与经验参考的同时，能通过本书起到“抛砖引玉”的作用，把测试工作进一步引入到健康快速发展的轨道，并推动国内的软件测试水平能迅速地提升。当然，本书主要描述内容为联想软件测试中的测试技术与经验的积累，所以对于联想内部员工帮助会更大一些。第一章：软件测试概述本篇介绍了软件测试基础方面的知识，是软件测试工作入门的基础。通过本篇的学习，可以使读者了解软件测试的含义，加深对软件测试的理解和认识，同时对联想软件设计中心的测试工作有个概要性的了解和认识。本章对于软件测试新员工和非专业测试人员非常重要，主要帮助大家了解和认识软件测试工作。其中最重要的部分如下： Ø 软件测试的目的； Ø 对软件测试的理解； Ø 软件测试的原则； Ø 测试用例介绍； Ø 软件测试流程概述。编程大师说：“任何一个程序，无论它多么小，总存在着错误。” 初学者不相信大师的话，他问：“如果一个程序小得只执行一个简单的功能，那会怎样？” “这样的一个程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生一个错误。” 但初学者不满足，他问：“如果操作系统不失效，那么会怎样？” “没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生一个错误。” 初学者仍不满足，再问：“如果硬件不失效，那么会怎样？” 大师长叹一声道：“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是一个错误。” 没有错误的程序世间难求。[James 1999] 医生可以把他的错误埋葬在地下了事，但开发人员却不能——而我们测试人员需要尽量把软件中的缺陷统统都“挖”出来。第一节：什么是软件测试目前，业界对软件测试看法不尽相同，甚至对软件测试的定义也不完全一致。其中比较公认的定义有以下三个。广义的软件测试定义是：贯穿在整个开发各阶段的复查、评估与检验活动，这远远超出了程序测试的范围，可以统称为确认、验证与测试活动（V，V&T——Validation, Verification and Testing）。而狭义的测试定义为：软件测试是为了发现错误而执行程序的过程。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程。 IEEE在1983年定义是：使用人工或自动手段来进行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。“软件测试以检验是否满足需求为目标”。我们不必追究到底哪个定义更正确、更科学，但我们至少可以得出以下结论： ² 软件测试要发现软件的错误； ² 软件测试最终要以软件满足用户需求为目标。对于联想软件设计中心的测试活动，主要指的是狭义的测试（以下都称为测试或软件测试），而确认和验证活动在其他软件工程活动中被定义和执行，并且一般也要有测试人员的参与。软件测试是软件开发的一部分。在各种软件开发生命周期中，都定义了软件测试阶段。在瀑布模型中，软件测试是在编码结束之后的重要阶段；在螺旋模型、快速原型等其他模型中，软件测试仍具有不可取待的位置。从广义来讲，软件测试人员也属于软件开发人员，只是我们会在实际工作中为了把测试人员与设计编码人员相区分，而把测试人员在称谓上从开发人员中分离开来，本书亦是如此。第二节：软件测试的目的谈到软件测试的目的，很多人会认为是为了证明软件是没有问题的。最初的软件测试的确是为了证明程序的正确性，但这只能在有限情况下证明程序的正确性，对于我们今天的软件规模和开发环境来讲，证明程序的正确性实际上是不可能的。所以，测试人员不可能在测试报告中描述：“经过我的测试，该程序是没有问题的！”其他人员也不要希望测试人员来担保程序或软件产品是完全正确的。软件测试最直接的目的是——发现软件中的缺陷，包括需求、设计方面的缺陷和程序中包含的BUG。这里缺陷是一种泛称，它可以指软件功能的错误，也可以指性能低下，易用性差以及其他软件工作产品中的缺陷等等。测试人员总是先假设程序中存在缺陷，再通过执行测试活动来发现并最终改正缺陷。理解测试的目的是个很重要的意识问题。如果说测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而会下意识地选用一些不易暴露错误的测试示例——这样的测试是虚假的，没有意义的。软件测试最终的目的是：检查软件是否满足用户的需求，其中包括用户的隐含需求和潜在需求。只有满足用户需求的软件才能成为“好”的软件产品，才能得到用户一致的满意和认可。 Glen Myers曾提出关于测试目标的规则： 1、测试是一个为了寻找错误而运行程序的过程。 2、一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。 3、一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。以上三条规则表明了两种涵义：其一是软件测试的直接目的，即发现软件中的错误；其二为测试工作的职责就是一定要发现软件中的错误。发现软件中的错误和检查软件是否满足用户的需求这两点，都是我们做软件测试工作的目的，但是否就局限如此呢？当然不是。测试工作要讲究工作效率，那么就需要我们尽早地和不断地进行测试。愈早发现缺陷，愈能降低软件质量风险，减少修复缺陷的花费；测试工作愈充分，则软件中的“虫子”会愈少，软件质量会愈高，软件维护费用也会愈少。所以，测试一定要尽早和充分。测试工作也要讲究效果，那么就需要我们尽量要把较为严重的缺陷更早地提出，包括严重影响软件质量、改动工作量大或编码实现技术风险大的缺陷。这样既能降低软件质量风险，又能保证软件开发进度。测试工作还不止如此，测试人员不仅仅是要找出软件中的缺陷，更重要的是要能对缺陷进行分析，尽量找出缺陷产生原因和引入阶段，并对软件产品质量进行评价。这一点具有非常重要的意义，也是容易被人忽略的软件测试目的：测试要帮助发现当前工作产品中的缺陷原因和引入阶段，并对软件产品质量进行定量评价，以便进行改进。通过分析缺陷的原因，开发人员可以尽快对缺陷进行改正。同时，这种分析也能帮助我们推理出与所分析的缺陷有关联的潜在错误（表现为我们常说的测试矩阵），从而使测试的针对性更加有效。通过分析缺陷引入的阶段，我们可以判断从缺陷的产生到缺陷的发现，跨越了多少个发阶段。一个缺陷能够超越本开发阶段而不被发现，就指明了该开发阶段的确认或验证工作（包括评审、同行评审或产品的检查）本身就有问题，从而也不难有针对性地制定出具体的加强措施与改进办法，这也是软件过程改进的一项重要内容。如果能做到在同一开发阶段发现并及时改正缺陷，那么我们就可以预期这是一个高质量的软件产品和一个低成本、高效率的软件开发过程。有些项目经理在做项目定义和策划时，希望以尽快的速度把测试之前的所有开发工作完成，并早日开始测试，这样测试时间会很长，也就能达到快速和高质量的目的。可实际的效果呢？当然是“欲速不达”。道理很简单：开发时间越仓促，则开发阶段引入的缺陷就愈多，等测试阶段发现这些缺陷时，唯一的结果就是更大量的用于修复缺陷和工作产品变更的项目花费！因此，正确分析与利用测试的结果，可以非常有效地帮助软件过程进行改进和软件质量的提高。第三节：对软件测试的理解从软件测试的定义，我们知道了什么是软件测试；从软件测试的目的看，软件测试意义之深远。而测试的道理并不深奥，计算机专业人员都应该明白，但就是这么简单的事，计算机专业的博士们都可能会不知道？！而且，大家对软件测试的看法都不尽相同，不同的角色、不同的文化环境使很多人对软件测试产生争议。在此，我们共同来进行探讨几个问题。 1. 需求－设计－编码－测试，软件测试工作在编码完成后才开始。实际上，软件测试要贯穿整个软件产品生命周期。一方面，软件测试实施前有测试计划、测试用例的设计和实现等，而且其效果直接会影响后期测试实施的效率和效度。因此，早在项目立项和策划阶段，软件测试工作就应该开始了。另一方面，软件测试越早进行越好，因为BUG越早发现，BUG造成的影响和修改的代价就越小。而且，软件测试工作不仅仅针对程序，还包括对软件的需求、设计等等进行同行评审和评审（这些也属于广义上的测试范畴）。 2. 软件测试能否确保软件质量？这一点至今仍存在争议，因为很多人把测试人员和质量保证人员（QA）等同起来，但是从软件测试目的来讲的确没有说明软件测试能确保软件质量。我们目前的理解为：软件测试本身不能确保软件质量，但它却是保证软件质量的重要而关键的技术手段，因为软件经过测试后，质量一般都会得以上升。测试不等同于QA 3. 软件发布后出现了质量问题，这是测试人员的责任。软件发布后出现了问题，尤其是遭到用户的抱怨或投诉，测试人员一般都要有一定的责任，但是软件测试并不能100%地发现软件所有的缺陷，即使是测试投入了充分的资源。“高质量的软件是开发出来的，并不是测出来的”。 4. 软件测试工作到底难不难？回答这个问题之前，我们看看现实情况：绝大多数公司的测试人员都要比开发人员技术水平要差；有些测试人员甚至只具有简单的计算机基础，有些编码人员技术水平较低，所以可能会转为测试人员――其实这些事实既是无可奈何，又是无可厚非的。一方面，很多具体测试实施工作并不需要有很高的技术知识，他们只需严格执行测试计划，执行测试用例，记录测试结果就可以了；另一方面，测试用例的设计与开发、测试工作的管理都需要测试人员具有深厚的技术功底和丰富的测试经验，从这一点上讲，测试效果和软件质量是与测试人员的技术经验水平成正比的。另外，测试人员在测试工作中要及时有效地进行缺陷分析，这一点对项目的益处是不言而喻的，而缺陷分析工作来源于测试人员的缺陷分析技术。所以说，高质量的软件测试工作是很难的。 5. 软件测试工作是否也像设计工作那样具有开拓性和创新性？软件测试工作并不是简单地运行程序和执行测试用例，发现程序中的BUG了事。很多测试工作都需要测试人员的技术能力，需要测试人员的技术开拓性和创新性： ü 设计和开发大量优秀的测试用例； ü 分析和把握用户的需求，制定出高“性价比”的测试策略； ü 切实可行的测试计划和BUG跟踪； ü 不断学习和发明测试新技术和方法。看看吧，谁还能说软件测试工作不具有开拓性和创新性呢？ 6. 软件测试对于软件开发是建设性的，还是摧毁性的？测试相对设计和编码阶段的审查和评审工作来说，是一种“事后诸葛”，不断提交的大量而较为严重的缺陷会令开发人员讨厌或心烦，甚至会使项目进度处于尴尬的局面；一遍又一遍的回归测试和新的BUG列表，会一次又一次地摧毁开发人员的信心和管理者对软件质量的信心。当最后总结才发现――都是“测试惹的祸”！？真的是这样吗？当然不是，软件测试导致项目成本大量的增加，但暴露出的是项目开发阶段工作的不足，这样有利于及时认识到哪些工作需要改进和调整；测试工作毕竟是使软件质量逐渐得以提高，缺陷愈来愈少。所以，软件测试对于软件开发是非常有建设性的。 7. 软件测试是测试人员的事，与开发人员无关。为了减少相互影响，一般要求开发和测试相对独立，但这只是分工上的不同。开发和测试是软件项目相辅相成的两个过程，人员之间的交流、协作和配合是提高整体效率的重要因素。而且，在实际操作中，开发人员也会有一些测试工作，比如软件设计中心的单元测试就是由开发人员完成的。 8. 软件测试与调试工作类似？很多开发人员会把自己的调试工作认为就是测试，认为是自己在测试自己的程序，而且觉得测试与调试本身也没什么差别。其实软件测试与调试是完全不同的工作，我们来比较一下： ² 目的：软件测试的目的是尽可能多地发现程序中的错误，而调试的目的是确定错误的原因和位置，并改正错误，调试也被称为纠错。 ² 工作性质：测试是测试人员针对被测软件产品执行的检查和确认，它属于测试范畴；而调试是开发人员在测试发现程序中BUG后开始的发现和改正BUG的工作，它属于开发范畴。 ² 内容与方法：测试是计划执行的，需要测试计划、设计开发、测试执行和测试评估几个阶段；而调试只是针对程序中BUG的开发工作，是“BUG驱动”类型的工作。通过以上这些观点的探讨，相信大家原来对测试的误解会逐渐消失的。如果大家仍未完全理解，那么不要紧，请大家看完本书后，再重新思考以上几个问题，你会发现这几个问题有多么的简单！但是，请不要因为误解而人为地造成软件开发和测试之间的隔阂，使项目开发和测试工作无端受到影响。第四节：软件测试的原则任何工作都是讲究原则的，软件测试工作更是如此，而且因为软件测试工作的特殊性（目的是为了发现错误），其原则可谓很多，下面我们通过两方面来分别理解。测试技术和策略方面 Ø 测试工作要尽可能地找出关键性的错误。因为这些错误很可能会限制用户使用此软件产品完成工作的能力，从而会直接影响客户对质量的评价。在实际测试过程中，可以应用ALAC测试理念和用户剖面的分析方法，具体见《第三章：软件测试技术和方法》。 Ø 把Pareto原则应用于软件测试。因为测试中的也有群集现象，也适用于Pareto原则。事实证明：一段程序中存在的错误数与其中已发现的错误数是成正比的。一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。 Ø 100%测试覆盖率。只有达到100%测试覆盖率才能最大程度地降低软件质量风险，这就要求我们实际测试过程中设计的测试用例要100%地执行。 Ø 所有的测试都应追溯到用户需求。软件测试的最终目的就是验证软件是否满足用户需求，所以测试工作要以用户需求为根本出发点，以用户实际应用环境为判断依据。 Ø 应当尽早地和不断地进行软件测试。尽早地测试可以保证项目开发进度，减少项目开销；不断地进行测试可以使测试更充分，可以更多、更有效地发现软件中的缺陷。 Ø 总假定程序是有错误的。这一原则非常有效，它涉及到人的心理问题。因为只有抱着“程序有错”的心理细心、全面，才能更精心地设计出测试用例，才能发现更多的缺陷；否则，测试人员想当然地认为程序没有问题，那么主观心理必然会使他的测试不充分。 Ø 彻底检查和仔细分析每一个测试结果。软件测试过程中，测试人员有时会忽略了对测试结果进行检查和分析。不彻底检查会使某些“隐藏”的BUG没有被发现，不仔细分析会使开发人员很难对BUG进行定位和修复。 Ø 不断提高测试策略和技巧。测试策略和技巧包含很多方面。例如：测试一般讲究从“小规模”开始，逐步转向“大规模”；穷举测试是不可能的，所以要采用科学的方法和根据用户实际使用情况综合分析测试内容和步骤；测试用例的设计与选择既要尽可能发现程序错误，又要满足测试策略。测试管理方面 Ø 测试必须是有计划、有组织、有准备的。其中包括：确定测试任务、时间、人员职责及分工、资源设备、方法与工具、测试输入和输出准则等。 Ø 严格执行测试计划并及时进行修订。严格执行测试计划，意味着要严格遵守测试的工作时间表及具体安排，排除测试的随意性，如果实际情况发生了变更，则要及时对测试计划进行修订。这样测试计划才能更好地达到测试测试管理的目的。 Ø 有效的BUG跟踪和管理。建立BUG管理流程，使软件中的BUG能够按统一标准和流程得到解决。另外，测试人员要对BUG坚决进行跟踪和监控，使软件质量能够得到保证和控制，为项目管理人员提供量化的软件质量状态。 Ø 由独立的第三方来完成测试工作。尤其是确认测试和系统测试，要有独立的测试机构进行测试，以达到更好的测试效果。对于单元测试经常是有开发人员自己完成，但是开发人员要避免测试自己开发的程序。另外，为了保证测试工作高效执行，需要很好的团队交流机制，以及快速的反应和反馈能力。 “好”的测试的一些属性到底什么样的测试才算是好的测试呢？一般公认至少具有如下属性： ü 一个好的测试发现错误的可能性很高。 ü 一个好的测试并不冗于。 ü 一个好的测试应该是“最佳品种”。 ü 一个好的测试即不会太简单、也不会太复杂。 ü 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。总的来说，就是保证测试的有效性和测试的恰到好处。第五节：测试用例介绍测试用例

展开阅读全文