ThreadingTest软件测试界顶层设计--由中国人引领的数字化软件测试时代来了(上）

threadingtest · 发表于 2015-4-21 20:39:30

长久以来，业界对软件测试一直存在或多或少的偏见，外行人更是认为软件测试可有可无，也大有人在。这个行业给人的印象是很好入门，经过简单的培训就可以上岗。相比开发岗位来讲，这个行业的能力天花板非常之低。绝大部分黑盒测试工程师通过一段时间的工作和学习后，很快就碰到测试天花板，在技术上很难突破，对职业发展无所适从。软件测试行业流行的一个话题永远是如何从测试成功转型的问题。
笔者看过一本专业测试书，作者的技术功底非常优秀，书中讲解了非常多的测试技术和测试工具，不过遗憾的是，作者也在该书的收官章节大谈测试转型的问题。因此，从某种程度上看，即使测试资深人士在潜意识中也认为：测试必须进行转型，否则永远冲不破瓶颈期到来的魔咒。这也从一个侧面反映了测试行业的诸多失望与无奈。
为何软件测试经过数十余年的发展仍然无法进入一个全新的境界，似乎整个行业多年以来也是原地转圈？随着经济的快速发展，软件人才需求越来越大，大量的软件测试队伍也在快速膨胀中。一些新的测试方法也在不停的创新和使用中，但是软件测试行业依然不愠不火，无法像开发一样得到重视、蓬勃发展。包括投资圈的投资老大们也表示，只要软件能按时上线，我们不用过多注意它的品质，后面让开发团队打补丁。但是不断暴露出来种种问题让技术总监寝食难安：上线后的闪退、崩溃，后期由于开发团队的变动导致的软件维护工作千头万绪、无从下手，恨不得推倒重来。但就算你不计成本重做一个，问题还是跟之前一样，需要面临着软件的过程检查、后续迭代挑战和沉重的心理压力。
其实，造成软件维护困难的深层次的原因在于：软件测试的整个过程和方法完全面对BLACK BOX。当你站在庞大的代码行面前，你十指生风，你飞快的进行盲点排错，你如何得知暗箱里的那部分到底是哪一部分影响了哪一部分？你如何能明查秋毫、一针见血、漂亮交工？听起来像绕口令，对吧？那么我们就简单捋一下那些不知死活的测试难点在哪里：首先，我们系统级的测试用的基本都是黑盒工具；第二，测试过程中所产生的数据基本都是人工录入，数据的准确性无法保证，也这是为什么软件测试永远强调团队的职业素质和管理能力；第三，传统的功能测试过程极其不稳定，特别依赖于测试人员的业务能力和临场发挥能力，即使很优秀的测试人员也会因为状态问题而导致测试用例设计水准出现波动，更不要提有经验人员和经验欠缺人员的在测试质量上的巨大差别；第四，业界几乎将自动化测试作为解决测试质量的灵丹妙药，但实质上自动化测试无外乎是人的经验的机械执行而已，完全无法解决测试的根本症结。所有罗列种种，造成了整个测试行业不被理解，不受重视。若是程序报错，测试人员在第一时间承受白眼，被无声质问：“你们是怎么搞的，不是测试过了吗？你们难道是吃白饭的吗？“在这样的工作条件下，测试工程师们如同拖着一个个沉重的铁球，困难重重、举步为难、四面楚歌。
那么到底什么样的测试技术才能改变软件测试的尴尬境地？我们可以在车辆功能安全标准ISO26262安全管理生命周期的细则中总结出软件测试必须具备的基因：从项目管理上来看，测试工作需要达到两点：第一，实现开发与测试的交互管理；第二，实现可追溯的工程技术。从项目测试执行上来看，测试工作需要同时支持：静态测试和动态测试。笔者是国家最早一批软件测试的专业硕士毕业，亦在软件测试业深耕多年，带领着近600多人的团队在各大集团公司做过各种复杂软件的测试任务，深知软件测试理论的博大精深、应用场景的精妙复杂。笔者曾经专研了解过国际最为领先的白盒测试工具，但令人失望的是：国外的白盒测试工具价格太贵：一个LISENCE需要5万元左右，功能较齐备的至少需要20万，基本局限在单元级测试。另外他们一个致命的缺点是：学习周期过长，单位培养一位白盒测试工程师的代价非常大。在这个唯快不破的互联网时代，此类的工具就显得过于拖沓、落伍。
最近，软件测试圈的小伙伴们，对一款数字化软件测试工具ThreadingTest着了迷，它不仅登上了国际软件测试大会（ISTQB）的主讲堂，而且实际中，很多大集团公司的测试部门都在下载试用。它最炫酷的显著特点就是：测试无需源码，用黑盒的测试方法得出白盒测试报表。若是管理需要，软件完全可以为您展示软件开发、测试与维护中的每一步变化的数字化追溯结果，因此项目过程管理、验收与维护，对于ThreadingTest简直是举重若轻的。那么，如此奇妙、炫炸天的功能是如何实现的？它还有什么其它的惊爆眼球的解决方案？那么，今天我就向大家简要介绍一下ThreadingTest穿线测试工具。
首先，ThreadingTest穿线测试技术目前是国际最前沿的测试技术。它在不打破传统黑盒的测试流程和手段的基础上，兼容任意形式的黑盒测试流程，被测程序运行过程中，程序内部的执行逻辑和覆盖情况可以自动的生成，产生大量的被测试程序的运行数据并进行图形化、可视化的分析。
第二，穿线测试从开发和测试人员的最主要工作组件入手，率先提出了测试用例和代码的双向追溯，它也是穿线测试最核心技术之一。即运行一个测试用例以后，穿线测试可以通过程序自动的记录和显示这个测试用例执行的代码。如果测试用户关注某一些代码行，它可以追溯出那些测试用例在运行过程中跑过这段代码。我们都知道软件开发的两大核心人员就是开发和测试人员，这是完全不同的两类技术工种，开发和测试一直没有办法进行真正的信息化沟通。通过这个技术特性，每个测试工程师的每个测试用例都可以进行量化的分析和统计，这些量化数据既可以用来对测试工程师进行工作的考量，也可以提供开发人员和测试人员之间进行信息化的交流。
双向追溯技术记录了每个测试用例对应的程序内部的执行细节，细致到每个条件，分支，语句块的执行情况，可以理解为一个全景的调试器。开发人员可以通过双向追溯的结果去理解程序逻辑，进行软件维护以及进行可一致性的修改，因此，开发人员将很大程度上增加对测试人员工作的认同。开发和测试交流最头痛缺陷复现的问题可以迎刃而解，大大提升了测试和开发的交流效率。
第三，ThreadingTest数字化软件测试和传统的测试管理系统最大的区别是：大部分的测试数据都是通过软件系统自动录入的，是原生产生的，对比人为录入的数据，它是精确、公正和不可抵赖的。数字化软件测试技术将是软件测试进行精准控制的第一代技术，它将软件测试从无序的状态变成精准可控的状态。测试之所以被比喻为“良心活”，是因为测试人员是否精心设计了用例，是否执行了测试，测试的充分度如何，在穿线测试技术出现之前都是无法定量分析的，完全取决于测试人员自己的记录填写。数字化软件测试将完全克服这个缺点，自动记录每个测试工程师执行测试用例对应的程序内部的执行逻辑，每个测试用例的覆盖率，用例执行的逻辑以及对与错，均可被精准跟踪，所有的信息都会被记录在ThreadingTest系统里面。
数字化软件测试可以让测试过程不再特别依赖于测试工程师的个人能力，因为在没有数字化软件测试技术出现之前，个人能力异常重要，因为测试是面对的黑盒，对一个黑盒的把握需要充分的经验和能力，而有了数字化软件测试技术之后，它能够将测试数字化和标准化，因此技术由于测试人员经验不足，数字化测试平台会甄别出来，并且引导测试工程师继续有效的进行测试，因此个人能力将变得不那么绝对的必要，即在数字化软件测试的技术和相应的标准下，不同能力水准的团队最后都可以达到基本一致的测试水准，唯一的区别可能是时间的问题而不是绝对的测试能力和业务能力所决定的，数字化软件测试强调高度可控的软件测试过程而弱化个人能力在其中起的作用，数字化软件测试技术可以让测试真正变成标准化过程。
数字化软件测试可以对管理过程产生很大的改进，TT可以实时展示整个项目的覆盖率情况以及增长情况，这样测试管理人员可以对测试进度情况进行非常精确的把握，也可以对每个测试工程师的工作量，工作效率进行非常客观的考核和分析。例如通过每个测试用例的覆盖率的数据，又可以精确的判断测试是否真正执行，以及哪些测试用例对系统的覆盖面最广，需要重点测试。
另外，针对移动测试，TT会自动上报测试用例执行的机型信息，同时自动分析每日有多少测试工程师实际参与测试，每个测试工程师运行的测试用例的数量，都可以自动的分析出来，更为关键的是，这些数据都是在测试工程师运行用例的过程中自动生成并且进入数字化平台进行分析的，这些数据都是客观，不可篡改和伪造的。