背景：

　　P-001是一款基于Linux平台开发的医用设备软件，属于嵌入式软件系统，按计划明天早上需发布带打印功能的软件版本。

　　发现问题：

　　为顺利开展明天要测试的软件打印功能，测试负责人T0已把相关测试人员的工作安排就绪。按惯例，开发人员提交代码正式发布版本前，应该确认自己所提交的功能是否符合需求，不存在低级问题。例如：打印功能，在UI层用户通过点击“打印“按钮即可得到一张数据报表，这也是团队对开发人员的基本要求。但是，此打印功能涉及多个子模块，这些子模块分别由不同的开发团队完成，各子模块的逻辑关系如下图所示。

　　T0很清楚一些开发人员的想法、特点，也即是他们的思路狭隘点。尽管有流程或规范要求要如何做如何做，据过去一些项目的经验，总会有一些开发人员爱犯错，事后找一堆这样那样的理由，言之什么是意外，什么什么又是意外等（其实是没有克服一些困难）。

　　负责P-001项目软件开发团队的办公位置离测试人员并不远，抱着几分担心与怀疑，T0在发版本的前天下午便主动过去“打听军情”。得知负责打印模块的开发工程师D1并无用真实打印机确认他的程序是否能在用户场景下跑。他给的解释是这样的：“我调试过程序，是没问题的。为什么呢？我负责打印的应用层部分，责职是收集用户的数据，并按要求准备好指定格式的数据，然后把这些数据发出去，只要能发出去，就说明我的程序是没问题的。目前我是采用虚拟打印机，即采用打印到文件中的方法进行调试的，我认为这样做是能达到预期的”。同时，T0也清楚地知道，负责打印模块中间层的开发人员D2属于另一开发团队，目前正在为其他项目服务，同样负责底层打印驱动的工程师D3也不在项目中。

　　解决问题：

　　T0明白D1的调试思路，但如果打印数据子模块与打印平台（逻辑处理）子模块接口间存在问题，对于用户来说不是一样吗，即打印失败。于是向他分析这样做可能存在的问题，如果问题一旦发生，测试人员必将会提交bug，并要求重发版本。与其这样，不如开发人员做一些必要的用户场景使用的联调。D1表示也理解，好像该这样做，但表示他的时间有限，且他不知道哪里有打印机等等。T0于是又把P-001的软件负责人D0找来，说明清楚问题发生的可能性，影响情况，并表示愿意提供打印机等资源协助相关开发人员进行用户场景的联调。

　　第二天早上一上班，T0发现并没有收到自动构建版本发布的邮件与QQ消息，问及软件开发负责人D0，回答：“打印平台与打印数据的接口地方存在问题，昨晚已安排两人进行问题的排查，正在更改打印平台的相关代码，版本稍后发布”。事情正如T0所料，不过，问题能在版本发布之前发现，要比留到测试端发现，提交bug后再解决成本低很多，这也正是T0想要的结果。

　　小结：

　　测试朋友，很熟悉的开发与测试工作场景吧。T0的行动，推动了把问题暴露在版本提交测试前，这对产品质量的稳定，开发过程的成本降低无疑是有贡献的。或许，你会说测试人员提交的bug能说服开发人员去解决，已不是一件容易的事，更何况推动开发人员按你的思路去做某件事呢？而这正是真正体现测试人员价值的地方。这不仅涉及技术、流程，还有沟通协调等。需要有足够的经验或知识去影响开发，帮助开发，让开发人员信服，充满挑战。

　　细心的读者，也许你已从案例中发现了挑战的起点、方法。这里再补充两点可操作的思路，第一：从开发的差异性角度入手分析，例如通常情况下，对产品的业务知识熟悉程度，测试人员比较优势，可帮助开发人员掌握更多的用户场景，及分析存在风险的地方；第二：对发现的bug进行归类，分析，通过提供这些数据，帮助开发解决问题时能更充分与更完备，尽量减少重打开的bug数。

　　末了，送大家一句话，也是笔者常激励自己的一句话“测试之路，路漫漫其修远兮，吾将上下而求索”。

　　说明：本文原登于<<测试人>>杂志 No.3，转载请注明来源