平台背景：白盒测试手段可存在于最早期介入的测试阶段，所以发现bug后修复的成本最低，也是能找到代码层面上的bug的不二手段。有些同学会说，那不就是开发自测么？这个说法可完全错误，完整的白盒测试，先不要说自动化测试了，也不说执行，也别说设计用例。就单单理解测试的具体方法就让人觉得非常困难了。
我可以肯定，对于我们绝大多数人，拿出一段简单的代码，让其设计白盒用例，100个人应该一个最终完全正确的都没有。它难就难在，你好不容易理解并运用了 5种逻辑覆盖率的算法，但是最终的用例规程却更难，也就是说，你要用更少的用例去覆盖更多的场景。所以仅掌握5种是不够的，最难的是把5种融会贯通，合一。
比如我随手写的这个简单代码：
def abc(a,b): if a<b or a==0: print a else: print b
看似及其简单的一段代码，设计用例。我这里不专讲白盒，所以就给大家说一点，你设计的用例中，不能只保证路径法 满足if 和 满足else俩种。因为满足if 的情况 有多个。按照不同覆盖率的用例也是不同的。
拿语句覆盖 来举例子：
比如：【a=1 ,b=2】 ，满足if。
但是a==0这段代码并没有运行，所以不完整。
然后增加 【a=2,b=1】,这样a==0这个判断才会运行一次，但是它为假了，也不完整。
然后继续增加 【a=0,b=-1】，这样又是满足if，而且还运行了a==0这段判断。
但是 【a=0,b=1】 这条用例呢？很显然没用，a<b成立了，a==0就干脆没运行，那这个a=0失去了意义。有人说，但是【a=0 b=1】 走了print a这个场景啊。但是别忘了，在我们前面用例，可以用 【a=0,b=-1】 来代替。【a=0,b=-1】这条用例，即可走a<b 又可走 a==0 还可走 print a。这一条就可以 走完这三段语句，所以a=0,b=1就没用。
怎么样 是不是非常绕，别忘了，这还只是语句覆盖，还有其他四种逻辑覆盖，一个比一个难，而且能融汇到一起，用更少的用例 覆盖其他逻辑的场景，这个就更难了。就这么一个简单的if else ，就麻烦成这样，别说那么多复杂到看不下去的一大段一段，一层套一层的高复杂度算法了。就算博主敢拍着胸脯说精通多个测试领域技术，但是也不敢在白盒测试领域装大。可以说白盒测试精通的人的算法水平代码水平是远超一般开发和算法工程师的，全国范围内可能都找不到几个甚至根本不存在。
正是因为白盒难度如此之高，而且大部分时间收效甚微（比如这个一眼就看出没什么问题的if else判断 启动白盒5种覆盖率测试 性价比太低了） 所以我们很少看到公司搞白盒测试，甚至大厂都没有，就算有，也远达不到我上面说的 教科书一样的 程度，大部分都是代码走查，肉眼看一下没问题就行了，这种只是测试对象是代码，手段其实顶多和开发自测差不多，距离白盒测试差的很远。
所以博主在思考这种情况后，决定开发首次的真正白盒自动化测试算法，一开始就拿最擅长的python开刀了。
输入一段代码函数，可以自动生成五种覆盖率的用例。进行了长期的可行性分析和设计后，正式开始打造，最终终于打通了 语句覆盖率的最终技术，这证明博主的幻想成真了，这一切是可以实现的，全世界可能都是头一份，但是巨大的精力消耗和成本，加之公司后台用的并不是python,所以这个实现并没有实际产生收益，最终上层决定封存这套技术，留着以后继续搞。
平台如下：
平台目前已经雪藏，希望以后可以抽出时间重启。毕竟支撑评委csdn测试领域 为数不多的社区专家，就是靠这半套平台的核心设计。
