通过这样的“谈心”交流，有时可以拓展自己在制定测试计划或测试用例时的思路，有时可以解决开发设计时的需求理解问题，甚至可以避免因开发人员的人为因素而造成的缺陷发生。

　　我一直觉得，测试驱动开发，是一种测试“驱动”开发方式。测试人员主动参与设计，诚挚跟设计、开发人员“谈心”，不仅可以帮助他们从测试的角度去看待一些问题，还可以使测试人员本身的思路更加清晰，而且，开发人员也可以拓展测试人员的思维。更为实在的是大大提升了工作效率，缩短了开发周期，降低了公司和客户的成本。共享多赢，何乐而不为？

　　二、针对需求制作人员

　　起初，我仅仅把“谈心式”软件测试法应用到了开发设计人员层面。后来，我发现这个方法不仅可以应用到与开发设计人员的沟通上，也可以用在需求制作人员的身上。

　　需求制作人员在制作需求文档的时候，经常要从两个角度出发，一是从客户的角度出发，因为他们要制作出客户满意的需求来。二是从软件开发角度，他们要思考功能实现的可能和成本。

　　不管怎么说，需求人员在对客户需求做二次加工的时候，就会自然而然地注入其个人的观点或意愿。测试人员在阅读、分析需求文档的时候，如果发现什么疑问，比如说新需求和软件系统以往的风格有出入，或功能点描述模糊，或其他一些问题，测试人员就可以直接与相关需求人员沟通，寻求问题的确认和帮助。这样的“谈心”，不仅仅是对需求的一定评审，同时也是对自己的测试工作的帮助。最为主要的是与需求制作人员多交流，多沟通，致使对需求更加明确无误，以免多走弯路，影响工期，增加成本。

　　三、针对客户

　　随着阅历的拓宽和实践经验的积累，现在的我已不满足和需求人员、设计开发人员“谈心”，有时也会与客户直接“谈心”。

　　在敏捷开发模式或其他快速开发模式下，项目组成员和客户的直接交流已成为可能，而且变得越来越频繁，越来越重要（比如我们现在的项目组）。

　　“测试从客户的原始需求开始”，已经是我的一种工作方式。

　　在遇到需求制作人员也无法给予答案的问题时，我就会直接和客户“谈心”。毋庸讳言，有很多时候，客户的需求是模棱两可的，甚或是想当然的。有时他们提供的原始计算方法或运算流程（在很多软件项目，客户所用到的计算方法或公式是很专业的，所以必须由客户直接提供）是不正确的。在这种状况下，如果测试人员发现了这方面先天不足的问题，并及时与客户“谈心”沟通，将之扼杀在萌芽状态下，必然会避免项目组宝贵时间的浪费，挽回客户相当的损失。

　　“谈心”不仅可以发现问题，解决问题，“谈心”还可以让测试人员更多地了解现在开发的软件所涉及的行业规范及其他知识。同时，也能为测试人员更好地测试当前软件、系统或产品提供准确的知识背景；能让测试人员制定出更符合此软件的测试用例；能有针对性地发现更多不符合行业规范或要求的软件缺陷。多年的经验告诉我，对于一个前沿的测试人，对当前系统所涉及到的行业、领域知识，在一定程度上，比测试技能（测试方法的应用、测试工具的使用）更为重要。

　　测试人员直接与客户“谈心”，似乎有“越俎代庖”之嫌，倘若遇到多虑的需求制作人员，有时难免会造成一些误会，生出一些不必要的嫌隙。在此值得一赞的是，我比较庆幸自己加入了一支奋发向上、相互尊重、团结和谐的团队。只要是有利于项目开发，有利于客户需求，我们这个团队，从不过多计较所谓的“规矩礼数”。

　　其实，测试人员不仅仅可以和文中所提及的这三类人员“谈心”。只要是项目干系人，均可用“谈心”的方式去直接或间接地对软件进行测试。测试人员可以把思路打开，不要仅盯着软件、系统本身。整个项目组从人员、到流程，都可以成为测试人员的测试对象。套一句时髦概念，此可称为“大测试”理论。

版权声明：本文出自 shan0310223 的51Testing软件测试博客：http://www.51testing.com/?624630

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。