本节书摘来自华章出版社《软件测试价值提升之路》一书中的第3章，第3.3节，作者：杨晓慧编著，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.3 受攻击出错
3.3.1 问题案例
我们的产品中遇到的这类问题并不多见，最典型的就是春节、麦加朝觐时，由于通信需求骤然增大对产品产生的浪涌冲击。我们的产品就是在这样的考验下，由最初的业务请求不断堆积形成拥塞，甚至无法进行维护操作，直至系统完全崩溃；到后来在32倍浪涌冲击下，都能保持业务处理能力。相应的测试方法和工具，也是随着产品可靠性能力的增强同步建设完善的。
众所周知，目前很多互联网产品的安全防护能力是较弱的，有一次一个同事兴奋地和我说，他获得了一项新技能，只用最简单的横向越权手段，就通过移动的网上营业厅获取了我手机的全部通话记录！
这类问题典型的有：被黑客攻击，网络风暴，对系统的人为误操作，对硬件设备的误操作，自然灾害导致停止服务等。
3.3.2 解决问题的思路
【一般处理原则】
通常这类错误的解决思路是在产品中增加安全防护、备份恢复、过载控制、故障检测和恢复机制，而不是试图通过测试把这些缺陷都挖出来。
【解决方法】
这类缺陷的发现条件是：产品受到了攻击，因此，通过攻击的方法实现缺陷的拦截是很自然的选择。通过对产品进行攻击，检验新加上的机制是否在各种已知攻击下都能够生效。通常可以根据网络上公布出来的安全性漏洞（如中国国家信息安全漏洞库www.cnnvd.org.cn公布的漏洞库）和可靠性故障模式（如国军标GJB/Z 1391—2006定义的故障模式），加上产品的已知缺陷，形成一个安全性漏洞和可靠性故障的模式库，这个模式库既是产品进行可靠性和安全性机制设计的依据，也是测试人员开展攻击测试的依据。因此，模式库的建设通常是产品设计人员主导，测试工程师根据网上问题的分析进行补充，并且确定每种攻击的模拟的方法。
选择攻击方法时不能完全依赖对客户问题分析，这样太被动。网上公布的安全性漏洞和可靠性故障模式，是从大量的产品报告的缺陷中总结出来的，以这些为基础，可以用较小的代价达到比较全面的覆盖效果。
3.3.3 建设故障模式库
故障模式库是可靠性测试的依据，测试时逐一模拟库中的每一种故障模式对产品进行攻击，考验可靠性机制能否确保产品在这些攻击下保持正常的业务处理。
安全漏洞库的作用和故障模式库的作用类似，考验的是安全性机制能否在这些攻击下，确保产品的服务不中断、无故障，数据不被非法盗取和利用。
对于我们的产品，建设得相对比较早的是可靠性故障模式库，安全性漏洞库的建设近几年投入比较大也基本成形。一个故障模式（漏洞模式大体类似）包含的内容有：
1）分类。比如物理组网、硬件、业务流程、业务数据等。
2）故障模式。故障模式的名称及其具体描述。比如文件服务器不可用，CPU占用过高等。
3）优先级。根据故障发生的频率和影响范围确定的优先级，高优先级的故障产品必须有相应的保护机制。
4）故障处理。约定故障处理的原则和预期效果。故障处理的原则有：进行根因告警（故障根本原因的告警，只要处理了这个故障，由这个故障引起的一系列异常都会自动恢复）；自动恢复（产品通过可靠性机制自动消除故障，故障处理无需人工干预）；手工恢复等。预期效果则与处理原则有关，比如自动恢复就需要说明由哪个特性实现自动恢复；手工恢复就需要说明恢复的方法。
5）故障模拟方法。故障使用什么方法、工具来模拟。
测试人员在使用故障模式库进行测试的时候，还需要补充一些通用的预期结果，比如：故障恢复的标志是业务恢复还是性能恢复；单个故障引发的告警不能超过3条；故障从触发到恢复的时间不超过XX分钟等。
我们的各产品线都有安全性漏洞库和故障模式库的基准库，故障模式基准库的结构如表3-3所示，安全漏洞库的结构与之类似。产品会在基准库的基础上进行定制。 
3.3.4 DFX测试能力提升的线路
可靠性和安全性测试能力提升，走了两条完全不同的线路。
产品的可靠性及其测试能力，是在不断满足产品应用场景需求的过程中，同步成长起来的。我们测试团队的可靠性测试内容经历了3个阶段的发展：
1）特性测试。针对可靠性设计进行的测试，例如主备双机冗余的设计方案中，当接收到切换命令、或主机主进程退出、或主机心跳中断的时候，就触发双机切换，原来的主机变成备机；原来的备机变为主机。测试时，需要逐一验证这些方式能否正确触发双机切换。当然，也会验证产品、进程在各种状态下触发双机切换，但基本上是围绕设计进行的测试。
2）故障注入。在可靠性机制基本开发完成后，开发和测试都开始关心这些机制能否在各种异常和极端情况下，充当产品最后的防护垫，保持正常业务不中断。于是，测试重心开始转向故障注入测试，构造各种软件、硬件、网络、环境的异常，检验产品的可靠性机制在这些情况下能否生效。这时候的测试依据，主要是通过对网上问题的长期分析积累下来的故障模式库。
3）可靠性指标测试。在产品的应用中发现，客户关心的不仅仅是故障发生后产品能否恢复，他们更关心恢复花了多长时间，有多少业务和用户受到影响。于是，产品开始细分各类故障的恢复方法，而测试则开始在故障注入测试的基础上，对故障自动恢复率（缩短故障恢复时长）、业务恢复时长（减少对业务和用户的影响）等可靠性指标进行采集和分析（可靠性指标参见4.1.2节“测试结果数据的内容”）。但是，在指标测试中，目前还没有方法计算产品的可靠性能够达到几个9（电信设备一般要求5个9，一年停机时间不超过5分钟）。
由于可靠性的测试能力是通过一个自然的过程生长起来的，因此，所需要的方法、工具，包括如何融入研发流程，这些都是以产品的测试团队为主力完成的。产品之间的交流，优秀经验、方法和工具的整理和传递，业界新方法和工具等信息的搜寻、获取、交流，要通过一个很小的技术团队来支撑。
产品的安全性及其测试能力，则走了一条不同的路。安全性受到重视，是由于产品进入某些市场遇到了门槛，几乎是一夜之间就要求所有产品给出满足安全要求的计划表。因此，很多产品的安全性是以“测试驱动开发”的方式建立的：
首先由专门的安全测试团队对产品进行基本的安全性评估；然后由安全设计团队指导产品，根据评估情况和设计要求进行安全性的专项开发；最后再由安全测试团队和产品测试团队共同进行安全性评估，并进行验收，确认符合安全性要求。
安全测试团队对产品的安全性测试包含两部分内容：
1）特性测试。针对安全性设计进行的测试，例如身份验证中，对密码复杂度的要求、信息传输通道要求、存储方式都有相应的设计。测试时，需要逐一验证这些需求和设计的实现情况。这些内容由产品测试团队随版本开发进行测试。
2）安全攻击。寻找漏洞进行安全攻击，例如针对身份验证，利用各种可能的手段，寻找绕过、欺骗身份验证的方法，以达到非法进入系统进行操作、或者获取信息的目的。由于产品测试团队没有足够的时间掌握安全攻击测试的能力，因此组建了一个跨产品的、专职的安全测试团队，完成安全漏洞库、安全攻击方法的能力建设，并进行产品的安全攻击及安全性评估工作。
由于安全性测试能力是通过一次强行推行建立起来的，测试所需要的方法、工具，研发流程的改造，这些都是以专门的安全性团队为主力完成的，目前并没有完全融入产品的研发团队和研发过程中。
如果有时间和机会的话，随着产品的发展让测试能力自然的演进，这是比较理想的方式，可以根据业界其他人的经验加快生长速度，少走弯路，但是，最好不要寄希望于一口气吃个胖子。
以这里提到的可靠性和安全性测试为例，从把可靠性测试作为一个专门的门类进行发展，到形成可靠性指标，前后大约经历了5～6年时间，可靠性的方法和工具始终都在产品中发挥作用，也和产品的架构、网络位置有较好的适配。随着技术的发展，产品的可靠性测试专家也获得了个人的发展。
而安全性测试，从公司下达要求至今也已经是第4个年头，仍然没有几个产品测试团队掌握了安全攻击测试方法和工具。可见，采用集中突破的方式，不一定能够加速技术在产品的落地应用。当然，这种方式对于快速响应需求还是有帮助的，只是在响应了需求以后，要把这些落实成为产品及其研发团队的常规能力，该走的路省不了。
3.3.5 重视行业信息的长期积累
如果产品受攻击导致服务质量降低，研发通常会启动相应的专项研究来改进项目。测试如果想在这类项目中取得主动，把项目做成由问题驱动的改进。关键的一点就是，测试人员是否在日常工作中就关注业界的相关新闻、资讯、成熟的方法和工具，并注意产品相关问题的分析和积累。这样在方案的讨论中，就能够提供更多的信息，测试提供的信息如果丰富且有结构性，就能够给研发团队解决问题的信心。
一般搜集和整理这类信息，可以从3个角度进行：看业界—整个软件行业和测试领域的相关信息；看同行—同形态的产品或同领域的业务或同公司的其他产品的相关信息；看自己—自己产品的相关问题及其影响。
在5.1.2节“拓展测试领域知识的广度”中介绍了一些软件测试行业信息的获取渠道，但可靠性和安全性测试的技术，通过这些渠道分享的比较少，更多的还是需要通过分析安全性测试（software safety testing）和可靠性测试（software reliability testing）的文章和论文来获取相关信息。
建议测试团队中，固定一个经验相对丰富或思维相对活跃的人，对可靠性和安全性方面的技术做比较长期的跟踪。基本上软件产品发展一段时间后，都会分离出相对核心的平台部分，这部分对可靠性和安全性会有较高的要求，也有比较大的机会去集中解决这方面的遗留问题。
