TJ.Liu June,2012

1. 员工培训 第一部分 软件测试概述 • TJ.Liu • June,2012

2. 本部分目标 • 软件的生命周期的定义 • 软件缺陷的定义 • 软件缺陷产生的原因 • 软件测试的目标 • 软件测试的特征

3. 软件生命周期 软件生命周期(Systems Development Life Cycle，SDLC)又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。

4. 软件生命周期模型 常见的软件生命周期模型包括以下几种: 1、瀑布模型 2、迭代模型 3、喷泉模型 4、其他衍生模型 增量模型 快速原型模型 螺旋模型 5、敏捷开发

5. 瀑布模型 1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 该模型的核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

6. 瀑布模型 瀑布模型的优点 1）为项目提供了按阶段划分的检查点。 2）当前一阶段完成后，您只需要去关注后续阶段。 瀑布模型的缺点 1）在项目各个阶段之间极少有反馈。 2）只有在项目生命周期的后期才能看到结果。 3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 4)瀑布模型的突出缺点是不适应用户需求的变化.

7. 迭代模型 迭代模型是RUP（Rational Unified Process，统一软件开发过程)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。 迭代和瀑布的最大的差别就在于风险的暴露时间上。“任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。”

8. 迭代模型 迭代模型的优点 与传统的瀑布模型相比较，迭代过程具有以下优点： 　　 1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。 2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。 3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。 4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

9. 喷泉模型 喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。 　　喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。

10. 喷泉模型 喷泉模型的优点 喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。 喷泉模型的缺点 由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

11. 衍生模型-增量模型 增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。 增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。

12. 衍生模型-增量模型 增量模型的优点 采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。 增量模型的缺点 1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。

13. 衍生模型-增量模型 3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

14. 衍生模型-快速原型模型 快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 快速原型模型的优点 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。 这种模型适合预先不能确切定义需求的软件系统的开发。 快速原型模型的缺点 所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。

15. 衍生模型-快速原型模型 使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。 快速原型模型的原理 　　快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。

16. 衍生模型-螺旋模型 螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。 螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。在实践中，螺旋法技术和流程变得更为简单。迭代方法体系更倾向于按照开发/设计人员的方式工作，而不是项目经理的方式。

17. 衍生模型-螺旋模型 螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动 : 1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； 2）风险分析：分析评估所选方案，考虑如何识别和消除风险； 3）实施工程：实施软件开发和验证； 4）客户评估：评价开发工作，提出修正建议，制定下一步计划。 螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

18. 衍生模型-螺旋模型 螺旋模型的优点 1）设计上的灵活性,可以在项目的各个阶段进行变更。 2）以小的分段来构建大型系统,使成本计算变得简单容易。 3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。 4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。 5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。 螺旋模型的缺点 很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

19. 敏捷开发 敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。 敏捷开发的价值观： 人和人的交互 重于过程和工具。 可以工作的软件 重于求全责备的文档。 客户协作 重于合同谈判。 随时应对变化 重于循规蹈矩。 其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

20. 敏捷开发的原则 • 2001年由一群敏捷开发方法的发起者和实践者起草了敏捷软件开发宣言，其中包括以下原则： • 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。 • 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。 • 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。 • 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。 • 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。 • 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。 • 可以工作的软件是进度的主要度量标准。

21. 敏捷开发的原则 • 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。 • 对卓越技术与良好设计的不断追求将有助于提高敏捷性。 • 简单——尽可能减少工作量的艺术至关重要。 • 最好的架构、需求和设计都源自自我组织的团队。 • 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

22. 敏捷开发-对比其他的方法 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。 适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。 对比迭代方法 相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。 对比瀑布式开发 两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。

23. 敏捷开发-对比其他的方法 瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。 相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。 有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行，例如极限编程。

24. 敏捷开发-敏捷方法的适用性 • 在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有： • 组织文化必须支持谈判 • 人员彼此信任 • 人少但是精干 • 开发人员所作决定得到认可 • 环境设施满足成员间快速沟通之需要 • 最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。

25. 敏捷开发-敏捷方法的适用性 另外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户，并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互的过程可以限制这些错误的发生，但前提是有效的负反馈，否则错误会迅速膨胀。 敏捷开发的重要方法： 敏捷建模 极限编程（XP Extreme Programming） Scrum 探索性测试等

26. 软件缺陷的定义 软件缺陷（Defect），常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE（电机电子工程师协会，Institute of Electrical and Electronics Engineers）对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。在软件开发生命周期的后期，修复检测到的软件错误的成本较高。

27. 软件缺陷的类别 软件缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有： 软件没有实现产品规格说明所要求的功能模块； 软件中出现了产品规格说明指明不应该出现的错误； 软件实现了产品规格说明没有提到的功能模块； 软件没有实现虽然产品规格说明没有明确提及但应该实现的目标； 软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。 根据以上五种缺陷类型，在软件测试中可以区分不同类型的问题。

28. 软件缺陷的分类 软件缺陷的分类方式也是多种多样的，包括以下分类方式： 以缺陷类型来划分； 以出现相应错误的开发阶段来划分； 以相应失效产生的后果来划分； 以缺陷的来源来划分； 以解决难度来划分； 以不解决会产生的风险来划分； 根据异常出现的频率来划分。

29. 软件缺陷产生的原因 在软件开发的过程中，软件缺陷的产生是不可避免的。那么造成软件缺陷的主要原因有哪些？主要包括软件本身、团队工作，技术问题和项目管理的问题等几个方面，软件缺陷的产生主要是由软件产品的特点和开发过程决定的。

30. 软件测试的目标 1.软件测试的目标是为了确保软件不存在软件缺陷。 根本错误的观点：简单的说，就是根本不存在没有缺陷的软件。 让测试人员走上失败之路的观点：无法完全覆盖到所有的数据输入及测试路径 软件测试的真正目标。 2.软件测试的目标是为了验证软件能够正常运转。 3.本着对用户负责的态度，找到以前没有发现的并且在用户使用过程中将对用户造成重大影响的软件缺陷，最终实现预防软件缺陷的目标。

31. 软件测试的特征 软件测试具有一定的风险 软件缺陷的寄生虫性 软件测试的杀虫剂现象 软件测试的不修复原则 Pareto原则

32. Contact Us: • Tel: +86 10 82825655 (China) • 400 000 6282 (China) • +1 213 814 3453 ( U.S. ) • Email: info@beyondsoft.com • URL: www.beyondsoft.com 谢谢 China • U.S. • Japan • India • Singapore