* 性能陷阱。 为了尽快实现业务逻辑。我们在第一次编码的时候往往不先考虑性能问题。这个想法不算太错误，但这个想法不能太过分。特别是涉及到一些”性能敏感”的代码段，比如我们产品中多处涉及到的Tcp Server的内核。这些部件的代码1天可能遭受几百万次的访问，瞬时绝对并发100是最正常的情况。因此0.1秒的性能损失，也会带来 100x0.1=10秒的性能损耗。10秒，足以使一个TCP Server达到实际“不可用”的严重程度！10行马虎的代码，可能毁掉客户对我们团队辛苦生产的100万代码的信任。切记！切记！
* 安全隐患。 某些安全隐患在我们刚开始写实验性的代码时往往可以忽略，但绝不能忘记。你必须在这个产品进入到下一阶段的时候加上必要的安全检查代码和与安全相关的逻辑验证代码。回忆一下，你是否忽略了下面的工作：
1. http session检查。 尽管我们可以用框架来保证这一点。但你还是要检视一下，是否在某些功能的实现上，你确实忘记它了。
2. 参数类型校验。 当你把一个'a'传递到servlet用Internet.parse（）来处理的时候，你是否考虑了可能出现的异常情况。等等此类。
3. NullException。 特别注意，千万不要让NullException出现在jsp中，否则你很难在系统部署后排查错误。在你第一次编写jsp代码时，你就必须考虑你所使用的对象或者属性是否可能为Null。
4. Anti-flood。 最容易被初级程序员忽略的要点之一。因为这个bug永远不会出现在你的eclipse开发运行环境里。也往往被功能测试组的人忽略。但一旦存在这个隐患，一个最菜的Hacker用最普通的teardrop也会让你tear drop。
* 线程安全。 永远不要忘记，你的代码需要在一个多线程的环境中运行，随时随地都有可能出现并发的情况。你的产生的临时文件名是否用uuid来避免重名了？你的静态（或单态）变量是否线程安全。你是否忘记将spring里定义的bean设置为scope=prototype？
* 忘记删除临时文件。 在上传文件、生成验证图片、生成缩略图的时候，你都可能用到临时文件。你是否在使用完毕后及时的删除了它？你是否考虑过在发生异常后，仍然安全的删除了这个文件？特别需要指出的是，我们在编码阶段的测试时，很难发现遗漏临时文件清理的工作。单在系统上线运行后，大量滞留在目录下的过期临时文件将用光客户的服务器磁盘空间，降低系统IO的性能。
* 极不友好的UI操作。 极不友好的UI操作同样是严重的BUG。比如：
1. 当用户提交表单的时候可能填写了错误格式的信息，而你的程序再提示错误，重新显示表单的时候清除了用户已经填写的数据。这对你的软件的使用者来说是极其恼火的体验，对于创造这个代码的您来说则是一种耻辱。
2. 另一种“极不友好的UI操作“可能发生在这种情况——你必须跟测试人员解释——他体验到这次系统出错的原因是他（测试人员）操作的步骤或顺序不正确。天那，这是噩梦，不仅是用户的噩梦，也是你的噩梦。如果你坚持你的做法没错，我将决定在系统上线后，把你的手机和家里的电话号码做为HELP放在你创造的界面的显著位置呈现给使用它的80万用户。
文章来源于领测软件测试网 https://www.ltesting.net/
