Tag: 软件测试

在代码签入之前运行测试

很久没有写文章，看着每天仅有的可怜的访问量，实在觉得对不起读者，决定再写点什么吧。

测试工程师应该做什么？如何体现测试工程师的价值？类似的问题如果放到一些测试会议或者沙龙上讨论，估计一定很热闹。每个人心中都有自己的认识和答案。我个人理解的较为简单，假如整个团队没有测试，会达得到什么样的一种成就？那假如把测试加进去这个团队，能否帮助大伙提高成就？如果测试是在做正功，那么就是有价值，至于价值多少不容易衡量，如果测试在做负功，那还是自求多福吧。

软件天生就有缺陷（Defect, Bug），缺陷从哪来？缺陷从不平白无故地出现，它总是伴随着功能（Feature）而来，谁创造了功能？随便啦，但是最后通常来是开发工程师动手的，所以大部分时间开发都会负责修bug。一般的流程都是：1. 写了一些功能； 2. 测试；3. 发现一些bug；4. 修bug。如果我们可以加速这个反馈的时间，那么也算是做了正功了。

在网上找到一张很好的图： http://www.jetbrains.com/teamcity/features/delayed_commit.html 很好的解释了怎么样在真正提交代码之前运行测试。至于如何做，基本上每个代码管理工具都有类似的支持，例如Git的Hook： http://git-scm.com/book/en/Customizing-Git-Git-Hooks， 又例如一个号称更加好的Hook：https://github.com/jish/pre-commit，SVN也行：http://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.pre-commit.html

我只分享一下我自己在使用上的一些经验：

  • 如果你的测试是Flaky的，不要放在pre-commit里面去。一切看起来很没好，但是如果当开发经常在写完一段代码正准备提交的时候，被一个fail的测试挡住了，然后花了半天时间发现不是他的代码有问题而是测试有问题，结果谁都不太爽
  • 不要把大量的end to end测试放在pre-commit里面跑，想一下让你跑10分钟测试才能提交代码，你能不抓狂吗？
  • 要让开发写测试，而不是测试工程师写测试。这样做的好处是开发自己了解测试代码，可以自己修改测试，更新测试，而不需要等测试来做修复。另一方面，产品质量真的不是测试工程师能保证的，大家测才是真的测
  • 不要在刚开始的时候就添加过多的测试，少量的测试总是比较容易跑过并且让大家接受
  • pre-commit测试不是万能，千万不要生搬硬套

开发人员与测试人员比例

上周末去参加了第二届（杭州）互联网测试技术交流会，下午结束了以后有个小型的交流会，会中淘宝的郭芙在自我介绍的时候提出了一个问题，就是开发人员与测试人员比例多少才是合适的呢？这个话题引起了各位嘉宾们的踊跃讨论，infoQ的泰稳整理了这次讨论（推荐看1楼回复），我也想谈谈自己的一些看法。

其实算上实习，我已经在4个公司工作过了，回头来看看这些公司研发团队的开发测试比例，从一个小职员的角度。

第一个公司是一家年收入10亿美元的百年老店，传统软件企业，在那里，开发和测试的比例大概是3:1。作为一个传统的软件企业，这家公司的自动化测试在那时候（2006年）才是刚起步，公司内部有较为规范的流程，QA在公司里面的工作大概就是从需求文档开始到各种设计文档进行review，之后dev开始写code，这时候QA也开始写测试用例，当时用的是QC。写好以后QA会review用例，然后就开始执行用例（真的是step by step，不夸张）。一个人一天如果能执行完40个用例，那是相当的高效率。3:1这个比率，看上去挺正常，但是其实QA做的工作并不多，总的来说QA的工作效率不是很高。在自动化测试程度不高的情况下，要保持产品质量，所以需要更多的QA来达到这个要求。我个人认为3:1的比率有点高。

之后在一家做统计分析的美资企业实习过一段时间，这个公司现在已经被IBM收购鸟……在这个公司，开发和测试比大概是2:1。QA的工作主要是阅读设计文档，设计测试用例，执行测试。同样，我觉得这个公司跟之前那个公司有着相同的问题，自动化测试程度不高，但是产品的质量要求非常高，所以需要更多人力物力在QA团队，而且由于各种各样的问题，团队的效率好像不是非常高。所以2：1这个比率有点高，但是其中是有他的原因的。

在MySpace，我们的开发测试比大概是5:1，互联网公司，要的就是一个快字，所以对产品的质量不需要很高，有Bug没关系，只要改的快就行了，抢在竞争对手前把产品发布出去才是根本。那时候基本上是一个人负责一个项目，一个项目可能持续2~3个月，完了以后继续第二个项目，QA要做的事情是，在拿到产品的设计文档以后，跟开发一起开会做设计，做测试用例，测试，上线，回归。我做的是后台的测试，所以我这边其实是4个开发写的代码给我1个人测试，那些接口测试用例其实都是自动化的（VSTS的mstest）。所以工作基本能很好完成。在这个互联网公司，有互联网的血统（快），但是对产品的质量要求也不低，QA做的工作比较细（其实主要是要经常性地在IE6的样式上纠结）。在自动化测试开展的还可以的情况下，比率是5:1。

终于到FreeWheel了，首先说一下我们的开发测试比，1.2:1，具体说就是12个开发对10个测试。说一下那么多QA都是干嘛的呢？QA的工作主要是拿到PM的设计以后，参与开发的设计，之后设计用例，测试，把测试转化为自动化回归测试（其实很方便的）；解答客户遇到的各种问题（为什么我的广告没出来，我想要XXX的数据，等等）。我个人觉得这套服务的特点是（相对于其他系统来说）商业逻辑非常复杂，软件本身的复杂度相对商业逻辑来说较低。据我的工作的体会，DEV很少会出现比较低级的bug，出现bug的地方大多数都是在商业逻辑上，说白了这是一套business driven的系统，客户需求是第一位，如果他说要一个算法，要1+1=7的，都是要实现的。所以QA在看需求的时候需要看的非常细，所以就需要更多的QA，并且会花比较多的时间去解决客户遇到的问题。

这个开发测试比，基本上每家公司都是不一样的。这个原因有很多，公司传统，领导风格，人员素质，工作内容，等等……如果离开了当前公司的这个Context去谈开发测试比，并没有太多的意义。就譬如说两家公司的开发测试比都是3:1，但是其中一家公司的可能很糟蹋，另一家很高效。谈这个开发测试比例，最好是在相同的类型的公司（创业型VS大公司），相同的行业（互联网VS传统），人员素质在同一个水平，等等。。。在这些前提条件下，如果发现自己的所在的组织的效率不如其他公司，可以参考同行有什么好的实践，取其精华去其糟粕。

开发测试比例只是浮云，整个组织的效率才是关键。

C/C++代码覆盖工具gcov与lcov入门

gcov是一个可用于C/C++的代码覆盖工具，是gcc的内建工具。下面介绍一下如何利用gcov来收集代码覆盖信息。
想要用gcov收集代码覆盖信息，需要在gcc编译代码的时候加上这2个选项 “-fprofile-arcs -ftest-coverage”，把这个简单的程序编译一下

gcc -fprofile-arcs -ftest-coverage hello.c -o hello

编译后会得到一个可执行文件hello和hello.gcno文件，当用gcc编译文件的时候，如果带有“-ftest-coverage”参数，就会生成这个.gcno文件，它包含了程序块和行号等信息
接下来可以运行这个hello的程序

./hello 5
./hello 12

运行结束以后会生成一个hello.gcda文件，如果一个可执行文件带有“-fprofile-arcs”参数编译出来，并且运行过至少一次，就会生成。这个文件包含了程序基本块跳转的信息。接下来可以用gcov生成代码覆盖信息：

gcov hello.c

运行结束以后会生成2个文件hello.c.gcov和myfunc.c.gcov。打开看里面的信息：

-: 0:Source:myfunc.c
-: 0:Graph:hello.gcno
-: 0:Data:hello.gcda
-: 0:Runs:1
-: 0:Programs:1
-: 1:#include
-: 2:
-: 3:void test(int count)
1: 4:{
-: 5: int i;
10: 6: for (i = 1; i < count; i++)
-: 7: {
9: 8: if (i % 3 == 0)
3: 9: printf (“%d is divisible by 3 n”, i);
9: 10: if (i % 11 == 0)
#####: 11: printf (“%d is divisible by 11 n”, i);
9: 12: if (i % 13 == 0)
#####: 13: printf (“%d is divisible by 13 n”, i);
-: 14: }
1: 15:}

被标记为#####的代码行就是没有被执行过的，代码覆盖的信息是正确的，但是让人去读这些文字，实在是一个杯具。不用担心，有另外一个工具叫lcov，可以用程序解析这些晦涩的字符，最终输出成html格式的报告，很好吧！

lcov -d . -t ‘Hello test’ -o ‘hello_test.info’ -b . -c

指定lcov在当前目录“.”去找代码覆盖的信息，输出为’hello_test.info’ ，这个hello_test.info是一个中间结果，需要把它用genhtml来处理一下，genhtml是lcov里面的一个工具。

genhtml -o result hello_test.info

指定输出目录是 result。一个完整的html报告就生成了，做一个连接，把这个目录连到随便一个web server的目录下，就可以看报告了。

Continue reading “C/C++代码覆盖工具gcov与lcov入门” →

内部自动化测试交流有感

上周公司组织了一个交流会，主题是关于自动化测试，这个已经在公司引起高层们足够重视的话题，说是交流会，其实我更觉得是个成果展示会，本人代表CORE QA跟大家分享了一下我们组内自动化测试的一些情况，并且在做的过程中的一些经验。我是第一个，下面是VI的自动化测试，VI主要是跟Video播放器结合的比较紧密，最后是UI同事的介绍。我从头到尾都参与，所以说说的我感受吧。

CORE这边测试的特点就是，针对MRM系统的后台进行测试，肩带来说就是模拟各种跟后台打交道的“程序”的工作，进行测试。我们测试有以下特点：

  1. 直接跟后台程序交互，基本没有现成的开源或者商业工具可以支持自动化测试快速开展
  2. 测试验证结果大多数是后台的输入，也就是前台或者是第三方系统的输入，所以验证的方法不能简单地观察输出结果，同时需要知道后台的输出拿到别的系统能否正常工作
  3. 牵涉到数据迁移或者数据重处理的时候，QA需要直接读取生产环境的数据进行校验

由于以上特点，所以我们的自动化测试85%都是自己开发工具来做，常用的脚本语言是Python，经常用到的一些模块包括读取MySQL的MySQLdb；csv模块；re模块；总得原则就是把重复性强，容易引入错误的工作都写成小工具。并且尽可能使用已有的成熟的库，而不是自己重复发明轮子。例如我们的前端页面使用了web.py轻量级框架，JSON库。到目前为止，我自己感觉我们的自动化测试还是做的不错的，主要是以下几点

  1. 简单。说起自动化测试，可能有部分人，或者说是外行的人吧，都觉得这个东西非常酷，人只要倒杯咖啡看着电脑执行测试就好了。但是其实实用有效的自动化测试并不是说看起来有多酷，而是这个东西能把人从重复劳动中解放出来。
  2. 强大。我刚到公司的时候，已经有600多个回归测试跑在自动化框架上，我当时就觉得已经挺不错的，因为这个自动化测试是由大概4~5个不同的人做的，我以前在MySpace的时候SOA大概有300个CASE，不过那都是我一个人做的，相比较而言FreeWheel应该是更好。
  3. 持续改进。虽然我刚到公司的时候自动化测试已经存在并且也算是行之有效，但是任何系统都是有可改进的空间的，我把前端UI改了一下，很高兴可以帮助大家缩短了找问题的时间
  4. 全面。基本上所有的模块都有自己的一堆自动化测试工具。

引用一句我非常喜欢的英语：So far so good。那下面我想做什么事情呢？

  1. 自动化测试其实不是测试，只是重复运行测试用例而已。真正的测试用的是脑，而不是工具，工具只是辅助我们的工作的
  2. 自动化测试是危险的，不要看到所有回归测试都通过了，就高枕无忧
  3. 手动测试才是根本
  4. 希望能给大家灌输一些思想，如果发现自己在重复做一件事情，那么应该停下来，想想有什么办法能够让自己停止重复，尽可能自己解决问题，培养自己的动手能力
  5. 看看有没有一些开源工作能让现在的工作做的更加好

下面说说对VI TEAM自动化测试介绍的一点感觉吧，VI和CORE有点儿相似，就是都是用的自己开发的自动化工具，而没用应用了太多开源工具，我个人觉得这里面原因有2个

  1. VI的测试面向Video播放器的SDK，也是一个后台，所以也没有太多现成的工具
  2. 用户怎么用我们的SDK？就是调用接口，跟CORE面对的问题相似

估计由于经常跟XML打交道，所以VI的自动化测试用到很多XML文件作为配置。由于隔行如隔山，所以没有看懂里面的一些玄机，总的来说就是跟我们CORE有点相似。

我们CORE和VI一样，这些工具如果跳出了这个公司，基本上就不能应用到其他地方，这也是对整个系统来说的底层部分做自动化测试的特点：高度定制化，通用性低，自己开发居多

最后就是UI的介绍，终于等到一个看得懂的啦。

UI那边就是大量使用开源工具，这个也是很有道理的

  1. UI的自动化测试实施难度比后台程序的自动化要大
  2. 现有的UI自动化测试非常丰富

那我们的UI是怎么做的呢？首先UI的同事用了一个持续集成的工具hudson作为一个颗粒度比较粗的测试用例管理工具，hudson作为自动化测试的主心骨，QA们可以在hudson上触发自动化测试的运行，运行完了以后可以看到测试结果，并且，利用了hudson的分布式结构，由多个测试机来执行测试，达到了很好的资源调配。对浏览器的控制方面，用了Selenium，会上没有问UI是否利用了Selenium的多浏览器支持，从演示上来看应该只做的Firefox的。他们的分工很明确，分了专门做功能测试的QA和专门做自动化测试工具开发的SDET，SDET主要是负责写RUBY代码，封装并且暴露了一些通用的方法给QA使用，并且同时使用了Cucumber作为一个DSL，QA是用Cucumber来做自动化测试的一些描述，Cucumber的作用就是对功能测试的QA屏蔽了底层RUBY脚本，对上就是“翻译”功能测试QA的意图，“翻译”成RUBY。说一下我觉得的优点：

  1. 分开了自动化测试工具开发和自动化测试实施
  2. 使用了大量开源工具，提高效率
  3. 而且都是业界常用工具，对以后跳槽帮助不小（嘿嘿）
  4. One click automation (只需要点一下hudson）

一些工具带来的制约

  1. 一次只能运行一批测试，不能重跑单个测试
  2. 个人觉得使用XPATH作为对象的识别并不是一个好的选择

总得来说大家都各有特色，并且都做得挺好，并且都有不少可以提高的空间。多点交流的确能带来不少灵感。

TestLink不能连接BugZilla的解决办法

TestLink是一个基于Web的PHP开源测试管理系统，虽然用起来跟QC那些商业软件比起来不是那么爽，但是由于是开源、免费，所以越来越多的公司在用TestLink。BugZilla作为老牌的bug管理工具，同样有着很大的用户群。

TestLink有一个BugTracking的接口模块，可以使得TestLink可以与其他BugTracking系统集成。在集成的过程中发现TestLink提示错误：Bug ID does not exist on BTS（中文的话是’bug的ID在BTS中不存在！’），找到TestLink的代码文件bugAdd.php，找到下面这段代码块

if($args->bug_id != "")
{
	$msg = lang_get("error_wrong_BugID_format");
	if ($g_bugInterface->checkBugID($args->bug_id))
	{
		$msg = lang_get("error_bug_does_not_exist_on_bts");
		// 问题在这里
		if ($g_bugInterface->checkBugID_existence($args->bug_id))
		{
			if (write_execution_bug($db,$args->exec_id, $args->bug_id))
			{
				$msg = lang_get("bug_added");
				logAuditEvent(TLS("audit_executionbug_added",$args->bug_id),"CREATE",$args->exec_id,"executions");
			}
		}
	}
}

问题出在$g_bugInterface->checkBugID_existence($args->bug_id)这个方法中。在、TestLink的int_bugzilla.php文件中，并没有overload这个checkBugID_existence的方法，所以这个方法就会按照int_bugtracking.php中的默认实现，返回false。TestLink就会出现error_bug_does_not_exist_on_bts这个ERROR

解决这个问题很简单，就是在int_bugzilla.php中自己实现checkBugID_existence方法，简单的实现如下：

function checkBugID_existence($id)
{
	$status_ok = 0;
        //关键是下面这个Query bug id的语句，大家自己看看数据库是哪个表，根据实际情况自己修改
	$query = "SELECT bug_id FROM bugs WHERE bug_id='" . $id ."'";
	$result = $this->dbConnection->exec_query($query);
	if ($result && ($this->dbConnection->num_rows($result) == 1))
	{
		$status_ok = 1;
	}
	return $status_ok;
}

OK。在int_bugzilla.php文件中添加了 checkBugID_existence() 方法后，就可以从TestLink中直接把BugZilla里面的BUG ID和某个测试关联起来了。

谁来保证测试工作的质量

在一个公司或者是某个组织里面，测试人员扮演的角色通常都会被认为是软件质量的保证者，把关者，仿佛经过测试的产品都是没有任何缺陷的。但事实大家都知道，即使经过多么“完美”测试的产品，总免不了在发布以后还会发现或多或少的问题。

以前在MySpace做测试的时候，主要是写代码来测试一些接口、模块等。这样就会出现一个问题，我用一段程序A去测试层序B，那么测试代码也是程序，如何保证程序A的正确性呢？OK，我们可以写一个程序C去测试程序A，由此来保障程序A的正确性，但是程序C的正确性又由谁来保证呢？who watches the watchers？当时只有我一个人负责白盒测试，最多也就是让开发帮忙看看。其实对于一段程序，只要写的足够简单，那么就可以认为这段简单的程序的正确性是能得到保证的。所以我一直都给自己强调，单元测试的代码不要写的复杂，尽可能不用判断，让测试代码顺序执行下去。

但是对于功能测试来说，怎么样才能尽可能地保证测试的方法，测试的数据，测试的覆盖率是能达到某项标准的呢？在这次MRM 2.9 Release的测试过程中，我们引入了peer review的做法，一个功能点一般会以ticket的形式存在，每个人拿到ticket的时候首先自己设计测试用例，包括测试数据的准备，用什么样的方法等等。然后找另外一个同事来review自己的用例。这样做的好处有：

  1. 强迫自己有一个较为系统的测试用例设计，因为这个是需要给同事看，并且让别人看懂的
  2. 同事之间的knowledge share在不知不觉中就达到
  3. 两个人的review总是比一大群人坐到会议室里面要有效，帮助提高测试覆盖率，尽可能避免测试盲点
  4. 互相监督

敏捷测试只是手段不是目的

首先我要声明：本人不懂敏捷测试。
敏捷开发在这两年一直很火，很多时候作为一个测试人员，经常会“被敏捷”。一些常见的现象有，当你所要文档的时候，相关人员可能会告诉你“我们是敏捷开发，没有文档”；当你索要进度表的时候，答案也是相似的。既然软件开发已经迈入了敏捷时代，那么软件测试还能原地踏步麽？那什么是敏捷测试？我不知道，不过我想说说我在“敏捷”组织里面进行软件测试的经历。
由于我不懂敏捷测试，所以我不知道它的定义，我只能通过“敏捷测试不是传统测试”这样的思路来开展工作。
首先，那种拿着各种需求文档设计文档来设计Test Case的日子是一去不复返了，因为敏捷开发强调的是能工作的软件比漂亮的文档要有用，人和人之间的沟通胜于文档。所以作为我，一个测试员，我对被测软件的知识的了解来源有2个方面，第一是代码，第二是开发人员。
其次，如果在测试过程中发现一个问题，第一件事情并不是把这个问题记录在Tracking system里面，而是找相关的开发和产品进行确认，究竟这是不是一个真的Defect。
然后，需要知道一个现在很流行的新玩意儿：探索性测试（Exploratory Testing）。每个人对Exploratory Testing的定义都不一样，最近两个大牛（James Bach, James Whittaker）也在掐架。我觉得如果简化这个定义的话，就是我们一边熟悉被测软件，一边进行测试，在测试进行的过程中，随着对软件的熟悉，继而设计出新的Test case来对被测软件进行测试，我个人觉得就像是一个小的迭代一样。
最后，忘记敏捷测试这个词。我觉得现在业界能说清楚这个概念的人很少，所以没有必要在这些定义上纠结。人们为什么要实施敏捷开发，是因为想交付更好的软件；我们为什么要实施敏捷测试，是想提高测试的质量以及生产力，从而帮助公司交付更加高质量的产品，至于是不是真正的敏捷，又有什么重要的呢

窥探云测试

云计算是当今的一个热点，也是一个潮流，那么软件测试能否借助云计算的威力而更上一层楼呢？最近看了几个号称云测试的网站，有感，记录一下。

第一个网站是Cloud Testing。这个公司能提供多种平台，多种浏览器的平台，一般的用户在本地用Selenium把自动化测试脚本编写好，然后上传到他们网站，然后就可以在他们的平台上运行Selenium脚本了。他们的优点是：平台和浏览器覆盖得广，按需付费。不过我自己对这样的服务有以下的疑问：

  1. 基于UI的自动化测试通常都会遇到一些不稳定的问题，本地编辑好的自动化脚本是否也能够在他们的平台上正常运行
  2. 如果出现错误，有没有办法进行调试。究竟这个错误是SUT的错误，还是测试脚本的错误，如何区分
  3. 用户自己开发的插件能否在这个云测试平台上使用（我觉得是不行的）

总得来说Cloud Testing是一个基于UI自动化测试的云测试平台，但是我认为这样的平台并没有太多的优势，一般做互联网的公司产品发布都是比较快的，根本是不可能有时间和资源去覆盖所有的浏览器和平台，根据80/20原则，在中国搞互联网，只要搞定Windows下的IE6和IE7基本上就万事大吉了，一般好一点的前端TEAM都是在Firefox下进行开发的，所以Firefox的兼容应该是不成问题，最后在Chrome和Safari上过一下关键流程，差不多了。再说，现在虚拟化技术日渐流行，自己搭建多个平台也不是非常耗费资源。

第二个是keynote公司的kite，这个感觉比Cloud Testing更加弱一点，kite有自己的浏览器，然后用户在这个浏览器上录制脚本，然后上传，然后可以在keynote公司不同的可用地点中运行测试，查看结果。这个平台给我的感觉更多的是关注终端用户性能，里面有一个页面元素下载的timeline，用户可以查看那些页面资源下载花费多少时间，DNS查询时间等等……

这个平台的问题有：

  1. 可用的节点不多，现在为止只有北美地区的几个节点可用
  2. 专门的工具，可能对测试的结果有影响

估计是keynote公司的一个实验性产品。

第三个是SOASTA。这个公司不单只提供了功能测试，而且还有性能测试。感觉上性能测试应该是利用云计算的一个非常重要而且有意义的点。貌似这个公司不是那么开放，没有太多公开的资料，所以不知道他们是怎么运作的。看他们的网站的一些成功案例，说的挺好，不过这样相对于在公网做性能测试，不知道会不会有问题：

  1. 带宽问题，例如云那段设定的带宽是1Mb，那么云和端之间的带宽是否能真正达到1Mb呢
  2. 安全问题，这些性能测试的脚本不会日后成为攻击的工具吧

突然觉得，现在做CDN的公司，其实他们可以兼营性能测试，因为他们的服务器分布的跟真实情况最接近的，而且也有足够多的服务器资源和带宽。

推荐阅读：5 Ways to Revolutionize Your QA

James Whittaker，两个月前还是微软Visual Studio的一个产品经理，好像是负责VSTS 2010的最新产品Lab Managment。现在已经跳槽到Google做测试总监了。

若干个月前他在utest有一个讲座，题目是《5 Ways to Revolutionize Your QA》，今天早上我又翻出这个文档仔细看了看，觉得真是受益匪浅，推荐推荐，在这里可以下载《5 Ways to Revolutionize Your QA》。

主要讲了5条：

Insight 1:  There are two types of code and they require different types of tests
Insight 2:  Take your testing down a level from features to capabilities
Insight 3:  Take your testing up a level from test cases to techniques
Insight 4:  Improving development is your top priority
Insight 5:  Testing without innovation is a great way to lose talent

其中我个人对第一条和最后一条感触比较深，第一条里面提到了当年Vista就是过分信任自动化测试，结果……大家都能看到；第五条就解释了为什么在测试这个行业，大牛那么少，而牛人又经常转做开发或者别的工作去了。

James Whittaker在微软的博客

James Whittaker现在偶然会在Google Testing Blog（哎，要翻墙才能看）发表文章

避免用户用一个邮箱在网站上注册多个帐号(马甲)

SNS的风已经刮过了，国内不少SNS网站正在刮第二阵风：游戏！像聚友网，开心网，山寨开心网，校内等社交网站都添加了大量的游戏，在这些游戏中都有一个共同之处–邀请朋友注册送积分（金币，道具等等……）。很多人就会多申请几个邮箱，然后再多注册几个马甲来获利。

我比较懒，一直想着有什么样的办法可以不申请更多的邮箱，而又能多注册几个马甲。可能大家都比较熟悉Google的Gmail邮箱，这个邮箱有一个特点就是它那神奇的“+”加号。例如现在我有这样一个邮箱abc@gmail.com那么我只需要在@符号和abc中间添加一个“+”，还有若干文字，就能“生成”一个新的邮箱，无需申请。例如abc+haha@gmail.com, abc+hi@gmail.com，这2个邮箱的邮件都发送到abc@gmail.com中，这就方便了我们注册马甲啦！
Continue reading “避免用户用一个邮箱在网站上注册多个帐号(马甲)” →