前两部分 1~7章

• (第一部分 软件测试综述)
• 第 1 章 软件测试的背景
• • 1.1 臭名昭著的软件错误用例研究
  • 1.2 软件缺陷是什么
  • 1.3 为什么会出现软件缺陷
  • 1.4 软件缺陷的修复费用
  • 1.5 软件测试员究竟做些什么
  • 1.6 软件测试员应具备的素质
• 第 2 章 软件开发的过程
• • 2.1 产品的组成部分
  • 2.2 软件项目成员
  • 2.3 软件开发生命周期模式
• 第 3 章 软件测试的实质
• • 3.1 测试的原则
  • 3.2 软件测试的主语和定义
• (第二部分 测试基础)
• 第 4 章 检查产品说明书（静态黑盒测试）
• • 4.1 开始测试
  • • 4.1.1 黑盒测试和白盒测试
    • 4.1.2 静态测试和动态测试
    • 4.1.3 静态黑盒测试、测试产品说明书
  • 4.2 对产品说明书进行高级审查
  • 4.3 产品说明书的低层次测试技术
  • • 4.3.1 产品说明书属性检查清单
    • 4.3.2 产品说明书术语检查清单
• 第 5 章 戴上眼罩测试软件（动态黑盒测试 / 行为测试）
• • 5.1 动态黑盒测试：戴上眼罩测试软件
  • 5.2 通过性测试和失效性测试
  • 5.3 等价类划分
  • 5.4 数据测试
  • 5.5 状态测试
  • 5.6 其他黑盒测试技术
• 第 6 章 检查代码（静态白盒测试 / 结构化分析）
• • 6.1 静态白盒测试：检查设计和代码
  • 6.2 正式审查
  • • 6.2.1 同事审查 / 伙伴审查
    • 6.2.2 走查
    • 6.2.3 检验
  • 6.3 编码标准和规范
  • 6.4 通用代码审查清单
• 第 7 章 带上 X 光眼镜测试软件（动态白盒测试 / 结构化测试）
• • 7.1 动态白盒测试
  • 7.2 动态白盒测试和调试
  • 7.3 分段测试
  • • 7.3.1 单元测试和集成测试
    • 7.3.2 单元测试示例
  • 7.4 数据覆盖
  • 7.5 代码覆盖

(第一部分 软件测试综述)

第 1 章 软件测试的背景

本章重点：
（1）软件缺陷如何影响我们的生活
（2）软件缺陷是什么，为什么会出现
（3）软件测试员是谁，他们在做什么

1.1 臭名昭著的软件错误用例研究

1.2 软件缺陷是什么

• 软件失败的术语
  缺点、故障、失败、异常、事件、偏差、问题、错误、缺陷、矛盾、特殊等。描述软件缺陷的术语很多，完全取决于公司的文化和开发软件的过程。在用词上过多计较是没有意义的。
  本书中，所有软件问题都称为 缺陷（bug）。
• 软件缺陷 的官方定义
  产品说明书：又称说明或产品说明，是软件开发小组的一个协定。它对开发的产品进行定义，给出了 产品的细节、如何做、做什么、不能做什么。（详见第 2 章）
  至少满足下列 5 个规则之一才称发生了一个 软件缺陷（software bug）：
  （1）软件未实现产品规格说明书要求的功能
  （2）软件出现了产品规格说明书指明不应该出现的错误
  （3）软件实现了产品规格说明书未提到的功能
  （4）软件未实现产品规格说明书虽未明确提及但应该实现的目标
  （5）软件难以理解、不易使用、运行缓慢、或者（从测试员的角度看）最终用户会认为不好
  注： 第（4）条，其目的是为了捕获产品说明书上的遗漏之处。第（5）条，并非所有测试发现的缺陷都要修改，要全面，最重要的是要客观。

1.3 为什么会出现软件缺陷

从开始到计划、编程、测试，到公开使用的过程中，都有可能发现软件缺陷。修复软件缺陷的费用呈 指数级 地增长（即，随着时间的推移，费用呈 十倍 地增长）

1.5 软件测试员究竟做些什么

软件测试员的目标： 尽可能早地找出缺陷，并确保其得以修复

1.6 软件测试员应具备的素质

（1）喜欢探索，喜欢拿到一个新的软件安装在自己的机器上，观看结果
（2）故障排除员，善于发现问题的症结，喜欢解谜
（3）不放过任何蛛丝马迹，喜欢不停地尝试，去发现软件缺陷
（4）具有创造性，创造新的手段来发现缺陷
（5）追求完美，但当知道某些无法企及时，不去苛求，而是尽力接近
（6）判断准确，要决定测试内容、测试时间，以及看到的问题是否是真的缺陷
（7）注重策略和外交
（8）善于说服

第 2 章 软件开发的过程

本章重点：
（1）软件产品构成的主要部分
（2）软件产品中包含哪些人的劳动和技术
（3）软件从构想到最终产品的过程

2.1 产品的组成部分

• 软件产品需要多少投入
  

2.2 软件项目成员

• 项目经理、程序经理 或者 监制人员：自始至终驱动整个项目，负责编写产品说明书、管理制度、进行重大决策
• 体系架构师 或者 系统工程师：产品小组中的技术专家，设计整个系统的体系架构或软件
• 程序员、开发人员 或者 代码制作者：设计、编写并修复软件中的缺陷。与项目经理和设计师密切合作制作软件，与项目经理和测试人员密切合作修复缺陷
• 测试员 或 质量保证员：找出并报告产品的问题。与开发小组全部成员在开发过程中密切合作
• 技术作者、用户协助专员、用户培训专员、手册编写员 或者 文案专员：编制软件产品附带的文件和联机文档
• 配置管理员 或 构建员：把程序员编写的代码及技术作者写的全部文档资料组合在一起，合成为一个软件包

2.3 软件开发生命周期模式

软件产生从最初构思到公开发行的过程称为 软件开发生命周期模式 ：
（1）大爆炸模式

最初只有粗略的想法，接着进行一些简单的设计，然后开始漫长的 来回编写、测试、修改缺陷 的过程。
（3）瀑布模式

一开始不必详细定义所有的细节，先定义重要功能，努力实现这些功能，接收客户反馈，然后进入下一阶段。
每一阶段包括 6 个步骤：
（1）确定目标、可选方案和限制条件
（2）明确并化解风险
（3）评估可选方案
（4）当前阶段开发和测试
（5）计划下一阶段
（6）确定进入下一阶段的方法

软件测试员喜欢这个模式，因为他们很早就参与开发过程，有机会尽早发现问题，为项目节省时间和金钱。

第 3 章 软件测试的实质

本章重点：
（1）软件为什么永远不会完美
（2）软件测试为什么不仅仅是技术问题
（3）软件测试员的常用术语

3.1 测试的原则

• 1. 完全测试程序是不可能的
  主要原因：
  （1）输入量太大。
  （2）输出结果太多。
  （3）软件执行路径太多。
  （4）软件说明书是主观的，从旁观者角度来看是缺陷。

• 2. 软件测试是有风险的行为
  如果不测试所有的情况，就是选择了冒险。测试量和发现的软件缺陷数量之间的关系：
  

  
  软件测试要精度还是准度很大程度上取决于 产品是什么，最终取决于 开发小组的目标。
• 2. 确认和验证
  确认：保证软件符合产品说明书的过程
  验证：保证软件满足客户要求的过程
• 3. 质量和可靠性
  可靠性仅仅是质量的一个方面。
  软件产品质量高就是指它能够满足客户要求，客户感到该产品性能卓越，优于其他产品。
  为了确保程序质量高而且可靠性强，软件测试员必须在整个产品开发过程中进行确认和验证。
• 4. 测试和质量保证
  软件测试员的目标：尽可能早地找出软件缺陷，并确保缺陷的已修复
  软件质量保证人员：创建和执行 改进软件开发过程并防止软件缺陷发生的 标准和方法
  双方的工作是交叉的。

(第二部分 测试基础)

第 4 章 检查产品说明书（静态黑盒测试）

本章重点：
（1）什么是黑盒测试和白盒测试
（2）静态测试和动态测试有何区别
（3）审查产品说明书有哪些高级技术
（4）在详细审查产品说明书时应注意哪些特殊问题

4.1 开始测试

确保最终产品符合客户要求 以及 正确计划测试投入 的唯一方法是 在产品说明书中完整描述产品。
编写详细产品说明书的另一好处：软件测试员可以将其作为测试项目的书面材料，据此可以在编写代码之前找出软件缺陷。

4.1.1 黑盒测试和白盒测试

黑盒测试（功能测试、行为测试）	白盒测试
只需知道软件要做什么，无法知道软件是如何运行的	可以访问程序员的代码，并通过检查代码来协助测试

4.1.2 静态测试和动态测试

静态测试	动态测试
只是检查和审核	使用和运行软件

4.1.3 静态黑盒测试、测试产品说明书

测试产品说明书属于静态黑盒测试，因为：
（1）产品说明书是书面文档，而不是可执行程序，因此是静态的；
（2）产品说明书是利用各种资源获得的数据，不必了解怎样和为什么要获取这些信息，以及获取这些信息的途径，只需要知道它们最终构成产品说明书就可以了，因此是黑盒。

4.2 对产品说明书进行高级审查

测试产品说明书的第一步：站在一个高度上进行审查

1. 假设自己是客户
   （1）了解客户所想（牢记，质量的定义是 “满足客户要求” ），但同时不要忘记软件安全性问题，因为客户可能会假设软件是安全的，但软件测试员不能这样。
   （2）假设什么知识也没有。要搞懂产品说明书的任何细节。
2. 研究现有的标准和规范
   标准比规范更加严格。标准必须严格遵守，规范可选。
   项目经理 ：定义软件要符合何种标准和规范
   软件测试员：观察、检查采用的标准是否正确、有无遗漏；在对产品进行确认和验收时，还要注意是否与标准和规范相抵触，把标准和规范视为产品说明书的一部分。
3. 审查和测试类似软件
   类似软件有助于设计测试条件和测试方法，还可能暴露意想不到的潜在问题。

4.3 产品说明书的低层次测试技术

4.3.1 产品说明书属性检查清单

（1）完整
（2）准确
（3）精确、不含糊、清晰
（4）一致
（5）贴切
（6）合理
（7）代码无关
（8）可测试性

4.3.2 产品说明书术语检查清单

（2）测试边界
从等价划分中选择测试数据时，从边界条件中选择，往往会找出更多的软件缺陷。
注意：要测试临近边界的有效数据，同时测试刚超过边界的无效数据。（越界测试）

状态转换图应包含：
（1）软件可能进入的每一种独立状态。不确定的也可以视为独立状态，若之后发现不是，随时可以剔除。
（2）从一种状态进入另一种状态所需的输入和条件。
（3）进入或者推出某种状态时的设置条件及输出结果。包括显示的菜单按钮、设置的标志位、产生的打印输出、执行的运算等。
（2）减少要测试的状态及转换的数量
将大量的可能性减少到可以操作的测试用例集合，有以下 5 种实现方法：
（1）每种状态至少访问一次。
（2）测试看起来最常见和最普遍的状态转换。
（3）测试状态之间最不常用的分支。（容易被忽略）
（4）测试所有错误状态及其返回值。
（5）测试随机状态转换。（见第 15 章，自动测试和测试工具）
（3）怎样进行具体的测试
确定要测试的 状态 及其 转换 之后，就可以定义 测试用例 了。
测试 状态 及其 转换 包括检查所有的 状态变量——与进入和退出状态相关的静态条件、信息、值、功能等。

失败状态测试
（1）竞争条件和时序错乱
指的是几个事件恰巧挤在一起，由于软件未预料到运行过程会被中断，以致造成混乱。也就是说，时序发生错乱。

都包括处理软件缺陷和查看代码，但 目标 不同。
动态测试的目标： 寻找软件测试
调试的目标： 修复缺陷
但他们在隔离软件缺陷的位置和原因上有交叉。

7.3 分段测试

7.3.1 单元测试和集成测试

代码分段构建和测试，最后合并在一起形成更大的部分，形成产品。

（1）首先确定此模块属于程序中的底层模块，可以由其他模块调用，但自己不能调用其他模块。所以需要编写一个驱动模块
（2）分析说明书，确定应该采用黑盒测试用例
（3）运用等价类划分法减少测试用例集合
（4）研究代码看函数是如何实现的，利用白盒测试知识增减测试用例，其实是根据程序内部的信息对等价类划分的进一步提炼

7.4 数据覆盖

查看代码决定如何调整测试用例合理的方法是，把软件分成数据和状态（或程序流程）。
**数据：**包括变量、常量、数组、数据结构、键盘和鼠标的输入、文件、屏幕输入输出，以及调制解调器、网络等设备的输入输出。

• 数据流
  数据流覆盖：是指在软件中完全跟踪一批数据
  黑盒测试只能知道变量开始和结束时候的值，动态白盒测试可以在程序运行期间检查变量的中间值，进而更改测试用例，保证变量取得感兴趣的、甚至具有风险的值。
• 次边界
  进行白盒测试需要仔细检查代码找到次边界条件，并建立能测试它们的测试用例。
• 公式和等式
  撇开代码中的公式和等式，查看它们使用的变量，在程序中正常输入和输出之外，为其建立测试用例和等价类划分。
• 错误强制
  懂

7.5 代码覆盖

测试程序的状态以及程序流程。代码覆盖是设法进入和退出每一个模块，执行每一行代码，进入软件每一条逻辑呵呵决策分支。
对于小程序或单独模块，可以利用编译环境的调试器通过单步执行程序查看代码。
但对大多数程序进行代码覆盖要用到代码覆盖分析器。利用代码覆盖分析器可以得到：
（1）测试用例没有覆盖软件的哪些部分
（2）那些测试用例是多余的
（3）为了使覆盖率更好，需要建立什么样的新测试用例
（4）还可以得到软件质量的大致情况。

• 语句覆盖/代码行覆盖
  保证程序中每一条语句最少执行一次。
  但是，即使全部语句都被执行了，不能说明走遍了软件的所有路径
• 分支覆盖/路径覆盖
  试图覆盖软件中的所有路径。
  大多数代码覆盖率分析器将根据代码分支，分别报告语句覆盖和分支覆盖的结果，使软件测试员更加清楚测试结果
• 条件覆盖
  将分支语句的条件考虑在内。
  代码覆盖率分析器可以被设置为将条件考虑在内。如果测试条件覆盖，就能达到分支覆盖，顺便也能达到语句覆盖

来源：果果是女生

声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！