[开发测试]安全测试项目工作流程是怎么样的？

安全测试在软件测试里面是一个很特别的科目（或作“工种”），次一碰到这个科目，很多人都觉得这个科目应该全权交给神秘的安全测试人员来管。这一个观念导致很多测试人员徘徊在安全测试的门口却迟迟不进去。

如果你能够在不同规模的软件开发项目上跟“神秘的安全测试人员”学习如何进行安全测试，发现“神秘的安全测试人员”不光是名字跟普通测试一样都有“测试”二字，所做的事情在本质上也是跟测试人员有很多相通。

做安全测试，你得先：

转换视角：从安全角度去看问题，例如一些便利性的问题就变成了信息泄漏

角色转换：从合法用户视角转换为恶意用户

使用专门的安全测试工具：例如渗透测试工具，扫描工具等

然后一般项目的工作流程是：

1. 识别系统中有价值的数据

很多人认为执行测试才是测试，而我们的安全测试从这里就开始了。

了解了业务以后，我们需要考虑系统中会有什么有价值的数据。这是为下一步加入恶意用户需求做准备。对于一个网上商城，有价值的数据可以包括产品信息、订单信息、用户信息、支付，等等。

2. 在需求阶段加入恶意用户需求

恶意用户需求是用来记录恶意用户想要在系统中达到的目的。与普通用户需求的区别是，我们不是要去实现它，而是使用它帮来助我们远离对系统使用者“不恰当的信任”。通常我们需要针对每一个合法用户需求来增加一个或多个相对应的恶意用户需求。

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

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

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

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

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

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

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

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

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

都测得差不多的时候，我们就可以向团队以及相关干系人汇报安全测试的结果了。跟非安全测试不同的地方是，当我们反馈安全漏洞的时候，要考虑是否不同漏洞结合起来会增加系统的安全风险。