测试就像寻宝一样 需要在最短时间内找到最值钱的宝物
每个测试人员在特质上可能有共同之处，但成长的经历却是不同的，李和恒在选择测试的工作的时候既有偶然的成分也有自主的选择。来微软
面试的过程中，他从面试题里面感觉到一点不平常：总是在问如何测试自己写的代码。最后一关经理终于问他对软件测试工程兴趣如何，这着实出乎意料。不过和恒回想起所有面试题的意图，如果是从事简单的工作，犯不着问这么难，所以就答应了。三年之后的现在，经历了若干项目之后，如果再选择一次，和恒觉得自己还是会选择测试工作。
具备什么样的素质才是合格的软件测试工程师？软件测试的具体工作内容包括：理解用户的
需求和体验，校正设计和项目计划，运用良好的
测试方法和实践，撰写有效的
测试计划，设计有效的测试用例，推动自动化测试，调查分析bug的根本病因，追求卓越的技术和业务能力，充分的团队合作，以及紧密地联系和关注用户和合作伙伴。
李和恒个人的理解是，软件测试就像沙滩上的寻宝人，你不可能知道沙里埋了些什么、有多少、在哪里。寻宝人要在尽量短的时间里面挖出尽量值钱的宝物。但极为讽刺的是，你不可能挖出所有的宝物，而且所有的宝物日后都会浮现出来，比如地震海啸地质运动什么的。在这里，测试工程师就是寻宝人，宝物就是bug。至于用什么办法寻宝，那是技术上的问题了。技术总是日新月异的，所以我对合格的软件测试工程师的期望是：狂热追求宝物，具有大局观，充分了解沙滩，最后才是了解并改革寻宝工具。
测试在架构下更简单
在沙滩上寻宝也是有沙滩的宽度的限制，同样测试工作也是需要在一定的规则下进行的。李和恒平时对架构设计很感兴趣，他告诉记者其实架构和测试是有相通之处的。 他所理解的架构是一组
游戏规则，在这组规则的保护下人们可以关注更有趣的事情，这个理解对测试工作来说是一样的。软件测试工程师在架构的保护下可以关心更值得注意的事情。举个例子，篮球规则让进攻队员可以专心投篮而不用担心被推拉，违反规则的行为可以被清晰的观察出来。另一个技术上的例子是.NET framework 3.0里面的插件开发模型，以前软件测试工程师可能需要测试不同类型的插件实现方法，现在只需要留意插件相对于产品的功能。换句话说，架构或者说是规则，已经被良好的测试过了，值得信赖。
采访后记
与和恒聊了很久，话语间提到在微软工作的收获，他认为最大的收获莫过于发现测试工作是一个未被开发的金山，莫过于跟一群具有智慧和热情的人们共同开发这座金山，莫过于发现自己还挖了不少好东西。最后记者希望他推荐本书给广大的
程序员，和恒拿出一本John Lakos的Large-Scale C++ Software Design，大规模C++程序设计，告诉记者说那里面介绍的系统分析方法使他从只关注自动化测试转向了解系统结构。
说的真不错啊。。。
