本文是关于一个遗留项目的测试思路。
Google Desktop是一个艰巨的项目，因为它有着几千万的用户、兼有客户端和服务端组件、并与Google搜索集成在一起。在我我之前，已经有很多人负责过这个项目的测试，遗留了一些质量和其他问题。项目很大，但是开发的节奏已经放慢，经过几年的使用，风险已经极大降低。
当我和其他两个同事进入这个项目，Google Desktop共有大约2500个测试用例，保存在TestScribe用例管理系统中，有几个外包人员在维护测试用例。一个测试周期经常达到一周甚至更长。之前有过一些尝试，试图通过UI和可访问性钩子进行自动化，但是最终由于问题的成本和复杂性而失败了。很难通过C++代码同时驱动Web页面和桌面视窗UI，此外，超时问题也不断的发生。
选择工具：我们决定采用一个Python测试框架，此框架通过Web DOM驱动产品，具有基本元素，例如一个继承自PyUnit的测试用例类。另外使用Python的TE和SET非常多，随时可以找到人帮忙，还有就是Python开发速度快，并且所有机器上都默认安装。
高优先级覆盖：我们使用ctypes驱动客户搜索的COM API，模拟服务器端的响应来讲本地结果注入到google.com的结果之中。首先建立了一个小型的、自动化的冒烟测试集来覆盖高优先级的功能。
整理遗留用例：我们分析了遗留的2500个测试用例。由于其中很多用例难以理解，缺乏文档说明，并且有太多的关于机器的上下文假设，引用了项目早期的原型或已不存在的特性中的暗语。经过分析，基于自己对产品的理解，保留了最重要的最有意义的150个用例，丢掉了其他，用例数降低了一个数量级。然后修改剩下的用例，讲测试步骤做到足够详细和清除。
自动化回归：我们有了自动化用例和对每个版本的回归测试，以及任何一个人一下午就能执行完毕的测试时间。同时解放了人员，使得他们有时间去做更高价值的事情。
潜在问题处理：在移交Desktop进入维护期之前，有一个bug不断出现，始终无法定位。测试团队不断督促PM和开发介入，最终找回了原来负责的开发人员，定位到了问题，彻底解决了这个bug。
How-to文档：我们编写了一份简短的文档，描述如何执行自动化和手工测试。
