▌工程应用与学术研究，对测试技术的了解和兴趣，差异巨大。

一年以前，朱少民老师在他的公众号“软件质量报道”中发布了《软件测试技术应用现状调查报告》系列，公布了他对大学、研究院、软件公司的测试从业者，对于测试技术的了解、应用情况和兴趣、热点的调查结果。

毫无意外的，软件公司与大学间存在巨大的差异：

◆成熟超过20年的测试技术，在公司和学校应用都比较普遍。

◆提出并应用已经超过10年的MBT，仍然更多的停留在大学。

◆更新一些的，基于搜索的测试方法，几乎还在大学，走进工程应用的非常少。

可见软件测试的热点，在工程应用和学术研究之间的差别还是比较大，学界研究算法较多，对人工智能充满信心。而在工程应用中，“软件开发的标准化、组件化”，以及敏捷、DevOps这一类的工程能力提升是热点。

测试并不是特例，事实上几乎所有的技术领域，应用和研究之间都隔着一个马云。这其实是很自然的。

▌学术研究需要在特定的方向上寻求突破：

▌工程应用则需要使用多个维度的、比较成熟、应用起来效率比较高的知识解决问题：

这并不意味着工程应用和学术研究会渐行渐远，相反，工程应用会追随学术研究的脚步，不断的将学术研究的成果转化为方便使用的工具，最终解决企业的问题。最初肯定是很少一部分先行者开始实现这个衔接，将新的技术用于解决工程问题，接下来会有更多比较敏锐的 工程师将这些技术用于更多的场景，最后，渐渐地新技术被工具、工程方法承载，变得易于使用。

那些比较敏锐的工程师，或者能及时掌握新工具的工程师，在团队中会显得比较“聪明”，因为当产品及其研发过程中，某类问题突出，需要启动专项改进项目时，他们能够取得主动，把项目做成由测试驱动的改进。这些人通常是长期跟踪和积累行业信息，才能在问题发生的时候，找到“趁手”的工具（解决问题的方法和技术）。

想要在这种时候给出“聪明”的建议，关键的一点就是，测试是否具有足够“宽度”的知识，是否在日常工作中就关注业界的相关新闻、资讯、成熟的方法和工具，产品相关问题的分析和积累。这样在方案的讨论中，就能够更准确的抓住问题的症结，提供更多的信息。测试提供的信息如果丰富且有结构性，就能够给研发团队解决问题的信心，从而支持根据测试的确认情况，评估并推进问题的解决（即测试驱动改进）。

一般搜集和整理信息，可以从三个角度进行：

◆看业界——整个软件行业和测试领域的相关信息；

◆看同行——同形态的产品或同领域的业务或同公司的其他产品的相关信息；

◆看自己——自己产品的相关方法、进展、问题及其影响。

从这些角度得到的信息，首先可以帮助我们形成系统视图。建议可以从“测试藏宝图”（software testing at a glance）或者“软件测试全景图”（网络上可以搜索到若干版本，选择日期比较近的作为参考）开始，以这个藏宝图或全景图为地图，就可以形成对测试技术的框架性了解。这个地图的信息量非常大，短期内每个领域都弄透彻是不可能的，建议先只了解到是什么，能解决什么问题。

从这些角度还可以了解当下比较热门技术，比较新颖的解决问题的思路。欧美的例如STAR系列会议：STAREAST、STARWEST、EUROSTAR，微软、IBM等业界顶尖公司组织的技术大会等。国内的例如TiD、CSTQB高峰论坛、MSUP的TOP100案例，阿里巴巴的测试嘉年华等各种技术大会。从这些会议的议题，可以看到在测试工程领域目前比较关注什么问题，什么工具、技术和观点比较热门。当然，对热门技术需要辩证的看待，一方面这些方法和思想对解决测试面临的问题是非常有益的；另一方面这些技术可能还很不成熟，应用的时候需要自己补齐模板和工具。

不过，可靠性和安全性测试的技术，通过这些渠道分享的比较少，更多的还是需要通过分析安全性测试（software safety testing），可靠性测试（software reliability testing）的文章和论文来获取相关信息。

此外，还有一个非常重要的渠道是向身边人学习，公司内、团队内的测试工程师也可以进行定期的分享和交流。我们的团队有一个内部论坛，每个人都定期讲讲自己的工作，也将最核心的工作成果拿上来show一下，这样可能很好的达到知识共享的目的。

总之，虽然在公司里，测试工程师似乎大部分都在用“过时”的方法和工具，但拓展视野、启发思想仍然是需要的，这样，对于个人的成长和工作效率的提升都是有帮助的。

最后啰嗦一句，测试工程的系统视图非常重要，前面提到过，解决工程问题需要多个领域的知识，系统视图就是帮我们解决维度的问题的。一些问题，如果选错了解决问题的维度，常常是事倍功半的。

推荐参考资料：

《软件测试技术应用现状调查报告》的信息，可在朱少民老师的微信订阅号“软件质量报道”查阅。

《软件测试价值提升之路》一书种，对各种常见情况下，解决问题的方法做了比较系统的介绍，也可参考。