软件测试与质量保证课件 第11章 系统测试

第11章系统测试2本章内容系统功能测试性能测试可靠性测试安全性测试可用性测试3本章内容系统功能测试性能测试可靠性测试安全性测试可用性测试系统测试4需求规格说明书功能性需求非功能性需求开发验证系统测试5专门测试人员客观专业权威资源有保证优势：系统测试系统测试（SystemTesting）是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。6被测软件系统功能测试7需求规格说明书软件功能是否满足需求是否有功能遗漏是否有功能冗余系统功能测试8需求规格说明书系统功能测试步骤：1、测试系统中每个功能的场景2、测试系统中的关联功能3、测试系统中的业务流程场景测试场景(scenario)是参与者和系统之间的一系列特定的活动和交互也称为用例实例(usecaseinstance)是使用系统的一个特定情节或用例的一条执行路径。如：使用现金成功购买商品的场景；信用卡支付被拒绝而购买失败的场景。9系统顺序图10事件触发场景测试在图中，有一个基本流和四个备选流。每个可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：场景1

基本流场景2

基本流备选流1场景3

基本流备选流1备选流2场景4

基本流备选流3场景5

基本流备选流3备选流1场景6

基本流备选流3备选流1备选流2场景7

基本流备选流4场景8

基本流备选流3备选流411场景测试案例：在线购物用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。12选购商品付钱交易账号登录生成订单场景测试第一步：确定基本流和备选流：13基本流登录在线购物网站，选择物品，登录帐号，付钱交易，生成订购单备选流1帐号不存在备选流2帐号或密码错误备选流3用户帐号余额不足备选流4用户帐号没有钱备选流x用户退出系统场景测试第二步：根据基本流和备选流来确定场景：14场景1-成功购物基本流场景2-帐号不存在基本流备选流1场景3-帐号或密码错误基本流备选流2场景4-用户帐号余额不足基本流备选流3场景5-用户帐号没有钱基本流备选流4场景测试第三步：设计测试用例对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。右面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。15编号场景/条件帐号密码用户帐号余额预期结果1场景1：成功购物VVV成功购物2场景2：帐号不存在In/an/a提示帐号不存在3场景3：帐号或密码错误（帐号正确，密码错误）VIn/a提示帐号或密码错误，返回基本流步骤34场景3：帐号或密码错误（帐号错误，密码正确）VIn/a提示帐号或密码错误，返回基本流步骤35场景4：用户帐号余额不足VVI提示余额不足V（有效）I（无效）“n/a”（不适用）常见的非功能性测试类型性能测试容量测试健壮性测试安全性测试可靠性测试协议一致性测试兼容性测试16安装性测试可用性测试配置测试文档测试GUI测试外国语言测试网站测试非功能性系统测试的内容质量需求容量测试性能测试兼容性测试安全性测试负载测试故障转移测试验证测试基准测试规划测试系统测试性能可用性兼容性可维护性安全性可靠性18本章内容系统功能测试性能测试可靠性测试安全性测试可用性测试什么是软件的性能世界上第一台计算机“埃尼阿克”由1.8万个电子管组成，占地有两三间教室般大。运算速度仅为每秒5000次加法运算。当时的用户对软件要求不高，只要能工作就行。

现在软件已经成为普通的商品，开始从经济学角度考虑软件。投入产出的关系：要尽可能的少占用硬件资源；运行速度也要尽可能的快。功能与性能的关系软件功能和性能的源头都是来自用户的需求。一个邮件系统来讲：功能：能支持收发30种语言为标题和正文的邮件，并支持粘接10MB的附件。性能：能够在2GBRAM/1GHzCPU的服务器上，支持10000注册用户，日均处理10000邮件，响应时间不超过5s/封。总结：功能的焦点在于“做什么”；性能关注于“做的如何”，表现为软件对“空间”和“时间”的敏感度。软件性能的不同视角用户视角管理员视角开发者视角用户视角的对软件性能计算性能——用户最关心的一个指标，即软件系统有多快。如，一个典型的业务需要花多少时间。资源的利用和回收——就是硬件和软件资源。硬件包括客户端硬件、服务器硬件和网络硬件；软件包括操作系统、中间件和数据库。特别关注系统对内存的使用。启动时间——用户希望系统进入正常工作状态的时间越短越好。稳定性——运行一段时间后会不会出现问题。管理员视角的软件性能关注用户视角关注的软件性能指标和系统状态相关的信息例如知道在并发用户为100，某业务响应时间为6秒的情况下，系统状态如何？CPU与内存达到多少？数据库状况？伸缩性——比如一个系统，在50个并发用户的时候表现正常，但是到1000的时候表现如何？是逐渐下降还是在某个拐点附近急剧下降？23管理员视角的软件性能管理员关注的部分性能相关问题24管理员关心的问题软件性能描述1服务器的资源使用状况合理吗资源利用率2应用服务器和数据库的资源使用状况合理吗资源利用率3系统是否能够实现扩展系统可扩展性4系统最多能支持多少用户的访问系统容量5系统性能可能的瓶颈在哪里系统可扩展性6更换哪些设备能提高系统性能系统可扩展性7系统能否支持7*24小时的业务访问系统稳定性开发视角的软件性能开发人员除了关注响应时间、系统扩展性等性能指标外，更关心如何调整设计和代码实现、系统设置等方法提高软件性能。开发人员关注的部分性能问题25开发人员关心的问题问题所属层次1架构设计是否合理系统架构2数据库设计是否存在问题数据库设计3代码是否存在性能方面的问题代码4系统中是否有不合理的内存使用方式代码5系统中是否存在不合理的线程同步方式设计与代码6系统中是否存在不合理的资源竞争设计与代码性能指标响应时间（Responsetime）并发用户数（Concurrentusers）吞吐量（Throughput）资源使用率（Resourceutilization）点击数（Hitspersecond）响应时间（Responsetime）响应时间指的是客户端发出请求到得到响应的整个过程所经历的时间。用户接口应用服务器数据库服务器时间三层体系结构举例响应时间（Responsetime）响应时间可以细分为：服务器端响应时间：服务器完成交易请求执行的时间，这个时间可以度量服务器处理能力。网络响应时间：网络硬件传输交易请求和交易结果所耗费的时间。客户端响应时间：客户端在构建请求和展现交易结果时所耗费的时间。客户感受的响应时间=以上三者之和并发用户数并发：若干用户同时访问服务器或者同一业务。OA系统经验公式：

并发用户数=使用系统的用户数量*（5%~20%）如果一个OA系统的期望用户为1000个，则只要测试出系统能支持200个并发用户就可以了。但是，一定要考虑典型的业务场景例如一个内部系统一般上班后30分钟左右集中出现用户登录一个教务系统一般在期末考试结束后、选课时出现大量用户较准确的并发用户数计算是根据应用服务器的日志吞吐量（Throughput）吞吐量直接体现软件系统的的性能承载能力，是指单位时间内系统处理的客户请求的数量。可用访问人数/天、业务数/小时等单位来衡量30资源使用率（Resourceutilization）定义：资源使用率指的是对不同资源的使用程度。常见的资源：CPU占用率内存使用率磁盘I/O网络I/O点击数（Hitspersecond）定义：按照客户端向WebServer发起了多少次http请求来计算的。一个客户的业务操作可能若干请求其他指标交易成功率——成功的交易数占总交易请求数的比率。系统恢复时间——当系统出错时，修正错误并重新启动系统所需的时间。其实，凡是用户有关资源和时间的要求都可以被视作性能指标。性能测试就是为了验证这些性能指标是否被满足。常见的性能测试方法负载测试（LoadTesting）LoadRunner、QALoad、WebLoad

压力测试（StressTesting）ApacheJmeter、LoadRunnerya、webbench并发测试（ConcurrencyTesting）QALoad、LoadRunner、BenchmarkFactory、

Webstress、AB-Apache基准测试（BenchTesting）稳定性测试（StabilityTesting）可恢复测试（RecoveryTesting）负载测试（LoadTesting）对负载测试的理解：（1）主要是考察软件系统在既定负载下的性能表现。（2）站在用户角度去观察在一定条件下软件系统的性能表现（3）负载测试的预期结果是用户的性能需求得到满足。负载测试的例子某网站测试需求：可以支持100个并发用户执行各种查询操作，要求各查询操作的响应时间在5秒以内，服务器CPU利用率在80%以下。设计负载测试用例：并发用户数：20、50、80、100、120压力测试（StressTesting）对压力测试的理解：（1）为了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数。（2）这个极端条件并不一定是用户的性能需求，可能要远远高于用户需求。（3）压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。（4）压力测试和负载测试的不同是，压力测试的预期结果是系统出现问题，而我们考察的是系统处理问题的方式。压力测试（StressTesting）用户量压力测试数据量压力测试例如：系统最大支持的同时在线用户数是1000个，压力测试需要测试在1000个用户甚至2000个用户同时在线时系统的表现。例如：在系统内存耗尽情况下，测试系统的运行情况，这种情况下被测试系统也不应该崩溃。压力测试的反常规操作当平均每秒出现1个或2个中断的情形下，应当对每秒出现10个中断的情形来进行特殊的测试；把输入数据的量提高一个数量级来测试输入功能会如何响应；应当执行需要最大的内存或其他资源（如CPU,内存，磁盘，网络）的测试用例；压力测试的反常规操作运行一个虚拟的操作系统中可能会引起大量的驻留磁盘数据的测试用例；两倍的已经极限的并发用户数或者HTTP连接数；随机的关闭及重开连接到服务器上的网络上集线器/路由器的端口（例如，可通过SNMP命令来实现）；把数据库断线然后再重启。容量测试采用特定的手段测试系统能够承载的处理任务的极限值的测试工作。这里的特定手段是指测试人员根据实际运行中可能出现极限，制造相对应的任务组合，来激发系统出现极限的情况。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理容量测试常应用于数据库容量方面的测试，以确定它何时达到使软件发生故障的极限。容量测试还可确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试进行容量测试的首要任务就是确定被测系统数据量的极限，即容量极限。这些数据可以是数据库所能容纳的最大值，也可以是一次处理所能允许的最大数据量等。系统出现问题，通常发生在极限数据量产生或临界产生的情况下，这时容易造成磁盘数据的丢失、缓冲区溢出等一些问题。由图11-1可以看到，随着用户负载增加，响应时间也缓慢的增加，而资源利用率几乎是线形增长。资源利用率接近百分之百时，会出现一个有趣的现象，就是响应以指数曲线方式下降，这点在容量评估中被称为饱和点。饱和点是指所有性能指标都不满足，随后应用发生恐慌的时间点。容量评估的目标是保证用户知道这点在哪，并且永远不要出现这种情况。在这种负载发生前，管理者应优化系统或者增加适当额外的硬件。并发测试（ConcurrencyTesting）对并发测试的理解：（1）一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。（2）负载测试往往就会使用并发来创造负载。（3）并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。并发测试的例子400并发用户，事务失败率（failpercent）>1.35%，软件系统失效。500并发用户，事务失败率（failpercent）>10%，系统中断。600并发用户，事务失败率（failpercent）>80%，系统崩溃。基准测试（BenchTesting）对基准测试的理解：（1）当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。（2）需要打开/关闭新模块至少各做一次测试。关闭模块状态下的系统各个性能指标记下来作为基准，然后与打开模块状态下的系统性能指标作比较。稳定性测试（StabilityTesting）对稳定性测试的理解：（1）考察测试系统在一定负载下运行长时间后是否会发生问题。（2）有些问题只有在运行一天或者一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。稳定性测试可能帮助找到一些大型问题，如死机、崩溃、内存泄露等，因为有些存在内存泄露问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄露的越来越多，就会导致系统崩溃。可恢复测试（RecoveryTesting）对可恢复测试的理解：（1）测试系统能否快速地从错误状态中恢复到正常状态。（2）可恢复测试通常结合压力测试一起来做。性能计数器用来衡量被测系统当前的状况和进行性能测试结果的分析。分为：操作系统级别应用服务器级别数据库级别等单个性能计数器只反映系统性能的一个侧面，需要根据多个性能计数器进行分析48性能计数器Windows操作系统的主要性能计数器49类别计数器Memory可用物理内存由于硬件页面错误而从磁盘读出的页面数文件系统缓存Process被处理器消耗的处理器时间数量处理线程最近使用的内存页…处理器CPU耗用百分比物理硬盘每秒读取硬盘次数…网络接口发送接收字节的速率系统性能计数器JavaEE应用服务器的主要性能计数器50类别计数器JVMJVM堆大小JVM可用堆大小JDBCConnectionPool等待的连接数量总的JDBC连接数JDBC连接池的容量当前活跃的JDBC连接数ExecuteQueue空闲的线程数量队列请求的最久时间已处理的请求总数挂起请求的数量性能计数器数据库服务器的主要性能计数器51类别计数器System数据库进程占用的CPU时间当前的用户连接数Memory缓存命中率当前使用的内存量Lock锁平均等待时间每秒的锁请求数每秒产生的死锁数量I/O被挂起的物理读写每秒页面读写的次数每秒产生的事务数量性能测试工具LoadRunnerQTP泽众公司PerformanceRunnerJmeter...52性能测试工具原理压力和负载测试工具架构53虚拟用户脚本产生器压力产生器压力调度和监控系统压力结果分析工具性能测试工具原理虚拟用户脚本产生器通过Proxy方式实现接收从客户端发送的数据包，记录并将其转发给服务器端接收从服务器端返回的数据流，记录并返回给客户端54性能测试工具原理压力产生器根据脚本内容产生实际的负载例如某测试场景要求产生100个虚拟用户，压力产生器会在调度下生成100个进程或线程每个线程都对指定的脚本进行解释执行5555虚拟用户脚本产生器压力产生器压力调度和监控系统压力结果分析工具性能测试工具原理用户代理用户代理是运行在负载机上的进程，该进程与产生负载压力的进程或线程协作，接受调度系统的命令，调度产生负载压力的进程或线程5656虚拟用户脚本产生器压力产生器压力调度和监控系统压力结果分析工具性能测试工具原理压力调度和监控系统性能测试工具中直接与用户交互的主要内容压力调度工具根据用户的场景要求，设置不同脚本的虚拟用户量、设置同步点等监控系统可以对各种数据库、应用服务器、服务器的主要性能计数器进行监控5757虚拟用户脚本产生器压力产生器压力调度和监控系统压力结果分析工具性能测试工具原理压力结果分析工具辅助进行测试结果的分析一般附带的分析工具能够将监控系统获取的性能计数器值生成曲线图、折线图等图但是，压力结果分析工具本身不能代替分析者进行性能结果的分析5858虚拟用户脚本产生器压力产生器压力调度和监控系统压力结果分析工具性能测试团队59工作角色具体职责测试经理和其他项目干系人交互确保测试的外部环境制定测试计划监控测试进度发现和处理测试中的风险测试设计员定义性能规划识别用户的性能需求建立性能场景测试开发员实现已设计的性能场景脚本开发、调试确定测试时需要监控的性能指标、性能计数器测试员部署测试环境执行脚本和场景根据监控要求记录测试结果、记录性能指标和性能计数器值测试分析员根据测试结果、性能指标的数值、性能计数器值进行分析；根据性能规划，分析出系统性能瓶颈，或是给出优化建议性能测试过程模型606.测试分析2.测试工具引入1.测试前期准备4.测试设计与开发3.测试计划5.测试执行与管理性能测试过程通用模型（PTGM）JMeterJmeter简介/watch/5795678631684416056.html?page=videoMultiNeedJmeter脚本录制/v_show/id_XOTE3ODQ2ODky.htmlJmeter脚本执行/watch/7969513224641868131.html?page=videoMultiNeedJmeter脚本优化/watch/03350326185846515067.html?page=videoMultiNeed61JMeter简介Jmeter是一个开源性能测试工具具有三个典型优点：扩展性好开源灵活62Jmeter基础概念Jmeter与其它性能测试工具具有一致的4个部分：负载发生器通常以多线程方式模拟用户行为用户运行器脚本运行引擎资源监视器报表生成器63Jmeter中的主要元件TestPlan（测试计划）ThreadGroup（线程组）可看成是一个虚拟用户组Sampler（采样器）向服务器发送请求、记录响应信息、记录响应时间的最小单元LogicController（逻辑控制器）Listener（监听器）对测试结果数据进行处理和可视化展示的一系列元件64Jmeter中的次要元件ConfigElement(配置元件)提供对静态数据的配置Timer(定时器)用于在操作之间设置等待时间Assertions(断言)检查测试中得到的相应数据是否符合预期PreProcessors(前处理器)对即将发出的请求进行特殊处理PostProcessors(后处理器)65Jmeter测试实例一测试中国石油大学（华东）的云课堂/meol/homepage/common/了解该网站在负载达到20QTS（每秒查询率）时的响应时间66Jmeter测试实例一测试步骤：建立空TestPlan为TestPlan增加ThreadGroup增加HttpRequestSampler添加ViewResultsinTable调试TestPlan67JMeter+BadBoy的性能测试Jmeter在执行性能测试时是运行的脚本脚本记录了执行过程BadBoy工具可以录制一段操作，并导出成Jmeter脚本68JMeter+BadBoy的性能测试测试过程BadBoy录制脚本Jmeter打开脚本配置线程组的参数添加监听器开始测试分析测试结果69Jmeter图形报表70Jmeter图形报表样本数目是总共发送到服务器的请求数。最新样本是代表时间的数字,是服务器响应最后一个请求的时间。吞吐量是服务器每分钟处理的请求数。平均值是总运行时间除以发送到服务器的请求数。中间值是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。偏离表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。7172本章内容系统功能测试性能测试可靠性测试安全性测试可用性测试73明确软件错误、缺陷、故障与失效的概念边界，建立统一的认知框架错误与缺陷错误是人为疏忽导致的逻辑偏差，缺陷是错误在代码中的具体体现，二者属于开发阶段的内在问题。故障故障是缺陷被激活后在系统中表现出的异常状态，是静态缺陷向动态失效转化的中间环节。失效失效是软件未能执行规定功能的外部可观测事件，直接体现为系统行为偏离用户预期。概念关联错误引发缺陷，缺陷在特定条件下触发故障，故障积累或传播最终导致系统失效。

软件失效74软件可靠性度量可靠度：指软件在规定条件下和规定时间内，不引起系统失效的概率。设规定的时间为t0，软件发生失效的时间为t，则：R(t0)=P(t>t0)失效率：软件在规定条件下和规定时间内，丧失规定功能的概率。设规定的时间为t0，软件发生失效的时间为t，则：F(t0)=P(t>t0)失效率与可靠度的关系：F(t0)=1-R(t0)平均失效前时间（MTTF）：指当前时间到下一次失效时间的均值。平均故障间隔时长（MTBF）：周期内总时长/故障次数，代表平均故障间隔时长，用于考核周期内的故障的频繁程度。故障出现了总要修复，修复后可能再次出现，这个指标对经常重复出现的故障也很有参考意义。可理解为这个产品平均每隔一个MTBF就会发生一次故障。平均故障修复时长（MTTR）：每个故障会有一定的不可用时长，MTTR是统计各级故障的平均不可用时长。故障率（风险函数）：维修率：平均无故障时间平均维护时间有效度残留的缺陷数目：可以采用撒播模型、Akiyama模型、Halstead模型等进行估计。可靠性：75软件运行剖面该系统根据用户使用软件方式分为系统模式1与系统模式2两种系统模式，其中系统模式1被用户使用的概率为0.6，系统模式2被用户使用的概率为0.4。该系统共有功能1~功能5等5个功能，其中系统模式1下使用功能1、功能2、功能3，使用的概率分别为0.2、0.5、0.3；系统模式2下使用功能2、功能4、功能5，使用的概率分别为0.2、0.4、0.4；这样可以求得每个功能的使用概率，例如功能2的使用概率为：0.6×0.5+0.4×0.2=0.38。软件可靠性模型软件可靠性模型类型特点代表性模型呈指数分布的NHPP模型认为累积缺陷是一个独立增量过程，其服从Poisson分布，并利用指数分布来描述缺陷的增长趋势Jelinski-Moranda模型Schneidewind模型通用指数模型、Shooman模型Musa基本模型非指数分布的NHPP模型认为累积缺陷数是一个独立增量过程，其服从Poisson分布，并利用非指数分布来描述缺陷的增长。相对于之后的缺陷排除，早期的缺陷排除对失效强度有更大的影响Musa&Okumoto对数泊松执行时间模型Duane模型Yamada的S型模型Brooks和Motley二项式泊松模型类型贝叶斯模型贝叶斯方法认为，如果一个程序在不被使用的代码中包含许多缺陷，那么这种软件所表现出的可靠度可能要比在经常使用的代码中包含一个缺陷的软件高。贝叶斯模型的特点则是认为可以根据历史数据或专家经验对模型中的参数有一些认识，即可以通过先验分布来考虑先验知识与参数之间的关系，从而获得更为准确的评价结果Litlewood-Verrall模型（L-V模型）软件可靠性测试软件可靠性测试是指在预期的使用环境中，为检出软件缺陷，验证和评估是否达到用户对软件可靠性需求而组织实施的一种软件测试。目的：（1）有效地发现程序中影响软件可靠性的缺陷，从而实现可靠性增长。验证软件可靠性满足一定的要求：通过对软件可靠性测试中观测到的失效情况进行分析，可以验证软件可靠性的定量要求是否得到满足。估计、预计软件可靠性水平。通过对软件可靠性测试中观测到的失效数据进行分析，可以评估当前软件可靠性的水平，预测未来可能达到的水平，从而为开发管理提供决策依据。软件可靠性增长测试软件可靠性增长测试的目的是为了有效地发现程序中影响软件可靠性的缺陷，通过排除这些缺陷实现软件可靠性增长；根据失效数据可以评估当前软件可靠性的水平，预测末来可能达到的水平，从而为软件开发管理提供决策依据。软件可靠性增长测试的特点测试目的通过测试—可靠性分析—修改—再测试—再分析—再修改的循环过程，使软件达到可靠性要求测试人员通常由软件研制方而非使用方进行测试测试阶段通常在软件系统测试阶段测试场所一般在实验室中进行测试对象软件产品的中间形式

测试方法基于操作剖面的随机测试方法测试特征测试过程中软件出现失效后修改软件、排除引起失效的缺陷，从而实现软件可靠性的增长软件可靠性增长测试——流程（1）测试策划阶段（2）测试设计与实现阶段（3）软件可靠性增长测试执行阶段（4）软件可靠性测试总结阶段81本章内容系统功能测试性能测试可靠性测试安全性测试可用性测试安全性测试软件安全性是指在非正常条件下不发生安全事故的能力。安全性测试是检查系统对非法侵入的防范能力，其目的是为了发现软件系统中是否存在安全漏洞。在安全性测试过程中，测试者扮演着一个试图攻击系统的角色。测试者可以尝试通过外部的手段来获取系统的密码，使用能够瓦解任何防护的客户软件来攻击系统；可以把系统“制服”，使别人无法访问；可以有目的地引发系统错误，期望在系统恢复过程中侵入系统；可以通过浏览非保密的数据，从中找到进入系统的钥匙等。只要有足够的时间和资源，好的安全测试就一定能够侵入一个系统。82安全性测试安全性一般分为两个层次，即应用程序级的安全性和系统级别的安全性，它们的关系如下：（1）应用程序级别的安全性包括对数据或业务功能的访问；而系统级别的安全性包括对系统的登录或远程访问。（2）应用程序级别的安全性可确保在预期的安全性情况下，操作者只能访问特定的功能或用例，或者只能访问有限的数据。例如，某财务系统可能会允许所有人输入数据，创建新账户，但只允许管理员才能删除这些数据或账户。（3）系统级别的安全性确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的入口来访问。83安全性测试方法功能验证漏洞扫描模拟攻击试验侦听技术84安全性测试步骤（1）执行系统，进行使用环境中的风险和威胁分析。（2）以一种它们可以和系统的安全性动作相比较的方式来定义安全性需求和划分优先级。基于威胁分析，为系统定义安全需求，最关键的安全性需求应该得到最大程度的关注。注意，系统最弱的链接也是重要的，定义安全性需求是一个多次反复的过程。（3）模拟安全行为。基于划分的安全需求的优先次序，识别形成系统安全动作的功能和它们依赖的优先顺序。（4）执行安全性测试。要求使用合适的证据收集和测试工具。（5）估计基基于证据的安全活动的可能性和影响。合计出一个准确的结果及系统是否满足安全性需求。85安全性测试工具AppScanAppScan提供了多种安全测试功能，涵盖了应用程序安全测试的各个方面。静态应用程序安全测试（SAST）通过分析源代码、字节码或二进制文件来检测安全漏洞，例如SQL注入，提供详细的修复建议。动态应用程序安全测试（DAST）模拟攻击者的行为，测试应用程序对实际攻击的响应和漏洞。交互式应用程序安全测试（IAST）结合SAST和DAST的优点，通过监控应用程序的内部行为来识别和定位安全漏洞。此外，AppScan还提供针对iOS和Android应用程序的移动应用程序安全测试，确保移动应用在各种平台上的安全性。8687本章内容系统功能测试性能测试可靠性测试安全性测试可用性测试可用性测试可用性测试（UsabilityTesting）是对于用户友好性的测试，是指在设计过程中被用来改善易用性的一系列方法。测试人员为用户提供一系列的操作场景和任务，让他们去完成，这些场景和任务与产品或服务密切相关，通过观察来发现完成过程中出现了什么问题、以及用户喜欢或不喜欢哪些功能和操作方式，并针对