都说互联网测试，到底互联网测试和平常的有什么不一样(2)

　　3. 有更多的人参与到测试里面来

　　互联网公司里面，测试vs开发的比例都很低，1:6，1:7都是很常见的，甚至更高，在这样的配比的情况下，如果来保证质量?必须有更多的方法。比如

　　a. 开发人员的自测。

　　测试耗费更多时间很多时候是因为代码的质量不够好，有很多bug，有很多讨论，很多的拉代码的次数。所以提高开发提交的代码质量就是一个很重要的方面。有些公司是通过开发人员的强制的单元测试来保证的，有些是通过功能级别的自测来保证的。这些可以借助一些数据来反映，比如同一个版本拉代码的次数，或者测试用例的通过率等等。

　　b. 产品或者运营人员的体验。

　　很多互联网的产品不像传统软件产品，不是一个产品经理来提所有的需求。产品，或者称为产品经理，是一个团队，每人负责一块来提出需求。另外很多需求可能是来自于运营团队，和business相关，或者是不同系统的打通。每个产品经理或者运营，需要在开发人员实现了相应的功能之后到体验环境里面来试用产品，就是所谓的体验，看这些功能是不是他们想要的。这样就可以在测试人员测试之前保证没有明显的需求理解的问题，避免浪费测试的人力和时间。

　　c. 发布之前的评审。

　　不同的角色进来看对于一个已经测完的工作还有没有问题，以及发布的时候需要注意的问题，环境的问题，配置的问题，数据的问题等等。

　　上面的一些做法可能都有帮助，但是如何来推动，如果来检验都是需要流程和工具来支撑。

　　4. 有一些是免测试的

　　不是所有发布到现网的东西都需要测试，有些改动是不需要测试的。这个没有一定的标准，取决于具体发布的情况，以及产品和团队的成熟度等因素。比如一些临时活动的页面，一些小的图片或者样式的改动，一些小的修复等等。只需发布完了之后到外网去验证。

　　有哪些可以走免测，这其实是一个很复杂的问题，当然风险也是有的，但是因此而带来的效率的提高也是很明显。

　　5. 海量的用户带来的挑战

　　其实有很多，这里列举几个

　　a. 如何来保证或者验证性能

　　传统软件的性能测试相对要单纯一些，可以比较容易搭建一套环境，流量也比较容易模拟。而互联网的一个产品可能有几百上千台甚至更多的服务器，多地多层部署，受到各种因素的影响，比如广告促销活动，一下子流量可以冲到很高。所以这方面的做法也会有所不同，全量的模拟不太现实，而且如上面所说，发布非常快，也没有那么多的时间去反复的做性能测试。所以如何来做比较轻量级的性能测试也是一个很大的课题。

　　b. 浏览器的兼容性。

　　用户使用的浏览器种类可能非常多，包括大家都在骂的IE6，还有IE9的n种模式，版本更新速度火箭一般的Chrome和Firefox，以及很多种国产的浏览器。要一一覆盖是一个很大的挑战，其实不可能，但是产品团队肯定希望测试能够覆盖更多。对于一些企业级的产品可以宣称就支持很少的几种，但是互联网产品很难这样做，那就等于放弃一些用户。如何来设计策略?有没有技术手段?

　　c. 一个小的改动引起的问题可以影响到无数的用户，而且很多时候马上会被发现，那个压力还是非常大的。整个修复的过程也是带电操作，没有那么多环境和时间来在内部慢慢调整，如何来保证修复的质量?

　　6. 问题的修复

　　互联网的产品相比传统的产品的一个优势或者说是特性就是问题的修复比较快，因为很快就可以影响到用户，而不需要等用户一个个去打hotfix或者patch，甚至安装新版本。有很多时候，这种问题的发生到修复的时间很短，真是绝大部分用户都没有感知。有时候这个也会成为quick & dirty的一个借口，不过一般都会把现网的问题列为一个考核的指标。而且有些问题不是小问题，会构成事故。其实对于这样的产品，测试人员对于漏测的压力就更大了。

　　7. 测试工具和技术选择上的差别

　　大概是因为互联网自身产品的一些特点，各大公司都在大量的使用开源的，以及内部开发的平台和系统。相应的，测试方面用到的平台和工具主要也是这两种，要么是开源的工具(也可能做一些改造)，要么是内部自己开发的工具。相比而言，传统软件行业更会去购买一些商业的测试工具，比如用于性能测试、覆盖率或者代码检查的工具，还有就是测试用例和缺陷的管理平台。 目前我了解到的情况，国内几大互联网公司都是改造和自研的比较多，所以在简历里面列一堆大的工具的使用经验不一定有多大优势。而对于新人来说需要花不少时间来学习和熟悉这些平台。

原文转自：http://blog.csdn.net/superqa/article/details/7430619