作为测试领域里混了十三年，在eBay也工作八年之久的一名质量工程师，一直想写一下eBay的测试。进入ebay之前也在别的公司工作过，深知软件测试的弊病。在eBay，也看着它一步步地从注重生产流程演变为注重技术创新的测试模式。
eBay的软件测试工程师称为QE(Quality Engineer)。我们许多项目都采用敏捷开发，每两周一个迭代，PD(开发)和QE(测试)有着清晰明确的分工。开发人员负责软件的设计和实现，同时还负责编写单元测试。我们用Jenkins来做持续集成。code每次checkin之后会自动触发编译，测试和打包。我们要求单元测试的覆盖率达到85%以上。code coverage的结果会由Jenkins的Sonar插件发布到统一的Sonar服务器，可以通过sonar来查看覆盖率是否达标。PD自身对代码要求也很高，经常重构改善代码，这时unit test就能让他们放心地去重构，对于这样的PD,本身也是很有意识地去写unit test。所以我们可能比许多其他公司在推行unit test的标准时遇到的抵触要小得多。这对于产品质量是非常重要。现在很多公司都意识到测试应采取金字塔结构，越底层的测试越要覆盖得广。因为越到上层，测试的代价就越高。这在ebay尤其典型。有些flow很长，一个case跑一个小时，还容易错，等整套测试跑完，黄花菜都凉了！所以能用unit test覆盖就写unit test，能用service test覆盖，就不写ui test，能写短的flow，就不写长的，用少量的end2end测试来做长flow的校验。
单元测试之后，Feature test就属于QE的职责范围了。对于Domain的QE需要熟悉许多相关的领域知识。但不仅仅是页面的功能，包括数据库，service的协议，跟其它Domain的交互接口等都要熟悉。PD也经常需要依赖QE的帮助来创建各种需要的数据。eBay整个网站非常复杂，各个领域之间有着错综复杂的联系，往往新人进来需要相当长的时间才能对各个方面都了解。ebay神奇的地方在于人员的稳定性。我原来部门的同事在ebay待的平均年限居然达到五六年！
在集成和系统的角度编写test case后进行手工测试,之后就要尽快编写自动化测试，不然以后一轮轮的迭代使回归测试的压力越来越大。而我们对于feature的自动化率也有定量的要求。我们部门基本上达到百分之八九十。公司内部开发了一些自动化测试的框架来使QE更好的开发自己的测试用例。对于Web测试，我们是Selenium社区的活跃用户，并且拥有Selenium Grid, Selndroid, iosDriver等框架和工具的开发者和贡献者。
这些自动化测试也都通过CI来定期运行。由于ebay 测试环境很复杂，测试案例碰到的问题和挑战会很多，我们需要通过不断的创新，使用各种技术来解决这些问题， 所以对于Ebay的测试人员的开发能力要求相当高。这是与传统测试不同的地方。难怪有人提出测试已死的说法，我的理解是那种单纯做手工测试的测试已经无法在现在这种快速迭代的开发方式下生存了，取代它的是新的，先进的，以自动化测试为代表的高生产率的测试方式。尤其是我目前所在的平台部门，所测试的产品都是底层框架，云计算，开发工具等产品，本身用户群体就是开发人员，更是需要用编程的方式来验证功能，需要自己编写合适的测试框架，整个测试全程基本上都是自动化。
最早ebay也采用一些商业测试软件来作为测试的工具，现在这类商业工具越来越少。我们更倾向于使用开源工具或自己开发的工具来帮助我们测试。我们也喜欢基于这些开源工具，做一些定制化与扩展来满足我们的一些需求。在我们的眼里，这些工具都能随意组合，以实现测试全过程的自动化。
除了这些工作，QE也需要参与design review, code review, release, support等工作中。而且我们也会在公司内外分享我们的经验与技能，这样，我们才会不断地学习，不断的提高我们的技术水平，同时激发创新的灵感，在提高自我的同时也创造更好的业绩。这就是我眼里的eBay软件测试，希望给你一点启发。
本文首发于微信公众号“小贝爱测试”
转载请注明原文出处