摘要: Noah Sussman 曾经写过一篇文章 《你应该测试的东西：软件系统测试清单》这份清单里面大部分东西都是有帮助的。然而我觉得它所鼓励的理念，本质上来说有误。 它的理念基本上是这样：找出开发者常犯的错误，然 ...
| Noah Sussman 曾经写过一篇文章 《你应该测试的东西：软件系统测试清单》这份清单里面大部分东西都是有帮助的。然而我觉得它所鼓励的理念，本质上来说有误。 它的理念基本上是这样：找出开发者常犯的错误，然后确保你写了测试样例来检查你没有犯了这样的错误。 然而这个做法的问题是它本质上是一种“打地鼠”式的调试方式，并没有终结掉那些该死的 bug。 一个更有效的做法是《Easy Programming》里提倡的“永远不要重复解决同一个 bug”（在这篇文章大约三分之一处）。 如果你遇到了一个或者一类经常出现的 bug，你不应该首先想到的就是“最好把它们加到我需要测试的这类 bug 的列表里面”，你应该想的是“我应该如何修改我的系统，使得这类 bug 再也不会出现？” 所以，对下面列出的一些东西进行测试： 输入处理的 bug，比如 SQL 注入或者 XSS 攻击在 Django 应用里，我从来不为 SQL 注入或 XSS 攻击写测试，原因就是对于 Django 应用来说这类 bug 是非常罕见的。因为用来执行 SQL 语句和生成 HTML 的 API 很容易使用，并且默认是打开了安全机制的。如果我的程序出现了任何这类的 bug， 那真是奇怪而又难以理解。用黑盒测试这种机枪法来找 bug 是在浪费时间。对于 XSS 来说，我有几次都有点想用一些容易遭受 XSS 攻击的方式来生成 HTML 代码。 比如说，用 Python 的字符串插入。然后，在这个时候，你仍然不应该通过测试来保证你正确地写好了它，相反你应该马上停止写愚蠢的 HTML 生成代码。 为了这么做，你首先得问一下你自己“为什么”，“为什么我会想用这种方式来写 HTML”。答案一般是“没有一个 API 能方便地用来实现我想要的这个功能”。正确的做法现在显而易见：创造一个新的 API，移除掉那些易引入潜在的漏洞的代码。 所以，这里有一些我在一个项目里写的一些代码，通过字符串插入来实现的一个格式化超链接的模板标签: |
from django.core.urlresolvers import reversefrom django.template import Libraryfrom django.utils.html import escapefrom django.utils.safestring import mark_saferegister = Library()@register.filterdef account_link(account):return mark_safe(u'<a href="%s" title="%s %s">%s</a>' % (escape(reverse('account_stats', args=(account.username,))),escape(account.first_name),escape(account.last_name),escape(account.username),)) 这样做的一个问题是我必须得记得为每一个变量进行转义。我这么写的原因是 Django 的模板 API 在这种使用情况下会很笨重。所以，我应该这么写：from django.core.urlresolvers import reversefrom django.template import Libraryfrom somewhere import html_fragmentregister = Library()@register.filterdef account_link(account):return html_fragment(u'<a href="%s" title="%s %s">%s</a>',reverse('account_stats', args=(account.username,)),account.first_name,account.last_name,account.username,)
