联想软件测试理论与实践 毕业论文

联想软件测试理论与实践联想软件测试中心序联想软件测试理论与实践终于完成了，欣喜之余，回想起软件测试中心这几年在测试技术和流程管理方面取得的巨大进步，真是令人感到骄傲和自豪。当然，软件测试工作持续改进是我们永恒的目标，所以随着我们对软件测试理论认识和实践经验不断深化，本书也会陆续做一些修订和补充。本书主要是联想软件内部使用，为软件测试中心人员提供测试技术指导和测试实施指南，对测试新员工尤为适用。同时联想其他同仁也可阅读此书，以了解软件测试知识和我们实际工作情况。本书安排由浅入深，从软件基础开始讲解，重点讲解了软件测试技术、软件测试类型、软件测试管理等几方面，同时也对软件质量、测试持续改进、测试自动化也做了介绍。对于软件测试新员工，可以按顺序学习，对于有一定测试经验或对软件测试比较了解的同仁，则可以直接选择自己所关心的章节进行阅读和参考。另外，本书并没有提供很多测试实例，大家可以到软件测试中心的技术构架中去获取。由于本书遵从联想软件研发规范，遵从联想软件设计中心的过程改进方针。所以阅读本书前，需要大家对软件工程和联想软件研发规范有一定的了解。本书采用的术语与联想软件设计中心研发规范相一致，同时在很大程度上把软件测试工作描述得更为深刻，有些目标和标准甚至是我们目前还没有开展实施的，并包含了作者个人的一些观点，所以可能会有不科学、不实用之处，敬请各位同仁多多指正和包涵很多人为本书的编写虽然付出了很多时间和心血，但仍感觉完成得较为仓促，所以请大家在阅读本书的同时，多多提出宝贵的意见和建议，谢谢本书是在联想助理总裁联想软件设计中心总经理韩振江的关心下完成的，这里要向所有关心本书和关心软件测试工作的领导和同仁们道谢作者于年12月目录序目录前言第一章软件测试概述第一节什么是软件测试第二节软件测试的目的第三节对软件测试的理解第四节软件测试的原则测试技术和策略方面测试管理方面“好”的测试的一些属性第五节测试用例介绍对测试用例的理解测试用例设计生成的基本原则第六节软件测试模型V模型H模型SHEWWHART循环模型模型小结第七节确认和验证第八节软件测试流程概述软件开发流程概述软件测试流程概述测试工程师的职责第九节测试人员的素质要求测试人员的技术素质要求测试人员的非技术素质要求第十节如何做好软件测试工作第二章软件质量与测试第一节软件质量的重要性第二节软件质量问题的原因第三节对软件质量特性的理解软件质量内涵软件质量特性定义软件质量特性之间的关系软件质量的观点软件质量特性对于测试人员的意义第四节基于软件质量特性的测试功能性测试可靠性测试易用性测试兼容性测试第三章软件测试技术和方法第一节静态测试和动态测试静态测试动态测试第二节黑盒和白盒测试概述第三节黑盒测试技术等价类划分边值分析特殊数据分析因果图法第四节白盒测试技术白盒测试概述程序结构分析逻辑覆盖最少测试用例倒数计算测试覆盖准则程序中的错误分类（WOWDEN）域测试（DOMAINTESTING）划分分析的过程域测试与划分分析的比较符号测试路径分析程序插装（PROGRAMINSTRUMENTATION）程序变异（PROGRAMMUTATION）第五节BUG分析技术BUG引入原因BUG分析要考虑的问题BUG修改后的分析BUG分析技巧第六节软件应用通用测试方法WEB站点测试技术与方法软件测试环境配置方法日期时间相关应用的测试方法数据库应用测试方法（MICROSOFTSQLSERVER）第七节其他测试技术和方法文档测试语言测试软件安全性测试第八节测试技术和方法的应用原则与技巧应用原则第四章软件测试类型前言第一节单元测试第二节集成测试集成测试的概述集成测试的策略和方法联想软件的集成测试工作第三节确认测试确认测试概述确认测试策略与方法确认测试设计方法确认测试的其他有关内容第四节系统测试系统测试概述系统测试内容系统测试的技术与工具应用第五节验收测试第六节封样测试封样测试概述封样测试过程封样测试注意事项第八节特殊测试类型回归测试用户反馈测试第五章软件测试经验与策略第一节到底什么时候开始软件测试工作第二节测试资源不充分的测试策略第三节如何应对没有文档化的需求第四节影响测试工作量的因素附件01软件测试术语定义附件02SEI/CMM所提议的软件评估与测试KPA介绍软件评估与测试的定义把验证和测试作为一个独立的KPA的理由加速软件文化的转变评估与测试在项目跟踪方面的作用评估与测试占项目花费中的比例评估于测试对项目开发进度和项目花费方面的影响缺陷的花费评估与测试KPA的内容建议的评估/测试KPA目标执行的委托执行的能力执行的活动测量和分析验证实施与现有CMM的KPA相协调把软件评估和测试KPA融于整个CMM之中重新组织现有KPA的建议附件03WEB站点应用测试技术与方法WEB站点应用测试基础知识HTMLWEB页面错误提示释义IE浏览器ASPIIS服务器性能WEB站点应用测试原则WEB站点应用测试标准WEB站点应用测试细则WEB页面测试多用户测试性能测试压力测试WEB事务处理能力测试WEB安全测试产品交互测试产品输入/输出测试WEB站点应用测试的BUG分析链接ASP关于本文档附件附件1ASP常见问题附件2ASP错误一览表附件3IE50快捷键附件4JSCRIPT错误及相应解释附件5VBSCRIPT错误代码及对应解释附件6HTML状态代码及含义附件04软件测试环境配置方法测试环境配置步骤测试环境配置的原则配置主测试环境遵循原则配置辅测试环境遵循原则测试环境配置缺陷分析和修改附件一电子教室测试环境配置方法附件二B/S结构产品测试环境配置方法附件05日期时间相关应用的测试方法日期时间应用标准1、日期和时间的格式2、日期和时间的输入3、日期和时间的存储4、日期和时间的逻辑日期时间与质量特性功能性可靠性易用性效率可维护性和可移植性日期时间与测试环境配置日期时间一些具体应用情况与测试方法附件06数据库应用测试方法前言四、SQLSERVER测试方法41数据库应用安装测试、安全性测试及软件结构测试42数据库应用性能测试附件附件07测试说明同行评审测试说明检查内容测试说明同行评审注意问题附件08面向对象软件的测试面向对象测试模型（OBJECTORIENTTESTMODEL）面向对象分析的测试（OOATEST）面向对象设计的测试（OODTEST）面向对象编程的测试（OOPTEST）面向对象的单元测试（OOUNITTEST）面向对象的集成测试（OOINTEGRATETEST）面向对象的系统测试（OOSYSTEMTEST）附件9语言测试语言翻译问题外国语言测试要考虑的因素1、文本扩展2、ASCII、DBCS和UNICODE3、热键和快捷键4、扩展字符5、字符计算6、阅读方向7、图片中的文字8、文字脱离代码9、本地化测试使用环境和兼容性问题附件10文档测试软件文档包括的内容文档测试标准文档测试方法文档测试原则文档测试细则文档测试要考虑的因素附件11软件安全性测试安全性测试概述安全性测试要考虑的问题两个常见到安全性错误安全性测试设计安全性测试其他问题软件的安全目标缓冲区溢出软件安装安全性测试十条安全法则前言目前，越来越多的软件组织开始重视软件测试工作，联想软件设计中心更是如此。因为大家都已意识到软件测试在开发过程中的作用越来越重要，而且软件测试本身就是一门学科，测试人员的技术和经验水平会直接影响软件产品质量和用户满意度。不过，仍有很多人对软件测试不以为然，觉得“就是那么回事儿”，在开发过程中并不重要，而且技术含量不高。那么希望本书的介绍会使这些人改变这种态度。此篇只是介绍性讲述软件测试的大致情况，如果您对软件危机和软件测试发展有简单的了解，可以跳过此章。为了更好的了解软件测试，首先让我们来回顾一下软件危机及软件测试的发展。计算机硬件的飞速发展和普及，促使软件产品能应用和普及到社会的各个领域，软件产品的质量状况也理所当然成为大家共同关注的焦点之一。不论软件的开发/销售组织还是软件的使用者，为了在日趋激烈的竞争环境中生存，为了使自己的软件占有市场，必须把软件质量作为企业的重要目标之一，以避免被竞争对手淘汰出局。用户为了保证自己业务的顺利完成，当然希望选用优质实用的软件。质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅度增加，还可能会产生其他的责任风险，造成公司信誉和品牌形象的下降，继而影响软件组织的发展前途甚至是生存。软件危机曾经是软件界甚至整个IT业最热门的话题。为了解决这场危机，软件管理者、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况，那就是软件中有缺陷，正是这些缺陷导致了软件开发在成本、进度和质量上的失去控制和平衡。大家已经意识到，软件中存在缺陷是不可避免的，问题在于我们如何去尽量避免缺陷的产生和消除已经被发现的缺陷，使程序中的缺陷密度达到尽可能低的程度，降低软件的质量风险。很多人曾经认为更好的程序语言可以解决软件缺陷的困扰，这就一度推动了程序设计语言的发展，更多的语言开始流行结构化程序设计语言、面向对象的程序设计语言、形式化描述语言、可视化工具程序语言对提高软件生产效率起到了一定的积极作用，但它对整个软件质量尤其是可靠性的影响还是比较小的。受到其他行业项目工程化的启发，软件工程学出现了，软件开发被视为一项工程，以工程化的方法来进行规划和管理软件的开发。针对需求不确定的应用，可以使用目前很流行的迭代开发模型，还可以采用快速应用程序开发（RAD）和协同应用程序开发（JAD）技术；IBM的DRHARLANMILLS提出了净室过程，净室过程组合了形式化程序验证和统计过程控制（SPC），它是一种相当新的软件开发方法，特别是要求SPC应用到软件的知识，这影响了其被广泛的接受；硬件成本持续降低，可支持CASE工具运行的新的强大的工作站和网络已经成为软件工程使用的工作平台，CASE工具可完成一些特定的软件开发过程。这些工具易于维护、易于交叉检查、易于理解。许多人相信CASE工具是解决软件危机的“拯救者”，但事实上我们看到的情形却是许多公司花了大量的金钱买回CASE工具，但很少使用，原因在于这些工具执行的过程并不适用于机构的软件开发过程。虽然软件新技术和新工具层出不穷，但一直没有解决软件开发过程的成熟性问题，即软件工程能力需要增强，其核心在于“管理”，因此人们将目标转向了管理的改善，一些以改进软件开发过程为目标的活动已经展示出积极的结果。可喜的是，联想软件设计中心的软件开发过程采用目前非常流行的基于SWCMM11的过程改进方法（CBAIPI），通过了CMM和CMM3的认证，并正逐步把研发管理水平提高到CMM5水平，软件工程水平已经走在了国内软件企业的前列。联想软件建立了专门的过程改进和质量管理部门，出台了一系列过程改进方针，软件研发规范不断推陈出新，使软件开发过程越来越成熟和规范。但事实上，对于软件来讲，不论采用什么技术和什么方法，软件中仍然会有缺陷。采用新的语言、先进的开发方式、完善的开发过程，可以大大减少缺陷的引入，但是绝不可能完全杜绝软件中的缺陷，这些缺陷需要在测试阶段来发现并改正，而对软件质量的评估也需要通过分析测试结果得出。“亡羊补牢，犹未为晚”，既然“亡羊”不可避免，那么“补牢”就是非常关键的措施；“补牢”实施得越好，“亡羊”的数量就会大大减少。软件测试是所有软件工程学科的基本组成单元，是软件开发的重要阶段。统计表明（外部资料得到的数据），在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40以上。而在软件开发的总成本中，用在测试上的开销要占30到50。如果把维护阶段也考虑在内，讨论整个软件生存期时，测试的成本比例也许会有所降低，但实际上维护工作相当于二次开发，乃至多次开发，其中必定还包含有许多测试工作。因此，测试对于软件开发来说是不可替代的，问题是我们应该思考“采用什么方法、如何安排测试”本书就要回答这些问题。很多人认为，软件测试是比较容易的工作。的确，很多软件开发公司雇佣了能力较低或是非专业的技术人员做软件测试工作，这是不争而令人遗憾的事实。但是，从联想软件测试中心四年来的实践证明，如果测试人员的能力和技术水平很低时，测试阶段投入的工作量往往得不到预期的效果，即投入的工作量越多，对项目的负面影响越大既加大了项目投入，又影响了项目进度，但软件质量提升却不大；而只有测试人员的技术能力达到一定水平后，测试投入对项目的积极效果会显著增加。（见下图）123456测试投入量对项目的作用很低较低一般较高图01，测试资源投入参考图从项目花费角度来看，在项目工作引入和加强测试，会大大减少项目后期的维护费用，这里有一个公式已经为软件业所公认C3C1C2其中C3没有执行软件测试活动的维护花费；C1软件测试活动的维护花费；C2软件测试没有发现缺陷的维护花费。由此可见，缺少了测试活动，虽然会减少项目前期的费用和投入，但对于联想软件的后期维护和长期发展是有百害而无一利的。联想软件设计中心对软件测试工作非常重视，无论是从资源投入还是测试流程规范推广上，都为软件测试工作提供了很大的支持，使得软件测试队伍成长愈来愈快，规模愈来愈大，并且朝着健康方向不断前进。另外，联想软件测试中心做为一个独立测试机构，这种独立测试机构设置有许多好处。由于心理学上等因素的影响，软件开发者很难以客观、准确地测试自己的软件，而找出那些因为对问题的误解而产生的缺陷就更加困难。测试中心作为一个独立的行政组织与核算中心，可以避免软件开发者测试自己开发的软件或者软件开发机构测试自己的软件，这样就能够更有效地发现软件中的缺陷。还有，软件产品的开发过程受到进度、成本和质量三者的制约，进度和成本指标易于度量，而质量却很难量化度量，因此，在软件开发过程中，当进度、成本和质量三者发生矛盾时，质量最容易被忽视，如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试质量大大降低。由于测试中心做为一个独立组织平台这种方式，无论在技术上还是管理上，对提高软件测试质量和软件质量都有着积极的意义，具体说来，包括以下方面A资源保证性。测试中心的主要任务是进行独立测试工作，这使得测试工作在费用、人力投入和计划实施方面更有保证，不会因为开发工作量的增加而减少对测试的投入，降低测试阶段的作用，可以避免开发部门“重开发，轻测试”这种心态对测试工作产生不利的影响。B工作客观性。测试人员能够对软件中的缺陷抱着客观的心态，这种心态可以解决测试中的心理学问题。这样，既能够进一步发现软件中更多的缺陷，又能不受发现的缺陷状况的影响。而经济上的独立性使测试工作有更充分的资源和条件，能够按测试计划和流程来完成。C技术专业性。测试人员把测试工作本身作为自己本职工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行测试实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效度的必然途径。D结果可信性。由于专业优势，独立测试工作形成的测试结果更具信服力，对软件质量的估计更科学。而且，测试结果常常和对软件的质量评价联系在一起，通过专业化的测试中心的评价，结果会更客观、公正和具有权威性。软件测试中心不断发展壮大的同时，也带来了越来越多的挑战和压力。例如如果更好地分配资源如果组织测试实施，才能取得最大化的效度，降低软件质量风险如何进一步提高测试人员的技术水平如果进一步扩大测试在整个研发过程的作用以上所有问题的解决不能单靠本书来解决，而需要整个测试工作的持续改进才能逐渐来解决，需要测试中心每位员工的努力和支持。所以，希望本书在尽可能为软件测试同仁提供技术与经验参考的同时，能通过本书起到“抛砖引玉”的作用，把测试工作进一步引入到健康快速发展的轨道，并推动国内的软件测试水平能迅速地提升。当然，本书主要描述内容为联想软件测试中的测试技术与经验的积累，所以对于联想内部员工帮助会更大一些。第一章软件测试概述本篇介绍了软件测试基础方面的知识，是软件测试工作入门的基础。通过本篇的学习，可以使读者了解软件测试的含义，加深对软件测试的理解和认识，同时对联想软件设计中心的测试工作有个概要性的了解和认识。本章对于软件测试新员工和非专业测试人员非常重要，主要帮助大家了解和认识软件测试工作。其中最重要的部分如下软件测试的目的；对软件测试的理解；软件测试的原则；测试用例介绍；软件测试流程概述。编程大师说“任何一个程序，无论它多么小，总存在着错误。”初学者不相信大师的话，他问“如果一个程序小得只执行一个简单的功能，那会怎样”“这样的一个程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生一个错误。”但初学者不满足，他问“如果操作系统不失效，那么会怎样”“没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生一个错误。”初学者仍不满足，再问“如果硬件不失效，那么会怎样”大师长叹一声道“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是一个错误。”没有错误的程序世间难求。JAMES1999医生可以把他的错误埋葬在地下了事，但开发人员却不能而我们测试人员需要尽量把软件中的缺陷统统都“挖”出来。第一节什么是软件测试目前，业界对软件测试看法不尽相同，甚至对软件测试的定义也不完全一致。其中比较公认的定义有以下三个。广义的软件测试定义是贯穿在整个开发各阶段的复查、评估与检验活动，这远远超出了程序测试的范围，可以统称为确认、验证与测试活动（V，V2开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；3对每个模块群进行测试；4删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。从第一步开始循环执行上述各步骤，直至整个程序构造完毕。下图说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块MA，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与MA接口，这时可对MAD3被去掉后，M3与模块群3直接接口，可对MB进行集成测试，最后MA、MB和MC全部集成在一起进行测试。图43，自底向上集成自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。由上面的介绍可以看出，自顶向下测试的主要优点在于它可以自然地做到逐步求精，一开始便能让测试者看到系统的雏形。这个系统模型的检验有助于增强程序人员的信心，它的不足是一定要提供桩模块。并且在输入、输出模块接入系统以前，在桩模块中表示测试数据有一定困难。由于桩模块不能模拟数据，如果模块间的数据流不能构成有向的非环状图，一些模块的测试数据难于生成。同时观察和解释测试输出往往也是困难的。另一方面，自底向上测试的优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也没有困难。如果关键的模块是在结构图的底部，自底向上测试是有优越性的。自底向上方法的缺点在于，当最后一个模块尚未开始测试时，还没有呈现出被测软件系统的雏形。由于最后一层模块尚未设计完成时，无法开始测试工作，因而设计与测试工作不能交叉进行。其它集成样式大爆炸集成是通过少数测试运行检测整个系统来论证系统的稳定性。大爆炸集成将所有的模块集合在被测系统之中，而不考虑构件之间的相依性或风险。应用一个系统范围的测试包以证明最低限度的可操作性。协作集成通过向被测试系统中加入模块的集合证明稳定性，该集成被要求支持一个特定的协作。协作中包括的模块按照在一个处理线程、一个事件响应路径或关键性能目标中的隶属关系来选择。如果不存在协作上的顺序约束，系统范围责任的测试包应该使用协作集成或往返场景测试。基干集成结合了自顶向下集成、自底向上集成和大爆炸集成的元素，以验证紧密耦合的子系统之间的互操作性。测试设计问题是首先识别支持应用控制的模块、基干和应用子系统，测试的顺序也是基于这个分析。层次集成层次集成使用增量式的方法验证一个层次体系结构中的稳定性。层次集成结合了自顶向下集成和自底向上集成的元素。测试设计必须识别层次并确定对每个层应用哪种集成方法。客户服务器集成论证客户和服务器之间交互的稳定性。从单独测试客户和服务器开始，然后在范围内使用受控增加直到所有接口被测试。测试方案必须识别客户和服务器。客户/服务器交互可以用任意适合的测试设计样式建模。扩充式用例测试和往返场景测试都适用。对双重星型网络，基本的集成策略是检测客户服务器对。在三重星型网络中，我们检测客户服务器和服务器服务器配置，随后是客户服务器服务器配置。分布服务集成论证松散耦合的同等模块之间的交互的稳定性。从单独测试一些结点开始，然后在范围内使用受控增加，直到所有接口被测试。集成测试一个分布式系统关心的是验证远程主机之间的接口是最低限度可操作的。寻找一个测试包，它给一个分布式系统的聚合行为以充分的可信度，是一个更加困难的问题。高频集成频繁地将新代码和一个已经稳定化的基线集成在一起，以免集成故障不能被发现，以及防止运行的、稳定化的基线的偏差。测试可以使用任意适合的系统范围的测试样式来开发协作集成、往返场景测试等。联想软件的集成测试工作以下是联想软件集成测试规范（摘自LSIC）A目的通过执行集成测试，及早发现软件模块间的接口错误。B责任人集成测试负责人C输入准则被测试单元通过单元测试；测试计划被批准概要设计说明书被批准；D输入软件代码；测试计划；概要设计说明书；前一阶段测试报告（可选）E活动根据测试计划制定集成测试计划根据概要设计说明书制定集成测试说明（设计与更新测试用例、实现测试用例），并对测试说明进行同行评审，评审的人员包括设计人员、编码人员、测试人员执行集成测试用例，编写阶段测试报告。F输出阶段测试计划、测试说明、阶段测试报告。G输出准则阶段测试报告被批准。H度量BUG数目；BUG修复时间；缺陷原因；工作量；功能覆盖率。下面将详细介绍工作过程集成测试前的工作的说明集成测试的入口准则与输入软件概要设计说明书软件概要设计说明书概要设计阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础，并为测试人员设计集成测试用例提供了依据。概要设计完毕后，阅读概要设计说明书，了解整个系统的组织结构和开发人员制定的开发顺序，先从整体把握这个系统，从而选择适当的集成策略，并根据接口描述和主要功能描述制定集成测试计划、设计和用例，根据概要设计说明书设计每个被测试模块的驱动和桩，并根据需求规格说明书和概要设计说明书针对每个模块所实现的功能设计测试用例，针对每个模块的输入参数设计不同的数据进行测试，设计测试用例的方法主要是黑盒测试方法等价类划分、边界值及因果分析法。人员安排综合测试既要求参与人熟悉单元的内部细节，又要求他们能够从足够高的层次上观察整个系统，因此一般由主要的软件开发者协助测试人员来完成集成测试的设计。集成测试计划制定在制定测试计划中重点要定义好A阐述项目背景B定义集成测试环境C确定集成测试范围（决定测试粒度）D建立测试通过和失败的准则E估计人力和其他资源F工作量的估计G做相关的风险估计和防范方法集成测试说明需要同行评审H根据概要设计确定整个集成测试的测试策略和方法，集成测试设计I将集成测试设计转变为简明易懂的集成测试用例。根据集成测试设计对环境的要求，编制测试程序和测试工具（或选购工具），构造测试用例的输入数据。在单元测试完成后，按照集成测试用例进行集成测试。集成测试的实施过程中要注意的问题A集成测试环境的搭建首先要了解系统的开发环境，使用的开发语言和开发工具，以便提出必要的资源需求。根据这些信息搭建集成测试的运行环境，集成测试的运行环境包括操作系统、数据库、开发软件，应与研发人员的开发环境保持一致。设置系统运行所需的参数、数据初始化工作，测试环境的搭建可由开发人员协助测试人员完成。B桩或驱动的制造在集成测试的过程中，我们需要根据集成测试策略的选取来决定是否在测试中制造桩或驱动，在大多数集成测试中需要使用驱动和桩加载被测试模块，然后输入测试数据进行测试并查看测试结果。针对不同的代码版本，驱动和桩一般不需要改变，但是测试用例可能需要完善。制造桩目的是模拟待测系统运行的实际环境，为其提供可用来调用的模块。桩和待测系统的关系是待测系统调用桩，桩是用来满足待测系统调用其他功能模块的需要的。比如我们要测试一只笔能否写字，就要拿来一张纸，这张纸就是测试笔时所使用的桩。如果为一个类制造桩，所要关心的是该类中定义使用的其他类的实例（对象）。即要搞清该类都使用了哪些外部的资源。然后我们以最简单的方式来提供这些资源。制造桩的问题，一般都会归结到编写函数上，即便这个桩是一个类。当待测模块调用一个有返回值的函数时，我们就可以编写一个简单返回数值的函数供其调用；当待测模块调用无返回值的函数，我们就编写一个打印简单提示信息的函数供其调用，仅仅用来当函数得到调用时提示一下。制造驱动目的是模拟待测系统运行的实际环境，提供调用待测系统的模块。驱动和待测系统的关系是驱动调用待测系统，驱动是用来满足待测系统被其他模块调用的需要的。还是用测试笔写字的例子，只有笔（待测系统）和纸（桩）还不能实现写字，还必须有一只手拿着笔才可以，这时的手即是驱动。如果为一个类制造驱动，所要关心的是该类提供了哪些供调用的公有函数，即要了解怎样才能使用这个类的功能。然后在驱动模块中对这些函数进行调用，观察这些函数的工作情况。这时就需要对函数的调用参数，调用方式等方面设计测试用例。C集成测试的测试点1）接口测试测试模块间的接口是否吻合。2）数据传递测试在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失。例如调用函数获得返回值、不同的模块使用同一个数据。3）误差积累测试由于原来可接受的误差的积累可能导致结果不可以接受，所有在测试方案中要考虑那些模块会产生误差，误差是否会积累，误差以什么方式增长。4）全局数据测试考虑全局数据的有效期，在有效期内对其的操作是否合理，是否存在使用过期数据的情况。5）负作用测试测试某一个模块的功能是否会对另一个模块的功能产生不利的影响。如抢占资源、破坏数据、安全漏洞、性能瓶颈等。6）组装功能测试子功能组合是否能达到父功能的预期要求。7）界面风格测试测试各个有界面的功能的界面风格搭配是否合理。8）回归测试在问题修改后，要对所有相关模块再进行一轮测试，验证本次修改没有产生负作用。D集成测试的操作步骤假定开发的软件系统按自底向上集成的方式进行测试。这种方法是将底层的单元分组集成测试，然后再逐步向上将软件集成起来，直到最后所有的单元都在一个组中。测试可按下列步骤进行A将最底层的功能模块进行分组，原则是将那些与上层某个功能模块相关联的模块分为一组。C对每一组分别进行测试，各组测试可并行展开，这样可以加快测试的进程。DC沿软件的结构，逐级向上集成，直到所有的单元都组合到一起，这样就完成了集成测试的任务。集成测试阶段是以黑盒测试为主，在自底向上集成的早期，白盒法测试占一定的比例，随着集成测试的不断深入，这种比例在测试过程中将越来越少，渐渐地，黑盒测试占据主导地位。E需要特别注意的问题1类内部使用全局变量。2类内部使用全局函数。3类内部使用库函数。4使用宏定义。上述这些情况也是模块（类）与外界发生联系的方式，但这些情况往往在相关文档中描述较少，在程序中又很隐蔽，这就需要我们测试人员对源程序多做一些内部的观察，还要与开发人员多进行沟通。在MFC程序中，要测试对话框类，不仅要导入类的文件，还要将对话框的模版导入进来。在测某一模块时，一定要明确该模块的功能，不属于该模块的功能就不需要测。比如对于一个充当主界面的对话框，他的一个消息响应函数调用了另一个函数。我们测试这个功能时，只要消息响应函数正确的调用了相应函数，就算测试通过了，而不用关心被调用函数到底怎样了。在测某一模块时，千万不要为了整个测试系统能正确运行而去改变模块内部的东西，虽然这些对我们是可见的，我们要以只读的态度去看待这些源代码。集成测试的结束集成测试后，根据测试情况撰写集成测试根据测试报告，模块设计功能需求覆盖率和接口覆盖率100的情况下转入下一个测试阶段。第三节确认测试本部分是本章的重点之一，确认测试本身也是我们目前测试工作的重点。确认测试概述确认测试是软件测试各个阶段中重要的一个测试阶段。在实际工作中我们可能因为各种因素作出裁减某些测试阶段的决定，然而确认测试却是无法被裁减的，原因何在让我们回顾一下前文关于确认和确认测试的定义。确认（VALIDATION）确认是指在软件开发过程结束时对软件进行评价，以确定它是否和软件需求相一致的过程。在软件产品开发完成以后，为了对它在功能、性能、接口以及限制条件等方面是否满足需求做出切实的评价，需要在开发的初期，在软件需求规格说明书中明确地规定确认的标准。确认测试（VALIDATIONTEST）又称为有效性测试。它的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。从定义中可以看出，确认测试的目的是保证开发出来的软件确实符合客户需求，是客户所真实需要的产品。一个软件无论规模大小、难度高低、质量好坏，终归是开发出来完成某种功能，达成客户某种需求的。如果这个目的没有达到，那么这个软件的存在就是毫无意义的。当我们向客户交付产品时，客户一定会提出这样的问题这个软件可以完成我要它做的事吗在开发过程中，我们的需求人员已经把客户的需求转化为需求规格说明，然后产生了各种设计文档，在此基础上编码人员完成了编码工作，最后诞生了软件产品。那么这个软件产品是否就是需求规格说明中描述的东西是否是客户脑海中的想象的真实表现我们的确认测试人员将进行确认测试来回答这个问题。质量工程的意义是用正确的方法做正确的事。确认测试的意义就是通过测试活动了解这个产品是否是正确的产品。确认测试的开始与结束确认测试作为一个如此重要的测试阶段，我们应当在何时进行呢可以用V模型的示意图清晰的表现这个问题的答案。如图11所示，确认测试的活动几乎贯穿了软件开发测试的全过程。它开始于项目初期的需求分析阶段，而终止于项目末期，确认测试的测试执行是在完成了单元测试和集成测试阶段后进行的。这里的测试活动采用的是广义的测试定义，即不单纯指为了发现错误而执行程序的过程本身，而是指从需求分析阶段就开始的一系列复查、评估与检验活动。作为一个确认测试人员，必须在项目初期需求分析阶段就加入项目进行各种活动，开始编写确认测试计划与确认测试说明等文档。确认测试的核心仍然是软件需求，是围绕着对于需求的一系列验证活动。确认测试工程师需要根据软件需求分析阶段的规格说明设计一批测试用例，并利用这些测试用例去运行程序，以发现程序与需求之间的偏差与错误的过程。其确认测试具体执行的时间点可以说是位于集成测试之后，确认测试实际上是根据需求规格说明书进行的动态黑盒测试。如果用H模型来表示，确认测试的测试准备活动开始的最早，而测试执行活动却相对很晚。说明测试流程大致分为两类活动，一类是测试准备活动，包括测试需求分析、测试计划、测试用例设计与实现、测试环境准备、培训学习等等，另一类是测试执行活动，包括测试实施、BUG提交与验证等等。注意V模型是一个理想单纯的项目过程的表现，事实上我们实际采用的项目周期包含了迭代、螺旋和增量等各种模式因素。因此软件的测试流程也随之产生各种并发、迭代。测试是一个不断的工作流，从项目开始就在不断的进行，只要条件完备即行开始。因此上文所述的测试阶段次序在实际意义上是项目某个子层次上的微观模式。确认测试策略与方法确认测试策略需要确定确认测试的具体内容和优先级分布,也就是测试重点布局；确认测试采用的测试方法；确认测试实施的顺序；确认测试环境的应用策略。确认测试设计方法在确认测试阶段，确认测试的测试设计可以按照两条轴线展开思考，这两条轴线就是基于需求规格说明书的软件功能分解和基于质量特性体系的软件质量子特性分解。这2条轴线综合考虑的结果将形成一个完整的软件确认测试布局。图45，确认测试设计方法基于需求规格说明书的软件功能分解基于需求规格的设计轴线是确认测试设计的基础，把需求规格中描述的功能点和其他需求作出合乎逻辑的分解，列出各种输入、执行条件，对应将需求要达到的目标作为预期的输出结果。当执行用例时，我们要验证实际输出结果是否符合预期，一旦实际输出与预期输出产生偏差，那么产品就很可能存在缺陷。功能点1功能点2功能点N质量子特性点N质量子特性点2质量子特性点1基于质量特性基于需求规格当我们将需求规格说明所描述的功能点一一分解为实际运行中的最小单元，就获得了一个被测试功能描述的清单。当然需求规格说明里除了功能需求的内容，还会包含一些类似性能、UI等非功能需求，测试用例同样要把这些内容的测试项目包含进去。为了保证需求规格说明被完备和一致的在确认测试用例里得到了描绘和分解，需要引入一个对照表。参见下表。通过表格的一一对应就容易保证每个需求都得到了充分的测试。请注意，需求与测试用例的对应一般不会是一对一的，而是一对多甚至是多对多的，一个需求往往需要多条用例才能测试完全。测试用例就是一组输入、事先准备的执行条件和预期的输出结果，这些都对应一个特定的目标（被测对象）。根据需求规格说明书分解形成的测试用例如下被测试功能描述输入数据操作预期结果评判标准功能点1细化分解功能点11细化分解功能点12细化分解功能点1N功能点2细化分解功能点21细化分解功能点需求序号需求内容测试用例序号需求1测试用例1需求1测试用例2需求2测试用例3需求M测试用例NNM被测试功能描述输入数据操作预期结果评判标准22基于质量特性体系的软件质量子特性分解需求规格说明主要反映了软件功能的需求细节，但是作为一个软件，同时应该具有许多其他质量特性，这些特性有些在需求规格说明的非功能性需求部分中有简单描述，但是大部分作为软件的隐含需求或者通用特性并没有在需求规格说明中描述，为了全面测试软件，需要从软件质量体系的角度考虑设计用例。软件质量体系有很多种，各有其优缺点。在此仅以中华人民共和国国标定义作为讲解的标准，实际应用中应该广为采纳各种体系之长，根据项目和软件的实际情况决定。考虑质量国标中定义的软件质量特性以及相关子特性，其中功能性、可靠性、,易用性是确认测试中最常考虑的测试内容，效率和可移植性有时也要考虑。A21功能性A211适合性A212准确性A213互操作性A214依从性A215安全性A22可靠性A221成熟度A222容错性A223易恢复性A23易用性A231易理解性A232易学性A233易操作性A24效率A241时间特性A242资源特性A25易维护性A251易分析性A252易改变性A253稳定性A254易测试性A26可移植性A261适应性A262易安装性A263遵循性A264易替换性我们需要根据被测试产品的特性决定哪些质量特性和子特性在本次测试中需要考虑，以及这些特性在产品中表现为什么样的功能点举例来说测试一个类似OUTLOOK的邮件类应用软件。它所具有的主要功能点是邮件的新建、发送、接收、浏览，其他的功能还包括邮箱地址的设置、参数的设置、通讯簿等等，那么根据这个产品的性质，我们可以决定测试时考虑的质量特性。首先是功能性中的适合性SUITABILITY与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性。这个特性在任何软件测试中都是基础的组成部分。本产品需要测试需求规格要求的这些新建邮件、发送/接收邮件等等各种功能确实存在并且正确运行。关于准确性由于本软件没有计算功能单元，因此可以不考虑。关于互操作性与同其他指定系统进行交互的能力有关的软件属性。由于邮件的发送和接收需要与其他邮件应用软件以及服务器、WEB邮箱系统等发生交互，所以是十分重要的测试点，包括是否测试了与其他同类产品（OUTLOOKLOTUS）等邮件收发的正确收发、显示以及各种编码方式的接收显示、本地邮箱与远程邮箱的互操作性等等。关于依从性所有的软件都需要遵守一定的标准、约定、法规及类似规定的软件属性，因此依从性的检查是必不可少的。通常情况下是测试软件的LOGO、图标是否符合公司的规定、标准，有些特殊的软件还需要检查内容、图片、文字是否合乎法律。关于安全性由于本产品存在远程的数据存储、传递，所以安全性是极其重要的测试内容，邮箱的用户权限、密码口令、数据存储、远程访问各种操作是否可以防止对程序及数据的非授权的故意或意外访问。至于程序运行的可靠性、易用性、可移植性中的易安装性都是需要在确认测试中考虑的。对应这些特性我们需要设计长时间大流量的测试用例，针对帮助文件的测试用例，针对安装卸载的测试用例等等。以上只是一个简单的例子，实际应用中需要根据软件的实际情况定义哪些属于需要测试的质量子特性，然后分析形成更多的测试分解点。形成的测试用例简表如下被测试特性描述输入数据操作预期结果评判标准可靠性成熟度测试分解点1测试分解点2测试分解点N易用性易学习性测试分解点1测试分解点2其他测试在逐步沿上述2条轴线进行分析后，基本已经覆盖了软件测试的全部内容，下面的工作是补充一些特殊的专项测试以完善测试整体覆盖程度。这些测试涉及内容从本质上仍然属于上述功能或者非功能特性的范畴，只是单独进行测试更有效率。以下是几个比较典型的专项测试，这些测试的细节请参照相关测试指南。易用性测试针对软件UI交互方式进行的专项测试，测试对象为软件界面、文字、菜单、按钮等一系列UI交互对象。关注点是七个要素符合标准和规范、直观性、一致性、灵活性、舒适性、正确性、实用性。测试方法比较典型的是用户使用性研究、ALAC和用户剖面方法。本地化测试针对软件在不同地域和语言环境下运行的测试。测试要点主要有1翻译问题1文本扩展影响屏幕,窗口,框体,按钮内存分配2使用UNICODE标准3热键和快捷键定义4字符计算文字排序和大小写转换5文本方向6图形中的文字7资源独立化2其他本地化问题1内容是否本地化包括范例文档图标图片声音视频剪辑帮助文件地图市场宣传材料包装WEB链接2数据格式包括度量衡时间纸张大小数字日历货币地址日期电话号码3准备和测试国外平台配置硬件国外版操作系统和应用软件国外版驱动国外版键盘布局4数据流动和转换的兼容性测试兼容性测试针对软件在各种操作系统、硬件平台、外设、其他应用软件以及各种配置、协议的环境中兼容性程度的测试。测试要点是根据需求列出完整的环境清单。OPERATINGSYSTEMSWINXPHOMEWINXPPROFESSIONALWINDOWS2000WINDOWSMILLENNIUMPCLEGENDCOMPAQDELLIBMAPPLICATIONSACCESSXPEXCELXPINTERNETEXPLORER6OUTLOOKXPHARDWARECONFIGURATION确认测试采用的技术在确认测试阶段，我们所依据的输入文档是需求规格说明，我们所检查验证的对象也是产品对于需求的满足程度，对于产品内部的逻辑结构和内部特性我们是不了解也不关心的。也就是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此确认测试采用黑盒测试技术主要的测试方法也就是黑盒测试的各种方法黑盒测试包括以下一些内容根据需求规格说明，检查是否有不正确或遗漏了的功能是否忽略了用户的隐含需求在软件外部接口上，输入能否正确地接受能否输出正确的结果是否有数据结构错误或外部信息（例如数据文件）访问错误性能上是否能够满足要求易用性和其他功能特性是否能够得到满足是否有初始化或终止性缺陷是否会出现用户不能接受的缺陷等价类划分、业务与逻辑分析、边界值分析、特殊数据分析，因果图、ALAC等测试方法是确认测试用例设计中最常见的设计方法。由于在前面的章节中已经做了十分详细的叙述，这里不再做过多重复，而是谈谈实际情况下各种测试方法的应用。等价类划分是最典型、最常用的黑盒测试方法。当产品中存在包含大量输入数据的输入域,采用测试每个输入数据的穷举测试是不现实的，因此需要在大量的可能数据中选取其中的一部分作为测试用例，即应用等价类划分方法。等价类划分的方法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。具体划分为有效等价类和无效等价类有效等价类是指对程序的需求规格是有意义的、合理的输入数据所构成的集合。在具体问题中，有效等价类可以是一个，也可以是多个。无效等价类无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。一般来讲，无效等价类会有多个，对于输入数据较多的情况，无效等价类要比有效等价类的数量要多。例如邮件类软件中的用户注册子窗口，需要输入用户名和密码，这个输入值必须遵循某些规则，比如用户名必须是614位字符序列，可以包含数字、英文字母、不包含操作符。针对这个命名规则依据等价类划分技术分解，可以得到一系列有效等价类和无效等价类的用户名与密码的取值，测试了这些取值的处理情况就代表测试了全部可能数据的处理情况。边界值分析往往与等价类划分同时采用，弥补等价类划分的不足。当输入域是一段数值范围时，等价类划分只需在数值段内取一个值，但是实际上，程序对于位于边缘的数值处理发生错误的可能性更高。此时就需要增加取值，将该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小个数及稍小于最小、稍大于最大个数作为测试用例。当软件的功能类型是对于各种输入产生相应的输出，采取等价类划分和边界值分析方法的结合来设计测试用例是比较合适的。当软件包含了复杂的业务流程和逻辑控制的情况下，应当采用业务与逻辑分析设计用例。如果软件运行流程和逻辑控制规模不是很大，采取因果图的思想来设计用例也是可以的。因果图法测试用例选择步骤为6分析程序规格说明的描述中，那些是原因，那