第6章 系统测试
文章目录
- 6.1 功能测试
- 6.2 回归测试
- 6.3 性能测试
- 6.4 压力测试(Stress test)
- 6.5 其它非功能性测试
-
- 6.5.1 安全性测试
- 6.5.2 可靠性和容错性测试
- 6.5.3 兼容性测试
6.1 功能测试
功能测试：对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
功能测试要点 ：
①功能逻辑清楚，符合使用者习惯
②系统的各种状态按照业务流程而变化，并保持稳定
③每项功能符合实际要求
功能测试要以客户需求为导向，全面理解功能特性。
整体思路：
6.2 回归测试
回归测试：在当前版本中对上一个版本中测过的功能再重复测试1遍
回归测试原因：一旦程序某些区域被修改了（增加新的功能），就可能影响其它区域，导致受影响的区域出现新的缺陷（回归缺陷）。如果这时没有回归测试，产品就带着这样的回归缺陷被发布出去了，造成严重后果。回归测试就是为了发现回归缺陷而进行的测试。
回归测试目的： 所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等； 不影响软件原有功能的正确性。
回归测试策略：
①再测试全部用例
②基于风险选择测试
③基于操作剖面选择测试
④再测试修改的部分
⑤更智能的选择方法
6.3 性能测试
常见性能问题：
- 资源耗尽，如CPU使用率达到100%；
- 资源泄漏，如内存泄漏 ，最终会导致资源耗尽
- 资源瓶颈，如线程、GDI、DB连接等资源变得稀缺
性能的具体指标：
- 数据传输的吞吐量（Transactions）
- 数据处理效率（Transactions per second）
- 数据请求的响应时间（Response time）
- 内存和CPU使用率
- 等等
性能测试：为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况。
性能测试目标：
①获取系统性能某些指标数据
②为了验证系统是否达到用户提出的性能指标
③发现系统中存在的性能瓶颈，优化系统的性能
性能测试类型：
- 性能验证测试，验证系统是否达到事先已定义的系统性能指标、能否满足系统的性能需求
- 性能基准测试，在系统标准配置下获得有关的性能指标数据，作为将来性能改进的基准线
- 性能规划测试，在多种特定的环境下，获得不同配置的系统的性能指标，从而决定在系统部署时采用什么样的软、硬件配置
- 容量测试，可以看作性能的测试一种，因为系统的容量可以看作是系统性能指标之一
性能测试要点(理解)：
- 测试环境应尽量与产品运行环境保持一致，应单独运行尽量避免与其他软件同时使用
- 录制脚本和手工编写脚本相结合
- 重点在于前期数据的设计与后期数据的分析
- 设置数据池，实现变量加载
- 采用复合交易测试方案、业务批量执行
- 需要同时监控数据库服务器、Web服务器以及网络资源等使用情况，以便对系统的性能做全面评估
- 模拟用户数的递增
- 合理设置交易之间时间间隔
- 超时（timeout）的设置、错误处理
- 并发用户连续执行交易数的设置、设置并发点
- 并发用户数量极限点
- 尽量将执行负载测试的机器合理分布
- 加压机器的CPU使用率也有必要监控
6.4 压力测试(Stress test)
也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。
在一种需要反常（如长时间的峰值）数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈或其它不稳定性问题
压力测试(ST)类型：
① 并发性能测试（重点）
并发性能测试的过程也是一个负载测试过程，即逐渐增加并发虚拟用户数负载，直到系统出现性能瓶颈或者崩溃为止。
破坏性压力测试，通过不断加载的手段，快速造成系统的崩溃，让问题尽快地暴露出来
②疲劳强度测试
采用系统稳定运行情况下能够支持的最大负载，持续长时间运行，以发现性能问题。
渗入测试（soak test），通过长时间运行，使问题逐渐渗透出来，从而发现内存泄漏、垃圾收集（GC）或系统的其他问题，以检验系统的健壮性
峰谷测试（peak-rest test），采用高低突变加载方式进行，先加载到高水平的负载，然后急剧降低负载，稍微平息一段时间，再加载到高水平的负载，重复这样过程，容易发现问题的蛛丝马迹，最终找到问题的根源
③ 大数据量测试
独立的数据量测试：
针对某些系统存储、传输、统计、查询等业务进行大数据量测试
综合数据量测试 ：
和压力性能测试、负载性能测试、并发性能测试、疲劳性能测试相结合的综合测试方案
例子：大数据量测试：10万、100万、千万条记录
大容量测试：某些字段存储10M、100M、1G等大体积数据。
负载（Workload）：
- 每次请求发送的数据量 (Request Per Second, RPS)
- 并发连接数 (Simultaneous Connections)
- 思考时间（thinking time），用户发出请求之间的间隔时间
- 加载的循环次数或持续时间
- 加载的方式或模式，如均匀加载、峰值交替加载等
将系统置于相同的高负载下，将请求之间间隔时间设为零。这样服务器会立即超载，并开始构建执行队列。
不可能/不需要对Web应用系统的所有功能进行性能测试，而是根据业务的实际操作情况和技术的角度来分析，选择关键业务
6.5 其它非功能性测试
6.5.1 安全性测试
软件安全性测试：检验系统权限设置有效性、防范非法入侵的能力、数据备份和恢复能力等，设法找出上述各种安全性漏洞
测试策略：
- 想方设法截取或破译口令；
- 专门开发软件来破坏系统的保护机制；
- 故意导致系统失败，企图趁恢复之机非法进入；
- 试图通过浏览非保密数据，推导所需信息等等。
理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利可图。
功能性测试 vs.安全性测试：
功能性测试：软件做它应该做的事，验证正确的输出不正确的输出 /行为 / 缺陷(Bug)
安全性测试：软件不做它不应该做的事, 应用输入验证, 没有不安全的事情发生。在测试软件系统中对危险防止和危险处理设施进行的测试，以验证其是否有效
不同的安全性风险：SQL注入式漏洞；URL和API的身份验证 ；缓冲区溢出；不安全的数据存储或传递；不安全的配置管理等等
安全性测试的范围：
系统级别的安全性
应用程序级别安全性 （重点）：用户权限；数据输入验证；敏感数据加密；数据存储安全性；用户口令等
安全功能测试 (Security Functional Testing)：数据机密性、完整性、可用性、不可否认性、身份认证、授权、访问控制、审计跟踪、委托、隐私保护、安全管理等
安全漏洞测试 (Security Vulnerability Testing)：从攻击者的角度, 以发现软件的安全漏洞为目的。安全漏洞是指系统在设计、实现、操作、管理上存在的可被利用的缺陷或弱点
安全性测试方法1：
①基于漏洞的方法, 从软件内部考虑其安全性，识别软件的安全漏洞。如借助于特定的漏洞扫描器。
②基于威胁的方法，从软件外部考察其安全性,识别软件面临的安全威胁并测试其是否能够发生
③模拟攻击测试：一组特殊的、极端的测试方法，如Fuzzing，使用大量半有效的数据作为应用程序的输入，以程序是否出现异常为标志，来发现应用程序中可能存在的安全漏洞
漏洞来源：
安全性测试方法 2：
-
白盒方法
用商业的统计分析工具
对源码的内审
借助工具 Coverity /Fortify 等 -
黑盒方法
错误注入（Fault injection）
Dumb Fuzzing -
灰盒方法
Smart Fuzzing / Intelligent fuzzing
静态安全性测试的重要性：对代码进行静态扫描，提前发现潜在的安全性问题，那么会避免后期因为漏洞而付出的代价。从微观来看程序代码有哪些安全性问题。
1.语言级代码安全，如C/C++缓冲区溢出…
2.逻辑级代码安全，如身份认证与授权…
3.规范级代码安全，如内存泄漏…
安全性测试方法 3
- 基于模型的安全功能测试
- 基于故障注入的安全性测试
- 模糊测试（Fuzz Testing）
- 基于白盒的安全测试
- 威胁模型与攻击树理论
- 形式化安全测试方法
- 语法测试
- 基于属性的测试
- 动态污点分析方法（Dynamic Taint Analysis）
- 基于风险的安全测试
- 基于风险的安全性测试方法
将风险分析、安全测试与软件开发过程 (Security Development Lifecycle，SDL)结合起来, 在软件开发的各个阶段进行误用模式、异常场景、风险分析以及渗透测试等, 尽早地发现高风险的安全漏洞。
- 渗透测试
完全模拟黑客可能使用的攻击技术和漏洞发现技术，对目标系统的安全做深入的探测，发现系统最脆弱的环节，直观地发现问题。探索式测试。
渗透测试方法：
- 黑箱测试，”zero-knowledge testing”这类测试，最初的信息获取来自DNS、Web、Email及各种公开对外的服务器。
- 白盒测试，测试者可以通过正常渠道向被测单位取得各种资料，包括网络拓扑、员工资料甚至网站或其他程序的代码片段。目的是模拟企业内部雇员的越权操作
- 不同网段 /vlan之间的渗透
- 端口扫描：利用网络安全扫描器
- 远程溢出：可利用现成的工具实现远程溢出攻击
（例如：溢出工具SQL2.exe + 监听工具nc.exe 攻击SQL server 1433端口） - 口令猜测：利用一个简单的暴力攻击程序和一个比较完善的字典，就可以猜测口令
- 本地溢出：指在拥有了一个普通用户的账号之后，通过一段特殊的指令代码获得管理员权限的方法，（如Wincsrss）
- 脚本及应用测试，针对web及数据库服务器进行。利用脚本相关弱点轻则可以获取系统其他目录的访问权限，重则将有可能取得系统的控制权限。
渗透测试实施策略： - 全程监控：采用类似ethereal/wireshark的嗅探软件进行全程抓包嗅探
- 择要监控：对扫描过程不进行录制，仅仅在安全工程师分析数据后，准备发起渗透前才开启软件进行嗅探
- 主机监控：仅监控受测主机的存活状态，避免意外情况发生
- 指定攻击源：该源地址的主机由用户进行进程、网络连接、数据传输等多方监控
- 对关键系统，可以采用对目标的副本进行渗透测试。
- 模糊测试(Fuzz Testing)
在一个被测试程序中附加上随机数据（fuzz）作为程序的输入。如果被测试程序出现问题（例如 Crush ,或者异常退出），就可以定位程序的缺陷。
模糊测试的巨大优势是，测试设计极其简单，系统的行为先入为主。
模糊器的构造：
①IDefense FileFuzz：测试者只想要按照要求来修改软件所能处理的特殊文件（逐个字节将数据换成FF）,然后给被测试对象处理
②OWASP JBroFuzz：用HTTP或HTTPS方式发送请求进行模糊测试，以提供一个单一的，便携式的，能够稳定模糊测试Web协议的应用程序
安全性测试总结：
6.5.2 可靠性和容错性测试
可靠性（Reliability）：产品在规定的条件下和规定的时间内完成规定功能的能力。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。
可靠性测试结果的评估：成熟性度量可以通过错误发现率DDP（Defect Detection Percentage）来表现。在测试中查找出来的错误越多，实际应用中出错的机会就越小，软件也就越成熟。
DDP=测试发现的错误数量/已知的全部错误数量
已知的全部错误数量是测试已发现的错误数量加上可能会发现的错误数量之和。
容错性测试（Fault-tolrent test）：检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。
测试手段：
①输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
②灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复。
6.5.3 兼容性测试
兼容性测试: 验证软件之间是否正确地交互和共享信息
兼容类别：
- 向后兼容（向下兼容）:可以使用软件的以前版本
- 向前兼容（向上兼容）:可以使用软件的未来版本
- 硬件兼容
- 软件之间兼容
- 数据之间兼容
多版本测试：需要对所有可能的软件组合等价分配，验证软件之间正确交互的最小有效集合。
通常的做法：
①将软件分类。例如：字处理，电子表格，数据库，图形处理，游戏等。从每种类型中选择部分测试软件
②按软件的流行程度选择较流行的软件
③按年份，选取一定年份内的程序和版本
例: 设计测试矩阵表
每一个浏览器和版本支持的特性上都有细微的差别，在不同的操作系统上表现也有所不同。
