联想软件测试理论与实践 毕业论文.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站点应用测试基础知识htmlweb页面错误提示释义ie浏览器aspiis服务器性能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-orienttestmodel）面向对象分析的测试（ooatest）面向对象设计的测试（oodtest）面向对象编程的测试（ooptest）面向对象的单元测试（oounittest）面向对象的集成测试（oointegratetest）面向对象的系统测试（oosystemtest）附件9：语言测试语言翻译问题外国语言测试要考虑的因素1、文本扩展2、ascii、dbcs和unicode3、热键和快捷键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，测试资源投入参考图从项目花费角度来看，在项目工作引入和加强测试，会大大减少项目后期的维护费用，这里有一个公式已经为软件业所公认：c3c1+c2其中：c3没有执行软件测试活动的维护花费； c1=软件测试活动的维护花费；c2=软件测试没有发现缺陷的维护花费。由此可见，缺少了测试活动，虽然会减少项目前期的费用和投入，但对于联想软件的后期维护和长期发展是有百害而无一利的。联想软件设计中心对软件测试工作非常重视，无论是从资源投入还是测试流程规范推广上，都为软件测试工作提供了很大的支持，使得软件测试队伍成长愈来愈快，规模愈来愈大，并且朝着健康方向不断前进。另外，联想软件测试中心做为一个独立测试机构，这种独立测试机构设置有许多好处。由于心理学上等因素的影响，软件开发者很难以客观、准确地测试自己的软件，而找出那些因为对问题的误解而产生的缺陷就更加困难。测试中心作为一个独立的行政组织与核算中心，可以避免软件开发者测试自己开发的软件或者软件开发机构测试自己的软件，这样就能够更有效地发现软件中的缺陷。还有，软件产品的开发过程受到进度、成本和质量三者的制约，进度和成本指标易于度量，而质量却很难量化度量，因此，在软件开发过程中，当进度、成本和质量三者发生矛盾时，质量最容易被忽视，如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试质量大大降低。由于测试中心做为一个独立组织平台这种方式，无论在技术上还是管理上，对提高软件测试质量和软件质量都有着积极的意义，具体说来，包括以下方面：a) 资源保证性。测试中心的主要任务是进行独立测试工作，这使得测试工作在费用、人力投入和计划实施方面更有保证，不会因为开发工作量的增加而减少对测试的投入，降低测试阶段的作用，可以避免开发部门“重开发，轻测试”这种心态对测试工作产生不利的影响。b) 工作客观性。测试人员能够对软件中的缺陷抱着客观的心态，这种心态可以解决测试中的心理学问题。这样，既能够进一步发现软件中更多的缺陷，又能不受发现的缺陷状况的影响。而经济上的独立性使测试工作有更充分的资源和条件，能够按测试计划和流程来完成。c) 技术专业性。测试人员把测试工作本身作为自己本职工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行测试实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效度的必然途径。d) 结果可信性。由于专业优势，独立测试工作形成的测试结果更具信服力，对软件质量的估计更科学。而且，测试结果常常和对软件的质量评价联系在一起，通过专业化的测试中心的评价，结果会更客观、公正和具有权威性。软件测试中心不断发展壮大的同时，也带来了越来越多的挑战和压力。例如：如果更好地分配资源？如果组织测试实施，才能取得最大化的效度，降低软件质量风险？如何进一步提高测试人员的技术水平？如果进一步扩大测试在整个研发过程的作用？以上所有问题的解决不能单靠本书来解决，而需要整个测试工作的持续改进才能逐渐来解决，需要测试中心每位员工的努力和支持。所以，希望本书在尽可能为软件测试同仁提供技术与经验参考的同时，能通过本书起到“抛砖引玉”的作用，把测试工作进一步引入到健康快速发展的轨道，并推动国内的软件测试水平能迅速地提升。当然，本书主要描述内容为联想软件测试中的测试技术与经验的积累，所以对于联想内部员工帮助会更大一些。第一章：软件测试概述本篇介绍了软件测试基础方面的知识，是软件测试工作入门的基础。通过本篇的学习，可以使读者了解软件测试的含义，加深对软件测试的理解和认识，同时对联想软件设计中心的测试工作有个概要性的了解和认识。本章对于软件测试新员工和非专业测试人员非常重要，主要帮助大家了解和认识软件测试工作。其中最重要的部分如下： 软件测试的目的； 对软件测试的理解； 软件测试的原则； 测试用例介绍； 软件测试流程概述。编程大师说：“任何一个程序，无论它多么小，总存在着错误。”初学者不相信大师的话，他问：“如果一个程序小得只执行一个简单的功能，那会怎样？”“这样的一个程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生一个错误。”但初学者不满足，他问：“如果操作系统不失效，那么会怎样？”“没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生一个错误。”初学者仍不满足，再问：“如果硬件不失效，那么会怎样？”大师长叹一声道：“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是一个错误。”没有错误的程序世间难求。james 1999医生可以把他的错误埋葬在地下了事，但开发人员却不能而我们测试人员需要尽量把软件中的缺陷统统都“挖”出来。第一节：什么是软件测试目前，业界对软件测试看法不尽相同，甚至对软件测试的定义也不完全一致。其中比较公认的定义有以下三个。广义的软件测试定义是：贯穿在整个开发各阶段的复查、评估与检验活动，这远远超出了程序测试的范围，可以统称为确认、验证与测试活动（v，v&tvalidation, verification and testing）。而狭义的测试定义为：软件测试是为了发现错误而执行程序的过程。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程。ieee在1983年定义是：使用人工或自动手段来进行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。“软件测试以检验是否满足需求为目标”。我们不必追究到底哪个定义更正确、更科学，但我们至少可以得出以下结论： 软件测试要发现软件的错误； 软件测试最终要以软件满足用户需求为目标。对于联想软件设计中心的测试活动，主要指的是狭义的测试（以下都称为测试或软件测试），而确认和验证活动在其他软件工程活动中被定义和执行，并且一般也要有测试人员的参与。软件测试是软件开发的一部分。在各种软件开发生命周期中，都定义了软件测试阶段。在瀑布模型中，软件测试是在编码结束之后的重要阶段；在螺旋模型、快速原型等其他模型中，软件测试仍具有不可取待的位置。从广义来讲，软件测试人员也属于软件开发人员，只是我们会在实际工作中为了把测试人员与设计编码人员相区分，而把测试人员在称谓上从开发人员中分离开来，本书亦是如此。第二节：软件测试的目的谈到软件测试的目的，很多人会认为是为了证明软件是没有问题的。最初的软件测试的确是为了证明程序的正确性，但这只能在有限情况下证明程序的正确性，对于我们今天的软件规模和开发环境来讲，证明程序的正确性实际上是不可能的。所以，测试人员不可能在测试报告中描述：“经过我的测试，该程序是没有问题的！”其他人员也不要希望测试人员来担保程序或软件产品是完全正确的。软件测试最直接的目的是发现软件中的缺陷，包括需求、设计方面的缺陷和程序中包含的bug。这里缺陷是一种泛称，它可以指软件功能的错误，也可以指性能低下，易用性差以及其他软件工作产品中的缺陷等等。测试人员总是先假设程序中存在缺陷，再通过执行测试活动来发现并最终改正缺陷。理解测试的目的是个很重要的意识问题。如果说测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而会下意识地选用一些不易暴露错误的测试示例这样的测试是虚假的，没有意义的。软件测试最终的目的是：检查软件是否满足用户的需求，其中包括用户的隐含需求和潜在需求。只有满足用户需求的软件才能成为“好”的软件产品，才能得到用户一致的满意和认可。glen myers曾提出关于测试目标的规则：1、 测试是一个为了寻找错误而运行程序的过程。2、 一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。3、 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。以上三条规则表明了两种涵义：其一是软件测试的直接目的，即发现软件中的错误；其二为测试工作的职责就是一定要发现软件中的错误。发现软件中的错误和检查软件是否满足用户的需求这两点，都是我们做软件测试工作的目的，但是否就局限如此呢？当然不是。测试工作要讲究工作效率，那么就需要我们尽早地和不断地进行测试。愈早发现缺陷，愈能降低软件质量风险，减少修复缺陷的花费；测试工作愈充分，则软件中的“虫子”会愈少，软件质量会愈高，软件维护费用也会愈少。所以，测试一定要尽早和充分。测试工作也要讲究效果，那么就需要我们尽量要把较为严重的缺陷更早地提出，包括严重影响软件质量、改动工作量大或编码实现技术风险大的缺陷。这样既能降低软件质量风险，又能保证软件开发进度。测试工作还不止如此，测试人员不仅仅是要找出软件中的缺陷，更重要的是要能对缺陷进行分析，尽量找出缺陷产生原因和引入阶段，并对软件产品质量进行评价。这一点具有非常重要的意义，也是容易被人忽略的软件测试目的：测试要帮助发现当前工作产品中的缺陷原因和引入阶段，并对软件产品质量进行定量评价，以便进行改进。通过分析缺陷的原因，开发人员可以尽快对缺陷进行改正。同时，这种分析也能帮助我们推理出与所分析的缺陷有关联的潜在错误（表现为我们常说的测试矩阵），从而使测试的针对性更加有效。通过分析缺陷引入的阶段，我们可以判断从缺陷的产生到缺陷的发现，跨越了多少个发阶段。一个缺陷能够超越本开发阶段而不被发现，就指明了该开发阶段的确认或验证工作（包括评审、同行评审或产品的检查）本身就有问题，从而也不难有针对性地制定出具体的加强措施与改进办法，这也是软件过程改进的一项重要内容。如果能做到在同一开发阶段发现并及时改正缺陷，那么我们就可以预期这是一个高质量的软件产品和一个低成本、高效率的软件开发过程。有些项目经理在做项目定义和策划时，希望以尽快的速度把测试之前的所有开发工作完成，并早日开始测试，这样测试时间会很长，也就能达到快速和高质量的目的。可实际的效果呢？当然是“欲速不达”。道理很简单：开发时间越仓促，则开发阶段引入的缺陷就愈多，等测试阶段发现这些缺陷时，唯一的结果就是更大量的用于修复缺陷和工作产品变更的项目花费！因此，正确分析与利用测试的结果，可以非常有效地帮助软件过程进行改进和软件质量的提高。 第三节：对软件测试的理解从软件测试的定义，我们知道了什么是软件测试；从软件测试的目的看，软件测试意义之深远。而测试的道理并不深奥，计算机专业人员都应该明白，但就是这么简单的事，计算机专业的博士们都可能会不知道？！而且，大家对软件测试的看法都不尽相同，不同的角色、不同的文化环境使很多人对软件测试产生争议。在此，我们共同来进行探讨几个问题。1. 需求设计编码测试，软件测试工作在编码完成后才开始。实际上，软件测试要贯穿整个软件产品生命周期。一方面，软件测试实施前有测试计划、测试用例的设计和实现等，而且其效果直接会影响后期测试实施的效率和效度。因此，早在项目立项和策划阶段，软件测试工作就应该开始了。另一方面，软件测试越早进行越好，因为bug越早发现，bug造成的影响和修改的代价就越小。而且，软件测试工作不仅仅针对程序，还包括对软件的需求、设计等等进行同行评审和评审（这些也属于广义上的测试范畴）。2. 软件测试能否确保软件质量？这一点至今仍存在争议，因为很多人把测试人员和质量保证人员（qa）等同起来，但是从软件测试目的来讲的确没有说明软件测试能确保软件质量。我们目前的理解为：软件测试本身不能确保软件质量，但它却是保证软件质量的重要而关键的技术手段，因为软件经过测试后，质量一般都会得以上升。测试不等同于qa3. 软件发布后出现了质量问题，这是测试人员的责任。软件发布后出现了问题，尤其是遭到用户的抱怨或投诉，测试人员一般都要有一定的责任，但是软件测试并不能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坚决进行跟踪和监控，使软件质量能够得到保证和控制，为项目管理人员提供量化的软件质量状态。 由独立的第三方来完成测试工作。尤其是确认测试和系统测试，要有独立的测试机构进行测试，以达到更好的测试效果。对于单元测试经常是有开发人员自己完成，但是开发人员要避免测试自己开发的程序。另外，为了保证测试工作高效执行，需要很好的团队交流机制，以及快速的反应和反馈能力。“好”的测试的一些属性到底什么样的测试才算是好的测试呢？一般公认至少具有如下属性： 一个好的测试发现错误的可能性很高。 一个好的测试并不冗于。 一个好的测试应该是“最佳品种”。 一个好的测试即不会太简单、也不会太复杂。 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。总的来说，就是保证测试的有效性和测试的恰到好处。第五节：测试用例介绍测试用例是测试术语中最常见的词汇之一，其实测试用例还是容易理解，但是要设计开发出高质量的测试用例，就与测试人员的技术和经验水平有很大关系了。对测试用例的理解测试用例的定义有很多“版本”，我们这里就不一一列举出来让大家判断哪一个更科学，但我们可以从以下几方面进行理解： 测试用例是测试人员在测试执行过程中，向被测软件输入数据或执行测试操作所使用的实例。 测试用例由测试数据、测试操作、预期结果及环境设置等组成。 对于交互式系统，软件交互执行过程的控制和操作也是一种测试用例。 测试用例的设计与生成是验证软件需求的进一步实例化。测试用例设计生成的基本原则 测试用例的代表性。能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。 测试结果的可判定性。测试执行结果的正确性是可判定的，否则该测试用例是没有意义的。 测试结果的可再现性。即使是有些执行结果并不是每次再现，但一般来说，测试用例的设计与生成尽量要能够保证：对同样的测试用例再次执行，系统的执行结果应当是相同的。 测试用例的有效性。测试用例要设计为发现错误可能性大的输入数据或操作，这一点与测试人员的技术与经验有很大关系。 一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。这一点毋需多说。第六节：软件测试模型提供了三种测试模型：v、h、pdca软件测试模型在很多资料中都有介绍，但是具体分起来，不难发现各自模型强调的重点各不相同，这里先加以介绍，然后我们再结合联想软件设计中心实际情况来进行分析和总结。v模型v模型主要应用于项目的测试工作中，是联想软件测试中心一直在使用的测试模型，它强调了测试阶段与开发阶段的对应关系以及测试工作的及早准备和进行。以下为v模型示意图：v模型揭示了软件测试活动分层和分阶段的本质特性。如：集成测试对应概要设计，那么集成测试计划和集成测试说明文档的编写就可以在概要设计阶段就可以开始编写，只要在集成测试实施前完成即可。v模型还有一点意义：在需求分析阶段编写测试用例，可以发现需求文档本身的缺陷，这样就能尽早把需求的缺陷消除，避免使缺陷残留到下一个阶段中；在概要设计阶段编写集成测试用例也会间接地提高软件设计质量。有人曾提出w模型的概念，大家不要疑惑，其实就是我们的v模型，我们也不必去分析它们到底是什么区别。总之，v模型测试与传统瀑布模型相比，测试工作能更早的开始，并且与开发阶段的对应明显，使测试工作更有效、更科学。h模型上面的v模型从某种意义上讲，把软件的开发视为需求、设计、编码等一系列的串行活动。而事实上，虽然这些活动之间存在着相互牵制的关系，但在大部分时间里，它们是相互独立的，是可以并发进行的。虽然软件开发期望有清晰的需求、设计和编码等阶段，但实践告诉我们，严格的阶段之分只是一种理想情况。很多测试工作并没有严格的先后顺序，只要测试条件满足，就可以进行测试。各个不同层次之间的测试除了简单的时间上的先后关系外，还存在着触发、反复、迭代和增量关系。另外，v模型并没有表示出测试流程的完整性。测试流程大致分为两类活动，一类是测试准备活动，包括测试需求分析、测试计划、测试用例设计与实现、测试环境准备、培训学习等等，另一类是测试执行活动，包括测试实施、bug提交与验证等等。测试的两类工作h模型做为一个新的理念，包含了以上的不足。h模型具体见下图所示（看起来象放倒了的“h”）。这个示意图仅仅演示了在整个生产周期中，某个测试层次上的一次测试“微循环”。图中的“其它流程”可以是任意开发流程，例如设计流程和编码流程，也可以是其它非开发的流程，甚至是测试流程本身。向上的空心箭头表示，在某个时间点，由于“其它流程”的进展而（由于先后关系）引发或者（由于因果关系）触发了测试就绪点，这个时候，只要测试准备活动完成，测试执行活动就可以（或者说，需要）进行了。概括的说，h模型揭示了： 软件测试不仅仅指测试的执行，还包括很多其他的活动。 软件测试是一个独立的过程，贯穿产品整个周期，与其它流程并发的进行。 软件测试要尽早准备，尽早执行。 软件测试根据被测物的不同是分层次的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。由上可以看出，软件测试是一个独立的流程，贯穿于整个产品周期，与其它流程并发的进行，当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。h模型兼顾效率和灵活性，可以被应用各种规模、各种类型的软件项目上。那么，为什么要采用h模型呢？首先，h模型强调软件测试准备和测试执行分离。准备阶段和执行阶段有不同的测试活动，例如，测试准备活动，包括测试需求分析、测试计划、测试用例设计与编写等等。准备阶段和执行阶段有不同的工作侧重点，不同的测试活动也需要不同的知识和技能。这样的分离有利于进一步的分工。显而易见，测试的设计人员比执行人员有更高的能力要求，不同的岗位可以聘用不同的人员。如果一个测试设计人员同时被指派去执行测试，那既是人力资源的浪费，也可能挫伤设计人员的创造性和积极性。所以，软件测试分工带来的第一个直接好处就是降低人力成本，第二个直接好处就是提高效率。分工带来的间接的长期的好处是，软件测试可以称为一个有职业前景的职位，这有利于吸引人才以此作为自己的职业生涯，从而形成软件测试领域的人力积累和良性循环。采用h模型的第二个理由是，h模型可以促使人们充分认识到软件测试的复杂性。这儿的负责并不是指技术上的复杂（尽管软件测试在技术上也的确是复杂的），而是指过程上的复杂。正如传统的软件开发被简化为编程一样，软件测试也常常被简化为运行一下被测的软件，观察是否有异样的运行结果。软件测试也有不同的阶段，有不同的活动，而且这些阶段和活动要被组成一个系统才能有效的运作。没有组织的，非结构化的软件测试除了浪费时间和金钱外，几乎不可能有实质性的产出。认识到复杂性才可能得到足够的重视和必要的尊重。重视主要来自于管理层，而尊重则主要来自于平行的其它流程人员，例如编码人员。尽管测试流程是一个独立的流程，但它必须被置于整个软件生产的流程系统中，作为一个有机的组成部分，并与其它流程有效的交互，才可能发挥作用。第三个理由则与一个长期存在的“测试怪圈”有关。测试经理总是抱怨测试上的投入不够；测试人员要么被看做是“无所事事”，要么被看做“忙而无功”；而管理层则因为测试上的投入的流向，例如，在各个测试活动上的投入分别是多少，比例是否合理，哪些是用于测试准备的，而如果由于其它流程的差错导致重做准备，那浪费的投入有多少。在h模型中，测试是一个有组织的、结构化的独立流程，既保证了自身的有序和结构清晰，也保证了流程之间的“界面”清晰。这样，软件测试就不是一笔糊涂帐，才可能得到公正的投入产出的评判，软件测试才可能避免成为“出气筒”和“替罪羊”的“宿命”。总结一下，软件测试采用h模型的三个理由为：1、 有利于测试的分工，从而降低成本，提高效率；2、 有利于认识到测试的复杂性，从而赢得重视和尊重；3、 有利于了解测试投入的去处，从而得到测试利益的公正评判。shewwhart循环模型shewwhart循环模型即是通常所说的pdca模式或pdca循环模型，pdca循环是提高产品质量，改善企业经营管理的重要方法，是质量保证体系运转的基本方式。此模型本身并不是应用软件测试上，但却适用于软