• 1. 拨云见雾 直面真谛1
  • 2. 软件测试基本知识软件开发模型 软件测试模型 软件测试案例—测试用例的认识 软件质量保证2
  • 3. 软件生命周期模型 人与软件的生命周期人 类软 件生命 终结孕育出生儿童少年青壮年、老年可行性研究需求分析设计,编码测试发布维护 淘汰3
  • 4. 软件开发模型瀑布模型 原型模型 增量模型 螺旋模型 4
  • 5. 瀑布模型(1/2)瀑布模型 包括了六个阶段,自上 而下,犹如瀑布 各项工作按照线性方式 进行 以文档驱动 5
  • 6. 瀑布模型(2/2)优点 各阶段清晰 适合需求稳定的中小型项目产品开发 缺点 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量; 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险; 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。 6
  • 7. 原型模型先建立一个能反映用户需求的原型系统,使得用户和开发者可以对目标系统的概貌进行评价和判断,然后对原型进行反复的扩充、改进和求精,最终建立符合用户需求的目标系统。 仅仅适合与客户交流比较方便的小项目。如,学生管理系统7
  • 8. 增量模型(1/2)原型模型与瀑布模型的结合 在每个阶段都生成软件的一个可发布版本。这些阶段是交错进行的。软件功能逐步完善。 分析设计编码测试增量1分析设计编码测试增量2分析设计编码测试增量3分析设计编码测试增量48
  • 9. 增量模型(2/2)优点: 较短的时间内提交一个可完成一定工作的有用的产品 逐步增加产品功能,使用户有充裕的时间学习、适应新产品,减少了全新软件给用户带来的冲击。 增量模型与原型模型的区别 原型模型中,每个阶段是发布一个原型 增量模型中,是完成一个正式的版本。 测试人员针对这两种模型的工作内容和要求有所区别 9
  • 10. 10
  • 11. 在瀑布模型的基础 上提出,并加入了风险分析。 螺旋模型的每一周期都包括制定计划、风险分析、实施工程和评审四个阶段。 螺旋模型(1/2)计划风险分析实施工程评审11
  • 12. 螺旋模型(2/2)特点: 强调风险分析,适合于复杂、高风险系统 需要专门的风险评估经验 和专门知识 过多的迭代延迟项目提交时间 12
  • 13. 软件开发模型比较模型优点缺点瀑布模型文档驱动系统可能不满足客户的需求原型模型关注满足客户需求可能导致系统设计差、效率低,难于维护增量模型开发早起反馈及时,易于维护需要开放式体系结构,可能会设计差、效率低螺旋模型风险驱动风险分析人员需要有经验且经过充分训练13
  • 14. 软件测试模型软件测试模型是软件测试工作的框架,它描述了软件测试过程中所包含的主要活动以及这些活动之间的相互关系。 通过测试模型,软件测试工程师及相关人员可以了解测试何时开始、何时结束,测试过程中主要包含哪些活动以及需要哪些资源等。 软件测试是和软件开发紧密联系的,在进行测试时需要根据软件项目的测试目的、所采用的开发过程模型和组织条件等,选择合适的测试模型。14
  • 15. 软件测试模型V模型 W模型 H模型15
  • 16. V模型(1/3)16
  • 17. V模型(2/3)改进的软件测试V模型需求功能设计系统/软件设计细节设计编码编码单元测试特征测试系统测试验收测试设计/分析校验测试开发和测试的过程确认需求客户、用户PM技术支持17
  • 18. V模型(3/3)V模型 仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试时软件开发的最后一个阶段,主要针对程序进行测试寻找错误,而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。 适合信息系统应用软件的开发 不适合高性能、技术风险高或不易模块化的系统开发 18
  • 19. W模型(1/2)用户需求需求分析与系统设计概要设计详细设计编码集成实施交付用户需求V&V验收测试设计需求分析与系统设计V&V确认与系统测试设计概要设计V&V集成测试设计详细设计V&V单元测试设计单元测试集成测试确认测试与 系统测试验收测试19
  • 20. W模型(2/2)特点: 在V模型中增加了软件各开发阶段中应同步进行的验证和确认活动,明确表示出了测试与开发的并行关系。 测试伴随着整个软件开发周期,对象不仅仅是程序,所有产生的软件产品都是测试对象。 局限性: 需求、设计、编码等活动被视为串行,测试和开发也是线性的前后关系。 无法支持迭代的开发模型。20
  • 21. H模型(1/3)测试准备测试就绪点测试执行测试流程其他流程21
  • 22. H模型(2/3)特点: 将测试活动完全独立出来,形成了一个独立的流程。 清晰体现了测试准备活动和测试执行活动。 示意图仅仅演示了整个生产周期中某个层次上的一次测试“微循环”。 软件测试时一个独立的流程,贯穿产品整个生命周期,与其他流程并发进行。22
  • 23. H模型(3/3)H模型揭示了: 软件测试不仅仅指测试的执行,还包括很多其他的活动。 软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。 软件测试要尽早准备,尽早执行。 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的,但也可能是反复的。23
  • 24. 测试模型的选择(1/2)V模型强调了在整个项目开发中需要经历的不同的测试级别,但忽视了测试的对象不应该仅仅是程序。 W模型明确指出应该对需求、设计进行测试。 H模型明确指出测试的独立性。只要测试条件成熟了,就可以开展测试。24
  • 25. 测试模型的选择(2/2)在实际测试工作中应尽可能地应用各模型中对项目有实际价值的方面。 测试策略: 以W模型作为框架,及早地、全面的开展测试。 同时灵活应用H模型独立测试的思想,达到恰当的就绪点时就应该开展独立的测试工作,同时将测试工作进行迭代,最终保证完成测试目标。25
  • 26. 软件测试用例(1/9)在对软件进行测试时,需要: 构造测试用例 执行测试用例,检查结果是否与期望的输出一致 作用: 测试用例催促工作 理清头绪,不重复,不遗漏 根据优先级分清重点 是工作的见证 记录灵感,将测试思路写成测试用例 改进工作,知道哪些用例测出bug的几率大26
  • 27. 软件测试用例(2/9)测试用例的基本概念 Test case 是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径是否正确或核实某个功能是否满足特定需求。 特征: 最有可能抓住错误的 不是重复的、多余的 一组相似测试用例中最有效的 既不是太简单,也不是太复杂 有效的,可执行的,有期望结果27
  • 28. 软件测试用例(3/9)用例编号:有一定的规则,比如系统测试用例的编号这样规定:PROJECT1-ST-001。定义编号,便于查找测试用例,便于跟踪。 测试标题:对测试用例的描述,表达测试用例的用途。如“测试用户登录时输入错误密码时,软件的响应情况”。 重要级别:定义测试用例的优先级别,高、低。一般来说,软件的需求优先级为高,测试用例的优先级也为高。 测试输入:提供测试执行时的各种输入条件。 操作步骤:提供测试执行过程的步骤。 预期结果:提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。28
  • 29. 软件测试用例(4/9)测试用例的作用 测试用例是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。 测试用例构成了设计和制定测试过程的基础。 判断测试是否完全的一个主要评测方法是基于需求的覆盖(95%的关键测试用例已得以执行和验证) 测试工作量与测试用例的数量成正比。29
  • 30. 软件测试用例(5/9)测试用例的设计 测试需求分析 业务流程分析 测试用例设计 测试用例评审 用例设计错误、遗漏、冗余、不充分等 测试用例更新完善30
  • 31. 软件测试用例(6/9)测试用例的设计原则 测试用例的代表性 能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的数据输入、操作和环境设置等 测试结果的可判定性 测试执行结果的正确性是可判定的,每一个测试用例都应该有相应的期望结果 测试结果的可再现性 对同样的测试用例,系统的执行结果应当是相同的31
  • 32. 软件测试用例(7/9)设计技巧 重用同类型项目的测试用例 如果我看得远,那是因为我站在巨人的肩上 软件公司项目分类: 业务:ERP软件、产品数据管理软件、通信软件、地理信息系统软件GIS等 软件结构:B/S架构软件、C/S架构软件、嵌入式软件 系统接近,测试用例简单修改即可使用。 拿来主义可以开阔测试用例的设计思路,也可以节省大量的测试用例设计时间。32
  • 33. 软件测试用例(8/9)定义测试用例的执行顺序 每个测试用例对测试环境有特殊的要求或影响 定义测试用例的执行顺序,对测试的执行效率影响非常大,如,某些异常测试用例会导致服务器频繁重新启动,则应该最后执行。33
  • 34. 软件测试用例(9/9)测试用例设计实例 要对windows记事本程序进行测试 测试项:文件菜单栏的测试 测试对象:记事本程序文件菜单栏(测试用例标识1000) 所包含的子测试用例描述如下: 文件/新建(1001) 文件/打开(1002) 文件/保存(1003) 文件/另存为(1004) 文件/页面设置(1005) 文件/打印(1006) 文件/退出(1007)34
  • 35. 字段名称描述标识符1007测试项记事本程序,菜单栏中的“文件”→“退出”命令的功能测试测试环境要求Windows2000professional中文版输入标准1.打开记事本程序,不输入任何字符,选择“文件”→“退出”命令 2.打开记事本程序,输入一些字符,不保存文件,选择“文件”→“退出”命令 3.打开记事本程序,输入一些字符,保存文件,选择“文件”→“退出”命令 4.打开一个记事本文件(*.txt),不做任何修改,选择“文件”→“退出”命令 5.打开一个记事本文件(*.txt),修改后不保存,选择“文件”→“退出”命令输出标准1.记事本未作修改,选择“文件”→“退出”命令,能正确地退出应用程序,无提示信息 2.记事本做修改未保存或者另存,选择“文件”→“退出”命令,会提示“未定标题文件的文字已经改变,想保存文件吗?”单击“是”按钮,windows将打开“保存”→“另存为”对话框;单击“否”按钮,文件将不被保存并退出记事本程序,单击“取消按钮将返回记事本窗口测试用例的关联35
  • 36. 36
  • 37. 37
  • 38. 软件测试小常识测试能提高软件的质量,但是提高质量不能依赖测试 测试只能证明错误存在,不能证明错误不存在 80-20原则:80%的错误聚集在20%的模块中,经常出错的模块改错后还会经常出错 测试应当循序渐进,不要企图一次性做完,注意“欲速则不达”38
  • 39. 软件质量保证(1/3)软件质量特性 满足用户的需求 合理进度、成本、功能关系 具备扩展性和灵活性,能够适应一定程度的需求变化 能够有效的处理例外的情况 39
  • 40. 软件质量保证(2/3)软件质量保证(SQA) 为了确保软件开发过程和结果符合预期的要求,而建立的一系列规程,以及依照规程和计划采取的一系列活动及其结果评价。餐厅老板当班经理主厨厨师检验员监督员程序员项目经理系统架构师老板测试员项目组SQA40
  • 41. 软件质量保证(3/3)SQA工作内容 从第三方的角度监控软件开发,保证软件质量 确保项目组制定的计划、标准和规程适合需要,并且满足评审和审计需要 保证开发的软件和开发过程符合标准与规程 保证不符合的问题得以解决41
  • 42. 软件测试与质量保证相同点: 都是贯穿于整个软件开发生命周期 不同点: SQA侧重于对流程中各过程的管理与控制,是一项管理工作,侧重于流程和方法。 软件测试是对流程中各过程管理与控制策略的具体执行和实施,其对象是软件产品(包括阶段性的产品) 软件测试时对软件产品的检验,是一项技术性的工作,常常被认为是质量控制的最主要手段。42