软件测试地基本概念.docx

软件测试地基本概念.docx

《软件测试地基本概念.docx》由会员分享，可在线阅读，更多相关《软件测试地基本概念.docx（14页珍藏版）》请在冰豆网上搜索。

软件测试地基本概念

软件测试的基本概念

一：

什么是软件测试

软件测试，目前定义混杂，没有统一的标准，但是最经典的定义是：

在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估的一个过程。

二：

什么是软件质量

软件质量包括：

内部质量，外部质量，使用质量。

软件质量：

软件满足规定或潜在用户需求的能力。

三：

软件测试与软件质量的区别

质量保证（QA）：

主要工作是通过预防，检查与改进来保证软件质量。

它所关注的是软件质量的检查与测量。

着眼软件开发活动中的过程，步骤及产物，而不是对软件进行剖析进而找出问题。

软件测试：

测试关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。

测试人员要“执行”软件，对过程中的产物—开发文档和源代码进行走查，运行，以找出问题，报告质量。

测试人员也必须假设软件存在问题，所以所做的操作都是为了找出更多的问题，而不仅仅验证每一件事是正确的。

四：

软件测试的内容

根据测试定义，测试贯穿于整个软件生命周期中。

在开发的不同阶段，需要测试不同的内容。

包括文档，源代码，数据等。

五：

软件测试的目的

测试的目的，是想以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。

（注意这个问题的答案，经常会与软件测试的定义混淆）

六：

软件测试的分类（面试问题）

按开发阶段来分：

单元测试，集成测试，系统测试，验收测试。

按测试的实施单位来分：

开发方测试，用户测试，第三方测试。

按测试技术：

白盒测试，黑盒测试，灰盒测试。

七：

黑盒，白盒，灰盒测试概念

白盒测试：

知道产品内部工作过程，可通过测试来检测产品内部是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能够按照预定要求正确工作，而不管产品的性能。

它包括两种测试方法：

静态测试和动态测试。

静态测试时不通过执行程序而进行测试的技术，其关键功能是检查软件的表示和描述是否一致，没有冲突或者产生歧义。

而动态测试需要软件的执行，当软件系统在模拟的或真实的环境中执行之前，之中，之后，对软件系统行为的分析是动态测试的主要特点。

黑盒测试：

是一种非常重要的测试策略，又称为功能测试。

使用这种测试方法，将程序视为一个黑盒子。

测试目标与程序内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正常运行的环境条件。

灰盒测试：

结合了白盒与黑盒的要素。

关注输出对于输入的正确性，同时也关注内部表现，但不像白盒那样详细，完整，只是表征性的。

八：

软件测试模型（面试常问到的问题）

V模型

从这个图，可以直观的观察到测试过程的局限性，它把测试过程放在了需求分析，概要设计，详细设计与编码之后了，容易使人理解测试是软件开发的最后一个阶段，主要针对程序进行测试寻找错误了。

而需求分析阶段隐藏的问题只能在最后才能发现。

所以，这个图形，不能很好的反应软件测试贯穿整个开发的过程。

（笔者个人认为这种图形，比较适合黑盒测试）

W模型

在V模型的基础上，演化出W模型。

根据图形，很容易看出，W模型比V模型更科学，它伴随着整个开发过程，而且测试对象不仅仅是程序，同时也测试需求与设计。

H模型

测试准备测试就绪点测试执行测试流程

H模型：

测试条件只要成熟，测试准备活动完成了，那么就可以执行测试活动。

在H模型中，测试模型是一个独立的过程，贯穿于整个产品周期，与其他流程并发的进行。

当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

X模型

九：

软件测试生命周期：

软件测试生命周期一般包括7个阶段：

1）计划2）分析，3）设计，4）构建，5）测试周期，6）最后测试和实施，7）实施后。

白盒测试方法

白盒测试方法包括动态和静态。

静态包括：

代码检查，静态结构分析，代码质量度量等。

代码检查又包括：

代码走查，桌面检查，代码审查。

代码走查与检查都要求一个小组的人员来阅读或直观检查特定的程序。

经常采用头脑风暴.

注意一点：

头脑风暴，是测试，非调试。

头脑风暴的程序：

1：

准备阶段

确立问题，提前一周通知给参加人员，一遍又独立思考的时间。

2：

头脑风暴

主持人简明介绍讨论问题的内容，扼要介绍各种系统的设想和方案，然后激发参加者踊跃发言，一些有价值的设想，往往可以经过“思维共振”的“头脑风暴”，通过对两个，对个设想的综合迅速发展起来。

3：

解决问题

综合大家的意见后，进而提出最终解决问题的可行性方案。

代码走查总，3~4人一组，参加者其中之一是程序编写者，测试的工作主要是其他人。

代码走查与代码检查是对过去桌面检查过程的改进。

（桌面检查就是程序员阅读自己程序的过程）。

代码走查与检查也更高效，其优点在于一旦发现错误，就能够迅速的对其进行定位降低了调试的成本。

在于可以找到30—70%的逻辑设计与编码错误。

注意：

30~70%的错误发现率，是指已知错误的70%，而不是整体错误的70%，因为对于错误总数来说，我们永远都不知道是多少。

白盒测试的动态方法：

程序插桩测试

所谓插桩，就是借助往被测程序中插入操作，来实现测试目的的方法。

（如常常加入打印语句，看执行后的效果是否为我们希望的结果）。

白盒测试具体实施办法

1：

代码检查：

以组为单位阅读代码，一系列规程和错误检查技术的集合。

一般这个小组成员为4个人。

其中一个人发挥着协调作用。

协调人应该是个称职的程序员，不是该程序的编码人员，不需要对程序的细节了解的很清楚。

协调人的职责包括：

Ø为代码检查分发材料，安排进程

Ø在代码检查中起主导作用

Ø记录发现的所有错误

Ø确保所有记录都得到纠正

其他成员为：

该程序的编码人员，其他的程序设计人员，一名软件测试专家（呵呵，我们的目标）

在代码检查的前几天，协调人员应该将资料下发。

所有成员应在检查前熟悉资料。

代码检查过程中进行两项活动：

有程序编码人员逐条语句讲述程序的逻辑结构（非一条条讲，主要讲逻辑结构和程序实现的方法）

对着历来的编码错误列表分析程序

代码检查的地点应该避免外部干扰，会议的时间为90~~120分钟之间。

下面给出一份代码检查中常见的错误列表：

✧数据引用错误

✧数据声明错误

✧运算错误

✧比较错误

✧控制流程错误

✧接口错误

✧输入/输出错误

✧其他检查

✧其他检查

2：

代码走查：

与代码检查很相似，大师规程略有不同，采用的错误检查技术也不同。

代码走查也是采用持续的不间断的会议形式。

小组成员由3-5人组成。

一个扮演协调人，一个人担当秘书（记录检查出来的错误），一名测试人员，建议其他的参加者是：

一位极富经验的程序员

一位程序设计语言专家

一位程序言新手

最终维护程序的人员

一位来自其他不同项目的成员

一位来自该软件编程小组的成员

走查的规程不用于检查。

代码的参与者“使用了计算机”，测试人员带来了测试用例来参加会议，把测试数据沿程序的逻辑结构走一遍。

人脑执行速度当然比较慢，因此，这些测试本身起不到关键的作用，作用只是提供了启动代码走查和质疑程序员逻辑思路极其设想的手段。

与代码检查相同，代码走查的参与者态度至关重要。

提出的建议应针对程序本身，而不是针对程序员。

3：

同行评分：

一种依据程序的整体质量，可维护性，可扩展性，易用性和清晰性对匿名程序进行评价的技术。

该项技术的目的是为了程序员提供自我评价的手段。

4：

覆盖测试：

包括语句覆盖，判定覆盖，条件覆盖，判定条件覆盖，条件组合覆盖，路径覆盖。

黑盒测试具体实施办法

黑盒测试用例设计方法

☯等价类划分方法

☯边界值分析方法

☯错误推测方法

☯因果图方法

☯判定表驱动分析法

☯正交试验设计方法

☯功能图分析方法

等价类划分法：

等价类划分法是把所有可能的输入数据，即程序的输入域划分为若干部分，然后从每一部分的子集选取少量具有代表性的数据作为测试用例。

可以划分为：

有效等价类，无效等价类。

划分的原则：

✓在输入条件规定的取值范围，确立一个有效等价和两个无效等价

✓在输入条件规定“必须如何”的条件下，确立一个有效等价和一个无效等价

✓输入布尔量的条件下，确立一个有效类和一个无效类

✓在输入条件规定输入数据的一组值，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

✓在规定了输入数据必须遵守的规则情况下，可确立一个有效等价类和若干个无效等价类。

✓在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应在将该等价类进一步的划分为更小的等价类。

#include

#include

voidmain（）

{

intn;

charstr[10];

scanf（"%s",str）;

n=atoi（str）;

printf（"string=%s,integer=%d\n",str,n）;

}

测试用例设计如下：

外部条件

编号

有效等价类

编号

无效等价类

输入字符串

做为参数

Y01

整数

Y02

带小数的实数

W01

非数字字符

W02

空字符串

边界值分析法：

是一种补充等价类划分的测试用例设计技术。

边界值是一种很实用的黑盒测试方法。

具有很强的发现错误的能力。

它的测试用例来源于等价类的边界值。

实践证明，大量的故障往往发生在输入定义域或输出值域的边界上，而非内部。

遵循的原则：

1）如果输入条件对取值范围进行了界定，则应以边界内部以及刚超出范围边界外的值作为测试用例。

若范围的下界为x,上界为y,则测试用例应当包含x,y，以及稍小于x和稍大于y的值。

2）如果对取值的个数进行了界定，则应当分别以最大、最小个数及稍小于最小，稍大于最大个数作为测试用例。

3）对于输出条件，前两条规则同样适应。

4）如果程序规格说明书中指明输入或者输出域是一个有序的集合，就应当选择集合中的第一个和最后一个元素作为测试用例。

如：

规定输入值范围为-1~+1,则测试用例设计为：

+1,-1,+1.01,-1.01

规定输入的记录可容纳1~255条，则测试用例设计为：

0,1,255,256。

因果图法：

前面的输入法只考虑输入条件，没有考虑输入条件的联系。

因此，必须考虑一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。

因果图法最终生成的就是判定表，适合于检查程序输入条件的各种组合情况。

因果图是一种形式语言，用自然语言描述的规格说明可以转换为因果图。

因果图实际上是一种数字逻辑电路。

利用因果图生成测试用例的基本步骤如下：

1.分析软件规格说明描述中，哪些是原因，哪些是结果，并给每个原因和结果赋予一个标示符。

2.分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的关系，根据这些关系，画出因果图。

3.由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现，为表明这些特殊的情况，在因果图上用一些记号表明约束或限制条件。

4.把因果图转换为判定表

5.把判定表的每一列拿出来作为依据，设计测试用例。

在因果图中，才Ci表示原因，Ej表示结果。

基本符号如下图（其中，各结点如下图，可取值“0”或“1”，“0”表示某状态不出现，“1”表示某状态出现）：

恒等。

若原因出现，则结果出现，若原因不出现，则结果也不出现。

非（~）：

若原因出现，则结果不出现，若原因不出现，则结果出现。

或（V）：

若几个原因中的一个出现，则结果出现；若原因都没出现，则结果不出现。

与（∧）：

若几个原因出现，结果才出现。

用因果图表示如下：

原因与原因之间的约束条件，有：

E（互斥）：

a，b两个原因不能同时成立，两个中最多只能一个成立

I（包含）：

表示a,b,c三个原因中至少有一个必须成立

O（唯一）：

表示a和b当中必须有且只有一个成立

R（要求）：

表示当a出现的时候，b也必须出现

M（屏蔽）：

表示当a是I时，b必须是O。

而当a为O时，b的值不定。

因果图的约束符号如下：

错误推测法：

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

错误推测方法的基本思想，列举出程序中所有可能的错误和容易发生错误的特殊情况，根据他们选择测试用例。

例如：

在单元测试时曾列出的许多在模块中常见的错误。

以前产品中曾经发现的错误等。

这些都是错误的总结。

还有，输入数据和输出数据为零的情况，输入表格为空格或输入表格只有一行。

这些都是容易产生错误的情况。

场景分析法：

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成场景，而同一事件不同的触发顺序和处理结果就形成了事件流。

这种软件设计方面的思想也可以引入到测试中来。

黑盒测试的优缺点

优点

不需要了解程序内部的代码及实现，即测试重点在输入与输入结果

从用户的角度出发，能尽早发现常见的错误

易于实施

缺点

不能完全覆盖所有的代码，覆盖率较低

自动化测试的复用性较低，重复工作量较大

完全取决于测试用例的设计，设计的好坏直接影响测试结果

如果软件规格说明书有误，则无法发现。