平民化的安卓测试工具--ThreadingTest介绍

1、软件测试领域30余年的主题----黑盒测试与白盒测试

测试在软件开发的整个生命周期中占据非常重要的地位，这一点从测试所占的时间上可见一斑，我们经常使用的测试方法大体上可分为黑盒测试和白盒测试，这是测试方法中的最典型的代表。

图1 常规软件工程各阶段所占时间比例

黑盒测试又称为功能测试或者数据驱动测试, 是把要测试的软件看成一个 “黑盒子”, 不管其内部结构如何以及以什么算法实现所要求提供的功能，而是按照需求的功能化要求, 设计相应的测试用例(包括测试的输入数据与条件设置和所预期的软件运行输出结果), 通过软件运行后所给出的输出(包括字符形式的输出与图象输出)与所预期的结果进行人工或者自动化比较, 来验证被测试软件是否能给出正确的结果, 从而判断该软件是否满足需求, 是否与该软件系统的规格说明书和用户手册相关部分一致。

      白盒测试也称为结构测试或者逻辑驱动测试，它与黑盒测试方法相反: 它不管所被测试的软件是否满足需求,是否实现了所设计的功能, 而只注重该软件内部的结构, 以便设计足够多的测试用例, 使得百分百或者尽可能多的程序组成要素能被测试到最少一次, 从而尽可能地将其中的软件错误暴露出来。测试市场上的白盒测试在测试领域本来就不是非常流行，那是因为传统的白盒测试是需要很高的编程能力，在测试人员中很难流行起来。而TT则对传统的白盒测试过程和方法进行了大规模的创新，甚至不改变传统黑盒测试的方法和过程的基础上，自动产生完整的白盒分析数据。TT采用的方法更接近于测试理论界的灰盒子测试方法，而传统的白盒测试厂商对该理论方法并不理解，纵观全球市场也鲜有相关产品。

 

2、全新的穿线测试

       黑盒测试和白盒测试从概念上来说是比较对立的，黑盒测试得到的结果很难定位到内部结构的所在位置，即功能性的错误不能定位到错误的代码处，只能由开发人员根据错误现象凭经验手工排查和定位；白盒测试的结果也很难跟功能应用直接挂钩，因为不是所有的内部结构都和功能应用有直接的关系。鉴于这些问题，灰盒测试的概念就自然而然的被提出，它介于黑盒与白盒之间，既关注功能的输入输出的正确性测试，也注重内部结构的测试。既包含了黑盒和白盒的优点，又弥补了两者的不足。但灰盒测试在市场上几乎鲜见有商用的测试工具支持，其主要方法仅仅停留在概念阶段，并没有在此基础上上设计可商用的工具和功能。

      

灰盒测试这个理念要想真正发挥作用，必须使其“平民”化，而将一件复杂的工作简化成一个普通从业者都能完成，通常的做法使用专业的工具，简单的说，要轻松的实现灰盒测试，工具必不可少。TT正是这样一种可以结合黑盒测试和白盒测试进而产生灰盒测试效果的工具。

 

3、TT的灰盒测试技术

TT通过全局共享测试技术，穿线式的连接测试人员和开发人员，测试人员仍然以黑盒测试的方法，测试过程配合开发人员，在黑盒测试的基础上，零成本实现白盒测试结果，从而产生灰盒测试的效果。

TT工具灰盒测试的典型工作流程如下：

1）           测试人员建立一个测试工程，由开发人员（对代码保密要求不高的话也可以由测试人员操作）将源代码通过TT编译成为插桩后的应用。

2）           测试人员使用上述由开发人员编译后的应用进行测试用例编写，并对应用进行黑盒测试方式的操作，操作过程通过TT提供的示波器进行测试路径、覆盖率等信息的记录。

图2 实时监控界面

3）           在测试过程中出现问题时，测试用人随时停止记录，在图2界面的示波器下部的控制台区域（Console），实时记录了测试用例最近运行的50个函数，开发人员根据测试路径，可以轻松直观的定位问题代码的范围。

4）           测试过程中，开发人员和测试人员通过TT的双向追溯（测试用例到源码的追溯、源码到测试用例的追溯）提供的测试信息共享平台，可以共同制定和优化测试用例，比如增加一些目标功能以外的测试用例，使得应用程序的关键模块测试覆盖率达到100%，在黑盒测试的同时几乎可以零成本实现白盒测试。

TT以其独特的技术特性，协同开发和测试人员进行高效的沟通互动，让开发和测试融为一体，通过2+1（测试、开发+TT）的模式让灰盒测试成为“平民”化的测试方法。

 

3、TT开启开发与测试的破冰之旅

 

 

在软件开发生命周期中，开发和测试之间的有效沟通和互动一个业界一直未有效解决的问题。在穿线测试理论出现之前，开发与测试通常只能通过自然语言进行互动和沟通，效率与精确性难以保障。例如当测试人员在执行一个测试用例发现缺陷的时候，他必须靠自然语言描述该故障出现的场景、条件等，这样开发就必须按照测试人员的描述来重现缺陷，然后再通过debug来解决问题。而通常基于测试人员自然语言描述的问题的重现会消耗大量的时间，甚至在更换环境以后无论怎样都无法重现，这个周期在宝贵的软件开发时间里面会显得异常的冗长。而TT在测试人员执行用例的过程中，自动的记录了测试人员进行操作的过程中，程序内部的精细到每一个路径、分支的执行情况，开发人员可以通过TT直接拿到测试实施这

些数据，快速定位问题。TT通过自动化手段进行灰盒测试的优化应用，并提供开发测试解决方案。它采用的专利问题解决方案技术，从以下几个方面大大加速了测试过程中问题解决流程：提供了自动化的信息采集、捕获现场操作并将所有的相关信息统一打包处理；消除了通常情况下需要完整重现问题发生的过程，避免在重现问题上耗费的时间开销；大大加速了问题分析的过程，使得开发人员能够快速分析问题并隔离根源问题。

 

另外一个角度，由于一般测试人员无法看到程序的内部逻辑，仅仅从功能表象上对被测程序的特性进行测试，因此没有量化的数据，通常没有办法和开发人员进行详细和高小的沟通，而由于二者本职工作方面差异的原因，通过开发人员也不会非常主动的帮助测试人员设计非常精准的用例。而有了TT以后，测试人员可以很明确的看到自己黑盒测试对应的程序内部的逻辑的覆盖情况，这样测试人员就可以通过这些量化、可视化的数据，而开发人员进行很容易的互动，因为拿着数据说话，很容易获得认同，开发人员就可以和测试进行非常有效的沟通和配合，一起为达到对关键模块精细化的，接近于100%的覆盖率进行努力。一同协作来对测试人员的用例进行补充。

 

 

对于测试人员来讲，每个版本的变更对回归测试时非常重要的依据，TT会给测试人员非常精确的每个版本的变化信息，而不再是通常由开发给出的模糊且带有大量遗漏的信息。另外基于TT的智能的双向追溯技术特性，它甚至可以直接告诉测试人员，这些变更应该会影响到哪些测试用例。帮助测试人员在海量用例集里面，针对本次的变更，直接定位那些需要进行复测的测试用例。同样，开发人员在计划对代码逻辑进行变更的时候，也可以利用测试人员建立的测试用例与代码逻辑的关系库，去分析一个功能点是如何实现的，对某些代码的改变会影响到那些其他功能点。TT的最大创新在于，测试人员在测试过程中由TT产生的数据，将被开发与测试共享使用，从技术手段将开发与测试之间的距离拉近。

 

TT在黑盒测试过程中自动记录用例与代码的逻辑对应关系，应用问题解决方案非常适用于测试人员和开发人员。对于测试人员来说，由于自动记录了测试场景和问题发生过程，避免了开发人员和测试人员之间相互推诿，同时开发人员可以通过“黑盒子”直接从测试人员那里得到更多信息，并帮助直接定位到代码行。