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

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

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

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

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

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

　　而这个环节存在的第二个目的是让我们可以从开发人员那里得到支持－具体实施的细节，帮助我们完善具体的测试用例。比如在这个时间点我们若从开发人员那里得知系统的后台没有对图片上传者做身份验证，我们就可以至少增加一个测试的用例：“恶意用户以其他用户的身份上传一个风马牛不相及的图片”。有时候错误的图片比没有图片更具有杀伤力。

　　6. 在测试环境中进行安全测试

　　终于到了运行测试的阶段。可能这个时候我们之前想到的测试用例已经被开发人员给解决了。如果是这样那就太好了。但是，事实并非有这么美好。第一，可能这些用例只是在开发环境上成功通过了，但是在理想的测试环境里，也就是类产品环境里，这些用例可能并不能完全通过；第二，肯定还有其他需要探索的地方。这时我们就可以用OWASP Zap、Burp这样的工具来辅助我们把之前的安全测试用例执行一次，同时还再可以对系统的安全性做一下探索测试。

　　7. 向团队反馈所发现的安全漏洞

　　都测得差不多的时候，我们就可以向团队以及相关干系人汇报安全测试的结果了。跟非安全测试不同的地方是，当我们反馈安全漏洞的时候，要考虑不同漏洞结合起来是否会增加系统的安全风险。举个例子：如果有两个安全漏洞，一个是系统没有很强的用户账户密码规规则，另一个是系统没有对上传图片的大小做限制，那么恶意用户把这两个漏洞一结合起来，事情就比原来风险大很多。那么我们就必须建议提高这两个漏洞中任意一个的优先级。

　　当我们用“三板斧”走完这七步以后，我们已经可以把很多安全漏洞都挖出来了。是不是没有想象中的难？所以，测试同仁们，让我们做安全测试吧！