随着公司业务的发展，之前测试部使用的siege性能测试工具在进行性能测试中发现瓶颈，虽然我们基于这个工具实现了自动化性能测试，但在较高的并发下时，siege出现异常。在之后的几个项目中，我们使用了JMeter这个开源的性能工具。具体使用方法不做过多的介绍，这里要说的，是性能测试结果数据。
Graph Results
graph results是图形报表，如下
图表底部参数的含义如下：
样本数目（No of Samples） 是总共发送到服务器的请求数。
最新样本（Latest Sample） 是代表时间的数字,是服务器响应最后一个请求的时间。
吞吐量（Throughput） 是服务器每分钟处理的请求数。
平均值（Avergae） 是总运行时间除以发送到服务器的请求数。
中间值（Median） 是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。
偏离（Deviation） 表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。
Aggregate Report
Aggregate Report聚合报告
图表含义说明如下：
Label：说明是请求类型，如Http，FTP等请求。
#Samples：也就是图形报表中的样本数目，总共发送到服务器的样本数目。
Average：也就是图形报表中的平均值，是总运行时间除以发送到服务器的请求数。
Median：也就是图形报表中的中间值，是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。
90%line：是指90%请求的响应时间比所得数值还要小。
Min：是代表时间的数字,是服务器响应的最短时间。
Max: 是代表时间的数字,是服务器响应的最长时间。
Error%:请求的错误百分比。
Throughput:也就是图形报表中的吞吐量，这里是服务器每单位时间处理的请求数，注意查看是秒或是分钟。
KB/sec:是每秒钟请求的字节数。
在测试过程中，平均响应时间是我们性能测试的一个重要衡量指标，但是在测试中，特别是在聚合报告中，得出的90%Line,我这里参考《《LoadRunner 没有告诉你的》之一——描述性统计与性能结果分析》，我认为90%Line等同于该文作者提出的90%响应时间,这个数值对我们性能测试分析也很有参考价值。90%响应时间是说在发送的请求中，90%的用户响应时间都比得到的数值上要短，同时说明，一个系统在应用时，90%的用户响应时间都能达到这个数值，那么就为系统性能分析提供了很好的参考价值。
1、《JMeter在Web Services性能测试中的应用》，作者Dmitri Nevedrov，引自：
2、《《LoadRunner 没有告诉你的》之一——描述性统计与性能结果分析》，作者：陈雷 (Jackei)，引自：。
Advertisements
评分：赞过：赞 正在加载……
这段时间一直在做搜索系统的自动化测试，基于selenium Webdriver，终于有了一点点成果，写成了文档，文档主要内容有WebDriver2介绍，WebDriver类型，WebDriver工作原理，WebDriver使用，maven搭建自动化工程方法，二次封装原理以及自动化脚本编写相关规范。详情如下：
搜索系统WebDriver自动化测试… 1
1概述… 3
2 WebDriver介绍… 3
2.1 Selenium2与WebDriver 3
2.2 WebDriver 5
2.2.1 WebDriver种类… 5
2.2.2 WebDriver分析… 5
2.2.3 WebDriver原理… 9
2.2.4 WebDriver总结… 10
2.3 WebDriver依赖… 11
2.4 WebDriver使用… 12
2.2.3 使用maven搭建工程… 12
2.4.2 编写WebDriver测试类… 16
3 搜索功能自动化… 17
3.1 工程目录… 17
3.2 实现原理… 18
3.3 脚本规则… 19
3.4 脚本编写与执行… 19
3.4.1 测试用例选择… 19
3.4.2 准备测试数据… 20
3.4.3 编写测试脚本… 20
3.4.4 本机调试运行… 21
3.4.5 上传版本管理… 21
3.4.6 纳入持续集成… 21
3.4.7 每日持续回归… 21
3.5 目前状况… 22
4结论… 23
4.1 WebDriver在搜索系统的可行性… 23
5相关资料… 23
Selenium是一种适合web自动化测试的工具，在selenium2.0版本之后，selenium推出了一个新的测试工具—WebDriver，用来代替即将废弃的selenium Remote Control，selenium webdriver更适合构建强健，基于浏览器上的回归测试，并可在跨平台间运行测试脚本。自搜索进行search2.5项目起，页面dome结构将不会有大的改动，搜索前端将更适合进行功能的自动化测试，考虑到公司主流开发语言为java，为了方便之后扩展和维护此自动化测试框架，搜索系统自动化测试框架也采用基于java开发的selenium框架，本文档是基于此特性进行的编写。
2 WebDriver介绍
2.1 Selenium2与WebDriver
Selenium2.0最大的不同就是包含WebDriver API，测试者可以根据不同的平台，不同浏览器选择不同的WebDriver进行测试。WebDriver它可以驱动本地或远程机器上的浏览器。测试者可以使用或都不使用selenium server，取决于你如何来使用selenium。如果严格按照webdriver api来使用，是不需要selenium server的，因为webdriver使用了与selenium RC完全不同的技术来实现与浏览器的交互，Selenium webdriver直接调用本地的浏览器来支持自动化；而selenium RC则是通过selenium server把javascript脚本注射到浏览器中，然后通过特定的测试脚本命令调用javascript命令，从而实现与浏览器的交互操作。总之，如果你使用selenium webdriver，就不需要再使用selenium server了。
WebDriver也可看成是基于Selenium的一个自动化测试类库，是selenium2.0之后的三个工具之一。WebDriver实现了多种方法（ById，ByName，ByLinkText，ByClassName，ByXPath等）并通过发送命令的方式来操作页面的某元素，模拟测试者在浏览器上与web应用进行交互。
在Selenium2之后的版本，selenium主要包括以下4个部份：
Selenium IDE：FireFox 的一个插件，支持脚本录制与回放，用selenium远程控制运行测试，只支持Firefox。
Selenium RC：Selenium Remote Control，梱绑selenium Core，支持多语言编程测试用例。
Selenium WebDriver：selenium2中的新工具，提供强大的API接口，实现驱动本地或远程计算机上的浏览器。
Selenium Grid：允许同时并行地、在不同的环境上运行多个测试任务，极大地加快Web 应用的功能测试。
2.2 WebDriver
2.2.1 WebDriver种类
目前WebDriver针对不同平台，不同浏览器，总共有7个实现，包括官网与第三方实现：
Name of driver
Pro language
HtmlUnit Driver
Java，C#，Python，Ruby
Firefox Driver
Java，C#，Python，Ruby
Internet Explorer Driver
Java，C#，Python，Ruby
Chrome Driver
Java，C#，Python，Ruby
Opera Driver
Java，C#，Python，Ruby
iPhone Driver
Java，C#，Python，Ruby
Android Driver
Java，C#，Python，Ruby
2.2.2 WebDriver分析
1. HtmlUnit Driver
htmlUnit Driver是目前运行速度最快且最轻量级的WebDriver，根据它的名称可以知道，htmlUnit Driver是基于htmlUnit实现的。
1） 最快的webdriver实现。
2） 纯java实现并且是一个独立的平台。
3） 支持javascript。
1）模拟其它浏览器的javascript行为。
常用的类和方法：
Class name
org.openqa.selenium.htmlunit.HtmlUnitDriver
HtmlUnitDriver()
findElement(By by)
findElementById(String id)
findElementByName(String name)
findElementByXPath(String selector)
HtmlUnitDriver driver = new HtmlUnitDriver();
driver.setJavascriptEnabled(true);
2. Firefox Driver
通过new一个FirefoxDriver实例来启动firefox浏览器，FirefoxDriver2.5支持firefox 7。
1） 在真实的浏览器中运行。
2） 运行速度比Internet Explorer Driver快
4） 支持javascript。
1）比Htmlunit Driver慢。
常用的类和方法：
Class name
org.openqa.selenium.firefox.FirefoxDriver
FirefoxDriver()
FirefoxDriver(FirefoxProfile profile)
org.openqa.selenium.firefox. FirefoxProfile
FirefoxProfile()
installExtensions(File parentDir) //向tmp中加载文件
org.openqa.selenium.firefox .FirefoxBinary
startFirefoxProcess(ProcessBuilder builder) //调用java中start()方法以-silent方式启动浏览器
System.setProperty("webdriver.firefox.bin","D:/program/Firefox/firefox.exe");
WebDriver driver = new FirefoxDriver();
工作流程：
FirefoxDriver按照RPC机制实现，主要写成一个Firefox插件形式，采用socket实现通信连接，并以JSon的格式发送命令，插件通过利用Firefox本身提供的XPCOM基元实现与浏览器的操作。操作命令可以在javascript中具体看到，前缀以”FirefoxDriver.prototype”开头。主要流程分为三个大的步骤：启动Firefox浏览器，发送命令，执行并返回结果。
启动Firefox流程：
1， 获取Firefox的端口号，默认是7055，如果7055端口被占用，则采取依次递减的方法，保证端口号唯一。
2， 确保第二个driver的端口号，如果第一个是7055，则第二个是7056。
3， 定位Firefox所用的配置文件，通常是anonymous。
4， 复制步骤3中的配置文件到当前用户的tmp目录下，包括为FirefoxDriver实现的Firefox插件，忽略已经运行过的配置文件。
5， 删除已经存在的缓存文件，确保浏览器在运行时都是取最新的插件。
6， 更新user.js中的参数，使WebDriver按照预期正常工作，把步骤2中的端口号赋值给webdriver_firefox_port参数。
7， 以“-silent”方式启动Firefox，让Firefox使用最新加载的配置文件运行，因为Firefox启动时，需要查找和修改这些配置文件。
8， Firefox实例完成后，结束以“-silent”方式启动的Firefox进程。
9， 再次启动Firefox，测试类开始不停连接Firefox，直到超时为止。
释放端口号
发送命令，执行并返回结果：
FirefoxDriver本质可以看成是RemoteWebDriver运行在客户端的一个实例。在以java为实现语言中，从客户端发送命令到Firefox的基本原理为：
1） 创建一个新的map或dictionary，把命令put到这个map中，格式为：
Context：在客户端中写成一个String类型，不透明的key。
CommandName：浏览器执行的命令，String类型。
Parameters：参数，类型取决于commandName类型，可以为空。
elementId：一个不透明的元素标识，String类型。
2） 使用Json实例步骤1中的map。
3） 通过socket协议连接FirefoxDriver插件。
4） 通过wire的形式把Json发送到Firefox浏览器
5） 通过另一个map，以Json的格式返回响应
methodName：响应方法的名称，String类型。
context：响应内容。
isError：声明异常
responseText：异常内容，如果有异常则会有这个字段。
当命令到达Firefox插件中后，JSON格式的命令则会被反序列化成一个javascript对象。第一件事就是解释命令的名称，但有些命令是不会被注意到，可以看成是windows或frame使用的。为了能执行这些命令，通常这些命令都命名为：FirefoxDriver.prototype.xxx，如get命令：
FirefoxDriver.prototype.get = function(respond, url)
3. Android Driver
AndroidWebDriver通过在手机或模拟器上安装android-server.apk，android-server是一个解释执行服务器，用jetty实现。
１）首先安装并启动android-server
２）测试程序通过采用socket进行通信，建立连接。
３）以JSON格式发送命令到android－server中
４）android-server获取到命令后解释并执行。
５）返回结果
在AndroidWebDriver中，页面直接运行在WebDriver中，采用官网上提供的WebDriver不支持本地浏览器，所以不能调UC浏览器进行测试，而且必须在手机或模拟器上启动jetty服务器才能运行测试类。连接不稳定，有时JSON发送不出去，容易使测试程序运行失败。
2.2.3 WebDriver原理
WebDriver主要有两种工作模式：
一种是客户端模式，如FirefoxDriver，OperaDriver和RemoteWebDriver；
具体流程如下：
1，建立socket协议实现对浏览器端口进行监听；
2，把需要用到的配置文件加载到本地（如FirefoxDriver加载到本地用户临时文件夹中）；
3，通过调用实现语言中的方法启动浏览器（如java中调用java.lang. ProcessBuilder.start()方法）
浏览器启动后，再把测试程序中对浏览器页面模拟的操作以JSON的格式，通过HTTP协议发送到浏览器端。根据不同浏览器的特性解析这些命令（如FirefoxDriver采用插件的方式），并执行相关操作。
结束后关闭driver。
一种是服务端模式，这种需要启动服务器，WebDriver在浏览器中运行，如ChromeDriver。
2.2.4 WebDriver总结
1） 用户可以针对不同的浏览器，不同的平台，选择或是自行开发WebDriver
2） Selenium 2提供了全面的接口和实现
3） 源代码开源
1） 主要来自浏览器，因为浏览器众多，需要根据浏览器自身的特性选择或定制WebDriver
2） 一个WebDriver只能实现对一种浏览器进行操作，如果要进行多浏览器的测试，需要在编写测试程序时进行封装。
2.3 WebDriver依赖
WebDriver目的用于代替selenium RC，在WebDriver实现中，除了webdriver外，webdriver还与selenium-server，selenium-java，selenium-remote-driver，selenium-support和selenium-api下图：
Selenium-api：selenium2类库中最高层的类库，主要功能是向下提供丰富的接口类。常用的类有：WebDriver，WebElement，By等等。Selenium-api依赖于google的guava库。
Selenium-remote-driver：上向实现selenium-api中接口的功能，并依赖json，httpclient，selenium-api，为下层的WebDriver提供方法调用支持。常用的类有：RemoteWebDriver，RemoteWebElement等。
Selenium-Firefox-Driver：用于实例一个不同浏览器的对象，依赖于selenium-api和selenium-remot-driver，调用selenium-remote-driver中实现的selenium-api的get()方法打开本地浏览器。常用类：FirefoxDriver，是RemoteWebDriver的子类。
Selenium-support：为下层依赖库（selenium-java，selenium-server）提供支持。常用类：WebDriverBackedSeleinum
Selenium-java：负责WebDriver与Selenium-server之间的连接，与selenium 1.0版本中的selenium-java-client的作用相同，为selenium server是一个java客户端。
Selenium-server：为兼容selenium1工作模式和从selenium1迁移到selenium2提供的依赖。
2.4 WebDriver使用
2.2.3 使用maven搭建工程
1，搭建maven环境（前提已经成功安装java环境）
1） 下载maven：
2） 解压到本地磁盘，如：D:\ProgramIDE\maven
3） 设置系统环境变量（M2_HOME和PATH）：
M2_HOME：D:\ProgramIDE\maven
PATH：%M2_HOME%\bin
4） 验证安装
开始-&运行-&CMD，在DOC中输入 mvn –v，如下图，则成功安装maven：
5） 配置setting.xml文件，修改&localRepository&设置
2，搭建eclipse-maven环境
1） 安装eclipse-maven插件
打开eclipse-&Help-&install new software-&add
2） 按提示重启，配置eclipse指向本地maven配置文件
3，用maven创建一个WebDriver工程
用maven命令创建一个名为searchui的工程
mvn archetype:create -DgroupId=com.xiu.searchui -DartifactId=searchUI -DpackageName= com.xiu.searchui
编辑生成的pom.xml文件，添加FirefoxDriver包
&dependency&
&groupId&org.seleniumhq.selenium&/groupId&
&artifactId&selenium–firefox-driver&/artifactId&
&version&2.24.1&/version&
&/dependency&
3） 编译并生成eclipse工程
mvn eclipse:eclipse
4） 把工程引入eclipse中
Src/test/java 目录为放置基础类和测试类
Src/test/resources 目录为放置测试数据，即测试用例。
2.4.2 编写WebDriver测试类
WebDriver工程可以很好地与JUnit，TestNG结合使用，并通过Hudson实现持续集成，如下是一个最原始的使用JUnit与Firefox WebDriver编写测试搜索列表页面商品价格与详情页面价格是否一致的自动化测试例子：
package com.xiu.searchui.
import junit.framework.A
import org.junit.AfterC
import org.junit.BeforeC
import org.junit.T
import org.openqa.selenium.By;
import org.openqa.selenium.WebD
import org.openqa.selenium.WebE
import org.openqa.selenium.firefox.FirefoxD
import com.xiu.search.util.ReadDataDaoI
public class SearchPagePrice {
static WebDriver driver;
ReadDataDaoImpl readData = new ReadDataDaoImpl();
@BeforeClass
public static void setUpDriver() {
System.setProperty(“webdriver.firefox.bin”,”D:/program/Firefox/firefox.exe”);
driver = new FirefoxDriver();
@AfterClass
public static void closeDriver() {
driver.quit();
public void 验证商品列表页面价格() {
driver.get(“;);
WebElement pricelistElement = driver.findElement(By.xpath(“//*[@id=&#15′]”));
String listPrice = pricelistElement.getText();
System.out.println(listPrice);
driver.get(“;);
WebElement listtodailElement = driver.findElement(By.xpath(“//*[@id=’prd_price_div’]/p[1]/span[1]”));
String dailtolist = listtodailElement.getText();
System.out.println(dailtolist);
Assert.assertEquals(“列表页展示价格”,listPrice,dailtolist);
3 搜索功能自动化
3.1 工程目录
搜索功能自动化工程将使用maven搭建，分基础工具类，测试基础类，测试脚本，数据对象资源文件，其它测试脚本分：search页测试脚本，list页测试脚本，brand页测试脚本。详情如下：
com.xiu.searchui.util：主要放置数据收集，测试结果转化成报告，并以邮件形式发出等相关功能扩展处理类。
com.xiu.searchui.base：主要放置webDriver api二次封装，基础类库等。
com.xiu.searchui.brand/list/search：主要放置测试脚本。
src/test/resoures：主要为测试用例，对象库等测试数据。
3.2 实现原理
搜索功能自动化测试基于selenium webdriver框架进行使用或二次封装，并结合JUnit进行执行测试脚本，目前测试结果的输出主要依靠JUnit。整个工程与webdriver相同，参见2.2.3
后继将结合hudson或其它持续集成框架，将此工程打包成可执行jar-version(版本号)包，放于持续集成框架中自动运行。
3.3 脚本规则
1）脚本类名，方法名，变量名，对象库命令易看易懂，其中方法名称使用中文，方便维护，其它使用英文命名。
2）统一独立的测试数据帐号。
3）工程版本命名规则化，如搜索系统命令为：auto-search-2.5.1.jar或其它。
4）公共类库，即可抽取并在多处重复使用的类，如登录操作。
3.4 脚本编写与执行
3.4.1 测试用例选择
在testlink中选择可以进行自动化测试的测试用例，方法如下：
1） 用例输入输出值可直接到页面获取，便于校验
2） 用例具有唯一原子功能性，不涉及多系统关联操作
3） 用例不涉及UI校验
4） 用例不涉及非本系统数据库或缓存系统数据读取（暂时）
3.4.2 准备测试数据
1）页面对象库数据
2）url链接
3）测试帐号（专门独立自动化测试帐号）
4）测试数据（商品，价格等）
目前测试数据格式如下：
3.4.3 编写测试脚本
脚本编写使用webdriver和junit结合，通过调用junit的运行机制，使用webdriver提供的api进行。
Webdriver提供多种获取页面元素的方法，也支持在此基础上扩展，原方法如下：
static class By.ByClassName(java.lang.String className)
static class By.ByCssSelector(java.lang.String selector)
static class By.ById(java.lang.String id)
static class By.ByLinkText(java.lang.String linkText)
static class By.ByName(java.lang.String name)
static class By.ByPartialLinkText(java.lang.String partialLinkText)
static class By.ByTagName(java.lang.String tagName)
static class By.ByXPath(java.lang.String xpathExpression)
应用实例：
public void 验证相关搜索功能() {
driver.get(“;);
WebElement pricelistElement = driver.findElement(By.xpath(“//*[@id=’index’]/div[2]/div[2]/div[2]/div[2]/label”));
String relatedName
= pricelistElement.getText();
Assert.assertEquals(“验证相关搜索功能”,relatedName,”相关搜索：”);
更多请查看官方API：
3.4.4 本机调试运行
测试人员在本机编写测试脚本后，并在本机调试通过。通过多client机方式并行编写测试脚本，节省成本。
3.4.5 上传版本管理
调试成功后，上传到SVN服务器，纳入版本管理，并安时间或程度转测版本进行打包。
3.4.6 纳入持续集成
将最新的打包版本纳入持续集成平台，设置适合时间自动运行。
3.4.7 每日持续回归
纳入持续平台后，每日持续回归脚本，验证系统功能的正确性。
3.5 目前状况
目前搜索自动化已经可以覆盖search，list，brand大部分主流程的自动化测试，如：
search，list，brand三页面共有的功能：搜索，相关搜索，搜索纠错，顶部翻页，底部翻页，筛选排序等功能；
商品展示页面：价格，立即购买，到货通知；
list页：品牌筛选，价格筛选功能；
brand页：品牌功能。
4.1 WebDriver在搜索系统的可行性
1，按照WebDriver的目标，可以根据不同浏览器特性使用不同的WebDriver，不论是PC平台还是手持设备，如android，OS。并可真实模拟用户进行浏览器操作，而非采用js注入形式。同时可以做到浏览器兼容性的测试。
2，按照目前测试业界经验与相关实践，特别是淘宝，UC等一些企业，采用数据驱动进行自动化框架的设计，对象库，数据库，脚本三者分离，将能大大提高功能自动化测试的效率，并能在测试流程中起到更好的效果。
3，搜索系统无需进行登录，省去了登录校验机制，也为搜索系统的功能自动化提供了很好的基础。
官方文档：
Google code wiki：
Wiki阅读顺序：
#第一步GettingStarted
#第二步NextSteps
#第四步（各种WebDriver资料）
欢迎继续完善此文档.doc
评分：赞过：赞 正在加载……
技术，产品，用户体验，细细想，这里面会有很多有意思的东西，不要单纯只做某一个，特别是测试工程师。沟通能力，技术能力，产品意识，注重用户体验，测试工程师不仅仅只是保证产品的质量，可以为团队，产品做更多事情。
评分：赞过：赞 正在加载……
软件测试是一项活动，但如果我们仅仅把测试当成一项为把关软件质量的活动来执行，或许你会发现这项活动会有些繁琐，有些枯燥，没有成就感……
软件测试又是一种艺术，但如果每个测试工程师都把自己视为艺术家，追求尽善尽美，开发同学可能就要疯了……
当然，这里并不是讨论软件测试是什么这个命题，而是作为一个测试人员，怎样去发现测试中的美，从而快乐地工作。
或许我们可以在测试活动中添加一点点艺术的元素，让测试“美”起来，使你不再有繁琐感，不再感觉枯燥，不再没有成就感，让你真正爱上测试。
下面从功能，性能，测试数据以及覆盖率分别扯下测试中的美，纯属个人拙见，不一定有用，不足之处，望请各位大侠前辈师兄多多指导。
功能测试美在哪里？
美在知识面的广
或许对于那些向往开发工作的测试员来说，也许“功能方向的测试技术含量是不高的”，或许有人会认为功能方向的测试只要了解需求，熟悉业务，点点鼠标就能完成，曾经我也是这么认为，看来是自己对功能测试认识太浅以及过于浮燥。
如果要想真正的做好每一个项目的功能测试，要知道的知识还是很多的，比如操作系统(Linux)，数据库(Oracle，MySQL，Sybase ASA)，网络以及一些常用的软件与测试工具及bug管理工具(twork，automan，QC，PLSQL)；
如今的大多数应用，不管是CS还是BS，都与数据库有亲密的接触，所以我们还要了解整个系统的数据结构，每个功能对应哪张表，进行哪些数据操作，前台展示是否一致，这些都需要功能测试人员自己去验证；
当然，我们还需要对代码结构有一定的了解，测试并非一次就可以通过的，在开发同学fix一个new状态的bug后，不管是close或 reopen，测试人员不防看看代码，懂一些代码知识也能更好地分析和定位bug，特别涉及到js等前端代码时，因为很多界面和功能兼容性问题都是由js 等前端代码造成的；
除此之外，我们还需要知道测试策略，测试方法以及设计测试用例的方法，如等价类，边界值，场景法，因果图，判定表，错误猜测法等。
如果你对这些还是不符合你对美的标准，请继续往下看。
美在测试思维的奇异
有人说当对测试技术与业务的掌握达到一定的程度上时，测试思维在此时就显得尤为重要。
在测试一个日常或项目前，通过对需求，UC及对系统的了解，能不能探索出一个最佳的测试方案和测试计划。特别是日常，因为日常较小，在了解或评审UC后，大概的测试方案或许应该浮现于你的脑海中。
测试用例是测试计划的进一步细化，在做TC设计时，能不能对那些测试用例设计方法信手拈来，使TC能覆盖一些特别的路径，从而发现那些更加隐秘的bug，这也是测试思维神奇的地方。
很多时候，喜欢thinking in testing这三个单词，当测试对象已经经过常规的测试轰炸后，如果我们能换个思维方式，从不同角度模拟更多的用户场景，或许能在“山穷水尽疑无路”时出现“柳岸花明又一村”的景象。
这就是测试思维奇异的地方，或许作为新人，我们还无法达到这种境界，但这并不防碍我们去思考。
美在功能的完整
在功能的世界里，只有完整，因为不完整就意味着是缺陷，那是bug！
而在淘宝，功能的完整有两种，一是指测试对象的功能要完整，二是指测试对象的界面要完整。
测试对象界面完整具体指界面美观，某一功能的界面色调与整体页面的色调要和谐，易用性强。试想，一个界面操作级难的功能，又有多少人会去使用，客户第一，我们拿实际行动证明。
喜欢下厨房的人或许有这样的体会：做一道好菜，看之有色，闻之有欲，食之有味。功能测试中的测试对象也如此，只有做好了，用户才会发出“哇”的惊叹，不然只有一声“哦”的敷衍，质的不同，这就是功能完整美魅力！
看着一个个功能在经过你的测试把关下发布上线，供千千万万的用户使用，你还会因为做功能测试而感到无成就感吗？相信你不会。
功能测试活动就好比做菜，怎样才能做出一道色香味具全的菜，不光要知道做菜的流程，技巧，最最重要的是你要热爱下厨，也就是要投入极大的热情。而下 面要说的性能测试活动又似什么？美在哪里？每当拿起画笔作速描绘画时，都不由得让我想到性能中曲线的美，以及从这些曲线中折射的魅力。学习和关注性能测试 时间最长，但接触性能测试工作并不多，小子斗胆在各位大侠前辈师兄面前班门弄斧，不正确之处还请提示，谢谢。
性能曲线美
在LR，JMeter或其它测试工具中得出的各种不同性能指标的图中，我们可以得出不同测试场景下的不同数据，从这些数据中可以判定系统是否达到预期标准，如果没有达到，系统瓶颈出现在什么地方，进而分析出优化的方案，这就是这些曲线的美之所在！
上图中的曲线（自下而上）是用LR模拟100个并发用户分别进行登录，发博文，退出一个博客系统的响应时间曲线图。
根据这些曲线，可以得出下面的分析：
1， 发布博文操作对应的曲线为最下面曲线，曲线平滑，变化不同，没有出现让人纠心的性能拐点，说明在100个并发用户同时发布时，响应时间在理想范围内，系统是能够经受考验，如果预期指标定义在这个范围，则系统可以接受。
2， 登录博客后台操作对应的曲线为中间两条曲线，相对于最下面那条曲线，这两条曲线出现了较大的波动，在性能平坦区之后有明显的性能拐点，响应时间加长
3， 退出博客系统操作对应的曲线为最上面一条，在右上角有明显的拐点，对照于中间两条以及预期的性能指标，出现了性能轻微下降区和性能急剧下降区，如果超出预期范围，根据这些数据，就要做些什么了。
注：性能平坦区，性能轻微下降区和性能急剧下降区是性能下降曲线分析中常遇到的，大家可以找下资料，这里不作过多解释。
根据这些曲线试想一下，如果在500个并发时要实现100个并发时的响应时间，我们可以怎么做？
一，服务器方向：
1， 采用集群策略，增加tomcat服务器数量，实现负载均衡。
2， 静态页面和动态页面分离处理，静态页面交给web server（如apache），动态页面交给application server（如tomcat，jboss）
3， 1，2两种方案一起使用。
4， 采用更强大的application server，升级tomcat服务器为jboss，weblogic或websphere；
二，硬件方向：
1， 增加内存
3， 增大硬盘容量
三，操作系统方向
1，采用Linux
四，数据库方向
1， 采用性能更大的database
2， 优化数据结构
3， 采用更有效率的数据库连接方式（数据连接池）
五，代码方向
这些都是通过分析这些曲线得到的数据后根据实际情况综合采取的解决方案。
上面仅仅只是响应时间一个性能指标的曲线图，而且登录操作也仅仅涉及到对数据库的读操作，如果是发布blog，此时涉及对数据库的插入操作，响应时 间又是另一个景象。并发用户数的不同，相应的资源利用率，吞吐量等曲线图都会发生变化，而我们正是根据这些曲线的变化进而分析性能的瓶颈的依据所在。
速描绘画中，几个笔画就可以让人产生无限的遐想，让人惊叹艺术给人带来的震撼美。在性能中的那些曲线何尝不是如此，透过这些曲线，可以让系统的深层次缺陷暴露无疑，这就是它的美，你动心了吗？
这里有一篇是关于LR的一些入门级的介绍（），新人还可以看看，高手漂过。还有一些资料在我的PC共享文件夹中，大家可连接下载，谢谢！更多的资料可惜在几次仓促的换系统中没来得急备份而丢失，抱歉！
数据精准美
测试活动过程中离不开测试数据的输入，测试活动与测试数据是鱼和水的关系，不论咸淡，只要水质是好的，鱼，就能活。
测试数据有狭义和广义之分。狭义上的测试数据是指一个数字，一个字符，一张图片，一个测试账号，一个测试用例等。广义上的测试数据则包括了狭义是所 指的那些，甚至我们可以把所有对测试对象的输入，不管是虚拟的还是物理的，都可以当成是测试数据来看待。比如我们用力来压健身用的臂力器，以压臂力器的功 能，这时力也可以看作是测试数据。
测试数据有正确与精准之别。测试数据首先要确保正确，这样测试活动才是有效的，但还不是最美的；最美的测试数据要精要准，这样的测试数据才能发现更多更有意思更有意义的bug，这种测试数据才是最美的！
精准的测试数据能让你避免一些徒劳的测试操作，节省测试时间也能节省测试成本；
精准的测试数据能让你发现一些边界中的缺陷，让系统在边界操作中更加放心；
精准的测试数据能让你发现一些容易忽视的路径，让测试覆盖率达到更高，特别是在单元测试方面，面对那些if…else…
但我们应该如何去准备好这样的测试数据？在这段时间的测试工作中，自己是从以下几点着手的，不一定是最好最适合，仅供参考，欢迎更多建议，一起完善。
1， 在UC阶段明确测试对像是什么，怎么样，尽早做好测试数据的准备。千万不能在执行时才开始准备测试数据，这样可能会搞得手忙脚乱，因为很有可能你在急于准备测试数据时，环境挂了，相信大家已经领教过。
2， 进一步了解测试对像的细节，如规则要求等。如输入图片的规格，输入字符的要求，测试账号要求是什么类型（如一测试账号所涉及到应该用哪种旺铺版本）
3， 了解数据输入输出的方式，数据从哪里输入，输入到什么地方，是数据库系统还是其它系统（在TB，除了database还有什么呢？不说，你也懂）；输出又是在什么地方显现，以什么方式显现
4， 如果对应的开发同学很高手，代码完成很有速度很给力，可以看看代码，这样可以通过代码了解具体的实现规则，对准备测试数据帮助更大。可以在eclipse或直接在svn中的log中查看对应代码。
5， 在准备这些测试数据时可能会有点点烦琐，如图片那些规格（在准备这方面的数据时可以用一些截图软件辅助），但相信大家都是好样的，完成后也会有惊喜出现的。
测试数据就像你为女朋友准备的生日礼物，不要求最贵，但要最好最美最精致，她最喜欢的，当然，如果你有大把大把的RMB，也可以选最贵的。Ok，开个玩笑，只是一个比喻！
在准备这些测试数据和执行测试输入时，可能会让你联想到更多的测试场景，特别是在我们淘宝，应用与应用之间的调用，系统与系统之间的影响，测试场景 非常多，使我们在测试任何一个功能时都不得不考虑清楚，尽量模拟卖家买家的使用习惯。从一个功能点到一个模块，从一个模块到整个系统，一步一步提高测试覆 盖率，从小到大，步步为营，测试思维和思路逐渐激发和发散开来。
当你认真准备好这份“生日礼物”后，肯定会得到意想不到了惊喜，享受这快乐吧！认真生活，快乐工作！
覆盖率动静美
覆盖率是用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。测试覆盖率可以表示出测 试的充分性，在测试分析报告中可以作为量化指标的依据(例如我们在twork中生成的项目测试日报)。虽然说测试覆盖率越高效果越好，但覆盖率不是目标， 仅仅只是一种手段。
测试覆盖率包括功能点覆盖率和结构覆盖率。功能点覆盖率用于表示软件系统已经实现的功能与软件需要实现的功能之间的比例关系；而结构覆盖率主要适用于白盒测试中，如语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等。
在测试活动中，覆盖率无处不在，从TC的编写，到测试的执行，不管是黑盒的路径，还是白盒代码中的REVIEW，在测试分析报告中，测试覆盖率是最最有力的数据。总结这些覆盖率的类型，无非两种，一种是静态的覆盖率，一种是动态的覆盖率，这就是覆盖率的动静之美。
静态的覆盖率包括testcase覆盖率，静态代码REVIEW覆盖率，功能自动化脚本覆盖率以及测试分析报告中以数据形式表示的覆盖率等等。在静态覆盖率中，最重要的是TC覆盖率，其次是静态代码REVIEW覆盖率。
TC是测试执行之始，也可以把TC当成测试执行活动的数据，TC的覆盖率直接影响测试活动的质量。可以不先考虑TC的粗细程度，但不得不考虑TC覆 盖的范围与正确程度。覆盖率强的TC可以发现更多不易发现的路径，测试更多应用场景，从而揭露出更多隐藏的bug，尤其是在测试淘宝的应用时。记得在测试 一个日常时，因为没有考虑到同一个应用下模块间的影响关系，在设计TC时没有覆盖到这条路径，导致上线后这个bug由卖家报给我们，很悲剧。不过从这个 bug中让我们这些新人意识到，我们在设计TC和测试中，要提高测试覆盖，或许这样才可以减少bug的遗漏。这也是TC覆盖率美之处在！
或许在设计TC时，作为新人，不可能达到很高的覆盖程度，但在执行测试活动时，要潜意识中记得，把思维发散开来，用执行测试的覆盖率弥补TC 中的覆盖缺陷，之后再完整我们的TC，让覆盖率更高的TC入库。在这方面，还有一段路要走，共勉！
静态代码REVIEW覆盖率
静态代码REVIEW覆盖率现在在国内用得不多，可能和重视程度有关，相关的资料也只是在某些专业的资料中见见。但少见并不意味它不重要，因为在代 码阶段发现bug的修复成本远远比在页面上发现bug的修复成本低。静态代码REVIEW还有一个优点就是已经实现工具化，现在有不少开源的工具可以做 到，又免费又好用，何乐而不为呢。
静态代码REVIEW主要对代码中的词法，语法，数据类型和单位，引用，表达式，接口进行分析，绘制成各种表进行分析，如变量引用表，函数表，等价表和常数表等，不同工具不同方法分析方式有所不同。
覆盖率还有动态之分，这是一种让人惊叹的覆盖率，出场于代码运行过程中，主要用工具来实现。当执行者运行某一功能时，动态覆盖率工具会以红绿两种颜色分别标识此功能没有运行的代码和此功能涉及到的代码，这里的执行者可以是开发同学，也可以是测试同学。
有些代码覆盖率工具可以当eclipse的插件使用，如eclemma（官方网址为： ；在eclipse中install这个插件的url为： ），它可以做到对类覆盖、函数覆盖、语句块覆盖、分支覆盖，并生成覆盖率数据以界面形式显示出来，如下是一个简单的应用场景：
以eclemma行动代码后可以很清楚地看到执行过的代码和没有执行过的代码，并在控制台上显示工程，包，类方法的覆盖率具体的数据报告。此外还提供最近两个时间段的报告用于比较。
还有一些已成系统的代码覆盖率工具，如开源的clover（ ），EMMA（ ）以及基于此的TCC，这些工具的功能可以在它们的官网详细查阅到。它们都实现了获取动态运行代码的覆盖率，并以一定的形式给出分析报告，以供开发和测试人员参加。
有人说程序之美始于静，用之于动，测试之美则是始于动，归之于静，如果要用工具去表达这种美，那么上面三种或是其它更多的则足已让你惊叹。
That’s all，测试之美系列，从开始学习软件测试到参加工作以来的一部分感悟，望大家多多指点。有一本测试类的书的名称也是叫测试之美，小子无意冒犯，只因这个名称太美，借用下，同时在此向大家宣传下这本书《测试之美》
评分：赞过：赞 正在加载……
工作之前，更多的是在思索如何成为一名优秀的测试工程师。时儿清晰，时儿模糊，并循环在自己身上出现，折磨着，很痛苦。佛说：人来到这个世上就是受折磨的。好吧，神都这样说了，安慰下自己。
工作之后，从平时学习和日常测试的实践中，以及我们产品线情况，在想，我们测试人员应该站在哪些角度上去保证软件质量？现在想到是三个方面。
1，从业务逻辑上着手。
这点很容易明白，业务是系统功能的一种体现形式如果，如果对业务逻辑了解清楚，不管系统有多复杂，也不管系统有多大，对那些熟悉业务的人来说，可以 设计出质量高的测试用例，进行一次成功的测试。很喜欢的一句话，就是专业知识是测试人员的左脚，业务知识是测试人员的右脚，也就是这个道理。在测试道路上 能走多远，就看左右脚有没有力了。
2，从用户体验上思考
在软件工程上，并不认为开发人员去自己测试他们的代码是一种好的方法。人很多时候很固执，总认为自己写的代码没有问题，特别是作技术的人。很多测试 人员，很多时候或许仅仅是从测试角度去测试一个系统，根据特定的流程，特定的方法等等，去完成一个系统的测试工作，如果测试结果通过测试，测试达标就ok 了。但我们很多时候忘记了从用户体验上去思考某个功能的使用，某个页面的样式。。。特别是我们淘宝的应用，系统体验好不好，很大程度是关系到我们的PV和 用户数量，我们是否在测试时，考虑下这方面，虽然这些不是功能或性能上的缺陷。
3，从系统架构上把握
这点是在工作之后给我的灵感。以前只是想到1，2两点，但仅仅是从上面这两点去做，能保证软件的质量么？
这是谁也不敢保证的。如果要解剖一头牛，你得要非常了解牛的架构是怎样的。同样，如果我们要保证软件系统的质量，我们也要非常了解软件系统的架构， 这样，我们才胸有成竹，有的放矢。可以从一个更高的视角，保证软件的质量。有一句诗词叫作：会当凌绝顶，一览众山小。当站在一个更高的角度看事物时，我们 的视角才宽广，才更全面。软件测试也是如此，当你对一个软件系统的实现结构了如指掌后，你就可以清楚地知道这个系统哪里是最弱的，哪里是最强的，哪些地方 是最需要关注的，哪些地方需要做性能测试，哪些地方可以使用自动化介入，从而采用最好最适合的测试策略。
ok，就这样先，好好学习，天天向上。。。
献给对软件测试有着很傻不拉机感情的人们!
评分：赞过：赞 正在加载……
万剑归宗乃是剑术最高境界，一经使出万剑归宗如仆见主。
如朝拜到尊神一般，剑招一出，凌厉无匹的剑劲由体而生，身形可化着一股青烟，劲气四散弥漫。
无数利剑狂风暴雨般的飞卷。漫天飞舞，剑势如网，凌厉无匹，蔚为奇观。
这是去年玩诛仙这款网游最喜欢的招式。有意思的是，来到公司后，有幸加入技委下面的一个团队，team的名儿也是万剑归宗，我是其中一剑，好像有点雷同七剑下天山的感觉。相信我们肯定要比天山七剑厉害，虽然我们还没有正式下山。
不过，快了，敬请关注淘宝测试团队博客
评分：赞过：赞 正在加载……
从4月6号入职，到6月12号，一直在参加公司内部培训。来到部门后，leader让我研究下webx，一个MVC框架，以后要负责本team在这块的接口测试工作，所以又拼命地学。很感谢我的leader，因为她懂得尊重我们的兴趣和方向，至少，让我做我喜欢的工作–coding。
当然，作为一名测试人员，业务上的东西也是要掌握的，所以，除了大部份花在webx上的时间外，还会安排一些测试工作，参加一个UC和TC的编写和评审。
在淘宝，很多东西要重新开始学习的，系统很大，平台很多。加油吧。
评分：赞过：赞 正在加载……
worked@TAOBAO
加入另外 1 位粉丝
Blog Stats
出错了。Feed 可能没有正常工作。请稍后重试。
Advertisements
If not now, when? If not me, who?Just another WordPress.com weblog