高级软件测试技术(与“测试”有关的共148张)

高级软件测试技术第一页，共148页。课程说明本课程的面向对象为测试经理、测试分析设计人员、测试工程师、项目经理、开发人员、质量相关人员课程时间安排为2天，上午9:00–12:00，下午13:00–17:00课程进行中，请关闭或是将调为震动课程进行中，任何问题都可以随时向讲师提出，但讲师有权决定在何时进行解答第二页，共148页。软件测试团队第三页，共148页。测试组织结构第四页，共148页。测试组织的构成测试部门经理测试项目经理/测试经理测试代表测试小组成员软件测试工程师硬件测试工程师自动化测试工程师其他技能人员第五页，共148页。选择合适的成员技能经验和背景类似的项目经验个人性格和软技能成员培训第六页，共148页。关注项目启动阶段关注项目确定的范围为即将到来的测试做好准备项目背景技能要求用户态度可能的参与模式要注意的特殊事项第七页，共148页。测试团队成员类型老虎牛猴子长颈鹿狐狸鼹鼠有活力、有冲劲、聪明、能干、敏锐、不惧怕压力

踏实、勤劳、敬业，但缺乏创造力聪明、大胆、活跃，但缺乏耐心最有前瞻能力，但缺乏执行力看上去最为忙碌的一个，但总是躲在事情的背后永远的茫然第八页，共148页。不同类型员工的对策……鼹鼠拿掉他用来隐藏自己的“多任务”，明确交给他少数的任务狐狸参谋。在规划部门发展的时候，可以多听听他们的意见，但最好不要完全交由他去进行长颈鹿部门新技术研究的不二人选，但必须时刻监控他的工作进展猴子让他做自己最擅长的事情牛给他挑战，把部门最重要的、最困难的工作交给他老虎第九页，共148页。部门氛围的营造学习型组织学习的交流的氛围部门讲师制度专题研究鼓励参与外部交流制度和流程制度流程先行知识不仅仅是个人的，首先是团队的第十页，共148页。部门讲师制度原则讲师既是荣誉，也是责任将讲师的传播工作作为绩效的组成部分讲师聘用制度部门讲师的认证方法自行报名考核认证发证第十一页，共148页。测试经验库“从实践中来，到实践中去”测试经验库的几个层次普适性的测试经验（测试设计经验、测试执行经验）针对具体产品的测试经验针对规范的测试经验测试经验库的载体Excel文档自行开发的信息系统采用Wiki作为载体第十二页，共148页。测试规范测试规范是另一种形式的测试经验积累测试规范的类型界面测试规范XX产品测试规范XX模块测试规范WEB应用性能测试规范……第十三页，共148页。围绕测试用例的测试工作什么样的用例才是好的用例？首选，评价用例的好坏要从“总体”的角度来考虑——覆盖性、有效性其次，用例应该具有基本的要素——用例编号、用例名称、用例前置条件、用例步骤、用例的输入数据、用例预期结果、验证用例的方法第十四页，共148页。用例示例第十五页，共148页。测试工程师绩效评价的难点测试不是构造工作，因此无法用确切的构造成果来评价测试不能提高质量，因此产品质量不是评价测试的唯一因素测试不是纯粹的技术工作，测试还应该包括许多沟通和协调的工作第十六页，共148页。测试工程师的绩效评估框架事后评价工作成果评价非技术因素评价组织建设评价第十七页，共148页。事后评价通常，我们可以通过对测试产品的质量评价的一部分反映测试人员的工作效果

现场发现问题数/测试发现问题数第十八页，共148页。工作成果评价用例设计效率用例执行效率发现缺陷数量工作规范化程度相关问题：测试组织的基准效率第十九页，共148页。非技术因素评价一个好的测试人员不是发现问题最多的测试人员，而是使自己发现的问题最多得到解决的测试人员。 ——《SoftwareTesting》沟通能力协作能力受欢迎程度评价的方法：360度考核第二十页，共148页。组织建设评价在测试理念推广上发挥的作用在测试工具研究上发挥的作用在测试自动化方向上发挥的作用为测试经验库和规范库贡献的成果其他与组织建设相关的工作建议方法：将所有这些纳入日常工作管理范围内，例如，月度计划、周报和日报第二十一页，共148页。测试度量第二十二页，共148页。测试是什么测试是一个系统工程测试是设计和实现一种特定软件系统的过程测试的目标是发现缺陷测试是一个发现缺陷的过程测试的手段是V（Verify）&V（Validate）测试是对依据系统预期行为设计的测试用例的动态验证（DynamicVerification）过程，目的是发现程序中的缺陷——SWEBOK2004第二十三页，共148页。测试度量过程测试现状CMM3级的经验数据：国防部经验数据：第二十四页，共148页。测试度量过程度量分析过程提供对其它相关过程的支持，是一个支持过程。度量分析过程指导项目和组织将度量需求和目标与提供客观有用结果的度量活动结合起来，从而帮助项目和组织制定有用的决策并采取适当的纠正措施。为有效开展度量分析活动，度量分析过程需遵守一些准则和规范：A)度量活动要满足相关方对数据的需求；B)与所投入的资源相比较，度量结果是有价值的；C)严格按照组织定义（或经批准的裁剪）的度量说明来执行。第二十五页，共148页。测试度量过程测试度量过程第二十六页，共148页。测试度量过程测试度量过程制定度量计划的过程确定目标识别关键过程选择和定义度量选择度量定义度量：必须创建操作定义告诉人们如何进行度量，而且要足够详细到其他人如果遵循同样的步骤也可以得到相同的结果集成度量到过程中第二十七页，共148页。测试度量过程测试度量过程选择度量过程执行情况：①度量由过程产生的产品的属性，如规模；②度量该过程本身的属性，如工作量。A.确定度量的GQM方法：GQM（Goal-Question-Measure）即“目标-问题-度量”方法，通过设立目标、提出问题、回答问题三个步骤来确定选择什么度量。B.过程中的度量实体：关键过程中有很多对象可以度量，过程所接收的事物、过程产生的事物、过程中的活动、过程中所消耗的事物，以及作为过程的结果而保留的事物（缺陷数、笔记、会议记录）都是可以被度量的对象，我们称之为实体。C.基础度量和衍生度量D.选择有用度量的标准E.操作定义第二十八页，共148页。测试度量过程选择有用度量的标准依据如下标准评价潜在的度量是否真的有价值：

度量与问题紧密相关；

能提供足够的信息来说明问题；

通过了事实的测试，如度量是否真的反映了过程对重要结果的实现程度；

数据收集起来容易、有效，不需花费太多的工作量；

使来源不同的相同度量数据一致、不矛盾；

度量后能够显示出可比较的差异；

形成数据集合时，可以用来诊断问题。第二十九页，共148页。测试度量过程操作定义对于所选择的每个度量，应当建立相应的操作定义，遵守以下三个原则，是定义出好的数据的基础：可传达。其他人可以清楚地知道度量了什么，怎样度量，度量单位是什么，包括什么不包括什么？重复性。度量是否可以重复，给出同样的定义，其他人能否取得同样的结果？可追踪。根据数据的收集时间、顺序、活动、产品、过程的状态、环境、使用的度量工具和收集方式，能够识别数据的来源第三十页，共148页。测试度量过程操作定义每个操作定义应包括以下内容实体。被度量实体的名称和描述。属性。被度量实体属性的名称和描述。值。对于每个属性，说明度量的单位（如数目、小时）和可能的值或值的范围。说明哪个值要包括，哪个值不包括。来源。说明产生数据的过程以及数据在哪里被报告，收集或报告的机制，使用的度量工具等。第三十一页，共148页。测试度量过程度量模型现执行项目数据库（DC）数据收集项目层组织层过程数据库PDB过程能力基线PCB项目结束指导分析EPG：度量组MG项目性能分析组织过程能力分析第三十二页，共148页。测试度量过程

测试度量角色MCTQAEPG测试人员TMPDT开发代表MG第三十三页，共148页。测试度量过程产品级别度量指标产品故障率（次/套*年）网上遗留问题次级密度（NPR）系统终端网上问题及时解决率网上逾期问题解决率总返还率内部问题累计解决率设计更改/工程更改/计划月更改频率产品关键交付件缺陷发现密度第三十四页，共148页。测试度量过程

项目级别度量两种度量类型：过程度量和交付件度量过程度量：规模、测试工作量、测试进度、测试生产率交付件度量：缺陷率（阶段）、缺陷排除率、可靠性等四个基本度量项：规模工作量进度缺陷第三十五页，共148页。测试度量过程测试度量指标（一）第三十六页，共148页。测试度量过程测试度量指标（二）第三十七页，共148页。测试度量过程测试度量指标（三）第三十八页，共148页。测试度量过程测试组织能力基线CB—依据收集到的度量数据建立的组织级能力基线数据，从而反映组织的开发能力和成熟度第三十九页，共148页。自动测试原理第四十页，共148页。目录－自动测试测试过程中的不同种选择自动化工具原理自动化工具特征回归测试基于GUI的自动测试工具自动化功能测试和回归测试的优点存在的问题分析基于功能的自动测试工具简介第四十一页，共148页。测试过程中的不同选择案例故事第四十二页，共148页。对不同测试工程师的评价测试员1

是一个典型的手动测试者，

从键盘手动运行所有的测试。手动测试在当前的工业界很普遍――它能提供直接的好处，但长时间的运行会让测试人员感到单调乏味，

对公司来讲成本高，效率低。“我看到的最悲哀的景象之一就是一个人在键盘上手动操作一些可以自动运行的东西。这是悲哀的但也是有趣的。”

－

－

Boris

Beizer，

黑盒测试：

软件和系统功能测试技术第四十三页，共148页。对不同测试工程师的评价测试员2

实践的是称为静态测试自动化的测试。静态自动化脚本每次根据同样的次序执行同样的命令序列。当应用程序发生变化时这些脚本的维护成本很高。测试是不断重复的；但由于它们总是执行相同的命令，

因此它们很难发现新的错误。第四十四页，共148页。对不同测试工程师的评价测试员3操作接近于自动化测试的边缘。这些类型的随机测试程序被称为蠢猴，因为它们就是毫无目的的敲打键盘。它们生成非常规的测试执行序列并发现很多致命的错误，但是想控制它们到应用程序中你想测试的部分却是很困难的。因为它们不知道自己在做什么，所

以它们会漏过应用程序中很多明显的错误。“猴子式的测试不能是你测试的全部。猴子不明白你的应用程序，由于它们的无知它们漏掉了很多错误。”

－

－Noel

Nyman，

“使用猴子式的测试工具,”SQTE,2004.1/2

第四十五页，共148页。对不同测试工程师的评价测试员4

通过一种称为“模型驱动测试”的智能测试自动化方法糅合了其它测试员的方法。模型驱动测试并不像静态测试自动化那样逐字逐句的记录测试序列，也不盲目的在键盘上敲打。模型驱动测试通过对应用行为的描述来判断哪些操作是可能的、期望输出是什么。这种方式不断自动生成新的测试序列，很好的适应了应用程序的变化，能够同时在多台机器上运行，

并能整天运行。“一个艺术家用他的智慧画画，

而不是用他的手。”

－

－Michelangelo

Buonarroti第四十六页，共148页。启示测试员1

的方法需要他的手不停的在键盘上工作。最后测试员1精疲力竭。测试员2

的静态脚本重复他的手已经执行过的那些键盘操作。测试员3

的猴子式测试本质上是无目的的在键盘上乱敲。测试员4,从另一方面，

在其它技术上进行了补充：思考应用程序的行为，将行为描述给一个测试生成程序，让测试生成程序来创建和运行测试用例。通过根据应用程序行为描述生成测试，测试员4

能够执行那些在

使用其它测试方法时不可实现的测试。这个故事的寓意：

自动化你的大脑，

而不只是你的手。

第四十七页，共148页。对测试自动化不切实际的期望所有的测试都能够实现自动化！既然自动化测试能如此显著地提高生产率，我们就能以更少的人员完成所有的测试（精减人员）。自动化测试如此简单，我们无需任何培训。自动化方法将缩减整体测试工作量。我们无需制订任何测试方案。有了自动化测试，测试人员不就成了“过时的”或“多余的”了吗？那种耗时的测试设计工作不再必要了。第四十八页，共148页。自动化测试不是银弹自动化测试，或者说自动化测试策略及工具的实现，只是测试人员工具箱里的一件利器。第四十九页，共148页。确定自动化测试的"用武之地"将所有工作中的特定部分作为应用自动化的候选对象。从高度冗余的任务或场景开始考虑。将乏味且人工容易出错的工作进行自动化。首先关注开发成熟、理解透彻的用例或场景。优先选择应用中相对稳定的部分，而非易变的部分。通过使用数据驱动的测试技术来提高自动化功效（增加测试覆盖的深度和广度）。指派几位专家负责自动化，不要让测试团队的每个人都做这项工作。牢记不要追求100%的自动化，手工测试仍然至关重要。第五十页，共148页。自动化工具原理自动化是相对手工测试而言的

——将手工测试过程记录下来；

通过输入，测试输出结果是否正确

——替换手段：通过串口，网络，Windows消息机制，函数调用等手段为一个对象提供自动化输入；

比较实际输出和期望输出

——替换手段：将输出通过串口，网络，界面等输出并记录下来；

负载测试

——多个输入同时施加到被测试对象上；第五十一页，共148页。自动化测试工具的特征1支持脚本化语言(ScriptingLanguage)支持多种常用的变量和数据类型支持数组、列表、结构、以及其他混合数据类型支持各种条件逻辑（IF,CASE等语句）支持循环(FOR,WHILE)支持函数的创建和调用

Perl,vbscript,javascript脚本语言的功能越强大，就越能够为测试开发人员提供更灵活的使用空间，而且有可能用一个复杂的语言写出比被测试软件还要复杂的测试系统。第五十二页，共148页。自动化测试工具的特征（续）2对程序界面中对象的识别能力:鼠标位置识别,对象识别，位图对象识别（图像比较）3支持函数的可重用：脚本比较容易实现对函数的调用，脚本与被调用函数之间的参数传递；4支持外部函数库：如Windows中DLL访问，如采用外部函数进行数据库操作正确性检查等；第五十三页，共148页。自动化测试工具的特征（续）5抽象层：抽象层将程序界面中存在的所有对象实体一一映射成逻辑对象，通过简单修改抽象层，帮助减少测试维护工作量。6分布式测试（DistributedTest）：分布式测试可以实现定制任务执行的时间表，安排多人同时进行测试第五十四页，共148页。自动化测试工具的特征（续）7支持数据驱动测试（DataDrivenTest）：测试脚本通过从实现准备好的数据文件中读取或者写入数据保证测试流程的正常执行，少的脚本，大量的测试数据即可。

8错误处理：在出现问题时能够跳过错误或者对系统进行复位，执行后面的任务，从而不至于出现一个问题而耽误了所有用例的执行；

9调试器（Debugger）：调试器要能够支持脚本单步执行、设置断点、核对变量返回结果等，有的还可以跟踪进入可执行程序，外部调用的函数库等；第五十五页，共148页。自动化测试工具的特征（续）10源代码管理

可以帮助我们进行测试脚本库的导入，导出，回退到以前版本，比较不同版本间的差别，以及同时对几个项目进行跟踪等，尤其在团队开发中很有必要，可以对测试数据文件，测试脚本，对象抽象层进行统一管理

11支持脚本的命令行方式（CommandLine）：如机器启动、程序BUILD后可以自动启动测试脚本执行等。第五十六页，共148页。回归测试AddappropriateverificationEnableteststousevariabledataRuntests&reviewactualandexpectedresultsCapturebusinessprocessintoatestscriptReuseandre-runtestsasapplicationchanges功能性和回归测试流程第五十七页，共148页。基于GUI的自动化测试工具基本原理：基于手工测试，基于已设计好的测试用例在测试者运行应用程序的同时，将其所有动作（键盘操作、鼠标点击等）捕捉下来，生成一个脚本文件，这个脚本以后可以被“回放”（playback），也就是按照上一步的所有动作重复执行一次，实现自动运行和测试。第五十八页，共148页。俘获/回放工具的分类

允许用户使用脚本语言去模拟GUI操作的需要。

这种俘获/回放工具通常是作为多平台应用，但需要额外的脚本程序编程。

工具提供自动记录和回放用户手动操作的能力而不要用脚本。

这种工具很容易使用，但作为多平台应用需要更多的人工操作

第五十九页，共148页。自动化功能测试和回归测试的优点覆盖大部分的系统测试提高效率来把精力专注于新模块创建可重用的测试模块减少人为错误第六十页，共148页。存在的问题及分析测试针对程序界面进行，一旦界面有改动，都需要手工修改已经录制好的相应测试脚本，或者重新进行录制。

尤其是程序中各模块都需要使用的一些公共程序部分（如用户登录界面），改动会引起大量测试工作的返工，造成测试脚本的日常维护工作量急剧增大；第六十一页，共148页。手段在被测试应用程序和录制生成的测试脚本之间增加一个抽象层，可以将程序界面上的所有元素映射成相对应的一个逻辑对象，测试就可以针对这些逻辑对象进行，而不需要依赖于界面上元素的变化；

建议把一些公共使用的函数进行封装，做成可重用的函数库第六十二页，共148页。分析最后，可以把测试执行过程中所需要的测试数据做成文件的形式，测试脚本在运行时能够随时从此文件读取预先定制好的数据，这样脚本和数据就可以独立维护

一个好的自动化测试工具其实与一个好的开发工具有很多相似的特性，也可以说：一个自动化测试过程实际也是一个软件开发的过程。第六十三页，共148页。自动化数据测试数据测试需要两个关键因素采集大量的产品数据为不同的数据集合准备测试脚本AutomatedTestScriptApplicationDataSource第六十四页，共148页。自动化创建可维护和可重用的测试应用的改变不需要改变测试脚本Test1Test2Test3可重用对象库第六十五页，共148页。功能测试自动化工具工具供应商工具RationalRationalSuiteTestStudioMIAstraQuickTest,WinRunner,XRunnerCompuwareQARunSegueSilkTest,SilkTestInterational,SilkPilotEmpirixe-testerSIAPanorama——OO_Playback第六十六页，共148页。组织级自动化测试的三个阶段第一阶段：Non_programmerTester第二阶段：EveryTestisaProgram第三阶段：EffectiveAutomationTest第六十七页，共148页。测试技术与测试自动化第一阶段：Non_programmerTester没有专职的测试脚本开发工程师自动化测试是一种项目组自发行为目前大部分公司的现状：项目组有空时或被领导推动时会研究一次测试技术，大多不了了之。第六十八页，共148页。测试技术与测试自动化第二阶段：EveryTestisaProgram要求每个测试人员都非常熟悉测试工具；并且有深厚的专业知识背景，如使用ITT需要掌握：TCL、ASN.1、协议、数据库等知识；存在问题：要实现自动化，对每个测试人员的要求都很高，测试成本高，资源外包的优势难以体现。以GUI的自动测试为例说明，此阶段自动化测试的问题是效率不高，在编写脚本的层次上重复，解脱的方法只有一种：测试设计。第六十九页，共148页。测试技术与测试自动化第三阶段：EffectiveAutomationTest测试设计与测试自动化职责分开；测试工具有专门的自动化程序员开发和维护测试设计采用电子表格编写测试用例，自动化程序员编写测试脚本、功能语句、处理引擎，负责并实现三者之间的有机结合。第七十页，共148页。测试技术与测试自动化不适合自动化测试的领域一次性项目

项目周期很短的项目业务规则复杂的项目

美观、音质、易用性测试系统不稳定涉及物理交互自动化测试的误区期望自动化测试完全替代手工测试期望自动化测试发现大量新的缺陷第七十一页，共148页。性能测试工具性能测试工具原理概述常用性能测试工具介绍性能测试工具的选择与评估构建还是购买第七十二页，共148页。性能测试工具原理基于功能测试工具，需要增加加载和监测分析手段；第七十三页，共148页。压力测试工具原理脚本工具控制调度工具压力产生器资源监视器报表和结果分析工具第七十四页，共148页。常用性能测试工具介绍MI的LoadRunner（://://mercury/cn/）支持多种协议（HTTP/HTTPS、FTP、SMTP、POP、数据库协议支持）能测试两层、三层应用良好的报表分析支持能和MI的其他产品很好集成拥有较大用户群价格是最大的问题，按照并发用户数收取License费用第七十五页，共148页。常用性能测试工具介绍Seague的SilkPerformer（://seague）功能上与LoadRunner相当支持多种协议价格比LR便宜国内的使用者不多，但在国外拥有广大的用户群第七十六页，共148页。常用性能测试工具介绍WebLoad（://radview）专用于Web测试，是“轻量级”的WEB测试工具只支持HTTP/HTTPS协议价格相对便宜运行于Windows平台上第七十七页，共148页。常用性能测试工具介绍免费工具WAS（://microsoft）在某些场合下可以应用，运行于Windows平台没有脚本支持对SessionID没有办法支持Microsoft不提供支持，也没有版本更新WAS的后续版本是ACT，不过已经不再是免费的了第七十八页，共148页。常用性能测试工具介绍开源工具OpenSTA（）专用于Web测试，只支持HTTP/HTTPS协议良好的脚本支持，脚本功能强大运行于Windows平台有庞大的社区支持脚本语言的复杂度要高于LoadRunner没有中文手册第七十九页，共148页。常用性能测试工具介绍ApacheJMeter（）支持多种协议（目前已支持的包括HTTP/HTTPS、FTP、Telnet、SMTP，还可通过插件扩展）不支持数据库协议用JAVA编写，可运行在多个平台上第八十页，共148页。白盒测试的性能测试工具CompuwareNumegaCompuwareDevPartnerRationalPurifyRationalPerformance……第八十一页，共148页。其他性能测试工具Compuware的QACenterPerformanceEdition（://wwwpuware）IBM的RationalRobot（://rational）开源工具theGrinder（:///）第八十二页，共148页。典型开源测试工具功能测试工具工具名称简介网址AbbotJavaGUITestFrameworkJavaGUI测试工具/SharpRobo针对dotNet的WinForm应用进行录制/回放的测试工具/projects/sharprobo/soapui通过HTTP协议对WebService进行测试/httpUnit通过代码控制对Web应用的访问和功能测试http://httpUSamieWeb功能测试工具，基于Perl/WatirWeb功能测试工具，调用IE的Automation接口实现，基于Ruby/LinuxTestProjectLinux的Kernel测试工具/第八十三页，共148页。典型开源测试工具性能测试工具工具名称简介网址OpenSTA使用者较多的一个WEB性能测试工具，支持HTTP/HTTPS协议/JMeter基于Java的性能测试工具，能支持HTTP/HTTPS、FTP、Socket等协议/jmeter/TheGrinder测试J2EE应用的性能测试工具/TestMaker测试WEB应用的性能测试工具，能支持HTTP,HTTPS,SOAP,XML-RPC,SMTP,POP3,IMAP协议/ptt/DBMonster用于产生数据库基础数据的工具http://dbmonster.kernelpanic.pl/DatabaseOpensourceTestSuite测试数据库性能的套件/第八十四页，共148页。典型开源测试工具测试管理工具工具名称简介网址BugzillarTestRunner基于Bugzillar的用例管理插件/projects/testrunner/Fitnesse测试描述、执行和管理的集成环境/TestLink以计划为主线，对测试用例的创建、执行的跟踪进行管理/docs/testLink.phpSoftwareTestingAutomationFramework(STAF)

一个测试自动化的框架，可通过增加Component等方式扩充自动化测试/projects/staf第八十五页，共148页。典型开源测试工具缺陷库工具名称简介网址Bugzillar最负盛名的缺陷库之一，功能强大，和配置工具CVS集成度好/projects/bugzilla/Mantis简单易用的缺陷库，完整包含一个缺陷管理工具的基本功能/Trac很好的缺陷和事件管理工具，能够与Subversion很好集成，保留每个缺陷的解决痕迹/trac/BugFree号称是微软缺陷管理系统的精简版本，中国人自己的开源工具/第八十六页，共148页。典型开源测试工具单元测试工具工具名称简介网址JUnitJava的回归测试框架，通过各种扩展已经成为一个庞大的测试框架/index.htmCactus测试ServerSide的单元测试工具，可针对Servlets、EJB等进行测试/cactus/index.htmlCppUnitC＋＋的单元测试工具/NUnitdotNet下的单元测试工具/DbUnit用于在不同测试间维护数据库环境/第八十七页，共148页。开源测试工具参考网站第八十八页，共148页。工具的选择过程很多工具一个工具被很多人使用的工具选择选择过程执行过程评估第八十九页，共148页。工具选择的过程定义问题考虑用自动化作为解决方法制造商业原因定义需要的功能候选评估演示检验决定约束第九十页，共148页。测试工具选择的策略了解被测系统的特性（运行平台、使用协议）需要工具提供的功能价格（足以完成测试任务的工具价格，包括License方式、培训价格、支持价格）学习曲线和培训成本对工具使用的支持不要对工具寄予不切实际的期望第九十一页，共148页。对测试工具的评估工具的功能工具的易用性使用的脚本语言是否被测试设计者熟悉报告能力平台支持能力是否支持特殊需求（代理服务器、IP欺骗、SessionID方式）第九十二页，共148页。创建还是购买？创建的优势最符合自己的需求可以在工具中补偿部分被测系统的不可测试性在文档和培训等方面不需要过多担心创建的缺点易用性和通用性可能不够问题可能较多第九十三页，共148页。购买的优势商品化的产品，比较稳定，能满足大部分需求拥有成本比自行开发要低良好的文档和支持购买的缺点可能无法满足某些个性化要求在考虑建立全公司的自动化测试体系时受限第九十四页，共148页。单元测试第九十五页，共148页。单元测试的概念关注的是单元功能和单元逻辑的实现通过白盒和黑盒测试的方式进行越早发现错误，改正的代价就越小值得注意的方面单元测试必须在设定目标的基础上进行单元测试并非越详细越好有了调试，为什么还需要单元测试？第九十六页，共148页。为什么需要做单元测试单元测试是设计的一部分越早，越少单元测试是里程碑成果单元测试是验证模块单元正常工作的最好评价过程提供了类文档的最佳格式增强开发人员对代码的信心是Refactory（重构）的基础第九十七页，共148页。单元测试应该由谁来做？谁开发，谁负责白盒测试需要对代码最了解的人来进行单元测试的测试方法依赖于IDE和框架单元测试是衡量代码工作是否完成的里程碑成果结论：单元测试应该毫无疑问地由开发人员进行第九十八页，共148页。单元测试过程第九十九页，共148页。单元测试主要角色PM质量保证人员QA度量协调员MC测试监督员项目组成员测试策略报告计划工具环境资源审核批准（UT）第一百页，共148页。单元测试的相关概念白盒测试语句覆盖路径覆盖黑盒测试因果图边界值等价区间异常测试第一百零一页，共148页。单元测试与开发过程瀑布开发模型迭代开发模型RUPeXtremeProgramming第一百零二页，共148页。单元测试执行中的角色与流程设计员－－制定单元测试计划设计员－－设计单元测试用例和测试驱动／桩程序员－－实现测试驱动／桩模块，执行测试程序员－－记录结果并形成报告设计员－－根据报告评估单元的实现情况第一百零三页，共148页。单元测试实作被测模块/桩模块/驱动模块面向对象系统中的单元测试单元测试方法白盒测试方法黑盒测试方法面向对象的考虑单元测试工具第一百零四页，共148页。面向对象系统的单元测试单元测试的单位是“类”单元测试对功能的关注通过对“接口”和“方法”的测试体现关注类的内部结构需要考虑对象的生命期对继承的接口的测试第一百零五页，共148页。桩模块与驱动模块被测模块桩模块桩模块驱动模块第一百零六页，共148页。对桩模块和驱动模块的说明在测试过程中，不一定需要实体的桩模块和驱动模块桩模块和驱动模块的开发只关注接口，记录/显示每次调用的情况，不包含任何容错处理第一百零七页，共148页。单元测试实作被测模块/桩模块/驱动模块面向对象系统中的单元测试单元测试方法白盒测试方法黑盒测试方法面向对象的考虑单元测试工具第一百零八页，共148页。单元测试中的白盒测试方法覆盖测试语句覆盖－－只要求每条语句至少执行一次路径覆盖－－要求每条可能的路径至少被执行一次执行路径控制更改变量值控制路径调试输出第一百零九页，共148页。语句覆盖与路径覆盖X=3X=0Y=5/XY=2*X第一百一十页，共148页。路径测试提示流图与独立路径独立路径－－包含至少一条以前未被包含的边V＝R（独立路径的上限＝流图的区域数）If(a>b||a>c){a=a+b;}else{a=a–b;}第一百一十一页，共148页。执行路径控制利用IDE集成环境利用其他调试工具利用输出的调试信息第一百一十二页，共148页。单元测试中的黑盒测试方法等价区间分析合法/非法输入数值：正数、负数、零字符串：长字符串、普通字符串、空字符串设计边界值循环的首次、第二次循环的最后一次和倒数第二次数组元素的第一个和最后一个数值类型的边界报表和屏幕位置的边界第一百一十三页，共148页。单元测试中的黑盒测试方法因果图异常测试测试系统的异常路径及异常处理第一百一十四页，共148页。单元测试实作被测模块/桩模块/驱动模块面向对象系统中的单元测试单元测试方法白盒测试方法黑盒测试方法面向对象的考虑单元测试工具第一百一十五页，共148页。面向对象的考虑从父类继承的成员是否不需要在子类中再次测试？对父类的测试能否照搬到子类？第一百一十六页，共148页。单元测试实作被测模块/桩模块/驱动模块面向对象系统中的单元测试单元测试方法白盒测试方法黑盒测试方法面向对象的考虑单元测试工具第一百一十七页，共148页。单元测试工具静态代码检查工具TelelogicLogiscopeRSM动态内存检查工具RationalPurifyCompuwareDevpartner覆盖率和性能辅助工具RationalPureCoverage、PurePerformanceCompuwareDevpartner第一百一十八页，共148页。xUnit单元测试框架JUnitCppUnitNUnitPerlUnit……xUnit的优势测试即设计测试用例就是文档Test-DrivenDevelopment可以与集成环境紧密集成不需要单独准备驱动模块和桩模块第一百一十九页，共148页。针对非功能需求的单元测试非功能需求建模要点模型非功能需求能分解到每个程序单元非功能需求有明确的验证手段SPE（软件性能工程）第一百二十页，共148页。技术评审第一百二十一页，共148页。产品测试流程第一百二十二页，共148页。技术评审的方式和方法正式评审书面的报告——记录了接受复审产品状况的书面报告复审小组全体成员的积极参与全体参与人员对复审活动的全面负责非正式评审一般采用邮件或是口头交流的非正式方式非正式评审用于小范围的非正式确认第一百二十三页，共148页。技术评审的作用通过技术评审体系，使产品质量处于监控之下根据经验，技术评审体系能够降低测试投入的50％－80％技术评审同时也是人员之间交流的一种良好渠道第一百二十四页，共148页。技术评审的对象任何阶段性成果，都可作为评审的对象需求文档设计文档代码单元测试报告测试方案测试报告……第一百二十五页，共148页。技术评审的一般过程第一百二十六页，共148页。技术评审的角色主持人角色事先向评审委员会发送评审通知，接收评委返回的意见在评审会议中充当记录员和协调者角色讲解人角色对被评审对象进行讲解（一般在代码走读中需要）评审委员会角色第一百二十七页，共148页。评审中常见的问题没有Review计划专家选择不合适没有充分的准备Review会议偏离主题和重点Review会议中过多的争论占用了大量时间问题修改后跟踪不力没有使用Checklist做指导第一百二十八页，共148页。技术评审的组织建议事先制定好评审的计划评审目的评审过程评审参与者评审时间和其他资源使用第一百二十九页，共148页。技术评审的组织建议选择合适的人会议主持人——好的协调者评委——对被评审内容能起到评审作用的人第一百三十页，共148页。技术评审的组织建议会后的跟踪确定每个问题的解决期限和跟踪人评审工作完成的标志并不是评审会议开完，更重要的是确保每个评审中发现的问题都能得到解决必要时，再次召集评审第一百三十一页，共148页。技术评审会议的注意事项不要把评审会变成了“上课”如果评委不能起到评审的作用，就另外寻找一个评委评审的主要工作在“会前”和“会后”，而不是会议中的时间避免争吵第一百三十二页，共148页。技术评审会议的建议至少提前2天通知相关评委如果不能收到评委的反馈，则可以考虑推迟评审或是更换评委评审会议限制在3小时内主持人最好不要是被评审对象相关人的直接领导评审是“对事不对人”第一百三十三页，共148页。软件测试的评估与总结第一百三十四页，共148页。目录软件测试的评估过程介绍软件测试的主要评测方法软件测试的总结第一百三十五页，共148页。软件测试评估-1目的评估测试结果，确定测试是否达到了预期质量要求，是否可以交付到下一个阶段。执行角色测试经理/开发经理/项目经理验证方式评审第一百三十六页，共148页。软件测试评估-2提供测试执行数据，证明测试过程完整的执行了测试计划的内容提供测试分析数据，证明系统的质量达到要求或者未达到要求提供模拟测试的结果，证明系统在实际运行环境中能够正常运行提供遗留问题及后续的解决