7年之间，我已经数不清上线了多少个版本、运行了多少遍测试用例、提交了多少个BUG、奋战了多少个通宵达旦，但是忘不了每次战友离开时那淡淡的忧伤。
曾经多次有人问我，为什么你还不跳槽？
因为一份坚持，从我的leader、从我的BOSS身上学到的那份坚持。也许它听起来有点冠冕堂皇，但听我慢慢道来。
故事之一：
时间大概是在2009年。在浏览器各项指标中，项目组上下一直极为重视浏览器的稳定性指标，也就是浏览器的崩溃率。为了改善这一崩溃率，只是通过常规的手工测试手段是保证不了的，这需要使用自动化技术。
起先，我们使用了BHO技术来完成浏览器内核的自动化测试，自动化脚本可以使得浏览器自动地进行前进、后退、导航和刷新等操作。但是这一技术的缺陷是无法进行浏览器内核以外功能的自动化操作，所以随着新功能不断地增多，BHO技术已经无法满足。
之后，我们尝试使用业界比较成熟的QTP进行自动化测试，通过控件识别+键盘快捷键等方式，内核之外的功能也逐步纳入到稳定性测试之中。但是随着浏览器2.0版本的发布，内核变为Trident+Webkit双内核，QTP无法有效识别Webkit内核的控件。
... ...
查看更多精彩内容，请点击下载：http://www.51testing.com/html/07/n-3649907.html
诸多的困难之下，我逐渐对自动化丧失信心，开始质疑这一方法的可行性。在我的学习经历中，所接受到的知识是自动化技术是用于解决重复性的、有预期结果的测试用例回归，我们只能让机器按照我们提前设定好的步骤去执行，然后对比实际结果是不是符合预期。而使用自动化技术进行随机性的操作去发现未知的问题，这行不通。
因为这个问题，我和我的老大鲁剑争论了多次，我坚持认为证明自动化发现不了未知的问题，过去一年多的实践就是最好证明。而鲁剑始终坚信自动化可以发现影响浏览器的稳定性问题，未来可以作为评估浏览器的上线标准。
我放弃了，但是鲁剑没有放弃。
他后来做了两件事：第一，让测试开发林飞使用python重写稳定性自动化脚本，以此来克服QTP的诸多问题。第二，让林飞每天查看浏览器的崩溃栈，根据栈信息分析可能的操作路径，然后将这些操作路径转化为自动化脚本。这项工作大概持续了一个月之久，林飞通过每天不断地动作补充，建立了三百个庞大的浏览器动作组合脚本。基于python面向对象的特性和更为高效的随机算法，稳定性脚本在效率、问题发现能力和脚本可维护性上都取得了进步。
通过这个脚本，我们多次在测试阶段就发现了潜在的崩溃问题，避免了问题的遗漏。这一通过随机浏览自动化测试的方式，已经成为国内浏览器厂商必备的评估方法。
故事之二：
时间大概也是在2009年，距离搜狗浏览器第一个版本上线后的半年。有一天，公司突然发全员邮件，告知王小川已不再管理搜索团队，只负责桌面团队的管理工作。这意味着什么，小川管理的团队拦腰砍半，原因可能是老张Charles和小川意见不合，不支持研发搜狗浏览器。
一般人遇到这种情况，自己努力工作却不被上级老板支持，也许就此放弃收拾收拾就走人了，但是在我眼里的小川是这样的：
... ...
查看更多精彩内容，请点击下载：http://www.51testing.com/html/07/n-3649907.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
