致测试同仁们：让我们做安全测试吧！(8)

3. 针对“恶意用户需求”设计测试用例

现在我们需要做的是努力把自己限制在“恶意用户”的角度做头脑风暴：“到底有什么方法可以使买家无法上传图片信息呢？”， “让页面无法正确显示买家秀图片又怎么做到？”嗯，也许最直接的办法就是让服务器所在的机房断电、断网之类的。这是些不错的想法，虽然执行难度有点大。没关系，记录下来。除此之外，我们还可以有其他测试用例，比如：

• 使存储图片的磁盘空间被占满而无法接受新的图片；
• 使处理上传图片的进程繁忙而无法接受新的上传任务；
• 上传特别大的图片使用户的客户端需要很长时间才能下载完
• 上传伪装成图片的恶意代码，进一步获取服务器权限，删除所有的买家秀图片；
• 等等

如果这个时候想到新的测试用例也同样记录下来，比如“我想不购买也上传买家秀图片以获得返现”之类的。

不用太担心这个阶段的测试用例过于“疯狂”或者不够完整，毕竟我们对于系统的实现还不是很了解。我们会在接下来的环节中完善具体的步骤。

4. 参与启动恶意需求的开发（evil story kickoff）

在开发人员开始开发合法用户需求之前，我们需要跟业务分析人员、开发人员一起沟通需求的内容。在敏捷软件开发项目中我们叫它story kickoff，即用户故事启动。当有了对应的恶意用户需求时，我们必然也要把它也加到启动的范围里。目的是把我们头脑风暴出来的测试用例跟所有的角色来沟通。预防胜于检测。

5. 在开发环境验收恶意需求的实现

100%预防软件的缺陷与漏洞是不太可能的，所以这个环节的存在是为了提早反馈。

我曾经经历过一个项目，都快上线了才决定做安全测试，结果测出来的问题之一是用户会话（user session）不能正确过期的问题，经过一番研究，发现需要对系统设计的架构进行比较大的修改，只能做个临时的修复让系统先上线，然后再把系统的架构给改了，重写这部分功能，重新测试。代价非常高。所以不管是安全测试还是非安全测试，”在开发环境验收恶意需求的实现“这个步骤都不能缺少。

原文转自：http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safety-test