经常听到会有人抱怨道，怎么这段代码没有注释啊，这是为什么这样写的啊，如此云云。仿佛没有注释，这个世界就不转了。类似的事情也经常发生在QA们的身边，只不过注释换成了文档。

刚毕业的时候做白盒测试，现在回想起来，那时候的我测试的代码大部分都是不包含注释的，不过我测试起来并没有太大的困难，总结一下，应该有以下几点原因：

1. 有意义的函数名、变量名。函数的命名让人一看就大概知道在做什么，例如PostBlog就是发布一篇博客，如果遇到一个叫SaveProfile的方法但做的却是加好友，那我想再多的注释我也会头晕
2. 代码不会说谎。根据经验，如果一段代码理解起来很费劲，那么通常里面都会隐藏着问题。代码就是最好的注释，一些过时的注释，设置会对阅读代码的人产生误导
3. 充分的沟通。虽然游走于几个项目组，跟不同的开发人员打交道，但是每当遇到问题的时候总会主动跟相关的人沟通，一个活生生的人坐在那里不问，却迷信什么文档，这真是本末倒置

注释，能不写就别写，实在要写，写WHY而不是WHAT。

联系一下最近在Team内写的一个新的回归测试工具，里面基本没有注释，希望过几个月以后，自己还能够看看代码就知道当时那段代码为什么这样写。

No related posts.

所谓的测试的坏味道，有三种：

1. 项目（Project）
2. 行为（Behavior）
3. 代码（Code）

按照《重构》书中提出的坏味道的概念来看，如果说是有坏味道（Smell），那么大多数都是指代码级别的。什么的坏味道？就是程序有可能会有大问题的一种征兆（symptom）。个人理解就是不能被直接观察到的现象，可以称之为坏味道。

对于自动化测试代码来说，如果有了项目级的坏味道，通常变现就是生产环境出现了BUG。如果出现这样的情况，那么自动化测试代码就不是有味道那么简单了，而是有问题了，自动化测试的安全网没有能够抓住这个BUG。

而行为的坏味道，其中一个表现形式就是我以前写过的在自动化测试中需要避免“诡异”的测试脚本提到的现象。还有诸如编译错误、不能被重复运行的测试等。其实如果我们碰到行为级别的坏味道，那么可以肯定，我们必须要修改它。如果不修复好这些问题，自动化测试根本无法进行。

代码的坏味道，这个才是我们需要注意的问题，因为代码有了坏味道，并不代表着自动化测试代码会运行出错，通常人们是不会去修改没有出错的代码，人之常情。发现测试代码的味道，并且去修复它，会让我们的自动化测试更加健壮。《XUnit Test Patterns》这本书的前言部分给出一个典型的例子来说明单元测试代码中有哪些坏味道，如何去修改。例子中的一些对单元测试的重构方法，我在平时的工作中也应用到了，不过看完了以后真是觉得裨益良多，虽然做了快一年的单元测试，集成测试，但是却没有停下来总结一年中学到了什么，真的要借着读这本书的机会，好好总结。

最近在接回以前的一些测试项目，个人觉得如果测试代码里面不写注释，这样也是一种坏味道。对于一堆测试代码，半年后可能都忘记了当初为什么这样写，尤其是对于没有注释的测试代码。就像我在译言翻译的第一篇文章里面说的那样，“很多时候，你就是注释的第一位受益者，或者受害者”。对于有坏味道的自动化测试代码，你可以让他继续发酵，腐烂，总有一天，你自己要收拾这个残局。

No related posts.

• 用户是谁
• 当前用户是否真的是他所代表的角色

通常来说，一个登陆系统，就是一个认证的系统。

那么授权（Authorization）又是什么呢？授权通常是用来回答以下问题：

• 用户A是否被授权访问资源R
• 用户A是否被授权执行P操作

常见的例如密码相册那些应用，就是应用到了授权系统。

No related posts.