一、测试大数据应用现状分析
软件测试积累了大量数据，直觉上，应该有可能把这些数据存在的规律、知识、模式发掘出来，反过来指导软件测试工程实践。这已经成为业界共识，而且不少人也从多年前就开始了相关研究工作，建立了不少测试样例库、故障库，甚至还有更全的库。但是到底从这些数据中发现了哪些有意思（我们以前没有意识到的）的知识、模式、规律，这些课题组总是闪烁其辞，我的理解，就是没有值得一提的东西。我见到的所谓大数据应用结果，大多都是些宏观的分类统计，确切地说，连决策支持（DSS）的水平都算不上，与人们对大数据应用的期望相差甚远，对具体的新的软件测试项目设计的作用不大。
我想出现这种状况一定是有地方出了问题，我想尝试梳理一下。
首先，软件测试大数据应用必须提出工程应用需求，第二，工程需求抽象、转换为科学问题，第三，通过科学工具，包括数学工具，建模工具等解决科学问题。
比如机器人、通信协议的测试，可以把应用抽象为米莉机，就是输入、输出和状态都是有限的自动机，且任意时刻只处于一种状态中，状态的迁移只取决于当前状态和输入。另一些应用的测试则可以抽象为摩尔机，即状态转换只依赖于输入。接下来，通过算法寻找米莉机的同步序列或归位序列，作为测试用例，验证系统可以进入的最终状态，或是其他预期行为。
类似地，我们期望通过软件测试数据的处理得到什么呢？我听得最多的就是测试用例推荐，当然这也是其他领域大数据应用的目前热点之一，互联网上已经有很多了，主要是各种商品和服务的针对性推荐。
那我们不妨想一想，我们自己学习软件测试的过程，是不是仅仅观察很多以前的测试用例或是软件问题报告呢？显然不是。对于我们这种基于需求测试模式为主的测评实验室来说，从需求映射为测试用例的技巧才是学习的关键，也是评价一个测试员能力水平的重要方面。好的测试员为什么优秀？主要体现在对具体需求的理解，能够结合自己的经验、常识甚至直觉，提出满足测试目标的合理的测试用例。当然，不同的测试级别对知识的要求层次差别还是很大的。根据一般的测试模型，测试级别越高，测试目标越具体。比如级别低的单元测试，只需要理解要完成的具体功能，与具体的应用没有很大的关系，因而比较容易抽象出通用的测试经验，甚至自动化。相反，系统测试强烈依赖特定的软件应用场景，类似的软件用在不同的场景中，会要求差别很大的测试设计。
软件在人们的生活中发挥着这样重要的作用，因此保证软件质量是至关重要的。测试是验证任何产品质量的过程。举一个纺织工业的例子：购买布匹时，我们期望布匹禁用，尺寸合适，不易掉色。在销售布匹之前，销售者有责任测试布匹的这些基本性质，换句话说，销售者要对布匹的质量负责。
二、测试大数据应用推进难点
我认为更为抽象的单元测试对于测试用例推荐，一般来说更容易。但是单元测试主要还是由软件研制单位完成，因此单元测试的用例推荐对软件测评实验室价值不高。对于大数据应用来说，单元测试用例推荐可能是比较好的起点，关注服务对象主要是软件研发单位。
同时，软件单元测试与其他测试级别相比也是最成熟的，目前唯一有效的软件测试国际标准就是单元测试标准，针对单元测试的自动化、半自动化工具也是最丰富的，在软件测试目前已有的四种主要方法中，包括基于规则的动态分析、基于测试数据输入的动态测试、基于符号运算的运行时检查、基于模型的软件逻辑正确性验证等，也是运用最成功的，因此大数据要想给出一些更具启发性的推荐也是比较困难的，但是如果大数据能够更深入地结合被测软件单元的结构信息，换句话说，大数据不仅要使用从单元测试数据中提取的模式信息，还要使用具体被测软件的结构或设计信息，推荐有价值测试用例的可能性更大。特别地，针对某些单元测试难度比较大的子问题，比如中断处理、变量定义/使用路径验证等的测试，获得突破的可能性更大一些。总之，面向的问题域越宽，给出高价值测试用例的可能性越低。我想大数据的发展策略应该是从特殊到一般。以往软件测试大数据应用效果不佳，我觉得很可能与开发策略有关。
不少人对我说，软件测试大数据应用效果不佳的主要原因是数据不够多，暗示只要测试数据足够多大数据应用的效果必然改善，尽管谁也说不清多少数据才算足够。我对这个想法深表怀疑。举个例子，大数据也好、数据库知识发现也好、人工智能、机器学习、模式识别等也好，当取得了一些重要突破后，无一例外地都把应用目标转向股市和类似的领域。直觉上这些技术应该在股市上有所作为，因为股市数据量不可谓不大，数据中的模式不可谓不多，已有的传统分析方法运用也几乎到了极致。但是事实是，即使是红得发紫的阿尔法狗也在中国股市潜水多时后黯然离开。从地球奔向月球是美好愿望，但是必须得有合适方法，你对自行车再挖空心思地改造，也永远不会把你带到月球。我想大数据也是一样。如果软件测试领域的复杂度可以与股市比较，再对着自行车费心思就大可不必了。关键是降低问题域的宽度和难度，大而化之的所谓软件测试大数据应用，我认为目前是不可行的。
三、测试大数据应用解决方向
软件测试的主要工作，是把软件需求映射为软件测试。大数据应用也可以表述为辅助测试人员，直至自动完成这个映射，大数据能力的表征也体现在对测试人员的辅助、启发效果。如果给出的推荐是测试人员没有想到，而且对测试具有重要性，则得正分；如果推荐是重复性的，比如被其他测试用例包含，则得零分；如果推荐没有可行性或必要性，甚至对测试人员的设计产生干扰，则得负分。这种奖励/惩罚机制可以构成大数据自我学习、进化的基础。
这个机制与测试人员的成长类似。测试大纲写好后经过内部评审和外部评审，经过几轮迭代不断完善。在理想情况下，测试人员会汲取教训和经验，同类问题出现概率越来越小。把这个测试设计进化过程送给大数据，即同一个项目的多个测试设计，以版本高低顺序排序输入给大数据，呈现出完整进化过程，可以是大数据的一个起点。因为测试设计在评审中被提出修改意见的落实结果，本质上就是一种推荐，而且是正分推荐。
不过问题远没有这么简单。测试设计评审，实际上也是评审同行背对背地进行从测试需求到测试设计的映射，并把自己的映射与被评审的测试设计产品进行比对，发现产品不足的过程，仅仅了解测试设计改进情况，而不知道为什么需要进行这些改进，很难获得实质性的经验。因此大数据了解测试需求等依据，理解测试设计多个版本的映射差异，对于大数据的模式发现来说可能是不可避免的。
于是下面的问题就变成大数据如何对测试需求进行理解。我听到不少人说，测试需求的理解通过自然语言处理解决，因为现实世界的测试需求主要以自然语言描述的形式给出。实际上，对测试需求的理解本身对测试人员的能力要求就是很高的，很少有测试人员仅仅根据测试需求文档就能很好理解被测软件的，与软件研发人员的沟通是很难避免的。这意味着大数据还要理解不同阶段的软件设计文档、甚至系统设计文档、项目技术方案、立项论证报告等等相关文件。即使这些条件都具备，通用的测试需求大数据理解也是非常困难的，可能降低难度的方向，应该是限定软件类型、使用领域等，达到一般测试人员的平均理解水平还是有可能的。
在测试需求大数据理解上，我觉得还有两个问题很难回避，一个是需求文档中的图表，一个是预期的测试环境初步想定。
图表对于测试人员对测试需求的理解至关重要，大数据直接理解图表中给出的丰富语义信息、结构信息、拓扑信息，我想还是有很大困难的。如果需要人工把图表进行自然语言转换，即使是能够做到，对大数据的实际使用也会是个很大制约。如果这个问题没有一个足够满意的解决方案，我想大数据对于软件测试可能弄不好就是那个自行车了。
测试需求到测试设计的映射还有一个重要条件，就是测试环境的初步想定，而测试环境又是在映射过程中逐步确定的。一般来说，测试需求决定测试环境，测试环境影响测试需求。但是测试环境的确定还受到很多技术、管理、成本、进度、可用资源等多方面的制约，可能需要比较复杂的综合考虑，既要考虑测试的充分性、有效性，还要考虑测试工程的可行性。而且测试环境的确定常常是一个逐步迭代的过程，测试任务的不同，使得通常不存在一个具体的理想目标测试环境模型。而如果要把测试环境作为测试设计大数据推荐的一部分，可能难度很大，因为测试大纲不同版本本身可能就包含测试环境的演化。可能的解决办法是优先确定测试环境，虽然这对测试人员来说也不是完全不能接受，但毕竟是对大数据的一个重要制约。
欢迎各位大佬提出意见见解，留言区等你哦！
联系客服
