比较测试是灰盒测试吗_黑盒白盒测试步骤_白盒测试,灰盒测试,黑盒测试(2)

4） 测试过程中，开发人员和测试人员通过TT的双向追溯（测试用例到源码的追溯、源码到测试用例的追溯）提供的测试信息共享平台，可以共同制定和优化测试用例，比如增加一些目标功能以外的测试用例，使得应用程序的关键模块测试覆盖率达到100%，在黑盒测试的同时几乎可以零成本实现白盒测试。图3 双向追溯界面TT以其独特的技术特性，协同开发和测试人员进行高效的沟通互动，让开发和测试融为一体，通过2+1（测试、开发+TT）的模式让灰盒测试成为“平民”化的测试方法。4、 TT开启开发与测试的破冰之旅在软件开发生命周期中，开发和测试之间的有效沟通和互动一个业界一直未有效解决的问题。在穿线测试理论出现之前，开发与测试通常只能通过自然语言进行互动和沟通，效率与精确性难以保障。例如当测试人员在执行一个测试用例发现缺陷的时候，他必须靠自然语言描述该故障出现的场景、条件等，这样开发就必须按照测试人员的描述来重现缺陷，然后再通过debug来解决问题。而通常基于测试人员自然语言描述的问题的重现会消耗大量的时间，甚至在更换环境以后无论怎样都无法重现，这个周期在宝贵的软件开发时间里面会显得异常的冗长。白盒测试,灰盒测试,黑盒测试而TT在测试人员执行用例的过程中，自动的记录了测试人员进行操作的过程中，程序内部的精细到每一个路径、分支的执行情况，开发人员可以通过TT直接拿到测试实施这些数据，快速定位问题。

TT通过自动化手段进行灰盒测试的优化应用，并提供开发测试解决方案。它采用的专利问题解决方案技术，从以下几个方面大大加速了测试过程中问题解决流程：提供了自动化的信息采集、捕获现场操作并将所有的相关信息统一打包处理；消除了通常情况下需要完整重现问题发生的过程，避免在重现问题上耗费的时间开销；大大加速了问题分析的过程，使得开发人员能够快速分析问题并隔离根源问题。另外一个角度，由于一般测试人员无法看到程序的内部逻辑，仅仅从功能表象上对被测程序的特性进行测试，因此没有量化的数据，通常没有办法和开发人员进行详细和高小的沟通，而由于二者本职工作方面差异的原因，通过开发人员也不会非常主动的帮助测试人员设计非常精准的用例。而有了TT以后，测试人员可以很明确的看到自己黑盒测试对应的程序内部的逻辑的覆盖情况，这样测试人员就可以通过这些量化、可视化的数据，而开发人员进行很容易的互动，因为拿着数据说话，很容易获得认同，开发人员就可以和测试进行非常有效的沟通和配合，一起为达到对关键模块精细化的，接近于100%的覆盖率进行努力。一同协作来对测试人员的用例进行补充。对于测试人员来讲，每个版本的变更对回归测试时非常重要的依据，TT会给测试人员非常精确的每个版本的变化信息，而不再是通常由开发给出的模糊且带有大量遗漏的信息。

另外基于TT的智能的双向追溯技术特性，它甚至可以直接告诉测试人员，这些变更应该会影响到哪些测试用例。帮助测试人员在海量用例集里面，针对本次的变更，直接定位那些需要进行复测的测试用例。同样，开发人员在计划对代码逻辑进行变更的时候，也可以利用测试人员建立的测试用例与代码逻辑的关系库，去分析一个功能点是如何实现的，对某些代码的改变会影响到那些其他功能点。TT的最大创新在于，测试人员在测试过程中由TT产生的数据，将被开发与测试共享使用，从技术手段将开发与测试之间的距离拉近。TT在黑盒测试过程中自动记录用例与代码的逻辑对应关系，应用问题解决方案非常适用于测试人员和开发人员。对于测试人员来说，由于自动记录了测试场景和问题发生过程，避免了开发人员和测试人员之间相互推诿，同时开发人员可以通过“黑盒子”直接从测试人员那里得到更多信息，并帮助直接定位到代码行。

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-28130-2.html