初看被标题吸引，也许这也是我学习测试想要得到的，分享给大家。大家同乐。

   李和恒，微软亚洲工程院软件测试开发工程师，从事测试工作已三年，先后参与过视频编码、在线会议和企业级即时通信等产品的测试工作，并主持web应用测试架构的开发。技术兴趣为泛型编程，架构设计，测试自动化。

　　谈起测试项目经历 感觉走在开发人员前面

　　李和恒最近比较关注的是跨浏览器、跨平台的web应用测试架构，这也是为他正在参与的产品项目服务。很多web应用程序在浏览器上只运行HTML和Javascrīpt，软件测试工程师还是要花不少时间在不同操作系统上进行手工测试。他希望通过良好地支持自动化测试来减轻这方面的负担。目前一个从发动测试到结果收集全程自动化运行、支持多浏览器端并行协作的系统已经在支撑两个项目的自动化测试工作，下一步是构建web应用测试的编程接口、支持代码注入。将来和恒的目标是在微软把web应用测试做得和桌面及服务器应用的测试一样完美。

　　谈到最满意的项目，和恒告诉记者我他对在线会议系统的记录模块进行测试是最令他满意的工作经历。在那里，他接触并实践了微软最先进的测试理念。微软内部进行了大量的“模型驱动测试”实践：对产品建模进而自动产生测试用例。依靠这种技术得到的测试用例，自动运行以后覆盖了接近90%的产品代码，而他自己的工作量只是五六百行的代码、一个Visio文件外加必要的维护。翘着脚看软件开发工程师在用那堆测试用例暴露出来的bug里面扑腾的时候，他有时会想：“总算跑到你们前头去了”。

　　回顾所有的项目，和恒认为其共通之处在于对测试工作的热情和责任感。实际工作中软件测试工程师的每一步工作都会引发更多的工作：暴露一个bug，修改好，再检查，还是有bug，再修改......有可能会像擦地毯上的奶油一样越擦越大。在没有交付到客户手上之前，测试工作的效率看上去是自我递减的。这跟开发工作不同，他们是自我递增的。没有极大的热情和责任感，很难想象这样的工作得以维持下去。

　　测试就像寻宝一样 需要在最短时间内找到最值钱的宝物

　　每个测试人员在特质上可能有共同之处，但成长的经历却是不同的，李和恒在选择测试的工作的时候既有偶然的成分也有自主的选择。来微软面试的过程中，他从面试题里面感觉到一点不平常：总是在问如何测试自己写的代码。最后一关经理终于问他对软件测试工程兴趣如何，这着实出乎意料。不过和恒回想起所有面试题的意图，如果是从事简单的工作，犯不着问这么难，所以就答应了。三年之后的现在，经历了若干项目之后，如果再选择一次，和恒觉得自己还是会选择测试工作。

　　具备什么样的素质才是合格的软件测试工程师?软件测试的具体工作内容包括：理解用户的需求和体验，校正设计和项目计划，运用良好的测试方法和实践，撰写有效的测试计划，设计有效的测试用例，推动自动化测试，调查分析bug的根本病因，追求卓越的技术和业务能力，充分的团队合作，以及紧密地联系和关注用户和合作伙伴。

　　李和恒个人的理解是，软件测试就像沙滩上的寻宝人，你不可能知道沙里埋了些什么、有多少、在哪里。寻宝人要在尽量短的时间里面挖出尽量值钱的宝物。但极为讽刺的是，你不可能挖出所有的宝物，而且所有的宝物日后都会浮现出来，比如地震海啸地质运动什么的。在这里，测试工程师就是寻宝人，宝物就是bug。至于用什么办法寻宝，那是技术上的问题了。技术总是日新月异的，所以我对合格的软件测试工程师的期望是：狂热追求宝物，具有大局观，充分了解沙滩，最后才是了解并改革寻宝工具。

　　测试在架构下更简单

　　在沙滩上寻宝也是有沙滩的宽度的限制，同样测试工作也是需要在一定的规则下进行的。李和恒平时对架构设计很感兴趣，他告诉记者其实架构和测试是有相通之处的。 他所理解的架构是一组游戏规则，在这组规则的保护下人们可以关注更有趣的事情，这个理解对测试工作来说是一样的。软件测试工程师在架构的保护下可以关心更值得注意的事情。举个例子，篮球规则让进攻队员可以专心投篮而不用担心被推拉，违反规则的行为可以被清晰的观察出来。另一个技术上的例子是.NET framework 3.0里面的插件开发模型，以前软件测试工程师可能需要测试不同类型的插件实现方法，现在只需要留意插件相对于产品的功能。换句话说，架构或者说是规则，已经被良好的测试过了，值得信赖。