黑盒测试详解

zhangkai85

任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

是否有不正确或遗漏的功能？

在接口上，输入是否能正确的接受？能否输出正确的结果？

是否有数据结构错误或外部信息（例如数据文件）访问错误？

性能上是否能够满足要求？

是否有初始化或终止性错误？
　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

对程序模块的所有独立的执行路径至少测试一遍。

对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

在循环的边界和运行的界限内执行循环体。

测试内部数据结构的有效性，等等。
　　以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误。

[ 本帖最后由 zhangkai85 于 2006-7-26 17:33 编辑 ]

zhangkai85

　是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

　　 1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

　　无效等价类:与有效等价类的定义恰巧相反.

　　设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

　　2）划分等价类的方法:下面给出六条确定等价类的原则.

　　①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

　　②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

　　③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

　　④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

　　⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

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

　　3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

　　 输入条件 有效等价类 无效等价类
　　... ... ...
　　... ... ...

　　 然后从划分出的等价类中按以下三个原则设计测试用例:

　　①为每一个等价类规定一个唯一的编号.

　　②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

　　③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

zhangkai85

怎么没人啊？

lyscser

sh
受教了，多谢！

summy911

人呢
在了啊

summy911

发了这么多啊
呵呵

etfltj1004

顶啊！！！

etfltj1004

做个样子看看啊

summy911

也是哈
那我也顶 下吧
你明天面试是在哪里啊?

zhangkai85

还以为你迷路了。。

etfltj1004

你测试报告发上面啊

zhangkai85

对
发上面
我看哈

etfltj1004

一个南山 一个岗夏啊

summy911

我这里没有现成的测试报告啊
跟你写了一点
我有的测试报告是专业的 不方便发
内部资料啊

zhangkai85

。。。

summy911

啊
早上的是南山吗?
那不是要起早啊
回去了给你们看啊
写的不多啊
细节太麻烦啊

zhangkai85

XX软件测试报告

共 x 页





拟制                    年    月    日
审核                    年    月    日
会签                    年    月    日
批准                    年    月    日





1 范围
本文档适用于XX软件的单元/集成测试。
1.2 系统概述
1.3 文档概述
本文档用于对XX软件的测试工作阶段成果的描述。包括对软件测试的整体描述，软件测试的分类和级别，软件测试的过程描述，软件测试的结果等内容。
2 引用文档
《XX软件需求规格说明》
《XX软件设计说明》
《XX系统接口协议》
3 测试概述
3.1被测软件的基本概况
使用的编程语言：XXX 汇编语言
程序行数：1590
子程序个数：11
单行注释行数：669
注释率：约为42%
3.1.1. 测试小结
本次测试对XX软件进行了静态分析和动态测试。测试工作分为两个阶段。第一阶段进行了软件静态分析，软件测试人员和开发人员分别对软件V1.00版本的代码进行走读。在此基础上软件开发人员对代码走查中发现的问题进行了修改，做了97处代码变更并提交了V1.01版本进行动态测试。
在测试过程中针对发现的软件缺陷进行了初步分析，并提交程序设计人员对原软件中可能存在的问题进行考查。在软件测试中首先根据软件测试的规范进行考核，将书写规范，注释等基础问题首先解决，其次考核软件测试中的问题是否存在设计上的逻辑缺陷，如果存在设计缺陷则应分析该缺陷的严重程度以及可能引发的故障。软件开发人员在以上基础上对软件的不足做出相应的修改，同时通过软件回归测试验证软件修改后能够得到的改善结果。

软件代码1.00与1.01版变更明细表：
编号        1.00版行号        1.01版行号        更改说明
1        19        22        注释变更
2        26        29        注释变更
3        29        32        注释变更
4        95        98        注释变更
5        108行后        113～116        增加新变量
6        171、172        180、181        命令字大小写变更
7        以下略               

从上表可以看出，注释变更一共有15处，主要排除了对原程序的理解错误问题；根据程序的书写规范要求，一行多条语句改为一行一条语句的更改一共有42处；命令字大小写变更一共有7处；在代码走查中对冗余和无用的代码作了更改，将这些代码注释掉，此类更改一共有14处。上述4类更改一共有78处，这些更改对程序本身的功能没有任何影响，但从软件规范的角度来看提高了程序的可读性和规范性。
其余19处变更为代码变更，主要是在软件测试中发现原程序的可靠性不足，在不改变原程序功能的基础上相应的增加了新变量、新语句、新程序以提高整个程序的可靠性。
在动态测试阶段进行了单元测试和集成测试。此阶段发现的软件问题经软件测试人员修改，提交了V1.02版本，软件测试人员对此版本的软件代码进行了回归测试，确认对前阶段发现的软件问题进行了修改，消除了原有的软件问题并且确认没有引入新的软件问题。认定V1.02版为可以发行的软件版本。
3.1.1.1 静态分析小结
静态测试采用人工代码走查的方式进行。参加代码走查的软件开发人员有：（略）；参加代码走查的软件测试人员有：（略）。代码走查以代码审查会议的形式进行。静态分析过程中共进行了四次会议审查。静态测试阶段的主要工作内容是：
        根据对软件汇编源代码的分析绘制详细的程序流程图和调用关系图（见附件1）；
        对照软件汇编源代码和流程图进行程序逻辑分析、算法分析、结构分析和接口分析；
        对软件汇编源代码进行编程规范化分析。
通过静态测试查找出软件的缺陷18个，其中
轻微的缺陷4个，占所有缺陷的22.2％
中等的缺陷11个，占所有缺陷的61.1％
严重的缺陷：3个，占所有缺陷的16.7％
上述软件缺陷见附件《软件问题报告单》
3.1.1.2 动态测试小结
动态测试使用的测试工具为XXX软件集成开发环境。
总共的测试用例数：143个。全部由测试人员人工设计。
其中单元测试用例138个，集成测试用例5个。
发现的软件缺陷有2个，都是在单元测试过程中发现的。集成测试阶段未发现新的软件缺陷。在发现的软件缺陷中：
中等的缺陷1个，占所有缺陷的50％
严重的缺陷1个，占所有缺陷的50％
上述软件缺陷见附件《软件问题报告单》
动态测试中代码覆盖率：
代码行覆盖率            100%
分支覆盖率              100%
程序单元调用覆盖率      100％
3.1.1.3 回归测试小结
对软件测试过程中发现的缺陷经软件开发人员确认后进行了代码更改，并对更改后的代码进行了回归测试。本报告中的数据是回归测试后的测试数据。
3.1.1.4 测试分析
下面将对此次软件测试中的所有缺陷以及改进设计进行分析。
1．        静态测试中的缺陷分析：
1）        4个轻微缺陷属于代码冗余，由于在程序设计中加入了部分调试程序，在程序设计完成后未将这些调试代码注释或删除掉而造成代码冗余，但对程序本身的功能并无影响。修改后程序的效率得到提高。
2）        11个中等缺陷属于注释变更，在原程序代码的注释中存在注释不准确的问题，会影响程序员对程序的理解，修改后的程序提高了程序的可读性。
3）        重点分析3个严重缺陷：
第一个严重缺陷属于XX号的无效判别和相应的处理问题，程序对XX号进行无效判别时，判别界限并不完全，在本跟踪程序中XX号的有效数为01-10（用4位表示），而判别无效时只判了为00的情况，没有判别大于10的情况。而且在为00时也没有作相应的处理，修改后的程序对设计进行了改进，详见改进设计分析3。
第二个严重缺陷属于程序设计中读取地址错误问题，经分析在调试中读取的数据是正确的，但是读取的地址与设计初衷不相符，修改后问题得到了解决，详见改进设计分析1。
第三个严重错误是近区/远区子程序判断与进入条件反了，经分析对程序的影响不大，但与设计初衷不一致，修改后问题得到了解决，详见改进设计5。
2．        动态测试中的缺陷分析：
1）        中等缺陷1个，在程序的注释中出现错误，将近区注释为远区，修改后问题得到了解决，提高了程序的可读性。
2）        严重缺陷1个，在XX号无效的判别中，本应判断大于10，但误设计为0，修改后经回归测试问题得到了解决。  
3．        改进的设计分析：
（因和产品相关，略）
   
3.1.2 测试记录
a 测试时间：2005年8月5日至2005年9月17日。
b 地点：（略）。
c 硬件配置：P4CPU/2.0G，内存256M，硬盘1G
d 软件配置：Wondows 98，
e 被测软件版本号：V1.0，V1.01，V1.02
f 所有测试相关活动的日期和时间、测试操作人员等记录见软件测试记录文档。
4 测试结果
在两个阶段测试过程中共发现软件缺陷20个，经软件开发人员确认的缺陷为20个，经过改正的代码消除了所有以确认的软件缺陷并通过了回归测试。因测试条件所限，未能进行软件的确认测试和系统测试。
5 评估和建议
5.1 软件评估
5.1.1 软件编码规范化评估
经过回归测试，未残留的软件编码规范性缺陷。软件代码文本注释率约为42%，代码注释充分，有利与代码的理解和维护。
5.1.2 软件动态测试评估
被测软件单元的总数：11个
使用的测试用例个数：143个
达到软件测试出口准则的软件单元数为11个，通过率100％
通过单元和集成测试得知：软件代码逻辑清晰、结构合理、程序单元间接口关系一致，运行稳定。
5.2 改进建议
a. 建议在软件开发项目中全面实施软件工程化，加强软件开发的管理工作。
b. 建议进一步加强软件需求规格说明、软件设计文档编制以及编写代码的规范化。特别是应该将系统中的硬件研制和软件研制分别管理，软件文档编制的种类和规格按照相关标准执行。
c. 尽早开展软件测试工作。在软件研制计划安排上给软件测试留有必要的时间，在资源配置上给软件测试必要的支撑。
d. 建议结合系统联试，开展软件的确认和系统测试。
附件：
软件问题报告单（略）
软件更改通知单（略）
软件测试记录（略）

zhangkai85

这个够规格的么？

etfltj1004

杂说话那么慢撒

summy911

呵呵
还要工作啊 老大
差不多是那几个步骤啊
你们只说大的几个步骤就可以了