《Web项目测试实战》笔记

《Web项目测试实战》刘德宝

1.       测试用例编写与管理

1）  TD创建项目过程：创建被测项目（SiteAdmin>Projects）, 设置项目组别（TD start_a.htm>Customize>Set up Groups），设置项目成员(TD>Customize>Set up Users)

2）  提取需求（TD>Requirements）》将测试需求转化为测试计划Test Plan(Requirements Tools>Convert to tests)》设计测试用例(TestPlan, Details_Descriptions加用例标识和前置条件，Design steps Description加测试数据和步骤)

3）  需求提取的方法：根据spec的需求定义/按测试要求或开发提供的功能列表或检查 进行提取，每一个客户需求/测试要求 就是一个测试需求，同时可以根据需求的性质进行分类，如功能、性能、安全等。测试需求尽量分析清晰，最好能细化到每一个功能点（最小功能单元）。功能测试又称数据驱动测试，那么只要存在数据流转，就可以看做系统的最小功能单元。

4）  需求提取后小组内要进行评审，小组成员互相阅读，检查遗漏点和错误点，记录，修改，评审，直至通过。用例设计好之后也要评审，讨论分析的方式确保正确性和覆盖度。

5）  没有TD也可以根据功能结构图或业务流程图组织测试

6）  设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据（一般情况，极限情况，边界），结合复杂的运行环境，在所有可能的输入和输出条件中确定测试数据。设计准则：测试用例的代表性（合理-不合理，合法-非法，边界-越界，极限的输入数据、操作和环境设置等），测试结果的可判定性和可再现性。

7）  用例维护：随需求变更更新，用例完善，随bug更新，随设计文档更新

2.       测试环境搭建：

1）  列出项目相关的硬件和软件：硬件—主机用途，机型，台数，CPU，内存，硬盘，网卡；软件及版本—OS，Browser（IE,Maxthon,Firefox），web server，编译器，中间件，数据库等

2）  安装OS：有时需要在虚拟机上安装OS，硬盘，网卡，网络连接方式等默认方式不一定行，比如有些主板使用SCSI方式模拟硬盘会导致失败，必须用IDE模式

3）  在提取测试版本时，要检查与系统相关的配置文件、数据库文件或者其他文件是否齐备，确认无误后方可进行环境搭建。

4）  常用数据库有MySQL, SQL Server, Oracle, DB2, Sybase等，每种数据库都有自己的数据生成方式，比如SQL导入、备份还原、数据库附加等。SQL导入方式：

MySQL：登陆 c:/mysql/bin>mysql -u root -p,输入密码；导入数据source c:/xxx.sql。

SQL Server：使用查询分析器，文件à打开sql文件，执行F5

Oracle：SQL plus登陆后命令行 @ c:/xxx.sql 换行后:

5）  被测应用程序部署流程：部署应用程序包，修改数据库连接文件，修改其他配置信息，启动服务与冒烟测试。开始部署前要弄清楚系统有哪些特殊的设置，比如是否需要连接数据库（数据库连接文件的名字和位置），需要设置日志路径吗（哪个文件设置），需要第三方插件吗（如何安装）等。

6）  编辑一些配置文件时可以使用EditPlus编辑器，如果使用记事本等往往会有乱码问题。

7）  常用web服务器：

n         IIS：windows自带，主要解析ASP程序代码，一般可以整合Apache，配置服务时注意权限

n         Apache：开源，支持大多数语言开发的B/S软件，优势是静态页面处理速度，一般与其他的web服务器整合使用（Tomcat，IIS，）。

n         Tomcat：免费Java服务器，主要处理JSP页面和Servlet文件。Tomcat做成集群威力巨大。

n         JBoss：Redhat产品，免费开源，比Tomcat专业些，管理EJB（EnterpriseJavaBean，sun的服务器端组件模型，最大的用处是部署分布式应用程序，类似微软的.net技术。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。）的容器和服务器，本身不支持JSP、Tomcat，需与Tomcat集成。一般下载的都是集成版本。不需安装，解压后配置好环境变量即可。

n         Resin：Caucho产品，支持JSP/Servlet，不管是动态还是静态页面处理速度都很快，可以单独使用，也可以和Apache, IIS整合。

n         WebLogic：BEA产品，用于开发、集成、部署和管理大型分布式web应用、网络应用和数据库应用的Java应用服务器，引入Java的动态功能和JavaEnterprise标准的安全性。专业，费用昂贵。

n         WebSphere：IBM产品，因特网的基础架构软件（中间件），使企业能够开发、部署和集成新一代电子商务应用，支持从简单的web发布到企业级事物处理的商务应用。比WebLogic更专业，也更贵，一般部署在IBM专业的服务器上。

8）  一般将被测系统的应用包放在哪里：IIS--Inetpub/wwwroot，Tomcat—webapps，JBoss—server/defailt/deploy。存放路径可以根据实际情况做出调整。

3.       测试用例执行（TD测试集Test Lab就是本次测试所需测试用例的集合）》缺陷跟踪处理》功能测试报告输出

4.       功能测试用例执行：测试用例可能只包含功能的测试点，这种情况下在执行功能测试用例之前，先看一下除功能之外的测试点，比如性能、页面标题、页面布局等。

1）  性能，打开页面的时间，正常用户可接受时间3-5s左右。“2，5，8，10”2s很爽，5s正常，8-10s无法忍受。

2）  界面设计布局：整体风格一致，比较主观

3）  界面脚本错误：通常测试B/S软件时使用IE—高级设置—勾选“显示每个脚本错误的通知”，取消“显示友好HTTP错误信息”

4）  页面标题：与当前页面一致

5）  正文文字，图片文字，按钮文字：拼写正确，大小合适

5.       缺陷报告：

1）  缺陷修复率=closed/all

2）  缺陷分布 module-number groupby status, 分析哪些模块缺陷多，原因

3）  当前遗留缺陷：非closed+非rejected, 分析哪些模块遗留缺陷多

4）  质量评价一定要在实际数据基础上作出公正严谨的评价，将当前的缺陷修复率与测试计划的项目停测标准进行比较，并作出是否通过测试的判断，同时需写出因某些遗留缺陷而导致当前软件产品发布后可能存在的问题。

6.       性能测试基本概念：

1）  性能测试：正常运行情况下的系统性能是否达标

2）  压力测试：系统在一定饱和状态下是否出错及业务能力。（短时间）

3）  负载测试：持续加压，使性能指标超过预期某资源饱和（长时间）

4）  并发数：在某一个点上并发，是真正产生压力的。通常所说的并发只是某时间段内的业务量，非绝对意义上的并发

5）  在线用户：即已经登录到系统的用户（不一定使用业务），不代表真正的系统压力

6）  PV（页面访问量）PageView：页面刷新次数，一般用在统计页面人气信息，但PV高不代表访问量高

7）  响应时间：用户发出业务请求，服务器接收并处理请求，然后返回结果，客户端接收请求结果的时间，一般不包括将客户端数据显示给用户的时间。最好不要尝试在公网上进行性能测试

8）  吞吐量：单位时间内系统处理用户请求的数量，请求数（单击数/字节数）/单位时间

9）  业务成功率：发起了很多笔业务的成功率

10）  系统资源耗用：CPU、内存使用率，网络带宽的使用情况，磁盘I/O的输入/输出量等

7.       性能测试流程：需求分析，用例设计，脚本录制优化与回放，场景设计和执行，结果收集与分析。

8.       性能测试需求提取流程：

1）  分析提取指标，确定测试点：用户常用功能，系统业务逻辑复杂、数据流转频繁的功能，与外部系统的接口处

2）  建立业务模型，弄清业务流程

3）  评审确定指标

9.       设计性能测试用例时，一定要弄清楚测试点是否存在约束条件，一般可由对应的功能测试用例得到。如一个用户只能一次考勤，一个IP可多次登录.

10.   LR代码录制优化与回放Vuser：

1）  代码优化流程：插入事务点Transaction（LR会监控事务点执行情况，一般用于考察某个具体操作的性能表现）à插入集合点（衡量加重负载情况下的性能Rendezvous）à设置思考时间à插入注释à数据参数化à设置关联à设置文本检查点à插入函数

2）  设置思考时间，录制之前，按照业务流程走一遍要测试的业务，初步估计每一步的操作时间，然后在这个基础上减去1-2s。负载测试时为了对服务器产生最大压力，可以取消思考时间。

3）  参数化设置流程：分析测试数据-》设计分配方式-》查找替换对象-》设定参数化。一般情况下，需要做参数化的地方有: A.数据有唯一性要求，如ID；B.系统不允许同样的数据多次使用，如一个用户只能登陆一次；C. 想更真实的模拟用户业务、分散用户行为。注意选择unique number参数类型时，设置的数据量要足够大（block size per Vuser*Vuser数。如模拟30分钟2000用户登录，每次业务执行时间约6秒，那么一个Vuser30分钟可以完成业务数30*60/6=300次，2000次/（300次/人）约=7人，那么可以设置7个VUser，每个用户大约300个数据，我们设置大点，设成450，那么总数据量就是450*7=3150个

4）  准备测试数据可以用数据导入，LR或QTP进行添加，用SQL完成，手工添加

5）  关联是让脚本自动地获取服务器分配的“号”，在测试过程中用这个号来完成相关的业务操作。关联可将脚本中已经获取的临时数据转变为由服务器提供的、动态变化的、每次都不一样的数值。需要考虑关联的情况：A操作无错，却没有数据出来；B系统中存在动态变化的值，并且是无规律的临时的值；C后面使用的数据是前面的输出，且随业务变化。分自动关联和手动关联

6）  文本检查点：web_find(从页面检查文本，无法查找隐藏文本), web_reg_find（从源代码查找）

7）  函数：

If(…) …; else ….;

Atoi 字符型转换成整型 I = atoi(s)

Strcmp: 字符串比较case-sensitive result=strcmp(s1,s2), result >/</= 0

Stricmp: case-insensitive compare

Strcpy(s1,”c://temp”) 字符串复制 s1=”c/temp”

Lr_log_message(“sss”) 发送日志到Vuser的运行日志

lr_output_message 发送日志到运行过程中的replay log window

lr_message 发送日志到运行日志和replay log window

lr_eval_string 得到参数当前的值，lr_output_message(“当前用户名：%s”,lr_eval_string(“{username}”))

lr_save_string(“439”,”ordered”) 把一个字符串保存到参数中

11.   场景设计与执行LR Controller

1）  流程：确定并发数à确定场景执行计划à设置集合点à设置运行时设置àIP欺骗使用à其他设置à数据监控设置

2）  确定并发数：脚本运行方式--一个业务流程内的测试点可以分为独立的action，或者插入事务点。C_人=n(次)*L(s/人次/T(s)， C平均并发用户数，n login session的数量，L login session的平均时间，T 考察的时间长度，比如平均每天400个用户要访问系统，一个用户从登陆到退出时间为4小时，一天之内只有8小时使用该系统，并发数C=400*4/8=200

3）  确定场景执行计划就是安排场景的持续加压Ramp Up（考察服务器接受请求的应付能力）、运行Duration（稳定性）、与减压Ramp down（是否内存泄露）的方式。场景计划设计分按场景计划和按组计划。按场景计划一般用在单一业务流程性能测试过程中，对多业务需要增加更多业务流程的脚本。按组计划一般用于比较复杂的业务流程，可以设置在同一场景中不同脚本执行的先后顺序，可以组合出相当复杂的业务逻辑。

4）  Run-time settings:

n         Run Logic一般不起作用，因为如果场景执行计划中设定了持续运行时间，那么action具体的执行次数是由服务器响应速度决定的，而不是由客户端决定，即Duration优先级>Run logic

n         Log: 一般调试时选always send messages, 运行时或测试时间很长时选send messages only when an error occurs

n         Miscellaneous：Error handling – continue on error脚本调试时不选

n         Preferences：Enable Image and text check，如测试要求非常严格，最好别使用，因为可能对结果造成影响

5）  IP Spoofer: Vuser模拟从不同的IP发送请求，从而绕过服务器IP限制。IP欺骗应该在连接负载生成器之前启用，各个负载生成器必须使用固定的IP

6）  测试结果存放路径：Results settings。

7）  负载生成器：Design Generators可以将VUser放到安装了Load Runner Agent的机器进行压力分担（如果启动了Agent且关闭了防火墙则会顺利连接）。Generators一般用于并发数很多的情况下，一般一个Vuser大约占2M物理内存，一台1G内存的机器通常可以支持200左右Vuser.

8）  数据监控：LR本身提供常用监控对象OS(windows, linux, unix),Web server(IIS, apache, weblogic, websphere), Database(sql server, oracle, Sybase, db2)。没有Tomcat, mysql，必须使用其他工具.

9）  Spotlight on Mysql, 需要先安装Mysql ODBC驱动。

10) Tomcat自动组件查看Tomcat的JVM耗用情况，但无法动态刷新，不利于统计。Probe, JProfile, JProbe等可以监控Tomcat，但是比较耗内存。可以用试用软件ManageEngine Application Manager，start后用application manager web console. 实际测试时一般监控Tomcat的JVM使用情况就可以了，主要查看该内存使用与预期是否一致。Web server端口？

 http://manageengine.adventnet.com/products/applications_manager/monitor-tomcat.html

10）              windows 资源监控：服务器开启remote procedure call and remote registry服务 services.msc，共享C$，安装LR的机器进入服务器C$就可以监控服务器系统资源了。常用监控指标

n         system.process queen length：指处理队列上的线程数（等待执行），不像磁盘计数器，仅计数就绪的线程数，不计数运行中的线程数。如果总是大于2通常表示处理器堵塞。参考值：小于2

n         processor.precessor time：CPU使用率若持续高于90%，则负载过重。为多处理器服务器添加该计数器的0到X个实例。参考值：小于75%，排除内存因素，如果该计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU瓶颈。

n         Memory.available mbytes: 物理内存可用数。默认IIS5.0使用50%的可用物理内存作为IIS的文件缓存。IIS基本占用2.5MB，每个附加连接将在此基础上占用10KB左右。参考值：至少要有10%

n         Memory.Page faults/sec 处理器向内存指定位置请求一页出现错误数，含软错误（Transition faults/sec 该页在内存其他位置）和硬错误（该页在硬盘）。硬错误将导致明显的拖延。为解决硬错误，从硬盘读取的页数Pages input/sec，次数page reads/sec，读取和写入的页数pages/sec. 如果page reads/sec持续保持5表示可能内存不足. 参考值：pages/sec 00~20，大于80表示内存处理有问题。这些值比较低表示服务器响应请求比较快，否则可能是内存短缺或缓存太大。Pages input/sec可以衡量硬错误页发生的速率，通常值》=page reads/sec

n         Memory.cache bytes: file system cache,默认50%可用物理缓存，需关注该值趋势变化。

n         Network Interface.Bytes Totals/sec 发送和接收字节的速率，包括帧字符在内。用该值和网络带宽比较，可以判断网络连接速度是否瓶颈，比值应小于50%

n         Web service.maximum connections最大连接数，total connections attempts连接尝试总数。

11）              nmon是IBM免费监控Aix和Linux系统的工具。LR监控经常会断掉。51testing有使用方法。下载后修改相关版本文件权限，nmon_x86_fedora5 –fT –s 5 –c 5将结果输出到ServerName_Date.nmon，下载到windows, 用工具nmon analyzer v334.xls打开(Analysis nmon data)，将生成相应的性能统计图表。

12）              场景执行前需要检查服务器和LR所在客户端，关闭不相关的服务和程序