软件测试第二部分：测试基础

静态黑盒测试是指：不运行程序、看不到代码的测试

通常针对的测试对象是：产品说明书

为什么测试产品说明书属于静态黑盒测试？

因为产品说明书是书面文档，而不是可执行的程序，因此是静态的，产品说明书的由来是通过各种资源获得的数据，我们不必要知道产品说明书是如何来的，只需要知道它用来干什么即可，因此是黑盒测试，所以说检查产品说明书是静态黑盒测试

温馨提示：虽然市面上产品说明书的格式和规格可能有所区别，但是核心思想、测试方法都是不变的

3.1对产品说明书进行测试的一些重要思想

假定自己是客户：第一次接到需要审查的产品说明书时，最容易做的事是把自己当作客户，站在客户的角度思考测试，但是在假定自己是客户时不要忘记了软件的安全性，客户本身是默认软件是安全的
研究现有的标准和规范：用于检查采用的标准是否正确、有无遗漏
审查和测试类似软件：了解软件最终结果的最佳方法是研究类似软件，通过对类似软件研究、尝试以积累审查产品说明书的经验

二、带上眼罩测试软件

将描述最常用、最有效的软件测试技术

软件最简单的认识就是将其分为两部分

程序
数据

因此测试也是围绕这两部分来进行的

1.动态黑盒测试---带上眼罩测试软件

动态黑盒测试是指：运行程序，看不到代码的测试

通常测试对象：最终软件产品

测试流程：设计测试用例、输入数据、接受输出、检验结果

首先最终产品它是动态的，因为程序在运行----软件测试员像用户一样使用它。同时它又是黑盒，因为测试时不知道程序如何工作---带上了眼罩

1.1测试用例

测试用例是指：用于测试的数据例子

测试用例的分类

有效测试用例：符合产品规格需求
无效测试用例：不符合产品规格需求

1.2设计测试用例的方法---等价类划分法

选择测试用例是软件测试员最重要的任务，一般使用等价类划分法

等价类划分是指：分步骤把海量的测试用例缩减的很小，但过程同样有效

温馨提示：在寻找等价划分时，考虑把软件中具有相似输入、相似输出、相似操作的分在一组。这些组就是等价组

1.3等价类划分法的重要思想---边界条件思想

边界条件是特殊情况，因为编程从根本上说在边界上最容易产生问题

边界条件是指：软件运行在计划操作界限的边界情况

边界条件的特征：

第一个/最后一个
最小值/最大值
开始/完成
超过/在内
空/满
最短/最长
最慢/最快
最早/最迟
最大/最小
最高/最低
相邻/最远

选择测试边界：如果建立两个等价划分就可以找出更多软件缺陷，第一个划分应该包含认为正确的数据---在边界内部最好一两个合法的数据点，第二个划分包含认为可能出现错误的数据---边界之外一到两个非法的数据点

例如： 1<5 那么选择 1 2 4 6

温馨提示：提出边界条件时，一定要测试靠近边界的有效数据，即测试最后一个可能有效的数据，同时测试刚超过边界的无效数据

围绕边界条件进行等价划分并建立测试用例是至关重要的

越界测试的做法:

第一个减1/最后一个加1
开始减1/完成加1
空了再减/满了再加
慢上加慢/快上加快
最大数加1/最小数减1
最小值减1/最大值加1
刚好超过/刚好在内
短了再短/长了再长
早了更早/晚了更晚
最高加1/最低减1

1.4等价类划分法的重要思想---次边界条件思想

普通边界条件容易找到，因为在产品说明书中就有定义，或者是软件的使用过程中很明显。而有些在软件内部，用户看不到，软件测试员有必要检查，这样的边界条件称之为了次边界条件

2的幂

计算机和软件基础是二进制数----用位表示0和1，一个字节byte由8个位组成，一个字由4个字节组成（8位=1字节=4/1字），下表列出了常用的2的幂单位及其等价数值

在建立等价划分的时候，要考虑等级划分中是否包含2的幂的次边界条件。

例如：

如果软件接受用户输入1-1000范围内的数字，谁都知道在合法区间中包含1和1000，也许还要有2和999，为了覆盖任何可能的2的幂的次边界，还要包含靠近4位边界的14、15、16，以及靠近字节边界的254、255、256

ASCII表

在ASCII表中字母和部分字符都有对应的ASCII值，这些情况也是次边界条件

如果测试进行行文本输入或文本转换的软件，在定义数据划分包含哪些值时，参考一下ASCII表是相当明智的。

例如：

如果测试的文本框只接受用户输入字符A-Z和a-z时，就应该在非法划分中包含ASCII表中这些数字符前后的值 @ 、 [ 、' 、{

1.5等价类划分法的重要思想---特殊情况思想

特殊情况分为，默认、空白、空值、零值、无

温馨提示：一定要考虑建立处理默认值、空白、空值、零值或者无输入等条件的等价划分

1.6通过性测试和失效性测试

通过性测试:确认软件至少能做什么，不考验其能力，运用最简单、最直观的测试用例即可

失效性测试：让软件崩溃，考验其能力，纯粹为了破坏软件而设计测试用例

1.7状态测试

到目前为止，我们测试的基本上都是数据，在软件测试的另一个方面是通过不同的状态验证程序的逻辑流程。

软件状态：是指软件当前所处的条件或者模式

建立状态转换图：

绘制状态转换图有几种技术，但绘图技术并不重要，只要项目小组看懂就行了

建立转换图应该表示以下项目:

软件可能进入的每一种独立状态
从一种状态转入另一种状态所需要的输入和条件
进入或者退出某种状态时的设置条件以及输出结果

温馨提示;因为正处于动态黑盒测试，所以不必了解代码中设置的底层变量。从软件用户的角度建立即可

知识补充：unicode(编码)

尽管ASCII仍然是软件表示字符数据非常流行的方式，但是它正被称为统一编码(Unicode)的新标准取代。

Unicode用来解决ASCII码无法表示的书面语言字符问题，如汉字等

三、检查代码

1.静态白盒测试---检查代码

静态白盒是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程

进行静态白盒测试的好处：

尽早发现软件缺陷
为黑盒测试设计测试用例提供思路

1.1正式审查

正式审查是进行静态白盒测试的过程。正式审查含义很广，从两个程序员之间的简单交谈，到软件设计和代码的详细、严格检查，均属于此过程，审查正确的进行可以证明这是早期发现缺陷的好方法，它好比是网口由大到小的抓虫过程，先抓大的，再逐渐抓小的

而正式审查是捕虫的第一张大网

正式审查4个基本要素：

确定问题
遵守规则
准备
编写报告

1.2同事审查

召集小组成员进行初次审查最简单的方法是通过同事审查的方式

大体类似于你看我的我看你的

同事审查常常仅在编写代码或设计体系结构的的程序员，以及充当审查者的其他一两个
程序员和测试员之间进行。这个小团体只是在一一起审查代码，寻找问题和失误。为了保证
审查的高效率(不致流于休息闲聊)，所有的参与者要切实保证正式审查的4个关键要素:查找问题、遵守规则、审查准备和编写报告。日由于同事审查是非正式的，这些要素常常大打折扣。即便如此，聚集起来讨论代码也能找出软件缺陷。

1.3走查

走查是比同事审查更正规划的下一步。走查中编写代码是程序员向小组或者其他程序员和测试员组成的小组做正式陈述。

陈述者逐行或者逐个功能地通读代码，解释代码为什么且如何工作。审查人员聆听叙述，提出有疑义的问题。由于公开陈述的参与人数要多于同事审查的，因此，为审查做好准备和遵守规则是非常重要的。同样重要的是，审查之后陈述者要编写报告说明发现了哪些问题，计划如何解决发现的软件缺陷。

1.4检验

检验是最正式的审查类型，具有高度组织化，要求每一个参与者都接受训练。检验与同事审查和走查的不同之处在于表述代码的人不是原来的程序员

其余的参与者称为检验员，其职责是从不同角度，如用户、测试员或者产品支持人员的角度审查代码。这有助于从不同视角来审查产品，通常可以指出不同的软件缺陷

有些检验员还被同时任为会议协调员和会议记录员，保证检验的过程遵守规则及审查有效进行

1.5编码标准和规范

在正式审查中，检验员查找代码中的问题和缺漏，有一些程序代码虽然可以正常运行，但是编写不符合某种标准或者规范，这将定成一种问题

坚持标准或规范的原因：为了保证以下特性

可靠性
可读性/维护性
移植性

项目要求可能从严格遵守国家或者国际标准的，到松散符合小组内部规范的，不一而足

重要的是开发小组在编程过程中拥有标准和规范，并且这些标准和规范被正式审查验证

1.6正式审查的审查清单

数据引用错误
数据声明错误
计算错误
比较错误
控制流程错误
子程序参数错误
输入/输出错误
其他错误等

四、带上X光眼镜测试软件

1.动态白盒测试---带上X光眼镜测试软件

由于是动态的，就一定是测试运行中的程序，由于是白盒，就一定要洞察盒子里面，检查代码并观察运行情况，这好像是带上了x光眼睛测试软件

用一句话来概括：

动态白盒测试是指利用查看代码功能（做什么）和实现方式（怎么做）得到的信息来确定哪些需要测试，哪些不需要测试，如何开展测试

1.1动态白盒测试和调试的区别

一定不要把动态白盒测试和调试弄混了，他们表面上很相似，但是他们的目标大不相同，

动态白盒测试的目标是寻找软件缺陷，而调试的目标是修复缺陷

1.2分段测试

将代码分段构建和测试，最后合在一起形成更大的部分，即可使得整个产品通过他们相连而成

单元测试：在底层进行的测试称为单元测试或者模块化测试。

集成测试：单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块的组合进行集成测试

系统测试：这个不断增加的测试过程继续进行，加入越来越多的软件片段，直至测试整个产品或者产品的主要部分，称为系统测试

1.3数据覆盖

同样的角度看软件，可以相当容易地把得到的白盒信息映射到已经写完的黑盒测试用例上,首先考虑数据

数据流:数据流覆盖主要是指在软件中完全跟踪一批数据，在单元测试级，数据仅仅通过一个模块或者函数，同样的跟踪方式可以用于集成模块，甚至整个软件产品

次边界:如果进行白盒测试就需要仔细检查代码，，找到次边界条件，建立能够测试他们的测试用例充分观察次边界条件

公式和等式:公式和等式藏在代码里，公式会有一些数学规定要求，例如分母不为0情况等等，这也需要仔细审查，是否做了前提条件

1.4代码覆盖

测试数据只是一半工作，还必须测试程序状态以及程序流程，设法进入和退出每一个模块，执行每一行代码，进入软件每一条逻辑决策和分支。这种类型测试叫做代码覆盖测试

对于小程序或者单独模块，使用调试器就够了，对于大多数程序进行代码覆盖测试要用到一个

工具：代码覆盖率分析器

温馨提示:如果测试用例覆盖了软件90%而未发现任何缺陷，说明软件质量很好--也可能有免疫力了。相反只覆盖了50%就发现了软件缺陷，说明软件还需要大大改进

1.5逻辑覆盖---语句覆盖

基本思想：设计用例，使程序中的每个可执行语句至少执行一次。
每个可执行语句：每个语句，那么下图中执行为：1->2->3->4

优点：可以很直观的从源代码获得用例，无需细分每条判定表达式
缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件是无法测试的，如在多分支的逻辑运算中无法全面考虑。语句覆盖是最弱的逻辑覆盖

1.6逻辑覆盖---判定覆盖

基本思想：设计用例，使得程序中的每一个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足

重点是判定（针对于真假判断），覆盖条件：

条件1：T，条件3：F
条件1：F，条件3：T

或者

条件1：T，条件3：T
条件1：F，条件3：F

优点：判定覆盖比语句覆盖具有更强的测试能力。同时判定覆盖与具有和语句覆盖一样的简单性，无需细分每个判定就可以得到测试用例
缺点：往往大部分的测试用例是由多个逻辑条件组合的，若仅仅判断其整个的最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径，判定覆盖仍是很弱的逻辑覆盖

1.7逻辑覆盖---条件覆盖

基本思想：设计用例，使每个判断中的每个条件的可能取值至少满足一次

重点是判断语句的条件（针对条件语句）

判断表达式1：
设条件 a>0 为真记T1
           假记F1
条件 b>0 为真记T2
           假记F2

判断表达式3：
设条件 a>1 为真记T3
           假记F3
条件 c>1 为真记T4
           假记F4

覆盖条件：

T1,F2,T3,F4
F1,T2,F3,T4

我们用条件覆盖的思想就是覆盖T1,T2,T3,T4,F1,F2,F3,F4

优点：增加了对条件判断情况的测试，增加了测试路径
缺点：条件覆盖不一定包含判定覆盖，例如，上面的测试用例中就不包含判断1的T分支，判断3的F分支。条件覆盖只能保证每个条件语句取值至少有一次为真，而不考虑所有的判定结果

1.8逻辑覆盖---条件-判定覆盖

基本思想：设计用例，使判定条件中的所有可能（条件成立、不成立）至少执行一次取值，同时，所有判断的可能结果（取真，取假），至少执行一次

覆盖条件用例：

T1,T2,T3,T4
F1,F2,F3,F4

要满足：T1,T2,T3,T4,F1,F2,F3,F4

优点：能同时考虑到判定，条件两种覆盖
缺点：未考虑条件的组合情况

1.9逻辑覆盖---组合覆盖

基本思路：设计用例，使所有可能的条件取值组合至少执行一次

重点：所有条件取值的组合

编号覆盖条件取值
1 T1,T2
2 T1,F2
3 F1,T2
4 F1,F2
5 T3,T4
6 T3,F4
7 F3,T4
8 F3,F4

覆盖条件覆盖组合
T1，T2 , T3 , T4 1,5
T1，F2 , T3 , F4 2,6
F1，T2 , F3 , T4 3,7
F1，F2 , F3 , F4 4,8

编号	覆盖条件取值
1	T1,T2
2	T1,F2
3	F1,T2
4	F1,F2
5	T3,T4
6	T3,F4
7	F3,T4
8	F3,F4

覆盖条件	覆盖组合
T1，T2 , T3 , T4	1,5
T1，F2 , T3 , F4	2,6
F1，T2 , F3 , T4	3,7
F1，F2 , F3 , F4	4,8

优点：组合覆盖满足了判定覆盖、条件覆盖、和判定、条件覆盖准则。
缺点：线性的增加了测试用例的数量

1.10逻辑覆盖---路径覆盖

基本思想：设计测试用例，来覆盖程序中的所有可能执行的路径

继上面的的条件取值表格

覆盖路径覆盖组合
1-2-4 1,5
1-2-5 1,8
1-3-4 4,7
1-3-5 4,8

优点：这种测试方法可以对程序进行彻底的测试，比前面五种的测试要广
缺点：需要设计大量的，复杂的测试用例，使得工作量呈指数增长，不见得能把所有的条件组合都覆盖