ThreadingTest（线程测试）领先的白框进入这个行业

测试一直是黑色的，白点。在一般情况下，因为白盒测试需要逻辑思维能力是比较高的技术要求比一般开发商的项目经验和谨慎甚至更高，和较长的测试时间，用于单元测试，昂贵的工具，因此，国内企业普遍忽视白盒测试。这就是为什么自成立以来的白盒测试。国内没有正式推广的原因。

对于一个健康的測试团队来讲，必需要有一个或多个熟悉白盒測试的人员。让我们先分析下，普通情况下，要实施覆盖率測试。有几种全然不同的策略。

1 黑盒測试（功能測试）

黑盒測试是面向功能的測试。測试用例的根据是软件的需求，測试的对象是执行起来的软件。

通常情况下。一个有经验的測试project师根据需求说明书编写的測试用例在执行完毕后。覆盖率一般能达到70%左右。须要N个工作日。要达到覆盖率的终于目标100%，还须要添加新的測试用例。有过覆盖率測试经验的朋友知道，剩下的30%可能须要 N* 3 工作日，甚至很多其它。同一时候为了达到更高的覆盖率。一般会产生大量反复的測试用例，大大添加的測试成本。

下图为黑盒測试的覆盖率及成本使用效果图：

2  白盒測试

和黑盒測试正相反，白盒測试的測试用例的根据就是软件代码。測试project师须要根据代码的逻辑结构、基本路径的分析。得到測试用例。由于该方法直接面向代码。写出的測试用例非常有针对性，每运行一个用例，覆盖率指标都能有新的提高，终于达到终极目标。听起来非常不错，事实上另一个非常大的问题，就是測试project师须要分析全部代码的逻辑结构、调用关系、数据流等。仅此一项。就须要花费巨额的时间。

另外传统单元级白盒測试只关注程序覆盖方面，并无论程序单元组合和集成后的系统级功能。下图为白盒測试的覆盖率及成本使用效果图：

结合上述2种方法，ThreadingTest提出了全新的理念即穿线測试（TheadingTest)。它採用了白盒和黑盒相结合的方法，以黑盒的測试方法，来得到白盒的測试数据。结合的优势：

3  穿线測试

　　既然上述讲到黑盒和白盒各有优劣，所以不如採用二者相结合的方法。穿线測试实际上属于创新型的系统级白盒測试工具。是软件測试领域里面全新的学术流派。它先通过传统黑盒測试把主要的功能都測试一轮。覆盖率达到70%，同一时候这个过程受到穿线測试工具的监控，并获取该阶段的測试结果数据；第二步，通过穿线測试得到的白盒结果。高速定位剩下30%的代码，进行针对性地添加測试用例。终于达到终极目标。经过非常多客户的实践经验。这样的方法对于覆盖率測试是最有效的。且測试时间最短。

讲到这，非常多測试人员肯定对穿线測试有浓厚的兴趣了。那我们接下来用故事来说明传统的白盒測试对測试人员的要求划分，以及穿线測试在这方面的应对策略：

一个关于代码覆盖率故事

一大早，一个年轻的程序猿问大师：“我准备写一些单元測试用例。代码覆盖率应该达到多少为好？”

大师回答道:“不要考虑代码覆盖率，仅仅要写出一些好的測试用例就可以。”

年轻的程序猿非常高兴，鞠躬，离去。

之后没多久，第二个程序猿问了大师相同的问题。

大师指着一锅烧沸的水说：“我应该往这个锅里放多少米？”

这个程序猿看起来被难住了。回答道：“我怎么会有答案？这取决于要给多少人吃。他们饿不饿。有什么菜。你有多少米，等等。”

“全然正确。” 大师说。

第二个程序猿非常高兴，鞠躬，离去。

末了，来了第三个程序猿问了大师相同的关于代码覆盖率的问题。

“百分之八十，不能少。” 大师一拳锤在桌子上，用严厉的口气回答道。

第三个程序猿非常高兴。鞠躬，离去。

一个关于代码覆盖率故事－解读

回复完这个之后，一个年轻的实习生走到大师身边：

“大师。今天我无意中听到了你对同一个代码覆盖率问题给出了三个不同的答案。为什么？”

大师从椅子上站起来：“给我泡点新茶，我们聊聊这个。”

当杯子里倒满了冒着热气的绿茶后。大师開始说：

“这第一个程序猿是个新手。刚刚開始学測试。

眼下他有大量的程序都没有測试用例。

他有非常长的路要走；如今对他要求代码覆盖率仅仅会打击他。没有什么用处。最好是让他慢慢的学会写一些測试用例，測试一下。他能够以后再考虑代码覆盖率。”

“而这第二个程序猿。不论对编程还是測试都是十分的有经验。

我以问作答。问她应该往锅里放多少米。使她明确决定測试用例多少的因素有非常多，她比我更知道这些因素——毕竟是她自己的代码。对这个问题没有一个简单的、直接的答案。以她的聪明全然能明确这个道理，正确的完毕任务。”

“我明确了。” 年轻的实习生说。 “可是假设没有一个简单直接的答案，那你为什么告诉第三个程序猿‘百分之八十，不能少’呢？”

大师笑的前仰后合，绿茶都喷了出来。

“这第三个程序猿仅仅想得到一个简单的答案——即使根本没有简单的答案 … 并且即使有答案她也不会按答案做。

”

年轻的实习生和头发斑白的大师在沉思中喝完茶。

从上述故事我们能够发现：

第一个新手測试人员要进行覆盖率測试时，须要培养非常长一段时间。

第二个有经验的測试人员在覆盖率測试时，须要对编程和測试以及被測程序的总体都要十分熟悉。

第三个说明測试人员在进行覆盖率測试时，覆盖率指标是有明白要求的。

但在实际操作过程中，国内因白盒測试人员的稀缺。培养周期长、昂贵以及測试进度的要求等问题导致其发展缓慢。

针对白盒这样的情况，穿线測试得提出全新的解决思路。

上文提到了穿线測试通过原有的黑盒測试方式，得到白盒结果，这样使得測试难度以及測试人员的能力要求大大减少，并在这个基础上。为了使得白盒測试结果更加方便理解，穿线測试又相继提出了可视化的代码覆盖率。以简单的图形显示，让广大不懂代码和程序内部结构的黑盒測试人员也能进行大师级别的代码覆盖率測试。

例：下图看到的截图为以穿线測试为理论，产品化的工具ThreadingTest中的截图：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGhyZWFkaW5ndGVzdDIwMTQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">

图中覆盖率ＳＣ０解释说明：

【 段 】

在二个连续的分支点之间的计算机程序语句序列被叫作段。

【可视段】

在一个控制层之内最大可能的非-条件语句序列被称为可视段。在二节点之间可视段的长度可能是零(没有可运行语句)。

SC0

基本段測试覆盖度量也称为块測试覆盖。假设程序的全部可见段(程序块)至少被运行一次，则该段程序的SC0覆盖率达到了100%。

SC0= 被运行的块个数/该段程序包括的块个数(就可以见段个数)

在图中。我们清晰地看到该函数的覆盖率ＳＣ０，是怎样被计算出。且显示出相关的代码，通过这样的方式展示，能够使广大没有接触过代码的測试人员，通过黑盒的測是方式，找出覆盖率中代码的没有覆盖到的部分，进行測试用例的补充，从而提升測试用例的制作，以及提高測试质量。

在ThreadingTest中，还有关于其他覆盖率的划分说明，如TRUE（真条件的百分比）、BOTH（条件真假的覆盖率百分比）、Branch(分支覆盖率)、MC/DC等。

请关注官方技术站点www.threadingtest.com中的覆盖率分析，有具体地解释说明和计算。

測试覆盖率作用

測试覆盖率是測试结束标准中的一部分

測试覆盖率低的模块 和 重要模块的測试覆盖率。这些数据能够帮助我们高速定位须要很多其它測试的模块，能够帮助我们了解重要模块的測试情况。以此来衡量我们測试用例的质量乃至測试的质量。

在螺旋式开发模式中，假设我们没有控制好我们上一个迭代中的測试覆盖率，当一个版本号

一个版本号累加下来后，你就非常难确定我们哪些模块在开发过程中没有给予足够的測试。

通过覆盖率，制定下阶段有效的測试计划

下图为測试覆盖率的报告

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGhyZWFkaW5ndGVzdDIwMTQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">

通过上图的覆盖率展示，我们能够进行下一步測试的总体方向计划。

检查未使用的功能

检查前10个的最低覆盖率

測试用例的加强

穿线測试覆盖率与验证阶段

验证阶段能够分为单元验证（UT）阶段、集成验证（IT）阶段和系统验证（ST）阶段。

单元验证阶段，关心的是模块功能和模块质量。此时出口条件为代码覆盖率。一般业内经常使用的出口条件是：行覆盖率达到100％，分支覆盖率达到100％，条件覆盖率达到95％。对没有覆盖率的需给出合理的说明。

集成验证阶段。关心的系统的功能，以及模块与模块之间的接口，此时出口条件为功能覆盖率。

一般业内经常使用的出口条件是：功能覆盖率达到90％，对没有覆盖率的需给出合理的说明。

•      功能覆盖率高、代码覆盖率低：

验证计划不充分，须要添加功能覆盖点。

•        代码覆盖率高、功能覆盖率低：

设计没有实现指定的功能。

穿线应对測试覆盖率。达到最佳实践

传统的白盒測试

路径覆盖率 > 条件覆盖 > 判定覆盖 > 语句覆盖

測试覆盖率100%是一个理想的情况，是非常难达到的

測试覆盖率100%不能说明我们做了全然的測试

測试覆盖率达到多少要考虑到软件总体的覆盖率情况，以及项目成本，包含人力，时间等等。

因以上因素，所以传统的白盒測试都不建议公司特意的去满足覆盖率測试指标，为了測试而測试。

穿线測试对于传统的白盒測试结果进行了測试数据统一管理。实现各阶段累计。缩短重复測试的时间。从而保证了測试100%覆盖率高质量化。

从原有的測试来看。正常測试中单元測试阶段、集成測试阶段以及系统測试阶段的測试数据是相互分开的，可是在实际过程中，单元測试的充分程度程度，对后期的集成測试、系统測试等都起到了关联作用，在这部分中穿线測试使用了累计覆盖率的技术，把整个測试的各个阶段的測试结果进行沿用和累计，这样使得整个測试迭代起到了量化关联的作用。能够随时对各阶段的測试进行分析和改善。

相比于传统的单元级的白盒測试，穿线測试还提出了分布測试方法，对于中大型软件或站点来说，单个測试人员是不可以完毕整个測试任务的，为了更好的相互配合。ThreadingTest採用了分布式測试设计，在測试过程中，測试人员可以在不同地点，同一时候对某个程序或站点的不同模块进行測试，測试结果在不相互干扰的情况下汇总到中央server，这样使得每天每一个人的測试数据结果有了统一的管理，从而对整个測试进度进行了有效的量化管理。

穿线測试的出现对測试界的改革

商用測试工具产品ThreadingTest把穿线理念进行了实际的产品化，通过工具的方式。让黑盒測试人员也能进行代码级别的白盒測试，并对整个測试各阶段的流程进行了量化的管理，通过黑盒測试来实现白盒结果的展示。完毕了測试界中最有效的70%黑盒+30%白盒相结合的測试方法。

穿线測试打破了传统白盒測试操作难度高，过于追求覆盖率等方式，通过黑盒与白盒的结合，使各阶段的測试人员，都能正确依照自己的需求进行測试，从而避免了盲目性、重复性、遗漏性等问题。

版权声明：本文博客原创文章。博客，未经同意，不得转载。