软件测试的价值体现：测试人员如何影响开发人员

　　精辟名言51Testing软件测试网)fyX5QKJj(f

　　当你读一本书，读到某句话或某场景，是否有这种感觉，有很多想说的话，竟然作者 替你说了；有很多场景，似曾相识，貌似曾经经历过，一切都是那么的熟悉。心中自然激起一层层共鸣的涟漪，或掩卷而思，或“拍案叫绝”，或许这也就是所谓 “书中自有黄金屋，书中自有言如玉”的读书之妙处吧。这样的书，谓之好书。由于每个人的背景都不同，你认为的好书，他人并不一定能找到同感。由于工作原因，读测试专业相关的书籍不少，但让我记忆深刻，并会常常拿出来翻来翻去的好像并不多，不过JW（James A.Whittaker）的<<探索式软件测试>>是例外，主要原因并不因为它是目前市上讨论的焦点之一，而是书中的一些精辟名言让我觉得很受用。51Testing软件测试网 TUc2@4~!S&W0e'P

%BuZ7e*A7~0　　例如：最近发生在身边的一些事情，让我一直在反思“测试的价值到底是什么？”，围绕这一主题思考，便又想到JW在书中提到的这句精辟名言：

W-Q bDR}8}0　　“软件测试的真正价值并不体现在代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限，思路中的狭隘和技能方面的不足“（托尼.霍尔，1996）“51Testing软件测试网dI
BqF.CJ

　　当第一次看到这句话时，正如前面提到的，激起了我思想的层层涟漪，似曾相识，道理亦明，似是心中埋藏很久的一句话，终于有人替自己说出来了。怎么好的至理名言，不敢独享，于是把这句话放在新浪微博上，与圈中朋友分享，见如下截图，自是引来不少同仁的反馈。51Testing软件测试网5V5I k4Qt:GK.?

　　为什么会激起我思想的层层涟漪，品着这句话，回顾过去。如果说过去我是无意识地去影响开发，那是因为有足够经验的驱使，为了把产品做好，不仅是软件开发人员，还是需求设计人员，甚至是产品开发链的其他成员，我都会主动出击去影响他们（或许这也是一个加勒比海盗学者的特点之一，读<<学习要像加勤比海盗>>后的自我发现）。常常，在面试时我会问应聘者：“做测试工作，让你感到自豪的事是什么？”，大部分人回答的是:“发现Bug，特别是一些让开发难于解决的严重bug，是最开心，最有成就感的事了“。而相反，测试大师们恰恰建议我们要丢弃软件缺陷数量、缺陷严重性、测试用例的 多少、自动化代码量等可量化的衡量指标，转而通过观察测试人员提高了多少开发人员的工作绩效来评估。面对这些差距，笔者倒也觉得正常，如同做任何一件事都 有一个循序渐进的过程，毕竟软件测试在国内的起步较晚，据去年我做的一些数据调查，基本上晚了约20年。但，这并不意味着我们只能望洋兴叹，站在巨人的肩 膀上，我们可以看得更高更远。

　　前行中的反思

　　就测试而言，质量如生命，效率如健康。软件测试人员是质量的最后把关者，守护神，这个我们都谈得很多了。谈到质量，我们会提及很多方法，如黑盒，白盒，灰盒，最近比较流行的敏捷测试，探索性测试等。谈到效率，我们会不由自主提及自动化测试， 自动化工具等。测试的使命就是围绕产品的质量、效率转。我们的出发点都很好，但在解决问题的方法上，往往是集中在结果上，即出现了什么结果，再去想办法解 决它。对于测试来说，可以理解这个“结果”就是软件的缺陷。我们经常也谈，测试要尽早介入，尽早发现问题，尽早把bug消灭在摇蓝中等。这些说的都是事， 而我们恰恰忽视了一个很最重要的东西，就是在整个产品开发链中，产生这些事的人的问题。（注：这里不是谈人的管理问题）。如果我们能盯住人（角色），因为 这些问题实际都是由前面的人产生的，我们是否可更加轻松。51Testing软件测试网 Sb'|6av/bE@*]9E

　　把我们的眼光放得更宽远一些，锁定可能会出现问题的设计人员或编程人员身上，用心去发现他们解决问题时的方法局限，思路狭隘或技能不足的体现，便能尽早发现问题。下面是案例分享。

　　【案例】用户场景联调51Testing软件测试网i4OLy%H.B

　　说明：故事是真实的，但为便于阐述及机密原因，案例中的人物及相关信息，采用化名51Testing软件测试网Jj.FhE

　　人物：

　　D0：软件项目经理

　　D1：Team 1的软件开发工程师

　　D2：Team2的软件开发工程师

　　D3：Team3的软件开发工程师

　　T0：测试负责人

({{7k2qbn0　　背景：

　　P-001是一款基于Linux平台开发的医用设备软件，属于嵌入式软件系统，按计划明天早上需发布带打印功能的软件版本。51Testing软件测试网;a6}6M;Lpe.v

&VIYD'P
Uv?H"u@0　　发现问题：51Testing软件测试网8mL9L2m\2Sz

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

51Testing软件测试网'm/\4MfL

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

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

　　解决问题：

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

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

　　小结：

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

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

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

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