1

android-sdk-windows\tools>uiautomatorviewer.bat 抓取页面控件元素

2

android-sdk-windows\platform-tools>adb install Aolaigo.apk 安装app软件

3

android-sdk-windows\tools aapt dump badging E:\apk\es3.apk 获取app入口

capabilities.setCapability("appPackage", "com.csc.aolaigo");

capabilities.setCapability("appActivity", ".ui.StartActivity")

4

eclipse Macketplace   安装android

5

appium

6

真机上测试时，android4.2不支持resources id；需要android4.4等以上

7
root安卓手机，adbWireless;adb connect 192.168.XX.XX;即可安装无线运行

一•介绍

自动化的本质----就是用程序来测试程序

随着Web项目的日益庞大，自动化测试技术的重要性日益突出

二•手工 vs 自动化

手工：不可替代、发现更多bug、人的想象力与理解力

自动化：可重复、效率高，增加软件信任度

三•自动化测试       

1自动化测试分类：

对web UI的自动化测试程序

对windows窗体c/s UI的自动化测试程序

API测试 比如 测试WCF service，Web API等

数据库测试，比如测试存储过程

接口测试，

单元测试

性能测试，性能测试都需要自动化

2自动化测试驱动

测试驱动是一个自动化测试框架的核心，其决定整个自动化脚本设计。当前比较流行的测试驱动有数据驱动和关键字驱动，使用不同的测试驱动，关系到脚本重用率，以及后期的可维护性。

（1）数据驱动

基于数据驱动的自动化测试框架是指测试驱动引擎从数据源获取测试数据，然后将将数据以参数的形式传递给测试脚本，最后通过执行测试脚本，验证测试结果，并将测试结果输出。

一般数据源与测试结果存储在数据库、Excel文件、Csv文件等。数据驱动主要优点是：

测试脚本与测试数据的分离，当应用功能变更时，只需要修改该功能部分的脚本；执行测试用例的人员不需要了解测试脚本的实现，只关注测试数据表与测试报告表。而且测试脚本的执行是离散的，即非线性的，测试人员可以有选择的执行测试用例。

（2）关键字驱动

关键字驱动的自动化测试框架是在数据驱动的基础上进行改进，数据源里包含的不只是数据，还有关键字，一个测试用例由一个或若干个关键字组成。每个关键字对应个不同的业务逻辑，例如，登录、注销等。数据表通过关键字，查找映射表，执行相关的脚本。

（3）驱动引擎

驱动引擎是对数据表的数据进行分析，根据不同的测试数据或关键字调用相应测试脚本。驱动引擎还需完成一些测试环境初始化、全局参数设置、测试用例是否执行的判断，以及测试报告的处理等。

3自动化测试用例设计 

分三步走：初始化，输入准备；

执行（方法调用），结果验证（断言）；

清理环境

4自动化测试脚本开发

测试脚本开发必须通过详细、合理的设计，要对脚本代码进行划分，脚本文件或数据文件分层管理。这样有利于自动化脚本的开发与维护，从而节省自动化测试的投入成本，也使得不同测试人员或开发人员可以协调开发脚本。

（1）脚本规范

测试脚本的开发也要遵循编程的规则与标准，应该统一规划，所有开发脚本的人员按照

统一的规定进行编码。除了编程本身规范，还考虑测试用例与库函数名的命名，测试用例需要加上项目名称，但公共的库函数却不需要，因为公共的库函数是独立于项目的。例如，项目M4.1客户端登录测试用例可命名为：TC_M4.1_client_login；读取excel表的函数可命名为：read_excel。

（2）脚本划分

测试脚本的划分，如何定义公共的脚本库，不同模块特有的脚本库，以及直接构建测试用例的脚本。为了方便以后脚本的维护问题，必须对脚本进行有效的分层，同时，提高了脚本的复用率。

①公共类库

公共类库包括所有模块都可能用户的操作方法，其抽象了不同模块同性，比如操作excel表的方法、读写测试报告、驱动引擎等。

②模块特定类库

在模块内部将可以为该模块共享使用的方法抽象出来，作为一个公共类。它可以是一个单的逻辑操作，也比较独立。比如客户端登录操作、控制台登录操作、控制台更新操作等。

③测试用例脚本

测试用例脚在最上层，它根据测试点进行设计，面向具体的应用。它可直接调用公共类库或模块特定类库的方法，即调单个逻辑操作。它是单个或多个逻辑操作的集合，即一个测试用户脚本。比如，在客户端访问资源的测试用例，它调用了客户端登录方法和访问资源方法。

（3）测试用例

①测试用例粒度

测试用例的粒度决定了用例模型级的复杂度，也决定了每一个用例内部的复杂度。

应该根据每个系统的具体情况来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。用例不能太大，这样一旦出执行测试用例出错，不利于定位问题；但也不能太细化，太小则不方便执行。

②测试用例与测试套件

一个大型的项目有许功能模块，必然会产生大量的测试用例，怎样才能有效的管理这些测试用例呢？这就需要创建测试套件，通过测试套件将测试某一个模块或功能点的测试用例集合起来，方便运行与管理。例如，只验证“用户管理”模块功能，则只需要执行“用户管理”模块套件即可。

（4）脚本与html标记分离脚本与html标记分离使得在一定程度上脚本独立于WEB页面，脚本没有直接的处理html标记，脚本代码通过html映射表获取赋有WEB页面标记值的变量。WEB页面标记包括html标记和页面内容（文本或图片等，这些都可能是判断用例是否成功能的检查点），当WEB页面标记变更后，不需要在范围的修改脚本。

（5）选择适合自动化测试的用例

在编写自动化测试脚本前，首先要确定哪些用例适合做自动化测试，因为自化测试不像手工测试，它不能那么智能，也没有发发散思维。通常适合自动化测试的用例有：

产品型项目。产品型的项目，新版本是在旧版本的基础上进行改进，功能变不大的项目，但项目的新老功能都必须重复的测试。

回归测试。回归测试是自动化测试的强项，它能够很好的验证你是否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。

机械并频繁的测试。每次需要输入相同、大量的一些数据，并且在一个项目中运行的周期比较长。

有一些交互性比较强，需要人工干预的操作，就不要指望通过自动化测试来完成了。

例如，用户使用DKEY登录。

四•测试自动化   偏向于开发岗位

自动化系统平台开发，自动化框架工具开发；提供给自动化测试或业务人员等执行自动化测试，结果收集，结果判断，结果通告

自动化框架    分上下两个层次

上层是管理整个自动化测试的开发，执行以及维护，在比较庞大的项目中，它体现重要的作用，它可以管理整个自动测试，包括自动化测试用例执行的次序、测试脚本的维护、以及集中管理测试用例、测试报告和测试任务等。

下层主要是测试脚本的开发，充分的使用相关的测试工具，构建测试驱动，并完成测试业务逻辑

五•开源自动化框架

PC端Web：Jenkins+ant+selenium+testing+tomcat

自动构建+脚本开发+测试结果

移动app：Jenkins+Appium+ant+selenium+testng+tomcat

自动构建+脚本开发+测试结果

做什么不深入，就看表面，浅尝辄止

JMeter的简介

可以肯定的是，JMeter至少符合以下几条自动测试标准：

• 零购置成本－－直接从http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi下载得到。
• 学习曲线平滑－－只需要基本的html和正则表达式知识。
• 功能全面－－不仅只能测试web应用。
• 架构可伸缩－－其组件被设计为可通过合并完成大规模测试。测试可以在多台主机上同时运行。
• API可扩展－－API开放，并可由用户扩展编程。
• 技术支持良好－－在线用户指南、用户论坛、网络文章也包括这本书。

本章引导您开始第一次的JMeter试用。将向您介绍JMeterm同时使您对它的能力有一个整体的认识。除此之外，还会带您认识JMeter的操作界面，让你亲身感受到几个重要的JMeter组件。

 让我们开始...
JMeter是一个桌面应用，被设计为用于测试c/s结构的应用程序，如web应用或FTP应用。是到目前为止，一个使用得最广泛的开源测试工具。它是由 纯java编写的，通过其API可以对它进行扩展。JMeter位于c/s中的客户端工作，它可以测试服务器的响应时间，CPU负载，内存占用和资源的使 用。

 绝大多数的JMeter测试脚本或测试计划都涉及到创建一个循环，按照预先定义的时间间隔和线程组来模拟向服务器发出请求。这些测试脚本可以定制和扩展。一个基本的JMeter测试计划应该至少包括三个部分：线程组，监听器，采样器。
线程组用来模拟一组用户（用户数至少一个）。
采样器使请求发往目标服务器。
监听器捕获每个请求后收到的响应数据。

通过界面认识它
一个典型的测试计划由一个或多个线程组，逻辑控制器，监听器，定时器，断言和配置等元素组成。
线程组：一个线程模拟一个用户。所有的测试计划的元素都必须放在一个线程组元素下。
监听器：监视JMeter运行测试用例时接收到的数据。
控制器：其逻辑可以自定义，如让检验员告诉JMeter向服务器发出请求。
定时器：设定一个线程发出的两次请求间的间隔时长。
断言：测试返回的结果是否是期望的值。
配置：与检验员相关，可以增加和修改请求。

以下为界面截屏图。

 

JMeter界面上有两个面板，一旦JMeter投入运行，你可以看到它们。测试计划和工作区面板，如下图所示。一个测试计划描述了JMeter投入运行后的测试步骤。工作区提供临时的数据存放空间。工作区数据与测试计划分开存放。

左边的面板以树形显示了我们测试计划，其中节点的添加和删除可以通过右击节点进行。右边的面板显示了每个节点的详细配置。

下面是由一个线程组和其它一些元素组成的一个测试计划例子。

在我们使用JMeter进行性能测试时，线程组是必选元素。这个元素可以通过模拟多个用户对服务器进行压力测试。你甚至可以对测试进行的时间进行预设，下图是线程组的详细显示。

另一方面，同样一个测试计划可以扩展成为包括功能或回归测试。如下图所示添加Assertion（断言）元素。

 正式开始使用...

 安装JMeter
你需要首先从以下网址下载最新发布的版本http://jakarta.apache.org/site/downloads/index.html，下载完成后，解压缩到你想要的目录就完成了安装。
提醒：为了进行远程测试请避免在压缩时使用带空格的目录名。

设置环境变量
首先机器上建议安装jdk1.4或更高版本。并设置JAVA_HOME环境变量。

运行JMeter
在你的JMeter的安装目录下有bin目录。在windows系统中，运行jmeter.bat。如果你运行在unix系统中，你需要运行jmeter。
在这个过程中，JMeter会自动在它的lib目录或lib/ext目录中找所需要的jar包。因此，如果将来您自己开发了JMeter的组件，你也需要把它们拷贝到JMeter的lib/exit目录中。
如果你运行JMeter在代理或防火墙的后面，你需要提供服务器名和端口号，用命令行的参数指定。
例如
jmeter -H 129.198.1.1 -P 8000 -u someusername -a someuserpassword -N localhost

测试计划

 JMeter的测试计划封装了你需要手动编写的测试脚本。
什么是测试计划？
测试计划定义了如何进行测试的框架。最简单的测试计划包括以下元素：
线程组：用于指定运行线程的个数和坡道期，循环次数。每个线程模拟一个用户，坡道期指定创建所有线程的时间。例如指定5个线程和10秒的坡道期，表示每个线程的创建时间为2秒。循环次数定义了测试重复的次数。而且可以指定开始和结束的具体时间。

采样器：用于发出http/ftp/soap/xml/jdbc/ldap请求到服务器。

监听器：用于后处理请求数据。例如你可以保存数据到文件或者以图表显示。

开始运行JMeter,测试计划就会出现工作区左边的面板窗口中。

具体描述如下：
User Defined Variables:你可以定义静态变量，它们是允许你在测试中重复提取的值，如服务器名，端口号等。例如你要测试一个www.example-jmeter.net的应用，你可以定义一个"server"变量，那么测试脚本中的"${server}"就会该值替代。

Functional Test Mode:它会记录下从服务器返回的数据。如果你要进行压力测试，请不要选择它因为它会影响结果。
Run each Thread Group separately：单独运行每个线程组。如果您有二个或更多的线程组在你的测试计划中。选中该项，表示JMeter会顺序地运行它们，否则会并发运行它们。

Add directory or jar to classpath:如果你自己扩展了JMeter组件，可以使用该项添加jar包。记住需要重启后才能生效。另外，你也可以直接把jar包拷贝到 JMeter/lib目录下。或者通过编辑JMeter.properties文件来包含额外的jar，如"#user.classpath=.. /classes;../jars/jar1.jar,这样可以避免出现路径中包含空格引发的问题。

测试计划的组成
测试计划必须由至少一个线程组组成。每个线程组中都可以包含一个或多个以下组合：
采样器，逻辑控制器，配置，监听器和定时器。每个采样器能够关联一个或多个预处理元素，后处理元素和断言元素。让我们更进一步了解它们。

线程组
线程组是测试计划的入口，它包含所有其它的JMeter元素，一个线程组控制所有由JMeter创建的仿真线程，它们模拟多用户请求。
线程组代表着一组执行特定测试用例的用户，在线程组的控制面板里，显示在下图。如果有多个线程组那么它们会彼此独立地执行。

详细描述如下：
Action to be taken after a Sampler error:一旦采样器在测试过程中报错，你可以作出以下的选择：Continue继续进行下测试，stop Thread停止当前测试的线程，Stop Test完成停止测试，便于进行错误原因的查看。
Number of Threads:模拟用户的人数或者是web应用的连接数。
Ramp-Up Period:定义JMeter创建所有测试线程的时长。例如设定线程数为10，坡道期为60秒，那么每个线程会以6秒/个的速度连续创建。在60秒以 后，所有的线程将会投入运行。比较好的策略是将你的坡道期设置得足够长以避免在测试一开始就造成很大的工作负载，但不要过长，你可以一开始将坡道期设置为 等于要创建的线程数，稍后根据情况进行调整。
Loop Count:定义测试执行的次数，默认情况下，测试仅执行一次。点击Forever选项框那么测试会一直重复执行直到你手动停止它。
Scheduler Configuration:1.9之后的版本具有该项，允许你设定测试的开始和结束时间。只有时间到达开始时间，测试才会真正开始。在每个测试循环之 后，除非结束时间到了，测试将会继续下去一直到达loop count的上限。startup delay用于设定JMeter在第一个测试线程启动前的开始等待时间，duration用于设定整个测试的进行时间。前者用于覆盖start time的设定，后者覆盖end time的设定。

控制器
JMeter有两类控制器：
1.Samplers:允许发送特定类型的请求给服务器。稍后我们会发送http请求给服务器，所以我们会选用Http Rquest采集器。可以通过Configuration元素给采集器进行设定。

2.Logic Controllers:允许自定义何时发出请求的逻辑。例如你可以用Random Controllers来向服务器随机发出http请求。

采集器
JMeter采集器允许你定义发往服务器的请求，模拟一个用户通过网页向服务器发出的请求。每个采集器生成结果包含以下一些，如性能、延迟时间、呑吐量 等。默认情况下，JMeter会按照采样器出现在测试计划树中的顺序发送请求命令。当然，为了处理的采样的顺序可以使用逻辑控制器进一步定制。这将在后面 的“逻辑控制器”中进一步解释 。

您可以自定义每个采样器通过设置其属性，或者您也可以添加配置元素。在这本书中，因为我们将发出许多HTTP请求到相同的服务器，我们可以使用默认配置元素，它预先定义了发送的http请求。

一个http请求的采样器面板显示如下：

 
如果你希望JMeter进行验证，你可以添加Assertion元素，关于Assertion的更多内容，后面再详细介绍。
在一个Http请求采样器面板中的响应Assertion显示如下：

 以下是JMeter提供的所有采样器列表：

HTTP Request
FTP Request
JDBC Request
Java Request
SOAP/XML-RPC Request
WebService (SOAP) Request
LDAP Request
LDAP Extended Request
Access Log Sampler
BeanShell Sampler
BSF Sampler
TCP Sampler
JMS Publisher
JMS Subscriber
JMS Point-to-Point
JUnit Request
Mail Reader Sampler
Test Action

逻辑控制器：用于定义采样器的执行顺序。一个逻辑控制器的子元素有：采样器、配置，其它逻辑控制器。JMeter可能会随机选取（使用随机控制器） ，重复（使用回路控制器） ，交换（使用交错控制器）等。

 

 
以下是所有JMeter提供的定时器列表：
Constant Timer
Gaussian Random Timer
Uniform Random Timer
Constant Throughput Timer
Synchronizing Timer
BeanShell Timer

 

配置元素
配置元素允许你创建默认的变量在采样器中使用。用于修改采样器发出的请求内容。
它们只能被同一范围内的采样器访问，并且先于采样器被执行。
以下是HTTP Request Defaults 面板，如图：


 

• 添加用户
• 添加和配置默认的HTTP Request
• 添加HTTP Request
• 添加监听器显示、存放测试结果
• 保存和运行测试计划

添加用户
1.右击Test Plan图标在左边窗格，然后选择add|Thread Group。


 右边的将显示Thread Group的控制面板。

2.将Thread Group更名为My Users.
3.设定为一次连接和一个用户。
4.更变Ramp-Up Period(坡道期)为0,意味着用户将会马上开始测试。如果还有其他的用户，那就意味着所有的用户立即开始测试。

 

接下来做其它的步骤。
添加默认的HTTP Request
1.右击My Users元素，选择Add | Config Element | HTTP Request Defaults。
2.选择后显示它的控制台界面。
3.重命名为My URL。
4.在服务器名或IP地址栏中输入www.mocksite.net或其它你想用的网址。其余不动。设置HTTP Request Default Element会引起在My Users中的所有请求采样器访问同一个服务器。
显示如下：


 

 

添加监听器
最后，我们添加一个简单的监听器，Aggregate Report。这个元素将存放所有http请求的结果，并以表格形式输出。
1.选择My Users元素并Add | Listener | Aggregate Report。
2.在Write All Data to a File：在Filename栏中输出目录名或用browse按钮选择，并输入输出文件名。
以下为完成图：


 

保存和运行测试计划
JMeter要求我们在运行之前保存测试计划。
1.选择Save Test Plan从File菜单。JMeter允许你只保存一部分，通过选择分支。
2.在Save as中输入文件名，例如输入My Users。扩展名为.jmx。
3.从run 菜单选择运行。
以下为Aggregate Report Element和Control Panel运行结果。注意右上角有小的方框，旁边的数字显示激活的线程数和总线程数。


 
以下为运行测试计划之后的界面。右上角方框为灰色，只显示总线程数，你也可以手动停止测试，通过选择Stop从Run菜单。

 

文件上传攻击 《转载》

《拆掉思维里的墙》读后感  《转载》

和list&非标类团队的开发同学合作了将近1年了，自己在这个阶段看到了一些自测效果提升的情况，分享出来。下表是xlist&非标类团队中15名开发同学2012年上半年和下半年的bug reopen率和低级bug率的统计。可以看到2项指标均有不同程度的下降。经过这半年的实践，小谈一下我接口的开发团队的自测情况。

表一 list&非标类团队中15名开发同学的bug统计

一、自测水平和代码水平有关系么？

我认为，自测水平和代码水平是弱关联的。虽然编码能力强，有助于自测的效率，但是并非编码能力决定自测水平。

我觉得自测的觉悟和人本身的责任心是息息相关的，有些开发同学从始至终自测精神都非常好。例如，我一个对口产品线的开发同学：盈轩，我最早测试她的产品，她才开始coding，那个时候她让我印象最深刻的就是，写出来的业务逻辑，几乎无bug。后来随着她编码能力越来越棒，自测也一直坚持做的非常好。

二、关于自测精神

我觉得自测精神是一个好开发应该具备的基本素质之一。假如我们比较代码，在某个项目、某个日常里面碰到不那么靠谱的开发怎么办？我觉得，他不重视，他的老大一定要重视。例如，我们对口开发组的主管索尼，非常重视开发自测的情况，每次质量团队的bug统计数据出炉之后，索尼都会强调下自测的重要性。我想这样是我们开发组自测风气略有提升的原因之一。万一主管也不重视呢？我也没办法了。

三、如何提升自测水平？

这一点，我本身是没有经历的。我只能分享给大家，我观察到的。给大家分享几个案例。女士优先，先来说说女生吧。

盈轩，一个开发经验不到2年的美女，但是代码质量非常好。每次产品完成开发之后，盈轩几乎自己会完整的测试一遍业务逻辑，还会关注下不同浏览器下的页面表征。

临意，如果你接口开发是临意，那我只能说，你走运了，因为你确实可以少操心好多。我也曾问过临意关于自测的看法，聊过单元测试之类的，他提到，单元测试还是功能自测都不重要，关键是开发要清楚业务逻辑，要分析记录好自测点，然后再开始自测，不能一顿乱点。

少符，非常了解业务的开发，他自测的优势在于非常了解所负责的产品逻辑，并且设计测试主流程和分支流去自测。

本相，通过完整而详细的UC指导自己的开发思路，完成开发只会会在本地自测业务逻辑。

通过他们的共性，可以总结出开发自测的要点：(1)理清楚业务逻辑，最好配以UC或思维导图；(2)编码完成后代码部署到本地进行一遍完整的功能执行，验证数据输入和输出；(3)主管要重视；

四、哪些日常可以完全让开发自测，测试不参与？

评估点：(1)日常的重要性。(2)开发对此业务的了解程度。如果开发新接手该业务，那么不管这个开发的代码质量有多好，建议都不要完全自测；如果通过日常合作了解该开发清楚业务主流程，那么可考虑开发自测即可。(3)开发过往的代码质量。

有时候日常感觉开发自测不完全放心的时候，可以考虑和开发一起评估UC，然后让其自测。如果UC依然不放心，可以自己写完TC，请开发同学执行TC，全部通过才算自测通过。

　　1.Running Vusers（负载过程中的虚拟用户运行情况）

　　说明——系统形成负载的过程，随着时间的推移，虚拟用户数量是如何变化的，描述为（用户在几分钟左右到达了组在峰值多少个虚拟用户，负载的生成是大约每分钟增加几个用户，峰值负载持续为几分几秒）。

　　2.Rendezvous（负载过程中集合点下的虚拟用户数）

　　说明——脚本中一般要设置集合点才会产生并发，随着时间的推移各个时间点上并发用户的数目，方便我们了解并发用户数的变化情况。描述（刚开始的几分钟内，负载的并发用户都是几个，而后面变化为几个用户并发）。

　　（二）在Transactions（事务）中

　　这里给出了所有和事务相关的数据统计，方便了解被测试系统业务处理的响应时间和吞吐量。

　　1.Average Transaction Response Time（平均事务响应时间）

　　说明——反映随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。如果和前面的用户负载生成图合并在一起看，就可以发现用户负载增加对系统事务响应时间的影响规律。描述（看到响应时间是如何增长的，随着时间的推移响应时间逐渐变长，并且在不到多少时间的时候突然出现响应时间大幅下降的情况）另外事务的响应时间也不应该超过用户的最大接受范围，否则会出现系统响应过慢的问题。

　　2.Transactions per Second（每秒事务数）

　　说明——数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。描述（看到系统的TPS随着时间的变化逐渐变大，而在不到多少分钟的时候系统每秒可以处理多少个事务。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。而在几分钟以后开始出现少量的失败事务）

　　3.Transaction Summary（事务概要说明）

　　说明——通过的事务数越多，说明系统的处理能力越强；失败的事务越少，说明系统越可靠。描述（对于注册操作一共有对少次操作成功，有几次失败。可以开率结合前面的每秒错误数进一步分析为什么会出现几个注册错误，以及错误发生的时间和该时间产生错误的原因）

　　4.Transaction Performance Summary（事务性能概要）

　　说明——给出事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。描述（看到这个事务最大时间为多少S，最小时间为多少S，平均时间为多少S。柱状图的落差越小说明响应时间的波动较小，那么说明系统不够稳定。）

　　5.Transaction Response Time Under Load（在用户负载下事务响应时间）

　　说明——在负载用户增长的过程中响应时间的变化情况，起始这张图也是将Vusers和Average Transaction Response Time图做了一个Correlate Merge得到的，该图的线条越平稳，说明系统越稳定。描述（看到负载逐渐增加到几个用户时，事务的响应时间基本没有变化，而用户增加到几个开始，随着用户负载的增加响应时间也有较大的波动）

　　6.Transaction Response Time（Percentile）（事务响应时间的百分比）

　　说明——有多少比例的事务发生在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。描述（看到百分几%的事务是在几秒内）

　　7.Transaction Response Time （Distribution）（每个时间段上的事务数）

　　说明——在每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。描述（看到在所有的事务中，有多少个事务的响应时间最接近几秒，而有几个事务的响应时间最接近几秒）

　　（三）在Web Resources（网页资源信息）中

　　当Controller的Run Time Setting中Preferences下的Generated Web performance graphs选项处于开启状态时，该图表才会出现。

　　1.Hits per Second（每秒点击数）

　　说明——每秒点击数提供了当前负载重对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。描述（随着时间的增加，每秒点击数在上升，最高达到了多少次/s）。

　　2.Throughput（带宽使用）

　　说明——当前系统负载下所使用的带宽，该数据越小说明系统的贷款依赖越小，通过这个数据能确定是否出现了网络带宽的瓶颈。描述（得到醉倒的带宽峰值是多少B，远远低于100Mb的局域网带宽上限，所以系统不存在带宽瓶颈）。

　　3.HTTP Responses per Second（每秒HTTP响应数）

　　说明——每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而HTTP响应数是指服务器返回的响应数。如果服务器返回的响应数小于发出的请求数，那么说明服务器无法应答超出负载的连接请求。描述（最高峰时服务器每秒能返回接近多少个HTTP _ 200 OK的状态）。

　　4.Connections Per Second（每秒连接数）

　　说明——两种不同状态的连接数，即中断的连接和新建的连接，方便用户了解当前每秒对服务器产生连接的数量。描述（随着时间的推移，系统的连接数逐步上升，最高达到每秒几个连接）同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常这个时候服务器会返回504错误。可以通过修改服务器的最大连接数来解决问题。

　　（四）在Web Page Diagnostics（网页分析）中

　　当在场景中打开Diagnostics菜单下的Web Page Diagnostics功能，就能得到网页分析组图。通过这个图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过这个功能，可以实现对网站的前端性能分析，明确系统响应时间较长时由服务器端（后端）处理能力不足还是短连接到服务器的网络（前端）消耗导致的。

　　1、 Web Page Diagnostics（网页分析）

　　说明——添加该图先会得到整个场景运行后虚拟用户访问的Page列表，也就是所有页面下载时间列表。描述（在注册用户事务进行分析，整个负载由三个页面请求组成，其中有一个请求始终在多少秒以内，而另外几个请求时间较长并且有上升趋势，然后通过Select Page to Break Down命令选择具体的Page来获得每个请求的相关详细信息——分析如下：

　　1.Download Time下载时间分析——组成页面的每个请求下载时间——可以看到创建用户的操作由4个请求组成，其中导致注册用户较慢的主要原因是注册完成后需要等待两秒钟再刷新至论坛首页，而非注册用户本身需要消耗的时间，首页刷新慢也只是因为Client（客户端）需要消耗较多时间，同时Receive（接收）的时间也有一定的影响。

　　2.Component（Over time）各模块的时间变化——通过这个功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。随着时间的增加，首页的处理时间（最上面的一根线）从多少秒上升到了最大值多少秒，而注册英护响应时间几乎没有上升。

　　3.Download Time（Over time）模块下载时间——针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。发现首页请求的下载时间主要消耗在Client上，而多少分多少秒之前Recevie所消耗的时间在逐渐变长。

　　4.Time to Buffer（Over time）模块时间分类——列出该元素所使用的时间分配比例，是受Network Time影响的多还是Server Time影响的多。对于首页刷新的响应时间来说，主要是Network Time网络上消耗的时间，而Server Time服务器端的处理时非常优秀的。Server Time是服务器对该页面的处理时间；Network Time是指网络上的时间开销。）

　　2、 Page Download Time Breakdown（页面响应时间组成分析）

　　说明——显示每个页面响应时间的组成分析，一个页面的响应时间一般由以下内容组成：

　　Client Time客户端浏览接收所需要使用的时间，可以不用考虑。

　　Connections Time连接服务器所需要的时间，越小越好。

　　DNS Resolution Time通过DNS服务器解析域名所需要的时间，解析受到DNS服务器的影响，越小越好。

　　Error Time服务器返回错误响应时间，这个时间反映了服务器处理错误的速度，一般是Web服务器直接返回的，包含了网络时间和Web服务器返回错误的时间，该时间越小越好。

　　First Buffer Time连接到服务器，服务器返回第一个字节所需要的时间，反映了系统对于正常请求的处理时间开销，包含网络时间和服务器正常处理的时间，该时间越小越好。

　　FTP Authentication Time FTP认证时间，这是进行FTP登录等操作所需要消耗的认证时间，越短越好。

　　Receive Time接受数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。

　　SSL Handshaking Time SSL加密握手的时间，而Analysis在这里会分析得到页面请求的组成比例图，便于分析页面时间浪费在哪些过程中。

　　3、 Page Download Time Breakdown（Over time）（页面组成部分时间）

　　说明——随着时间的变化所有请求的响应时间变化过程。这里会将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析再不同的时间点上组成该页面的各个请求时间是如何变化的。描述（看到大多数页面的响应时间是比较稳定的，其中首页刷新变动较大——首先找到变化最明显或者响应时间最高的页面，随后在针对这个页面进行进一步的分析了解时间偏长或者变化较快的原因。）

　　4、 Time to First Buffer Breakdown（页面请求组成时间）

　　说明——组成页面时间请求的比例说明（客户端时间/服务器时间），通过这个图，我们可以直接地了解到整个页面的处理是在服务器端消耗的时间长，还是在客户端消耗的时间长，从而分析得到系统的性能问题是在前段还是在后端。描述（网络或客户端的时间开销占了绝大多数）

　　5、 Time to First Buffer Breakdown（Over time）（基于时间的页面请求组成分析）

　　说明——在整个负载过程中，每一个请求的Server Time和Client Time随着时间变化的趋势，可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致的还是由于服务器端变化导致的。描述（对于用户注册操作，望楼上的时间变化比服务器上的时间变化要剧烈）

　　（五）在Network Monitor（网络监控）中

　　在 Controller中添加了Network Delay Time监控后会出现该数据图。这个功能很好但并不是非常直观和方便，建议使用第三方专门的路由分析工具进行网络延迟和路径分析。

　　1、Network Delay Time（网络延迟时间）

　　说明——从监控机至目标主机的平均网络延迟变化情况。描述（看到网络延迟从多少毫秒逐渐减少到多少毫秒，最后上升到多少毫秒）。

　　2、Network Sub-Path Time（网络Sub-Path时间）

　　说明——当客户端在连接一个远程服务器时，路径并不是唯一的，收到路由器的路由选择，可能会选择不同的路径最终访问到服务器。描述（从监控服务区至目标服务器所经历的路径，以及每个路径上的网络延迟）

　　3、Network Segment Delay Time(网段延迟时间)

　　说明——各个路径上的各个节点网络延迟情况。描述（路由器和路由器之间的网络延迟变化情况，以便于分析影响整个网络时间的原因及节点）。

　　（六）在Resources（资源监控）中

　　资源包括很多种，在Analysis中监控的都市各种系统的计数器，这些计数器反映了系统中硬件或者软件的运行情况，通过它可以发现系统的瓶颈。

　　1、 System Resources（系统资源）列出了再负载过程中系统的各种资源数据是如何变化的，该图需要在场景中设置了对应系统的监控后才出现：

　　1.Database Server Resources（数据库资源）

　　说明——数据库的相关资源在负载过程中的变化情况。

　　2.Web Server Resources（Web服务器资源）

　　说明——Web服务器资源在负载过程中的变化情况。

　　（七）在Error（错误统计）中

　　当场景在运行中出现错误时，错误信息将会被保存在该计数器组中，通过Error信息可以了解错误产生的时间和错误的类型，帮助我们定位产生错误的原因。

　　Error per Second（每秒错误数）

　　说明——每秒错误数可以了解在每个时间点上错误产生的数目，该数据越小越好。通过这个图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。描述(看到场景在多少的时候出现了一次错误)。

　　Service Level Agreement Legend（SLA图标说明）

　　1、图标为灰色带减号的为No Data，说明在SLA中未对这个数据项进行监控，没有数据；

　　2、图标为红色带叉的为Fail，说明在SLA中定义了该项的数据监控，但该数据未能达到期望的阀值；

　　3、图标为绿色带钩的为Pass，说明在SLA中定义了该项的数据监控，该数据达到了期望阀值。

-----------------------------------------------------------------------------------------------------------------------------------------------------------

Vusers (虚拟用状态)

　　Vusers　用户状态计数器组提供了产生负载的虚拟用户运行状态的相关信息，可以帮助了解负载生成的过程。

　　Running Vusers(负载过程中的虚拟用户运行情况)

　　此图反映系统形成负载的过程，随着时间的推移，虚拟用户数是如何变化的。

　　Rendezvous(负载过程中集合点下的虚拟用户)

　　当场景中设置了集合点后会出现该图，反映了随着时间的推移各个时间点上并发用户的数目，方便了解并发用户数的变化情况。

　　Errors(错误统计)

　　当场景在运行中出现错误时，错误信息将会保存在该计数器组中，通过 Error 信息可以了解错误产生的时间和错误的类型，帮助定位产生错误的原因。

　　Errors per Second(每秒错误数)

　　可以了解在每个时间点上错误产生的数目，该数据越小越好，通过该图可以了解错误随负载的变化情况，定位何时系统在负载下开始不稳定甚至出错，配合系统日志可以定位产生错误的原因。

　　Transactions(事务)

　　给出所有和事务相关的数据统计，方便了解被测系统业务处理的响应时间和吞吐量。

　　事务默认状态：PASS、FAIL、STOP，如果是手工事务那么状态会有 PASS 和 FAIL 两种。

　　Average Transaction Response Time(平均事务响应时间)

　　反映了随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快。

　　结合负载生成图合并一起看，可以发现用户负载增加对系统事务响应时间的影响规律。

　　Transactions per Second(每秒事务数)

　　另一个关键数据是 TPS 吞吐量，该数据反映了系统在同一时间内能处理业务的最大能力，这个数据越高，说明系统处理能力越强。

　　TPS 会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS 会有所下降。

　　Transaction Summary(事务概要说明)

　　说明事务的 Pass 个数和 Fail 个数，了解负载的事务完成情况。通过的事务越多，说明系统的处理能力越强，失败的事务越少，说明系统越可靠。

　　结合每秒错误数图进一步分析错误产生的原因。

　　Transaction Performance Summary(事务性能概要)

　　事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。

　　柱状图的落差越小说明系统响应时间的波动较小，如果落差很大，说明系统不够稳定。

　　Transaction Response Time Under Load(在用户负载下事务响应时间)

　　在负载用户增长的过程中响应时间的变化情况，改图的线条越平稳，说明系统越稳定。

　　Transaction Response Time(Percentile)(事务响应时间的百分比)

　　不同百分比下的事务响应时间范围，可以了解有多少比例的事务发送在某个时间内，也可以发现响应时间的分布规律，数据越平稳说明响应时间变化越小。

　　Transaction Response Time(Distribution)(每个时间段上的事务数)

　　每个时间段上的事务个数，响应时间较小的分类下的事务数越多越好。

　　Web Resources(网页资源信息)

　　给出的是对于 Web 操作的一些基本信息，这些信息在服务器端也能获得，当 Controller 的 RunTime Setting 中 Preferences 下的 Generated Web performance graphs 选相处于开启状态时，才会得到该图。

　　Hits per Second(每秒点击数)

　　每秒点击数提供了当前负载中对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。

　　Throughput(宽带使用)

　　在当前系统下所使用的带宽，该数据越小说明系统的带宽依赖越小，通过这个数据能确定是否出现了网络带宽的瓶颈(注意使用单位为字节)。

　　HTTP Responses per Second(每秒 HTTP 响应数)

　　每秒钟服务器返回各种状态的数目，该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而 HTTP 响应数是指服务器返回的响应数。如果服务器返回的响应数小于客户端发出的点击数，那么说明服务器无法应答超出负载的连接请求。

　　结合每秒点击数看，如吻合，则说明服务器能够对每一个客户端请求进行应答。

　　Connections Per Second(每秒连接数)

　　给出两种不同状态的连接数，即中断的连接和新建的连接，方便了解当前每秒对服务器产生连接的数量。

　　同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常服务器会返回504错误。

　　可以通过修改服务器的最大连接数来解决该问题。

　　Web Page Diagnostics(网页分析)

　　当在场景中打开 Diagnostics 菜单下的 Web Page Diagnostics 功能，就能得到网页分析组图。

　　通过该图，可以对事务的组成进行抽丝剥茧的分析，得到组成这个页面的每一个请求时间的分析，进一步了解响应时间中有关网络和服务器处理时间的分配关系。通过该功能，可以实现对网站前端的性能分析，明确系统响应时间较长是由服务器端处理能力不足还是客户端连接到服务器的网络消耗导致的。

　　Web Page Diagnostics(网页分析)

　　添加改图先会得到真个个场景运行后虚拟用户访问 Page 列表，也就是所有页面下载时间列表。

　　通过 Select Page to Break Down 命令选择具体的 Page 来获得每个请求的相关详细信息。

　　Diagnostics options 选项提供四大块功能。

　　Download Time(下载时间分析)

　　可以得到组成页面的每个请求下载时间。

　　Component(Over time)(各模块的时间变化)

　　列出组成页面的每个元素，以及随着时间的变化所带来的响应时间变化。

　　通过该功能可以分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢。

　　Download Time(Over time)(模块下载时间)

　　提供了针对每个组成页面元素的时间组成部分分析，方便确认该元素的处理时间组成部分。

　　Time to First Buffer(Over time)(模块时间分类)

　　这里会列出该元素所使用的时间分配比例，是受 Network Time 影响的多还是 Server Time 影响的多。

　　Network Time：指网络上的时间开销。

　　Server Time：服务器对该页面的处理时间。

　　Page Download Time Breakdown(页面响应时间组成分析)

　　这张图显示了每个页面响应时间的组成分析，一个页面的响应时间一般由以下内容组成：

　　Client Time

　　客户端浏览器接收所需要使用的时间，可以不考虑。

　　Connections Time

　　连接服务器所需要时间，越小越好。

　　DNS Resolution Time

　　通过 DNS 服务器解析域名所需要的时间，解析受到 DNS 服务器的影响，越小越好。

　　Error Time

　　服务器返回错误响应时间，这个时间反映了服务器处理错误的速度，一般是 Web 服务器直接返回的，包含了网络时间和 Web 服务器返回错误的时间，该时间越小越好。

　　First Buffer Time

　　连接到服务器，服务器返回第一个字节所需要的时间，反映了系统对于正常请求的处理时间开销，包含了网络时间和服务器正常处理的时间，该时间越小越好。

　　FTP Authentication Time

　　FTP 认证时间，这是进行 FTP 登录等操作所需要消耗的认证时间，越短越好。

　　Receive Time

　　接受数据的时间，这个时间反映了带宽的大小，带宽越大，下载时间越短。

　　SSL Handshaking Time

　　SSL加密握手时间

　　得到页面请求的组成比例图，便于分析页面时间浪费在那些过程中。

　　Page Download Time Breakdown(Over Time)(页面组成部分时间)

　　提供了随着时间的变化所有请求的响应时间变化过程。将整个负载过程中每个页面的每个时间组成部分都做成单独的时间线，以便分析在不同的时间点上组成该页面的各个请求时间是如何变化的。

　　首先找到变化最明显或者响应时间最高的页面，随后再针对这个页面进行进一步的分析了解时间偏长或者变化快的原因。

　　Time to First Buffer Breakdown(页面请求组成时间)

　　提供了组成页面时间请求的比列说明(客户端时间/服务器时间)，通过这个图，可以直观的了解到整个页面的处理是在服务器端消耗的时间长，还是在客户端消耗的时间长。从而分析得到系统的性能问题是在前端还是后端。

　　Time to First Buffer Breakdown(Over Time)(基于时间的页面请求组成分析)

　　给出了整个负载过程中，每一个请求的 Server Time 和 Client Time 随着时间变化的趋势，可以方便定位响应时间随着时间变化的原因到底是由于客户端变化导致的还是由于服务器端变化导致的。

    随着公司组织架构的调整，战略调整，产品的实现技术不断变化，现在的测试人员可以说是什么都可以干。

    有些人做产品，有些人做平台，有些人做工具......

    有些人有点象专职开发，有些人有点象专职运营......

      Facebook,google的一些敏捷测试理念中，测试人员应该致力于提出测试解决方案，研究各种测试工具为主，具体的测试执行工作，由coding的开发同学去做。

    变化后面也有很多不变的，测试手段无外呼白盒测试，黑盒测试，静态测试，动态测试，单元测试，集成测试，系统测试，安全测试，性能测试等等。那些奋斗在一线的测试工程师的工作内容实则没有什么大的变化，访谈的结果是大家觉得自己也没有成就感，工作很累。

    这一切都让我迷惑了，很多人象我一样也迷惑了，测试人员的核心价值到底是什么？

    测试人员的职业发展是什么？特别是focus在业务上的测试人员的核心价值是什么？在这里仅表达下我个人的观点，欢迎大家一起拍砖。

Ø  核心价值一：测试设计能力

最基本的也是最重要的价值就是测试设计。无论是采用白盒，黑盒，手工还是自动化等不同的方式，精华都在测试设计中。测试设计能力入门容易，做深难，需要耐得住寂寞，不断的学习积累，同时需要的知识面非常广。

下面几点可以提升测试设计能力：

1.对产品的熟知程度

2.对用户的了解程度

3.技术实现/依赖产品/中间件/DB设计/缓存机制/安全机制等技术的深入了解程度

4.产品运行环境（包括服务端，客户端，浏览器，系统并发量，吞吐量等）

5.bug回溯（定位/分析）

非常值得一提的是bug回溯，是一项非常有意义的活动。很多公司特别重视线上bug的预防，分析，却忽略了线下bug的回溯。而实际上，大家都有这样的印象，发现bug的不一定是你设计的TC，而是在执行TC时发散的其他测试场景。通过bug原因分析，可以更精准的帮助你识别易出问题的点。而且现在的技术，环境都是多样性的，总会出现一些你意想不到的bug，它的存在一定是有原因的。这些东西需要通过bug回溯不断的积累。

Bug回溯  与测试设计形成良性循环

Ø  核心价值二：制定测试策略

大家都知道测试是不能穷举的。在有限的人力、时间、资源情况下，如何更快，更全面的覆盖被测对象，是需要策略的。

我记得以前天彤说过，专家级的测试工程师可以对被测对象进行“精准爆破”，非常认同。对于象淘宝这么庞大复杂的系统来说，如果不能做到精确设计，精确测试，为了保障大用户量大数据量的并发下，想最大程度的规避可能出现的风险，让测试同学以眉毛胡子一起抓的方式进行测试就是在劳民伤财。

不同产品，不同的团队，产品成熟度，人员的成熟度，所采用技术的成熟度等等，都可能导致测试策略的不同。制定测试策略的过程，就是对当前的项目、团队进行量体裁衣。

影响测试策略的因素：

• 项目类型  如：新产品，完善功能，重构型的，底层升级，数据库升级，不同的项目类型，测试重点也不同，采用的测试工具和测试类型也不尽相同

• 产品成熟度    主要考虑产品的业务是否稳定，成熟。是属于创新型，试水产品，是否是成熟行业，需求明确稳定等等？

• 使用研发技术和研发平台    采用新的研发工具，新的研发技术，还是公司成熟的技术，工具，使用什么样的数据库设计，包括产品的设计思想，产品架构等

• 团队能力及默契度   稳定型团队？新团队？半新半旧，人员技术能力如何？人员特点如何？（特别需要说明的是，通过bug回溯可以发现团队开发或测试人员的技术能力，代码质量，业务掌握情况，逻辑清晰等这些个人特质，针对不同的人可以在测试时做不同的重点验证）

•  研发模式   采用什么研发模式，传统的瀑布，还是敏捷，迭代等。这种研发模式以往常出现的问题是什么？该模式在该团队的运行是否成熟，稳定？

• 产品线上运行环境    包括服务端和客户端的运行环境，负载机制，缓存机制，服务器分布等

• 产品线上并发量，吞吐量等指标    关注目前指标及增长趋势

• 产品使用用户   使用产品的用户人群众分布？目前的使用满意度如何？用户的计算机使用水平如何？用户反馈的最大问题是什么？用户的使用习惯是什么？竞争产品在用户中的优势是什么？

• 测试过程保障    上线前测试依赖的环境、数据、技术、平台、工具保障，有现成的，还是需要开发？

测试策略的方面

²  测试类型

²  各种测试类型的测试程度、测试通过/停止标准

²  使用测试技术

²  依赖平台、工具

在工作中，大家对一些事情存在一些误区：

1.编码能力   我们不盲目崇拜编码能力，而是随着测试手段不同，测试深入程度不同，需要我们有能力去识别代码中存在的风险，对产品的技术实现有更深入全面的掌握，才能更有针对性的进行测试，所以，我们必须具备编码能力。

2.创新     我们不能为了创新而创新，而是在工作过程中，技术结合业务，为解决实际的问题自然而然的生长出来的新东西。这个创新一定是解决我们工作中的问题或用户的问题的。

3.工具     工欲善其事，必先利其器，随着我们被测试对象的复杂化，多样化，使用技术的差异化，一些常规手段无法测试的内容，一些重复的劳动密集性的事务，需要让工具代替手工去做，自然而然的就会产生工具。所以，我们不是迷信工具，也不是崇拜工具，工具是为我们服务，带来价值的。如果这个工具不能给我们带来价值，就算做一个工具，没有人使用，又有什么意义呢？

在实现测试设计与测试策略制定过程中，我们为解决实际问题自然会生出一些工具，平台，我们要鼓励大家用创新的思维去思考和解决问题，这样的产出是非常有价值的。

软件测试价值观-SMBT新理念  《转载》

　近年来有不少软件测试同行不少有些困惑-软件测试人员的价值在哪里？我们怎么才能做好软件测试？怎么才能让自己的价值在团队中得到最佳的体现？在这里SMBT理念会给你答案，你所有的困惑将会迎刃而解。 

　　一、SMBT是什么？

　　SMBT是Shortest time、Most bug、Best bug、Track bug这几个单词的缩写，其含义就是“测试人员要在最短的时间内发现最多最有价值的Bug，并将Bug跟踪到底”，这就是我们测试人员追求的最高价值。其核心包括：一个宗旨、四个关键域。

附：SMBT图示

　　二、SMBT宗旨

　　以产品成败为出发点，站在整个项目团队的立场上思考问题、解决问题，而不是单一的从测试团队或者个人为出发点。

　 　在这点我想说明的是：在一些企业里面的某些产品团队因为或多或少的原因导致产品失败，最后影响整个产品团队的考核，这个时候必然会有一部分测试人员跳出 来说我们测试做的挺好的，产品失败和我们没什么关系，为什么给我们也考核得那么差。这时我想对那些测试人员或者主管测试的负责人说，你们真的错了，你们是 为整个产品团队服务的，虽然产品失败的因素可能会很多、可能和你没直接关系，试想一下难道真的和你一点关系都没有么？如果现在用SMBT的宗旨来看待这个 问题，你势必会找到你错在了哪里！我们不能有本位主义的思想来禁锢自己，我们一切要为整个产品团队出发，只有这样你才能在整个产品研发过程中充分发挥你的 才能为整个产品服务，而不是单单的测试活动，因为单单的测试活动是远远不够的，这是传统的测试理念和思维给我们带来的弊端，也是SMBT产生的根本。

　　三、SMBT关键域

　　1、Shortest time：最短时间、尽早、尽快

　　一方面Bug无限，时间有限，这个道理大家都知道，我们在测试工作中测试的时间是有限的，我们的每一项测试的时间都不可能很充足，随着互联网行 业的竞争越来越大，产品更新换代的周期日益缩小，企业稍微慢一步，整个产品就完全没有竞争优势，势必会被竞争对手抢占先机，即使你有创新的想法，但没有最 快的速度上市，也难得商机。不管是互联网行业还是其他行业，现在都是快鱼吃慢鱼的时代，在这种环境下，对我们的研发团队、我们的测试人员提出更高的要求， 那就是快-快-快，一点都不能慢。测试时间长了即使你产品的质量再好，因为时间关系错失商机、流失用户，我们所有的付出都将白费。

　　另一方面从研发模式来讲，现在很多企业都比较推崇敏捷研 发模式，这也是追求快速响应的一个途径，然而对于测试来讲，我们一定要尽早的发现Bug，让开发人员尽早的修改，或者让产品人员调整需求，而不是到了产品 最后某些本应该前期发现的Bug结果到了产品快上线的时候才发现，一旦这个时间出现比较严重的Bug，这将会对整个产品的研发进度造成严重的影响，同时因 为这个Bug的修复势必会对本来感觉已经稳定的系统带来重大的质量干扰，因为修复Bug在很大程度上必然会带来新的Bug，至于修复Bug的难度那就更不 用说了。特别是在产品研发的后期发现需求流程上的问题，这将是灾难性的后果！

　2、Most bug：最多Bug

　　量变到质变是事物的变化规律，测试也如此，只有Bug的量上去了，产品的质量才能有所改观，如果Bug在数量上上不去，这对测试活动有信心谈何 容易，一旦遇到这种情况测试经理们就头痛起来了，因为这必定是一个危险的信号，我们的信心将会荡然无存，除非系统质量足够的好，测试手段足够的高超，否则 我们将会面临产品上市后的最大危机。

　　3、Best bug：最有价值Bug

　　之前谈到我们尽早发现Bug、发现最多的Bug，难道这样就可以了么，很显然特别的片面，进一步的说我们还要发现有价值的Bug。那么什么样的 Bug才算有价值呢？直白一点就是最影响系统使用、对系统功能模块有严重影响或者破坏作用的Bug，最能决定研发周期的Bug，比如说如果事先能把需求类 的Bug在需求阶段提出来解决而不是等研发末期提出来，还有就是影响系统架构的Bug以及一些隐藏很深修复难度及波及面广的Bug，所有这些都是从量变到 质变的过程。

　　4、Track bug：跟踪Bug

　　经常会遇到一些项目在项目末期了才去关注以前提交的Bug，测试人员尽管很早就提出了很多严重的Bug，没有引起开发人员的注意或者测试人员跟 进不给力，在这个时候需求类Bug提交的早、也提交的多、并且也很有价值，甚至有些直到产品发布上线运营了有客户投诉或者在运营过程中再次暴露的时候才引 起关注，此类情况的发生直接说明前期所做的测试工作算是白做了，根本没有对产品质量做保证和提升嘛。也就是说我们测试人员缺乏明显的跟进，只发现Bug而 不跟进Bug修改这是测试人员最大的悲哀，反之如果测试人员做到了这点也是测试人员的最大价值体现，我们找到Bug不算什么，关键还是要让Bug得到解 决，这样才能对整个产品负责，也只有这样测试人员的价值才能得到真正的发挥和体现。

　　四、SMBT运用

　　1、领会SMBT的宗旨，建立良好的心态，做一个有责任心的测试人员，明确自己的工作不仅仅是测试工作，而是为整个产品团队服务的工作，当然这得根据自己的精力和能力来限定范围，不能什么都抓什么都做。

　　2、如何实现Shortest time

　　　　1）尽早介入到产品研发活动中，特别是产品需求阶段是很容易被忽略的，有问题尽早发现；

　　　　2）对测试活动及相关的安排进行合理的部署，测试策略、测试方法及测试工具的选择对测试效率的影响至关重要。

　　3、如何实现Most bug、Best bug

　　　　1）加强测试设计的能力，提升测试技术基础势在必行，剖析被测对象的内在，而不仅是表象。

　　　　2）站在产品用户的立场思考问题做好测试设计、深入挖掘用户行为和心理、深入理解系统运行机制及实现原理，这些都做到了，还做不到Most bug、Best bug真的很难。

　　　　3）不能单一的追求Most bug或Best bug，要两者兼顾，要在Most的基础上Best。

　　4、如何实现Track bug

　　　　1）以主人翁的心态对待每一个Bug，我们不仅负责测试出Bug，还要将这个Bug的修改情况负责跟踪到底，直到最终解决不再复现为此，也只有这样我们的测试工作才算完成。另外还要以积极的心态高效的跟进，不能有半点耽误和延迟。

　　　　2）不光要配合Bug修改，更重要的是要起到督促的作用，测试人员的行为要为整个项目负责。

　　领会SMBT宗旨，将SMBT四个关键域融会贯通、运用自如，此乃测试最高境界也！

　　PS：坦诚的讲，鄙人自知对SMBT的理解或许存在一些不完善的地方，在此也算是起到抛砖引玉的作用吧。希望测试界的广大同仁及读者能够对 SMBT进行完美的补充，让SMBT更加完善，理念更加深入透彻。也希望测试工作者能够灵活运用到企业中，更好的改进测试工作，提升测试价值，保持测试行 业的绝对竞争优势！

　　本文转载自：http://blog.csdn.net/vincetest/article/details/8330303

10种使测试人员陷入困境的行为趋势   《转载》

这篇文章的作者是著名软件与网络测试实验室Quardev的高级顾问，做过测试经理、测试承包商、为微软等公司做过顾问，并为很多杂志写过文章，且时常在各种测试大会中做演讲。在10年的时间中作者组织、管理了超过400次的测试岗位面试，这些面试都是以项目模拟的形式进行的，从对这些面试中面试者的表现，作者总结了限制测试人员发挥其测试技能的10种倾向，并提出了如何避免这些倾向的建议。

　　作者组织这些面试的目的是让面试者们暴露他们的优势与不足，从而决定他们是否适合在Quardev的工作。面试的流程如下：先是通过电话面试了解求职者的工作经历，然后通过邮件提供给求职者一个产品，并要求在20分钟之类对其进行测试写出至少一个bug。接下来，会邀请求职者去实验室，对他们的工作经历进行一次面对面的深入调查。项目模拟是最后一步，项目模拟的过程如下：

　　作者在白板前介绍测试任务，然后在白板上写下Bugs和Issues/Questions。

　　求职者在Bugs下记录他们发现的问题，每条记录必须少于20个单词。Issues和Bugs的区别在于，测试人员可能不是很确认这是否是一个bug，他们不确定是否原本就是这么设计的。比如"在主目录下没有setup.exe"，事实上可能是一个bug。这与求职者对于程序设计原理的了解程度和自信心等级有关。

　　如果求职者过于谨慎，在测试过程中没有在Bugs下有任何记录，或者过于自信，不认真考虑具体的实际情况，将自己发现的问题都记

　　录为bug，我都会特别关注。我希望在谨慎和自信直接找到一个平衡点。

　　作者告诉求职者，当他们发现一个问题的时候有三个选择：1）记录为一个bug；2）记录为一个issue；3）提一个问题。然后作者写下Test Ideas和Tests Run。Tests Ideas是由于执行时间过长而不当场执行的测试，Tests Run则是求职者当场执行的测试。

　　白板上的内容如下图：

　　然后作者给求职者一台笔记本电脑，上面有一个目录存放着被测软件，软件目录如下：

　　这是一个检查三角形类型的程序，输入用逗号隔开的3个数字，点击Check按钮后，会有5种可能的输出：“scalene” (three unequal sides), “equilateral” (three equal sides), “isosceles” (two equal sides), “invalid”, and “Not a Triangle.”。软件的UI如下：

作者让求职者开始进行测试，并在进行过程中接受求职者的提问。在项目模拟过程中，作者关注求职者的以下一些能力：

　　Questioning：他们是否通过提问来构建他们的测试，还是直接进行测试

　　Resourcing：他们是否索要项目相关的文档、用例、邮件的资源

　　Modeling：他们如何关注提供测试的目录？是否打开每一个文件夹？并对每一个进行提问，并围绕他们设计测试

　　Recording：测试过程中是否进行记录

　　Conjecturing：推断，如果他们没有向我进行提问，他们对产品的设想是如何的？并且如何进行测试？

　　作者在求职者的测试过程中寻找所谓的“The 3 C’s”：caution， critical thinking， and curiosity。

　　如果他们向我进行提问，我们会以开发、项目经理、测试lead、CEO等角色中的一个对他们进行回答。有时作者会给以善意但是误传消息的回答，有时回答又会自相矛盾，这些都是真实项目中会出现的情况。

　　作者的目标是观察求职者的技能，并使他们陷入作者自己或者身边的人曾经遇到过的困境。通过这些面试，作者总结了最常见的10种使测试人员陷入困境的行为趋势：

　　10、Stakeholder Trust

　　测试人员对利益相关者过分的信任，认为他们拥有所有必须的信息，并且所有他们提供的信息都是正确和中肯的。

　　如何避免：尽可能多的形式收集信息：阅读、提问、交谈、测试...

　　9、Compartmental Thinking

　　思维局限性，测试人员仅从自己的或者近似的视角出发考虑问题，而没有用其他的、对立的或者正交纬度的视角出发，这样会导致漏掉一些

　　系统级的bug，或者漏测某个完整的特性。

　　如何避免：尝试Brute Cause Analysis

　　8、Definition Faith

　　测试人员没有意识到诸如“回归测试”、"测试用例"、"功能"、"特性"等对不同的人来说意味着不同的事情。结果会导致，测试人员自认为测

　　试已经完整了，而实际上测试却还没开始。

　　如何避免：牢记相同的单词可能有不同的含义，使用与你作为测试人员所服务的合作伙伴角度出发最合适的定义来理解。

　　7、Inattentional Blindness

　　非注意盲视，和思维局限性有所不同，测试人员以自己的视角发现了某些事情，但是却没有处理这些信息，而是直接忽略了。

　　如何避免：全面获取信息，而不是指关注自己认为会引起问题的那部分。situational awareness态势感知，在大规模系统环境中，对能够引起系统态势发生变化的安全要素进行获取、理解、显示以及预测未来的发展趋势。

　　6、Dismissed Confusion

　　由于困惑而驳回自己的意见，测试人员不自信，认为开发软件的人员比自己更聪明，导致问题的不是软件本身的bug。

　　如何避免：增加自信，遇到困惑的时候提出问题或者记录下来

　　5、Performance Paralysis

　　面临选择的时候害怕犯错而迟疑不定。

　　如何避免：尝试P.I.Q.cycle：Plunge-In-and-Quit，从某处开始考虑一个问题，当思考的过于复杂或者抽象而让你头疼的时候，退出来休息下，然后回来以新的视角考虑这个问题

　　4、Function Fanaticism

　　功能狂热，只通过对UI判断，程序能做什么、不能做什么，以此来直接进行测试。而不考虑程序的构成、如何运行、如何被使用及有哪些依赖项。

　　如何避免：使用启发式思考或者checklist

　　3、Yourself， untested

　　测试人员没有从合作伙伴的角度评估自己的工作。给合作伙伴提供了不准确的信息：bug报告、测试说明等。

　　如何避免：test your testing，评估自己的测试技术、策略、计划、风险等

　　2、Bad Oracles

　　Oracles 指识别问题的原理和机制。这里相当于用例是否通过的标准。测试人员使用了错误的标准或者不知道使用什么标准来评判一个用例是否通过。

　　如何避免：听取其他合作伙伴的已经，以判断问题是否为bug。

　　1、 Premature Celebration

　　提前庆祝，发现问题后不深入寻找原因，而是提前抛出问题。

　　如何避免：遇到问题立即进行分析推断，而不是马上下定论。

PDCA理念融入软件测试   《转载》

　　摘要：软件测试作为软件质量保障的重要手段，PDCA循环是全面质量管理所应遵循的科学程序。本文结合软件测试工作的特点，通过文档规范的方式，将PDCA的理念融入软件测试，提出一套软件测试工作的流程。

　　关键字：软件测试、PDCA、测试流程

　　1、引言

　　PDCA循环又叫戴明环，是美国质量管理专家戴明博士提出的，它是全面质量管理所应遵循的科学程序。全面质量管理活动的全部过程，就是质量计划的制订和组织实现的过程，这个过程就是按照PDCA循环，不停顿地周而复始地运转的。PDCA 描述如下，PLAN：活动、控制、资源、目标；DO：按计划实施；CHECK：监控和测量一致性和有效性；ACTION：分析/回顾/改进/提高有效性。软件测试是有计划、有组织和有系统的软件质量保证活动，是软件工程的重要组成部分。本文结合PDCA循环对于质量改进的作用，依靠文档管理，将PDCA 理念融入软件测试。在软件测试流程中，结合PDCA 理念，各个阶段进行如此诠释，PLAN：编写测试计划；DO：按计划开展测试工作；DO：按计划开展测试工作；ACTION：维护测试文档。

　　2、PLAN：编写测试计划

　　软件测试组接到测试项目后，测试工程师首先编写《系统测试计划》，为本次测试工作做好安排。

　　根据研发部门提交的《项目总体需求说明书》《项目模块需求说明书》《项目概要设计说明书》《项目详细设计说明书》及《数据库设计说明书》等内容，测试工程师编写《系统测试计划》。测试计划中包含编写目的、参考资料、测试内容、测试环境、测试方案、测试通过标准、风险评估、测试组织和时间安排等内容，包括了PLAN中应该进行活动、控制、资源、目标等全部内容，实现了做测试工作的计划性。

　　3、DO：按计划开展测试工作

　　完成测试计划后，即按照计划的时间要求进行测试工作。

　　测试工程师依据《总体需求说明书》、《模块需求说明书》、《概要设计说明书》和《验收测试计划》分析测试需求，撰写该项目的《测试需求说明书》。软件测试的核心文件《系统测试需求说明书》是列出项目所有的测试点，保证了软件测试的有据可依。测试工程师根据《测试需求说明书》编写《测试用例》。

　　测试负责人依据《系统测试计划》及项目进度向测试工程师分配测试任务；测试工程师向测试负责人领取测试资料，执行测试。本轮测试结束后，测试工程师编写《系统测试报告》。

图1 测试设计工作流程

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿 

　　4、CHECK：审核和评审测试文档

　　审核和评审是PDCA方法中最重要的组成部分，在软件测试中主要是依靠对测试文档的审核和评审，来保证测试工作的质量。

　　《系统测试计划》是测试工作的纲领性文件，是对整个系统测试的工作安排。测试工程师完成后，需要由测试负责人进行审核，审核通过后由研发和测试人员组成的评审小组进行评审，保证了测试计划的合理性。

　　《测试需求说明书》是整个测试工作的核心文件，列出项目的所有测试点。首先由测试负责人进行审核，审核通过后组织评审，项目经理和评审小组参与进行评审，要求有测试记录。从研发和测试的角度保证了尽可能不遗漏测试点，也能有效减少测试组与研发部门的分歧。

　　《系统测试用例》是根据《测试需求说明书》的测试点扩展而来，测试工程师完成后，由测试负责人审核《系统测试用例》，并提出修改意见。

　　《系统测试报告》是每轮测试结束后，测试工程师编写《系统测试报告》，然后测试负责人审核《系统测试总结报告》。审核通过后，将《系统测试报告》交给测试负责人、项目经理、评审小组成员进行审批；审批不通过，则测试人员进行修改；审批通过，更新系统测试用例后，一轮测试结束。

图2 系统测试工作流程

　　5、ACTION：维护测试文档

　　文档《系统测试计划》和《测试需求说明书》都需要经过测试负责人的审核和评审小组的评审，《系统测试用例》要由测试负责人进行审核，《系统测试总结报告》由测试负责人审核外，还要进行项目经理、评审小组成员进行审批和会签，在此过程中，会有很多测试工程师要按照评审意见进行修改，达到了分析改进提高的效果，保证测试工作的质量。

　　6、总结：提高测试工作效率

　　将PDCA方法融入软件测试工作流程中，使得测试流程更加规范，提高了测试工作效率。编写测试计划，使得测试工作按部就班；规范的工作内容，在各个阶段都明确的产出物，方便领导对测试工作的检查；增加测试文档的评审机制，既降低测试组与研发部门沟通成本，减少分歧，又提高了软件测试的质量。

1、质量控制

　　软件质量控制对开发过程中的软件产品的质量特性进行连续的收集和反馈，通过质量管理和配置管理等机制，使软件开发过程向着既定的质量目标发展。质量控制是质量管理的的路标和动力，质量管理是质量控制的执行机制。

　　问题1：软件质量控制应该注意哪些方面？

　　建议：

　　（1）在整个软件生命周期中都该进行质量控制；

　　（2）不同阶段活动不同，应采用不同的技术；

　　（3）综合使用“预防性”和“检测性”技术。

　　问题2：软件质量控制技术有哪些类型？

　　建议：

　　（1）预防性技术：通过为过程、产品和资源设立标准等途径，来避免在产品开发过程中产生缺陷；

　　（2）检查性技术：用于发现和纠正缺陷，甚至分析产生缺陷的原因。

　　问题3：软件质量控制一般有哪些方法？

　　建议：

　　（1）目标问题度量法：通过确定软件质量目标并连续监视这些目标是否达到来控制软件质量；

　　（2）风险管理法：设别和控制软件开发过程中对软件质量危害最大的因素；

　　（3）PDCA质量控制法：PDCA是一个基于统计方法的迭代过程，已被作为国际标准。

　　问题4：软件质量控制的准则有哪些？

　　建议：

　　（1）制定明确的改进质量目标，满足客户需要；

　　（2）持续改进过程以提高质量和生产率，降低成本；

　　（3）消除恐惧，让员工更有效地工作；

　　（4）消除领域障碍，建立团队精神；

　　（5）不以口号要求零缺陷、高效率；

　　（6）进行培训，为所有人建立学习和自我提高机制。

　　2、质量目标

　　为了达到质量控制，测试团队不但需要明确软件的功能，还要明确软件应达到什么样的质量标准，即制定软件的质量目标。为了达到这些目标，在开发过程的各个阶段进行检查和评价。在质量评价时，需要有对质量进行度量的准则和方法，但更重要的是，需要在软件生存期中如何使用这些准则和方法的质量保证步骤及提高该项作业生产率的工具。

　　问题1：制定合理的质量目标需要从哪些方面考虑？

　　（1）适应性：必须制定能适应各种用户要求、软件类型和规模的质量标准，并能够度量；

　　（2）易学性：不需要特殊技术，软件技术人员人人都容易掌握；

　　（3）可靠性：对同一个软件的评价，评价的人或场合可能不同，但评价结果必须一致；

　　（4）针对性：不是在检查时才改进质量，而必须从设计阶段起就确立质量目标，在各个阶段实施落实；

　　（5）客观性：要从各种不同角度加以评价，并将评价结果定量地表示，使得人人都能理解；

　　（6）经济性：考虑如何才能把质量度量和保证所需要的费用控制在适当的范围内。

　　问题2：测试团队，需要重点关注哪些质量指标？

　　建议：

　　（1）测试设计覆盖率

　　（2）测试执行覆盖率

　　（3）各阶段缺陷密度

　　问题3：测试过程中，需要关注哪些测试缺陷密度？

　　建议：

　　（1）测试计划评审缺陷发现密度

　　（2）测试策略/方案评审缺陷发现密度

　　（3）测试用例评审缺陷发现密度

　　（4）系统测试缺陷发现密度

　　（5）集成测试缺陷发现密度

　　（6）验收测试缺陷密度

　　3、同行评审

　　在软件开发过程中邀请同行对工作产品进行审查，以图尽早查找出工作产品缺陷，进行质量控制的一种质量活动。需要前期准备、计划，安排好时间进度表，而且越早开展对项目越有价值。

　　问题1：常见的评审有哪些形式？

　　建议：

　　（1）审查：由公正的、接受过正式评审技术培训的组织者引导进行的同行检查；

　　（2）走查：又称走读，由产品的设计者或开发人员引导开发组成员和其它相关组成员浏览软件工作产品；

　　（3）分发：又称轮查，产品的设计者或开发人员将要评审的工作产品共享或分发，评审人员以修订标记或批注的方式将意见直接添加到工作产品或其复件上。

　　问题2：评审过程中常见的问题？

　　建议：

　　（1）项目进度紧张，开发人员没有时间进行评审；

　　（2）评审力度不够，评审发现的有效问题太少；

　　（3）评审会议中过多争论占用大量时间；

　　（4）评审专家与作者，或者多位评审专家之间的评审意见不一致；

　　（5）评审发现问题修改后，评审人员跟踪不充分。

　问题3：项目进度紧张，专家没有时间进行评审怎么办？

　　建议：

　　（1）将评审活动的时间、需要的评审专家写入项目计划；

　　（2）通过“正式渠道”协调评审专家资源，并得到承诺；

　　（3）评审开始前提前1-2天通知评审专家。

　　问题4：如何可以提高测试评审的效果，达到预期的效果？

　　建议：

　　（1）评审前可以使用Checklist、代码检视工具等进行自检活动；

　　（2）考虑知识结构、观点角度等方面，选择合理评审专家；

　　（3）必要时安排介绍会议，向相关专家介绍被评审对象；

　　（4）充分安排好足够预审时间。

　　4、漏测预防

　　漏测是指软件产品的缺陷在某一阶段未被发现而遗漏到了后续阶段、经效果评估后，将有效的预防措施纳入到流程或相关预防平台中，制定改进措施和跟进实施。

　　问题1：哪些环节容易发生漏测？

　　建议：

　　（1）需求分析，如需求分析遗漏、需求分析特性理解错误、需求变更未及时跟踪；

　　（2）策略漏测，如组网考虑不全面、继承特性考虑不全、性能稳定性考虑不全面；

　　（3）设计漏测，如用例描述不规范准确、用例观察点遗漏、功能交互遗漏、异常考虑不全面等；

　　（4）执行漏测，如用例执行构造数据不全面、没有严格按步骤执行用例、测试技能或经验不足等。

　　问题2：漏测分析需要做哪些工作？

　　建议：

　　（1）选择问题，选择有代表性的漏测问题；

　　（2）分析根因，进行漏测问题的根因分析；

　（3）改进实施，制定改进措施并跟进实施；

　　（4）补充测试设计，共性问题要跟踪多版本闭环；

　　（5）成果固化，经效果评估后，将有效的预防措施纳入到流程或相关预防平台中。

　　问题3：有哪些方法，可以进行漏测预防？

　　建议：

　　（1）测试策略和测试方案充分考虑各业务逻辑之间的交互和影响；

　　（2）测试用例设计时，充分考虑功能点与其他模块之间的交互和影响；

　　（3）充分考虑修改问题单、需求变更是否引入新的问题；

　　（4）参考优秀实践和经验案例；

　　（5）每次缺陷分析完要有总结，把容易漏测的形成测试经验checklist，并组织学习。

　　5、发散测试

　　发散测试，顾名思义就是不以某个标准或者框框作为约束的一种测试，发散测试准确来说应该叫具备发散思维的探索性测试。为了提高测试执行覆盖率，在严格按照用例测试执行后，通常需要进行发散测试，这里包括自由测试和交叉测试。

　　问题1：发散测试，需要关注哪些方面？

　　建议：

　　（1）重点模块和核心流程，需要安排多人进行交叉测试；

　　（2）根据2/8原则，对发现缺陷高的模块，需要重点安排人力交叉测试；

　　（3）了解用户场景，按照用户常常使用的实际场景进行发散测试；

　　（4）识别异常场景，模拟可能发生的各种异常场景进行发散测试；

　　（5）遵循规范原则，根据规范组织测试，如协议规范、设计规范和接口规范等。

　　如果你看到这篇文章了，你就有机会成为专业的了！

　　我写这篇文章并不是因为这个，其他无数的测试人员有比我更多的好东西拿来分享。总体而言，我的意思是在空闲时间阅读其他测试相关文章来提高自己的测试技能时，你也将是有志成为专业测试人员中的一分子。

　　寻找最佳理由

　　上周我在LinkedIn上看到有人讨论“为什么测试不是一份职业”，有很多答复包括说“因为大学没有专业授教”，但都是说“因为它是新兴的，人们并没有专业的进行学习”。但我没有找到有人反驳这个观点的人并说“因为大多数人工作的方式就不是专业的，才被觉得测试不是一份职业”。

　　我猜大家都注意到了给我们的责备而忙于自怜和抱怨受到的不公平。

　　寻找答案

　　坦白的讲，不管在哪我们不被当成专业人士都是因为我们并没有优先地专业化的开展工作。

　　基于我有限的工作经历，不管什么地方认真对待工作并尝试改进而给组织带来的价值的测试人员都会被尊重，并且会给予高度的评价和感谢。

　　现在切入正题，不能成为专业测试人员的10大理由：

　　1、你认为测试并不是一份技术性的职业，所以并不去尝试学习理解产品的编码

　　如果你从事的是软件开发，至少会理解一些软件工程的知识。而作为测试人员，你应该能够读懂代码来分析产品，来理解代码的变更和修复将会如何引入其他的bug.黑盒vs白盒的日子应该结束了。

　　如果你不想这样，即使不用写任何代码依然可以从事该工作。但是如果你不去读代码，将会失去对整个测试流程很重要的一项投入。

　　2、只有当开发人员告知开始测试时才真正介入到整个流程中

　　大家如实的回答，在整个开发流程中何时开展测试的？

　　理论上我们想在需求收集分析阶段就介入，和其他成员一起完成余下的，事实上我们很难投入进去，只有当开发人员想尽快得到反馈首次提交代码交付给我们时才能介入。

　　为什么要这样持续下去？大多数测试人员会说这种测试工作是开发流程中的最后一环，当其他人忙于计划时我们总是忙于测试。

　　但是实际上，如果不能每天抽两小时做测试设计就意味着你在管理时间上很差劲。而且还意味着，你不想提早介入到开发流程中的唯一原因是没有优先处理，或者换句话根本不想这么做。

　　3、只有在技术支持的同事要求重现bug时才与客户之间交流

　　测试人员一部分工作职责就是基于各种用户使用场景进行测试，一旦产品发布之后基于场景来寻找bug尤为重要。

　　但事实上（这里应该指的是外包项目中），在整个开发流程中你只是代表了客户而不是用户，根据客户的工作行为来计划测试及搭建测试环境，只是被期望基于他们的需求和限制来提供功能反馈。

　　如果真是这种情况，不了解真实的用户如何代表用户模拟他们的行为呢？最后一次访问用户如何使用产品是什么时候？工作中你能真正考虑到他们如何使用产品和工作环境有哪些限制吗？我猜答案一定是NO！

　　去拜访一些用户直到你理解他们，才不会一直做这样差劲的工作。

　4、只有在处理人寿保险时才进行风险管理

　　对于测试有一个简单的真理，也许是最微不足道的：测试人员没有足够的时间验证一切。这时，基本的风险管理派上用场了，帮助我们区分工作的优先级，哪些需要测试，哪些优先测试，可以假定哪些是基于其他测试结果上工作的。

　　但是如我所说，这只是风险管理基本的一面，更高级的是在分析跟测试压根一点关联都没有时候可以提供更大价值。

　　所有测试人员都知道产品中风险更大的区域是哪里，哪里有更多的bug，团队因为什么不定期和无计划的事务被推迟的。

　　作为测试人员我们应该意识这些区域并在项目不同的阶段实时提醒团队。这样，我们也能决定是否使用产品其他模块开发这些功能，或者考虑到这些意想不到的问题迟早都会出现，如果允许的话是否可以花更多的时间来保持系统的稳定。

　　你应该尽力尽早暴露这些影响产品的问题，不管是已知的还是潜在的，帮助团队设定靠谱的目标，在时间和预算上达成目标。

　　5、你没有任何计划来提高自己测试工作的价值

　　测试职业在许多方面都是未知的领域，有很多途径带入到测试行业，一旦进入到测试行业中，就有各种途径来改进测试专业技能。大部分测试技能提升来自于个人，而且将会由测试人员个人能力，当前工作环境的需要和限制，还有就是当前能获取的信息来源等因素决定的。

　　总之，并没有唯一的途径把自己培养成一名专业的测试人员，而且并不容易，成效并不快。所以除非你决定想真正改进开发流程，并且知道如何达到这些目的后才能够真正提高测试技能和提高能够贡献给团队的价值。

　　如何达成呢？

　　开始列出作为测试人员的强项和弱项，想想哪些方面你想改善，最终寻找可取的方法。有一件事很确定，如果你不把握机会或者跟别的测试人员的职业发展牵着一起，将永远不可能得到提高。

　　6、我们认为测试工作就是设计和运行预先定义好的测试用例

　　其实除了运行测试用例之外，还有更多的内容：

　　- 对产品设计上提供反馈；

　　- 分析当前项目计划的风险；

　　- 在不同的开发阶段提供非正式的反馈；

　　- 开发自动化框架，能帮助开发人员维持他们所开发的产品的稳定性；

　　- 运行脚本或用例，但不单单是之前预先设计好的；

　　- 分析测试结果以及能获取的所有信息，帮助我们了解产品的最新进展状况；

　　- 在流程中持续反馈

　　而且我们可以照这些步骤持续开展。

　　总之，如果只是单纯的运行用例并设置为PASS OR FAIL，那价值远远没有实现。

　7、自动化是一门高级学问，测试项目能在以后空闲时间里开展

　　请不要想出一大堆借口解释为什么不做自动化！

　　从另一个角度讲，这是一些测试人员技术弱点的另一面。

　　自动化不是灵丹妙药，并不能处理测试人员遇到的所有问题，但是通过使用脚本或工具仍然能够代替我们做一些重复的劳动，更高效，更省时。

　　问题是，一些测试人员到这里仍然感觉不够有技术含量，所以他们并不选择通过自动化或脚本改进测试。某种意义上讲，就好比使用钻木取火而拒绝用打火机并一边说这种方式很容易。

　　8、大多数时候非常自我自负的做测试

　　一个好的测试人员应该谦卑。我们需要知道如何提供反馈，更重要的是如何从其他组员或同行那获得反馈。

　　如果其他成员特别是开发人员对测试工作提供一些未经请求的反馈，或者他们查出bug遗漏或测试没有执行后，很多测试人员感到很沮丧。其实每次都有很好的理由来解释漏测，只需要冷静下来分享下这些信息，但是很多测试人员认为这是对工作失职的人身攻击，并且反驳说一些难听的话。

　　同时，我们需要知道如何提交bug，并为团队提供消极的反馈，并且需要知道如何从同行那获得建设性的批评。

　　没人期望你是完美的。但是他们期望你能认真对待失误并且同时从获得的反馈中学到经验教训。

　　9、并没有跟进需要改进提升的技能或领域

　　之前我其中一个最好的经理经常谈论我们个人的“虚拟工具箱”，好比我们所携带的技能在需要的时候随时可以使用。

　　在你的工具箱里都有哪些？

　　哪些工具需要改进或更新了？

　　哪些是你需要的，哪些是下一步想要获得的？

　　不容置疑，测试像是一门手艺，没有合适的工具不能创造需要的产品。

　　10、你的职业发展生涯就是成为管理人员或改行

　　有些人转行是因为他们觉得做测试是种很好的途径转做开发，还有部分人根本不知道测试是干什么的，甚至是因为觉得整体玩弄这些程序很好玩。毕竟，也难不到哪里去。

　　一部分人最终成了很棒的测试人员，但是多数人最后失意收场，度日如年的盼着啥时候能结束测试生涯，可以做自己想做的工作，而另外的人并不欣赏测试所带来的挑战，他们觉得唯一获得进步的就是做管理。

　　没错，做管理的确也有挑战和收获。但是不做管理也是要克服无数的问题，这些也许能给予你更大的挑战和收获（绝对还没那么头疼）。

　　我的观点是，如果你一直在想做其他的而不能关注于做一名更好的测试人员，根本不可能做的更专业。所以想想是否入对了行或者可能应该简单地摸索点别的。

　　想成为专业？首先作一个专业的测试！

　　总结上面10点，贯穿始终的是如何改变我们对测试的认知。

　　第一步就是把测试当成你的职业！

　　当我们做到了第一步，第二步就是看看哪些我们遗漏了，哪些我们需要加强，我们要怎么开展工作以及如何与同事及客户处理好关系，以及为了提高我们的价值现在能做什么。

　　第三步是我们应该未雨绸缪，并且意识到作为一种职业在变成大师或专家之前有很多东西需要学习。

　　最重要的是要意识到这种改变要发自肺腑有实际行动，而不是从一些神赐予的法令而来，或者邮件所署名字旁边的标题来证明。

百度测试架构师眼中的百度QA（一）  《转载》

发表于2013-04-09 15:31| 4004次阅读| 来源架构师Jack的个人空间| 13 条评论| 作者董杰

百度测试QA

摘要：一直以来百度质量部在业界都比较低调，外部同行鲜能了解百度QA的工作流程，以及如何应对互联网研发节奏和质量的平衡。为此，百度测试架构师董杰在博客中分享了百度QA的四大核心价值，帮助理解全程软件测试的意义。

从组织结构上百度所有的QA都归属于一个大部门百度质量部统一管理，在一个大部门下的好处是很容易一起跨产品线的协同作战，各种测试技术和测试工具能以最快的速度得到传播，避免重复造轮子的浪费。同时QA们能有一种更强的组织归属感、有着专业的发展通道与空间、关键能交到更多在QA领域与自己志同道合的朋友，扩展视野，所有QA都能从这种大资源池中获益。这一点对所有做测试的人而言更有利于测试专业技能的持续提升。

从我工作所见和感受来看，百度QA有四个主要的工作挑战：职责范围广（覆盖完整的产品生命周期全流程）、 面对产品技术新（如移动互联网、WebOS、推荐引擎）、研发速度快（互联网的节奏）、大数据系统的复杂（百度本质是一个分析处理数据的公司）。这些挑战长期影响着QA日常的工作方式，使得与传统的tester有着工作模式的不同。

百度QA的工作范围覆盖了百度所有形态的产品从基础架构的分布式系统、搜索架构系统、到搜索算法、Web前端、Windows客户端、手机客户端，以及最新的多媒体技术、机器学习等这些前沿的IT业务，因此在这里我能最广泛的接触到各领域测试的QA同行，听听他们的分享，扩展我的测试视野。当然我也有机会到各领域进行测试实战，从我到百度算起，我已在web前端、windows客户端、手机客户端、搜索架构系统、搜索算法、图片搜索领域进行了各种测试实践工作，大大丰富和完善了我的测试技术知识体系，受益不少。

另外百度QA会更完整参与到产品研发流程的周期，从最早的MRD，到设计评审、到产品发布后的效果评测是端到端的参与完整的产品生命周期。与我过去经历最大的区别在于，QA与PM（产品经理）打交道的时间非常多，在整个产品生命周期中几乎是同步一起从头到尾密切配合，同时QA还会为PM设计并开发用于产品评测的平台对产品设计的影响会更多。对于QA与RD的关系，QA不仅只是响应RD提交代码的测试，还会主动去帮助RD如何更好地做好UT（单元测试）、如何做好code review。

基于百度QA职责范围的扩大，在百度QA工程师的职责和发展路线上目前来看已大致分为QAD和QAT，至少我在进行职称评定的评审时，已会有意识的区别评估。QAD就是QA中的软件开发者更多侧重测试工具和测试系统的软件开发，我在参加QAD任职评审1对2活动时，基本是以一个对软件开发者和软件产品设计者的角度来进行review，关注其代码质量、软件架构设计思路和产品设计思路的能力。QAT则是标准的Tester，偏重如何尽早的发现更多软件质量问题，要求精通产品的应用场景以及各种测试类型。

因此各种风格和兴趣的QA都可以在百度找到自己希望和喜欢的角色，当然有时QAT和QAD也会互换，我个人而言，认为相对而言QAT转QAD容易，QAD转QAT要难些，因为百度的QAT大多具备一定的软件开发能力，平时也会根据工作需求自己做一些自动化测试开发和工具开发的工作。而QAD要转QAT则还需要补充多种测试类型的知识技能，以及产品的业务知识。

我在这里目前算是QAT路线，大多时间在思考如何设计更完整的测试避免问题遗漏，以及如何让测试人员在短时间内发现更多的深层次问题，当没有QAD资源来帮助你时，也会自己设计与实现一些小规模的测试系统或测试工具。如果未来某天我的兴趣转换到了QAD的工作内容了也是比较容易获得机会转换的。所以当QA工作的平台足够大时，个人的兴趣也会得到最大化的满足。

在日常的工作中，很多百度QA常常还会面对很多新产品技术的挑战，这里的“新”是指新形态的互联网产品（机器学习、推荐系统、多媒体搜索）以及新的软件应用场景（移动互联网和Webos），这些新的被测对象所带来的直接挑战主要是业界很难有现成的完整的测试方案及测试技术，于是不得不逼迫百度的QA比传统软件测试的Tester更加持续地进行测试技术的创新才能满足“新”产品的质保需求。例如：我今年参加的整个百度质量部层面的移动互联网测试技术专项topic组的工作，就不得不去填补诸多业界在移动APP稳定性测试领域、性能测试领域、自动化测试领域技术的空白，否则无法达到真正对高质量用户体验的追求。

当业界大多数APP的稳定性测试只依赖Monkey测试工具时，Monkey测试已只占百度最新APP稳定性测试用例类型不到10％的覆盖面，其他90％的稳定性测试方法大多是业界还未知但APP应用又必须要考虑的，否则就会出现“为什么用户会碰到而我无法重现的问题”。

当业界还靠移动机型穷尽进行兼容性crash问题的覆盖时，百度的QA已设计实现了基于静态代码自动扫描的兼容性crash问题的快速测试。当很多QA还在为如何在不稳定的2G网络下得到稳定的测试结果而苦恼时，百度QA已靠不到1000元的低成本技术方案很好地解决该问题。同时在完善移动APP测试方案的过程中QA内部还设计开发了不少APP测试工具填补了业界在移动APP测试领域的很多空白。

经过我对内部信息的了解，之前官方对外宣传较多的移动云测试MTC只代表了百度QA在移动互联网领域测试技术积累的一部分而不是全部。所以我希望下一步有机会百度质量部能逐渐给业界分享出来，让大家都能受益从而减少移动互联网测试的烦恼和困难。

据我在百度的观察我个人总结了一个规律：中国人并不缺创新能力，而是缺逼迫自己去持续创新的压力和平台。正是由于百度QA所处的工作环境和测试对象的特点，逼迫他们不得不去创新，结果QA个人的创新能力在不断提升并形成了创新的习惯。我在这样的环境下，一年下来自己的创新效率感觉比以前也提升了一倍以上，发现原来测试很多领域都有着创新的可能与空间。有朋友问我在百度累吗？我说相比过去身体不累但脑子累因为经常都在思考如何创新地解决所遇到的各种没有现成方案的测试问题。

曾有多位互联网的测试友人网上问我：“百度是如何进行面向互联网的快速测试的？”对于这个问题，我最大的感受是互联网研发速度与质量的平衡让百度的QA必须持续通过测试技术的改进来实现该目标，靠智慧的测试而不是加班来同时满足进度与质量的需求。为了满足这些需求百度质量部有大型测试平台如百度TIP(Test in production)系统、百度众测平台、百度MTC、分布式并行自动化测试等支持大多数产品组同时获得研发速度加快和研发质量提升的收益。

我个人认为百度TIP应该是国内在beta测试领域做得非常智能和系统的beta测试系统，可大大提升beta测试的效率和质量。而百度众测平台则是国内第一个也是规模最大的众测社区，依靠互联网上的热心用户资源帮助产品尽早发现更多用户场景特有的问题，减少了百度QA测试时间资源和测试物料的投入，值得国内各公司借鉴。如何更好地把用户吸引进来参与beta测试，花点钱是必须的，空手套白狼是不可能的，但是投入产出比是值得的。百度移动云测试MTC平台则通过对已有测试物料和测试资源的共享管理及自动化应用帮助各产品APP测试缩短了在兼容性测试领域和性能测试领域的测试时间，并且让各产品APP获得更广的测试覆盖从而获得更高质量的APP。

除了这些公司级的测试平台帮助各产品QA加快测试速度外，在日常的测试工作中一线百度QA还会主动积极学习和广泛地应用业界优秀的测试技术：持续集成、code review实践、静态代码自动测试工具、环境一键搭建、监控系统、分布式并行测试、探索测试等都在大多数产品组普及落地，希望靠先进的技术手段生产力来提升测试效率，缩短研发测试周期。

据我所知百度质量部的探索测试在国内应该是应用产品范围最广的，从windows客户端、移动APP、web产品都在例行应用，探索测试几乎覆盖百度所有产品线，应用和实施探索测试的QA数达到上百人以上，涌现出不少内部探索测试教练，实施了探索测试的产品在没有增加测试周期和测试人力的前提下能提前发现更多问题减少漏测，部分产品探索测试发现的问题数所占比例已达30％以上，提升了发现单个缺陷的测试效率。

我个人认为对比靠延长工作时间和减少必做测试类型来加快研发速度的做法，靠主动持续应用各种新测试技术实践和成果是一种更可持久更科学更人性化的做法。关于百度如何进行“快测试”的咨询，我想这里已给出了一个已验证的解决方案了，希望值得各位同行借鉴和思考。

对于当前很热门的“大数据”及大数据如何测试？我觉得百度有些实践值得大家了解，给大家一些大数据测试的启发思路。

 因为百度天生就是一个大数据公司，百度大数据系统的复杂度很高导致一直要求百度的QA既要保证高负载数据处理系统的稳定性、还要挖掘大数据中的badcase，尤其要擅长算法的测试。在保障高负载数据处理系统的稳定性领域，既有“线下百度”这样集系统化的稳定性测试方案与监控系统为一体的专项测试系统，也有不少申请了专利的可靠性测试工具来解决稳定性测试中异常构造和测试流量构造的问题。同时几乎所有产品线都通过百度的大型后台系统的稳定性测试实战培养起了该领域的测试高手。

当然我也受益于百度的稳定性测试工作，通过为某百度第二大流量的产品进行稳定性测试方案的改进，在这里真正地把我过去在可靠性测试、压力测试、长时间测试领域的经验系统地结合起来形成了我自己完善的稳定性测试模型，并通过大数据处理系统的测试应用检验了我的稳定性测试模型的完整性，确保有各种测试方法可提前发现所有可产生稳定性问题的风险。

另外为了更好地对大数据时代的数据挖掘和推荐效果算法进行效果评估，而不仅仅只是进行新算法程序正确性验证，百度的QA们还积极应用机器学习的思想、算法和工具对诸多产品的推荐效果算法进行产品算法集有效性的自动化评测，各产品线QA们设计的badcasse自动化挖掘系统在很多产品都能达到85％－95％的准确性，提供大量的量化数据帮助产品的算法设计者重新优化算法，而不只是修改算法的程序bug。

同时为了更早更快更准地体现算法效果测试的价值，有的QA还积极进行该领域的其他创新，诸如：网页搜索的QA把badcase自动化挖掘系统与百度众测结合后大大减少了研发人员大规模分析与定位badcase的成本。图片搜索的QA甚至实现了线下badcase自动挖掘的算法，突破了搜索业界传统依靠线上用户数据进行用户体验测试的限制，能在大数据产品上线前未获得用户数据前就提前自动发现大量的badcase数据，为用户提供更好的推荐结果。大数据领域的测试涉及很多，由于我个人所见有限，就先给大家分享到这里。

如果非要我用一句话来总结百度QA的特点那就是：“持续技术创新与积极学习”。

平时在微博上测试同行们常讨论QA的核心价值是什么，甚至常有开发领域的老兵也来参与辩论。当然在百度内部也会有关于QA核心价值的讨论，从我了解的情况来看百度QA的核心价值在内部已得到了一些共识和不可替代性的证明。

百度QA的第一个核心价值是：全流程质量保障中心

全流程质量保证确保所有百度产品的程序质量。从需求/设计/编码/产品发布的全流程都会有QA介入并提供各类质量保障手段。从尽早发现问题，到缺陷预防，到减少发布后遗漏问题的影响都是百度QA投入和支撑的目标。

百度产品的全生命周期的质量保障是百度QA的首要工作目标，也是在百度不可或缺的核心价值，大部分的QA都一直为将漏测率降低到千分之几，甚至是零漏测长期进行着持续的测试创新和技术改进工作。

百度QA的第二个核心价值是：公司用户体验测试技术能力中心

前面所介绍的百度QA的工作范围和工作目标不只是传统tester所涉及的内容，他们被要求不仅要发现程序的错误，还要发现产品效果的问题，要求对用户体验质量全面负责。所以，百度QA除了广泛应用各种软件测试技术帮RD找bug还会积极进行产品的应用效果评测工作为PM提供用户体验方面的缺陷，badcase自动化挖掘系统、百度众测平台等都是这方面的典型代表。我觉得从这点来看百度QA的用户体验定义的覆盖含义远超过了很多人所认知的易用性感受。

百度QA不只关心程序错误这一点突破了许多公司目前对tester的限定，因此我建议各公司的tester们应该更积极主动的行动起来，在公司内部开展对产品业务有效性的评测而不仅是正确性的评测，因为只有这样才是真正的产品测试，而不仅是软件测试，测试者的价值能够获得更多的体现。

百度QA的第三个核心价值是：公司研发效率提升能力中心

百度QA们从最开始关注如何提升测试过程的效率，到现在考虑如何通过提供研发辅助工具和流程改造，提升公司整体的研发效率。我看到的是除了百度质量部层面的质量工程中心、还有产品线层面的EP专职团队、以及分布在各产品组的QA们都在积极贡献各种提升测试效率和开发效率的工具及系统。百度TIP系统、持续集成等是研发流程层面的典型代表，分布式并行测试系统、各种代码自动扫描工具等是测试效率提升的典型代表，提供给UE的单测工具FIS、提供给RD的UT技术支持服务则是研发效率能力提升的另一种形式。我认为在研发效率提升方面，百度的QA们担负起了最大的职责和贡献了最大的价值。因此各公司的tester们如果要跳出测试价值的狭义定义，可以考虑参考百度QA的工作模式，积极担负起公司研发效率提升的担子。

百度QA的第四个核心价值是：百度技术部的人才“黄埔军校"

在很多公司测试部或质量部都是向各部门培养人才的输送部门，这是因为测试工作的综合性让很多测试者获了全面的锻炼。成为一个懂技术的产品经理，成为一个懂质量的研发人员都是测试人员转岗的优势。

不过在百度我看到这里的QA在质量部内部得到了更多综合性的锻炼，不依靠转岗也能在质量部内部专注做产品研发、做产品经理。因为有的QA团队本身就在做产品，承受着做产品的质量标准压力，如百度移动云MTC本身就是百度移动云战略产品的一部分，百度众测也是一个完整的互联网产品，QA们在其中担任起了互联网产品经理，互联网产品运营，互联网产品研发角色，能参与这些项目的QA是比较幸运的，这些经历对他们未来的发展都是一次很全面的锻炼。同时前面谈到QA从MRD到产品发布后的全程介入工作，也使得QA能掌握大多数PM的技能和更深入的了解产品的完整生命周期成为“半个PM”。

因此QA的发展空间和路径是很广阔的，关键看自己在公司内部如何去推动，如何去影响周边团队，让自己的工作范围扩大的更多。没有人说“你不能做什么？”只有自己内心限制了自己“不能做什么”。从这点来看，百度的QA玩得还挺“风生水起”的，希望国内其他公司的测试人员们能跳出原有思路，扩大自己的影响范围。

原文链接：上半部分   下半部分

思科-网迅（中国）软件有限公司资深QA总监朱少明点评道：

第一篇的下半部分更精彩，谈到了百度QA的四大核心价值：全流程质量保障中心、用户体验测试技术能力中心、研发效率提升能力中心和人才中心。使大家更深刻理解全程软件测试的意义，软件测试=软件产品的测试，软件测试不是成本中心，它可以提高软件开发生产力。期待更具体的分享。

百度测试团队这几年增加比较快，希望将来能看到百度分享一些移动测试方面、专业性很强的文章。