1 软件测试背景
软件测试一：软件测试综述之软件测试的背景、实质、软件开发的过程
软件测试⼀：软件测试综述之软件测试的背景、实质、软件开发的过程1、软件测试的背景1、缺陷是什么（缺陷的官⽅定义）产品说明书：对开发的产品进⾏定义，给出产品的细节、如何做、做什么、不做什么。
只有⾄少满⾜下列5个规则之⼀才称发⽣了⼀个软件缺陷：1. 软件未实现产品说明书要求的功能2. 软件出现了产品说明书指明不会出现的错误3. 软件实现了产品说明书未提到的功能4. 软件未实现产品说明书虽未明确提出但应该实现的⽬标5. 软件难以理解，不易使⽤，运⾏缓慢或者--从测试员的⾓度看--最终⽤户会认为不好注意：软件测试员在运⽤第5条测试规则时，要全⾯，最重要的是要客观评价，并⾮所有测试发现的缺陷都要修改。
2、缺陷产⽣的原因最⼤原因：产品说明书（说明书--没有写或者不够全⾯、经常更改、沟通不⾜）；第⼆：设计（程序员规划软件的过程--随意、易变、沟通不⾜）；其次：把本来正确的当成缺陷、测试错误。
这类缺陷只占极⼩的⽐例，不必担⼼。
最⼤原因：需求规格说明书；第⼆：设计⽅案；其次：编写代码，其他1）需求理解错误，编写过程中引起的错误2）需求不断变更：项⽬失败的最⼤杀⼿，会引起重新设计，⼯程重新安排3）开发过程中缺乏有效的沟通，或没有进⾏沟通：导致设计不正确4）编程中产⽣错误5）软件开发⼯具本⾝隐藏的问题：选择较为成熟的产品6）不重视开发⽂档7）软件复杂度越来越⾼8）项⽬进度的压⼒3、软件测试员的⽬标尽可能早地找出软件缺陷、并确保其得以修复。
（注意：修复缺陷并⾮⼀定要改正软件。
可以是指在⽤户⼿册中增加⼀段注释或为⽤户提供特殊的p）4、测验1、在千年⾍例⼦中，dave有错吗？如果dave是个好的程序员，他应该对这个‘显然的’疏忽产⽣疑问⽽不是仅仅将程序涉及到只能有效⼯作到1999年，由于他没有这样做，软件测试源就应该测试并发现该缺陷，然后⼜开发⼩组确定是否修正。
2、判断是⾮：公司或开发⼩组⽤户称呼软件问题的术语很重要。
错。
软件测试质量保障方案
软件测试质量保障方案第1章质量保障概述 (4)1.1 软件测试背景与意义 (4)1.2 质量保障体系构建 (4)1.3 质量保障策略与目标 (5)第2章测试团队组织与管理 (5)2.1 测试团队构建 (5)2.1.1 团队层次结构 (5)2.1.2 团队规模 (5)2.2 岗位职责与能力要求 (5)2.2.1 测试管理层 (6)2.2.2 测试设计层 (6)2.2.3 测试执行层 (6)2.2.4 测试支持层 (6)2.3 团队协作与沟通 (6)2.3.1 团队协作 (6)2.3.2 沟通 (6)第3章测试需求分析 (6)3.1 需求获取与分析 (6)3.1.1 需求获取 (6)3.1.2 需求分析 (7)3.2 测试需求管理 (7)3.2.1 测试需求文档化 (7)3.2.2 测试需求跟踪 (7)3.2.3 测试需求变更管理 (7)3.3 需求变更控制 (7)3.3.1 建立需求变更管理制度 (8)3.3.2 变更影响分析 (8)3.3.3 变更决策 (8)3.3.4 变更实施与跟踪 (8)第4章测试计划与策略 (8)4.1 测试计划制定 (8)4.1.1 目标与范围 (8)4.1.2 测试依据 (8)4.1.3 测试阶段划分 (8)4.1.4 测试方法与工具 (8)4.2 测试策略制定 (8)4.2.1 功能性测试策略 (8)4.2.2 功能测试策略 (9)4.2.3 兼容性测试策略 (9)4.2.4 安全性测试策略 (9)4.2.5 用户体验测试策略 (9)4.3.1 测试进度安排 (9)4.3.2 测试资源分配 (9)4.3.3 缺陷管理 (9)4.3.4 测试报告 (9)第5章测试用例设计 (9)5.1 测试用例编写方法 (9)5.1.1 确定测试目标 (9)5.1.2 分析需求文档 (10)5.1.3 设计测试用例 (10)5.1.4 测试用例维护 (10)5.2 测试用例管理 (10)5.2.1 测试用例库建立 (10)5.2.2 测试用例版本控制 (10)5.2.3 测试用例权限管理 (10)5.2.4 测试用例维护与更新 (10)5.3 测试用例评审 (10)5.3.1 评审流程 (11)5.3.2 评审内容 (11)5.3.3 评审记录 (11)第6章测试执行与监控 (11)6.1 测试环境搭建 (11)6.1.1 环境概述 (11)6.1.2 硬件环境 (11)6.1.3 软件环境 (11)6.1.4 网络环境 (11)6.1.5 数据准备 (12)6.2 测试执行 (12)6.2.1 测试用例执行 (12)6.2.2 测试方法 (12)6.2.3 测试数据管理 (12)6.2.4 自动化测试 (12)6.3 缺陷跟踪与管理 (12)6.3.1 缺陷报告 (12)6.3.2 缺陷跟踪 (12)6.3.3 缺陷分析 (12)6.3.4 缺陷管理工具 (12)6.4 测试监控与报告 (12)6.4.1 测试进度监控 (12)6.4.2 测试结果分析 (12)6.4.3 风险识别与应对 (12)6.4.4 测试报告 (12)第7章自动化测试 (13)7.1 自动化测试概述 (13)7.2.1 功能自动化测试工具 (13)7.2.2 功能自动化测试工具 (13)7.2.3 接口自动化测试工具 (13)7.3 自动化测试脚本编写 (13)7.3.1 脚本编写规范 (13)7.3.2 脚本编写技巧 (13)7.4 自动化测试框架设计 (14)7.4.1 框架结构 (14)7.4.2 框架功能 (14)第8章功能测试与优化 (14)8.1 功能测试概述 (14)8.1.1 功能测试目的 (14)8.1.2 功能测试内容 (14)8.1.3 功能测试原则 (15)8.2 功能测试方法与工具 (15)8.2.1 功能测试方法 (15)8.2.2 功能测试工具 (15)8.3 功能瓶颈分析 (15)8.3.1 数据分析 (15)8.3.2 瓶颈定位 (16)8.3.3 问题解决 (16)8.4 功能优化策略 (16)8.4.1 代码优化 (16)8.4.2 数据库优化 (16)8.4.3 网络优化 (16)8.4.4 硬件优化 (16)第9章安全测试与防护 (16)9.1 安全测试概述 (16)9.2 安全测试方法与工具 (17)9.2.1 安全测试方法 (17)9.2.2 安全测试工具 (17)9.3 安全漏洞分析与防护 (17)9.3.1 安全漏洞分类 (17)9.3.2 安全漏洞防护措施 (17)9.4 安全测试策略与实施 (17)9.4.1 安全测试策略制定 (17)9.4.2 安全测试实施 (17)9.4.3 安全测试持续改进 (17)第10章测试总结与改进 (18)10.1 测试项目总结 (18)10.1.1 测试范围与目标回顾 (18)10.1.2 测试覆盖率和缺陷分析 (18)10.1.3 测试资源利用分析 (18)10.2 测试过程改进 (18)10.2.1 优化测试策略 (18)10.2.2 测试流程规范化 (18)10.2.3 缺陷管理改进 (18)10.2.4 测试工具与技术选型 (18)10.3 测试团队能力提升 (18)10.3.1 培训与交流 (19)10.3.2 建设专业人才队伍 (19)10.3.3 优化团队组织结构 (19)10.4 持续集成与持续改进 (19)10.4.1 持续集成实践 (19)10.4.2 持续改进机制 (19)10.4.3 测试数据与经验积累 (19)第1章质量保障概述1.1 软件测试背景与意义信息技术的飞速发展，软件已经成为支撑现代社会运行的重要基石。
软件测试(测试背景概念和分类)
软件测试背景 ❖小结
▪ 首先我们知道了Bug的官方定义，产生原因和修复成本。从而使 我们更加深刻的理解了软件测试员的根本目的，测试人员应该具 备的素质和应该承担的工作。
软件测试(测试背景概念和分类)中软19国
软件测试概述
•本章是主要介绍软件测试的本质，包括软件 测试的概念和原则，并且集中阐述了软件测试 的分类。弄懂本章的知识对于今后的学习有非 常重要的意义。
的程序员合作） ▪ 说服力（善于表达观点，通过实际演示标明缺陷为何必须修复）
中软国际（天津ETC)
软C件h测in试aS(o测ft试I背nt景er概na念tio和n分al类中)软中国软际国
软件测试背景
❖软件测试人员在测试过程中要肩负着如下 职责：
▪ 测试人员要了解项目需求内容，从用户的角度 提出自己的测试看法。
软件测试背景
❖爱国者导弹防御系统，1991
❖ 事件：
美国爱国者导弹防御系统是罗纳德里根总体提出的主动战略防御（即 星球大战）程序的缩略版本。它首次应用在海湾战争中对抗伊拉克飞毛腿导 弹的防御战争中。尽管对于该系统的赞誉不绝于耳，但是它确实在几次对抗 导弹的战役中失利。其中一枚在沙特阿拉伯的多哈击毙28名美国士兵。
软件测试员的目的是尽早发现软件缺陷，并确保其得以修复。
中软国际（天津ETC)
软C件h测in试aS(o测ft试I背nt景er概na念tio和n分al类中)软中国软际国
软件测试背景
❖怎样成为优秀软件测试员
❖ 软件测试员应具备的素质
▪ 探索精神（喜欢拿到新软件） ▪ 故障排除能手（善于发现问题的症结） ▪ 不懈努力（不停尝试） ▪ 创造性（想出富有创意甚至超常的手段来寻找缺陷） ▪ 追求完美（力求完美，但不苛求，尽力接近目标） ▪ 判断准确（决定测试内容、测试时间、是否真正的缺陷） ▪ 老练稳重（知道如何将坏消息告诉程序员，知道如何跟不够冷静
软件质量保证与软件测试技术
1.1.2 软件缺陷与故障
1、软件缺陷和软件故障案例
• 案例1 美国迪斯尼公司的狮子王游戏软件bug 兼容性问题 • 案例2 美国航天局火星登陆事故 系统测试 衔接问题 • 案例3 跨世纪“ 千年虫” 问题 • 案例4 爱国者导弹防御系统炸死自家人 系统时钟误差积累 • 案例5 Windows 2000 中文输入法漏洞 上述所有实例中的软件问题在软件工程或软件测试中 都被称为软件缺陷或软件故障。
软件测试技术概要（续）
• 软件测试技术的发展趋势： （1）软件验证技术 （2）静态测试分析技术 （3）测试数据的选择— — 主要对测试用例进行选择 通常从下面几个方面评价测试用例的质量： 检测软件缺陷的有效性、测试用例的可重用性、 测试用例的经济性、测试用例的可维护性 （4）集成化测试— — 研究如何实现软件测试的自动 化过程以及相关的一系列内容。
4、测试信息流程 测试信息流程如图1-2所示。测试过程中需要 三类输入：软件配置、测试配置和测试工具。
回归测试 软件配置 测试配置 测试工具
修正的软件 测试结果 错误 测试结果 结果分析 改正错误 测试
预期结果
可靠性分析
预测的可靠性
图1-2 测试信息流程
软件测试的基本理论（续）
5、软件测试的周期性 软件测试的周期性是“ 测试->改错->再测试-> 再改错” 这样一个循环过程，如下图1-3所示。
1.2.4 软件测试技术概要
• 软件测试的策略：就是测试将按照什么样的思路 和方式进行。通常，软件测试要经过单元测试、 集成测试、确认测试、系统测试以及验收测试。 • 软件测试技术： （1）白盒测试和黑盒测试 （2）静态测试和动态测试 （3）传统测试方法和面向对象测试的方法 （4）特定环境及应用的测试
软件测试大纲
第1章软件测试背景1.1 软件测试现状1.1.1 国外软件测试现状1.1.2 国内软件测试现状与发展趋势1.2 软件缺陷定义1.3 为什么会出现软件缺陷1.4 软件缺陷的修复费用1.5 软件测试员应该做些什么1.6 优秀的测试工程师应具备的素质第2章软件测试与软件开发关系2.1 软件开发过程2.2 软件测试在软件开发中的作用2.3 软件测试过程模型2.4 软件测试环境的搭建第3章软件测试的实质3.1 软件测试的原则3.2 软件测试的术语和定义第二部分软件测试基础第4章软件测试概念4.1 软件测试定义4.1.1软件测试正向思维4.1.2 软件测试反向思维41..3 IEEE定义的测试4.1.4 广义软件测试4.2 软件测试的目的4.3 软件测试心理学4.3.1 程序测试过程具有破坏性4.3.2程序员应避免测试自己的程序4.3.3 程序设计机构不应测试自己的程序4.4 软件测试的分类4.4.1 按照开发阶段划分4.4.2 按照测试实施组织划分4.4.3 按照测试技术划分4.4.4 按照执行状态划分4.4.5 按照软件特效划分4.4.6 其他划分4.5 软件测试的流程第5 章黑盒测试技术5.1 静态黑盒测试5.2 通过性测试和失效性测试5.2 等价类划分5.2.1 等价类划分方法5.2.2 等价类划分法的测试运用5.3 边界值分析法5.3.1 边界条件5.3.2 次边界条件5.3.3 特殊数据5.3.4 边界值分析法的测试运用5.4 决策表法5.4.1 决策表法的原理5.4.2 决策表法的测试运用5.4 因果图法5.4.1 因果图法的原理5.4.2 因果图法的测试运用5.5 其它黑盒测试技术5.5.1 像笨拙的用户那样做5.5.2 在已经找到的软件缺陷的地方再找找5.5.3 像黑客一样考虑问题5.5.4 凭借经验、直觉和预感第6 章白盒测试技术6.1 静态白盒测试6.1.1 检查设计和代码6.1.2 静态错误分析6.1.3 通用代码审查清单6.2 单元测试6.2.1 单元测试环境6.2.2 单元测试方法6.2.3 单元测试用例设计6.3 集成测试6.3.1 非增量式测试6.3.2 增量测试方法6.3.3 回归测试6.3.4 冒烟测试第7章灰盒测试技术第8章系统测试技术8.1 功能测试8.2 错误处理测试8.3 内存泄漏测试8.4 用户界面测试8.5 安装与卸载测试8.6 升级测试8.7 兼容性测试8.8 安全测试8.9 性能测试8.10 压力测试第9章WEB测试9.1 WEB测试特点9.2 用户界面测试9.3 功能测试9.4 表单测试9.5 兼容性测试9.6 安全测试第10章APP测试12.1 移动环境12.2 手机测试与传统测试的区别12.3 移动测试面临的挑战12.3.1 移动设备多样性12.3.2 运营商网络基础设施12.3 测试方法12.3.1 真机测试12.3.2 基于模拟器的测试第11章软件自动化测试13.1 LoadRunner性能测试工具13.1.1 环境搭建及主要功能菜单介绍13.1.2 性能测试相关术语13.1.3 性能测试流程13.1.4 脚本录制过程13.1.5 优化性能脚本13.1.6 执行测试场景及结果分析13.2 QTP自动化测试工具13.2.1 环境搭建及主要功能菜单介绍13.2.2 录制、回放自动化脚本13.2.3 优化自动化脚本13.2.4 执行自动化脚本及结果分析13.3 Monkey自动化测试工具第四部分测试管理第12章编写、跟踪测试用例13.1 测试用例的定义和特征13.2 设计测试用例目的13.3 好的测试用例是什么样子13.4 测试用例包含内容13.5 设计测试用例常用方法第13章报告发现的问题14.1 软件缺陷跟踪管理系统14.1.1 缺陷包含的内容14.1.2 bug状态14.1.3 bug重要程度划分14.1.4 bug优先级划分14.2设法修复软件缺陷14.3 分离和再现软件缺陷14.4 软件缺陷的生命周期第14章常用的缺陷管理工具15.1 TestDirector使用介绍15.2 Quality Center使用介绍15.3 BugFree第17章软件测试项目管理17.1 建立测试管理体系17.2 测试管理的基本内容17.3 测试组织管理17.4 测试过程管理17.5 资源和配置管理17.6 测试文档管理17.7 测试管理原则17.8 测试管理实践。
第1章_软件测试的背景
千年虫：约1974
当时计算机存储空间小，为节省字节，将四 位的年份用两位表示。 只有到数十年后的2000年1月1日才会出现 问题，这期间肯定会升级 或更改系统。 各种系统中这类问题的解决 费用估计超过数亿美元。
美国爱国者导弹防御系统：1991
该系统应用于海湾战争中对抗伊拉克飞毛腿导 弹的防御战，有几次在对抗导弹战役中失利， 其中一枚在沙特阿拉伯的多哈击毙了28名美军 士兵。 原因：软件缺陷。一个很小的系统时钟错误累 积起来就可能延迟14小时，造成跟踪系统失去 准确度。在多哈袭击战中，系统被延迟100多个 小时。
软件测试员的职责
发现软件缺陷 尽可能早的发现软件缺陷 尽可能早的发现软件缺陷，并确保其得以修 复。 修复：不一定是修改程序，比如对用户进行 特殊的培训。 真正的“十全十美”通常是难以企及的，不 要纠缠于难以达到的完美。
1.6 软件测试员应具备的素质
业务素质 业务知识 产品设计知识 了解软件架构 了解UML 掌握自动化测试工具 懂一些开发知识 编写文档的能力
优秀的软件测试员应具备的素质
他们是群探索者 他们是故障排除员 他们不放过任何蛛丝马迹 他们具有创造性 他们是群追求完美者 他们判断准确 他们注重策略和外交 他们善于说服 在软件编程方面受过教育
1.7 软件测试现状及趋势
国际现状： 国际现状：测试在软件开发中占有不可或缺的 重要地位
阶段 资金量 需求分析 3% 设计 8% 编码 7% 测试 15% 投产和维护 67%
14
迪斯尼的狮子王：1994－1995
1994年秋，迪斯尼公司发布了面向儿童的游 戏“Lion King Animated Storybook”，进 行了大量的宣传和促销，销售额可观。12月 26日，开始收到大量投诉：游戏无法正常运 行，舆论哗然。 原因：没有对市场上的各种PC机型进行测试， 该软件只能在少数系统中正常工作，但在大 众常用的系统中不行。
软件测试行业背景
该公司注重玩家体验和游戏性能的测试。他们采用敏捷开发方法，与 开发团队紧密合作，快速迭代和优化。
挑战与应对
随着游戏规模扩大和玩家数量增长，性能和稳定性成为主要问题。为 此，他们引入负载和压力测试，模拟大量用户同时在线的情况。
结果
通过优化测试流程和增加负载/压力测试，该游戏公司提高了游戏的 稳定性和性能，赢得了更多玩家。
软件测试行业的发展前景
自动化测试的普及
随着技术的发展，自动化测试将逐渐成为主流，提高测试效率和 质量。
云测试和容器化测试的兴起
云技术和容器技术的发展将推动云测试和容器化测试的普及和应用。
个性化测试服务的涌现
随着软件需求的多样化，个性化测试服务将逐渐成为主流，满足不 同客户的需求。
05
软件测试行业的案例分析
目的
发现代码级别的错误和问 题，确保软件在代码层面 上是正确的。
方法
通过检查代码的内部结构、 逻辑和实现细节，发现潜 在的缺陷和问题。
灰盒测试
定义
灰盒测试结合了黑盒测试和白盒测试 的特点，既关注软件的功能和用户界 面，也关注内部的逻辑和实现细节。
目的
方法
通过输入数据、操作和检查内部结构， 验证软件的输出结果、性能和安全性 等是否符合预期。
全面评估软件的质量，确保软件在功 能、性能和安全性等方面都满足要求。
自动化测试工具
定义
自动化测试工具是用于自动化软 件测试过程的工具，可以模拟人 工操作，执行测试用例并生成测
试报告。
目的
提高测试效率，减少人工干预，降 低测试成本。
方法
通过编写脚本语言或使用工具提供 的界面，创建和执行自动化测试用 例。
软件测试行业的机遇
软件测试背景概述
xiangr@
IT Education & Training
1.2.4软件测试技术概要
1.软件测试策略 软件测试策略就是测试将按照什么样的 思路和方式进行。通常，软件测试要经 过单元测试、集成测试、确认测试、系 统测试和验收测试。
xiangr@
IT Education & Training
xiangr@
IT Education & Training
1.3.1软件产品的组成
7.其他组成部分
① ② ③ ④ ⑤ 帮助文件 用户手册 样本和示例 产品支持信息 图表和标志 ⑥ 错误信息 ⑦ 广告与宣传材料产品支 持信息 ⑧ 软件的安装 ⑨ 软件说明文件 ⑩ 测试错误提示信息
5.测试文档
1.3.1软件产品的组成
一般的测试文档包括如下: ① 测试计划 ② 测试用例设计 ③ 软件测试报告 ④ 归纳、统计和总结
xiangr@
IT Education & Training
1.3.1软件产品的组成
6.开发进度（Gantt图）
① 系统最终交付日期已经确定，软件开发部门 必须在规定期限内完成 ② 系统最终交付日期只确定了大致的年限，最 后交付日期由软件开发部门确定 ③ Gantt图中横坐标表示时间，纵坐标表示任 务，图中的水平线段表示对一个任务的进度 安排，线段的起点和钟点对应在横坐标上的 时间分别表示该任务的开始时间和结束时间， 线段的长度表示完成该任务所需的时间。
IT Education & Training
软件测试的原则
⑤ 对测试错误结果一定要有一个确认的过程。一 般有A测试出来的错误，一定要有一个B来确 认，严重的错误可以召开评审会进行讨论和分 析。 ⑥ 制定严格的测试计划，并把测试时间安排得尽 量宽松，不要希望在极短的时间内完成一个高 水平的测试。 ⑦ 回归测试的关联性一定要引起充分的注意，修 改一个错误而引起更多错误出现的现象并不少 见。 ⑧ 妥善保存一切测试过程文档，意义是不言而喻 xiangr@ 的，测试的重现性往往要靠测试文档。
第1章_软件测试的背景
2013年7月9日6时19分
软件测试员的目标
软件测试员的目标是发现软件缺陷。 软件测试员的目标是尽可能早地找出软件缺陷。
随着时间的推移，修复软件缺陷的费用将迅速增长
软件测试员的目标是尽可能早地找出软件缺陷，并确 保其得以修复。
2013年7月9日6时19分
2013年7月9日6时19分
Wang_anwen@
26
软件测试的特点
完全测试程序是不可能的 软件测试是有风险的行为 测试很难显示潜伏的软件缺陷 找到的软件缺陷越多，就说明软件缺陷越多 杀虫剂现象：软件测试越多，免疫力越强 并非所有软件缺陷都能修复 没有足够的时间、修复的风险、不值得修复 难以说清的软件缺陷 产品说明书不断变化，没有最终版本 软件测试员在产品小组中不受欢迎 早点找出缺陷、控制情绪、不要总是报告坏消息 软件测试是一项讲究条理的技术工作
31
软件测试背景
软件测试的发展
1970S:
Glenford J. Myers: 测试是尽可能多地发现软件错误 Myers的软件测试定义： 测试是为发现错误而执行一个程序或系 统的过程
测试（test）
2013年7月9日6时19分
Wang_anwen@
22
软件测试的定义与定位（分析）
把软件测试(包括其它任何测试)定位在证明软件的 正确性上是不对的,软件测试的目标是:查件正确性的目标不可达：测试是无法证明软件的正 确性的，原因是我们无法对软件进行理想测试（在理想情 况下：对程序的所有可能执行情况进行测试），如完全的 白盒测试（设计若干测试用例，使得软件中所有的执行路 径都被执行到，见图1）或黑盒测试（设计若干测试用例， 穷举所有软件可能的输入，见图2），这都要花费我们不 能承受的成本（时间，人力），退一步讲，就算我们能对 软件实施完全的白盒测试与黑盒测试，我们也无法保证软 件在需求获取或是设计上没有失误，更何况我们还要考虑 到非法和无效输入的问题。
1、软件质量和测试的背景
三个阶段
我们可以把与软件工程相关的工作分为三 个阶段，其中的每个阶段能够回答上述的 一个或多个问题：
定义阶段针对“做什么” 开发阶段针对“如何做” 维护阶段针对“改变”
14
补充说明
还有很多保护性活动用来补充说明在软件工程的 一般视图中的各个阶段和相关步骤，这些典型的 贯穿于整个软件过程中的活动包括：
7
新的挑战也逐渐显现出来
普适计算 网络资源 开源软件 新经济
8
1.1.2
层次化软件工程
Fritz Bauer在NATO（北大西洋公约组织）会议 上给出的定义仍是我们进一步展开讨论的基础：
软件工程：是为了经济地获得可靠的和能在实际机器 上高效运行的软件而建立和使用的好的工程原则。
软件是计算机程序、规程以及可能的相关文档 和运行计算机系统需要的数据。软件包含计算 机程序、规程、文档和软件系统运行所必需的 数据四个部分。
4
软件具有与硬件完全不同的特征
软件是开发产生的，而不是用传统方法制 造。 软件不会像硬件一样有磨损。 很多软件不能通过已有构件组装，只能自 己定义。
软件质量保证与测试
第1章 软件质量和测试的背 景
1
内容提要
1.1
软件特征与软件工程
1.1.1 1.1.2 1.1.3 1.1.4 软件分类 层次化软件工程 软件范型的转变 现代软件开发 质量概念 质量运动 软件质量概念 软件质量评价体系与标准 软件测试的意义 软件测试的定义 软件测试方法 软件测试自动化 软件缺陷的修复费用 现代软件研发对软件人才的需求 优秀的软件测试员应具备的素质
第1章 软件测试背景
大纲
1.1 软件测试起源 1.2 什么是软件缺陷 1.3 为什么会出现软件缺陷 1.4 软件缺陷的修复费用 1.5 软件测试员的职责 1.6 软件测试员应具备的素质 1.7 软件测试行业的前景
1.7 软件测试行业的发展前景
国内现状，2006年的一个统计数据
重要性调查：68.2%的企业认为软件测试非常 重要，必须设立软件测试部分，与开发同样重 要；31.8%的企业认为比较重要；0%的认为 可有可无。
测试人员与开发人员比例： 36.5%的企业为 1:5 31.8%的企业为 1:2 31.7%的企业>= 1:1
1.4 软件缺陷的修复费用
从 说明书——》设计——》编码——》测试——》发布 其修复费用成指数级增长
狮子王案例：如果在写产品 说明书时，有人研究过当下 流行的PC配置；如果……
大纲
1.1 软件测试起源 1.2 什么是软件缺陷 1.3 为什么会出现软件缺陷 1.4 软件缺陷的修复费用 1.5 软件测试员的职责 1.6 软件测试员应具备的素质 1.7 软件测试行业的前景
即使测试用例集满足上述条件，仍不能保证 可以查找出所有可能的错误
即使测试一个这么小的程序，也不是件容易 的事
完全测试一个复杂的、实际运行的程序似乎 是不太可能的——可以通过使用一些测试技 术，尽可能完全地对软件进行测试
软件测试之所以困难，是因为：
我们在任何地方都可能犯错。从软件的需求获 取阶段到代码编写阶段以及各阶段之间的转换 过程都有可能引入错误，贯穿整个软件生命周 期，因此占整个开发工作量的45%。
软件测试的背景和发展
软件测试的发展历史.. 20世纪60年代（软件工程建立前），为表明程序正确而进行测试。
.. 1972年在北卡罗来纳大学举行了首届软件测试正式会议。
.. 1975年John Good Enough和Susan Gerhart在IEEE上发表了《测试数据选择的原理》的文章，软件测试被确定为一种研究方向。
.. 1979年，Glenford Myers的《软件测试艺术》，对测试做了定义：测试是为发现错误而执行的一个程序或者系统的过程。
.. 20世纪80年代早期，“质量”的号角开始吹响。
软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。
制定了各类标准。
.. 1983年，Bill Hetzel在《软件测试完全指南》中指出：测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。
.. 20世纪90年代，测试工具盛行起来。
.. 1996年提出的测试能力成熟度TCMM（Testing Capability Maturity Model）、测试支持度TSM（Testability Support Model）、测试成熟度TMM（Testing Maturity Model）。
.. 到了2002年，Rick和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义：测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。
软件测试流程•一、新产品或工程管理流程1、需求调研在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。
2、制定测试计划进行每一种测试之前，测试负责人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Ø 编码人员造成的，人员素质和技术水平是其中原因之一
Ø 间接的看，来自上层的分析和设计问题
其他 编写产品描述 设计 编写代码
程序错误分类-按软件生存期阶段分类
• 软件的逻辑错误按生存期不同阶段分为4 类。
1.问题定义（需求分析）错误
它们是在软件定义阶段，分析员研究用户的要 求后所编写的文档中出现的错误。换句话说，这类 错误是由于问题定义不满足用户的要求而导致的错 误。
（4）静态逻辑错误：这类错误主要包括：不正确地 使用CASE语句；在表达式中使用不正确的否定 （例如用“＞”代替“＜”的否定）；对情况不适当地分 解与组合；混淆“或”与“异或”等。
4.数据错误 （1）动态数据错误 ：动态数据 是在程序执行过程中 暂时存在的数据 （2）静态数据错误：静态数据在内容和格式上都是 固定的。它们直接或间接地出现在程序或数据库 中。由编译程序或其它专门程序对它们做预处理。 （3）数据内容错误：数据内容 是指存储于存储单元 或数据结构中的位串、字符串或数字。数据内容本 身没有特定的含义，除非通过硬件或软件给予解 释。数据内容错误就是由于内容被破坏或被错误地 解释而造成的错误。 （4）数据结构错误：数据结构是指数据元素的大小 和组织形式。在同一存储区域中可以定义不同的数 据结构。数据结构错误主要包括结构说明错误及把 一个数据结构误当做另一类数据结构使用的错误。 这是更危险的错误。 （5）数据属性错误：数据属性是指数据内容的含义 或语义。
Ø Defects’ categories:
Ø Wrong： 未将规格说明书正确实现 Ø Missing：规定的或者预期的需求没有体现在产品中
Ø Extra ：规格说明书中未规定的需求被纳入产品加以 实现
软件bug
• 软件bug机理可描述为:软件错误，软件缺陷，软 件故障，软件失效。
– 软件错误：是指在软件生存期内的不希望或不可接受 的人为错误，其结果是导致软件缺陷的产生。
4. 严重错误：系统运行不可跟踪，一时不能掌握其规律，时好 时坏。
5. 非常严重的错误：系统运行中突然停机，其原因不明，无法 软启动。
6. 最严重的错误：系统运行导致环境破坏，或是造成事故，引 起生命、财产的损失。
程序错误分类
• 按错误的性质和范围分类
B.Beizer从软件测试观点出发，把软件错误分为5类。
程序错误分类-按错误的性质和范围分类
5.代码错误
主要包括：语法错误；打字错误；对语句或指令不正 确理解所产生的错误。
软件缺陷按软件生存期阶段分类
Ø 软件缺陷的产生原因：
Ø 产品规格说明书（SRS）
Ø 没有写 Ø 不够全面，准确，细致 Ø 经常变更
Ø 软件的设计（Architecture）
Ø 这是软件的蓝图 Ø 描述不够清楚 Ø 框架的结合不够紧密和连贯 Ø 软件框架经常变动，不稳定
Ø 开发人员及开发过程之间管理不规范，约定不严 格，文档书写不完整，软件可维护性不好。
Ø 缺少严密有效的质量检验手段，交付给用户的软 件质量差，运行中出现许多问题，带来严重后 果。
Ø 系统更新换代难度大
Software Crisis !
软件工程
• 将系统化的、规范的、可度量的方法应用 于软件的开发、运行和维护的过程，即将 工程化应用于软件中。
– Hold状态：第三方产品引起的、或是无法解决的 bug。
– Differed状态：不需解决或准备在下版中解决的bug。
软件缺陷的定义
Ø 简单说：软件中不满足的问题称为软件缺陷 Ø 软件缺陷的详细定义：
Ø 软件没有达到产品说明书表明的功能 Ø 软件出现了产品说明书指明不会出现的问题 Ø 软件功能超出产品说明书指明的范围 Ø 软件没有达到产品说明书虽未指明，但应该达到的功
软件测试
& 教材 (Text Book)
软件测试
[美]Paul C.Jorgensen 译：韩柯
机械工业出版社
& 参考书目(References)
¨软件测试
[美]Ron Patton 译：张小松
¨软件测试方法和技术
朱少民主编 清华大学出版社
& 参考书目 (References)
Software Testing
– 软件缺陷：是存在于软件（文档、数据、程序）之中 的那些不希望或不可接受的偏差。其结果是软件运行 于某一特定条件时出现软件故障，这时称软件缺陷被 激活。
– 软件故障：是指软件运行过程中出现的一种不希望或 不可接受的内部状态。此时若无适当措施（容错）加 以及时处理，便产生软件失效。
– 软件失效：是指软件运行时产生的一种不希望或不可 接受的外部行为结果。
（4）不可行错误：规格说明中有些功能要求是不可行 的。
（5）不可测试错误：有些功能的测试要求是不现实的。
程序错误分类-按软件生存期阶段分类
3.设计错误
这是在设计阶段产生的错误，它使系统的设计与需求规格 说明中的功能说明不相符。它们又可以细分为：
（1）设计不完全错误：某些功能没有被设计，或设计得 不完全。
软件生存周期包括软件定义、软件开发、软件使 用与维护。
软件生存期各阶段间需保持的正确性
理解正确性 表达正确性
用户要求 用户: 我要什么?
1
相符吗?
5
需求说明书
分析员: 我可以提 供什么?
理解正确性 设计正确性 表达正确性
2
设计说明书
设计员: 我要让软件行得 到的结果
程序错误分类-按软件生存期阶段分类
2.规格说明错误
这类错误是指规格说明与问题定义不一致所产生的错误。 它们又可以细分成：
（1）不一致性错误：规格说明中功能说明与问题定义发 生矛盾。
（2）冗余性错误：规格说明中某些功能说明与问题定义 相比是多余的。
（3）不完整性错误：规格说明中缺少某些必要的功能说 明。
能 Ø 软件测试人员认为软件难以理解、不易使用、运行速
度慢，或者用户认为不好。
软件缺陷的积累和放大效应
45 40 35 30 25 20 15 10
5 0
需求 设计 编码 测试 维护
2.系统错误 （1）外部接口错误：外部接口指如终端、打印机、通信线路等 系统与外部环境通信的手段。 （2）内部接口错误：内部接口指程序之间的联系。它所发生的 错误与程序内实现的细节有关。例如，设计协议错、输入／ 输出格式错、数据保护不可靠、子程序访问错等。 （3）硬件结构错误 ：这类错误在于不能正确地理解硬件如何工 作 。例如，忽视或错误地理解分页机构、地址生成、通道容 量、I／O指令、中断处理、设备初始化和启动等而导致的出 错。 （4）操作系统错误：这类错误主要是由于不了解操作系统的工 作机制而导致出错。当然，操作系统本身也有错误，但是一 般用户很难发现这种错误。 （5）软件结构错误：由于软件结构不合理或不清晰而引起的错 误。这种错误通常与系统的负载有关，而且往往在系统满载 时才出现。这是最难发现的一类错误。 （6）控制与顺序错误：这类错误包括：忽视了时间因素而破坏 了事件的顺序；猜测事件出现在指定的序列中；等待一个不 可能发生的条件；漏掉先决条件；规定错误的优先级或程序 状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理 步骤等。 （7）资源管理错误：这类错误是由于不正确地使用资源而产生 的。
• 为了便于跟踪和管理某个产品的缺陷，可以定义 不同的bug状态:
– 激活状态(Active或Open)：问题还没解决，测试员报 的bug、或验证后bug仍然存在。
– 已修正状态(Fixed或Resolved)：开发人员针对缺 陷，修改程序，认为已解决问题，或通过单元测试。
– 关闭或非激活状态(Close或Inactiv)：测试员验证 Fixed bug后，确认bug已改的状态。
程序错误分类-按软件生存期阶段分类
4.编码错误
编码过程中的错误是多种多样的 ，大体可归为 以下几种 ：数据说明错、数据使用错、计算错、比 较错、控制流错、界面错、输入／输出错，及其它 的错误。
在不同的开发阶段，错误的类型和表现形式是 不同的，故应当采用不同的方法和策略来进行检 测。
软件缺陷的状态
程序错误分类
按错误的影响和后果分类
1. 较小错误：只对系统输出有一些非实质性影响。如，输出的 数据格式不合要求等。
2. 中等错误：对系统的运行有局部影响。如输出的某些数据有 错误或出现冗余。
3. 较严重错误：系统的行为因错误的干扰而出现明显不合情理 的现象。比如开出了0.00元的支票，系统的输出完全不可信 赖。
运行正确性
4
输入正确性
源程序
程序员:
我要让计算
3
机什么做?
理解正确性 编码正确性
ABC
D
ABC
BC
CB
？
软件测试
• 简单地说，软件测试就是为了发现错误而执行程 序的过程。
• 在IEEE提出的软件工程标准术语中，软件测试被 定义为：“使用人工和自动手段来运行或测试某个 系统的过程，其目的在于检验它是否满足规定的 需求或弄清楚预期结果与实际结果之间的差别。”
3.加工错误
（1）算术与操作错误：指在算术运算、函数求值和 一般操作过程中发生的错误。
（2）初始化错误：典型的错误有：忘记初始化工作 区，忘记初始化寄存器和数据区；错误地对循环控 制变量赋初值；用不正确的格式，数据或类型进行 初始化等等。
（3）控制和次序错误：这类错误与系统级同名错误 类似，但它是局部错误。包括：遗漏路径；不可达 到的代码；不符合语法的循环嵌套；循环返回和终 止的条件不正确；漏掉处理步骤或处理步骤有错 等。
1.功能错误 2.系统错误 3.加工错误 4.数据错误 5.代码错误
程序错误分类-按错误的性质和范围分类
1.功能错误 （1）规格说明错误：规格说明可能不完全，有二义 性或自身矛盾。 （2）功能错误：程序实现的功能与用户要求的不一 致。这常常是由于规格说明中包含错误的功能、多 余的功能或遗漏的功能所致。 （3）测试错误：软件测试的设计与实施发生错误。 软件测试自身也可能发生错误。 （4）测试标准引起的错误：对软件测试的标准要选 择适当，若测试标准太复杂，则导致测试过程出错 的可能就大。