高级软件测试技术——2.ppt

《高级软件测试技术——2.ppt》由会员分享，可在线阅读，更多相关《高级软件测试技术——2.ppt（149页珍藏版）》请在三一文库上搜索。

1、高级软件测试技术,国信培训 段念 2005.12.17,课程说明,本课程的面向对象为测试经理、测试分析设计人员、测试工程师、项目经理、开发人员、质量相关人员 课程时间安排为 2 天，上午 9:00 12:00，下午 13:00 17:00 课程进行中，请关闭手机或是将手机调为震动 课程进行中，任何问题都可以随时向讲师提出，但讲师有权决定在何时进行解答,软件测试团队,测试组织结构,测试组织的构成,测试部门经理 测试项目经理/测试经理 测试代表 测试小组成员 软件测试工程师 硬件测试工程师 自动化测试工程师 其他技能人员,选择合适的成员,技能 经验和背景 类似的项目经验 个人性格和软技能 成员培训

2、,关注项目启动阶段,关注项目确定的范围 为即将到来的测试做好准备 项目背景 技能要求 用户态度 可能的参与模式 要注意的特殊事项,测试团队成员类型,老虎 牛 猴子 长颈鹿 狐狸 鼹鼠,有活力、有冲劲、聪明、能干、敏锐、不惧怕压力,踏实、勤劳、敬业 ，但缺乏创造力,聪明、大胆、活跃 ，但缺乏耐心,最有前瞻能力 ，但缺乏执行力,看上去最为忙碌的一个 ，但总是躲在事情的背后,永远的茫然,不同类型员工的对策,鼹鼠,拿掉他用来隐藏自己的“多任务”，明确交给他少数的任务,狐狸,参谋。在规划部门发展的时候，可以多听听他们的意见，但最好不要完全交由他去进行,长颈鹿,部门新技术研究的不二人选，但必须时刻监控他的

3、工作进展,猴子,让他做自己最擅长的事情,牛,给他挑战，把部门最重要的、最困难的工作交给他,老虎,部门氛围的营造,学习型组织 学习的交流的氛围 部门讲师制度 专题研究 鼓励参与外部交流 制度和流程 制度流程先行 知识不仅仅是个人的，首先是团队的,部门讲师制度,原则 讲师既是荣誉，也是责任 将讲师的传播工作作为绩效的组成部分 讲师聘用制度 部门讲师的认证方法 自行报名 考核认证 发证,测试经验库,“从实践中来，到实践中去” 测试经验库的几个层次 普适性的测试经验（测试设计经验、测试执行经验） 针对具体产品的测试经验 针对规范的测试经验 测试经验库的载体 Excel 文档 自行开发的信息系统 采用

4、Wiki 作为载体,测试规范,测试规范是另一种形式的测试经验积累 测试规范的类型 界面测试规范 XX产品测试规范 XX模块测试规范 WEB应用性能测试规范 ,围绕测试用例的测试工作,什么样的用例才是好的用例？ 首选，评价用例的好坏要从“总体”的角度来考虑覆盖性、有效性 其次，用例应该具有基本的要素用例编号、用例名称、用例前置条件、用例步骤、用例的输入数据、用例预期结果、验证用例的方法,用例示例,用例示例.doc,测试工程师绩效评价的难点,测试不是构造工作，因此无法用确切的构造成果来评价 测试不能提高质量，因此产品质量不是评价测试的唯一因素 测试不是纯粹的技术工作，测试还应该包括许多沟通和协调的

5、工作,测试工程师的绩效评估框架,事后评价 工作成果评价 非技术因素评价 组织建设评价,事后评价,通常，我们可以通过对测试产品的质量评价的一部分反映测试人员的工作效果 现场发现问题数 / 测试发现问题数,工作成果评价,用例设计效率 用例执行效率 发现缺陷数量 工作规范化程度 相关问题：测试组织的基准效率,非技术因素评价,一个好的测试人员不是发现问题最多的测试人员，而是使自己发现的问题最多得到解决的测试人员。 Software Testing 沟通能力 协作能力 受欢迎程度 评价的方法：360度考核,组织建设评价,在测试理念推广上发挥的作用 在测试工具研究上发挥的作用 在测试自动化方向上发挥的作用

6、 为测试经验库和规范库贡献的成果 其他与组织建设相关的工作 建议方法：将所有这些纳入日常工作管理范围内，例如，月度计划、周报和日报,测试度量,测试是什么,测试是一个系统工程 测试是设计和实现一种特定软件系统的过程 测试的目标是发现缺陷 测试是一个发现缺陷的过程 测试的手段是 V（Verify）& V（Validate） 测试是对依据系统预期行为设计的测试用例的动态验证（Dynamic Verification）过程，目的是发现程序中的缺陷 SWEBOK 2004,测试度量过程,测试现状 CMM 3级的经验数据： 千行代码错误数：2.39 美国国防部经验数据： 千行代码错误数 0.01,测试度量

7、过程,度量分析过程提供对其它相关过程的支持，是一个支持过程。度量分析过程指导项目和组织将度量需求和目标与提供客观有用结果的度量活动结合起来，从而帮助项目和组织制定有用的决策并采取适当的纠正措施。 为有效开展度量分析活动，度量分析过程需遵守一些准则和规范： A) 度量活动要满足相关方对数据的需求； B) 与所投入的资源相比较，度量结果是有价值的； C) 严格按照组织定义（或经批准的裁剪）的度量说明来执行。,测试度量过程,测试度量过程,测试度量过程,测试度量过程 制定度量计划的过程 确定目标 识别关键过程 选择和定义度量 选择度量 定义度量：必须创建操作定义告诉人们如何进行度量，而且要足够详细到其

8、他人如果遵循同样的步骤也可以得到相同的结果 集成度量到过程中,测试度量过程,测试度量过程 选择度量 过程执行情况：度量由过程产生的产品的属性，如规模；度量该过程本身的属性，如工作量。 A. 确定度量的GQM方法 ：GQM（Goal-Question-Measure）即“目标-问题-度量”方法，通过设立目标、提出问题、回答问题三个步骤来确定选择什么度量。 B. 过程中的度量实体： 关键过程中有很多对象可以度量，过程所接收的事物、过程产生的事物、过程中的活动、过程中所消耗的事物，以及作为过程的结果而保留的事物（缺陷数、笔记、会议记录）都是可以被度量的对象，我们称之为实体。 C. 基础度量和衍生度量

9、 D. 选择有用度量的标准 E. 操作定义,测试度量过程,选择有用度量的标准 依据如下标准评价潜在的度量是否真的有价值： 度量与问题紧密相关； 能提供足够的信息来说明问题； 通过了事实的测试，如度量是否真的反映了过程对重要结果的实现程度； 数据收集起来容易、有效，不需花费太多的工作量； 使来源不同的相同度量数据一致、不矛盾； 度量后能够显示出可比较的差异； 形成数据集合时，可以用来诊断问题。,测试度量过程,操作定义 对于所选择的每个度量，应当建立相应的操作定义，遵守以下三个原则，是定义出好的数据的基础： 可传达。其他人可以清楚地知道度量了什么，怎样度量，度量单位是什么，包括什么不包括什么？ 重

10、复性。度量是否可以重复，给出同样的定义，其他人能否取得同样的结果？ 可追踪。根据数据的收集时间、顺序、活动、产品、过程的状态、环境、使用的度量工具和收集方式，能够识别数据的来源,测试度量过程,操作定义 每个操作定义应包括以下内容 实体。被度量实体的名称和描述。 属性。被度量实体属性的名称和描述。 值。对于每个属性，说明度量的单位（如数目、小时）和可能的值或值的范围。说明哪个值要包括，哪个值不包括。 来源。说明产生数据的过程以及数据在哪里被报告，收集或报告的机制，使用的度量工具等。,测试度量过程,度量模型,现执行项目数据库（DC） 数据收集,项目层,组织层,过程数据库 PDB,过程能力基线 PC

11、B,项目结束,指导,分析,EPG：度量组 MG,项目性能分析,组织过程能力分析,测试度量过程,测试度量角色,MC,TQA,EPG,测试人员,TM,PDT 开发代表,MG,测试度量过程,产品级别度量指标 产品故障率（次/套*年） 网上遗留问题次级密度（NPR） 系统终端 网上问题及时解决率 网上逾期问题解决率 总返还率 内部问题累计解决率 设计更改/工程更改/计划月更改频率 产品关键交付件缺陷发现密度,测试度量过程,项目级别度量 两种度量类型：过程度量和交付件度量 过程度量：规模、测试工作量、测试进度、测试生产率 交付件度量：缺陷率（阶段）、缺陷排除率、可靠性等 四个基本度量项： 规模 工作量

12、进度 缺陷,测试度量过程,测试度量指标（一）,测试度量过程,测试度量指标（二）,测试度量过程,测试度量指标（三）,测试度量过程,测试组织能力基线 CB依据收集到的度量数据建立的组织级能力基线数据，从而反映组织的开发能力和成熟度,自动测试原理,目录自动测试,测试过程中的不同种选择 自动化工具原理 自动化工具特征 回归测试 基于GUI的自动测试工具 自动化功能测试和回归测试的优点 存在的问题分析 基于功能的自动测试工具简介,测试过程中的不同选择,案例故事,对不同测试工程师的评价,测试员1 是一个典型的手动测试者， 从键盘手动运行所有的测试。手动测试在当前的工业界很普遍它能提供直接的好处，但长时间的

13、运行会让测试人员感到单调乏味， 对公司来讲成本高，效率低。 “我看到的最悲哀的景象之一就是一个人在键盘上手动操作一些可以自动运行的东西。这是悲哀的但也是有趣的。” Boris Beizer， 黑盒测试： 软件和系统功能测试技术,对不同测试工程师的评价,测试员2 实践的是称为静态测试自动化的测试。静态自动化脚本每次根据同样的次序执行同样的命令序列。当应用程序发生变化时这些脚本的维护成本很高。测试是不断重复的；但由于它们总是执行相同的命令， 因此它们很难发现新的错误。 “高度重复的测试实际上将发现所有重要问题的几率最小化了，这和沿着别人的足迹前行将发现自己的天地的几率最小化的原因是一样的” Jam

14、es Bach， “骗人的测试自动化,”Windows 技术期刊,1996.10,对不同测试工程师的评价,测试员3 操作接近于自动化测试的边缘。这些类型的随机测试程序被称为蠢猴，因为它们就是毫无目的的敲打键盘。它们生成非常规的测试执行序列并发现很多致命的错误，但是想控制它们到应用程序中你想测试的部分却是很困难的。因为它们不知道自己在做什么，所 以它们会漏过应用程序中很多明显的错误。 “猴子式的测试不能是你测试的全部。猴子不明白你的应用程序，由于它们的无知它们漏掉了很多错误。” Noel Nyman， “使用猴子式的测试工具,” SQTE,2004.1/2,对不同测试工程师的评价,测试员4 通过

15、一种称为“模型驱动测试”的智能测试自动化方法糅合了其它测试员的方法。模型驱动测试并不像静态测试自动化那样逐字逐句的记录测试序列，也不盲目的在键盘上敲打。模型驱动测试通过对应用行为的描述来判断哪些操作是可能的、期望输出是什么。这种方式不断自动生成新的测试序列，很好的适应了应用程序的变化，能够同时在多台机器上运行， 并能整天运行。 “一个艺术家用他的智慧画画， 而不是用他的手。” Michelangelo Buonarroti,启示,测试员1 的方法需要他的手不停的在键盘上工作。最后测试员1精疲力竭。 测试员2 的静态脚本重复他的手已经执行过的那些键盘操作。 测试员3 的猴子式测试本质上是无目的的

16、在键盘上乱敲。 测试员4,从另一方面， 在其它技术上进行了补充： 思考应用程序的行为，将行为描述给一个测试生成程序，让测试生成程序来创建和运行测试用例。 通过根据应用程序行为描述生成测试，测试员4 能够执行那些在 使用其它测试方法时不可实现的测试。 这个故事的寓意： 自动化你的大脑， 而不只是你的手。,对测试自动化不切实际的期望,所有的测试都能够实现自动化！ 既然自动化测试能如此显著地提高生产率，我们就能以更少的人员完成所有的测试（精减人员）。 自动化测试如此简单，我们无需任何培训。 自动化方法将缩减整体测试工作量。 我们无需制订任何测试方案。 有了自动化测试，测试人员不就成了“过时的”或“多

17、余的”了吗？ 那种耗时的测试设计工作不再必要了。,自动化测试不是银弹,自动化测试，或者说自动化测试策略及工具的实现，只是测试人员工具箱里的一件利器。,确定自动化测试的“用武之地“,将所有工作中的特定部分作为应用自动化的候选对象。 从高度冗余的任务或场景开始考虑。 将乏味且人工容易出错的工作进行自动化。 首先关注开发成熟、理解透彻的用例或场景。 优先选择应用中相对稳定的部分，而非易变的部分。 通过使用数据驱动的测试技术来提高自动化功效（增加测试覆盖的深度和广度）。 指派几位专家负责自动化，不要让测试团队的每个人都做这项工作。 牢记不要追求100%的自动化，手工测试仍然至关重要。,自动化工具原理,

18、自动化是相对手工测试而言的 将手工测试过程记录下来； 通过输入，测试输出结果是否正确 替换手段：通过串口，网络，Windows消息机制，函数调用等手段为一个对象提供自动化输入； 比较实际输出和期望输出 替换手段：将输出通过串口，网络，界面等输出并记录下来； 负载测试 多个输入同时施加到被测试对象上；,自动化测试工具的特征,1 支持脚本化语言(Scripting Language) 支持多种常用的变量和数据类型 支持数组、列表、结构、以及其他混合数据类型 支持各种条件逻辑（IF, CASE 等语句） 支持循环( FOR, WHILE) 支持函数的创建和调用 Perl , vb script ,

19、java script 脚本语言的功能越强大，就越能够为测试开发人员提供更灵活的使用空间，而且有可能用一个复杂的语言写出比被测试软件还要复杂的测试系统。,自动化测试工具的特征（续）,2 对程序界面中对象的识别能力 :鼠标位置识别,对象识别，位图对象识别（图像比较） 3 支持函数的可重用：脚本比较容易实现对函数的调用，脚本与被调用函数之间的参数传递； 4 支持外部函数库：如Windows 中DLL访问，如采用外部函数进行数据库操作正确性检查等；,自动化测试工具的特征（续）,5 抽象层：抽象层将程序界面中存在的所有对象实体一一映射成逻辑对象，通过简单修改抽象层，帮助减少测试维护工作量。 6 分布式

20、测试（Distributed Test）：分布式测试可以实现定制任务执行的时间表，安排多人同时进行测试,自动化测试工具的特征（续）,7 支持数据驱动测试（Data Driven Test）：测试脚本通过从实现准备好的数据文件中读取或者写入数据保证测试流程的正常执行，少的脚本，大量的测试数据即可。 8 错误处理：在出现问题时能够跳过错误或者对系统进行复位，执行后面的任务，从而不至于出现一个问题而耽误了所有用例的执行； 9 调试器（Debugger）：调试器要能够支持脚本单步执行、设置断点、核对变量返回结果等，有的还可以跟踪进入可执行程序，外部调用的函数库等；,自动化测试工具的特征（续）,10 源

21、代码管理 可以帮助我们进行测试脚本库的导入，导出，回退到以前版本，比较不同版本间的差别，以及同时对几个项目进行跟踪等，尤其在团队开发 中很有必要，可以对测试数据文件，测试脚本，对象抽象层进行统一管理 11 支持脚本的命令行方式（Command Line ）： 如机器启动、程序BUILD后可以自动启动测试脚本执行等。,回归测试,Add appropriate verification,Enable tests to use variable data,Run tests & review actual and expected results,Capture business process i

22、nto a test script,Reuse and re-run tests as application changes,功能性和回归测试流程,基于GUI的自动化测试工具,基本原理： 基于手工测试，基于已设计好的测试用例 在测试者运行应用程序的同时，将其所有动作（键盘操作、鼠标点击等）捕捉下来，生成一个脚本文件，这个脚本以后可以被“回放”（playback），也就是按照上一步的所有动作重复执行一次，实现自动运行和测试。,俘获/回放工具的分类,允许用户使用脚本语言去模拟GUI操作的需要。 这种俘获/回放工具通常是作为多平台应用，但需要额外的脚本程序编程。 工具提供自动记录和回放用户手动操作

23、的能力而不要用脚本。 这种工具很容易使用，但作为多平台应用需要更多的人工操作,自动化功能测试和回归测试的优点,覆盖大部分的系统测试 提高效率来把精力专注于新模块 创建可重用的测试模块 减少人为错误,存在的问题及分析,测试针对程序界面进行，一旦界面有改动，都需要手工修改已经录制好的相应测试脚本，或者重新进行录制。 尤其是程序中各模块都需要使用的一些公共程序部分（如用户登录界面），改动会引起大量测试工作的返工，造成测试脚本的日常维护工作量急剧增大；,手段,在被测试应用程序和录制生成的测试脚本之间增加一个抽象层，可以将程序界面上的所有元素映射成相对应的一个逻辑对象，测试就可以针对这些逻辑对象进行，而

24、不需要依赖于界面上元素的变化； 建议把一些公共使用的函数进行封装，做成可重用的函数库,分 析,最后，可以把测试执行过程中所需要的测试数据做成文件的形式，测试脚本在运行时能够随时从此文件读取预先定制好的数据，这样脚本和数据就可以独立维护 一个好的自动化测试工具其实与一个好的开发工具有很多相似的特性，也可以说：一个自动化测试过程实际也是一个软件开发的过程。,自动化数据测试,数据测试需要两个关键因素 采集大量的产品数据 为不同的数据集合准备测试脚本,Automated Test Script,Application,Data Source,自动化创建可维护和可重用的测试,应用的改变不需要改变测试脚本

25、,Test 1,Test 2,Test 3,可重用对象库,功能测试自动化工具,组织级自动化测试的三个阶段,第一阶段：Non_programmer Tester 第二阶段：Every Test is a Program 第三阶段：Effective Automation Test,测试技术与测试自动化,第一阶段：Non_programmer Tester 没有专职的测试脚本开发工程师 自动化测试是一种项目组自发行为 目前大部分公司的现状：项目组有空时或被领导推动时会研究一次测试技术，大多不了了之。,测试技术与测试自动化,第二阶段：Every Test is a Program 要求每个测试人员都

26、非常熟悉测试工具； 并且有深厚的专业知识背景，如使用ITT需要掌握：TCL、ASN.1、协议、数据库等知识； 存在问题： 要实现自动化，对每个测试人员的要求都很高，测试成本高，资源外包的优势难以体现。 以GUI的自动测试为例说明，此阶段自动化测试的问题是效率不高，在编写脚本的层次上重复，解脱的方法只有一种：测试设计。,测试技术与测试自动化,第三阶段：Effective Automation Test 测试设计与测试自动化职责分开； 测试工具有专门的自动化程序员开发和维护 测试设计采用电子表格编写测试用例，自动化程序员编写测试脚本、功能语句、处理引擎，负责并实现三者之间的有机结合。,测试技术与测

27、试自动化,不适合自动化测试的领域 一次性项目 项目周期很短的项目 业务规则复杂的项目 美观、音质、易用性测试 系统不稳定 涉及物理交互 自动化测试的误区 期望自动化测试完全替代手工测试 期望自动化测试发现大量新的缺陷,性能测试工具,性能测试工具原理概述 常用性能测试工具介绍 性能测试工具的选择与评估 构建还是购买,性能测试工具原理,基于功能测试工具，需要增加加载和监测分析手段；,压力测试工具原理,脚本 工具,控制 调度 工具,压力 产生器,资源 监视器,报表和 结果 分析工具,常用性能测试工具介绍,MI的LoadRunner（http:/http:/ 支持多种协议（HTTP/HTTPS、FTP

28、、SMTP、POP、数据库协议支持） 能测试两层、三层应用 良好的报表分析支持 能和MI的其他产品很好集成 拥有较大用户群 价格是最大的问题，按照并发用户数收取License费用,常用性能测试工具介绍,Seague 的 Silk Performer （http:/） 功能上与LoadRunner相当 支持多种协议 价格比 LR 便宜 国内的使用者不多，但在国外拥有广大的用户群,常用性能测试工具介绍,WebLoad（http:/） 专用于Web测试，是“轻量级”的WEB测试工具 只支持HTTP/HTTPS协议 价格相对便宜 运行于Windows平台上,常用性能测试工具介绍,免费工具WAS（htt

29、p:/） 在某些场合下可以应用，运行于Windows平台 没有脚本支持 对SessionID没有办法支持 Microsoft不提供支持，也没有版本更新 WAS的后续版本是ACT，不过已经不再是免费的了,常用性能测试工具介绍,开源工具OpenSTA（www.opensta.org） 专用于Web测试，只支持HTTP/HTTPS协议 良好的脚本支持，脚本功能强大 运行于Windows平台 有庞大的社区支持 脚本语言的复杂度要高于LoadRunner 没有中文手册,常用性能测试工具介绍,Apache JMeter（http:/jakarta.apache.org/jmeter/index.html）

30、 支持多种协议（目前已支持的包括HTTP/HTTPS、FTP、Telnet、SMTP，还可通过插件扩展） 不支持数据库协议 用JAVA编写，可运行在多个平台上,白盒测试的性能测试工具,Compuware Numega Compuware DevPartner Rational Purify Rational Performance ,其他性能测试工具,Compuware的QACenter Performance Edition（http:/） IBM 的 Rational Robot（http:/） 开源工具theGrinder（http:/ http:/www.sourceforge.org

31、 http:/www.junit.org/ http:/ 需要工具提供的功能 价格（足以完成测试任务的工具价格，包括License方式、培训价格、支持价格） 学习曲线和培训成本 对工具使用的支持 不要对工具寄予不切实际的期望,对测试工具的评估,工具的功能 工具的易用性 使用的脚本语言是否被测试设计者熟悉 报告能力 平台支持能力 是否支持特殊需求（代理服务器、IP欺骗、SessionID方式）,创建还是购买？,创建的优势 最符合自己的需求 可以在工具中补偿部分被测系统的不可测试性 在文档和培训等方面不需要过多担心 创建的缺点 易用性和通用性可能不够 问题可能较多,购买的优势 商品化的产品，比较稳

32、定，能满足大部分需求 拥有成本比自行开发要低 良好的文档和支持 购买的缺点 可能无法满足某些个性化要求 在考虑建立全公司的自动化测试体系时受限,单元测试,单元测试的概念,关注的是单元功能和单元逻辑的实现 通过白盒和黑盒测试的方式进行 越早发现错误，改正的代价就越小 值得注意的方面 单元测试必须在设定目标的基础上进行 单元测试并非越详细越好 有了调试，为什么还需要单元测试？,为什么需要做单元测试,单元测试是设计的一部分 越早，越少 单元测试是里程碑成果 单元测试是验证模块单元正常工作的最好评价过程 提供了类文档的最佳格式 增强开发人员对代码的信心 是Refactory（重构）的基础,单元测试应该

33、由谁来做？,谁开发，谁负责 白盒测试需要对代码最了解的人来进行 单元测试的测试方法依赖于IDE和框架 单元测试是衡量代码工作是否完成的里程碑成果 结论：单元测试应该毫无疑问地由开发人员进行,单元测试过程,单元测试主要角色,PM,质量保证人员 QA,度量协调员 MC,测试监督员,项目组成员,测试策略,报告,计划,工具,环境,资源,审核批准（UT）,单元测试的相关概念,白盒测试 语句覆盖 路径覆盖 黑盒测试 因果图 边界值 等价区间 异常测试,单元测试与开发过程,瀑布开发模型 迭代开发模型 RUP eXtreme Programming,单元测试执行中的角色与流程,设计员制定单元测试计划 设计员设

34、计单元测试用例和测试驱动桩 程序员实现测试驱动桩模块，执行测试 程序员记录结果并形成报告 设计员根据报告评估单元的实现情况,单元测试实作,被测模块/桩模块/驱动模块 面向对象系统中的单元测试 单元测试方法 白盒测试方法 黑盒测试方法 面向对象的考虑 单元测试工具,面向对象系统的单元测试,单元测试的单位是“类” 单元测试对功能的关注通过对“接口”和“方法”的测试体现 关注类的内部结构需要考虑对象的生命期 对继承的接口的测试,桩模块与驱动模块,被测模块,桩模块,桩模块,驱动模块,对桩模块和驱动模块的说明,在测试过程中，不一定需要实体的桩模块和驱动模块 桩模块和驱动模块的开发只关注接口，记录/显示每

35、次调用的情况，不包含任何容错处理,单元测试实作,被测模块/桩模块/驱动模块 面向对象系统中的单元测试 单元测试方法 白盒测试方法 黑盒测试方法 面向对象的考虑 单元测试工具,单元测试中的白盒测试方法,覆盖测试 语句覆盖只要求每条语句至少执行一次 路径覆盖要求每条可能的路径至少被执行一次 执行路径控制 更改变量值控制路径 调试输出,语句覆盖与路径覆盖,X=3,X=0,Y=5/X,Y=2*X,路径测试提示,流图与独立路径 独立路径包含至少一条以前未被包含的边 VR（独立路径的上限流图的区域数）,If (a b | ac) a = a + b; else a = a b; ,执行路径控制,利用IDE

36、集成环境 利用其他调试工具 利用输出的调试信息,单元测试中的黑盒测试方法,等价区间分析 合法/非法输入 数值：正数、负数、零 字符串：长字符串、普通字符串、空字符串 设计边界值 循环的首次、第二次 循环的最后一次和倒数第二次 数组元素的第一个和最后一个 数值类型的边界 报表和屏幕位置的边界,单元测试中的黑盒测试方法,因果图 异常测试 测试系统的异常路径及异常处理,单元测试实作,被测模块/桩模块/驱动模块 面向对象系统中的单元测试 单元测试方法 白盒测试方法 黑盒测试方法 面向对象的考虑 单元测试工具,面向对象的考虑,从父类继承的成员是否不需要在子类中再次测试？ 对父类的测试能否照搬到子类？,单

37、元测试实作,被测模块/桩模块/驱动模块 面向对象系统中的单元测试 单元测试方法 白盒测试方法 黑盒测试方法 面向对象的考虑 单元测试工具,单元测试工具,静态代码检查工具 Telelogic Logiscope RSM 动态内存检查工具 Rational Purify Compuware Devpartner 覆盖率和性能辅助工具 Rational PureCoverage、PurePerformance Compuware Devpartner,xUnit单元测试框架,JUnit CppUnit NUnit PerlUnit ,xUnit的优势 测试即设计 测试用例就是文档 Test-Driv

38、en Development 可以与集成环境紧密集成 不需要单独准备驱动模块和桩模块,针对非功能需求的单元测试,非功能需求建模 要点 模型 非功能需求能分解到每个程序单元 非功能需求有明确的验证手段 SPE（软件性能工程）,技术评审,产品测试流程,技术评审的方式和方法,正式评审 书面的报告记录了接受复审产品状况的书面报告 复审小组全体成员的积极参与 全体参与人员对复审活动的全面负责 非正式评审 一般采用邮件或是口头交流的非正式方式 非正式评审用于小范围的非正式确认,技术评审的作用,通过技术评审体系，使产品质量处于监控之下 根据经验，技术评审体系能够降低测试投入的5080 技术评审同时也是人员之

39、间交流的一种良好渠道,技术评审的对象,任何阶段性成果，都可作为评审的对象 需求文档 设计文档 代码 单元测试报告 测试方案 测试报告 ,技术评审的一般过程,技术评审的角色,主持人角色 事先向评审委员会发送评审通知，接收评委返回的意见 在评审会议中充当记录员和协调者角色 讲解人角色 对被评审对象进行讲解（一般在代码走读中需要） 评审委员会角色,评审中常见的问题,没有 Review 计划 专家选择不合适 没有充分的准备 Review 会议偏离主题和重点 Review 会议中过多的争论占用了大量时间 问题修改后跟踪不力 没有使用 Checklist 做指导,技术评审的组织建议,事先制定好评审的计划

40、评审目的 评审过程 评审参与者 评审时间和其他资源使用,技术评审的组织建议,选择合适的人 会议主持人好的协调者 评委对被评审内容能起到评审作用的人,技术评审的组织建议,会后的跟踪 确定每个问题的解决期限和跟踪人 评审工作完成的标志并不是评审会议开完，更重要的是确保每个评审中发现的问题都能得到解决 必要时，再次召集评审,技术评审会议的注意事项,不要把评审会变成了“上课” 如果评委不能起到评审的作用，就另外寻找一个评委 评审的主要工作在“会前”和“会后”，而不是会议中的时间 避免争吵,技术评审会议的建议,至少提前2天通知相关评委 如果不能收到评委的反馈，则可以考虑推迟评审或是更换评委 评审会议限制

41、在3小时内 主持人最好不要是被评审对象相关人的直接领导 评审是“对事不对人”,软件测试的评估与总结,目录,软件测试的评估过程介绍 软件测试的主要评测方法 软件测试的总结,软件测试评估-1,目的 评估测试结果，确定测试是否达到了预期质量要求，是否可以交付到下一个阶段。 执行角色 测试经理/开发经理/项目经理 验证方式 评审,软件测试评估-2,提供测试执行数据，证明测试过程完整的执行了测试计划的内容 提供测试分析数据，证明系统的质量达到要求或者未达到要求 提供模拟测试的结果，证明系统在实际运行环境中能够正常运行 提供遗留问题及后续的解决办法，便于评审人员对质量进行判断,软件测试的主要评测方法,覆盖

42、评测 基于需求的测试覆盖 基于代码的测试覆盖 缺陷分析 缺陷报告 缺陷密度 缺陷龄期 缺陷趋势 性能评测 动态监测 响应时间/吞吐量 百分位报告 比较报告 追踪和配置文件报告,覆盖评测,覆盖指标提供了“测试的完全程度如何？”这一问题的答案。 最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。 简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。,基于需求的测试覆盖,基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、

43、已执行的和成功的测试覆盖）。 测试覆盖通过以下公式计算： 测试覆盖 = T(p,i,x,s) / RfT 其中： T 是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。 RfT 是测试需求 (Requirement for Test) 的总数。,基于代码的测试覆盖,基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之

44、前是否已作定义。 基于代码的测试覆盖通过以下公式计算： 测试覆盖 = Ie / TIic 其中： Ie 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。 TIic (Total number of Items in the code) 是代码中的项目总数。,缺陷分析,对于缺陷分析，常用的主要缺陷参数有四个： 状态：缺陷的当前状态（打开的、正在修复或关闭的等）。 优先级：必须处理和解决缺陷的相对重要性。 严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。 起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。,缺陷报告,缺陷分布（密度）报告显示缺

45、陷在不同模块，业务单元中的分布情况。 缺陷龄期报告是一种特殊类型的缺陷分布报告。 缺陷龄期报告显示缺陷处于特定状态下的时间长短，如“提出的”。在龄期类别中，缺陷还可以按其他属性分类，如“拥有者”。 缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。,性能评测,评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。 主要的性能评测包括： 动态监测 - 在测试执行

46、过程中，实时获取并显示正在执行的各业务单元的响应时间了资源分配状态。 响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测（关键业务、重点环节）。 比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。 （并行测试或者系统发生变更时）,软件测试总结-1,目的 对测试工作进行得失的总结，收集可以复用的资源。 执行角色 测试经理/测试工程师 验证方式 测试主管审阅,软件测试总结-2,测试经理组织测试人员编制测试总结报告 收集测试过程数据，统计分析，总结测试执行过程的得与失 收集测试结果数据，统计分析，总结测试计划，方案，设计方法的改进方式 收集测试用例并根据可重用原则进行筛选、分类，纳入知识库,自由提问时间,个人联系方式,Email： Email： 个人Blog：http:/,谢 谢！,