01、测试基础-学习目标、课程内容、引入

掌握什么是软件测试;

掌握测试的目的;

掌握软件生命周期的各个阶段以及相互关系;

初步了解软件生命周期各阶段的具体工作内容;

大致了解软件研发团队的组织形式和研发流程。

软件测试的定义和目的

软件生命周期

软件研发组织和流程

软件中产生缺陷的原因

问题讨论

网上购物/浏览网页是不是软件测试?  不是    软件使用

用手机/电脑打游戏是不是软件测试？  不是    软件使用

使用Office办公软件是不是软件测试?  不是    软件使用

什么是软件测试？

1.特定的目的 (购物的增删改查 软件运行时的性能) 2.测试是有一定的方法

3.提交缺陷 跟踪缺陷

软件测试演示

软件测试并不神秘,快速入门并不难

功能测试演示

性能测试演示

02、测试基础-软件测试的定义

梅尔斯  《软件测试的艺术》

G.J.Myers认为(1979)：

1 程序测试是为了 发现错误 而执行程序的过程;

2 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案;

3 成功的测试是发现了至今为止尚未发现的错误的测试。

25年之后, G.J.Myers在《软件测试的艺术第二版》中;

所谓软件测试,就是一个过程或一系列过程,用来确认 计算机代码

完成了其应该完成的 功能 ,不执行其不该有的操作。

什么是软件测试

目前没有公认非常完整的定义形式。

1983,IEEE提出的软件工程标准术语,软件测试定义如下:

"使用人工和自动手段来运行或测试某个系统的 过程 ",在其目的在于检验它是

否满足规定的需要或是弄清  预期结果 与 实际结果 之间的差别"。

没有必要一定要背一个概念出来,搞清软件测试的含义即可:

软件测试是一个过程,包含若干活动,运行软件进行测试只是活动之一;

进行软件测试可以人工方式也可以借助于工具;

进行软件测试可以 运行软件 也可以 不运行软件;

动态 静态

软件测试的目的不仅仅是为了发现错误。

03、测试基础-软件测试的目的

人们对软件测试目的的认识也经历了一个过程。

证明   检测 预防

表明软件能够工作 发现错误          管理质量

20世纪60年代 20世纪70年代中期      20世纪90年代

软件测试目的之证明

20世纪60年代

测试是证明软件没有问题。

现在

获取系统在可接受风险范围内可用的信心;

尝试在非正常情况和条件下的功能和特性;

保证一个工作产品是完整的并且可用或者被集成。

软件测试目的之检测

20世纪70年代中期

测试是为了发现错误。

现在

发现缺陷、错误和系统不足;

定义系统的能力和局限性;

提供组件、工作产品和系统发质量信息。

软件工程: 1.开发技术

2.开发管理

软件测试目的之预防

预防下一版本可能出现的问题

预防用户使用软件时可能出现的问题

提前发现开发过程中的问题和风险

大大较低开发的风险

提供可以用以分析的测试结果数据

了解哪些缺陷的原因和以前的数据进行分析

针对薄弱的环境进行加强(未雨绸缪)

软件测试观念的转变

传统测试 现在测试

在开发的后期介入 已经扩展到了整个软件生命周期

基于代码运行的测试 已经扩展到了静态的范畴

已发现错误为目的 已经扩展到了错误预防的范畴

希望通过测试收集和分析一些数据起到预防缺陷的作用

04、测试基础-软件测试常见的误区

调试和测试是一样的;

调试是定位错误修改程序    测试是找错误

调试是随机性的(程序员)    测试是目的性的

测试组应当为保证质量负责;

质量是做出来的,不是测出来的

过分依赖Beta测试;

(Beta测试是一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就会进入发布阶段。验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求， 确保所开发的软件产品符合用户的各项要求。 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。)

把测试作为新员工的一个过渡工作;

把不合格的开发人员安排做测试;

关注于测试的执行而忽略测试的设计;

测试自动化是万能的;

测试是可以穷尽的;

测试是为了证明软件的正确性;

测试是枯燥乏味,缺乏创造力的工作;

非常要求创造力的工作

软件测试发主要工作

软件测试工程师一般会承担以下一些具体工作;

检视代码、评审开发文档

进行测试设计、写作测试文档(测试计划、测试方案、测试用例等)

目的性,条理性

执行测试,发现软件缺陷,提交缺陷报告,并确认缺陷最终得到了修正

出现bug会造成什么后果

通过测试度量软件的质量

05、软件生命周期-计划

软件测试的定义和目的

软件生命周期

软件生命周期的各个阶段

计划----需求分析----设计----编码-----测试-----运行----评价--计划

软件研发组织和流程

软件中产生缺陷的原因

计划

工作内容 计算器例子

确定软件开发总目标   研发一个计算器

给出软件的功能、性能、可靠性以及接口等方面的设想; 支持加、减、乘、除,所有运算都需在一定时间之内完成;

研究完成该项目的可行性,探讨问题 该项目目前不存在任何技术障碍;

解决方案; 需要在3个月之内完成所有开发和测试工作,并推向市场;

对可供开发使用的资源、成本、可取得

的效益和开发进度作出估计; 具体计划参见项目一级计划(比如测试计划 质量保证计划 配置管理计划)。

制定完成开发任务的实施计划

06、软件生命周期-需求分析

需求分析(重要 复杂)

客户(没有IT背景) 说服客户

工作内容：

对开发的软件进行详细的定义,由 需求分析人员 和 用户共同 讨论决定,哪些需求 可以满足 的,并且给予 计算器例子

确切的描述 ,写出软件需求说明书SRS(Software Requirement Specification) 功能需求:

十进制加、减、乘、除

八进制加、减、乘、除

软件研发的类型不同,需求的来源也不同,需求分析中的"用户"针对的具体对象也不同 二进制加、减、乘、除

十六进制加、减、乘、除

针对 产品 的软件研发

需求来源:市场调研(来源市场 女性 男性 儿童 ...) 性能需求:

用户:市场调研人员 32位十进制加法需在2秒内完成

特点:自己想研发什么,自己就来研发 16位十六进制乘法需在10秒内完成

针对 项目 的软件研发

需求来源:客户要求

用户:实际的客户

特点:别人想研发什么,我们帮着研发

-----------------------------------------------------------------------------------------

设计

工作内容

设计是软件工程的技术核心,这个阶段需要完成设计说明书

概要设计(HLD),在设计阶段吧各项需求转换成相应的体系结构,每一部分是功能明确的模块;

详细设计(LLD),对每个模块要完成的工作进行具体的描述。

计算器例子

概要设计

整个软件分成六个模块:界面模块、主控模块、加法模块

减法模块、乘法模块、除法模块,主控模块调用后四个模块。

加法模块包含五个函数:加法主函数、十进制加法函数、八进制加法函数、二进制加法函数、

十六进制加法函数、主函数调用后四个函数。

详细设计

加法主函数的流程图(或者伪代码)

08、软件生命周期-编码、测试、运行和维护

编码

工作内容 计算器例子

把软件设计转换成计算机可以 用C语言实现详细设计说明书中描述的所以函数。

接受的程序,即写成以某个程序

设计语言表示的源程序清单,使用RDBMS工具建立数据库。

测试

工作内容 计算机例子

测试是检验软件是否符合客户需求,达到质量要求,一般由独立的小组执行,测试工作分为: 单元测试

单元测试 参照LLD(详设)

对每一个函数进行测试

集成测试 集成测试

参照HLD(概设)

对函数与函数的集成、模块与模块的集成进行测试

系统测试 系统测试

参照SRS

对每一个功能需求、性能需求等进行测试

运行和维护

工作内容

这个阶段将软件交付用户投入正式使用,可能有多种原因需要对它进行修改,如软件错误 计算机例子

、系统软件升级、增强软件功能、提高性能等。 计算器提供给用户使用,用户在使用过程中如发现问题可通过技术支持人员反映,

问题解决后为用户进行软件升级....

09、软件研发组织和流程-软件研发组织

软件测试的定义和目的

软件生命周期

软件研发组织和流程

软件中产生缺陷的原因

软件研发相关要素

人员 只有合适的人员借助合适的

过程         工具经过合适的过程才能研发出高质量的软件

工具

软件项目组人员组成

项目组一般由 项目经理 领导并负责制定 项目计划 ,分配任务。

项目组一般有下列人员参与:

分析人员

设计人员

开发人员

测试人员

配置管理人员

SQA:(软件质量保证 软件质量保证（SQA-Software Quality Assurance）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。)

常见项目组架构

项目经理 -----  SQA(监控整个软件研发的过程)

开发经理 测试经理 配置经理

软件开发组 软件测试组 配置管理组

分析人员 测试人员 配置管理员 CMO

设计人员

开发人员

10、软件研发组织和流程-瀑布模型

基本软件研发流程

常见的软件研发流程:

瀑布模型(00:40)增加了开发的风险 用户只能到最后才能看到 开发后期的测试阶段才能发现 带来了严重的后果

应用的最为广泛的一种模型,也是最容易理解和掌握的模型,

然而它的缺陷也是显而易见的。

螺旋模型

综合了基本的瀑布式模型和演化/渐增原型方法。

RUP流程

所有工作流在各个阶段都有体现。

IPD流程

从整个产品角度出发,不仅仅针对研发。

11、软件研发组织和流程-螺旋模型

螺旋模型(00:05) 非常看重风险分析的

确定目标、替代方案和限制

评价替代方案和标识与解决风险

优点:设计比较灵活  使客户每个阶段都可以客户去参与

缺点:周期长

12、软件研发组织和流程-RUP

RUP流程是IBM公司提出来的

工作流

过程

业务建模

需求

分析和设计

实现

测试

分布

支持

配置与变更管理

项目管理

环境

阶段

初始化 细化 构造 发布

初始 细化*1 细化*2 构造*1........

13、软件研发组织和流程-IPD

IPD流程  思想来源一家公司PRTM    IBM公司使用

阶段 概念 计划 开发 验证 发布 生命周期

IPMT

PDT

财务

系统工程

研发

硬件开发

软件开发

结构开发

工业设计

测试

资料开发

技术支持

制造

采购

市场

销售

14、软件中产生缺陷的原因

软件缺陷和Bug

软件缺陷:既指 静态 存在于软件工作产品(文档、代码)中的错误,

也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。

Bug:代码中的缺陷。有时也被泛指因软件产品颞部的缺陷引起的软件产品最终运行时和

预期属性的偏离。

软件错误、软件缺陷、Bug在实工作中可以认为一样。

常见的其他引入缺陷的原因

软件复杂度越来越高

编程中产生错误

需求不断变更

项目进度的压力

不重视开发文档

...

缺陷类型

所有缺陷可以归结为三类:

遗漏；规定的或预期的需求未体现在产品中(可能未将规格说明全面实现,也可能需求分析阶段就遗漏了需求)

错误: 未将规格说明正确实现(可能设计错误、也可能编码错误)

额外的实现:规格说明并未规定的需求被纳入产品,得到实现

缺陷的放大模型

需求阶段缺陷----概要设计阶段缺陷----详细设计阶段缺陷----编码设计阶段缺陷

常见的其他引入缺陷的原因

软件复杂度越来越高

编程中产生错误

需求不断变更

项目进度的压力

不重视开发文档

...