众所周知，系统测试是需要编写测试用例的，它是保证测试执行正确性、有效性的基础。但是，大家可能很难想象神秘的黑客在挖掘漏洞的时候会提前编写测试用例，然后按照用例去执行。因为他的漏洞挖掘思路是存在脑海中，并且不断的根据实际情况进行调整的。
当然，关于黑客单打独斗挖掘漏洞的这种想象，显然已不大符合当前安全界的实际情况。从网络及信息安全的攻击角度来说，恶意攻击分子已经逐渐形成了目标精准、分工明确、技术先进的网络黑色产业链条，相应的从安全保护和防御角度来说，国家加大了对网络攻击等犯罪行为的打击力度，企业也逐渐加大了网络安全投入。
那么，当安全测试成为企业安全建设中的一个重要环节，安全测试需要写测试用例么？
思考要解决安全测试是否需要编写测试用例的问题，需要先理清安全测试的目的。
当前业界对于安全测试并没有特别权威的定义。"安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和安全质量标准的过程。"这个定义虽然有一定的局限性，但是定义相对清晰，安全测试的目的就是进行安全的度量和尽量在发布前找到尽可能多的安全问题并进行修复从而提升产品的安全质量。
那么，基于度量的目的就引申出两个问题：
· 一是如何度量，度量是需要标准的，不管是对于产品安全性的度量，还是安全测试效果的度量；
· 二是各企业的安全测试团队普遍偏年轻，假如安全测试仅依据个人经验，效果各一，如何达到在发布前找到尽可能多的安全问题的目标。
此时就需要一个既可以作为安全测试执行的指南，又能依据执行结果进行产品安全度量的文档。安全测试用例正好符合这个要求。需要说明的是，此处提到的安全测试不含使用漏洞扫描工具进行的纯自动化扫描。
从表现形式上看，安全测试用例和系统测试用例类似，也需要有测试用例编号、测试用例名称、测试目的、测试前置条件、测试步骤、预期结果等要素，以便于安全测试人员在看到测试用例就可以清楚的知道要测什么，怎么测，如何判断是否存在漏洞。这样就可以达到指导安全测试执行的目的。
从测试用例设计方法的角度，系统测试用例设计的方法诸如等价类划分、边界值、场景法等并不适用于安全测试用例设计。目前业界较常用的可借鉴的方法有微软的STRIDE威胁建模方法、基于攻击图的分析设计方法等。一种比较实用的方法是从漏洞的维度进行设计，分析汇总归纳常见漏洞，可以参考OWASP的测试指南，整理成测试的checklist（图1），然后将checklist转化成测试用例（图2）。
图1：checklist样例
图2 安全测试用例样例
从度量的角度来说，通过执行安全测试用例，记录执行结果，以及进行发现的安全漏洞的管理，可以从测试的进度、安全漏洞的密度等多个维度进行安全度量。
· 测试用例执行的进度=已执行的用例数/总用例数
· 测试用例执行通过的情况=执行通过的用例数/总用例数
· 剩余漏洞数=发现的漏洞总数-已解决漏洞数
· 漏洞的存活时间=漏洞从提交到结束的时间间隔
· 漏洞密度=漏洞总数/被测系统总功能点数
总结综上所述，当安全测试作为企业中一个保障产品安全质量的常规环节时，从流程的规范化和实施的规范化角度来说，是有必要编写安全测试用例的。安全测试用例可以提供一份安全测试执行的标准化的指南，从而可以结合产品的其他因素进行安全的度量。
但是，如果安全测试仅依赖于安全测试用例则仍然存在一定的局限性，比如不同的产品或者系统由于其应用场景不同，功能不同，系统架构不同等，可能存在的安全风险也是不同的，在测试用例编写的时候无法考虑到所有的风险，覆盖到所有测试要点。所以在实际的安全测试过程中，规范的测试用例为指南也需要和人的主观能动性相结合。
最后给测试人的一封信IT工作是辛苦的，软件测试当然也不例外。每天执行用例、跟踪Bug，还要与开发、产品同学争吵PK，与人斗其乐无穷~
但正是因为这些默默的付出，你让一场本该在用户面前发生的灾难，提前在自己面前发生了，你是否有一种救世主的感觉？
你拯救了用户，也拯救了这一软件，避免了她被撇弃、卸载的命运。既然选择了测试这一行，何不一站到底~~
现在我邀请你进入我们的软件测试学习交流群，关注 私信我“测试”，即可拉你入群哟~~
大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，我们一起进阶Python自动化测试/测试开发，走向高薪之路。
那我邀你进群吧！记得：关注 私信我“测试”，即可拉你入群哟 免费送你软件测试学习资料包！
