测试新手求助。JAVA程序白盒测试。
小弟从事软件测试行业近2年。主要负责功能及性能测试方面的黑盒测试。现需接手公司内JAVA白盒测试。但当时培训机构并未详细培训白盒测试方面的技术。个人JAVA水平很有限，求助！小弟自我感觉测试理论基础掌握较为扎实，但是由于从未从事过白盒测试，JAVA编程水平也仅仅停留在大学时代的水平（编写程序最长不超过200行代码），JAVA编程最多可以算入门水平。
公司主要开发政府机构软件。以B/S架构为主。主要开发语言JAVA。希望各位同行高手们能帮我介绍一本JAVA白盒测试的书籍。或者能尽快熟悉了解JAVA编程的书籍。感激不尽！
白盒测试的覆盖测试
白盒测试的六种覆盖摘要：白盒测试作为测试人员常用的一种测试方法，越来越受到测试工程师的重视。白盒测试并不是简单的按照代码设计用例，而是需要根据不同的测试需求，结合不同的测试对象，使用适合的方法进行测试。因为对于不同复杂度的代码逻辑，可以衍生出许多种执行路径，只有适当的测试方法，才能帮助我们从代码的迷雾森林中找到正确的方向。本文介绍六种白盒子测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。白盒测试的概述
由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我们经常相信某逻辑路径不可能被执行, 而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的，因此我们要进行白盒测试。
白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。
白盒的测试用例需要做到：
•保证一个模块中的所有独立路径至少 被使用一次
•对所有逻辑值均需测试 true 和 false
•在上下边界及可操作范围内运行所有循环
•检查内部数据结构以确保其有效性
白盒测试的目的：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
白盒测试的特点：依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。
白盒测试的实施步骤：
1.测试计划阶段：根据需求说明书，制定测试进度。
2.测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。
3.测试执行阶段：输入测试用例，得到测试结果。
4.测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。
白盒测试的方法：总体上分为静态方法和动态方法两大类。
静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后,对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。
白盒测试的优缺点
1. 优点
•迫使测试人员去仔细思考软件的实现
•可以检测代码中的每条分支和路径
•揭示隐藏在代码中的错误
•对代码的测试比较彻底
•最优化
2. 缺点
•昂贵
•无法检测代码中遗漏的路径和数据敏感性错误
•不验证规格的正确性
六种覆盖方法
首先为了下文的举例描述方便，这里先给出一张程序流程图。（本文以1995年软件设计师考试的一道考试题目为例，图中红色字母代表程序执行路径）。
1、语句覆盖
1）主要特点：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
2）用例设计：（如果此时将A路径上的语句1—〉T去掉，那么用例如下）
XY路径
15050OBDE
29070OBCE
3）优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。
4）缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。在本例中去掉了语句1—〉T去掉，那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支，那么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行，而往往这种错误会经常出现。再如，在Do-While结构中，语句覆盖执行其中某一个条件分支。那么显然，语句覆盖对于多分支的逻辑运算是无法全面反映的，它只在乎运行一次，而不考虑其他情况。
2、判定覆盖
1）主要特点：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。
2）用例设计：
XY路径
19090OAE
25050OBDE
39070OBCE
3）优点：判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
4）缺点：往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
3、条件覆盖 1）主要特点：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
2）用例设计：
XY路径
19070OBC
240
OBD
3）优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。
4）缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
4、判定/条件覆盖
1）主要特点：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
2）用例设计：
XY路径
19090OAE
25050OBDE
39070OBCE
47090OBCE
3）优点：判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。
4）缺点：判定/条件覆盖准则的缺点是未考虑条件的组合情况。
5、组合覆盖
1）主要特点：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
2）用例设计：
XY路径
19090OAE
29070OBCE
39030OBDE
47090OBCE
53090OBDE
67070OBDE
75050OBDE
3）优点：多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。
4）缺点：线性地增加了测试用例的数量。
6、路径覆盖
1）主要特点：设计足够的测试用例，覆盖程序中所有可能的路径。
2）用例设计：
XY路径
19090OAE
25050OBDE
39070OBCE
47090OBCE
3）优点：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。
4）缺点：由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，如：
If（!A）B++；
If（!A）D--；
这两个语句实际只包括了2条执行路径，即A为真或假时候对B和D的处理，真或假不可能都存在，而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。
总结
白盒测试是一种被广泛使用的逻辑测试方法，是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性，尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径，即使穷举也未必会带来好运（穷举不能查出程序逻辑规则错误，不能查出数据相关错误，不能查出程序遗漏的路径）。
那么正确使用白盒测试，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。 ESTCA覆盖（Error Sensitive Test Cases Analysis)
先前的六种测试是从逻辑结构考虑的，其出发点似乎是合理的。所谓“覆盖”，就是想要做到全面、无遗漏。例如，如果把
if( i == 0 ) then i = j
错写成
if( i > 0 ) then i = j
如果使用前面的覆盖测试，就无法发现这个问题。出于这种情况的原因在于，错误边界仅仅在 i = 0 这个点上，测试才能发现错误。这种疏漏恰恰发生在容易发生问题的条件判断场合。因此，要更多地针对容易发生问题的地方设计测试用例。
K.A.Foster从测试工作实践的教训出发，吸收了计算机硬件的测试原理，提出了一种经验型的测试覆盖准则，较好的解决了上述问题。
经验型覆盖准则是从硬件的早期测试方法中得到启发的。在硬件测试中，对每一个门电路的输入、输出测试都是有额定标准的。通常，电路中一个门的错误常常总是“输出总是0”，或是“输出总是1”。与硬件测试这一情况类似，我们应该重视程序中（条件判断）谓词的价值。但实际上它可能比硬件测试更加复杂。Foster通过大量的试验确定了程序中谓词最容易出错的部分，得出了一套错误敏感测试用例分析规则ESTCA（Error Sensitive Test Cases Analysis）。
规则 1对于A real B（rel 可以是 > 或 < ，A是变量，C是常量）型的分支谓词，应适当地选择A与B的值，使得测试执行到该分支语句时，A < B 、A == B 和 A > B 的情况分别出现一次。
规则 2对于A real C ( rel 可以是 > 或 <，A是变量，C是常量)型的分支谓语，当rel为 < 时，应适当地选择A的。使得 A = C - M （M 是距 C最小的容许正数，若A和C均为整型时，M = 1）。同样，当rel为 > 时，应适当地选择A，使得A = C + M 。
规则3对外部输入变量赋值，使其在每一测试用例中均有不同的值和符号，并与同一组测试用例中其他变量值与符号不一致。
显然，上述规则 1 是为了检测rel的错误，规则2是为了检测“差一”之类的错误（例如，本应是“if （A > 1）”而错误写成“if （A > 0）”），规则3则是为了检测程序语句中的错误（例如，应引用一个变量而错误写成引用一个常量）。
上述三条规则并不是完备的，但在程序的测试中却是有效的。原因在于规则本身针对程序员容易发生的需哦无，或是围绕着发生错误的频繁区域，从而提高了发现错误的命中率。
试运用这些规则来检查上面的小程序段错误。应用规则1，对它测试时，应选择 i 的值为 0 ，使 i = 0 的情况出现一次。这样一来就立即找出了隐藏的错误。
当然，ESTCA规则也有很多的缺陷。一个缺陷是，有时不容易找到合适的输入数据，使规则所指的变量值满足要求。另一个缺陷是，仍有很多错误发现不了。
LCSAJ覆盖
LCSAJ覆盖（Linear Code Sequence and Jump Coverage）既是线性代码顺序和跳转覆盖，是Woodward等人提出来的一套覆盖率准则。一个LCSAJ是一组顺序执行的代码，以控制流跳转为其结束点。它的定义如下：
•它起始于程序的入口或者是一个可能导致控制流跳转的点。
•它结束于程序的出口或者是一个可能导致控制流跳转的点。
•对于该点，一个跳转在后面的序列中产生。
它不同于 DDP。DDP是根据程序有向图决定的。一个DDP是指两个判断之间的路径，但其中不再有判断。程序的入口、出口和分支结点都可以是判断点。而LCSAJ的起点是根据程序本身决定的。它的起点是程序第一行或转移语句的入口点，或是控制流可以跳转到达的点。因此，几个LCSAJ首尾相接构成LCSAL串，组成程序的一条路径。第一个LCSAJ起点为程序起点，最后一个LCSAJ终点为程序终点。一条程序路径可能是由两个、三个或多个LCSAJ组成的。基于LCSAJ与路径的这一关系，Woodward提出了LCSAJ覆盖准则，这是一个分层的覆盖准则：
【第一层】：语句覆盖。
【第二层】：分支覆盖。
【第三层】：LCSAJ覆盖。即程序中的每一个LCSAJ都至少在测试中经历过一次。
【第四层】：两两LCSAJ覆盖。即程序中每两个首尾相连的LCSAJ足额起来在测试中都要经历一次。
【第n+2层】：每n个首尾相连的LCSAJ组合在测试中都要经历过一次。
这说明了，越是高层的覆盖准则越难满足。在实施测试时，若要实现上述的Woodward层次LCSAJ覆盖，需要产生被测程序的所有LCSAJ。
尽管LCSAJ覆盖要比判定覆盖复杂的多，但是LCSAJ的自动化相对还是容易获得的。另外，对一个模块的微小的变动可能对LCSAJ产生重大影响，因此维护LCSAJ的测试数据是相当困难的。一个大模块包含极其庞大的LCSAJ，因此要获得100%的覆盖率也是不现实的。然而Woodward等人提供的证据表明，把测试100%的LCSAJ作为目标比100%的判定覆盖要有效的多。
前六个是从网上弄下的，后两个是从书上摘来的！ 出处：http://www.qltesting.cn/thread-1446-1-1.html
前六种的数据有点没弄好。 楼上说的很全面 非常有用！
感激不尽！ 值得看看
谢谢 study... 学习了谢谢 好东西 谢谢了 非常感谢，正是我需要的，谢谢，不过白盒测试是自己写程序覆盖，还是输入不同的值覆盖呢 真是大开眼界，不过也许把事情复杂化了。
Java white box == API testing! 谢谢，我刚刚才开始学习软件测试。 正在学习白盒。。。先顶再实践 我只用junit做过简单的单元测试~~ 并且测试用例什么都没写，直接就是路径覆盖，代码覆盖率倒蛮高的90%以上~~其他一概不懂。。。想学习，但又不知道怎么入门，看测试用列的设计方法倒能轻松看懂~但目前的工作环境根本就没实际应用的地方。。迷惑了 不知道该怎么学习~~ 又黑盒又白黑，你们老板当你全才啊，全才应该去做开发。。 这个好，谢谢楼主分享 好东西 很好，借鉴啦:)
页:
[1]
