精华内容
下载资源
问答
  • 二、测试步骤 1、编写性能测试方案 由于我是刚进入此项目组不久,只参与了其中3个模块的功能测试,遍接口回归测试,所以在写性能测试方案时,首先将业务流程、业务功能梳理了遍,重点对将要性能测试的接口的...

    一、项目背景

    我们的平台为全国某行业监控平台,经过3轮功能测试、接口测试后,98%的问题已经关闭,决定对省平台向全国平台上传数据的接口进行性能测试。

    二、测试步骤

    1、编写性能测试方案

       由于我是刚进入此项目组不久,只参与了其中3个模块的功能测试,一遍接口回归测试,所以在写性能测试方案时,首先将业务流程、业务功能梳理了一遍,重点对将要性能测试的接口的文档再次仔细看一遍,在导师的引导下,对各个接口响应的功能更加了解,收获最大是,性能测试应该对应各接口的实际功能,设计合适的用例,如:针对某一对象,有两种数据上传,一种是实时数据,一种是历史数据,此时,实时数据就应该更多考虑连续上传的稳定性,而历史数据应该更多考虑数据堆积后,一次上传多条(1000条)数据的情况,要去更多关注数据上传后的正确性,完整性。

       对各个接口功能和数据上传逻辑梳理清楚后,将每个接口性能测试的方法、测试项、需要的数据都设计好,整理后就是我们的测试方案了。下面是部分截图,

       测试方案是在在即实际操作尝试可行的情况下编写的,后续施行的过程中发现的需要调整的地方,按实际需求进行了调整。文档末我会附上本次性能测试中出现的问题和解决方法,希望对新学性能测试的盆友们有所帮助~

    2、测试方案讨论

      将测试方案提交导师审核后,小组内开会讨论了此方案,组长对不合适的地方提出改进意见,同事们提出自己的想法,还有不清楚的地方也在大家的讨论中更明朗了。通过讨论后,测试方案变得更贴合项目需要、更可行了。本次需要修改的部分截图如下:

     

    3、性能测试执行

    我们使用Jmeter工具进行测试。接口信息如下:

    协议方式

    HTTP

    请求方式

    POST

    编码格式

    UTF-8

    传输格式

    JSON

    测试脚本使用Java编写,数据打包为json格式。

    4、输出测试报告

    5、分析数据

    6、问题排查

    7、性能改进

    三、案例分享

    下面分析详细一个接口案例--历史数据上传。

    1、创建一个线程组:打开Jmeter.bat,出现图形界面,依次点击如下图:

    2、添加HTTP默认请求:添加此配件为了控制此线程组的访问地址和端口,依次点击如下:

    配置HTTP默认请求参数,根据要测试的IP和端口,如下所示:

    3、数据库连接配置:因为我们要从数据库获取企业信息,所以要配置数据库连接(使用配置元件-JDBC连接配置),若你们用固定的用户名和密码登录,可以省去此步。

    JDBC连接配置:

    Database

    Driver class

    Database URL

    MySQL

    com.mysql.jdbc.Driver

    jdbc:mysql://host:port/{dbname}

    PostgreSQL

    org.postgresql.Driver

    jdbc:postgresql:{dbname}

    Oracle

    oracle.jdbc.driver.OracleDriver

    jdbc:oracle:thin:@host:port:service

    MSSQL

    com.microsoft.sqlserver.jdbc.SQLServerDriver或者net.sourceforge.jtds.jdbc.Driver

    jdbc:sqlserver://IP:1433;databaseName=DBname或者jdbc:jtds:sqlserver://localhost:1433/"+"library"

     

    3、添加仅一次控制器:属于逻辑控制器,用来控制采样器的执行顺序。因为这里的用户只需要登录一次,所以用仅一次控制器,即表示此控制器下的内容在整个线程组运行中只循环一次。

    4、添加HTTP请求:要添加在仅一次控制器下面,才能受它控制。HTTP请求属于Sampler(采样器),然后根据接口文档相关内容填写http请求内容。

     

    5、添加正则表达式提取器:需要在http请求下面添加,因为要从http请求的响应结果中通过正则表达式来提取我们需要的key。

    正则表达式:

        ():括起来的部分就是要提取的。

        .:匹配任何字符串。

        +:一次或多次。

        ?:不要太贪婪,在找到第一个匹配项后停止。

      (3)模板:用$$引用起来,如果在正则表达式中有多个正则表达式,则可以是$2$$3$等等,表示解析到的第几个值给引用名称的那个量(如:key)。如:$1$表示解析到的第1个值。

      (4)匹配数字:0代表随机取值,1代表全部取值,通常情况下填0。

    (5)缺省值:如果参数没有取得到值,那默认给一个值让它取。

     

    6、添加获取当前时间:使用采样器里的BeanShell Sampler。为了方便在Redis里查看数据时知道是什么时间上传的。次数需要在采样器中编写提取当前时间的java脚本。

    7、使用java编写脚本设置上传数据,此处也使用Bean Shell Sampler采样器。数据需要json格式。这里开始,采样器就要添加在线程组下面,因为数据有可能要多次循环上传,如果只部分截图如下:

    8、添加http请求,将刚设置的符合接口要求的数据上传。

    9、添加监听器

    在监听器中设置运行日志保存的位置.

    10、运行后查看结果。

    展开全文
  • CTS 是个兼容性性测试工具。是Android TV 的必备条件。 CTS 是个自动化测试工具,其中包括两个主要软件组件: CTS tradefed 自动化测试框架会在桌面设备上运行,并管理测试执行情况。 单独的测试用例会在被测...

    CTS 是一个兼容性性测试工具。是Android TV 的必备条件。

    CTS 是一个自动化测试工具,其中包括两个主要软件组件:

    • CTS tradefed 自动化测试框架会在桌面设备上运行,并管理测试执行情况。
    • 单独的测试用例会在被测设备 (DUT) 上执行。测试用例采用 Java 语言编写为 JUnit 测试,并打包为 Android .apk 文件,以在实际目标设备上运行。

    CTS的主要测试模型如下:

    这个图是官网上面来的。是CTS运行的主要流程。

    在我做CTS测试的过程中,大概是遵照如下一个流程去测试的:

    1、准备好你要测试的Android 系统

    2、下载CTS 测试工具包

    3、下面media测试包

    4、配置好测试环境,测试用的服务器

    5、进行CTS测试。根据报告重试fail项目。直到你得到一个干净的报告。

    这个是一个比较费时的过程,Android 8.0的测试项目有74万多项。测试时间理论时间需要87个小时的样子。但实际上没有一个星期基本上得不到一个结果。测试时间会受到VPN网络的影响。机器跟服务器中断的影响等。

     

    Android system的需求

    首先你得拿到google的 认证。成为google partner。这样你会得到google的一个指引等等。这是另外一个话题。这里只说一下system的大概需求:首先必须是user模式编译。系统必须有一个device的usb口。需要有widewine playready hdcp2 的drm 等。

     

    固件准备好了之后,你必须到google官网下载CTS 测试工具。这个是开放的。谁都能下载到:

    https://source.android.com/compatibility/cts/downloads

    cts测试工具之外还需要从官网下载media包。大概有4个g的样子,这样能节省你在跑CTS时候的时间。提前内置media,就不需要由盒子在测试过程中去下载媒体了。

     

    这里比较重要的一点是服务器的搭建:

     

    CTS currently supports 64-bit Linux and Mac OS host machines

    google 推荐使用 ubuntu14.04系统。事实证明这个版本的Ubuntu跑起来也是最顺利的。其他版本都有各种中断或者其他小问题。

    1、安装 Ubutnu 14.04

    2、安装openjdk

    3、安装Android SDK 可以参考:https://developer.android.com/studio/command-line/sdkmanager.html

    4、配置adb的环境变量。这个比较重要。

    google 有比较详细的说明:

    参考网站:https://source.android.com/compatibility/cts/setup

     

    服务器搭建好,接下来就是进行测试:

    1、机器必须有唯一标识 也就是deviceID。

    2、打开开发者模式,打开usbdebug 保持屏幕wake

    3、把下载好的media包推进机器里面:进入media包 tools目录下面

    运行拷贝脚本 ./copy_media.sh all

    4、进入CTS 测试套件目录:进入tools目录 :

    ./cts-tradefed 运行进入cts测试命令行

    然后:run cts 进行全模块测试

     

    这样一个流程就可以进行cts 测试。在测试过程中有几个比较重要的命令可能会使用到:

     

    help all

    Display the complete list of available commands

     

    这个是最重要的,这个命令可以让你看到所有的cts 命令帮助。一开始的时候,我就是通过这个了解到这些命令的

     

    –retry

    Retry all tests that failed or were not executed from the previous sessions. Use list results to get the session id.

    run cts -r 0

     

    cts 一定会中断,测试不会中断的肯定是上一百辈子都拯救了整个宇宙一万次。我跑过最顺利的一次cts用了一个星期,因为只跑了32bit的测试。最正常的加上调试一个多月没跑完的。

     

    –module/-m [–module/-m …]

    Run the specified test module or modules.

    run cts -m module

     

    这个命令也比较重要,因为cts测试过程中,可能会涉及到一些软件的更改。修改软件之后,验证是否成功,这个命令就比较有用个,他可以单独测试一个模块。

    –abi

    Force the test to run on the given ABI, 32 or 64. By default CTS runs a test once for each ABI the device supports.

     

    这个命令简直是一个神一样的存在,对于一些64bit的机器。你跑直接run cts 他是需要跑 64bit 跟32bit的两份测试的。但是你加上 -abi 可以指定单独跑32bit 或者64bit的测试,相当于只需要一半的时间可以跑完cts的测试。

     

    可能有些没有vpn的没有办法看到google上面的资料,下面是我从google网站上面抄下来的关于环境配置的一些东西:

     

    设置 CTS

    物理环境

    蓝牙 LE 信标

    如果 DUT 支持蓝牙 LE 功能,则应在与 DUT 的距离不超过五米的范围内放置至少三个蓝牙 LE 信标,以进行蓝牙 LE 扫描测试。这些信标可以为任何类型,不需要进行配置或发射任何特定信号,并且可以包括 iBeacon、Eddystone,甚至模拟 BLE 信标的设备。

    GPS/GNSS

    如果 DUT 支持全球定位系统 (GPS)/全球导航卫星系统 (GNSS) 功能,则应该以合适的信号电平向 DUT 提供 GPS/GNSS 信号(GPS 部分符合 ICD-GPS-200C 标准),以便其接收到相应信号并计算 GPS 位置。GPS/GNSS 信号源的种类不限(可以是卫星模拟器,也可以是室外 GPS/GNSS 信号中继器),只需将 DUT 放在距离窗口足够近的位置以使其可以直接接收到足够强的 GPS/GNSS 信号即可。

    请注意:在进行 GPS 测试时,请确保互联网连接设置未屏蔽 supl.google.com 的 7276 端口的连接。该端口将用于下载 GPS 辅助数据,以便在本地设备上测试位置计算。

    WLAN 和 IPv6

    CTS 测试需要满足以下要求的 WLAN 网络:支持 IPv6,可以将被测设备 (DUT) 视为隔离客户端,并可以连接到互联网。隔离客户端是一种配置,可使 DUT 无法接收子网络上的广播/多网消息;这种配置可通过 WLAN AP 配置或通过在未连接其他设备的隔离子网络上运行 DUT 来实现。

    如果您无法访问原生 IPv6 网络、IPv6 运营商网络或 IPv6 VPN,以致无法通过基于 IPv6 的一些测试,则可以改为使用 WLAN 接入点和 IPv6 隧道。请参阅维基百科 IPv6 隧道代理列表

    台式机设置

    注意:CTS 目前支持 64 位 Linux 和 Mac OS 主机。CTS 无法在 Windows 操作系统上运行。

    ADB 和 AAPT

    在运行 CTS 之前,请确保您已安装最新版本的 Android 调试桥 (adb) 和 Android 资源打包工具 (AAPT),并将这些工具的位置添加到计算机的系统路径中。

    要安装 ADB,请下载适用于您的操作系统的 Android SDK 工具包,打开它,然后按照附带的 README 文件中的说明进行操作。要了解问题排查相关信息,请参阅安装独立 SDK 工具

    确保 adb 和 aapt 位于您的系统路径下。以下命令假定您已在主目录中打开了软件包归档文件:


    export PATH=$PATH:$HOME/android-sdk-linux/build-tools/<version>
    

    注意:请确保起始路径和目录名称均准确无误。

    Java 开发套件 (JDK)

    安装正确版本的 Java 开发套件 (JDK)。对于 Android 7.0 -

    如需了解详情,请参阅 JDK 要求

    CTS 文件

    下载并打开与您设备的 Android 版本以及您的设备支持的所有应用二进制接口 (ABI) 相匹配的 CTS 包。

    下载并打开最新版本的 CTS 媒体文件

    设备检测

    请按照相应的步骤设置您的系统以检测设备,例如为 Ubuntu Linux 创建 udev 规则文件。

    Android 设备设置

    用户版本

    兼容的设备被定义为具有 user/release-key 签名版本的设备,因此您的设备应运行基于代号、标签和版本号中已知兼容的用户版本(Android 4.0 及更高版本)的系统映像。

    注意:使用 CTS 确认最终系统映像的 Android 兼容性时,您必须在具有用户版本的设备上执行 CTS。

    初始 API 级别版本属性

    某些 CTS 要求取决于设备最初搭载的版本。例如,如果设备最初搭载的是较低的版本,则不一定需要遵循适用于搭载较高版本的设备的系统要求。

    为了保证 CTS 可读取到这些信息,设备制造商可以定义编译时属性:ro.product.first_api_level。该属性的值是对该设备进行商业化发布时所采用的初始 API 级别。

    OEM 可以将 PRODUCT_PROPERTY_OVERRIDES 添加到其 device.mk 文件以设置这项属性,具体如以下示例所示:

    #ro.product.first_api_level indicates the first api level, device has been commercially launched on.
    PRODUCT_PROPERTY_OVERRIDES +=\
    ro.product.first_api_level=21
    

    注意:对于产品的第一个版本,ro.product.first_api_level 属性应未设置 (0);而对于所有后续版本,该属性应设置为正确的 API 级别值。通过这种方式,该属性可以正确标识新产品,而且我们不会丢失任何关于产品初始 API 级别的信息(值为 0 意味着 ro.product.first_api_level = Build.VERSION.SDK_INT)。

    CTS Shim 应用

    Android 7.0 包含以下预编译的应用(根据此处的源代码编译),这些应用不包含除清单以外的任何代码:

    CTS 会使用这些应用来测试特权和权限。要通过测试,您必须将应用预加载到系统映像上的相应目录下,但不能对它们重新签名。

    存储空间要求

    CTS 媒体压力测试要求将视频剪辑存放在外部存储设备 (/sdcard) 上。大部分剪辑来自 Big Buck Bunny,其版权归 Blender Foundation 所有并采用 Creative Commons Attribution 3.0 许可

    所需空间取决于设备支持的最高视频播放分辨率(要查看所需分辨率的平台版本,请参阅兼容性定义文档中的第 5 部分)。请注意,被测设备的视频播放功能将通过 android.media.CamcorderProfile API(针对早期 Android 版本)和 android.media.MediaCodecInfo.CodecCapabilities API(针对 Android 5.0)进行检测。

    以下是按最大视频播放分辨率列出的存储空间要求:

    • 480x360:98 MB
    • 720x480:193 MB
    • 1280x720:606 MB
    • 1920x1080:1863 MB

    屏幕和存储空间

    1. 任何没有嵌入式屏幕的设备一律需要连接到屏幕。
    2. 如果设备具有存储卡插槽,请插入空的 SD 卡。请使用支持超高速 (UHS) 总线且具有 SDHC 或 SDXC 容量的 SD 卡,或使用至少具有 Class 10 速度的 SD 卡,以确保设备能够通过 CTS。

      警告:CTS 可能会修改/清空插入设备的 SD 卡上的数据。

    3. 如果设备具有 SIM 卡插槽,请将激活的 SIM 卡插入每个插槽。如果设备支持短信,则应填充每个 SIM 卡的号码字段。

    开发者 UICC

    为了执行 CTS 运营商 API 测试,该设备需要使用运营商授权的 SIM 卡。请参阅准备 UICC

    Android 设备配置

    1. 将设备恢复出厂设置:设置 > 备份和重置 > 恢复出厂设置

      警告:这将清空设备中的所有用户数据。

    2. 将设备的语言设置为英语(美国):设置 > 语言和输入法 > 语言
    3. 如果设备具有 GPS 或 WLAN/移动网络功能,则打开位置信息设置:设置 > 位置信息 > 开启
    4. 连接到满足以下要求的 WLAN 网络:支持 IPv6,可以将被测设备 (DUT) 视为隔离的客户端(请参阅上文的物理环境部分),并可连接到互联网:设置 > WLAN
    5. 确保设备上未设置锁定图案或密码:设置 > 安全 > 屏幕锁定 > 无
    6. 在设备上启用 USB 调试设置 > 开发者选项 > USB 调试

      注意:在 Android 4.2 及更高版本中,默认情况下会隐藏开发者选项。要显示这些选项,请依次转到设置 > 关于手机,然后点按版本号七次。返回上一屏幕以查找开发者选项。要查看其他详细信息,请参阅启用设备上的开发者选项

    7. 确保将时间设置为 12 小时格式:设置 > 日期和时间 > 使用 24 小时制 > 关闭
    8. 依次选择:设置 > 开发者选项 > 不锁定屏幕 > 开启
    9. 依次选择:设置 > 开发者选项 > 允许模拟位置 > 开启

      注意:此模拟位置设置仅适用于 Android 5.x 和 4.4.x。

    10. 依次选择:设置 > 开发者选项 > 通过 USB 验证应用 > 关闭

      注意:此验证应用步骤在 Android 4.2 中为必需步骤。

    11. 启动浏览器并关闭任何启动/设置屏幕。
    12. 使用 USB 数据线连接用于测试设备的台式机

      注意:将运行 Android 4.2.2 或更高版本的设备连接到计算机时,系统会显示一个对话框,询问您是否接受允许通过此计算机进行调试的 RSA 密钥。选择“允许 USB 调试”。

    13. 在设备上安装和配置帮助程序应用。

      注意:对于 CTS 版本 2.1 R2 至 4.2 R4,请通过以下命令设置您的设备(或模拟器),以便执行无障碍测试:
      adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk
      在设备上,依次启用:设置 > 无障碍 > 无障碍 > Delegating Accessibility Service

      注意:对于 7.0 之前的 CTS 版本,请在声明 android.software.device_admin 的设备上,使用以下命令设置您的设备,以便执行设备管理测试:
      adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk

      依次选择“设置”>“安全”>“设备管理器”,然后启用两个 android.deviceadmin.cts.CtsDeviceAdminReceiver* 设备管理器。确保 android.deviceadmin.cts.CtsDeviceAdminDeactivatedReceiver 和任何其他预加载的设备管理器均保持停用状态。

    14. 将 CTS 媒体文件复制到设备上,如下所示:

      注意:对于 CTS 2.3 R12 及更高版本,如果设备支持视频编解码器,则必须将 CTS 媒体文件复制到设备上。

      • 导航 (cd) 到下载并解压缩媒体文件的目标路径。
      • 更改文件权限:chmod u+x copy_media.sh
      • 运行 copy_media.sh
        • 要复制分辨率不超过 720x480 的剪辑,请运行:./copy_media.sh 720x480
        • 如果您不确定最大分辨率,请尝试运行 ./copy_media.sh all,以便复制所有文件。
        • 如果 adb 下有多个设备,请将 -s(序列号)选项添加到末尾。例如,要将分辨率不超过 720x480 的文件复制到序列号为 1234567 的设备,请运行:./copy_media.sh 720x480 -s 1234567

     

     

     

     

     

     

    展开全文
  • 个网站基本完工后,需要通过下面几个步骤测试才可以算大功告成并可以交货 基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。 基于Web的系统测试不但需要检查和验证...

    转载:http://www.cnblogs.com/myc618/p/4642320.html

    一个网站基本完工后,需要通过下面几个步骤来测试才可以算大功告成并可以交货

    基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。
    基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。
    重要的是,还要从最终用户的角度进行安全性和可用性测试。 如从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法……

       

    随着Internet和Intranet/Extranet的快速增长,Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。
    许多传统的信息和数据库系统正在被移植到互联网上,电子商务迅速增长,早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。
    Web的流行和无所不在,是因为它能提供支持所有类型内容连接的信息发布,容易为最终用户存取。  

    Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。
    Web工程作为一门新兴的学科,提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。
    它" 使用合理的、科学的工程和管理原则,用严密的和系统的方法来开发、发布和维护基于Web的系统"。
    目前,对于web工程的研究主要是在国外开展的,国内还刚刚起步。  

    在基于Web的系统开发中,如果缺乏严格的过程,我们在开发、发布、实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大。
    而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题。
    当这种情况发生时,我们对Web和Internet的信心可能会无法挽救地动摇,从而引起Web危机。
    并且,Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。  

    在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。
    基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。
    重要的是,还要从最终用户的角度进行安全性和可用性测试。
    然而,Internet和Web 媒体的不可预见性使测试基于Web的系统变得困难。
    因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。  

    一般软件的发布周期以月或以年计算,而Web应用的发布周期以天计算甚至以小时计算。
    Web测试人员必须处理更短的发布周期,测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。  

    网站测试流程、要求及测试报告

    一个网站基本完工后,需要通过下面三步测试才可以交活。 

    一、 制作者测试,包括美工测试页面、程序员测试功能。在做完后第一时间内有制作者本人进行测试。  

    a) 页面包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;图片上有没有错别字;各连接是否是死连接;各栏目图片与内容是否对应等  

    b) 功能达到客户要求;数据库连接正确;各个动态生成连接正确;传递参数格式、内容正确;试填测试内容没有报错;页面显示正确  

    二、全面测试根据交工标准和客户要求,由专人进行全面测试  也是包括页面和程序两方面,而且要结合起来测,保证填充足够的内容后不会导致页面变形。
    另外要检查是否有错别字,文字内容是否有常识错误。  

    三、 发布测试 网站发布到主服务器之后的测试,主要是防止环境不同导致的错误。

    附:网站测试与软件测试的区别    

    软件测试在于于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等    

    软件未达到产品说明书标明的功能。软件出现了产品说明书指明不会出现的错误。    

    软件功能超出产品说明书指明范围。    

    软件未达到产品说明书虽未指出但应达到的目标。    

    软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。  

    测试的主要方面:  

    一、 网站功能测试  

    对于网站的测试而言,每一个独立的功能模块需要单独的测试用例的设计导出,主要依据为《需求规格说明书》及《详细设计说明书》,对于应用程序模块需要设计者提供基本路径测试法的测试用例。 

    网站功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。常用的测试方法如下: 

    1、页面链接测试  
    链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。
    每一个链接是否都有对应的页面,并且页面之间切换工具,如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。
    LinkBotPro不支持中文,中文字符显示为乱码;
    HTML Link Validater只能测试以Html或者htm结尾的网页链接;
    Xenu无需安装,支持asp、do、jsp等结尾的网页,同时能够生成html格式的测试报告。

    链接测试可分为三个方面:  

    1)测试所有链接是否按指示的那样确实链接到了该链接的页面;  

     2)测试所链接的页面是否存在;  

    3)保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。  

    链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。  

    Xenu------主要测试链接的正确性的工具  可惜的是对于动态生成的页面的测试会出现一些错误。

    2、表单测试  
    当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在
    这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。
    例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。
    如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。
    例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。  

    要测试这些程序,需要验证服务器能正确保存这些数据,而且后台运行的程序能正确解释和使用这些信息。  
    B/S结构实现的功能可能主要的就在这里,提交数据,处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能,
    编写可重复使用的脚本代码,可以在测试、回归测试时运行以便减轻测试人员工作量。  
    我们对UM子系统中各个功能模块中的各项功能进行逐一的测试,主要测试方法为:边界值测试、等价类测试,以及异常类测试。
    测试中要保证每种类型都有2个以上的典型数值的输入,以确保测试输入的全面性。  

    3、Cookies测试  
    Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,
    Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。  

    如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作而且对这些信息已经加密。
    测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。  

    4、设计语言测试  
    Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。
    当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。
    除了HTML的版本问题外,不同的脚本语言,例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。  

    5、数据库测试  
    在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。
    在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。  
    在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。
    数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。  

    6、相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确检查按钮的功能是否正确 如新建、编辑、删除、关闭、返回、保存、导入等功能是否正确。

    7、字符类型检查:在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。

      1)标点符号检查:输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。

      2)特殊字符检查:输入特殊符号,如@、#、$、%、!等,看系统处理是否正确。

      3)字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。

    8、中文字符处理:在可以输入中、英文的系统输入中文,看会否出现乱码或出错。

      检查信息的完整性 在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。

    9、信息重复:在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。

    10、检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。

    11、检查添加和修改是否一致:检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型

    12、检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错。同时,也要注意,会不会报和自己重名的错

    13、重复提交表单:一条已经成功提交的纪录,返回后再提交,看看系统是否做了处理。对于Web系统检查多次使用返回键的情况   在有返回键的地方,返回到原来页面,重复多次,看会否出错

    14、搜索检查:有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确。如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确。

    15、输入信息位置:注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。

    16、上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。下载文件能否打开或者保存,下载的文件是否有格式要求,如需要特殊工具才可以打开等。

    17、必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加“*”;对必填项提示返回后,焦点是否会自动定位到必填项。

    18、快捷键检查:是否支持常用快捷键,如Ctrl+C、 Ctrl+V、 Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。

    19、回车键检查:在输入结束后直接按回车键,看系统处理如何,会否报错。

    20、刷新键检查:在Web系统中,使用浏览器的刷新键,看系统处理如何,会否报错。

    21、回退键检查:在Web系统中,使用浏览器的回退键,看系统处理如何,会否报错。对于需要用户验证的系统,在退出登录后,使用回退键,看系统处理如何;多次使用回退键,多次使用前进键,看系统如何处理。

    22、直接URL链接检查:在Web系统中,直接输入各功能页面的URL地址,看系统如何处理,对于需要用户验证的系统更为重要。

    23、空格检查:在输入信息项中,输入一个或连串空格,查看系统如何处理。如对于要求输入整型、符点型变量的项中,输入空格,既不是空值,又不是标准输入。

    24、输入法半角全角检查:在输入信息项中,输入半角或全角的信息,查看系统如何处理。如对于要求输入符点型数据的项中,输入全角的小数点(“。”或“。”,如4。5);输入全角的空格等。

    25、密码检查:一些系统的加密方法采用对字符Ascii码移位的方式,处理密码加密相对较为简单,且安全性较高,对于局域网系统来说,此种方式完全可以起到加密的作用,但同时,会造成一些问题,即大于128的Ascii对应的字符在解密时无法解析,尝试使用“uvwxyz”等一些码值较大的字符作为密码,同时,密码尽可能的长,如17位密码等,造成加密后的密码出现无法解析的字符。

    26、用户检查:任何一个系统,都有各类不同的用户,同样具有一个或多个管理员用户,检查各个管理员之间是否可以相互管理,编辑、删除管理员用户。同时,对于一般用户,尝试删除,并重建同名的用户,检查该用户其它信息是否重现。同样,提供注销功能的系统,此用户再次注册时,是否作为一个新的用户。

    27、系统数据检查:这是功能测试最重要的,如果系统数据计算不正确,那么功能测试肯定是通不过的。数据检查根据不同的系统,方法不同。对于业务管理平台,数据随业务过程、状态的变化保持正确,不能因为某个过程出现垃圾数据,也不能因为某个过程而丢失数据。

    28、系统可恢复性检查:以各种方式把系统搞瘫,测试系统是否可正常迅速恢复。

    二、性能测试 

     网站的性能测试对于网站的运行而言异常重要,但是目前对于网站的性能测试做的不够,
    我们在进行系统设计时也没有一个很好的基准可以参考,因而建立网站的性能测试的一整套的测试方案将是至关重要的。  

    网站的性能测试主要从三个方面进行:连接速度测试、负荷测试(Load)和压力测试(Stress),  

    连接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试,压力测试更像是恶意测试,压力测试倾向应该是致使整个系统崩溃。  

    1、连接速度测试  
    用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。
    当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。
    如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。  
    另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。
    而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。  

    2、负载测试  
    负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。
    负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。
    例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

    3、压力测试  
    负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。
    因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。  
    进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,
    也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。  
    压力测试的区域包括表单、登陆和其他信息传输页面等。  
    采用的测试工具:  性能测试可以采用相应的工具进行自动化测试,我们目前采用如下工具  ab -----Apache 的测试工具  OpenSTA—开发系统测试架构  

    三、接口测试  在很多情况下,web 站点不是孤立。Web 站点可能会与外部服务器通讯,请求数据、验证数据或提交订单。  

    1、服务器接口  
    第一个需要测试的接口是浏览器与服务器的接口。
    测试人员提交事务,然后查看服务器  记录,并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库,确认事务数据已正确保存。  

    2、 外部接口  
    有些 web 系统有外部接口。例如,网上商店可能要实时验证信用卡数据以减少欺诈行  为的发生。
    测试的时候,要使用 web 接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。
    如果商店只使用 Visa 卡和 Mastercard 卡,可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别,
    例如 3 表示 American Express,4 表示 Visa,5 表示 Mastercard,6 代表Discover。)通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。  

    3、错误处理  
    最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错  误,但却无法预期系统所有可能的错误。尝试在处理过程中中断事务,看看会发生什么情况?  
    订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服  务器的连接。在这些情况下,系统能否正确处理这些错误?是否已对信用卡进行收费?
    如果  用户自己中断事务处理,在订单已保存而用户没有返回网站确认的时候,需要由客户代表致  电用户进行订单确认。  

    四、可用性测试

      可用性/易用性方面目前我们只能采用手工测试的方法进行评判,而且缺乏一个很好的评判基准进行,此一方面需要大家共同讨论。  

    1、导航测试  
    导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。
    通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?  
    在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。
    很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。  
    导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。  
    Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

    2、图形测试  
    在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:  

    (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。  

    (2)验证所有页面字体的风格是否一致。  

    (3)背景颜色应该与字体颜色和前景颜色相搭配。  

    (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。  

    3、内容测试  
    内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。  
    信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。
    这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的"拼音与语法检查"功能;
    信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"。  

    4、整体界面测试  
    整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。
    例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?  
    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。  
    对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。  

    五、兼容性测试

      需要验证应用程序可以在用户使用的机器上运行。如果您用户是全球范围的,需要测试各种操作系统、浏览器、视频设置和 modem 速度。最后,还要尝试各种设置的组合。  

    1、平台测试  
    市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。
    Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。  
    因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。  

    2、浏览器测试  
    浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。
    例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,JavaScript是Netscape的产品,Java是Sun的产品等等。
    另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。  
    测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。  
    采用测试工具:  通过白盒测试或者黑盒测试导出的测试用例,采用相应的工具进行测试,可以采用OpenSTA进行测试,此测试工具可以采用不同的浏览器进行测试。

    3.视频测试  
    页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?  

    4.Modem/连接速率测试  
    是否有这种情况,用户使用 28.8 modem下载一个页面需要 10 分钟,但测试人员在测  试的时候使用的是 T1 专线?
    用户在下载文章或演示的时候,可能会等待比较长的时间,  但却不会耐心等待首页的出现。最后,需要确认图片不会太大。  

    5、打印机测试  
    用户可能会将网页打印下来。因此网页在设计的时候要考虑到打印问题,注意节约纸张和油墨。
    有不少用户喜欢阅读而不是盯着屏幕,因此需要验证网页打印是否正常。
    有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。  

    6、组合测试  
    最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错,但是在 IBM 兼容  机上却很难看。
    在 IBM 机器上使用 Netscape 能正常显示,但却无法使用 Lynx 来浏览。  如果是内部使用的 web 站点,测试可能会轻松一些。
    如果公司指定使用某个类型的浏览器,  那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线,可能不需要测试下载施加。  
    (但需要注意的是,可能会有员工从家里拨号进入系统) 有些内部应用程序,开发部门可能  在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。
    但是,理想的情况是,  系统能在所有机器上运行,这样就不会限制将来的发展和变动。  

    六、安全测试

      Web应用系统的安全性测试区域主要有:  

    1、 目录设置  
    Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页  面,这样就不会显示该目录下的所有内容。
    如果没有执行这条规则。那么选中一幅图片,单击鼠标右键,找到该图片所在的路径"… com/objects/images"。然后在浏览器地址栏中手工输入该路径,发现该站点所有图片的列表。
    这可能没什么关系。但是进入下一级目录 "…com/objects" ,点击 jackpot。
    在该目录下有很多资料,其中有些都是已过期页面。如果该公司每个月都要更改产品价格信息,并且保存过期页面。
    那么只要翻看了一下这些记录,就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息,他们在谈判桌上肯定处于上风。  

    2.登录  
    现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。  

    3.Session  
    Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。  

    4.日志文件  
    为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。  

    5.加密  
    当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。  

    6.安全漏洞  
    服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。  
    目前网络安全问题日益重要,特别对于有交互信息的网站及进行电子商务活动的网站尤其重要。
    目前我们的测试没有涵盖网站的安全性的测试,我们拟定采用工具来测定,  
    工具如下  SAINT------- Security Administrator’s Integrated Network Tool  此工具能够测出网站系统的相应的安全问题,并且能够给出安全漏洞的解决方案,
    不过是一些较为常见的漏洞解决方案。  

    七、代码合法性测试

      代码合法性测试主要包括2个部分:程序代码合法性检查与显示代码合法性检查。  

    1、程序代码合法性检查  
    程序代码合法性检查主要标准为《intergrp小组编程规范》,目前采用由SCM管理员进行规范的检查,未来期望能够有相应的工具进行测试。  

    2、显示代码合法性检查  
    显示代码的合法性检查,主要分为Html、JavaScript、Css代码检查,目前采用  HTML代码检查------采用CSE HTML Validator进行测试  JavaScript、Css也可以在网上下载相应的测试工具。


     

    展开全文
  • LoadRunner压力测试实例步骤

    万次阅读 2017-02-20 12:44:15
    LoadRunner 是种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上 千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个 企业架构进行测试。通过使用LoadRunner , ...

    LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上

    千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个

    企业架构进行测试。通过使用LoadRunner , 企业能最大限度地缩短测试时间, 优化性能和加速应用系统的发布周期。目前企业的网络应用环境都必须支持大量用户,网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢, 系统崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源, 无需购置额外硬件而最大限度地利用现有的IT 资源, 并确保终端用户在应用系统的各个环节中对其测试应用的质量, 可靠性和可扩展性都有良好的评价。LoadRunner 是一种适用于各种体系架构的自动负载测试工具, 它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统, 它通过模拟实际用户的操作行为和实行实时性能监测, 来帮助您更快的查找和发现问题。此外,LoadRunner 能支持广范的协议和技术, 为您的特殊环境提供特殊的解决方案。

    1.1 基本步骤

    使用LoadRunner 完成测试一般分为四个步骤:

    1Vvitrual User Generator 创建脚本

    ² 创建脚本,选择协议

    ² 录制脚本

    ² 编辑脚本

    ² 检查修改脚本是否有误

    2)中央控制器(Controller)来调度虚拟用户

    ² 创建Scenario,选择脚本

    ² 设置机器虚拟用户数

    ² 设置Schedule

    ² 如果模拟多机测试,设置Ip Spoofer

    3)运行脚本

    ²  分析scenario

    4)分析测试结果

    2 安装LoadRunner 中文版

    LoadRunner 分为Windows 版本和Unix 版本。如果我们的所有测试环境基于Windows 

    平台, 那么我们只要安装Windows 版本即可。本章讲解的安装过程就是LoadRunner7.8中文的Windows 版本的安装。

    2.1 系统要求

    目前部门的测试机和工作机器足可以满足LoadRunner7.8 的最低要求。不过要比较好

    的运行LoadRunner, 内存最好在512M 以上, 安装LoadRunner 的磁盘空间至少剩余500M。操作系统最好为Windows 2000

    2.2 安装过程

       LoadRunner7.8中文版安装基本分两个步骤:首先安装LoadRunner7.8英文原版,然后安装中文语言插件包

    LoadRunner7.8英文原版存放位置:\\10.138.149.139\ test tools\LR7.8nt.rar将压缩文件拷贝解压到本机的安装,过程比较简单要开始安装LoadRunner,以Administrator 的身份登陆Windows2000 后,运行LoadRunner 安装目录下Setup.exe 即可进入安装程序。

    1. 在“Registration Information” 界面中, 输入序列号( 不用改动, 就是8

    2. 在安装类型界面中, 选择一种安装类型

     

    下面简单的对这三种安装类型进行介绍

    Standalone Installation 将要安装LoadRunner 在一台计算机上

    Network Installation LoadRunner 安装在一个网络驱动器上, 这样任何能连接到这个

    网络驱动器的计算机都可以使用LoadRunner 的部分或者全部组件。

    Network Installation and shortcuts Network Installation 类似,不同的只是这种类型将把

    自己的计算机配置成Workstation 来运行LoadRunner。如果选择了第二项, 我们还需要

    进行2.3 的安装来配置Workstation.。考虑到我们是自己学习研究学习, 选择第一种安装方法。

    3. 在安装方式界面中, 需要选择一种安装方式。建议选择“ 自定义安装”, 这样所有的组件都会一次安装。

    下面简单的对各个安装方式进行介绍

    Typical Installation 安装比较通用的组件, 包括ControllerVuser、在线帮助和脚

    该选项适合于控制Vusers 的机器。

    Load Generator    只安装运行Vusers 产生负载的组件。该选项适合于只产生负载, 

    而不控制Vusers 的机器。

    MI Listener 安装MI Listener 组件, 用来透过防火墙来运行Vusers 并且监视性能。

    Custom Installation 自定义安装, 我们将使用该选项, 安装全部的组件。

     

    4. 在“License Information” 中输入License Key 后,Next, 继续

        100个用户(无时间限制):AEAMAUIK-YAFEKEKJJKEEA-BCJGI

       10000个用户(有时间限制):AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB

    5. 如果是网络安装,最好把网络驱动器映射成本机的一个盘符, 安装LoadRunner 的各级目录不要包含中文字符。

    6. Next 后进入拷贝文件的界面

    7. 拷贝文件完成后, 进入“User Login Settings” 界面。

    Allow virtual users to run on this machine without user login 需要在下面输入域、用

    户名和密码, 这样运行Load Generator 的机器会自动登陆到网络, 

     ●Manual log in to the Load Generator machine 运行Vusers 时, 自动登陆到网络, 

    无需登陆用户名和密码, 这样Vusers 就会不用任何干预自动的启动运行。推荐

    选择该项。这里选择第一项和第二项都可以。

    8. 重新启动, 安装完成

    LoadRunner7.8英文原版存放位置:\\10.138.149.139\test tools\ LoadRunner7.8中文版.rar

    将压缩文件拷贝解压到本机的安装.。过程比较简单要开始安装以Administrator 的身份登陆Windows2000 后,(注意要退出已经运行的英文原版)运行安装目录下Setup.exe 即可进入安装程序,安装过程中一切人机交流窗口多选择默认“下一步”即可

    注意:解压文件存放的文件夹不可起中文名字,安装目录最好使用默认,如果更改则安装目录不要使用中文名!

    3.项目背景介绍

    3.1 背景概述

    LMS网校考试平台”是一个典型的三层B/S架构的MIS系统(客户端/应用服务器/数据库管),中间层是业务逻辑层,应用服务器处理所有的业务逻辑,但应用服务器本身不提供负载均衡的能力,而是利用开发工具提供的ORB(对象请求代理)软件保证多个应用服务器间的负载均衡。本次测试的目的是:进行应用服务器的压力测试,找出应用服务器能够支持的最大客户端数。方法是:按照正常业务压力估算值的1~10倍进行测试,考察应用服务器的运行情况。

    3.2压力测试用例

     场景描述一:

    1. 用户登录的lmm模块,总共登陆24个用户,所有用户都同时并发操作。 

    2. 用户点击“登记的教程”

    3. 用户点击“启动”,进行课程学习,进入DS模块

    4. 在DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    5. 点击“返回LMS”按钮,返回到lmm模块,点击“退出”按钮,退出系统

     

     

    场景描述二:

    1. 用户登陆lmm模块,总共登录48个用户,每1秒登录1个用户

    2. 用户点击“已登记教程”

    3. 用户点击“启动”,进行课程学习,进入DS模块

    4. 在DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习;

    5. 点击“返回LMS”按钮,返回到lmm模块,点击“退出”按钮,退出系统

     

    场景描述三:

    1. 用户登录的lmm模块,总共登陆48个用户,所有用户都同时并发操作。 

    2. 用户点击“登记的教程”

    3. 用户点击“启动”,进行课程学习,进入DS模块

    4. 在DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    5. 点击“返回LMS”按钮,返回到lmm模块

    点击“退出”按钮,退出系统

     

    场景描述四:

    1. 用户登录的lmm模块,总共登陆48个用户,每秒同时登录10个用户。 

    2. 用户点击“登记的教程”

    3. 用户点击“启动”,进行课程学习,进入DS模块

    4. 在DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    5. 点击“返回LMS”按钮,返回到lmm模块,点击“退出”按钮,退出系统

     

    场景描述五: 

    1. 用户登录的lmm模块,总共登陆100个用户,所有用户同时并发操作。 

    2. 用户点击“登记的教程”

    3. 用户点击“启动”,进行课程学习,进入DS模块

    4. 在DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    5. 点击“返回LMS”按钮,返回到lmm模块

     

    场景描述六: 

    1. 用户登录的lmm模块,总共登陆200个用户,所有用户同时并发操作

    2. 用户点击“登记的教程”

    3. 用户点击“启动”,进行课程学习,进入DS模块

    4. 在DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    5. 点击“返回LMS”按钮,返回到lmm模块,点击“退出”按钮,退出系统

     

    场景描述七: 

    1. 户登录的lmm模块,总共登陆24个用户。所有用户都同时并发操作 

    2. 所有用户都同时并发操作,户点击“登记的教程”中“test”课件

    使用自发测试工具,目的测试24个用户同时打开课件时服务器性能

     

    场景描述八: 

    1. 登录的lmm模块,总共登陆60个用户。所有用户都同时并发操作 

    2. 有用户都同时并发操作,户点击“登记的教程”中“test”课件

    使用自发测试工具,目的测试60个用户同时打开课件时服务器性能

     

    4.使用LoadRunner进行负载/压力测试

    4.1录制基本的用户脚本

    创建用户脚本需要用到VuGen。提示: 运行VuGen 最好在1024*768 的分辨率下, 否则有些工具栏会看不到。

    启动Visual User Generator 后, 通过菜单新建一个用户脚本, 选择系统通讯的协议。

    这里我们需要测试的是Web 应用,同时考虑到后台SQL数据库所以我们需要选择Web(HTTP/HTML)协议+SQL SERVER协议,确定后, 进入主窗体。通过菜单来启动录制脚本的命令。

     

    ●在URL 中添入要测试的Web 站点地址..

    ●测试http://lms.ah.sp.com.cn/lms-lmm/loginForm.do选择要把录制的脚本放到哪一个部分, 默认情况下是“Action”。

    这里简单说明一下:VuGen 中的脚本分为三部分:vuser_initvuser_end Action。其

    vuser_init vuser_end 都只能存在一个, 不能再分割, 而Action 还可以分成无数多个部分( 通过点击New 按钮, 新建ActionXXX)。在录制需要登陆的系统时, 我们把登陆部分放到vuser_init 中, 把登陆后的操作部分放到Action 中, 把注销关闭登陆部分放到vuser_end 中。( 如果需要在登陆操作设集合点, 那么登陆操作也要放到Action 中, 因为vuser_init 中不能添加集合点) 在其他情况下, 我们只要把操作部分放到Action 中即可。注意: 在重复执行测试脚本时,vuser_init vuser_end 中的内容只会执行一次, 重复执行的只是Action 中的部分。

     

    ●点“ 选项 ”按钮, 进入录制的设置窗体, 这里一般情况下不需要改动。

    ●然后点“OK” 后,VuGen 开始录制脚本。在录制过程中, 不要使用浏览器的“ 后退” 功能,LoadRunner 支持不太好! 录制过程中, 在屏幕上会有一个工具条出现。录制的过程和WinRunner 有些类似, 不再多介绍。录制完成后, 按下“ 结束录制” 按钮,VuGen 自动生成用户脚本, 退出录制过程。

    4.2 完善测试脚本

    当录制完一个基本的用户脚本后, 在正式使用前我们还需要完善测试脚本, 增强脚本的

    灵活性。一般情况下, 我们通过以下几种方法来完善测试脚本。插入事务、插入结合点、插入注解、参数化输入。这里只举例介绍参数化如何设置,其它只作简单介绍。

    4.2.1 插入事务

    事务(Transaction): 为了衡量服务器的性能, 我们需要定义事务。比如: 我们在脚本

    中有一个数据查询操作, 为了衡量服务器执行查询操作的性能, 我们把这个操作定义为一个事务, 这样在运行测试脚本时,LoadRunner 运行到该事务的开始点时,LoadRunner 就会开始计时, 直到运行到该事务的结束点, 计时结束。这个事务的运行时间在结果中会有反映。

    插入事务操作可以在录制过程中进行, 也可以在录制结束后进行。LoadRunner 运行在

    脚本中插入不限数量的事务。

    具体的操作方法如下: 在需要定义事务的操作前面, 通过菜单或者工具栏插入。输入该事务的名称。注意: 事务的名称最好要有意义, 能够清楚的说明该事务完成的动作。插入事务的开始点后, 下面需要在需要定义事务的操作后面插入事务的“ 结束点”。同样可以通过菜单或者工具栏插入。默认情况下, 事务的名称列出最近的一个事务名称。一般情况下, 事务名称不用修改。事务的状态默认情况下是LR_AUTO。一般情况下, 我们也不需要修改, 除非在手工编写代码时, 有可能需要手动设置事务的状态。

    4.2.2 插入集合点

    插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中, 可能会

    要求系统能够承受1000 人同时提交数据,在LoadRunner 中可以通过在提交数据操作前面加入集合点, 这样当虚拟用户运行到提交数据的集合点时,LoadRunner 就会检查同时有多少用户运行到集合点,如果不到1000 人,LoadRunner 就会命令已经到集合点的用户在此等待, 当在集合点等待的用户达到1000 人时,LoadRunner 命令1000 人同时去提交数据, 从而达到测试计划中的需求。

    注意: 集合点经常和事务结合起来使用。集合点只能插入到Action 部分,vuser_init vuser_end 中不能插入集合点。具体的操作方法如下: 在需要插入集合点的前面, 通过菜单或者工具栏操作输入该集合点的名称。注意: 集合点的名称最好要有意义, 能够清楚的说明该集合点完

    成的动作。

    4.2.3 插入注释

    注释的作用就不多说了, 不过插入注释最好是在录制过程中。具体的操作方法如下: 在需要插入注释的前面, 通过菜单或者工具栏操作

    4.2.4 参数化输入

    如果用户在录制脚本过程中, 填写提交了一些数据, 比如要增加数据库记录。这些操作

    都被记录到了脚本中。当多个虚拟用户运行脚本时, 都会提交相同的记录, 这样不符合实际的运行情况, 而且有可能引起冲突。为了更加真实的模拟实际环境, 需要各种各样的输入。参数化输入是一种不错的方法。

    用参数表示用户的脚本有两个优点: 

    ① 可以使脚本的长度变短。

    ② 可以使用不同的数值来测试你的脚本。例如, 如果你企图搜索不同名称的图书, 你

    仅仅需要写提交函数一次。在回放的过程中, 你可以使用不同的参数值, 而不只搜索一

    个特定名称的值。

    参数化包含以下两项任务: 

    ① 在脚本中用参数取代常量值。

    ② 设置参数的属性以及数据源。

    参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。

    另外, 不是所有的函数都可以参数化的。

    参数化输入的讲解, 我们采用一个例子的方式来进行。

    在本例中我们参数化用户的登陆名:

    先看如下脚本,通过脚本录制找到用户登陆部分,如图

     

    框选住登陆名,点鼠标右键,弹出对话框,选择“替换为新参数”弹出对话框

     

    参数名随意取,建议取通俗易懂的名字,下面我们重点介绍一下参数的类型。

    DateTime: 很简单, 在需要输入日期/时间的地方, 可以用DateTime 类型来替代。

    其属性设置也很简单, 选择一种格式即可。当然也可以定制格式。

    .Group Name:暂时不知道何处能用到,但设置比较简单。在实际运行中,LoadRunner 

    使用该虚拟用户所在的Vuser Group 来代替。但是在VuGen 中运行时,Group Name 

    将会是None 

    .Load Generator Name: 在实际运行中,LoadRunner 使用该虚拟用户所在Load Generator 的机器名来代替。

    .Iteration Number: 在实际运行中,LoadRunner 使用该测试脚本当前循环的次数来

    代替。

    .Random Number: 随机数。很简单。在属性设置中可以设置产生随机数的范围

    .Unique Number:唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。

    注意: 使用该参数类型必须注意可以接受的最大数。例如: 某个文本框能接受的

    最大数为99。当使用该参数类型时, 设置第一个数为1, 递增的数为1, 但100 

    虚拟用户同时运行时,第100 个虚拟用户输入的将是100,这样脚本运行将会出错。

    注意: 这里说的递增意思是各个用户取第一个值的递增数, 每个用户相邻的两次循

    环之间的差值为1。举例说明: 假如起始数为1, 递增为5, 那么第一个用户第一

    次循环取值1, 第二次循环取值2; 第二个用户第一次循环取值为6, 第二次为7; 

    依次类推。

    Vuser ID: 设置比较简单。在实际运行中,LoadRunner 使用该虚拟用户的ID 来代

    替,该ID 是由Controller 来控制的。但是在VuGen 中运行时,Vuser ID 将会是–1

    File: 需要在属性设置中编辑文件,添加内容,也可以从现成的数据库中取数据( 下

    面我们将会介绍) 

    User Defined Function: 从用户开发的dll 文件提取数据。就目前我认为, 这种方式

    没有必要。VuGen 支持语言的语法,在VuGen 中重新编写类似的函数应该不难。

    上面的例子中, 我们取随机数即可。点“Properties… ..” 按钮, 进行属性设置窗口

    添入随机数的取值范围为(1-50), 选择一种数据格式。在“属性” 中有以下几

    个选项: 

    Each Occurrence:在运行时, 每遇到一次该参数, 便会取一个新的值

    Each iteration:运行时, 在每一次循环中都取相同的值

    Once:运行时, 在每次循环中, 该参数只取一次值

    这里我们用的是随机数, 选择Each Occurrence 非常合适。

    下面我们再介绍用数据库中的用户名来参数化登陆用户名。

    框选住登陆名,点鼠标右键,弹出对话框,选择“替换为新参数”弹出对话框,此时参数名输入:name,参数类型选择File,如图

     

    点“属性”按钮, 出现以下窗口

     

    注意: 参数的文件名不要使用con.datpm.dat 或者lpt*.dat 等系统装置名下面我们将会连接数据库, 从数据表中选择用户名。点“数据向导” 按钮,显示如图

     

    使用第项, 选择“使用手动指定SQL语句”点下一步,出现如图窗口

     

    添入连接字符串, 点“创建” 按钮,选择事先配置好的ODBC连接。在SQL语句里输入select查询语句,出现如图窗口

     

    提醒: 在参数数据显示区, 最多只能看到100 行, 如果数据超过100 行, 只能点“编辑” 按钮, 进入记事本看。

    “选择下一行 ” 有以下几种选择: 

    Sequential: 按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取

    Random: 在每次循环里随机的读取一个, 但是在循环中一直保持不变

     ●Unique : 唯一的数。注意: 使用该类型必须注意数据表有足够多的数。比如Controller 中设定20 个虚拟用户进行次循环, 那么编号为的虚拟用户取前个数, 编号为的虚拟用户取6-10 的数, 依次类推, 这样数据表中至少要有100 个数据, 否则Controller 运行过程中会返回一个错误。

    “按编号”指选择列表中的那一列数据,从左到右分别是123依次

    通常用在有关联性的数据上面。我们这里取值Sequential 即可。完成设置关闭即可

    4.3 单机运行测试脚本

    经过以上的各个步骤后, 脚本就可以运行了。运行脚本可以通过菜单或者工具栏来操作。

    执行“ 运行” 命令后,VuGen 先编译脚本, 检查是否有语法等错误。如果有错误,VuGen 

    将会提示错误。双击错误提示,VuGen 能够定位到出现错误的那一行。为了验证脚本的正

    确性, 我们还可以调试脚本, 比如在脚本中加断点等, 操作和在VC 中完全一样, 相信大家谁都不会感到陌生。如果编译通过, 就会开始运行。然后会出现运行结果。

    5实施测试

    5.1 选择脚本,创建虚拟用户

      启用“controller”弹出如图窗口

     

    选择刚才录制并保存好的脚本,添加到方案中,点“确定”出现如图

     

    根据需要修改虚拟用户数量,这里我们取“100”根据实现场景设计,取不同数字

     

    点“编辑计划”细化方案,计划名里选择计划种类:加压,缓慢加压、默认计划或新建立计划。

    ² 默认计划:同时加载所有vuser,直到完成

    ² 加压:每15秒启动2vuser 持续时间5分种

    ² 缓慢加压::每2分种启动2vuser 持续时间10分种

    这里我们选择“加压” 出现如图

     

     点“加压”标签设置加压方法,点“持续时间”标签选择完成时间,点“加压”标签选择退出方法,点“方案开始时间”可以定义时间后自动到点执行,并在一个限定的时间范围内结束,所有设置完毕后,点“ok”返回上一级窗口,点“开始方案”启动运行,出现如图窗口

     

     

    5.2 添加windows资源监视窗口

    loadruner默认性能监视窗口四个,分别是“运行vuser“、”事务响应时间“、

    “每秒点击次数”最后一个可以根据用户自己选择现实什么窗口。打开可用图中目录树,

    选择系统资源,找到windows资源双击,则windows资源监视窗口便自动替换原窗口如上图。当然loadrunner也可以同时显示116个窗口,方法是点右键,在弹出菜单中选择“查看图”选择显示的图数,也可以自定义数字。

    5.3 添加windows性能计数器

    鼠标选择windows资源监视窗口,点击右键弹出菜单中选择“ADD Measurements..”弹出如图窗口

    点“添加”把监视的服务器ip地址输入,点确定,如图

     

    如果可以正常联机到服务器,则在资源度量中会显示全部计数器,此时如果点“确定”则系统默认全部选中,在监视窗口中会显示所有性能曲线,无法单独过滤显示某条曲线,如果选中某个计数器后点“添加”则弹出该项目下的其它性能指标,选择需要的计数器后点“添加”如图

     

    此时要注意,你登陆客户端(也就是你装有loadrunner机器)的用户应该是管理员身份,同时还要保证该用户在被监视的服务器上也是管理员身份。这样选择虽然监视窗口中仍会显示所有性能曲线,但是可以通过鼠标右键弹出菜单,选中你指定的某条曲线单独显示。方法是双击监视窗口放大显示,然后右键选择“仅显示指定图”监视窗口还可以互相叠加等操作,功能强大,通过右键菜单选择可以进行复杂显示操作。常用的还有web程序服务器图、数据库服务器资源图等,添加方法雷同。计数器有那些,有什么含义,理想值是多少,可以参见第六章节。

    5.4 执行脚本

    此时设置完毕后,那就简单了,点击“开始方案”注意观察吧。

     

    5.4.1 分析结果

      脚本执行完毕后,loadrunner会自动分析结果,生成分析结果图或表,方法是点导航栏“结果”选现,在弹出窗口中选择“分析结果”

    6 分析以及监视场景

    在运行过程中, 可以监视各个服务器的运行情况(DataBase ServerWeb Server 等)。

    监视场景通过添加性能计数器来实现。这一章非常的重要, 确定系统瓶颈全靠它了。

    下面重点讲讲需要添加那些计数器, 以及那些计数器代表什么意思。由于Win2000 ProfessionalServer 以及Advanced Server 提供的计数器不完全相同, 这里我们讨论将以Server 为基准。监视场景需要在Run 视图中设置然后, 出现添加计数器的对话框其他的操作就和控制面板“ 性能” 中添加性能计数器的操作一样, 这里不再详细说明。本章主要说明一下各个系统计数器的含义( 数据库的计数器不做重点, 只是拿SQL Server2000 作为例子进行说明。因为数据库各个版本之间差异比较大, 请参考您使用的数据库系统的帮助)。

    6.1 Memory相关

    内存是第一个监视对象, 确定系统瓶颈的第一个步骤就是排除内存问题。内存短缺的问题可能会引起各种各样的问题。

    Object( 对象)

    Counters

    Description( 描述)

    参考值

    Memory

    Available MBytes

    物理内存的可用数( 单位 Mbytes)。默认情况下IIS5.0 使用50%的可用物理内存, 作为IIS 的文件缓存(file cache)。IIS 基本占用 2.5 MB,每个附加连接将在此基础上占用 10 KB 左右

    至少要有10% 的物理

    Memory

    Page/sec 

    Page Faults/sec 

    Pages Input/sec

    Pages Input/sec 

    Page Reads/sec 

    Transition 

    Faults/sec 

     

    物理内存的可用数( 单位 Mbytes)。默认情况下IIS5.0 使用50%的可用物理内存, 作为IIS 的文件缓存(file cache)。IIS 基本占用 2.5 MB,每个附加连接将在此基础上占用 10 KB 左右。至少要有10% 的物理内存值当处理器向内存指定的位置请求一页( 可能是数据或代码) 出现错误时, 这就构成一个Page Fault。如果该页在内存的其他位置, 该错误被称为软错误( 用Transition Fault/sec 数器衡量); 如果该页必须从硬盘上重新读取时, 被称为硬错误。许多处理器可以在有大软错误的情况下继续操作。但是, 硬错误可以导致明显的拖延。Page Faults/sec 是处理器每秒钟处理的错误页( 包括软错误和硬错误)。Pages Input/sec 是为了解决硬错误页, 从硬盘上读取的页数, 而Page Reads/sec 是为了解决硬错误, 从硬盘读取的次数。如果 Page Reads/Sec 比率持续保持为 5, 表示可能内存不足。Pages/sec 是指为解析硬页错误从磁盘

    读取或写入磁盘的页数。

    Page/sec 推荐00-20( 如果服务器没有足够的内存处理其工作负荷, 此数值将一直很高。如果大于80,表示有问题)。这些计数器的值比较低, 说明Web服务器响应请求比较快, 否则可能是服务器系统内存短缺引起( 也可能是缓存太大, 导致系统内存太少)。Page Input/sec 的值可以衡量出硬错误页发生的速率, 通常它的值会于或者等于Page Reads/secMemory Cache Bytes

    Memory

    Cache Bytes

    文件系统缓存(File System Cache

    默默认情况下认情况下为50%的可用物理内存。如为50%的可IIS5.0 运行内存不够时, 它会自动整理用物理内存缓存。需要关注该计数器的趋势变化

    Internet File Cache Hits %

     

    File Cache Hits %是文件缓存命中全部( 对于一个Information File Cache 缓存需求的比例, 反映了IIS 的文件缓大部分是静Services Flushes 存设置的工作情况。而File Cache Hits 态网页组成

    Global File Cache Hits 是文件缓存命中的具体值,File Cache 的网站)File Flushes 是自服务器启动之后文件缓存Cache Hits% 刷新次数, 如果刷新太慢, 会浪费内存; 如果刷新太快, 缓存中的对象会太频繁属于非常好! 的丢弃生成, 起不到缓存的作用。通过File Cache Hits File Cache Flushes 可以得到一个适当的刷新值( 参考IIS 的设置ObjectTTL MemCacheSize MaxCacheFileSize

     

     

     

     

     

    Memory

    PoolPaged BytesPool Nonpaged Bytes

    Pool Paged Bytes Pool Nonpaged Bytes 这两个计数器监视服务器上各个进程的分页池字节数和非分页池字节数。

    在访问数比较固定的情况下, Pool Nonpaged Bytes 是比较定的, 如果访问数逐步增加, 该值会缓慢的增加

    Process

    Virtual Bytes

    Working Set 计数器

    Virtual Bytes( Virtual Bytes 数器监视IIS5.0 保留的例inetinfo 、虚地址空间的数量, 实例化为inetinfo dllhost) Working Set( 实例进程(IIS 运行的核心)Dllhost 进程( 隔离连接池的应用程序必需的)。inetinfo dllhost) Working Set 计数器反映了每个进程使Dllhost#n 进程都用的内存页的数量。系统的内存页(pool 要添加计数器Page) 只能由操作系统的核心模块直接访问, 用户进程不能访问。运行IIS5.0 的服务器上, 负责web 连接的线程以及它需要的一些对象都保存在未分页的池中(nonpaged pool), 比如文件句柄和socket 连接

     

    Process

    Private Bytes

    指这个处理不能与其他处理共享的、已分配的当前字节数

     

    Memory

    Committed 

    Bytes

    是指以字节表示的确认虚拟内存。(确认内存是指为磁盘分

    页文件在磁盘上保留的空间以便在需推荐不超过物理内存的75% 

    要将其写回磁盘时使用)

    推荐部超过物理内存的75

     

     

     

     

    内存问题主要检查应用程序是否存在内存泄漏。如果发生了内存泄漏,Process\Private Bytes 计数器和Process\Working Set 计数器的值往往会升高, 同时Available Bytes 的值会降低。内存泄漏应该通过一个长时间的, 用来研究分析当所有内存都耗尽时, 应用程序反应情况的测试来检验。

    6.2 Processor相关

    Object( 对象)

    Counters

    Description( 描述)

    参考值

    Sytem

    Processor Queue 

    Length 

     

    Processor Queue Length 是指处理列队中的线程数。即使在有多个处理器的计算机上处理器时间也会有一个单列队。不象磁盘计数器, 这个计数器仅计数就绪的线程, 而不计数运行中的线程。如果处理器列队中总是有两个以上的线程通常表示处理器堵塞

    小于2。显示在由 Web 服务器所有处理器共享的队列中等待执行的线程数。处理器瓶颈会导致该值持续大于2

    Processor

    %Processor Time

    CPU 使用率。这是查看处理器饱和状况的最佳计数器。显示所有 CPU 的线程处理时间。如果一个或多个处理器的该数值持续超过 90%,则表示此测试的负

    载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的 到 个实例

    小于75%。排除内存因素, 如果该计数器的值比较大, 而同时网卡和硬盘的值比较低, 那么可以定CPU瓶颈

    System

    Context Switches/sec

    Context Switches/sec 指计算机上的所有处理器全都从一个线程转换到另一个线程的综合速率。当正在运行的线程自动放弃处理器时出现上下文转换, 由一个有更高优先就绪的线程占先或在用户模式和特权(内核)模式之间转换以使用执行或分系统服务。它是在计算机上的所有处理器上运行的所有线程的Thread: Context Switches/sec 的总数并且用转换数量衡量。在系统和线程对象上有上下文转换计数器

    如果切换次数到5000*CPU个数和10000*CPU 个数中, 说明它忙于切换线程而不是

    处理ASP 脚本

    Processo

    %Privileged Time

    % Privileged Time 是在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时, 此服务经常在特权模式运行, 以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。对系统的调用可以是直接的(explicit)或间接的(implicit), 例如页面错误或中断。不像某些早期的操作系统,Windows 除了使用用户和特权模式的传统保护模式之外, 还使用处理边界作为分系统保护。某些由Windows 为您的应用程序所做的操作除了出现在处理的特权时间内, 还可能在其他子系统处理出现

     

    Time

    Switches/sec ( 实例化inetinfo dllhost

    如果你决定要增加线程字节池的大小,你应该监视这三个计数器( 包括上面的一个)。增加线数可能会增加上下文切换次数, 这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高, 就应该减小线程字节池的大小

     

    Processor

    Interrupts/sec %DPC Time

    Time 这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。如果处理器使用率超过Interrupts/sec 指处理器每秒钟接收并维90% 且 硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每Interrupt Time 大于隔 10 毫秒中断处理器一次, 形成了间15%, 则处理隔活动的后台

    如果处理器使用率超过90%,且Interrupts/sec time大于15%则处理器可能负载过重,并发生中断

    Processor Interrupts/sec %DPC Time 这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。如果处理器使用率超过Interrupts/sec 指处理器每秒钟接收并维90% 且 硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每Interrupt Time 大于隔 10 毫秒中断处理器一次, 形成了间15%, 则处理隔活动的后台。器可能负荷过重, 并发生中断。判断应用程序是否存在处理器瓶颈的方法: 如果Processor Queue Length 显示的队列长度保持不变(>=2) 个并且处理器的利用率%Processor Time 超过90%, 那么很有可能存在处理器瓶颈。

    如果发现Processor Queue Length 显示的队列长度超过2, 而处理器的利用率却一直很

    低, 那么或许更应该去解决处理器阻塞问题, 这里处理器一般不是瓶颈。如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(Context Switches/sec 显示的上下文切换次数比较大), 那么就会占用大量的系统资源。如果系统的吞吐量降低并且CPU 的使用率很高,并且此现象发生时切换水平在15000 以上, 那么意味着上下文切换次数过高同时还可以比较Context Switches/sec %Privileged Time 来判断上下文切换是否过量。如果后者的值超过40%, 且上下文切换的速率也很高, 那么应该检查为什么会产生这样高的上下文切换。

    6.3 网络吞吐量以及带宽

    Object

    Counter

    Description

    参考值

    Network Interface

    Bytes Total/se

    Bytes Total/sec 为发送和接收字节的速率, 包括帧字符在内。判断网络连接速该计数器的值和目前网度是否是瓶颈, 可以用该计数器的值和络的带宽相目前网络的带宽比较

    改计数器的值和目前网络带宽相除,结果应该小于50%

    Web Servic

    Maximum Maximum Connections

    Maximum Maximum Connections :“ 最大连接数” Attempts Total Connection Attempts :“ 连接尝试总数” 是从服务启动时利用Web 服务尝试连接的总数。该计数器应用于全部所列的实例。

     

     

    6.4 磁盘相关

    Object( 对象) Counters( 计数器名称) Description( 描述) 参考值

    Object

    Counters

    Description

    参考值

    Network

    Bytes Total/sec

    Bytes Total/sec 为发送和接收字节的速Interface 率, 包括帧字符在内。判断网络连接速度是否是瓶颈, 可以用该计数器的值和目前网络的带宽比较

     

     

    Processo

    %Processor Time

    % Privileged Time

    CPU 使用率该计数器对应于处理器执行Windows. 2000 内核命令( 如处理SQL Server I/O 请求) 所用时间的百分比。如果 Physical Disk 计数器的值很高时该计数器的值也一直很高, 则考虑使用速度更快或效率更高的磁盘子系统。

     

     

    PhysicalDisk

    %Disk Time

    % Disk Time 指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大, 那

    么硬盘不是瓶颈。如果只有%Disk Time 比较大, 另外两个都比较适中, 硬盘可能会是瓶颈。在记录该计数器之前, 请

    在 Windows 2000 的命令行窗口中运行 diskperf -yD 。若数值持续超过 80%, 则可能内存泄漏。

     

    PhysicalDisk

    AverageDisk 

    Queue Length

    指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。

     

     

    PhysicalDisk

    PhysicalDisk

    指在此盘上读取操作的速率

     

    PhysicalDisk

    Disk Writes/sec

    指在此盘上写入操作的速率

     

    判断磁盘瓶颈的方法是通过以下公式来计算: 

    每磁盘的I/O 数 = [读次数 4 * 写次数)] / 磁盘个数

    如果计算出的每磁盘的I/O 数大于磁盘的处理能力, 那么磁盘存在瓶颈。

    6.5 Web应用程序

    这里以ASP.NET 开发的Web 应用程序为例进行说明。

    Object

    Counters

    Description

    参考值

    ASP.NET Applications

    Request/Sec Request Executing

    每秒执行的请求数。

    如果Request/Sec ApplicationsRequest Executing 当前执行的请求数。的值比较小, 你

    Web 程序可能

    是瓶颈

     

    ASP.NET

    ASP.NETRequestWait 

    Time 

    Request Executing Time 

     

     

    最近的请求在队列中等待的毫秒数。执行最近的请求所用的毫秒数。Queued 在理想状况下应该接近0Request Queued 等候处理的请求数。该计数器应保持接近 0。超过 IIS 队列长度会出如果这两个值太大, 那么需要重现“服务器太忙”错误

     

     

     

     

     

     

     

     

     

    6.6 SQL Server

    这里针对SQL Server2000, 而且只是列出比较关键的几个。更加详细的信息可以参考SQL Server 的联机文档。

     

    Object

    Counters

    Description

    参考值

    Processor

    %Processor time

    CPU 使用率

     

    SQL Server: Logins/sec

    这是每秒登录到 SQL Server 的计数

     

     

    SQLServer:CacheManage

    Cache Hit Ratio

    (all instances)

    显示在高速缓存中找到数据的命中率。如果数值持续小于 85%, 则表

    示内存有问题。

     

     

     

    SQL Server

    General Statistics

    User Connections

    显示当前 SQL 用户数。与Active Server PagesRequests/Sec 计数器

    进行比较, 可帮助了解脚本对 SQL Server 的影响程度。如果差别过大, 则表示测试脚本不能有效地对SQL Server 进行应力测试。

     

     

    SQLServer:Locks

    Lock Waits/sec

    显示在当前进程完成之前强制其他进程等待的每秒锁定请求的数量。如果该值始终大于 0, 则表示事务有问题。

     

     

    SQLServer: BuffeManage

    Buffer Manager Hit Ratio

    计数器值依应用程序而定, 但比率最好为 90% 或更高。增加内存直到这一数值持续高于 90%, 表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。

     

     

    SQLServer

    SQL Statistics

    Batch Requests/sec

    每秒收的Transact-SQL 命令批数。这一统计信息受所有约束( 如I/O、用户数、高速缓存大小、请求I/O、用户数、高速缓存大小、请求的复杂程度等) 影响。批请求数值

    高意味着吞吐量很好。

     

     

    SQL Server:

    Buffer Manager 

     

    Lazy Writes/sec

    每秒被缓冲区管理器的惰性写入器写入的缓冲区数。惰性写入器是一

    个系统进程, 其主要任务是刷新成批的老化的脏缓冲区( 指包含更改

    的缓冲区, 这些更改必须写回磁盘, 才能使该缓冲区由其它页重新使

    用), 并使之可由用户进程使用。惰性写入器消除了为创建可用缓冲区而频繁执行检查点的需要。

     

     

    SQL Server: 

    Buffer Manager 

     

    Page Reads/sec

    每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据

    库间的物理页读取总数。由于物理I/O 的开销大, 可以通过使用更大

    的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法, 使开销减到最小。

     

     

    SQL 

    Server:Databases 

     

    Transactions/sec

    每秒为数据库启动的事务数

     

    这里针对SQL Server2000, 而且只是列出比较关键的几个。更加详细的信息可以参考SQL 

    Server 的联机文档。

    6.7 Network Delay

    如果要监视的两台计算机在同一个局域网络内, 建议不要使用Network Delay Monitor

    因为在同一局域网内,Network Delay 会非常的小, 网络监视器会有足够的时间在每秒钟内发送成百上千的请求, 这样会导致源计算机(source machine) 的CPU 和内存超负荷工作。

    默认情况下“Enable display of network nodes by DNS names” 选择是没有选中的, 因为

    选中它会明显的降低该监视器的速度。

    7 分析实时监视图表

    这一章仅仅介绍几个最重要的图表。

    Q1 事务响应时间是否在可接受的时间内? 哪个事务用的时间最长? 

    Transaction Response Time 图, 可以判断每个事务完成用的时间, 从而可以判断出那个事务用的时间最长, 那些事务用的时间超出预定的可接受时间。

    Q2 网络带宽是否足够

    Throughput”图显示在场景运行期间的每一秒钟, 从Web Server 上接受到的数据量的值。

    拿这个值和网络带宽比较, 可以确定目前的网络带宽是否是瓶颈。

    如果该图的曲线随着用户数的增加, 没有随着增加, 而是呈比较平的直线, 说明目前的

    网络速度不能够满足目前的系统流量。

    Q3 硬件和操作系统能否处理高负载

    Windows Resources” 图实时地显示了Web Server 系统资源的使用情况。利用该图提供的数据, 可以把瓶颈定位到特定机器的某个部件。

    8 经常遇到的问题

    8.1 VuGen的问题

    在使用VuGen 中经常会遇到的问题。

    8.2 Controller的问题

    在使用Controller 中经常会遇到的问题。

    1. 在添加完Load Generators 机器时, 连接老是失败; 添加的机器明明已经安装了

    loadrunner, 并且网络通讯正常。

    解决方法: 在安装loadrunner 的第七步骤, 应该选择第项, 如果选择了第一项, 

    就会有这种问题。重新安装一下即可。

    2. VuGen 中运行良好的脚本, 到Controller 中运行却出问题。

    这种问题可能会遇到。为了确定问题出在Controller 中的场景,而不是脚本的问题, 

    你应该在所有的Load Generators 机器上使用VuGen 运行测试脚本, 确保都能够运

    行正确。因为VuGen Controller 运行的机制不一样。在VuGen 中运行时使用的

    是完整的浏览器, 而在Controller 中运行时使用的只是浏览器的基本的部分。

    8.3 计数器的问题

    在使用性能计数器中经常会遇到的问题。

    1. 添加了Windows Resources 计数器后, 却看不到实时的数据。

    解决方法: 要得到监视的数据, 必须要在被监视的服务器(Web Server) 上获得管

    理员权限。最简单的方法是在“ 网络邻居”中以administrator 身份登陆Web Server

    当然使用下面的控制台命令也可以:net use \\< 机器名然后登陆用户名和密码即

    可。(登陆的用户名必须具有管理员权限) 

    2. 添加了一些默认的性能计数器后, 出现了错误。

    解决方法: 可能是一些LoadRunner 默认的计数器在WebServer 上已经不存在的原

    因, 尤其是数据库的计数器方面。简单的解决方法, 就是删除有问题的计数器, 添

    加比较接近的计数器( 可能需要参考Windows 帮助或者数据库的帮助) 

    9.结果分析

    根据不同的场景设计,配置脚本后进行测试得到如下结果

    测试环境

    LMM:

    CPU4x2.7G RAM:4G

    Websphere 5.0 + IBM Http Server  

    线程池:100

    JDBC连接池:100

    会话超时:30分钟

     

    DS:

    CPU4x2.2RAM:4G

    Websphere 5.0 + IBM Http Server 

    线程池:100

    JDBC连接池:100

    会话超时:30分钟

     

    DB&LDAP:

    CPU2x2.2GRAM:4G

    Oralce 8.1.7 + LDAP

     

    测试工具:Load Runner 7.8

    用户数据:用户名test1 – test100; 口令与用户名相同。

     

    测试用例1

    测试场景描述

    用户登录的lmm模块,总共登陆24个用户,所有用户都同时并发操作。 

    用户点击“登记的教程”

    用户点击“启动”,进行课程学习,进入DS模块

    DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    点击“返回LMS”按钮,返回到lmm模块

    点击“退出”按钮,退出系统

    测试结果

    LMMDS模块CPU平均利用率在10%以下。LMM服务器CPU利用率峰值为20%,其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%(持续时间为7秒),其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户平均操作响应时间不超过5秒,所有交易成功。

     

    测试用例2

    测试场景描述

    用户登陆lmm模块,总共登录48个用户,每1秒登录1个用户

    用户点击“已登记教程”

    用户点击“启动”,进行课程学习,进入DS模块

    DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习;

    点击“返回LMS”按钮,返回到lmm模块

    点击“退出”按钮,退出系统

    测试结果

    LMMDS模块CPU平均利用率在5%以下。LMM服务器CPU利用率峰值为10%,其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为8%,其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户操作响应时间不超过3秒,所有交易成功。

    测试用例3

    测试场景描述

    用户登录的lmm模块,总共登陆48个用户,所有用户都同时并发操作。 

    用户点击“登记的教程”

    用户点击“启动”,进行课程学习,进入DS模块

    DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    点击“返回LMS”按钮,返回到lmm模块

    点击“退出”按钮,退出系统

    测试结果

    LMMDS模块CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为40%,其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%(持续时间为10秒),其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户平均操作响应时间不超过10秒,所有交易成功。

    测试用例4

    测试场景描述

    用户登录的lmm模块,总共登陆48个用户,每秒同时登录10个用户。 

    用户点击“登记的教程”

    用户点击“启动”,进行课程学习,进入DS模块

    DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    点击“返回LMS”按钮,返回到lmm模块

    点击“退出”按钮,退出系统

    测试结果

    LMMDS模块CPU平均利用率在10%以下。LMM服务器CPU利用率峰值为10%,其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%(持续时间为2秒),其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户平均操作响应时间不超过5秒,所有交易成功。

    测试用例5

    测试场景描述

    用户登录的lmm模块,总共登录100个用户,每1秒登录一个用户。 

    用户点击“登记的教程”

    用户点击“启动”,进行课程学习,进入DS模块

    DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    点击“返回LMS”按钮,返回到lmm模块

    点击“退出”按钮,退出系统

    测试结果

    LMMDS模块CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为10%,其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%(持续时间为2’20分钟),其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户最大操作响应时间30秒,所有交易成功。

    测试用例6

    测试场景描述

    用户登录的lmm模块,总共登陆100个用户,所有用户同时并发操作。 

    用户点击“登记的教程”

    用户点击“启动”,进行课程学习,进入DS模块

    DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    点击“返回LMS”按钮,返回到lmm模块

    点击“退出”按钮,退出系统

    测试结果

    LMMDS模块CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为40%,其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%(持续时间为3分钟),其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户超时1个。

    测试用例7

    测试场景描述

    用户登录的lmm模块,总共登陆200个用户,所有用户同时并发操作。 

    用户点击“登记的教程”

    用户点击“启动”,进行课程学习,进入DS模块

    DS模块中进行学习,过程包括:首先,点击一次课程结构树;然后,进行课程内容的学习。

    点击“返回LMS”按钮,返回到lmm模块

    点击“退出”按钮,退出系统

    测试结果

    LMM CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为40%,其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%(持续时间为5分钟),其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户超时108个。

    10参考文献

    LoadRunner中文使用手册(完全版) ---作者:huior

    LoadRunner 7.8 联机帮助

    随笔有些是自己写的,有些是根据网上的东西自己整理的,文章基本都是别人的,只是为方便查看复制到那里
    展开全文
  • 因果图设计测试用例的步骤

    千次阅读 2020-03-06 13:13:58
    没有固定的流程说明究竟分解到何种程度才算简单,需要测试人员根据自己的经验和业务复杂度具体分析。 1.1.2. 确定原因和结果 在每个已经分解好的块,找出哪些是原因,哪些是结果。并且把原因和结果分别画出来。...
  • 自动化测试的七个步骤

    千次阅读 2013-07-18 20:05:55
    【摘要】 我们对自动化测试充满了希望,然而,自动化测试却经常带给我们...本文介 绍自动化测试的 7 个步骤:改进自动化测试过程,定义需求,验证概念,支持产品的可测试性,具有可延续性的设计( design for sustaina
  • Linux搭建测试环境详细步骤

    千次阅读 多人点赞 2019-10-01 16:09:02
    本文讲解如何在Linux CentOS下部署Java Web项目的步骤 环境准备 (1)Linux系统 (2)JDK (3)Tomcat (4)MySQL 工具下载 可从官网下载。已把安装工具存于百度网盘:  链接:...
  • TDD(Test-DrivenDevelopment)测试驱动开发是敏捷开发一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。单元测试是最基本的...
  • iOS -真机测试详细步骤

    万次阅读 2012-06-06 15:13:07
    1 进入网址developer.apple.... 2 登录之后,点击右上角的ios Developer Program 下面的ios Provisioning Portal 3 如果添加新设备,点击Devices-->  Add Devices--> 填写Device Name ,Device ID(打开xco
  • 自动化测试的7个步骤

    千次阅读 2006-04-29 11:39:00
    自动化测试的7个步骤 作者: Bret Pettichord 译者:王威 来源: 51testing http://www.csai.cn 2005年12月07日 【摘要】 我们对自动化测试充满了希望,然而,自动化测试却经常带给我们沮丧和失望。虽然,自动化...
  • 测试用例附实例

    万次阅读 多人点赞 2019-03-07 21:10:04
    测试用例的概念 测试用例是测试过程很重要的类文档,它是...测试用例八个基本是:测试用例编号、测试项目、测试标题、重要级别、预置条件、输入、操作步骤、预期输出 (不同公司的测试用例内容不尽相同...
  • 测试开发需要学习的知识结构

    万次阅读 多人点赞 2018-04-12 10:40:58
    努力成为个优秀的测试开发从业者,加油!!! 一些视频链接:我这有一些软件测试的视频,你可以点开看看。转行互联网测试需要哪些技能? - 假装在测试的回答 - 知乎作为名软件测试人员,有哪些网站是你应该多多...
  • SOAPUI测试步骤(四)---The Script TestStep

    千次阅读 2015-09-07 10:52:52
    SoapUI的脚本是个核心,允许您调整您的测试执行的行为您的具体需求。 功能测试范围之内,下面的脚本可能是可用的: TestCase的脚本TestSteps。项目,TestSuite和TestCase的Setup和TearDown脚本。脚本...
  • 自动化测试实施步骤和最佳实践

    千次阅读 2014-09-01 16:21:07
    个故事 :  我在很多软件公司工作过,公司规模有大有小,也和来自其他公司的人员交流,因此经历过... 以 前,我们有个软件项目,开发小组内所有的人都认为应该在项目采用自动化测试。软件项目的经理是 Ani
  • 做好功能测试需要的八基本技能

    千次阅读 2018-11-21 23:11:56
    本文转自乐博学院公众号--软件测试资源共享 功能测试测试工程师的基础功,很多人功能测试还...那么,功能测试需要掌握哪些方面的技能? 、 熟练使用SQL 1、常用的 sql 语句一定会写。比如说增删改查之类。 2...
  • android cts测试方法及步骤

    万次阅读 2014-12-30 10:24:29
    打开下面网址, http://source.android.com/compatibility/downloads.html 以android5.0为例,进入页面后,点击Android 5.0 R1 Compatibility Test Suite (CTS) - ARM进行下载; 当然,如果打不开上面的网址,就是...
  • iOS开发 -xcode真机测试详细步骤

    万次阅读 2012-08-03 13:45:42
    1 进入网址developer.apple.... 2 登录之后,点击右上角的ios Developer Program 下面的ios Provisioning Portal 3 如果添加新设备,点击Devices-->  Add Devices--> 填写Device Name ,Device ID(打开xco
  • 软件测试按照研发阶段一般分为5个部分:单元测试、集成测试、确认测试、系统测试、验收测试下面将不同阶段需要的一些工作内容做一下梳理希望可以帮助到大家。 单元测试(是指对软件的最小可测试单元进行检查和...
  • 测试环境搭建

    万次阅读 多人点赞 2019-02-13 13:44:06
      开发与测试环境一般都是单独搭建的,开发与测试环境的分离是为了方便重现开发环境无法重现的bug,同时开发可以并行地修复bug,如果用开发环境来进行测试,开发人员进行某操作后发生系统崩溃...
  • 工欲善其事必先利其器,现在开始测试工具准备: *准备工作 1.虚拟机工具:vmware (我选择的是7.0的),下载地址: thunder://QUFodHRwOi8vZnRwY25jLXAyc3AucGNvbmxpbmUuY29tLmNuL3B1Yi9kb3dubG9hZC8...
  • 3. 构建测试计划 测试计划描述了系列Jmeter运行时要执行的步骤个完整的测试计划包含个或者多个线程组,逻辑控制,取样发生控制,监听器,定时器,断言和配置元件。
  • 自动化测试的7个步骤(转载)

    千次阅读 2006-01-10 18:23:00
    个故事 : 我在很多软件公司工作过,公司规模有大有小,也和来自其他公司的人员交流,因此经历过或者听说过... 以前,我们有个软件项目,开发小组内所有的人都认为应该在项目采用自动化测试。软件项目的经理是 An
  • 篇文章,我们已经搭建了jenkins的持续集成环境,本文将指导我们如何利用jenkins进行自动化构建。 新建JOB 在Jenkins首页点击“新建”,进入到新建JOB的页面。这里我们先选择“构建个自由风格的软件项目”。...
  • 提交个标准bug应该包含的要素: 1、bug编号 2、所属的系统 3、发现bug所属的模块 4、发现的版本(存在迭代版本的,这个很重要) 5、bug提交人(开发有不清楚的好找到对应人沟通) 6、bug的错误类型:代码错误、...
  • 单元测试1-为什么需要单元测试

    千次阅读 2016-10-10 11:35:11
    为什么需要单元测试  软件开发的标准过程包括以下几个阶段:『需求分析阶段』→『设计阶段』→『实现阶段』→『测试阶段』→『发布』。其中测试阶段通过人工或者自动手段来运行或测试某个系统的过程,其目的...
  • 【转】自动化测试的七个步骤

    千次阅读 2009-11-18 12:18:00
    不过,回归测试检查列表只是合于那些了解产品,并且知道需要采用测试方法的人。 在你开始测试自动化之前,你需要完善上面提到的回归测试检查表,并且,确保你已经采用了确定的的测试方法,指明测试中需要什么...
  • 2019 Python接口自动化测试框架实战开发(

    万次阅读 多人点赞 2019-06-28 15:55:25
    说明:该篇博客是博主一字码编写的,实属不易,请尊重原创,谢谢大家! 目录 丶叙述 二丶接口基础知识 三丶接口测试工具 四丶Fiddler的使用 五丶unittest使用 六丶mock服务入门到实战 七丶接口自动化...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 185,166
精华内容 74,066
关键字:

下面哪一项测试步骤中需要