正在阅读一本很棒的书，《软件测试经验与教训》。几名国外的软件测试大师，以大量的测试工作实战经验为出发点，总结了深刻而精悍的两百多条经验。作者把这些经验比喻成为波尔多红酒，鼓励读者分散阅读，带入自己的工作实际情境，慢慢细品，深入思考。当然还有，不要独摊波尔多，分享给我的朋友、同事们！

　　《软件测试经验与教训》一书，讨论的第一个话题，就是关于测试人员的角色定位。我对这个话题讨论的个人理解是：清晰认识自己的角色定位，能够帮助测试人员明确对自己工作目标的预期。而清楚的认识测试人员的角色定位，对于公司、项目的其他成员来说，可以使他们对于测试工作的“期待”更加恰当，即使是“指责”，也更恰如其分。关于这个话题，以下是对于书中部分经验的理解或讨论。

　　“测试员是前灯”

　　研发经理和开发人员或许正开着一辆吉普，行进在盘山公路上，测试人员的职责就是做好探路的前灯，哪里是悬崖，哪里有险情，前方的路面情况如何……而产品或者项目的关键决策，都是基于这些信息的。测试人员的职责是将关于这一切的尽可能详细的信息告知公司或项目的其他成员。

　　是这样的角色：全面搜集、整理、报告信息

　　不是这样的角色：决策者

　　“迅速找出重要的程序问题”

　　测试人员很重要的一条使命就是“迅速找出重要的程序问题”。如何做好这点，书中给出了几条建议。他们看上去很简单，很质朴，似乎每个人都知道，但是在实际工作方法中有经常性地提醒自己或者潜意识中就使用这几条建议么？所谓大道至简。

　　*首先测试经过变更的部分，修改和更新都意味着新的风险

　　*首先测试核心功能，测试产品所完成的关键和常用功能，测试完成产品基本任务的功能

　　*首先测试能力，即每个基本功能是否能用，然后测试可靠性，即深入检查每个功能在不同条件下的表现

　　*首先测试常见情况，使用常用的数据和使用情境。然后测试特殊情况。

　　*首先测试影响重大的问题

　　*优先测试最需要的部分--对团队其他成员有重要意义的任何部分的任何问题

　　*测试人员对产品、相关软硬件、产品的最终用户越了解，就越可能更快地找出重要问题。

　　“Follow 开发人员”

　　为开发人员提供支持，这也是测试人员的一项重要使命。尽可能建立最短、最快的反馈环路--开发人员交付产品时，马上进行测试；开发人员修改变更代码后，马上测试变更的内容（trunk版本的测试即是此种情况）。在书中，几位测试大师认为，最理想的情况是，开发人员为了修改测试人员发现的缺陷而忙得团团转，是开发人员，而不是测试人员，成为项目的瓶颈。当然，老板可能不会认为这个情况理想：）

　　“询问一切，但不一定外露”

　　多提问。做测试时，遇到的情况千变万化，不可能不遇到问题。如果真的连续地进行测试工作，而没有任何问题可提，那么不妨暂停一下手上的测试工作，留给自己一些思考的空间，还是那个论断，不可能没有问题。

　　书中提到提问的方法，认为直白的提问就如一剂猛药，会刺激到别人，所以尽量减低剂量，或与米饭同吃（结合其他沟通形式）。这个的确是个不错的经验建议，在面对开发人员、产品需求设计人员、实施人员等同事时，可以尽量采用这样的提问方式。当然，在面对测试部门同事、主管时，个人觉得，直接提问会更有效率。