进化的测试

前两篇文章介绍了VSTS性能分析工具Profiler和如何用Profiler发现性能问题并且进行优化。今天想分享一下如何在测试ASP.NET程序的过程中获取代码覆盖率的信息。 设想如下场景，测试人员介入到项目的需求，分析，设计的阶段，得到了很多有用的文档和信息。接下来就到了编码的阶段，在这个时候测试工程师开始根据前面获得的信息来设计测试用例，做用例评审，力求测试用例覆盖能覆盖系统的每一个角落。不幸的是，系统实在是太大，没有人能确切地知道手上的测试用例对系统的覆盖（这里指定为代码的行覆盖）能达到什么样的程度。对于系统的关键部分，没有人希望在经过几轮测试以后，还有相当部分的代码是没有被执行过的。 解决这个问题的其中一个方法，就是对关键部分的代码进行代码覆盖率的统计。平时我做单元测试和接口测试的时候，得益于IDE的帮助，代码覆盖率信息很容易就能得到，但是对于部署在IIS上的ASP.NET代码，又如何去收集代码覆盖率信息呢？曾经找过好多.NET的代码覆盖率工具，没有合适的。不过就在最近，让我发现了VSPerfMon，VSTS自带的性能数据收集工具。真是众里寻他千百度，蓦然回首，那工具却在灯火阑珊处。 1. 首先要对需要进行代码覆盖率信息收集的二进制文件(DLL, EXE)用VSInstr进行处理，记得带上/COVERAGE参数 VSInstr “D:\Websites\somewhere\bin\MySpace.Web.UserHome.dll” /COVERAGE 2. 停掉IIS iisreset /stop 3. 用VSPerfClrEnv 设置相关的环境变量 VSPerfClrEnv /globaltraceon 4. 启动VSPerfMon；参数/COVERAGE代表本次监控收集的数据是代码覆盖率；/user:”NETWORK SERVICE”，指定用户名;/CS 启用跨域会话分析；/output:”d:\magus\0422.coverage”，指定输出文件的名字和路径，记得用.coverage作为扩展名。

对于从事Web开发和测试的工程师来说，Firefox是一个优秀的浏览器；因为基于Firefox的插件有很多，这些插件都极大地方便了开发和测试的工作。其中有著名的FireBug，FireCookie，Web Developer等，今天要介绍的是另外几个名气没那么大的Firefox插件，他们分别是FlagFox、Remove Cookie(s) for Site、Screengrab。 1. FlagFox 这是一个可以将网站服务器所在国家的国旗显示在状态栏上的插件。它通过查询扩展内建的IP地址库，同时通过维基和Geotool获得更多信息。可以参考下图，当我们浏览一个网站的时候在浏览器地址栏的最右边会有一个中国国旗，因为该网站的服务器就在中国；然后把鼠标挪过去放在国旗上面，就会出现该网站的IP，这里就是60.28.210.209。 其实我知道IP所在的国家对于测试没什么帮助，我只想知道我所访问的网站的IP。因为大家都知道做测试的时候经常需要配HOST，重启浏览器，但是有时候 配好了HOST重启完了还不一定生效；又或者HOST文件太大，有时候一个域名给配上了若干个IP（这是一个失误啦~）；又或者是一个域名下有多台测试 机。我想在测试的过程中清楚地知道我现在究竟在访问哪台测试机。这就是FlagFox能起到的作用了

最近项目不是十分多，所以大部分的学习来自于书本还有同行的博客，淘宝的QA Team博客就是一个很好博客，里面N多淘宝的工程师写，而且更新的非常频繁，质量也很好。翠翠同学以后就要加入淘宝了，以后就能看到他写的博客了。 早上来看到一篇文章，大概讲的是在单元测试中容易用到了Try…Catch语句而容易出现的一个错误，这里想说一下我对单元测试中异常处理的。记得一个牛人曾经说过（实在想不起来谁也搜不到），大概的意思就是“处理一个问题的最好的办法就是不去处理它”。我不知道当时他讲这句话的具体场景是什么，不过我觉得这句话用在单元测试的异常处理中还是比较合适的。 首先来看看两条关于异常处理的原则 如果无法处理某个异常，那么就不要捕获它 如果捕获到一个异常，那么不要胡乱处理它 单元测试的代码和开发的生产代码，虽然同是程序代码，但是他们存在的意义是不一样的。前者是验证程序的正确性，属于为程序服务的；后者是实现某种功能，属于为客户服务的。然后在看上面的两条异常处理的原则。

昨天Check in了几行代码，部署到了生产环境，一切正常，这个是我第一次把代码提交到生产环境。今天早上看到一篇文章“Who fixes the bugs?”。这篇文章是讲述了一个测试工程师是否应该去深入到代码，然后自己把发现的BUG修复，这样的一个事情。很有趣，我刚做完这样的事情，就看到一篇文章讲述同样的问题。 读完那篇文章以后会发现，软件测试真的是一件跟上下文（Context）联系的特别紧密的事情。所以在做某一件事，或者讨论某一件事情的时候，最好先把上下文先弄清楚，然后再下判断。下面阐述一下文章的观点。 作为一个团队里面的成员，每个人都有义务和责任去提高产品的质量。 测试工程师来修复BUG这样的行为虽然不会京城在传统的软件行业里面发生，但是也不能以这个为理由去打击它。 你不必要去创造一个敏捷的过程来规定测试工程师可以修复BUG。 上面这三点非常模棱两可的观点，在我看来就是作者让读者知道，我们在充分了解上下文的前提下来进行判断。对于我现在所处的公司的环境下，昨天我做的事情是没啥问题的。 公司没有严格的流程或者指引，规定了Tester不能往生产的代码库中check-in代码 现在公司的Developer不是很多，有时候能帮的地方尽量帮助，自己也能学到东西 对于我测试过的代码，熟悉起来还是会比较快 我也需要对代码的质量负责 那么这样做会有什么问题呢？ 变相地成了自己测试自己的代码，不推荐 对于测试小组来说，比较难留住人才（那篇文章的观点，也是一个现实） 在多数情况下，测试工程师的工作就是不断地折磨那个被测软件，不断地向被测系统提问题；然后等待被测系统的答案，从这些答案里面获得尽可能多的信息，软件测试在开发生命周期活动里面扮演一个服务者的作用，给开发经理，开发工程师，各个stakeholder们提供信息，所以软件工程师甚少去修BUG。而且在大多数非常正规的企业中，测试工程师设置没机会看到代码，所以也没有办法能修复BUG。软件工程师可以修复BUG吗？可以，不过不常见。

SNS的风已经刮过了，国内不少SNS网站正在刮第二阵风：游戏！像聚友网，开心网，山寨开心网，校内等社交网站都添加了大量的游戏，在这些游戏中都有一个共同之处–邀请朋友注册送积分（金币，道具等等……）。很多人就会多申请几个邮箱，然后再多注册几个马甲来获利。 我比较懒，一直想着有什么样的办法可以不申请更多的邮箱，而又能多注册几个马甲。可能大家都比较熟悉Google的Gmail邮箱，这个邮箱有一个特点就是它那神奇的“+”加号。例如现在我有这样一个邮箱abc@gmail.com那么我只需要在@符号和abc中间添加一个“+”，还有若干文字，就能“生成”一个新的邮箱，无需申请。例如abc+haha@gmail.com, abc+hi@gmail.com，这2个邮箱的邮件都发送到abc@gmail.com中，这就方便了我们注册马甲啦！

首先说一下Test Fixture，我不知道怎么样翻译这个Test Fixture，没能搜到一个翻译的比较合适的。最让我气愤的是某人翻译的一本书中，直接把Test Fixture翻译成为测试夹具，这明显就是什么词霸词典硬翻译出来的，我强烈鄙视这样不负责任的翻译行为。 The test fixture is everything we need to have in place to exercise the SUT 我觉得这是一个对Test Fixture的一个很清晰明了的定义，就是运行被测软件所需要的一切东西，这个“东西”不单只是数据，同时还包括对被测软件的准备，例如实例化某个被测方法所在的类，准备数据库的ConnectionString等。通常来说，有三种方法来准备Test Fixture。 1. 内联方式：这种方式就是直接在测试方法中编写准备Test Fixture的代码。用这种方法的缺点是很容易造成代码的重复，出现很多复制粘贴的代码。同时，如果这个SETUP的过程比较复杂，也会降低测试代码的可读性，可维护性。另外的一个问题就是，这种方法很容易会带来测试数据Hard code的隐患。既然有那么多缺点，这种方法还有什么生命力呢？首先，可能对于初学者来说，这种方法是最简单的；其次，在一些只需要准备简单的Test Fixture的场合中，这种方法还是给编写测试的人提供了便利。

用单元测试的框架MSTEST，做单元测试，集成测试快1年了，总结一下工作中学到都东西。 单元测试，集成测试有什么用？ 1. 改进产品质量 软件测试，很多时候围绕着两个问题： Verification和Validation，常说的双V。前面的Verification就是Is the software built correctly?。后面的Validation就是Have we built the right software? 单元测试，更多的是Verification。所以有时候经过我单元测试和集成测试以后的功能模块，在交给其他同事做功能测试的时候，依然会有一些BUG，这时候开发可能会埋怨我测试得不够完全，诸如此类。但是其实很多时候，我的关注点是单个方法的功能、行为，没有站到更高的位置来测试这个模块。对于这样的问题，开发和测试应该互相体谅，我本人也会提高自身的水平。希望在单元测试和集成测试中也加入更多关于Validation的思考。

Martin Fowler有一本很出名的书《重构》，里面有个很出名的概念，Code Smell。前阵子我也刚发现一本很好的书，《XUnit Test Patterns》。这本书主要讲的是如何重构测试代码，这里的测试代码指的就是自动化测试的代码，再进一步细化就是单元测试为主的自动化测试代码的重构。由于此书已经让清华大学翻译烂了……所以建议大家下载英文版。 所谓的测试的坏味道，有三种： 项目（Project） 行为（Behavior） 代码（Code） 按照《重构》书中提出的坏味道的概念来看，如果说是有坏味道（Smell），那么大多数都是指代码级别的。什么的坏味道？就是程序有可能会有大问题的一种征兆（symptom）。个人理解就是不能被直接观察到的现象，可以称之为坏味道。 对于自动化测试代码来说，如果有了项目级的坏味道，通常变现就是生产环境出现了BUG。如果出现这样的情况，那么自动化测试代码就不是有味道那么简单了，而是有问题了，自动化测试的安全网没有能够抓住这个BUG。

跟测试工程师打交道最多的可能就是测试用例了，先设计出一些测试用例，然后这些测试用例要经过评审，之后要执行这些测试用例，完了以后还有可能需要对这些测试用例进行更新。测试用例的重用是一个很有必要的活动。那怎么重用呢？很多人可能第一时间想到了一些测试管理工具能帮上忙，例如Quality Center，Test Link；又或者是一些保存测试用例的工具，例如Word，Excel。 不过这些东西真的能帮助我们重用测试用例么？我想未必。测试用例的重用，应该是测试用例里面的设计思想的重用，而不是具体某个测试用例的，因为对于功能测试的测试用例来说，大多数的测试用例都跟某个具体的被测应用有想到大的关联性，例如要测试一个博客编辑器，对于MySpace的博客编辑器和facebook的博客编辑器来说，它们的主要功能是相似的，都有发表博客，编辑博客，修改博客等……但是由于这是两个不同公司的产品，他们的具体功能或者UI是完全不一样的，所以拿到的两套测试用例，也应该是不一样的。如果分别提取出测试用例的核心思想（就是那些可以重用的部分），应该能看到很多的共同点，或许会有这么一条共同的用例思想。

场景：在本地有一台代理服务器，这台服务器会定时检查部署在远程的服务器的状态，如果检测到某台服务器是工作异常的，那么该台服务器就会被移除到生产服务器列表；如果过了一段时间，程序发现原来工作异常的服务器已经恢复正常，那么该服务器就会被重新添加到生产服务器列表中。那些被检测服务器的IP是以配置文件的方式记录。 测试的一个关键点：某台服务器Down了以后被代理服务器剔除出生产列表，如果这个台服务器恢复正常以后，代理服务器上的监控能否检测到该服务器已恢复正常，并且把该服务器添加到生产服务器列表中。 限制：1. 我没有远程服务器的管理员权限，甚至无法登陆到那些远程服务器；2. 没有处于测试状态的服务器，全部服务器都是线上生产服务器。