软件测试的艺术

1、 所谓软件测试，就是一个过程或一系列过程用来确认计 算机代码完成了其应该完成的功能不执行其不该有的操作。 软件应当是可预测且稳定的，不会给用户带来意外惊奇。 作者眼中的测试： 2.1 软件测试的心理学软件测试的心理学 测试执行得差，其中一个主要原因在于大多数的程序员一开始就测试 这个术语的定义搞错了，他们可能会认为： 1.软件测试就是证明软件不存在错误的过程。 2.软件测试的目的在于证明软件能够正确完成其预定的功能。 3.软件测试就是建立一个软件做了其应该做的信心的过程。 那么，对于测试，更为合适的定义应该是：测试是为发现错误而执行 程序的过程 2.2 软件测试的经济学软件测试的经济学 2.2

2、.1 黑盒测试 黑盒测试：又被称为功能测试、数据驱动测试或基于规格说明的测试， 是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检 查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设 计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件 怎样工作。 2.2.2 白盒测试 白盒测试：是通过程序的源代码进行测试而不使用用户界面这种类型 的测试，需要从代码语法发现内部代码在，算法，溢出，路径，条件 等等中的缺点或者错误，进而加以修正。 2.3 软件测试的原则软件测试的原则 原则l： 测试用例中一个必需部分是对预期输出或结果的定义。 原则2： 程序员应当避免测试自己编写的

3、程序 原则3： 编写软件的组织不应当测试自己编写的软件 原则4： 应当彻底检查每个测试的执行结果。 原则5： 测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当 根据无效和未预料到的输入情况。 原则6： 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半 是检查程序是否“做了其不应该做的”。 原则7： 应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。 原则8： 计划测试工作时不应默许假定不会发现错误。 原则9： 程序某部分存在更多错误的可能性，与该部分已发现错误的数目成 正比。 原则10 软件测试是一项极富创造性、极具智力挑战性的工作。 3.1 代码检查代码检查 一个

4、代码检查小组通常由四人组成，其中一人发挥着协调作用。协调 人应该是个称职的程序员，但不是该程序的编码人员，不需要对程序 的细节了解得很清楚。 协调人的职责包括以下几点： 1.为代码检查分发材料、安排进程。 2.在代码检查中起主导作用。 3.记录发现的所有错误。 4.确保所有错误随后得到改正。 3.2 用于代码检查的错误列表用于代码检查的错误列表 3.2.1 数据引用错误 3.2.2 数据声明错误 3.2.3 运算错误 3.2.4 比较错误 3.2.5 控制流程错误 3.2.6 接口错误 3.2.7 输入/输出错误 3.2.8 其他检查 3.3 代码走查代码走查 代码走查也是采用持续一至两个小时

5、的小间断会议的形式。代码走查 小组由三至五人组成，其中一个人扮演类似代码检查过程中“协调人” 的角色，一个人担任秘书（负责记录所有查出的错误）的角色，还有 一个人担任测试人员。关于这二到五个人的组成结构，有各种各样的 建议。当然，程序员应该是其中之一。我们建议另外的参与者应该包 括：(1)一位极富经验的程序员；(2)一位程序设计语言专家；(3)一位 程序员新手（可以给出新颖，不带偏见的观点），(4)最终将维护程序 的人员；(5)一位来自其他不同项目的人员；(6)一位来自该软件编程小 组的程序员。 4.1黑盒测试黑盒测试 等价类划分 边界值分析 判定表分析 错误测试 4.2白盒测试白盒测试 语句

6、覆盖 判定覆盖 条件覆盖 判定/条件覆盖 多重条件覆盖 等价类划分等价类划分： 等价类的定义：等价类的定义：等价类是指某个输入域的子集合，在该子集合中，各 个输入数据对于揭露软件中的错误都是等效的。 等价类的划分：等价类的划分：有效等价类、无效等价类 等价类如何划分？等价类如何划分？ 1.如果确定了取值范围，可以划分1个有效，2个无效 2.如果规定了必须如何的情况下，可以划分为1个有效，1个无效 3.如果是布尔量，可以划分为1个有效，1个无效。特殊情况下，可以 划分为2个有效 4.如果确定了取值范围假定N个并且程序要对每一个输入值分别处理 的情况下，可以确定n个 有效等价类和1个无效等价 5.

7、在规定了输入数据必须遵守的规定的情况下，可以确定一个有效 等价类符合规则和若干个无效等价类（从不同的角度违反规则） 6.划分等价类可以先粗分，再细分 等价类覆盖法设计测试用例的步骤： 1.进行等价类划分（等价类划分是所有测试用例设计方法的基础） 2.进行用例覆盖 2.1 设计一个测试用例让其尽可能多的覆盖有效等价类，循环直到所有的 有效等价类全部达到覆盖 2.2 设计一个测试用例让其仅覆盖一个无效等价类，循环直到所有的无效 等价类全部达到覆盖 3.确定测试数据，完成测试用例 边界值的定义边界值的定义：有效等价类边界点以及超出有效等价类边界的点 边值点的定义边值点的定义： 上点：边界上的点，如果

8、域的边界是封闭的，上点就在域范围内； 如果域的边界是开放的，上点就在域范围外 离点：就是离上点最近的点，如果域的边界是封闭的，离点在域 的范围外,如果域的边界点是开放的,离点就在域的范围内 内点：就是在范围内的任意一点 判定表的定义：判定表的定义：判定表是分析和表达多种输入条件下系统执行不同动作 的工具 判定表的四个组成部分：判定表的四个组成部分： 条件装：列出了系统的所有输入，列出的输入次序无光紧要 （输入项） 动作装：列出了系统可能采取的操作，这些操作的排列顺序没有约束 （输出项） 条件项：列出针对它左列输入的取值，在所有可能情况下的真假值 （输入项的取值组合） 动作项：列出在输入项的各种

9、取值情况下应该采取的动作 （每组条件的预期输出） 判定表设计用例的步骤：判定表设计用例的步骤： 1.确定条件桩（输入项）和动作桩（输出项） 2.构建判定表（条件项1的取值*条件项2的取值*条件项3的取值） 3.填写动作项 4.对判定表进行合并/化简 合并的原则：动作桩完全相同，条件项只有一个不相同，可以考虑合 并合并有风险，因为减少了用例，破坏了原有的规则。所以一般来说 条件项小于8个，不建议合并。 5.去除无效的组合 错误猜测：错误猜测：在软件测试中,人们可以靠经验和直觉推测系统中可能存在 的各种错误,从而有针对性地编写检查这些错误的例子 步骤：步骤： 1.确定合适的错误猜测 2.确定需要进

10、行错误猜测的测试子项 3.根据checkList检查对应测试子项的规格进行错误猜测 软件测试的原则：软件测试的原则： 原则l：测试用例中一个必需部分是对预期输出或结果的定义。 原则2：程序员应当避免测试自己编写的程序 原则3：编写软件的组织不应当测试自己编写的软件 原则4：应当彻底检查每个测试的执行结果。 原则5：测试用例的编写不仅应当根据有效和预期的输入情况，而且也 应当根据无效和未预料到的输入情况。 原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另 一半是检查程序是否“做了其不应该做的”。 原则7：应避免测试用例用后即弃,除非软件本身就是一个一次性的软件 原则8：计划测试工作

11、时不应默许假定不会发现错误。 原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数目 成正比。 原则10 软件测试是一项极富创造性、极具智力挑战性的工作。 6.1 功能测试 6.2 系统测试 6.3 验收测试 6.4 安装测试 6.5 测试的计划与控制 6.6 测试的结束准则 6.7 独立的测试机构 功能测试功能测试 功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。 外部规格说明是一份从最终用户的角度对程序行为的精确描述。 系统测试系统测试 系统测试最容易被错误理解，也是最困难的测试过程。系统测 试并非是测试整个系统或程序功能的过程，因为有了功能测试， 这样会显得多余

12、。系统测试有着特定的目的：将系统或程序与 其初始目标进行比较。给定这个目标之后，隐含两方面的含义： 1. 系统测试并不局限于系统。如果产品是一个程序，那么系统 测试就是一个试图说明程序作为一个整体是如何不满足其目标 的过程。 2. 根据定义，如果产品没有一组书面的、可度量的目标，系统 测试也就无法进行。 系统测试系统测试 能力测试 容量测试 强度测试 易用性测试 安全性测试 性能测试 存储测试 配置测试 兼容性/配置/转换测试 安装测试 可靠性测试 可恢复性测试 适用性测试 文档测试 过程测试 系统测试的执行 验收测试验收测试 验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的 过程

13、。这是一种不寻常的测试类型，因为该测试通常是由程序的客户 或最终用户来进行，一般不认为是软件开发构的职责。对于软件按合 同开发的情况，由订购方（用户）来进行验收测试，将程序的实际操 作与原始合同进行对照。 安装测试安装测试 安装测试有些不寻常，它与所有其他测试过程不同。与设计过程中 的任何阶段都没有联系。它的不寻常是由于其目的不是为了发现软件 中的错误，而是为了发现在安装过程中出现的错误。 测试的计划与控制测试的计划与控制 与大多数项目的情况一样，计划是管理测试过程中至关重要的一环。 一个良好的测试计划应包括： 1. 目标。必须定义每个测试阶段的目标。 2. 结束准则。必须制定准则以规定每个测

14、试阶段何时可以结束 3. 进度。每个阶段都须有时间表.应指出何时设计、写和执行测试用例. 4. 责任。对于每一个阶段，应当确定谁来设计、编写和验证测试用例， 谁来修改发现的软件错误。由于在大型项目中讨论特定的测试结果是 否代表错误时，有可能出现争端，因此还需要确定一名仲裁者。 5. 测试用例库及标准。在大型项目中，用于确定、编写以及存储测试 用例的系统方法是必须的。 6. 工具。必须确定需要使用的测试工具，包括计划由谁来开发或采购、 如何使用工具以及何时需要使用工具。 测试的计划与控制测试的计划与控制 7. 计算机时间。计划每个测试阶段所需的计算机时间，包括用来编译应用程序的 服务器（如果需要

15、的话）、用来进行安装测试所需的桌面计算机、用来运行基于 web 应用程序的web 服务器、联网的设备（如果需要的话）等等。 8. 硬件配置。如果需要特别的硬件配置或设备，则需要一份计划来描述该需求， 该如何满足需求以及何时需要满足。 9. 集成。测试计划的一部分是定义程序如何组装在一起的方法（例如自顶向下的 增量测试）。一个系统如果包含大的子系统或程序，可按增量的方式组装在一起， 例如可以使用自顶向下或自底向上的方法，但是这些构造块是程序或子系统，而 不是模块。如果是这种情况，就需要一个系统集成计划。系统集成计划规定了系 统集成的顺序、系统每个版本的功能以及编写“脚手架”代码以模拟不存在的部 件的职责分工。 10. 跟踪步骤。必须跟踪测试进行中的方方面面，包括对错误易发模块的定位，以 及有关进度、资源和结束准则的进展估计。 11. 调试步骤。必须制定上报已发现错误、跟踪错误修改进程以及将修改部分加入 系统中去的机制。调试计划中还应包括进度、责任分工、工具以及计算机时间/资 源等。 12. 回归测试。回归测试在对程序作了功能改进或进行了修改之后进行，其目的是 判断程序的改动是否引起了程序其他方面的退步。 测试的结束准则测试的结束准则 有三类较为有用的结束准则 第一类，但不是最佳的