平民化的白盒--threadingtest灰盒测试技术.docxVIP

“平民”化的白盒— ThreadingTest穿线测试工具 1、软件测试领域30余年的主题----黑盒测试与白盒测试 测试在软件开发的整个生命周期中占据非常重要的地位，这一点从测试所占的时间上可见一斑，我们经常使用的测试方法大体上可分为黑盒测试和白盒测试，这是测试方法中的最典型的代表。 图1 常规软件工程各阶段所占时间比例 黑盒测试又称为功能测试或者数据驱动测试, 是把要测试的软件看成一个 “黑盒子”, 不管其内部结构如何以及以什么算法实现所要求提供的功能，而是按照需求的功能化要求, 设计相应的测试用例(包括测试的输入数据与条件设置和所预期的软件运行输出结果), 通过软件运行后所给出的输出(包括字符形式的输出与图象输出)与所预期的结果进行人工或者自动化比较, 来验证被测试软件是否能给出正确的结果, 从而判断该软件是否满足需求, 是否与该软件系统的规格说明书和用??手册相关部分一致。 白盒测试也称为结构测试或者逻辑驱动测试，它与黑盒测试方法相反: 它不管所被测试的软件是否满足需求,是否实现了所设计的功能, 而只注重该软件内部的结构, 以便设计足够多的测试用例, 使得百分百或者尽可能多的程序组成要素能被测试到最少一次, 从而尽可能地将其中的软件错误暴露出来。测试市场上的白盒测试在测试领域本来就不是非常流行，那是因为传统的白盒测试是需要很高的编程能力，在测试人员中很难流行起来。而TT则对传统的白盒测试过程和方法进行了大规模的创新，甚至不改变传统黑盒测试的方法和过程的基础上，自动产生完整的白盒分析数据。TT采用的方法更接近于测试理论界的灰盒子测试方法，而传统的白盒测试厂商对该理论方法并不理解，纵观全球市场也鲜有相关产品。 2、全新的穿线测试 黑盒测试和白盒测试从概念上来说是比较对立的，黑盒测试得到的结果很难定位到内部结构的所在位置，即功能性的错误不能定位到错误的代码处，只能由开发人员根据错误现象凭经验手工排查和定位；白盒测试的结果也很难跟功能应用直接挂钩，因为不是所有的内部结构都和功能应用有直接的关系。鉴于这些问题，灰盒测试的概念就自然而然的被提出，它介于黑盒与白盒之间，既关注功能的输入输出的正确性测试，也注重内部结构的测试。既包含了黑盒和白盒的优点，又弥补了两者的不足。但灰盒测试在市场上几乎鲜见有商用的测试工具支持，其主要方法仅仅停留在概念阶段，并没有在此基础上上设计可商用的工具和功能。 灰盒测试这个理念要想真正发挥作用，必须使其“平民”化，而将一件复杂的工作简化成一个普通从业者都能完成，通常的做法使用专业的工具，简单的说，要轻松的实现灰盒测试，工具必不可少。TT正是这样一种可以结合黑盒测试和白盒测试进而产生灰盒测试效果的工具。 TT的灰盒测试技术 TT通过全局共享测试技术，穿线式的连接测试人员和开发人员，测试人员仍然以黑盒测试的方法，测试过程配合开发人员，在黑盒测试的基础上，零成本实现白盒测试结果，从而产生灰盒测试的效果。 TT工具灰盒测试的典型工作流程如下： 测试人员建立一个测试工程，由开发人员（对代码保密要求不高的话也可以由测试人员操作）将源代码通过TT编译成为插桩后的应用。 测试人员使用上述由开发人员编译后的应用进行测试用例编写，并对应用进行黑盒测试方式的操作，操作过程通过TT提供的示波器进行测试路径、覆盖率等信息的记录。 图2 实时监控界面 在测试过程中出现问题时，测试用人随时停止记录，在图2界面的示波器下部的控制台区域（Console），实时记录了测试用例最近运行的50个函数，开发人员根据测试路径，可以轻松直观的定位问题代码的范围。 测试过程中，开发人员和测试人员通过TT的双向追溯（测试用例到源码的追溯、源码到测试用例的追溯）提供的测试信息共享平台，可以共同制定和优化测试用例，比如增加一些目标功能以外的测试用例，使得应用程序的关键模块测试覆盖率达到100%，在黑盒测试的同时几乎可以零成本实现白盒测试。 图3 双向追溯界面 TT以其独特的技术特性，协同开发和测试人员进行高效的沟通互动，让开发和测试融为一体，通过2+1（测试、开发+TT）的模式让灰盒测试成为“平民”化的测试方法。 TT开启开发与测试的破冰之旅 在软件开发生命周期中，开发和测试之间的有效沟通和互动一个业界一直未有效解决的问题。在穿线测试理论出现之前，开发与测试通常只能通过自然语言进行互动和沟通，效率与精确性难以保障。例如当测试人员在执行一个测试用例发现缺陷的时候，他必须靠自然语言描述该故障出现的场景、条件等，这样开发就必须按照测试人员的描述来重现缺陷，然后再通过debug来解决问题。而通常基于测试人员自然语言描述的问题的重现会消耗大量的时间，甚至在更换环境以后无论怎样都无法重现，这个周期在宝贵的软件开发时间里面会显得异常的冗长。而TT在测试人员执