航天工业总公司二院204所 周新蕾 缪峥红
一、对软件可靠性测试的认识

1.有关术语
(1)软件可靠性 在规定条件下,在规定时间内,软件不引起系统失效的概率。该概率是系
统输入和系统使用的函数,也是软件中存在故障的函数,系统输入将确定是否会遇到存在的故
障。
(2)软件可靠性估计 应用统计技术处理在系统测试和运行期间采集、观察到的失效数据
,以评估该软件的可靠性。
(3)软件可靠性测试 在有使用代表性的环境中,为进行软件可靠性估计对该软件进行的
功能测试。
需要说明的是,"使用代表性"指的是在统计意义下该环境能反映出软件的使用环境特性
。

2.软件可靠性测试的目的
软件可靠性测试的主要目的有:
(1)通过在有使用代表性的环境中执行软件,以证实软件需求是否正确实现。
(2)为进行软件可靠性估计采集准确的数据。估计软件可靠性一般可分为四个步骤,即数
据采集、模型选择、模型拟合以及软件可靠性评估。可以认为,数据采集是整个软件可靠性
估计工作的基础,数据的准确与否关系到软件可靠性评估的准确度。
(3)通过软件可靠性测试找出所有对软件可靠性影响较大的错误。

3.软件可靠性测试的特点
软件可靠性测试不同于硬件可靠性测试,这主要是因为二者失效的原因不同。硬件失效
一般是由于元器件的老化引起的,因此硬件可靠性测试强调随机选取多个相同的产品,统计它
们的正常运行时间。正常运行的平均时间越长,则硬件就越可靠。软件失效是由设计缺陷造
成的,软件的输入决定是否会遇到软件内部存在的故障。因此,使用同样一组输入反复测试软
件并记录其失效数据是没有意义的。在软件没有改动的情况下,这种数据只是首次记录的不
断重复,不能用来估计软件可靠性。软件可靠性测试强调按实际使用的概率分布随机选择输
入,并强调测试需求的覆盖面。
软件可靠性测试也不同于一般的软件功能测试。相比之下,软件可靠性测试更强调测试
输入与典型使用环境输入统计特性的一致,强调对功能、输入、数据域及其相关概率的先期
识别。测试实例的采样策略也不同,软件可靠性测试必须按照使用的概率分布随机地选择测
试实例,这样才能得到比较准确的可靠性估计,也有利于找出对软件可靠性影响较大的故障。
此外,软件可靠性测试过程中还要求比较准确地记录软件的运行时间,它的输入覆盖一般也要
大于普通软件功能测试的要求。
对一些特殊的软件,如容错软件、实时嵌入式软件等,进行软件可靠性测试时需要有多种
测试环境。这是因为在使用环境下常常很难在软件中植入错误,以进行针对性的测试。

4.软件可靠性测试的效果
软件可靠性测试是软件可靠性保证过程中非常关键的一步。经过软件可靠性测试的软件
并不能保证该软件中残存的错误数最小,但可以保证该软件的可靠性达到较高的要求。从工
程的角度来看,一个软件的可靠性高不仅意味着该软件的失效率低,而且意味着一旦该软件失
效,由此所造成的危害也小。一个大型的工程软件没有错误是不可能的,至少理论上还不能证
明一个大型的工程软件能没有错误。因此,保证软件可靠性的关键不是确保软件没有错误,而
是要确保软件的关键部分没有错误。更确切地说,是要确保软件中没有对可靠性影响较大的
错误。这正是软件可靠性测试的目的之一。
软件可靠性测试的侧重点不同于一般的软件功能测试,其测试实例设计的出发点是寻找
对可靠性影响较大的故障。因此,要达到同样的可靠性要求,可靠性测试比一般的功能测试更
有效,所花的时间也更少。
另外,软件可靠性测试的环境是具有使用代表性的环境,这样,所获得的测试数据与软件
的实际运行数据比较接近,可用于软件可靠性估计。
总之,软件可靠性测试比一般的功能测试更加经济和有效,它可以代替一般的功能测试,
而一般的软件功能测试却不能代替软件可靠性测试,而且一般功能测试所得到的测试数据也
不宜用于软件可靠性估计。

二、软件可靠性测试中需注意的问题
软件可靠性测试一般可分为四个阶段:制定测试方案,制定测试计划,进行测试并记录测
试结果,编写测试报告。
制定测试方案时需要特别注意被测功能的识别和失效等级的定义。制定测试计划时需设
计测试实例,决定测试时要确定输入顺序,并确定程序输出的预期结果,这时也需注意测试覆
盖问题。

1.功能识别
软件可靠性测试的第一步就是进行功能识别,确定使用剖面。功能识别的目标是:识别所
有被测功能以及执行这些功能所需的相关输入,识别每一个使用需求及其相关输入的概率分
布。
为达到第一个目标,需要分析软件功能的所有集合,这些功能之间全部的约束条件,功能
之间的独立性、相互关系和相互影响,还需分析系统的不同运行模式、失效发生时系统重构
策略等对软件运行方式有较大影响的因素。
第一个目标也是一般软件功能测试需要达到的目标,但第二个目标则是软件可靠性测试
特别强调的。为了得到能够反映软件使用的有代表性的概率分布,测试人员必须和系统工程
师、系统运行分析员和顾客共同合作。需要指出的是,由于可靠性的要求,输入数据的概率分
布应包括合法数据的概率分布和非法数据的概率分布两部分。有时为了更好地反映实际使用
状况,还需给出那些影响程序运行方式的条件,如硬件配置、负荷等的概率分布。

2.定义换效等级
定义失效等级主要是为了解决下面两个问题:
·对发生概率小但失效后危害严重的功能需求的识别。
·对可不查找失效原因、并不做统计的功能需求的识别。
在制定测试计划时,失效及其等级的定义应由测试人员、设计人员和用户共同商定,达成
协议。一般的等级定义如表所示。
@@16115000.GIF;表1 失效等级定义@@
如果存在1级和2级失效可能性,那么就应该进行故障树分析,标识出所有可能造成严重失
效的功能需求和其相关的输入域、外部条件和发生的可能性。
对引起1级和2级失效的功能需求及其相关的输入域必须进行严格的强化测试。对引起3
级失效的功能可按其发生概率选择测试实例。第4级失效可不查找原因,可在以后的版本中处
理。

3.可靠性测试覆盖
可靠性测试必须保证输入覆盖和环境覆盖,这是准确估计软件可靠性的基础。
输入覆盖包括下面几个内容:
·输入域覆盖,即所有被测输入值域的发生概率之和必须大于软件可靠度的要求。
·重要输入变量值的覆盖。
·相关输入变量可能组合的覆盖,以确保相关输入变量的相互影响不会导致软件失效。
·设计输入空间与实际输入空间之间区域的覆盖,即不合法输入域的覆盖。
·各种使用功能的覆盖。
环境覆盖是指测试时必须覆盖所有可能影响程序运行方式的条件。

三、软件可靠性测试的步骤
软件可靠性测试分为四个阶段:

1.制订测试方案
本阶段的目标是识别软件功能需求,触发该功能的输入和对应的数据域,确定相关的概率
分布及需强化测试的功能。
以下是我们推荐的步骤。在一些特定的应用中,有的步骤并不是必须的。
(1)分析功能需求 分析各种功能需求,识别触发该功能的输入及相关的数据域(包括合法
与不合法的两部分)。分析时要注意下述问题:
·该软件是否存在不同的运行模式?如果存在,那么应列出所有的系统运行模式。
·是否存在影响程序运行方式的外部条件?如果存在,那么有多少?它们的影响程度如何
·各种功能需求之间是相互独立的还是相关的?如果相关,是密切相关还是部分相关?如
果两种功能密切相关,那么可将两种功能合并为一种功能。如果功能之间为部分相关,则需列
出相应输入变量的合法组合。
(2)定义失效等级 判断是否存在出现危害度较大的1级和2级失效的可能性。如果这种可
能性存在,则应进行故障树分析,标识出所有可能造成严重失效的功能需求和其相关的输入域
。
(3)确定概率分布
·确定各种不同运行方式的发生概率,判断是否需要对不同的运行方式进行分别测试。
如果需要,则应给出各种运行方式下各数据域的概率分布;否则,给出各数据域的概率分布。
·判断是否需要强化测试某些功能。
(4)整理概率分布的信息 将这些信息编码送入数据库。

2.制订测试计划
本阶段的目标是:
(1)根据前一阶段整理的概率分布信息生成相对应的测试实例集,并计算出每一测试实例
预期的软件输出结果。
本阶段需要注意:在按概率分布随机选择生成测试实例的同时,要保证测试的覆盖面。
(2)编写测试计划,确定测试顺序,分配测试资源。由于本阶段前一部分的工作需要考虑
大量的信息和数据,因此需要一个软件支持工具,建立数据库,并产生测试实例。另外,有时预
测软件输出结果也需要大量的计算,有些复杂的软件甚至要用到仿真器模拟输出结果。
总之,具体实施与被测应用软件的实际功能类型有关。

3.测试
本阶段进行软件测试。需注意的是被测软件的测试环境(包括硬件配置和软件支撑环境
)应和预期的实际使用环境尽可能一致,对某些环境要求比较严格的软件(如嵌入式软件)则应
完全一致。
测试时按测试计划和顺序对每一个测试实例进行测试,判断软件输出是否符合预期结果
。测试时应记录测试结果、运行时间和判断结果。如果软件失效,那么还应记录失效现象和
时间,以备以后核对。

4.编写测试报告
按软件可靠性估计的要求整理测试记录,并将结果写成报告。
笔者认为,软件可靠性测试的关键在于:
·对需求、输入、数据域的识别及相关概率分布的确定。
·按照概率分布随机生成测试实例,并确定测试顺序。
据国外有关文献报导,这种测试方法已成功应用于大量应用软件的可靠性测试,包括一些
商用软件和航空、航天电子设备中嵌入式软件的测试,其效果很好。因此,我们有必要投入一
定的人力、物力,针对我们的实际需要,有目的地对各类应用软件进行软件可靠性测试,从实
践中逐步积累经验。同时需要软件开发方和使用方共同合作,进行软件可靠性测试方法的研
究和有关支持工具的开发,促进我国软件可靠性水平的提高。

（计算机世界报 1997年 第16期）

单元/集成测试通过标准

⑴：各基类和存储过程的正常值测试全部通过；

⑵：联调测试各接口没有问题；

⑶：各基类和存储过程的异常值测试通过率达85%以上；

系统测试通过标准

(1)基本流程能够通畅的完成，核心功能可以体现；（不存在A，B级BUG）

(2)对具备分支的流程，确保有一种分支可以持续使用，另外几种要求可以体现设置方法和直接效果，否则就应暂时屏蔽分支功能；

(3)基本界面符合术语规范，不存在错误或明显歧义；所有可使用的流程中的界面设计工作必须完成；

(4)按照标准流程没有出现各种非正常提示；

(5)关键流程和流程中的基本数据备份恢复没有问题；

(6)所有报表能够在基本数据的基础上正确生成；

(7)非A，B级BUG的遗留数不能超过总用例数的5%

一、单元测试用例的类型：

• 　需求测试用例：测试是否符合需求规范
• 　设计测试用例：测试是否符合系统逻辑结构
• 　代码测试用例：测试代码的逻辑结构和使用的数据

需求测试用例通常是按照需求执行的功能逐条地编写输入数据和期望输出。一个好的需求用例是可以用少量的测试用例就能够覆盖所有的程序功能。

设计测试用例检测的是代码和设计是否完全相符。是对底层设计和基本结构上的测试。设计测试用例可以涉及到需求测试用例没有覆盖到的代码空间（例如界面的设计）。

代码测试用例是基于运行软件和数据结构上的。它要保证可以覆盖所有的程序分支、最小的语句和输出。

二、测试数据的种类：

•  正常数据：在测试中所用的正常数据的量是最大的，而且也是最关键的。少量的测试数据不能完全覆盖需求，但我们要从中提取出一些具有高度代表性的数据作为测试数据，以减少测试时间。
• 边缘数据：边缘测试是界于正常数据和错误数据之间的一种数据。它可以针对某一种编程语言、编程环境或特定的数据库而专门设定。例如若使用SQL Server数据库，则可把SQL Server关键字（如：';AS;Join等）设为边缘数据。其它边缘数据还有：HTML的HTML;<>等关键字以及空格、@、负数、超长字符等。边缘数据要靠测试人员的丰富经验来制定。
• 错误数据：显而易见，错误数据就是编写与程序输入规范不符的数据从而检测输入筛选、错误处理等程序的分支。

3、单元测试代码评审的检查点

•  代码风格和规则审核
•  程序设计和结构的审核
•  业务逻辑的审核

代码风格和规则的审核是在每个程序员完成一个模块或类的时候要进行编码规范的检查。

程序设计和结构的审核，对于不同的程序员所检测代码的宽度和深度也是不同的。项目经理可以根据程序员经验的不同制定被审议人员的宽度和深度。例如：年轻的程序员要审议所有代码。但有经验的就可适当减少。

业务逻辑性审议必须要在代码完成后审议。业务逻辑审议实际上是审议单元模块的功能。这些功能是以系统说明为依据的。审议人员要有开发的经验并且对系统也要熟悉。审议人员通过执行程序从而了解底层代码的状态。这阶段的审议实际也包含了前两种审议，因为审议者也可以通过最后的结果检测单元模块设计和结构的准确性。

4、代码的调试：

代码的调试是用来保证程序能按照系统需求正常运行的一种手段。但是我所提到的这种代码调试并不是简单的调试，它要包括以下两部分：

• 特征调试
• 代码覆盖调试

首先我们要先进行特征调试。它是通过运行程序找到代码中的错误，这与我们平时常进行的调试相同。到程序能运行后，我们可使用已编好的三种类型的用例并以正常数据测试用例进行测试，若不能正常运行则要用调试工具调试。在这阶段，我们要用大量正常数据去测试。测试后，该程序应可在绝大多数的正常数据中运行。

其次，我们要进行代码覆盖测试，一直要达到以下目标为至：

• 测试到每一个最小语句的代码
• 测试到所有的输出结果

我们应该通过一步步的调试去运行每个程序的所有语句和分支。如果我们想要百分之百地覆盖就应适当运用边缘数据和错误数据。测试在这个阶段的质量是难以掌握的。它基于程序员的责任心和经验。当这阶段完成后，每个程序员所测的深度也是不同的。因此，在这个测试阶段之前，项目经理（或测试工程师）应制定出测试指导和计划书。它们至少应包括以下内容：

• 测试的主要对象
• 主要调试点
• 怎样测试
• 什么时候可以完成

本文只为个人查看方便，详细可查看http://www.51testing.com/?action_viewnews_itemid_7578.html

1。要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。

2。测试用例、输入数据及预期输出。

输入数据是测试用例的核心，它是被测试函数所读取的外部数据及这些数据的初始值。外部数据是对于被测试函数来说的，实际上就是除了局部变量以外的其他数据，共分为以下几类：参数、成员变量、全局变量、IO媒体。IO媒体是指文件、数据库或其他储存或传输数据的媒体，例如，被测试函数要从文件或数据库读取数据，那么，文件或数据库中的原始数据也属于输入数据。一个函数无论多复杂，都无非是对这几类数据的读取、计算和写入。

我们应该用一定的规则选择有代表性的数据作为输入数据，主要有三种：正常输入，边界输入，非法输入，每种输入还可以分类，也就是平常说的等价类法，每类取一个数据作为输入数据，如果测试通过，可以肯定同类的其他输入也是可以通过的。下面举例说明：
　　正常输入
　　例如字符串的Trim函数，功能是将字符串前后的空格去除，那么正常的输入可以有四类：前面有空格；后面有空格；前后均有空格；前后均无空格。
　　边界输入
　　上例中空字符串可以看作是边界输入。
　　再如一个表示年龄的参数，它的有效范围是0-100，那么边界输入有两个：0和100。
　　非法输入
　　非法输入是正常取值范围以外的数据，或使代码不能完成正常功能的输入，如上例中表示年龄的参数，小于0或大于100都是非法输入，再如一个进行文件操作的函数，非法输入有这么几类：文件不存在；目录不存在；文件正在被其他程序打开；权限错误。
　　如果函数使用了外部数据，则正常输入是肯定会有的，而边界输入和非法输入不是所有函数都有。一般情况下，即使没有设计文档，考虑以上三种输入也可以找出函数的基本功能点。实际上，单元测试与代码编写是“一体两面”的关系，编码时对上述三种输入都是必须考虑的，否则代码的健壮性就会成问题。
3。白盒测试针对程序的逻辑结构设计测试用例，用逻辑覆盖率来衡量测试的完整性。逻辑单位主要有：语句、分支、条件、条件值、条件值组合，路径。

经验：发现与条件直接有关的错误主要是逻辑操作符错误，例如：||写成&&，漏了写!什么的，采用分支覆盖与条件覆盖的组合，基本上可以发现这些错误，另一方面，条件值覆盖与条件值组合覆盖往往需要大量的测试用例，因此看来，条件值覆盖和条件值组合覆盖的效费比偏低。本人认为效费比较高且完整性也足够的测试要求是这样的：完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖。实际就是通过使用工具实现，否则人工难以完成，工作量太在。

白盒测试用例的设计，普通方法是画出程序的逻辑结构图如程序流程图或控制流图，根据逻辑结构图设计测试用例，这些是纯粹的白盒测试，推荐一类方法：先完成黑盒测试，然后统计白盒覆盖率，针对未覆盖的逻辑单位设计测试用例覆盖它，例如，先检查是否有语句未覆盖，有的话设计测试用例覆盖它，然后用同样方法完成条件覆盖、分支覆盖和路径覆盖，这样的话，既检验了黑盒测试的完整性，又避免了重复的工作，用较少的时间成本达到非常高的测试完整性。不过，这些工作可不是手工能完成的，必须借助于工具，后面会介绍可以完成这些工作的测试工具。
4。单元测试工具：针对c/c++

最后介绍Visual Unit，简称VU，这是国产的单元测试工具，据说申请了多项专利，拥有一批创新的技术，如［自动生成测试代码 快速建立功能测试用例 程序行为一目了然 极高的测试完整性 高效完成白盒覆盖 快速排错 高效调试 详尽的测试报告］。［］内的文字是VU开发商的网页上摘录的，网址是：http://www.unitware.cn。前面所述测试要求：完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖，用VU可以轻松实现，还有一点值得一提：使用VU还能提高编码的效率，总体来说，在完成单元测试的同时，编码调试的时间还能大幅度缩短。工具好不好用，合不合用，要试过才知道，还是自己去开发商的网站看吧，可以下载演示版，还有演示课件。

备注：本篇是个人剪裁过的，为了个人阅读方便，详细可查看

http://www.51testing.com/?action_viewnews_itemid_7430.html

 

今天在论坛看到一篇有关单元测试文章，里面一段话：单元测试，针对业务功能进行测试，而业务功能的测试难点，就是模态窗体的测试。这个难点的罪魁祸首是Windows的消息机制决定的。每一个模态窗体都有自己的消息循环（死循环）在处理消息，当从一个模态窗体切换到另一个模态窗体的时候，测试代码就不能继续下去。针对这个问题的处理方式，就是“解铃还须系铃人”。通过Windows的消息循环就可以穿透这种切换的休克。当然了，处理方式还是比较复杂的。

具体做法是什么呢？期待以后能够用一个实例来解答这个问题。如果游园的朋友知道，分享一下，谢谢！

一、数据引用错误。
　定义：是指使用未经正确初始化用法和引用方式的变量、常量、数组、字符串或记录而导致的软件缺陷。
是否引用了未初始化的变量？查找遗漏之处与查找错误同等重要。
数组和字符串的下标是整数值吗？下标总是在数组和字符串大小范围之内吗？
在检索操作或者应用数组下标时是否包含“丢掉一个”这样的潜在错误？
是否在应该使用常量的地方使用了变量－例如在检查数组范围时？
变量是否被赋予不同类型的值？例如，无意中使代码为整形变量赋予一个浮点数值？
为引用的指针分配内存了吗？
一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？
二、数据声明错误。
产生的原因：不正确地声明或使用变量和常量
所有变量都赋予正确的长度、类型和存储类了吗？例如，本应声明为字符串的变量声明为字符数组了吗？
变量是否在声明的同时进行了初始化？是否正确初始化并与其类型一致？
变量有类似的名称吗？这基本上不算软件缺陷，但有可能是程序中其他地方出现名称混淆的信息。
存在声明过、但从未引用或者只引用过一次的变量吗？
在特定模块中所有变量都显式声明了吗？如果没有，是否可以理解为该变量与更高级别的模块共享？
三、计算错误。
是基本的数据逻辑问题，计算无法得到预期结果。
计算中是否使用了不同数据类型的变量，例如将整数与浮点数相加？
计算中是否使用了不同数据类型相同但不同长度的变量－例如，将字节与字相加?
计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？
赋值的目的变量是否小于赋值表达式的值？
在数值计算过程中是否可能出现溢出？
除数/模是否可能为零？
对于整型算术运算，某些计算，特别是除法的代码处理是否会丢失精度？
变量的值是否超过有意义的范围？例如，可能性的计算结果是否小于0%或者大于100%？
对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级对吗？需要加括号使其清晰吗？
四、比较错误。
小于、大于、等于、不等于、真、假。比较和判断错误很可能是边界条件问题。
比较得正确吗？虽然听起来简单，但是比较应该是小于还是小于或等于常常发生混淆。
存在分数或者浮点值之间的比较吗？如果有，精度问题会影响比较吗？1.00000001和1.00000002极其接近，它们相等吗？
每一个逻辑表达式都正确表达了吗？逻辑计算如期进行了吗？求值次序有疑问吗？
逻辑表达式的操作数是逻辑值吗？例如，是否包含整数值的整型变量用于逻辑计算中？
五、控制流程错误。
原因：编程语言中循环等控制结构未按预期方式工作。它们通常由计算或者比较错误直接或间接造成。
如果程序包含begin..end和do...while等语句组，end是否对应？
程序、模块、子程序和循环能否终止？如果不能，可以接受吗？
可能存在永远不停的循环吗？
循环可能从不执行吗？如果是这样，可以接受吗？
如果程序包含像switch...case语句这样的多个分支，索引变量能超出可能的分支数目吗？如果超出，该情况能正确处理吗？
是否存在“丢掉一个”错误，导致意外进入循环？
六、子程序参数错误。
来源于软件子程序不正确地传递数据。
子程序接收的参数类型和大小与调用代码发送的匹配吗？次序正确吗？
如果子程序有多个入口点，引用的参数是否与当前入口点没有关联？
常量是否当作形参传递，意外在子程序中改动？
子程序是更改了仅作为输入值的参数？
每一个参数的单位是否与相应的形参匹配。
如果存在全局变量，在所有引用子程序中是否有相似的定义和属性？
七、输入/输出错误。
包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。
软件是否严格遵守外部设备读写数据的专用格式？
文件或者外设不存在或者未准备好的错误情况有处理吗？
软件是否处理外部设备未连接、不可用，或者读写过程中存储空间占满等情况？
软件以预期方式处理预计的错误吗？
检查错误提示信息的准确性、正确性、语法或拼写了吗？
八、其他检查。
软件是否使用其他外语？是否处理扩展ASCII字符？是否需要用统一编码取代ASCII？
软件是否要移植到其他编译器和CPU，具有这样做的许可吗？如果没有计划或者测试，那么，移植性可能成为一个大难题。
是否考虑了兼容性，以使软件能够运行于不同数量的可用内存，不同的内部硬件，例如图形卡和显卡，不同的外设，例如打印机和调制解调器？
程序编译是否产生“警告”或者“提示”信息？这些信息通常指示进行了有疑问的处理。纯粹主义者可能认为警告信息是不可接受的。

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

　对白盒测试新的理解如下：

1.在进行白盒测试之前是需要先设计黑盒测试案例，从整体功能上去把握每一个模块功能，避免只是检查代码，走入程序员的思路范围，而忽略对功能的整体把握。

2.通过了解代码的细节，可消除冗余的测试用例，增加针对原先没有考虑到的区间的测试用例。

3.查看代码，把软件分为数据和状态（程序流程），以黑盒测试用例的角度看待软件，把得到的白盒信息映射到已写完的黑盒测试案例上。

• 　　数据流：观察变量，运行时的即时值（黑盒主要关注开始值和结束值）
• 　　次边界：有些边界在软件的内部，最终用户几乎看不到，这样的边界条件称为次边界或内部边界条件，如临近字节边界的254,255,256.ASCII码表中A~Z,a~z之外的非法区间，如@,[,{,'
•  　错误强制：强制为变量赋值。不要设立现实世界中不可能出现的情况，如程序员在函数开头检查n值必须大于零，而n值仅用于该公式中，那么将n值设为零，使程序失败的测试用例就是非法的。
• 　公式和等式：例如分母不能为零，考虑有没有类似的情形，什么样的程序输入会导致它出现。
• 　代码范围：语句覆盖等的分析，单步执行查看（调用堆栈对话框查看）；每条语句至少执行一次，路径、分支等的覆盖

技术的提升是永无止境的，要想成为一个优秀的测试人员，在掌握技术的同时，也需要在不断实践中，在恰当的时机中，来合理地运用这些基本技术。