软件测试

软件测试
2011年12月31日
　　软件验收标准
　　1 验收内容
　　a) 功能项测试
　　对软件需求规格说明书中的所有功能项进行
　　测试。
　　b) 业务流程测试
　　对软件项目的典型业务流程进行测试。
　　c) 容错测试
　　容错测试的检查内容包括:
　　1) 软件对用户常见的误操作是否能进行提示;
　　2) 软件对用户的的操作错误和软件错误, 是
　　否有准确、清晰的提示;
　　3) 软件对重要数据的删除是否有警告和确认
　　提示;
　　4) 软件是否能判断数据的有效性, 屏蔽用户的错误输入, 识别非法值, 并有相应的错误提示。
　　d) 安全性测试
　　安全性测试的检查内容包括:
　　1) 软件中的密钥是否以密文方式存储;
　　2) 软件是否有留痕功能, 即是否保存有用户的操作日志;
　　3) 软件中各种用户的权限分配是否合理。
　　e) 性能测试
　　对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明书中的各项性能指标。
　　f ) 易用性测试
　　易用性测试的内容包括:
　　1) 软件的用户界面是否友好, 是否出现中英文混杂的界面;
　　2) 软件中的提示信息是否清楚、易理解, 是否存在原始的英文提示;
　　3) 软件中各个模块的界面风格是否一致;
　　4) 软件中的查询结果的输出方式是否比较直
　　观、合理。
　　g) 适应性测试
　　参照用户的软、硬件使用环境和需求规格说明书中的规定, 列出开发的软件需要满足的软、硬件环境。对每个环境进行测试。
　　h) 文档测试
　　用户文档包括: 安装手册、操作手册和维护手册。
　　对用户文档测试的内容包括:
　　1) 操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块;
　　2) 用户文档描述的信息是否正确, 是否没有歧义和错误的表达;
　　3) 户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达;
　　4) 用户文档对主要功能和关键操作是否提供应用实例;
　　5) 用户文档是否有详细的目录表和索引表。
　　i) 用户有特别要求的测试。
　　2 验收标准
　　1) 测试用例不通过数的比例信息来源：
　　?1 根据场景运行过程中的错误提示信息
　　?2 根据测试结果收集到的监控指标数据
　　一．错误提示分析
　　分析实例：
　　1 ?Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection
　　?Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely
　　分析：
　　?A、应用服务死掉。
　　（小用户时：程序上的问题。程序上处理数据库的问题）
　　?B、应用服务没有死
　　（应用服务参数设置问题）
　　例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
　　?C、数据库的连接
　　(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)
　　2  Error: Page download timeout (120 seconds) has expired
　　分析：可能是以下原因造成
　　?A、应用服务参数设置太大导致服务器的瓶颈
　　?B、页面中图片太多
　　?C、在程序处理表的时候检查字段太大多
　　二．监控指标数据分析
　　1．最大并发用户数：
　　应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
　　在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
　　如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
　　2．业务操作响应时间：
　　? 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
　　? 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
　　? 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
　　3．服务器资源监控指标：
　　内存：
　　1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
　　2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。
　　内存资源成为系统性能的瓶颈的征兆:
　　很高的换页率(high pageout rate);
　　进程进入不活动状态;
　　交换区所有磁盘的活动次数可高;
　　可高的全局系统CPU利用率;
　　内存不够出错(out of memory errors)
　　处理器：
　　1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
　　合理使用的范围在60%至70%。
　　2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
　　CPU资源成为系统性能的瓶颈的征兆:
　　很慢的响应时间(slow response time)
　　CPU空闲时间为零(zero percent idle CPU)
　　过高的用户占用CPU时间(high percent user CPU)
　　过高的系统占用CPU时间(high percent system CPU)
　　长时间的有很长的运行进程队列(large run queue size sustained over time)
　　磁盘I/O：
　　1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
　　2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
　　I/O资源成为系统性能的瓶颈的征兆 :
　　过高的磁盘利用率(high disk utilization)
　　太长的磁盘等待队列(large disk queue length)
　　等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
　　太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
　　过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
　　太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)
　　4．数据库服务器：
　　SQL Server数据库：
　　1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
　　2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
　　3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
　　4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
　　Oracle数据库：
　　1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
　　快存（共享SQL区）和数据字典快存的命中率：
　　select(sum(pins-reloads))/sum(pins) from v$librarycache;
　　select(sum(gets-getmisses))/sum(gets) from v$rowcache;
　　自由内存：    select * from v$sgastat where name=’free memory’;
　　2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
　　缓冲区高速缓存命中率：
　　select name,value from v$sysstat where name in (‘db block gets’,
　　‘consistent gets’,'physical reads’) ;
　　Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
　　3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
　　日志缓冲区的申请情况 ：
　　select name,value from v$sysstat where name = ‘redo log space requests’ ;
　　4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
　　内存排序命中率 ：
　　select round((100*b.value)/decode(.value+b.value), 0, 1, .value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk
　　性能测试问题
　　1.如果web服务器、数据库以及网络都正常，问题会出在哪里？
　　这个问题可以在系统本身，还是在应用服务器中的代码。
　　2.如何发现web服务器的相关问题？
　　利用网络资源的监控，我们可以找到的Web服务器的性能。利用这些监测分析吞吐量我们可以在Web服务器上，点击数每秒
　　期间发生的情况下，一些HTTP响应每秒下载的人数页每秒。
　　3.如何发现数据库的相关问题？
　　运行“数据库”的监督和帮助下， “数据资源图”我们可以找到数据库有关的问题。例如您可以指定您想要的资源来衡量的，然后再运行控制器和比你可以看到数据库的有关问题
　　4.解释所有web录制配置？
　　5.解释一下覆盖图和关联图的区别？
　　覆盖图：它覆盖的内容，这两个图表有着共同的X轴。左Y轴的图表显示，合并后的当前图的价值和权利Y轴显示的价值， Y轴的图表是合并。
　　关联图：图的Y轴的两个图表互相对抗。积极图表的Y轴成为X -轴的合并图。 Y轴的图表合并成为合并后的图Y轴。
　　34.你如何设计负载？标准是什么？
　　负荷试验计划，以决定用户数量，什么样的机器，我们要使用和从那里运行。它是基于两个重要文件，工作分布图和交易资料。任务分布图给我们的信息的用户人数为特定的交易和时间上的负荷。在高峰使用和场外的使用是决定从这个图。交易的个人资料给我们提供了一个有关交易的名字和他们的优先级
　　6.Vuser_init中包括什么内容？
　　业务初始化内容Vuser_init action contains procedures to login to a server.
　　7. Vuser_end中包括什么内容？
　　业务执行场景Vuser_end section contains log off procedures
　　8.什么是think time？think_time有什么用？
　　“Think Time”顾名思义－思考时间。它效仿真实用户在实际操作过程中的等待时间。
　　我们做性能测试，很多时候就要模拟这种状态。例如：某系统，要求满足100用户同时在线操作，响应时间在5秒。如果不设置Think Time，我觉得，你的测试是失败的。大家想想为什么？
　　设置Think Time有两种方式，一种是使用Record think time在录制过程中根据实际等待时间自动的写入脚本。另一种是在脚本录制结束后手动加入到脚本中。接下来我们详细介绍。 思考时间是真实用户在action之间等待的时间。例如：当一个用户从服务器接收到数据时，用户可能需要在响应之前等待几分钟回顾数据，这种推迟被称为思考时间。
　　9.标准日志和扩展日志的区别是什么？
　　Standard Log Option：选择标准日志时，就会在脚本执行过程中，生成函数的标准日志并且输出信息，供调试用。大型负载测试场景不用启用这个选项。
　　扩展日志包括警告和其他信息。大型负载测试不要启用该选项。用扩展日志选项，可以指定哪些附加信息需要加到扩展日志中
　　性能测试步骤
　　第一，分析产品结构，明确性能测试的需求，包括并发、极限、配置和指标等方面的性能要求，必要时基于LOAD测试的相同测略需同时考虑稳定性测试的需求。
　　　　第二，分析应用场景和用户数据，细分用户行为和相关的数据流，确定测试点或测试接口，列示系统接口的可能瓶颈，一般是先主干接口再支线接口，并完成初步的测试用例设计。
　　　　第三，依据性能测试需求和确定的测试点进行测试组网设计，并明确不同组网方案的重要程度或优先级作为取舍评估的依据，必要时在前期产品设计中提出支持性能测试的可测试性设计方案和对测试工具的需求。
　　　　第四，完成性能测试用例设计、分类选择和依据用户行为分析设计测试规程，并准备好测试用例将用到的测试数据。
　　第五，确定采用的测试工具。
　　第六，进行初验测试，以主干接口的可用性为主，根据测试结果分析性能瓶颈，通过迭代保证基本的指标等测试的环境。
　　第七，迭代进行全面的性能测试，完成计划中的性能测试用例的执行。
　　第八，完成性能测试评估报告。
　　　　在进行性能测试的时候，我们需要知道一些有效的性能指标，下面我们来列出一些主要的性能指标：
　　　　一是，通用指标（指Web应用服务器、数据库服务器必需测试项）：
　　*ProcessorTime：指服务器CPU占用率，一般平均达到70%时，服务就接近饱和；
　　*Memory Available Mbyte：可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
　　*Physicsdisk Time ：物理磁盘读写时间情况。
　　二是，Web服务器指标：
　　*Avg Rps：平均每秒钟响应次数＝总请求时间/秒数；
　　*Avg time to last byte per terstion（mstes）：平均每秒业务角本的迭代次数；*Successful Rounds：成功的请求；
　　*Failed Rounds：失败的请求；
　　*Successful Hits：成功的点击次数；
　　*Failed Hits：失败的点击次数；
　　*Hits Per Second：每秒点击次数；
　　*Successful Hits Per Second：每秒成功的点击次数；
　　*Failed Hits Per Second：每秒失败的点击次数；
　　*Attempted Connections：尝试链接数。
　　三是，数据库服务器指标：
　　*User 0 Connections ：用户连接数，也就是数据库的连接数量；
　　*Number of deadlocks：数据库死锁；
　　*Butter Cache hit：数据库Cache的命中情况。
　　性能测试包含哪些
　　基准测试-比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。
　　争用测试：-核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。
　　性能配置-核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。
　　负载测试（Load Test）-是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。
　　强度测试Stress Testing-核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。
　　强度测试在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括
　　Spike testing：短时间的极端负载测试
　　Extreme testing：在过量用户下的负载测试
　　Hammer testing：连续执行所有能做的操作
　　容量测试(Volume Test)：确定系统可处理同时在线的最大用户数
　　关注点：how much（而不是how fast）
　　容量测试，通常和数据库有关，容量和负载的区别在于：容量关注的是大容量，而不需要表现实际的使用。
　　容量测试、负载测试、强度测试的英文解释为：
　　Volume Testing = Large amounts of data
　　Load Testing = Large amount of users
　　Stress Testing = Too many users, too much data, too little time and too little room
　　什么是性能测试，负载测试
　　性能测试（或称多用户并发性能测试）、负载测试、强度测试、容量测试是性能测试领域里的几个方面，但是概念很容易混淆。下面将几个概念进行介绍。性能测试（Performance Test）：通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。
　　关注点：how much和how fast
　　负载测试（Load Test）：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。
　　关注点：how much
　　强度测试（Stress Test）： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括
　　Spike testing：短时间的极端负载测试
　　Extreme testing：在过量用户下的负载测试
　　Hammer testing：连续执行所有能做的操作
　　容量测试(Volume Test)：确定系统可处理同时在线的最大用户数
　　关注点：how much（而不是how fast）
　　容量测试，通常和数据库有关，容量和负载的区别在于：容量关注的是大容量，而不需要表现实际的使用。
　　其中，容量测试、负载测试、强度测试的英文解释为：
　　Volume Testing = Large amounts of data
　　Load Testing = Large amount of users
　　Stress Testing = Too many users, too much data, too little time and too little room
　　可能大家角色性能测试、负载测试和强度测试比较混淆。没错，这三个概念是比较容易使人糊涂。负载测试和强度测试，都属于性能测试的子集。下面举个跑步的例子进行解释。
　　性能测试，表示在一个给定的基准下，能执行的最好情况。例如，在没有负重的情况下，你跑100米需要花多少时间（这边，没有负重是基准）？
　　负载测试，也是性能测试，但是他是在不同的负载下的。对于刚才那个例子，如果扩展为：在50公斤、100公斤……等情况下，你跑100米需要花多少时间？
　　强度测试，是在强度情况下的性能测试。对于刚才那个例子，如果改为：在一阵强风的情况下，你在负重或没有负重的情况下，跑100米需要花多少时间？
　　静态测试与动态测试区别
　　静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
　　动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。
　　如果能执行完美黑盒测试还要执行白盒测试吗？
　　黑盒测试：从用户角度出发，根据规格说明设计测试用例，并不涉及程序的内部特性和内部结构，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。黑盒测试有两个显著特点：
　　（1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以用。
　　（2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。
　　黑盒测试主要是为了发现以下几类错误：
　　　 1、是否有不正确、遗漏或额外的功能实现？
　　2、在接口上，输入是否能正确的接受？能否输出正确的结果？
　　3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
　　4、性能上是否能够满足要求？
　　5、是否有初始化或终止性错误？
　　白盒测试：已知程序的内部结构，检查内部操作是否按规定执行。主要对程序细节进行严密检验，针对特定条件和循环设计测试用例，对程序的逻辑路径进行测试。通过在程序的不同点检查程序状态，确定实际状态是否与预期的状态一致。
　　白盒测试主要是想对程序模块进行如下检查：
　　　 1、程序的所有语句至少执行一次。
　　2、对所有的逻辑条件都能至少执行一次。
　　3、在循环的边界和运行的界限内执行循环体。
　　4、测试内部数据结构的有效性，等等。
　　从以上可以看出就算执行了完美的黑盒测试也是无法测试程序内部特定部位，另外当规格说明本身有误，也不能发现问题。而白盒测试能对程序的内部特定部位进行覆盖测试，所以黑盒和白盒测试为互补关系，结合起来进行测试用例的设计更为合理。
　　经验表明，通常在进行单元测试时采用白盒测试方法，集成测试采用灰盒测试方法，系统测试采用黑盒测试方法
　　系统测试退出标准
　　1) 系统测试用例设计已经通过评审
　　2) 按照系统测试计划完成了系统测试
　　3) 系统测试的功能覆盖率达100％
　　4) 系统的功能和性能满足产品需求规格说明书的要求
　　5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
　　6) 系统测试后不存在A、B、C类缺陷
　　7) D类缺陷允许存在，不超过总缺陷的5％
　　8) E类缺陷允许存在，不超过总缺陷的10％
　　集成测试退出标准
　　1) 集成测试用例设计已经通过评审
　　2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改
　　3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试
　　4) 达到了测试计划中关于集成测试所规定的覆盖率的要求
　　5) 集成工作版本满足设计定义的各项功能、性能要求
　　6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
　　7) A、B类BUG不能存在
　　8) C、D类BUG允许存在,但不能超过单元测试总BUG的50％
　　9) E类BUG允许存在
　　单元测试退出标准
　　1) 单元测试用例设计已经通过评审
　　2) 核心代码100％ 经过Code Review
　　3) 单元测试功能覆盖率达到100％
　　4) 单元测试代码行覆盖率不低于80％
　　5) 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
　　6) 不存在A、B类缺陷
　　7) C、D、E类缺陷允许存在
　　8) 按照单元测试用例完成了所有规定单元的测试
　　9) 软件单元功能与设计一致