ThreadingTest（穿线测试）引领白盒测试进入工业界(一）
是面向功能的测试，测试用例的依据是软件的需求，测试的对象是运行起来的软件。通常情况下，一个有经验的测试工程师根据需求说明书编写的测试用例在执行完成后，覆盖率一般能达到70%左右，需要N个工作日。要达到覆盖率的最终目标100%，还需要增加新的测试用例。有过覆盖率测试经验的朋友知道，剩下的30%可能需要 N* 3 工作日，甚至更多，同时为了达到更高的覆盖率，通常会产生大量重复的测试用例，大大增加的测试成本。下图为黑盒测试的覆盖率及成本使用效果图：http://img.blog.csdn.net/20141017150835813?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGhyZWFkaW5ndGVzdDIwMTQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast2白盒测试 和黑盒测试正相反，白盒测试的测试用例的依据就是软件代码。测试工程师需要依据代码的逻辑结构、基本路径的分析，得到测试用例。因为该方法直接面向代码，写出的测试用例非常有针对性，每执行一个用例，覆盖率指标都能有新的提高，最终达到终极目标。听起来很不错，其实还有一个很大的问题，就是测试工程师需要分析所有代码的逻辑结构、调用关系、数据流等，仅此一项，就需要花费巨额的时间。另外传统单元级白盒测试仅仅关注程序覆盖方面，并不管程序单元组合和集成后的系统级功能。下图为白盒测试的覆盖率及成本使用效果图：http://img.blog.csdn.net/20141017150621687?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGhyZWFkaW5ndGVzdDIwMTQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast结合上述2种方法，ThreadingTest提出了全新的理念即穿线测试（TheadingTest)，它采用了白盒和黑盒相结合的方法，以黑盒的测试方法，来得到白盒的测试数据。结合的优势：3穿线测试 既然上述讲到黑盒和白盒各有优劣，所以不如采用二者相结合的方法。穿线测试实际上属于创新型的系统级白盒测试工具，是软件测试领域里面全新的学术流派。它先通过传统黑盒测试把基本的功能都测试一轮，覆盖率达到70%，同时这个过程受到穿线测试工具的监控，并获取该阶段的测试结果数据；第二步，通过穿线测试得到的白盒结果，快速定位剩下30%的代码，进行针对性地增加测试用例，最终达到终极目标。经过很多客户的实践经验，这种方法对于覆盖率测试是最有效的，且测试时间最短。http://img.blog.csdn.net/20141017151049771?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGhyZWFkaW5ndGVzdDIwMTQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast说到这，很多测试人员肯定对穿线测试有浓厚的兴趣了，那我们接下来用故事来说明传统的白盒测试对测试人员的要求划分，以及穿线测试在这方面的应对策略：一个关于代码覆盖率故事一大早，一个年轻的程序员问大师：“我准备写一些单元测试用例。代码覆盖率应该达到多少为好？”大师回答道:“不要考虑代码覆盖率，只要写出一些好的测试用例即可。”年轻的程序员很高兴，鞠躬，离去。之后没多久，第二个程序员问了大师同样的问题。大师指着一锅烧沸的水说：“我应该往这个锅里放多少米？”这个程序员看起来被难住了，回答道：“我怎么会有答案？这取决于要给多少人吃，他们饿不饿，有什么菜，你有多少米，等等。”“完全正确，” 大师说。第二个程序员很高兴，鞠躬，离去。末了，来了第三个程序员问了大师同样的关于代码覆盖率的问题。“百分之八十，不能少！” 大师一拳锤在桌子上，用严厉的口气回答道。第三个程序员很高兴，鞠躬，离去。一个关于代码覆盖率故事－解读回复完这个之后，一个年轻的实习生走到大师身边：“大师，今天我无意中听到了你对同一个代码覆盖率问题给出了三个不同的答案。为什么？”大师从椅子上站起来：“给我泡点新茶，我们聊聊这个。”当杯子里倒满了冒着热气的绿茶后，大师开始说：“这第一个程序员是个新手，刚刚开始学测试。目前他有大量的程序都没有测试用例。他有很长的路要走；现在对他要求代码覆盖率只会打击他，没有什么用处。最好是让他慢慢的学会写一些测试用例，测试一下。他可以以后再考虑代码覆盖率。”“而这第二个程序员，不论对编程还是测试都是十分的有经验。我以问作答，问她应该往锅里放多少米，使她明白决定测试用例多少的因素有很多，她比我更知道这些因素——毕竟是她自己的代码。对这个问题没有一个简单的、直接的答案。以她的聪明完全能明白这个道理，正确的完成任务。”“我明白了，” 年轻的实习生说， “但是如果没有一个简单直接的答案，那你为什么告诉第三个程序员‘百分之八十，不能少’呢？”大师笑的前仰后合，绿茶都喷了出来。“这第三个程序员只想得到一个简单的答案——即使根本没有简单的答案 … 而且即使有答案她也不会按答案做。”年轻的实习生和头发斑白的大师在沉思中喝完茶。从上述故事我们可以发现：第一个新手测试人员要进行覆盖率测试时，需要培养很长一段时间。第二个有经验的测试人员在覆盖率测试时，需要对编程和测试以及被测程序的整体都要十分熟悉。第三个说明测试人员在进行覆盖率测试时，覆盖率指标是有明确要求的。但在实际操作过程中，国内因白盒测试人员的稀缺，培养周期长、昂贵以及测试进度的要求等问题导致其发展缓慢。针对白盒这种情况，穿线测试得提出全新的解决思路。上文提到了穿线测试通过原有的黑盒测试方式，得到白盒结果，这样使得测试难度以及测试人员的能力要求大大降低，并在这个基础上，为了使得白盒测试结果更加方便理解，穿线测试又相继提出了可视化的代码覆盖率，以简单的图形显示，让广大不懂代码和程序内部结构的黑盒测试人员也能进行大师级别的代码覆盖率测试。
沙发:D 支持，很好的介绍方法。 希望这种介绍方法，能让大家更容易理解软件测试特别是针对白盒测试的覆盖率问题 期待最佳实践的案例。。。 你说的这只是概念，如何实施呢，实时收集第一轮的代码覆盖率么？ 学习了，谢谢分享！
页:
[1]
