互联网测试有什么不一样

　　最近一直有写这样一篇文章的想法，因为自己工作的变动，都是些零散的思路和想法，这里稍作整理，贴出来。正好假期的时候有朋友问到这方面的话题，希望也是一个参考。

　　其实说实话，觉得自己不是很够资格来写这个，毕竟开始做互联网测试的时间不长，很多方面还在摸索和catch up中。但是另一个方面，如果真都习以为常了反倒没有对比的新鲜感了也不想写了。再加之今天看到韩少的那篇写给不一样的自己，觉得把看法写下来，哪怕若干时日之后觉得现在的看法很stupid也无妨，那就是代表进步了。没有进步是最可怕的事情，不是吗?

　　当然，这个不代表公司的一些做法，更不能代表很多公司，也不能代表不同人，纯属一个刚开始从事互联网测试(但不是刚开始做测试)的人的一些个人观察和思考。

　　互联网行业的人有意无意的把非互联网的软件都称为传统软件，也就是说我们这种都是从“传统”行业，好吧，传统软件行业转过来的。也许在有些人眼里这个带有一些自诩的成分，当然更多人是为了区分。就像我们做IT的把其他比较实体的行业称为传统行业一样，似乎有某种优越感。这里不争论这些称谓，意义不大，有没有价值让市场去决定。如果把一件事情说得玄乎，那么主要有两种可能，没有搞明白，或者装高深。这两种都不太好，所以还不如看看到底有什么不同。

　　如果真要用传统软件行业这个词，那么这里是指的那种需要用户去安装客户端，或者需要客户的管理员在机房去部署的那种软件，放在光盘里也好，放到硬件里一起卖也好，又或者是为某客户量身订做的一套系统。

　　------------------------------- 废话的分割线 ------------------------------

　　变和不变总是永恒的主题。先说说我看到的不一样的地方。

　　1. 最大的不同就是互联网的产品很多都是自己来部署和运营，用户只要用一个瘦客户端就能使用。

　　这里的瘦客户端是一个浏览器，一个App，或者一个需要安装的client，但是核心的数据和业务逻辑主要在互联网公司的机房里面，在IDC，在云端。这里和以前的C/S, B/S架构的企业系统的主要区别在于为多大范围的人来服务以及谁来运营和运维这样的系统。所以自然的，就多了很多的这方面的工作。

　　缩小范围到测试这个方面，就需要考虑现网的问题。比如有下面的这些方面：

　　a. 如何来监控现网功能的可用性。

　　这个需要和运维一起来做，但是运维针对的是比较通用的部分，比如机器的资源使用情况、流量和带宽的情况，但是偏产品业务层面的，比如哪些功能是否可用，可能就需要业务测试人员来设计和开发自动化的系统来监控了。

　　b. 如何来发布功能到现网

　　测试完了一般直接就发布了，所以不像传统的软件有那么长的测试周期，包括internal beta，external beta等过程，而且我了解到的情况，很多基于web的互联网产品平均一天有多个发布，可大可小。所以发布可能就成了测试人员的工作，当然有相关的系统的支持。 这里还需要考虑的问题是常见的基于各种条件的灰度发布，先让部分用户用起来。发布完了之后还要做现网的验证。

　　c. 如何来保证或者验证测试环境和现网是同步的

　　一旦是互联网的这种模式，测试环境的问题就会变得比较突出，因为常常牵涉的系统比较多，有些和外部系统的接口可能很难以自己搭建或者用mock。另一方面如果保证测试环境是好的，到现网也是好的。需要相应的机制和工具来验证和同步。

　　2. 互联网产品的节奏都很快

　　不像传统的一个客户端或者服务器的软件产品，可能周期是半年，一年，甚至更长。这样有比较充足的时间来做项目计划，需求评审，然后是概要/详细设计，进而有测试设计文档，开大量的测试用例，然后有不同的测试cycle，同时也可以有很多的时间来准备测试环境和自动化测试。

　　就目前来看，互联网的产品这样做不太现实。这样对测试人员也是很大的挑战，可能看到一个需求过几天就要开测了，用例是临时开出来的，根本来不及自动化，也没有很多的时间来做测试设计，然后测两天这个功能就上线了。

　　不切身的感受很难体会到这种速度带来的差异。所以如何在这么短的时间里面来保证测试的覆盖度和质量，如果减少遗漏?

　　这是现实的问题，或者说是要求，有一些措施，但是其实也没有很好的答案。

原文转自：http://www.ltesting.cn/deltestingde/