(完整版)1.测试概述(软件测试).ppt

《(完整版)1.测试概述(软件测试).ppt》由会员分享，可在线阅读，更多相关《(完整版)1.测试概述(软件测试).ppt（111页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1.测试概述课程内容软件测试的背景软件测试概述软件测试技术软件测试方法软件测试模型软件测试过程软件测试人员例子软件错误失效案例迪斯尼的狮子王游戏 时间：1994 1995 背景：迪斯尼公司首次进军儿童游戏市场，市场宣传力度很大，前期销售情况很好 出现的问题：该游戏在一些PC 机上无法玩 原因：迪斯尼公司没有对市场上已经投入运行的PC 机型进行调研，并且进行测试，导至该游戏只在程序员开发游戏的系统上可以运行，但在大众使用的常见系统中无法运行 结果：迪斯尼公司不得不承担客户的投诉、产品退货、更换光盘、以及又一轮的调试、修改和测试的所有费用。软件错误失效案例迪斯尼的狮子王游戏 时间：1994 199

2、5 背景：迪斯尼公司首次进军儿童游戏市场，市场宣传力度很大，前期销售情况很好 出现的问题：该游戏在一些PC 机上无法玩 原因：迪斯尼公司没有对市场上已经投入运行的PC 机型进行调研，并且进行测试，导至该游戏只在程序员开发游戏的系统上可以运行，但在大众使用的常见系统中无法运行 结果：迪斯尼公司不得不承担客户的投诉、产品退货、更换光盘、以及又一轮的调试、修改和测试的所有费用。软件错误失效案例Intel 奔腾浮点除法软件缺陷 时间：1994 背景：Intel 发布的一款新处理器 问题：在装有这款处理器计算机的计算器中执行算式“(4195835/3145727)3145727-4195835”不等于0

3、 原因：老式奔腾CPU 的浮点除法软件有缺陷 结果：Intel 事实上在芯片发布之前，已经发现了这个缺陷，但认为不严重，没有修正。被外界发现后，试图掩饰。最终，迫于舆论压力公开道歉，花费4 亿美元更换老芯片。软件错误失效案例Intel 奔腾浮点除法软件缺陷 时间：1994 背景：Intel 发布的一款新处理器 问题：在装有这款处理器计算机的计算器中执行算式“(4195835/3145727)3145727-4195835”不等于0 原因：老式奔腾CPU 的浮点除法软件有缺陷 结果：Intel 事实上在芯片发布之前，已经发现了这个缺陷，但认为不严重，没有修正。被外界发现后，试图掩饰。最终，迫于舆

4、论压力公开道歉，花费4 亿美元更换老芯片。软件错误失效案例美国航天局火星极地登陆 时间：1999 年12 月3 日 背景：火星极地登陆飞船在试图登陆火星表面时失踪。问题：某一个数据位被意外复位.原因：为了省钱，采用一个廉价的触点开关来控制关闭推进器。但是由于飞船脚迅速打开的机械震动，大多数情况下也会打开触点开关，并设置错误的数据位。测试过程分两组：一组是测试飞船脚的落地打开过程；另一组是测试飞船打开后的着陆过程；前一组没有注意数据位是否被置位，因为这不是他们负责的范围。而后一个组在每次测试之前又重置计算机，清除所有的数据位。双方独立工作都很正常，但两个组没有进行集成测试。结果：飞船坠毁软件错误

5、失效案例千年虫 时间：20 世纪90 年代 背景：随着21 世纪的到来，很多的计算机系统都面临着“千年虫”的危害 问题：这样就导致2000 年以后的年份的记录出现问题，如00 年是指1900 还是2000？原因：20 实际70 年代时，由于计算机存储空间很小，并且十分昂贵，所以在计算机中记录时间采用了“偷懒”的方式，例如将1973 缩减为73 结果：世界各地为了更换和升级系统，花费了上百亿的美元软件缺陷的定义软件未达到产品说明书中已经标明的功能；软件出现了产品说明书中指明不会出现的错误；软件未达到产品说明书中虽未指出但应当达到的目标；软件功能超出了产品说明书中指明的范围；软件测试人员认为软件难

6、以理解、不易使用，或者最终用户认为该软件使用效果不良。举例：计算器内的嵌入式软件软件缺陷的示例软件未达到产品说明书标明的功能 计算器的产品说明书声称：“它能够准确无误的进行加减乘除运算”。测试人员输入“5/0”，如果没有反应或出现错误的反映，则根据上述规则，这是一个软件缺陷。软件出现了产品说明书指明不会出现的错误 说明书声称“计算器永远不会崩溃、死锁”。如果狂敲键盘会使计算器停止接受输入，那么根据第2 条，这是一个缺陷。软件功能超出了产品说明书指明的范围 如果计算器产品说明书只说明了其能够完成加减乘除的运算，而在实际中发现其还可以进行平方根的运算，这是缺陷。软件缺陷的示例软件未达到产品说明书虽

7、未指出，但应该达到的目标 对于测试人员来讲，这实际上是为了找出产品说明书中的遗漏之处。例如，在测试计算器时，发现电池没电时会导致计算不正确。说明书中可能没有提及这一点，这是缺陷软件测试人员认为软件难于理解、不易使用、运行速度慢，或者最终用户认为不好 这是一个含盖比较广的规则。测试人员往往是真正使用软件的第一人，扮演着客户的角色。如果发现有什么不对劲的地方，无论什么原因都要认定为是软件缺陷。例如，某个按钮的位置不好，界面的格局设计不符合习惯，颜色太刺眼等；缺陷的分类（1）1.轻微 词语拼写错误2.中等 误导或重复信息3.使人不悦 被截断的名称，0.00 美元账单4.影响使用 有些交易没有处理5.

8、严重 丢失交易6.非常严重 不正确的交易处理7.极为严重 经常出现“非常严重”的错误8.无法忍受 数据库破坏9.灾难性 系统停机10.容易传染 扩展到其它系统的系统停机缺陷的分类：根据严重程度分类缺陷的分类（2）1.输入输出缺陷2.逻辑缺陷3.计算缺陷4.接口缺陷5.数据缺陷缺陷的分类：按性质和范围分类 缺陷的分类（3）缺陷的分类：按软件的生存周期分类 1.问题定义（需求分析）错误 在软件定义阶段，分析员研究用户的要求后所编写文档中出现的错误。换句话说，这类错误是由于问题定义不满足用户的要求而导致的错误。缺陷的分类（3）缺陷的分类：按软件的生存周期分类 2.规格说明错误 这类错误是指规格说明与

9、问题定义不一致所产生的错误。它们又可以细分成：不一致性错误：规格说明中功能说明与问题定义发生矛盾。冗余性错误：规格说明中某些功能说明与问题定义相比是多余的。不完整性错误：规格说明中缺少某些必要的功能说明 不可行错误：规格说明中有些功能要求是不可行的。不可测试错误：有些功能的测试要求是不现实的。缺陷的分类（3）缺陷的分类：按软件的生存周期分类 3.设计错误 设计阶段产生的错误，它使系统的设计与需求规格说明中的功能说明不相符。它们又可以细分为：设计不完全错误：某些功能没有被设计，或设计得不完全。算法错误：算法选择不合适。主要表现为算法的基本功能不满足功能要求、算法不可行或者算法的效率不符合要求。模

10、块接口错误：模块结构不合理；模块与外部数据库的界面不一致，模块之间的界面不一致。控制逻辑错误：控制流程与规格说明不一致；控制结构不合理。数据结构错误：数据设计不合理；与算法不匹配；数据结构不满足规格说明要求缺陷的分类（3）缺陷的分类：按软件的生存周期分类 4.编码错误 多种多样，大体归为以下几种：数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入输出错，及其它的错误 在不同的开发阶段，错误的类型和表现形式不同，故应采用不同的方法和策略来进行检测。软件缺陷的构成软件缺陷修复的代价软件在从计划、编制、测试、一直到交付用户公开使用的过程中，都有可能产生和发现缺陷。随着整个开发过程的时间推

11、移，修复软件的费用呈几何级数的增长。下图是软件缺陷在不同阶段发现时修改的费用示意图课程内容软件测试的背景软件测试概述软件测试技术软件测试方法软件测试模型软件测试过程软件测试人员例子软件测试的发展软件测试发展史上的几个重要事件 1972 年6 月，首次软件测试会议 1972 年6 月，Bill Hetzel（代表论著The Complete Guide to Software Testing）在美国的北卡罗来纳（North Carolina）大学组织了首次以软件测试为主题的会议。1973 年，Bill Hetzel 定义软件测试概念，就是建立一种信心，认为程序能够按预期的设想运行。1983 年，

12、Bill Hetzel 将定义修订为：评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。他还把软件的质量定义为“符合要求软件测试的发展软件测试发展史上的几个重要事件（续）1979 年，Glenford Myers：The Art of Software Testing 出版。这本书是软件测试方面的圣经。Myers 定义及诠释的测试方法论已成为软件测试的基本模块。提出测试的目的是证伪。1983、1990 年，IEEE/ANSI 标准定义软件测试概念。1990 年的IEEE/ANSI 标准将软件测试进行了这样的定义：在既定的状况条件下，运行一个系统或组建

13、，观察记录结果，并对其某些方面进行评价的过程。这里所谓“既定的状况”可理解为需求或设计。软件测试的发展软件测试发展史上的几个重要事件（续）1996 年提出：测试能力成熟度TCMM（Testing Capability Maturity Model）、测试支持度TSM（Testing Support Model）、测试成熟度（Testing Maturity Model）。软件测试的发展软件测试发展趋势 测试与质量保证体系的融合 测试方法越来越细分，如网站测试、安全性测试等 测试技术不断发展 软件验证技术方面 软件静态测试方面 测试用例的选择方面 自动化测试方面 测试走向专业化道路Softwar

14、e Engineering什么是软件测试广义的概念 指软件生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段，以及完成开发后维护阶段的各类文档、代码的审查和确认狭义概念 识别软件缺陷的过程，即实际结果与预期结果的不一致Software Engineering什么是软件测试软件测试通常包括验证(verification)和确认(validation)：-验证指保证软件正确的实现了某一特定功能的一系列活动（功能性）-确认指的是保证软件的实现满足了用户需求的一系列活动（实用性）Software Engineering什么是软件测试软件的质量与可靠性：-可靠性：运行稳定、满足客户需求-质

15、量：功能强度、可靠性、性能、客服以及性价比等-可靠性和功能，哪一个更重要？Software Engineering什么是软件测试软件的测试（Testing）与质量保证（Quality Assurance，QA）：-软件测试：尽可能找到软件缺陷，并确保缺陷得以修复-软件质量保证：创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法-？QA和QC的异同点？Software Engineering软件测试的目的测试的目的就是发现软件中的各种缺陷测试只能证明软件存在缺陷，不能证明软件不存在缺陷测试可以使软件中缺陷降低到一定程度，而不是彻底消灭以较少的用例、时间和人力找出软件中的各种错误和缺陷，以确

16、保软件的质量以更少的支出（需求变更、维护、客服等成本）来谋取收入支出比达到最大化。Software Engineering软件测试的原则软件开发者的座右铭：“尽早地和不断地进行软件测试”。测试用例应由测试输入和与之对应的预期输出结果两部分组成。妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。Good-enough:一种权衡投入/产出比的原则：选择测试保证测试的覆盖程度，但穷举测试是不可能的：有限测试所有的测试都应追溯到用户需求测试的规模由小而大，从单元测试到系统测试为了尽可能地发现错误，应该由独立的第三方来测试不能为了便于测试擅自修改程序既应该测试软件该做什么也应该测试软件

17、不该做什么Software Engineering软件测试的原则充分注意测试中的群集现象。经验表明，测试后程序残存的错误数目与该程序中以发现的错误数目或检错率成正比。应该对错误群集的程序段进行重点测试。其中的原因是：编写该段程序时，程序员情绪不佳、心情不好；程序员往往犯同样的错误；某些软件缺陷实乃冰山一角。Software Engineering软件测试的原则严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的组装方式，跟踪规则，调试规则，以及回归测试的规定等等以

18、及评价标准。应当对每一个测试结果做全面的检查。对测试结果要有一个确认过程。A 测出的错误由B 确认。严重的错误可召开评审会进行讨论和分析Software Engineering软件测试的原则严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的组装方式，跟踪规则，调试规则，以及回归测试的规定等等以及评价标准。应当对每一个测试结果做全面的检查。对测试结果要有一个确认过程。A 测出的错误由B 确认。严重的错误可召开评审会进行讨论和分析Software Engineeri

19、ng软件测试的原则软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间服从质量。并非所有软件缺陷都要修复 原因：没有足够的时间进行修复；修复的风险较大；不值得修复可不算做故障的一些缺陷；“杀虫剂现象”。结论：关键是要进行正确判断、合理取舍，根据风险分析决定哪些故障必须修复，哪些故障可以不修复。Software Engineering软件测试的规律木桶原理：软件质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终软件的质量（例如：老板不诚信）测试是提高软件质量的必要条件，最直接、最快捷的手段，但决不是一种根本手段 2

20、个角度：木桶原理与反木桶原理？Software Engineering软件测试的规律Bug 的80-20 原则 在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug（提前测试）而系统测试又能找出其余Bug 中的80%最后的5%的Bug 可能只 有在用户的大范围、长时间使用后才会曝露出来Software Engineering软件测试的规律80/20 原则1.80%的工程量用在20%的需求上（关键需求）2.80%的开发成本花费在20%的部件上3.80%的错误是由20%的部件引起的4.80%的延期或返工是由20%的变更造成的5.80%的系统资源是由20%的部件消耗的6.80%的进度是

21、由20%的人完成的Software Engineering软件测试的对象（1）软件测试并不等于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。Software Engineering软件测试的对象（2）在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来。Software Engineering软件测试的重点测试用例的良好设计 测试用例的设计是整个软件测试

22、工作的核心 测试用例反映对被测对象的质量要求，决定对测试对象的质量评估Software Engineering软件测试的重点测试工作的管理 尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提测试环境的建立 测试环境应该与实际测试环境一致Software Engineering软件测试的质量软件测试可以发现以下软件缺陷：软件实现的功能不正确“缺少”：软件没有实现某项功能“多余”，软件实现的某项功能在需求中没有定义发现第一类软件缺陷的过程-“验证”发现后两类软件缺陷的过程-“确认”“验 证”和“确 认”哪 一 个 更 重 要？“确 认

23、”有 必 要 吗？Software Engineering软件测试度量1、测试覆盖率 有多少需求、代码已经被测试了2、缺陷发现率 缺陷是何时被发现，并且有多少缺陷已经被发现。缺陷可以根据严重性来分类。需记录以下值：缺陷数目缺陷的严重性Software Engineering软件测试度量3、测试成功率：有多少测试已经通过了，并且有多少是运行正常的？需记录以下值：已通过的测试用例的数目可利用的测试用例的数目Software Engineering软件测试的分类典型的软件测试类型 功能测试 可靠性测试 容错性测试 恢复测试 易用性测试 性能测试 可维护性测试 可移植性测试 安全性测试 用户文档测试S

24、oftware Engineering软件测试误区软件开发完成后进行软件测试；软件测试=程序测试；软件质量问题是测试人员的错误，软件发布后如果发现问题，那是软件测试人员的错；测试技术要求不高，比编程容易，随便找一个人就可以了；测试跟着开发动，有时间就多测，没时间就少测；测试是测试人员的事，与开发人员无关；软件测试是没有前途的工作，只有程序员才是软件高手；测试要执行所有可能的输入；好的测试一定要使用很多的测试工具。Software Engineering错误（error）：同义词“过错”（mistake）,是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。缺陷（Faul

25、t）：同义词“缺点”（Defect）,缺陷是错误的结果。更精确地说，缺陷是错误的表现，表现可以是叙述性文字、数据流框图、层次结构图、源代码等。失效（failure）:是指软件运行时产生的一种不希望或不可接受的外部行为结果。事故（incident）:当出现失效时，可能会也可能不会呈现给用户。事故说明出现了与失效类似的情况，警告用户注意所出现的失效。测试中的几个概念Software Engineering课程内容软件测试的背景软件测试概述软件测试技术软件测试方法软件测试模型软件测试过程软件测试人员例子Software Engineering软件测试技术Software Engineering动态测

26、试和静态测试静态测试不执行程序来寻找代码中存在的错误或评估代码的过程。由人工来进行，发挥了人的逻辑思维的优势或测试经验。能够批量性地发现问题，并直接定位到缺陷或错误的具体位置。用静态测试来进行代码检查、静态结构分析。动态测试 必须生成测试数据来运行被测试程序，取得程序运行的真实情况、动态情况，进而进行分析测试质量依赖于测试数据 生成测试数据、分析测试结果的工作量大，使开展测试工作费时、费力、费人Software Engineering软件测试技术黑盒测试/白盒测试-从要不要看代码部分来区分PINOUT白盒测试:黑盒测试:Software Engineering通过维恩图理解测试Software

27、 Engineering通过维恩图理解测试用例测试的工艺性：测试人员怎样才能使这些集合都相交的区域（区域1）尽可能的大？如何标示集合T 中的测试用例？Software Engineering功能性测试（1）Software Engineering功能性测试（2）基本观点：任何程序都可以看做是将输入定义域取值映射到输出值域的函数测试依据：软件的需求规格说明优点：与软件如何实现无关，若实现发生变化，测试用例仍然有用 测试用例设计可以与实现并行进行，可压缩总的项目开发时间缺点：测试用例之间可能存在严重的冗余 可能有未测试的软件漏洞Software Engineering结构性测试（1）Softwar

28、e Engineering结构性测试（2）基本观点：实现是已知的测试依据：内部实现细节优点：可以严格描述要测试的确切内容 测试覆盖指标的定义和使用，提供明确描述软件测试项范围的方法，有利于测试管理缺点：不能表示没有编码实现的行为Software Engineering功能性测试和结构性测试的比较两种方法单独使用都是不充分的。明智的组合会带来功能性测试的置信，以及结构性测试的度量。如果知道容易犯什么错误，并且知道在被测软件中可能存在什么类型的缺陷，就可以利用这种知识运用更恰当的测试用例标示方法，而正是这一点使得测试真正成为一种工艺。Software Engineering课程内容软件测试的背景软

29、件测试概述软件测试技术软件测试方法软件测试模型软件测试过程软件测试人员例子Software Engineering手工测试和自动测试手工测试自动测试适合自动化的测试操作手工测试和自动测试的比较Software Engineering手工测试传统的测试方法由测试人员手工编写测试用例缺点在于测试工作量大，重复多，回归测试难以实现Software Engineering自动测试利用软件测试工具自动实现全部或部分测试工作：管理、设计、执行和报告自动测试节省大量的测试开销，并能够完成一些手工测试无法实现的测试自动化测试前必须首先手工测试（调试）缺点：无法及时进行动态调整和数理分析，例如：计算正确不代表逻

30、辑性上没有错误；Software Engineering适合自动化的测试操作测 试 用 例 的 生 成（包 括 测 试 输 入，标 准 输 出，测试操作指令等）测 试 的 执 行 与 控 制（包 括 单 机 与 网 络 多 机 分 布 运行；夜间及假日运行）测试对象、范围、版本等的控制Software Engineering适合自动化的测试操作测试结果与预期输出的对比测试的统计，报表的产生Software Engineering手工测试和自动测试的比较手工完成测试的全部过程无法保证测试的科学性与严密性:修改的缺陷越多，回归测试越困难 没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率

31、 反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一 测试花费的时间越长，测试的严格性也就越低 难以对不可视对象或对象的不可视属性进行测试。Software Engineering手工测试和自动测试的比较自动测试将测试人员从反复、烦杂的测试执行中解放出来，用更多的时间进行测试设计和结果分析软件测试不可能完全自动化不能完成所有手工测试任务无创造性且灵活性差，不能改进测试的有效性过程中可能会遇到许多意想不到的问题，特别是当软件不稳定时测试脚本的维护高Software Engineering课程内容软件测试的背景软件测试概述软件测试技术软件测试方法软件测试模型软件测试过程软件测试人员例子Sof

32、tware Engineering软件测试流程软件测试由一系列活动组成，软件测试流程模型用于定义软件测试的流程和方法。软件测试专家通过实践总结出一些测试流程，这些模型对测试活动进行抽象，并与开发活动有机地进行结合。Software EngineeringV 模型A 版本（1）Software EngineeringV 模型B 版本（2）Software EngineeringV 模型C 版本（3）Software EngineeringV 模型（4）V 模型：Paul Rook 在20 世纪80 年代后期提出，最具有代表意义的测试模型，是软件开发瀑布模型的变体，反应了测试活动与分析和设计的关系

33、两个特点：展示了动态测试的全过程，并定义了动态测试与开发之间的关系 动态测试的行为与开发过程的行为相对应，测试基础是对应开发阶段的文档Software EngineeringV 模型（5）三个特点 测试与开发文档之间很少有完美的一对一关系 完全没有提及静态测试，忽略了代码审查、需求规格说明审查等重要的测试手段 软件测试时间经常由于前期开发阶段进度的拖延而被挤上，甚至取消，从而使得测试质量得不到保证Software EngineeringW 模型（1）Software EngineeringW 模型（2）W 模型：Paul Herzlich 在1993 年提出，对V 模型的改进，表明测试与开发的

34、并行关系，充分体现测试贯穿于整个开发过程两个特点：W 是V 的发展，强调测试应在整个开发周期进行 W 和V 一样，开发行为与测试行为为一一对应，但W并不主张动态测试必须要与开发阶段对应起来，W 也不限制动态测试行为必须严格地基于开发行为产生的单一文档Software EngineeringW 模型（3）缺点：在W 模型中，需求、设计、编码等活动是串行的，测试和开发活动也保持一种线性的前后关系。只有上一个阶段完成之后，才能正式开始下一个阶段工作，从而无法支持迭代的开发模式。Software EngineeringH 模型（1）Software EngineeringH 模型（2）H 模型：将测试

35、活动视为一个完全独立的活动，具有独立的包括测试准备活动和测试执行活动的流程。只要测试准备就绪，就可以开始测试执行活动。在整个开发周期内，存在多个这样独立的测试流程。体现“尽早准备、尽早执行”的思想，并且不同测试活动可以按照合理的顺序进行Software EngineeringX 模型X 模型基本思想由Brian Marick（软件子系统测试的作者）提出，Robin F.Goldsmith（Go 项目管理咨询公司的总裁）命名。Brian Marick 对V 模型的质疑主要有：V 模型无法引导项目的全过程。他认为一个模型应能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等 V 模

36、型基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。按照V 模型所指导的步骤进行工作，某些做法并不切合实用。Software EngineeringX 模型Software EngineeringX 模型X 模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试 此后将进行频繁的交接,通过集成最终合成为可执行的程序。(右上半部分）,这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示

37、变更可以在各个部分发生。X 模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误.X 模型及其探索性测试的提倡也是为了避免把大量时间花费在测试文档编写上面，那样的话，真正用于测试的时间就减少了。Software Engineering软件测试过程模型选择策略任何模型都不完美，不应为了使用模型而照搬。实测中，应灵活运用各模型优点，通常在W 模型框架下，运用H 模型的思想进行独立测试。当有变更时，按X 模型的思想进行处理。测试和开发密不可分，寻找恰当的就绪点开始测试，并反复进行迭

38、代测试，以达目标。Software Engineering课程内容软件测试的背景软件测试概述软件测试技术软件测试方法软件测试模型软件测试过程软件测试人员例子Software Engineering软件测试的过程对于各种测试，需要有一系列的测试活动来完成Software Engineering软件测试活动1.测试条件取决于被测试验证的项目或事件。测试条件是被测环境的描述，可以用多种方式描述：如简单的语言，表格项形式或类似于流图的图表形式；标识测试条件的活动最好与开发活动（即V 模型左边的活动）并行开展。Software Engineering软件测试活动2.设计测试用例（test case），确

39、定“怎样测试”测试是从大量的测试用例中选择有限的测试用例发现软件中的大部分缺陷的一种技术。测试用例是按一定顺序执行的与测试目标（测试理由或目的）相关的一系列测试。测试用例设计将产生许多测试所包括的输入、期望结果及其他任何运行测试的有关信息，如环境要求。期望输出包括应输出或建立的内容，应修改或更新或应删除的内容。期望输出集可以是一个很大的集合。Software Engineering软件测试活动 好的测试用例的4 个特性：检测软件质量的有效性，是否能发现缺陷，或至少可能发现缺陷；可仿效的测试用例可以测试很多内容，因而减少测试用例的数量；经济性，测试用例的执行、分析和调试是否经济；测试用例的可修改

40、性，每次软件修改后对测试用例的维护成本。Software Engineering软件测试活动3.开发测试用例，包括准备测试脚本、测试数据以及期望输出。测试脚本（test script）是具有正规语法的数据和指令的集合，在测试执行自动工具使用中，通常以文件形式保存；必须先完成测试用例的先决条件，然后再执行测试。测试用例可能要求专门的硬件或软件，如网络环境或打印机等；期望输出可以组成成文件形式用于自动工具。对于手动测试，期望输出仅仅只是简单地记录在手工测试过程或脚本中。设置用于自动比较的期望输出比设置用于手工测试的期望输出复杂得多。在自动工具中要求每项内容都要拼写正确，而在手工测试中要求没这么严格

41、。测试开发的任何工作可以提前进行（相对V 模型左边的活动进行），以后可以节省时间。Software Engineering软件测试活动4.执行测试用例 对于手动测试来讲，测试者按事先准备好的手工过程进行测试，测试者输入数据、观察输出、记录发现的问题。对于自动测试，可能只需要启动测试工具，并告诉工具执行哪些测试用例；Software Engineering软件测试活动5 将测试结果与期望输出进行比较 应该对每次测试的实际输出进行分析研究，判断软件功能是否正确。验证可以是非正式的测试者主观判断，也可以是将实际输出与期望输出进行严格准确的比较。一些信息比较，如可以在执行测试时进行显示屏幕上的信息,另

42、一些输出比较，如修改数据库记录，只能在测试执行结束后进行。自动测试一般结合了这两种方法。Software Engineering软件测试的信息流测试信息流程如图所示。测试过程中需要三类输入：软件配置、测试配置和测试工具。Software Engineering课程内容软件测试的背景软件测试概述软件测试技术软件测试方法软件测试模型软件测试过程软件测试人员例子Software Engineering测试的组织方式小组测 试 组 长 是 测 试 对 外 的 唯 一 接 口，对 内 完 全 负 责组员的工作安排、工作检查和进度管理测 试 小 组 内 部 分 为 测 试 人 员 和 支 持 人 员(管

43、理 人员属于支持人员)支 持 小 组 负 责 测 试 的 后 勤 保 障 和 日 常 管 理 工 作：负 责 网 络 管 理、数 据 备 份、文 档 管 理、设 备 管 理和 维 护、员 工 内 部 培 训、测 试 理 论 和 技 术 应 用、日常事务管理和检查等Software Engineering软件测试工程师分类测试工程师一般分为两类：测试工具软件开发工程师和软件测试工程师。测试工具软件开发工程师主要负责编写测试工具代码，并利用测试工具对软件进行测试或开发测试工具为软件测试工程师服务。软件测试工程师主要负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误，决定软件是否具有稳定性

44、，并写出相应的测试规范和测试案例。Software Engineering软件测试工程师素质软件测试员的目标：发现潜在的软件缺陷 软件测试员在开发团队中“讨人厌”保持团队和谐的建议 尽可能早的找出缺陷 控制情绪 不要总是报告坏消息Software Engineering软件测试工程师素质Software Engineering软件测试人员的现状1、软件测试人员的合理比例 在软件产业发达的国家：软件测试在人员配备和资金投入方面占据相当的比重。微软为打造Windows2000，1700 多个开发人员，以及3200 个测试人员，开发和测试人员之比约为三比五。HP 公司的测试人员和开发人员的比例为一比

45、一，这是很多先进软件企业通常的人员配比。在国内：企业往往忽视软件测试，很多企业都没有软件测试部门，甚至不设置软件测试的岗位，造成产品质量得不到保证。测试人员大都不到开发人员的5%，随着产业和企业的发展，企业必然需要大量的测试人员。Software Engineering软件测试人员的现状2、软件测试人才紧缺 软件测试人才需求快速增长，体现在：中国软件产业正在快速增长，需要大量软件相关人才；软件企业的发展要求测试人才达到一个合适的比例。近一两年软件企业开始认识到软件测试对于提高软件质量的重要性，开始重视软件测试，但由于历史的原因，找不到合适的软件测试人员。Software Engineering

46、课程内容软件测试的背景软件测试概述软件测试技术软件测试方法软件测试模型软件测试过程例子Software Engineering举例（1）三角形问题NextDate 函数佣金问题SATM 系统货币转换器Software Engineering三角形问题（1）输入三个整数a、b、c，分别作为三角形的三条边，现通过程序判断由三条边构成的三角形的类型为等边三角形、等腰三角形、不等边三角形（特殊的还有直角三角形）或非三角形。现在要求输入三个整数a、b、c,必须满足以下条件：条件1 1a 200 条件4 a b+c 条件2 1b 200 条件5 b a+c 条件3 1c 200 条件6 c b+cSoft

47、ware Engineering三角形问题（2）如果输入值a、b、c不满足条件1、条件2 和条件3，程序给出“边的取值超出允许范围”的信息。如果输入值a、b、c 满足条件1、条件2 和条件3，则输出下列四种情况之一：（1）如果不满足条件4、条件5 和条件6 中的一个，则程序输出为“非三角形”。（2）如果三条边相等，则程序输出为“等边三角形”。（3）如果恰好有两条边相等，则程序输出为“等腰三角形”。（4）如果三条边都不相等，则程序输出为“一般三角形”。结论：三角形问题的复杂之处在于输入与输出之间的关系比较复杂。Software EngineeringNextDate 函数NextDate 函数说

48、明另一种复杂的关系，即输入变量之间逻辑关系的复杂性。NextDate 函数包含三个变量month、day 和year，函数的输出为输入日期后一天的日期。要求输入变量month、day 和year 均为整数值，并且满足下列条件：条件1 1 month 12条件2 1 day 31条件3 1912 year 2050结论：在NextDate 函数中有两种复杂性的输入来源，一是输入域的复杂性，二是确定闰年（4 闰，100 不闰，400再闰）的规则并要增加“额外天”Software Engineering佣金问题（1）一位步枪销售商销售密苏里州制造商制造的步枪机（lock）、枪托（stock）和枪管（

49、barrel）Lock=$45.00 stock=$30.00 barrel=$25.00每个销售商每月至少要售出一支完整的步枪生产限额是每一个销售商在一个月内内可销售70 个枪机、80 个枪托，90 个枪管每访问一个镇子后，销售商都给密苏里州制造商发出电报，说明在那个镇子中售出的数量。到了月末，销售商法出一个“-1”的电报。这样步枪制造商就知道当月的销售情况。佣金计算如下：sales1000 美元，佣金为销售额的10%1000 美元sales1800 美元，佣金为销售额的15%sales 1800 美元，佣金为销售额的20%佣金计算程序生成月销售报告、汇总售出的枪机、枪托和枪管总数、销售商的

50、总销售额、以及佣金Software Engineering佣金问题（2）该问题分为三个不同的部分：输入数据部分，用来处理输入数据的有效性，与在三角形和NextDate 程序中做的一样。因此，在此忽略输入数据的有效性部分。输出部分：销售额的计算以及佣金计算结论：佣金问题是一个典型的商务计算例子，包含了计算和决策Software EngineeringSATM 系统（1）Software EngineeringSATM 系统（2）屏幕1欢迎！请插入ATM 卡屏幕2请输入密码：如果输错请按“取消”键屏幕3个人密码有误，请重新输入屏幕4无效密码，您的卡将被留下，请给银行打电话屏幕5请选择交易的类型：余