第一章-软件测试基础入门

1、第一章第一章 软件测试基础入门软件测试基础入门 主讲人：崔海燕 教学内容教学内容 p 1.1、什么是软件测试？ p 1.2、软件测试的重要性 p 1.3、软件测试定义 p 1.4、软件测试体系 p 1.5、软件测试的基础理论 p 1.6、软件测试技术的发展 1.11.1、什么是软件测试？、什么是软件测试？ p软件测试从杯具开始软件测试从杯具开始 给你一只纸杯，你如何去做测试？ 1.11.1、什么是软件测试？、什么是软件测试？ p软件测试从杯具开始软件测试从杯具开始 需求测试：查看杯子的使用说明 界面测试：查看杯子的外观 功能测试：装物体时漏或不漏，能不能喝到杯子中所装物体 安全性测试：有没有毒

2、或细菌 可靠性测试：从高处落下杯子的损坏度 可移植性测试：在不同地方、温度是否可正常使用 兼容性测试：装果汁、白水、酒精等 易用性测试：是否烫手，防滑，方便使用 疲劳测试：放24小时水 泄漏时间和情况测试：装汽油24小时看泄漏时间和情况 压力测试：放针不断加重，击穿 1.21.2、软件测试的重要性、软件测试的重要性 p由2007年奥运会门票销售系统性能问题、2011年 7.23动车追尾事件、2012.1月全国火车订票系统 崩溃事件、2012.2.29广州市出租车计费表不能跳 表事件所想到. 1.21.2、软件测试的重要性、软件测试的重要性 p奥运会门票销售系统性能问题 n 事件事件: : 20

3、07年，奥运会第二阶段门票开始预售，公众的奥 运热情很高，承担此次售票的票务网站一小时浏量 达800万次、每秒钟提交的站票申请20万张；呼叫 中心一小时呼入200万人次. 由于访问过大，导致售票系统速度慢、不能登录 系统的情况，最终整个系统崩溃。 n 原因原因: : 系统性能测试严重不足 1.21.2、软件测试的重要性、软件测试的重要性 p7.23动车追尾事件 n 事件事件: : 723甬温线特别重大铁路交通事故 ，2011年7月23 日20时34分，北京至福州的D301次列车行驶至温州 市双屿路段时，与杭州开往福州的D3115次列车追尾 ，导致D301次1、2、3列车厢侧翻，从高架桥上掉落

4、，毁坏严重，4车厢悬挂桥上，D3115次15、16车厢 损毁严重。事故已造成40人死亡，200多人受伤。 n 原因：原因： 由于温州南站信号设备在设计上存在严重缺陷，遭 雷击发生故障后，导致本应显示为红灯的区间信号 机错误显示为绿灯。 1.21.2、软件测试的重要性、软件测试的重要性 p2012.1月全国火车订票系统崩溃事件 n 事件事件: : 春节，Hold不住的回家路， 12年1月9日，铁道部官 方订票网站点击量超过14亿次，相当 于所有中国人当天都点击了一次。由于访问量太大 ，网站无法顺畅登录，最终导致崩溃。 n 原因原因: : 网站耗资数千万未做过春运模拟演练。 n 启示启示 巨大的火

5、车订票需求必然催生12306网站瘫痪的风 险。有句话说得好，成长是要付出代价的。 1.21.2、软件测试的重要性、软件测试的重要性 p广州的士遭遇“闰年虫”发作锁死1500辆的士计 费表 n 事件事件: : 2012年2月29日是四年一遇的2月29日，从凌晨起， 广州50多家出租车公司约1500辆出租车的计价器出 现故障。昨天上午，大量出租车集中在白云大道永 泰路段的检测点等待维修，一度造成该路段交通拥 堵。 n 原因原因: : 某些2008年前版本的出租车计价器有缺陷，在闰年 无法将时间跳至2月29日，导致发生了时间性锁表 故障。 1.31.3、软件测试定义、软件测试定义 p软件测试的历史

6、n 二十世纪70年代以前：边想边测试。 n 70年代末80年代中期：基础理论和几已经形成，作为 质量保证。 n 80年代末90年代中期：测试工具在质量和数量上不断 增长，测试自动化开始广泛应用。 n 90年后期：关注有效的过程程管理对软件测试的重要性 ，形成各种测试模型。 n 二十一世纪初：软件开发活动应该以测试为主导的思想 。随着软件测试分工的细化和成熟，促使大量的软件测 试服务机构涌现，从单一第三方测试到参与整个软件过 程的测试服务。 1.31.3、软件测试定义、软件测试定义 n 1、软件调试 n 2、独立的软件测试 n 3、定义软件测试 n 4、软件测试成为专门学科 n 5、开发与测试的

7、融合 1.31.3、软件测试定义、软件测试定义 p软件测试的发展趋势 1.软件测试技术进入快速发展轨道 2.自动化软件测试技术应用越来越普遍 3.测试技术不断细分 WEB应用测试 手机软件测试 嵌入式软件测试 安全测试 可靠性测试 1.31.3、软件测试定义、软件测试定义 n 从工作类型看手工测试和用例设计占的比重相当大。 n 在学习中，要避免“重工具不重过程”、“重使用不 重思维”的误区。 n 工具只是为实现某种测试目的的手段，并非掌握的工 具越多越好。 n 只有对软件系统、测试理论越来越深入的理解，才能 更好地把握测试。 p准备工作 n 要测的系统？ n 要做哪方面的测试？ n 基本实现思

8、路？ p开展 n 实现的方式与手段 n 需要的资源（环境、工具、人力） n 文档管理 p收尾 n 撰写报告，收集统计数据，结论 如何开始测试？如何开始测试？ 1.31.3、软件测试定义、软件测试定义 业务 分析 需求 定义 架构 设计 详细 设计 编程和单 元测试 系统 测试 发布/ 部署 开发流程开发流程 测试流程测试流程 需求可测 试性评审 用户沟通 测试分析 和设计 测试策略 缺陷跟踪 功能测试计划、设 计及其评审 非功能测 试计划 测试环境 搭建 部署验证 计划 单元测试 集成测试 测试脚本 开发 测试具体 脚本 测试执行 测试结果 分析 产品质量 评估 测试报告 覆盖软件开发全过程覆

9、盖软件开发全过程 1.31.3、软件测试定义、软件测试定义 p测试&开发的同步关系 1.31.3、软件测试定义、软件测试定义 p软件测试概念的演化软件测试概念的演化 n 1979年，Glenford Myers的软件测试艺术的定义：测试是为测试是为 发现错误发现错误而执行的一个而执行的一个程序程序或者系统的过程或者系统的过程 。 n 1983年，Bill Hetzel在软件测试完全指南中指出：测试是以测试是以 评价评价一个程序或者系统属性为目标的任何一种活动，测试是对软一个程序或者系统属性为目标的任何一种活动，测试是对软 件件质量的度量质量的度量。 n Rick和 Stefan在系统的软件测试

10、一书中对软件测试的定义: 测试是为了度量和测试是为了度量和提高提高被测软件的质量被测软件的质量, ,对测试软件进行工程设对测试软件进行工程设 计、实施和维护的计、实施和维护的整个生命周期过程整个生命周期过程。 1.31.3、软件测试定义、软件测试定义 p1983年IEEE（Institute of Electrical and Electronics Engineers）国际电子电气工程师协 会提出的软件工程标准术语中给软件测试下的定 义是：使用人工或自动手段来运行或测定某个系 统的过程，其目的在于检验它是否满足规定的需 求或是弄清预期结果与实际结果之间的差别。 p我们把软件测试定义为在程序中

11、找出故障的过程 ，使测试成为可以做到的任务，从而克服了心理 上存在的问题。因此，对软件测试人员而言，测 试的最好定义是：软件测试是为了发现错误而执 行程序的过程。 1.31.3、软件测试定义、软件测试定义 p狭义观点 vs. 广义观点 n 狭义观点狭义观点 G.J.Myers所给出了测试定义“程序测试是为了发 现错误而执行程序的过程” 。 瀑布模型 n 广义观点广义观点 将测试延伸到需求评审、设计审查活动中去。 由静态测试和动态测试静态测试和动态测试构成一个全过程的、完整的软件 测试 1.31.3、软件测试定义、软件测试定义 p 辩证观点辩证观点 n验证软件是验证软件是“工作的工作的”，以正向

12、思维，以正向思维，针对软件 系统的所有功能点，逐个验证其正确性。 n证明软件是证明软件是“不工作的不工作的”，以反向思维方式，以反向思维方式， 不断思考开发人员理解的误区、不良的习惯、程序代 码的边界、无效数据的输入以及系统的弱点，试图破 坏系统、摧毁系统，目标就是发现系统中各种各样的 问题。 1.31.3、软件测试定义、软件测试定义 p软件测试的其它观点 n 风险观点风险观点：软件测试是对软件系统中潜在的各种风险进行评估 的活 n 经济学观点经济学观点：一个好的测试用例是在于它能发现至今未发现的 错误 。缺陷发现得越早，所造成得代价就越低，这就是从经济学 的观点来说明测试越早越好。 n 标准

13、观点标准观点：软件测试就是“验证（Verification）”和“有效 性确认（Validation）”活动构成的整体，即软件测试 = V&V 1.31.3、软件测试定义、软件测试定义 n 软件测试=软件调试？ n 。两者并不等价 n 软件调试：开发时发现错误后消除错误的过程 n 软件测试：主要目的是寻找缺陷(不包括修正) n 调试必须由开发人员自己完成，测试则不一定 1.31.3、软件测试定义、软件测试定义 n 找Bug n 判断：软件测试员的工作的主要目的是验证软件是否 能实现要求的功能。 n 错。软件测试员的主要工作是发现bug。 n 无论再充分的实验，也无法验证一个软件的完全正确 性，

14、因此假如让测试员来“验证” 其实是一项无穷尽 的、不可能的工作。 1.31.3、软件测试定义、软件测试定义 n 用户不一定遵守规则，测试员需要知道假如用户不守 规则将可能出现什么后果。否则，将遗漏某些缺陷并 造成严重后果,因此，在测试中需要全面的考虑 1.31.3、软件测试定义、软件测试定义 p计算器的例子 n 计算器说明书：该计算器将准确无误地进行加、减、乘、 除运算。计算器不会出现崩溃、死锁或停止反应。 （1）2+3，没有反应？ （2）随意敲击键盘后，没有了反应？ （3）还能计算某数的平方根 （4）因为电池没有电，所以计算错了 （5）按键很小、显示屏看不清楚 1.41.4、软件测试体系、软

15、件测试体系 1.41.4、软件测试体系、软件测试体系 p质量 缺 陷 指导 软件软件 测试测试 阶 段 管 理 思 想 质 量 用 例 方 法 源泉 确定 寻求 设计 发现 实施 清除 目 标 1.41.4、软件测试体系、软件测试体系 p高质量的软件 应该是相对相对的无产品缺陷无产品缺陷(Bug Free)(Bug Free)或只有极少 量的缺陷、满足客户需求满足客户需求的、是可维护可维护的， 而且它能够准时准时交给用户、其费用是在预算内在预算内的。 但是, 有关质量的好坏最终评价依赖于用户的反 馈。 产品质量 过程质量 1.41.4、软件测试体系、软件测试体系 p软件产品质量的需求 n 功能

16、性需求功能性需求 PRD/MRD, UI Mock-up, Functional Spec 也可称为可说明性 n 非功能性需求非功能性需求 性能、安全性、可用性、兼容性、可靠性、 易用性、可达性（Accessibility）等 1.41.4、软件测试体系、软件测试体系 p测试目标 (质量需求) 缺 陷 指导 软件软件 测试测试 阶 段 管 理 思 想 质 量 用 例 方 法 目 标 源泉 确定 寻求 设计 发现 实施 清除 可靠性测试 可用性测试 兼容性测试 安装测试 恢复测试 安全性测试 性能测试 功能测试 国际化测试 本地化测试 1.41.4、软件测试体系、软件测试体系 p测试方法 缺 陷

17、 指导 软件软件 测试测试 阶 段 管 理 思 想 质 量 用 例 方 法 目 标 源泉 确定 寻求 设计 发现 实施 清除 单因素？单因素？ 多因素？多因素？ 1.41.4、软件测试体系、软件测试体系 p测试用例重点重点 缺陷 指导 软件软件 测试测试 阶段 管理 思想 质量 用例 方法 目标 源泉 确定 寻求 设计 发现 实施 清除 测试执行 测试数据 测试环境 测试套件 测试脚本 测试工具 手工测试 自动化测试 1.41.4、软件测试体系、软件测试体系 p缺陷 缺陷 指导 软件软件 测试测试 阶段 管理 思想 质量 用例 方法 目标 源泉 确定 寻求 设计 发现 实施 清除 缺陷报告 缺

18、陷生命周期 缺陷跟踪 趋势分析 分布分析 缺陷清除率 质量评估 缺陷预防 1.41.4、软件测试体系、软件测试体系 p缺陷 n 软件的Bug，狭义概念是指软件程序的漏洞或缺陷 n 广义概念除此之外还包括测试工程师或用户所发现和 提出的软件可改进的细节、或与需求文档存在差异的 功能实现等。 1.41.4、软件测试体系、软件测试体系 p什么什么是软件缺陷？是软件缺陷？ （1）软件未达到产品说明书中已经标明的功能； （2）软件出现了产品说明书中指明不会出现的错误； （3）软件未达到产品说明书中虽未指出但应当达到的目标； （4）软件功能超出了产品说明书中指明的范围； （5）软件测试人员认为软件难以理解

19、、不易使用，或者最 终用户认为该软件使用效果不良。 1.41.4、软件测试体系、软件测试体系 p测试思想 质量文化 客户需求 质量保证 测试现实 测试原则 测试驱动 成熟度模型 缺 陷 指导 软件软件 测试测试 阶 段 管 理 思 想 质 量 用 例 方 法 目 标 源泉 确定 寻求 设计 发现 实施 清除 1.41.4、软件测试体系、软件测试体系 p测试管理 缺 陷 指导 软件软件 测试测试 阶 段 管 理 思 想 质 量 用 例 方 法 目 标 源泉 确定 寻求 设计 发现 实施 清除 测试策略 测试风险 资源进度 测试计划 实验室 测试团队 测试覆盖 测试报告与模板 1.41.4、软件测

20、试体系、软件测试体系 p测试阶段 缺 陷 指导 软件软件 测试测试 阶 段 管 理 思 想 质 量 用 例 方 法 目 标 源泉 确定 寻求 设计 发现 实施 清除 需求审查 设计审查 单元测试 集成测试 系统测试 验收测试 /测试 回归测试 冒烟测试 1.41.4、软件测试体系、软件测试体系 p软件测试全过程 (1) 1.41.4、软件测试体系、软件测试体系 p软件测试全过程 (2) 1.41.4、软件测试、软件测试体系体系- - 1.41.4、软件测试、软件测试体系体系 效统提升 职业化 统一基础 测试项目是核心，质 量标准、测试流程、 测试技术都是为测试 项目提供支撑和服务 的 1.41

21、.4、软件测试体系、软件测试体系 p软件测试工具体系 1.41.4、软件测试体系、软件测试体系 p测试管理工具： n TD、QC、Rational系列 p性能测试工具： n loadRunner、JMeter p功能自动化测试工具： n QTP、Robot p缺陷管理工具： n TD、QC、Mantis 1.41.4、软件测试体系、软件测试体系 p软件测试方法论体系 1.51.5、软件测试的基础理论、软件测试的基础理论 n 测试的目的就是发现软件中的各种缺陷 n 测试只能证明软件存在缺陷，不能证明软件不存在缺 陷 n 测试可以使软件中缺陷降低到一定程度，而不是彻底 消灭 n 以较少的用例、时间

22、和人力找出软件中的各种错误和 缺陷，以确保软件的质量 1.51.5、软件测试的基础理论、软件测试的基础理论 p测试的目标 n 最终目的是确保软件的功能符合用户的需求，把尽可 能多的问题在发布或交付前发现并改正： - 确保软件完成了它所承诺或公布的功能 - 确保软件满足性能的要求 - 确保软件是健壮的和适应用户环境的 1.51.5、软件测试的基础理论、软件测试的基础理论 p测试的目标 n 为软件的质量评估提供依据 n 为软件质量改进和管理提供帮助 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的对象 n 软件测试应贯穿于软件定义和开发的整个期间 需求分析、概要设计、详细设计以及

23、程序编码 等各阶段所得到的文档，包括需求规格说明、概要 设计规格说明、详细设计规格说明以及源程序，都 应做为软件测试的对象 1.51.5、软件测试的基础理论、软件测试的基础理论 1.51.5、软件测试的基础理论、软件测试的基础理论 n 软件的Bug，狭义概念是指软件程序的漏洞或缺陷 n 广义概念除此之外还包括测试工程师或用户所发现和 提出的软件可改进的细节、或与需求文档存在差异的 功能实现等。 1.51.5、软件测试的基础理论、软件测试的基础理论 n 从产品内部看，缺陷是软件产品开发或维护过程中存 在的错误、毛病等各种问题；从产品外部看，缺陷是 系统所需要实现的某种功能的失效或违背。 l 表现

24、： n 1、软件没有实现产品规格说明所要求的功能模块 n 2、软件中出现了产品规格说明指明不应该出现的错误 n 3、软件实现了产品规格说明没有提到的功能模块 n 4、软件没有实现虽然产品规格说明没有明确提及但应 该实现的目标； n 5、软件难以理解，不容易使用，运行缓慢，或从测试 员的角度看，最终用户会认为不好。 1.51.5、软件测试的基础理论、软件测试的基础理论 n Bug（统称） n Defect（瑕疵，缺点，可能不明显的bug） n Fault（故障，相对稍严重一些的bug） n Failure（必然导致运行失败的bug，较严重） 缺陷不一定会产生运行失败缺陷不一定会产生运行失败 1.

25、51.5、软件测试的基础理论、软件测试的基础理论 p软件缺陷产生的原因 图1 软件缺陷产生的原因分布 其他其他 10% 软件产品说明软件产品说明 书（需求）书（需求） 56% 编写代码编写代码 7% 设计设计 27% 1.51.5、软件测试的基础理论、软件测试的基础理论 软件本身 团队工作 技术问题 项目管理的问题 l1.需求说明差需求说明差 l1.不切实际的时间表不切实际的时间表 l3.测试不充分测试不充分 l4.不断增加功能不断增加功能 l5.交流问题交流问题 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件缺陷产生的原因软件缺陷产生的原因 n 使需求分析变得困难的几种原因：

26、（1）客户说不清楚需求； （2）需求自身经常变动； （3）分析人员或客户理解有误。 n 如何改善？ 进退两难进退两难一个项目经理的日记一个项目经理的日记 1.51.5、软件测试的基础理论、软件测试的基础理论 1.51.5、软件测试的基础理论、软件测试的基础理论 n 软件在从需求、设计、编码、测试一直到交付用户公 开使用后的过程中，都有可能产生和发现缺陷。随着 整个开发过程的时间推移，更正缺陷或修复问题的费 用呈几何级数增长。 0 0 2020 4040 6060 8080 100100 编制说明书编制说明书设计阶段设计阶段编写代码编写代码测试测试发布发布 图2 软件缺陷在不同阶段发现时修复的费

27、用示意图 1.51.5、软件测试的基础理论、软件测试的基础理论 $1 $10 $100 designcoderelease $1000+ specification 1.51.5、软件测试的基础理论、软件测试的基础理论 修复成本修复成本 l问题发现的越早越好 1.51.5、软件测试的基础理论、软件测试的基础理论 p练习： 假如手头上没有任何需求、设计文档和源代码，只拿到一 个程序假如是windows自带计算器程序。请思考：针 对下图计算器的功能，如何进行测试？并思考以下几个 问题： 是否需要测试所有可能的运算？ 是否需要测试每一个运算符的运算？ 是否需要测试每一个按键？ 是否需要测试哪些特定的

28、组合？ Any others? 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 p 1 1、保证测试的覆盖程度，但穷保证测试的覆盖程度，但穷 举测试是不可能的举测试是不可能的 n 例例: : 测试测试windowswindows计算机器计算机器 p 原因：原因： n 输入量太大输入量太大 n 输出结果太多输出结果太多 n 软件执行路径太多软件执行路径太多 n 软件说明书是主观的，没有客观软件说明书是主观的，没有客观 标准。标准。 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 n 2、软件测试是有风险的活动 Software Testing is

29、 a Risk-Based Exercise 如果不选择完全测试所有情况，那就是选择了冒险 Not to test every possible test scenario, Customer will eventually find it someday. 如：1024+1024=2048 矛盾： Testing vs. Release deadline Stop testing vs. Costly bug 关键测试要点： 把数量巨大的可能测试减少到可以控制的范围 针对风险做出明智的选择，哪些测试重要，哪些不重要 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 n

30、3、测试无法显示潜伏的软件缺陷和故障 软件测试员可以报告软件缺陷存在,却不能报告软件 缺陷不存在. 可以进行测试,发现并报告软件缺陷,但是任何情况 下都不能保证软件缺陷不存在. What can you do?! 唯一的方法: 继续测试,找到更多的缺陷 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 n 4. 充分注意测试中的群集现象 缺陷可能成群出现 发现一个,附近就可能有一群 缺陷一个接一个 可能的原因: A.程序员也有心情不好的时候 B.程序员往往犯同样的错误 C.有些软件故障可能是冰山一角 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则

31、n 5 5、测试的杀虫剂现象、测试的杀虫剂现象 用于描述测试人员对同一测试对象进行的测试次数 越多，发现的缺陷就会越来越少的现象。就像老用 一种农药，害虫就会有免疫力，农药发挥不了效力 。这种现象的根本原因就是测试人员对测试软件过 于熟悉，形成思维定势。 1.51.5、软件测试的基础理论、软件测试的基础理论 p如何规避和解决杀虫剂现象：如何规避和解决杀虫剂现象： n 1、重新分析测试需求 ：重新对需求文档进行分析， 找出不同的业务逻辑。尤其是组合条件较复杂的逻辑 和业务工作流。 n 2、拓展测试用例 ：根据新制定的测试需求，必须重 新设计测试用例来进行检验。 n 3、改变测试方法，加入更多的场

32、景 ：很多问题是在 长时间操作，反复进行业务交互后才产生的。 1.51.5、软件测试的基础理论、软件测试的基础理论 p如何规避和解决杀虫剂现象：如何规避和解决杀虫剂现象： n 4、在模块功能稳定的情况下，适当补充非功能性测试， 在易用性、可靠性、稳定性等质量指标下，系统容易 暴露更多的状况，很多是用例未考虑的情况。 n 5、缺陷问题整理和归纳 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 n 6.并非所有的软件缺陷都要修复 虽然测试员尽了最大的努力，但并非找到的所有软 件缺陷都要修复。 并非意味着软件测试员没有达到目的. 解决办法 依赖软件测试员的素质进行良好的判断，

33、根据风险决定 哪些缺陷需要修复，哪些不需要修复。 造成软件缺陷不能修复的原因： （1）时间不够 （2）不算真正的软件缺陷 （3）修复的风险太大 （4）不值得修复 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 n 7 7、木桶原理：、木桶原理： 软件质量的关键因素是分析、设计和实现，测试应 该是融于其中的补充检查手段，其他管理、支持、 甚至 文化因素也会影响最终软件的质量 测试是提高软件质量的必要条件，最直接、最快捷 的手段，但决不是一种根本手段。反过来说，如果 将提高产品质量的砝码全部押在测试上，那将是一 个恐怖而漫长的灾难。 1.51.5、软件测试的基础理论、软件测

34、试的基础理论 p软件测试的原则 n 8、Bug的80-20原则 在分析、设计、实现阶段的复审和测试工作能够发 现和避免80%的Bug 而系统测试又能找出其余Bug中的80% 最后的5%的Bug可能只有在用户的大范围、长时间 使用后才会曝露出来 80%的Bug集中在20%功能模块上 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 n 9 9.软件测试必须有预期结果 软件缺陷是经过对比而得出来的。没有预期结果的 测试是绝不可以的。我们事先不知道或是无法肯定 预期的结果，我们必然无法了解测试正确性。 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 n

35、10. 应当把“尽早地和不断地进行软件测试”作为软 件测试者的座右铭（想想虫卵、小虫、大虫） 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 n 11. 程序员应该避免检查自己的程序。 Why? 程序员从来不会承认自己写的程序有错误 程序员的测试思路有明显的局限性 多数程序员没有经过严格正规的职业训练，常忽视 测试 程序员无良好的BUG跟踪和回归测试的习惯 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的原则 n 12 追溯至用户需求 n 13 及时更新测试 1.51.5、软件测试的基础理论、软件测试的基础理论 软件测试按照不同的划分方法，有不同的分类

36、： n 按照软件测试用例的设计方法而论，软件测试可以分 为白盒测试法、黑盒测试法和灰盒测试法。 n 按照软件测试的策略和过程来分类，软件测试可分为 单元测试、集成测试、系统测试、验证测试和确认测 试。 1.51.5、软件测试的基础理论、软件测试的基础理论 单元测试集成测试 系统测试（确认测试、回归测 试、验收测试） o单元测试最低级别的测试，测试对象是软件的一个独立模块(通 常是一个函数) 。 o集成测试 测试若干个单元组合在一起后是否能够按既定意图协 作运行 o确认测试检验软件是否能按用户要求工作。 o回归测试对被测过的程序在修改缺陷后进行的重复测试，以发 现是否引入新的缺陷 o验收测试确定

37、产品是否能够满足合同或用户所规定需求，让系 统用户决定是否接受 1.51.5、软件测试的基础理论、软件测试的基础理论 n 功能测试系统能干什么。主要考虑软件的外部表 现。 n 包括逻辑功能测试、界面测试、安全性测试、互操作 性测试等 n 性能测试系统工作的怎样。包括并发测试、稳定 测试、负载测试、压力测试等。 n 其他非功能测试：易用性测试、可移植性测试、可维 护性测试、兼容性测试等 1.51.5、软件测试的基础理论、软件测试的基础理论 n (Alpha)测试一个用户在开发环境下进行的测试 。也可以由开发机构内部的用户在模拟实际操作环境 下进行。通常在开发现场进行，是受控制的环境下进 行的测试

38、。开发者在测试现场，随时记录错误情况和 使用中的问题。 n (Beta)测试多个用户在实际使用环境下进行的测 试。开发者不在测试现场，是在开发者无法控制的环 境下进行的现场、实时、随机的应用。 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的分类软件测试的分类 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试的周期性软件测试的周期性 软件测试的周期性是“测试-改错-再测试-再改错” 这样一个循环过程，如下图1-3所示。 测试周期测试周期 开发开发/ 改错改错 改错改错测试周期测试周期改错改错 串行方式串行方式 开发者开发者： . 开发者：开发者： 并行方式并行

39、方式 测试者：测试者： 开发开发/ 改错改错开发开发/ 改错改错 最终回归测试最终回归测试回归测试回归测试1测试周期测试周期1 功能冻结功能冻结代码冻结代码冻结 测试周期测试周期2 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试关键问题 n （1）测试由谁来执行？（Who） 通常软件产品的开发设计包括开发者和测试者两种 角色。开发者：通过开发形成产品，如分析、设计 、编码调试或文档编制等。测试者通过测试来检测 产品中是否存在缺陷，包括根据特定目的而设计测 试用例、构造测试、执行测试和评价测试结果等。 通常由开发者负责完成第一阶段的代码单元测试， 而系统测试则由独立的测试人员或

40、专门的测试机构 进行。 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试关键问题 n （2）测试什么？ 软件产品的组成： 软件产品到底是什么？并不仅仅是从软盘或者光盘安装到 计算机上的程序，还包括许多隐含的内容，容易被忽视， 但这些也往往是包含软件缺陷的测试对象，需要软件测试 员铭记在心！ 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试关键问题 n 软件测试对象：软件测试不仅仅是对程序的测试，而 是贯穿于软件定义和开发的整个过程。因此，软件开 发过程中产生的需求分析、概要设计、详细设计以及 编码等各个阶段所得到的文档，包括需求规格说明、 概要设计说明、详细设计

41、规格说明以及源程序，都是 软件测试的对象。 n 软件测试在软件生命周期，也就是从开发设计、运行 、直到结束使用的全过程中，主要横跨以下两个测试 阶段： 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试关键问题 n 第一阶段：单元测试阶段，即在每个模块编写出以后 所做的必要测试。 n 第二阶段：综合测试阶段，即在完成单元测试后进行 的测试，如集成测试、系统测试、验收测试等。 n 研究表明，通常表现在程序中的故障，并不一定是由 编码所引起的，可能是需求分析，概要设计、详细设 计等阶段的问题所致，要排除故障就必须追溯到前期 的工作（这就涉及到下一个问题什么时候进行测 试） 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试关键问题 n （3）什么时候进行测试。 测试可以是一个与开发并行的过程，也可以是开发 完成某个阶段任务后的的活动，即模块开发结束之 后，还可以在各模块装配成为一个完整的程序之后 再进行测试。 1.51.5、软件测试的基础理论、软件测试的基础理论 p软件测试关键问题 n （4）怎样进行测试。 对软件进行测试就是根据软件的功能规范说明和程 序实现，利用各种测试方法，生成有效的测试用例