事情的起因是这样的：
上周三下午要出去打个电话，经过小会议室门口的时候测试负责人叫住我问有事吗？小A做的性能测试出现了点问，要我帮忙分析一下。打完电话后到小会议室与小A、测试负责人一起看小A的性能测试出现了什么问题。小A说她对X项目进行了性能测试，但是结果与现在线上的差距特别大，线上入库是10条/秒，而她测试的结果是3-4条/秒，对于她测试得出来的结果项目的负责人很不认同，认为是她做错了，而她又找不出来问题出在哪，她很郁闷。
接下来是我们的一段对话
我：小A，你说一下这次性能测试，是对哪几个点做的，场景都是啥样的？
小A：主要是两个点，一个是单一场景针对短信入库的，场景设计的是30、50、100条数据并发持续2个小时，是根据线上前段时间出现的问题发3万条短信，结果处理的时间特别长这个问题设计的；另外一个是将接收到的不同类型的短信入库，是个混合场景，场景是短信2条、彩信1条、WAPPUSH1条、EMN1条，这些数据并发，持续2个小时。
我：问一下，线上对于短信发送真实操作场景是什么样子的呢？
小A：这个我不知道啊，反正我只知道现在线上要求1个小时内必须把这些短信发完，线上现在预计的入库量是10条/秒。
我：好吧，换个问法，X系统小A你最熟了，线上的这个问题，有大量的数据过来，X系统 对这些数据是怎样处理然后入库的呢，是一批一批的处理，还是一条一条的处理呢，如果是一批一批的处理，对于这一批数据是怎样处理的呢，是同时处理掉，还是一条一条的数据。
小A：这个我不清楚，要不一会儿我去问一下开发的吧。
我：我再问一下，现在搭建的这套测试环境，各个机器的配置是怎么样的？和线网的机器配置差距有多大？线网的带宽是多少？现在测试环境的带宽是多少？线网是有负载均衡的，有VPN通道的，测试环境上有这些吗？
小A：tomcat的机器是一台服务器，4核的，另外两台数据库还有LR加压机都是实体机。线网的机器配置我不知道，测试环境也是100兆带宽，负载均衡啥的测试环境都做不了。
我：线网带宽是千兆的，测试环境的百兆带宽不全是给你来测试用的，公司上班时间所有同事办公还占用一部分带宽呢。线网的数据库做过一次优化的，有几个参数是调整过的。
我觉得这次问题的分析可以从几个方面来入手查，第一，场景设计，我从开发的那里了解到线上真实的情况是没有并发的，只是一条一条的来处理，处理的数据量是3万条，1个小时处理完，是我们自己的要求。所以场景可以重新设计，设计成没有并发，处理3万条数据；第二，测试脚本的性能，测试脚本里的代码可能本身响应时间就长；第三，机器配置、网络带宽，查看现在测试机的配置与线网比相差多少，这些能不能想办法进行一下换算，结果可能有误差，如果找到依据，看看误差能控制在多少范围内。
小A：我觉得脚本代码不是问题，我就是这样写的都能执行过去，能执行过去为啥就会有问题呢。线上真实的操作那在那台服务器上还可能有别的省发短信呢，对那台服务器还有影响呢，那台服务器的配置好可能还有别的省来占用呢，所以机器配置也不应该是问题。带宽我觉得也不是问题，公司百兆的带宽也够用了呀，我在测试的时候也没发现网络上哪里出现了问题，CPU占用率呀都非常少的。
我：......无语
对于性能测试，到底应该怎样做，会用了工具（最著名的是LR）就会了性能测试了吗？NO，NO，NO
我认为：
前期分析：
分析业务：分析用户群，业务真实使用和操作情况。比如在哪个时间段哪个操作会多，哪个操作会少，怎样来操作，是会有很多人一起对系统发起请求呢（所谓的并发），还是数据量很大，但是都是一个请求一个请求过来的，很持续很长时间吗（比如8个小时都在做这样的操作），还是主要是对一定的数据量操作的（比如处理完几十万条数据后任务就完成了），每次只有一个场景吗，还是是个混合场景都有，如果是混合场景，那么各个场景的比例大约是多少呢。线上已经有多少数据量了？预期要达到多少数据量？
分析环境：线上系统环境是什么样子的？有负载均衡吗？有多次转发吗？......机器配置是什么样子的，每台机器上都有哪些服务？线网的带宽是多少？是专用的吗？搭建的测试环境和线网真实的环境有多大的差距，带宽是多少，是专用的吗？测试环境不可能与线网环境是一模一样的，有办法换算吗？误差大约是多少？
分析团队成员：给你配备的配合的开发人员了吗？与你配合的开发人员靠谱吗？你的团队里有性能测试的高手吗？团队对这个项目的性能测试支持吗？
时间分析：测试的时间充足吗？哪些是必须测的，哪些是可以不测的。
测试执行：
有了前面的详细的分析之后，才能整理出测试需求、设计测试方案、编写测试用例、编写测试脚本、设计出合理的测试场景，才能执行测试。
结果分析：
测试出了结果，不能就算完事了，把结果丢给别人让别人分析查找原因，那不是高手，真正的高手是可以分析出问题在哪里，是什么原因产生的，怎样优化。简单的几个切入点可能从服务器系统CPU、内存等等，数据库中SQL执行速度，数据库CPU、内存等入手。查看事务平均响应时间是否在可控范围内，每秒处理的事务数怎样等等。借用一些工具查看操作数据库的SQL执行情况等等。
总结一下，性能测试个人认为最重要的不是使用工具，而是测试前的分析和结果的分析，前面的分析够透彻才能保证后面做的是对的，而不是一上来就是用工具，就大并发，只有大量的并发才是性能测试，一定得根据现实的真实使用情况来做才可以，违背了现实做再多也是无用。每次一听到有开发的对我讲你帮我们做一下性能测试吧，弄个几万的压一下，我就特无语。
第一：return语句并不是函数的最终出口，如果有finally语句，这在return之后还会执行finally（return的值会暂存在栈里面，等待finally执行后再返回）
第二：finally里面不建议放return语句，根据需要，return语句可以放在try和catch里面和函数的最后。可行的做法有四：
1、return语句只在函数最后出现一次。
2、return语句仅在try和catch里面都出现。
3、return语句仅在try和函数的最后都出现。
4、return语句仅在catch和函数的最后都出现。
注意，除此之外的其他做法都是不可行的，编译器会报错。
（1）如果程序运行到try成功时可以返回结果，则采用方法2。（见下面的例子test0_1，在那个例子中，方法2和4都是可行的，但是推荐方法2？）
（2）如果程序运行到catch时（即中途出错时）无需再继续执行后面的代码了，则采取方法4；（见下面例子中的test0，在那个特殊的例子中，只能采取方法4）
（3）如果程序运行到try或catch时还需要继续执行后面的代码，则采取方法1（见下面的例子test0_2，该例子只能采用方法1）。
下面是测试代码：
public class Test { public static void main(String[] args) {
System.out.println("=============test1==================");
System.out.println(test1());
System.out.println("==============================="); System.out.println("=============test1_1==================");
System.out.println(test1_1());
System.out.println("==============================="); System.out.println("\n============test2===================");
System.out.println(test2());
System.out.println("==============================="); System.out.println("\n============test2_1===================");
System.out.println(test2_1());
System.out.println("==============================="); System.out.println("\n============test3===================");
System.out.println(test3());
System.out.println("==============================="); System.out.println("\n============test3_1===================");
System.out.println(test3_1());
System.out.println("===============================");
} public static String test0() {
String a;
int b;
try{
b = 8/0;
}catch(Exception e){
return null;
}
a = String.valueOf(b);
return a+b;
}
public static String test0_1() {
String a;
int b;
try{
b = 8/0;
a = String.valueOf(b);
return a+b;
}catch(Exception e){
return null;
}
//return a+b;
}
public static String test0_2() {
String a;
int b=0;
try{
b = 8/0;
}catch(Exception e){
}
a = String.valueOf(b);
return a;
}
public static String test1() {
String a = "in try";
int n = -1;
try{
return a+n; //先执行这个，再执行finally
} catch ( Exception e ) { } finally {
//对String和int的更改均无效
a = "in finally";
n = 123;
System.out.println("do finally");
}
return a; //不会执行
} //总结出一点：return语句并不是函数的最终出口，如果有finally语句，这在return之后还会执行finally public static String test1_1() {
String a = "in try"; try{
return a;
} catch ( Exception e ) { } finally { //从eclpise报警告可看出，finally里面不建议有return语句
a = "in finally";
System.out.println("do finally");
return a; //注释掉这句，eclipse将不再警告
}
} public static int test2() {
int a = 1; try{
return a;
} catch ( Exception e ) { } finally {
a = 2;
System.out.println("do finally");
} return a;
} //很显然，finally里面更改无效，返回的是a=1 public static int test2_1() {
int a = 1; try{
return a;
} catch ( Exception e ) { } finally {
a = 2;
System.out.println("do finally");
return a;
}
} //很显然，a取finally里面的值，a=2 //Helper类，将整数转换成字符串
static class Helper {
int a; public String toString() {
return String.valueOf(a);
}
}
public static Helper test3() {
Helper h = new Helper();
h.a = 1; try{
return h;
} catch ( Exception e ) { } finally {
h.a = 2; //对h.a的更改起作用!!
//因为在try里面返回的是一个句柄，它指向的对象的内容 是可以改变的
System.out.println("do finally");
}
return h; //这个不会被执行
} public static Helper test3_1() {
Helper h = new Helper();
h.a = 1; try{
return h;
} catch ( Exception e ) { } finally {
h.a = 2; //返回a=2，这个不用说了
System.out.println("do finally");
return h;
}
}
/**
* 总结：
* return语句，finally里面不建议放return语句，根据需要，可以放在try和catch里面
*
*/
}
|
简介
同是企业WEB应用程序项目，一个用敏捷，一个用瀑布流程，它们的测试策略会有何不同？在二者中，测试的关注点都在于告诉业务客户这个应用程序做了哪些事情，同样也要消除应用程序作为产品交付以后的失败风险。它们的主要区别不是测试本身，而是何时执行测试、由谁执行测试。测试的每个阶段都可以在系统就绪后随时开始，无须等待前一个测试阶段完成。
从未涉足敏捷项目，或是刚启动某个敏捷项目并在寻找指导建议的读者都可以看看这篇文章，它正是为你们而写。文中的信息虽并非笔者新创，但也是收集整理的结果，希望这些信息能帮助你们朝着更为敏捷的过程迈进。
敏捷项目的测试阶段跟瀑布项目的测试阶段几乎毫无二致。每个阶段都有准出标准，但是在进入某个测试阶段之前，是不需要等待整个应用程序完成的。只要应用程序所完成的部分足以进入下一个测试阶段就行。因为测试的对象是一个已完成的功能，而不是一个发布，所以测试阶段是在持续并行进行的。于是就有了一大堆回归测试。这便也意味着回归测试是测试自动化的基础。对于敏捷项目而言，环境与资源也是要注意的地方，因为对测试环境的需求会来得更早、更加频繁。
“快速失败”是敏捷项目的一句格言，它的含义是尽可能早地判断出应用程序无法满足业务需求。要做到这一点，就需要不断地对解决方案是否满足业务需求进行检测，一旦不满足，就要尽早把问题解决。敏捷团队成员-开发人员、测试人员、架构师、业务分析师以及业务代表等人都关注于尽早交付业务价值。所以，测试需要所有团队成员协力来做， 它不仅仅是测试人员的责任。
测试分类
敏捷项目跟瀑布项目的测试分类几乎是一样的。其差别主要在于大部分精力投入的地方和每个测试阶段所执行的时机。敏捷项目倾力关注单元测试和功能测试，从而为稍后执行的测试阶段创造出高质量的代码，于是后期就不会发现本应在早期发现的缺陷，并能专注于所需要测试的领域。而瀑布项目就有一个常见的问题，后期测试的焦点总是放在找出本来应该在前期发现的缺陷身上。于是修复缺陷的成本提高了，测试工作的投入翻番了，测试的关注点也偏离了。
瀑布项目和敏捷项目另外一个巨大的不同在于测试自动化。敏捷项目力求在所有测试领域内都达到100%自动化。测试跟持续构建系统集成在一起，于是当代码发生变化时，这个变化会被自动检测到，应用程序被构建起来，然后所有的测试都会被执行。
测试驱动开发（TDD）在敏捷项目中很常用，用这种方法的时候，测试用例比代码要先一步创建。于是我们就可以越来越多地看到为代码和功能创建的测试用例。用自动化测试来驱动开发，然后消除重复，这种做法可以保证无论复杂度多高，任何开发者都可以写出可靠的、没有bug的代码。TDD常用的地方是单元测试，但也同样可以用于功能测试、集成测试、用户验收测试和性能测试。
单元测试
单元测试又称白盒测试，它要测试所开发出来的每一个模块。瀑布项目不关注这个测试阶段，而且大多数时候即便有的话也是随意为之。敏捷项目强调单元测试，而且会把所有单元测试都自动化。自动化的单元测试是敏捷项目的基础，对持续集成和重构起辅助作用。
单元测试应当考虑以下几点：
1、用stub和mock来消除对外部接口的依赖。
2、由创建代码的开发人员编写单元测试。
3、单元测试要能自动化执行，而且要被包含在持续开发构建中。
4、单元测试之间不能有依赖，让每一个单元测试都能独立执行。
5、任何开发人员都要能在他自己的机器上执行单元测试。
6、用代码覆盖率来判断哪些部分的代码没有被单元测试覆盖。
7、在检入代码的修改之前，要保证单元测试100%通过。
任何测试失败都表示构建失败。
功能测试
功能测试常常跟系统测试相关联，它的重点是测试应用程序的功能（包括负面测试和边界条件）。在瀑布项目中，测试团队一般是在这个阶段开始测试工作。测试团队的成员会一直等下去，直到开发者完成了所有的功能，并通过所有的单元测试之后才进入功能测试阶段。 敏捷项目把功能拆分成故事，每次迭代开发一定数量的故事。每个故事都有一些验收标准，这些标准一般都是由业务分析师和测试分析师制定的，它们也可以看作跟测试条件类似。测试分析师会根据验收标准创建测试用例，用它们来检测代码行为的完成程度。故事一旦编码完成，而且单元测试运行通过以后，就可以运行功能测试来判断是否满足验收标准了。这就意味着在敏捷项目中，只要第一块功能已经完成编码，功能测试就可以启动，而且会贯穿整个项目的生命周期。
功能测试应当考虑以下几点
1、要能自动化执行，并且进入持续构建（如果测试运行时间很多长，也可以只在开发持续构建中包含一小部分精挑细选的功能测试，而在系统集成持续构建中包含全部功能测试）。
2、在编码之前写下测试意图，代码完成后对测试进行实现。
3、把通过所有功能测试作为故事完成的条件。
4、在应用程序安装到另外一个环境（如试机环境或产品环境）上的时候需要执行功能测试。
任何测试失败都表示构建失败。
探索性测试
探索性测试又称为随机测试。瀑布项目在它们的测试策略中没有这种测试类型，不过大多数测试人员都会多少做一些探索性测试。在敏捷项目中这是个很关键的测试阶段，因为它可以用来检测自动化测试的覆盖率，并收集对于应用程序质量的反馈。它为测试人员和业务分析师提供了一种结构化的方式去使用、去探索系统，从而找到缺陷。如果探索性测试在某个功能区域内找到了大量缺陷，那这部分的自动化测试用例就要被审核。
探索性测试应当考虑以下几点：
1、在系统集成环境中执行。
2、在较高的层次上监测探索性测试活动。
3、用自动化的环境设置方式来减少搭建环境的时间。
4、将破坏性测试作为探索性测试的一部分。
集成测试
应用程序在作为产品部署的时候，需要各个部分的协作；集成测试就是把这各个独立的部分集成起来进行测试。瀑布项目不但会把应用程序的各个独立模块进行集成，还会把那些虽然不属于项目的一部分，但是要开发当前应用程序就必须用到的一些应用程序也做集成。在敏捷项目中，独立模块间的集成是被持续构建所覆盖的，所以集成测试的关注点就是那些不属于当前项目的外部接口。
集成测试应当考虑以下几点
1、在执行集成测试的时候，需要考虑到当前迭代还没有开发的功能。
2、写一些集成测试来定位特殊的集成点，以协助代码调试，即便功能测试会调用到这些集成点也无妨。
3、将集成测试自动化，放到系统集成持续构建中。
任何测试失败都表示构建失败。
数据验证
如果项目需要移植既有数据的话，就要进行数据验证。它可以保证现有的数据被正确地移植到新的Schema中，新的数据被添加进来，旧的数据被移除。这种类型的测试在瀑布项目和敏捷项目中是被同等对待的，除了敏捷项目会尽力把它自动以外。
数据验证应该考虑以下几点：
1、在系统集成环境、试机环境和产品环境中都要执行。
2、尽可能地自动化。
3、要把测试放到系统集成持续构建中。
任何测试失败都表示构建失败。
用户验收测试（UAT）
UAT关注的是完整的业务过程，它用来确保应用程序能按照业务的处理方式工作并能满足业务需求。它同样还要从客户、消费者、管理员等各种用户的角度出发考虑应用程序的可用性。在瀑布项目中，这个阶段通常就被用来找出应该在早期阶段就被发现的bug。业务人员也会在这个阶段验证开发团队交付的应用程序的质量。敏捷项目用UAT来确保应用程序满足业务需求，因为等到进入这个测试阶段的时候，代码质量已经较高了。在敏捷项目中，业务人员从早期的测试阶段就开始参与，所以他们对交付的东西有更多的信心。
UAT应该考虑以下几点：
1、首先进行手工测试，等它验证了系统行为以后再把它自动化。
2、把自动化测试放到系统集成持续构建中
3、让应用程序的最终用户亲自将整个程序运行一遍，不过项目的测试人员要在旁边协助。
4、在试机环境下执行UAT， 用作验收。
5、只要完成了一个业务过程或者一个主要的UI组件，就要执行UAT。
任何测试失败都表示构建失败。
性能测试
性能测试涵盖的范围比较大，不过一般可以分成以下三类。
1、容量测试：独立测试核心功能组件的容量。例如， 可以支持多个用户并发检索？一秒种能做多少次？等等。容量测试被用来精确度量系统的极限，还可以对容量规划和系统的扩展性起辅助作用。
2、负载测试：侧重于系统在负载下的表现。负载应该要体现出用户所期望系统可以经受得住的流量。
3、压力测试：关注系统在压力下的表现。比较常用的技术是浸泡测试（soak test）；在浸泡测试中，系统会在一定的负载下持续运行一段时间，用来找出长期问题，如内存泄漏、资源泄漏等。压力测试还会覆盖故障转移和恢复，例如正在工作的集群中的一台服务器出现问题，检查是否可以做到故障转移和恢复。
瀑布项目直到项目接近尾声的时候才做性能测试，这个时候应用程序已经“完成了”开发，通过单元测试和功能测试。而敏捷项目则会尽快启动性能测试。
性能测试应该考虑以下几点：
1、在功能测试中设置一些性能度量，例如一个测试第一次运行要花多长时间，接下来每次又要花多久，把这些时间所占的百分比做一下比较（上升表示有问题，下降表示良好）
2、把一些性能测试放到系统集成持续构建中去做。
3、一旦一个业务过程，或是某个规模比较大的功能或接口完工，就要做性能测试。
4、只有在试机环境中运行的时候才签收性能测试。
任何测试失败都表示构建失败。
非功能性测试
非功能性测试所涵盖的范围很广，性能测试通常也属于这个话题。但是因为性能测试是企业解决方案中很重要的一部分，而且需要不同的资源和技能集，所以就被划出来单独成为一个测试阶段。非功能性测试一般都包含有这些内容：可操作性（包括监控、日志、审计/历史记录）、可靠性（包括故障转移，单个组件故障，完整故障，接口故障）以及安全性。无论瀑布项目还是敏捷项目，在这个测试阶段都会遇到重重阻碍，二者的差异不太突出。
非功能性测试应该考虑以下几点：
1、非功能性需求一般都是很难捕获的，而且即便被捕获，也很难进行度量。（例如：99.9%的无故障时间）
2、尽可能让所有的非功能测试都自动化执行，把它们也都放到系统集成测试环境中。
3、在定义测试用例的时候，让真正要监控产品环境并对其提供支持的人也参与进来。
4、在应用程序成为产品以后，非功能测试或监控还要继续。
回归测试
在瀑布项目中，回归测试无论从时间上还是费用上来看，都算得上是成本最高的测试阶段了。如果在项目晚期（如UAT阶段）发现了缺陷，再构建应用程序的时候，就得把所有单元测试、功能测试和用户验收测试重新运行一遍。因为大多数瀑布项目都没有自动化测试，所以回归测试的开销就很大。敏捷项目以持续构建和自动化测试来应对回归测试，使每次构建都可以进行回归测试。
回归测试应该考虑这一点：
每次迭代结束时都做一下手工测试，收集早期反馈。
产品校验
产品校验会在把产品交付给用户使用之前，审查产品环境中的应用程序，看看所有内容是否否都已经正确安装，系统的操作性如何。而有些测试还是只能到了产品环境中才能完整运行的，最好尽快将其完成。无论是瀑布项目还是敏捷项目，产品校验的方式并无二致。
产品校验应该考虑以下几点：
1、让最终用户来做产品校验测试。
2、趁着产品系统还没有正式上线，从这个测试阶段的早期就要尽可能多地执行自动化回归测试。
瀑布项目和敏捷项目的测试阶段还是很相似的，主要差异就是每个测试阶段关注的重点和执行时机。敏捷项目中有大量的自动化测试，用持续集成来减少回归测试对项目带来的影响。在瀑布项目中，如果发现应用程序的质量低下，那么在晚期再去执行前期的测试就是很常见的事情（如在UAT的时候做功能测试）。敏捷项目可以减少测试中的浪费，在早期发现问题，让团队在交付应用时增强信心。
环境
在开发过程的各个阶段都要用到测试环境，从而确保应用程序的正常运行。越到后期，测试环境与预期的产品环境就会越相似。测试环境一般都会包括一个开发环境，让开发者集成代码并运行一些测试。系统集成环境跟开发环境有些类似，不过它会集成更多的第三方应用程序，也许还有大批量的数据。试机环境几乎是产品环境的镜像，也是应用程序变成产品之前的最后一个阶段。
敏捷项目和瀑布项目所需的环境没太大区别，其中一个不同之处在于，敏捷项目从项目伊始直至项目结束，都要用到所有的环境。在敏捷项目中，保证所有的环境都一直正常工作也是很重要的。无论因为什么原因让某个环境出现故障，都要立刻让它重新工作起来。在这个话题上，敏捷和瀑布还有另外一点差异，那就是环境的计划和资源分配对它们的影响不同，尤其是当各种环境被项目之外的团队进行管理的时候，其差异尤为显著。
开发集成环境
开发者在开发环境中集成代码，开发应用程序。瀑布项目对开发环境的重要性不会考虑太多；开发环境中的代码一直都不能工作，到了开发者需要彼此集成代码的时候才想起来使用，而这时项目已经临近尾声。在敏捷项目中，开发环境是整个开发工作中不可分割的一部分，在开始编码之前就必须准备就绪。这个环境会被用来持续地集成代码和运行测试套件。无论因为什么原因造成环境故障，都要立刻修复。
开发环境应该考虑以下几点：
1、集成代码、构建和测试的时间加起来不要超过15分钟。
2、每个开发人员所用的环境跟开发环境保持一致（硬件环境可以不一样，但软件环境一定要一样）。
3、所用的数据要尽可能跟产品数据保持一致。如果产品数据过于宠大，难以载入，也可以只取一部分。在每个发布周期的开始阶段，这些数据要从产品数据中重新更新。
4、管理这个环境的责任应该落在项目团队身上。
5、向这个环境中部署的频率大约是以小时计算。
6、自动部署。
系统集成环境
系统集成环境用来将所开发的应用程序和其他应用程序进行集成。在瀑布项目中，这个环境只会在项目临近尾声的时候才会用到，而且倾向于多个项目共用一个集成环境。在敏捷项目中，一旦开始编码，这个环境就要准备就绪。应用程序会被频繁部署到这个环境中，继而开始执行功能测试、集成测试、可用性测试和探索性测试等等。应用程序的演示是在这个环境中进行。
系统集成环境应该考虑以下几点。
1、集成点应该被真正的外部应用程序所代替。外部应用程序应该处于测试状态，而非真正的生产版本。
2、把产品环境的架构复制过来。
3、把这个环境中所使用的数据应该是产品环境数据的副本，每个发布周期的开始阶段，都要从产品数据中重新更新。
4、建立运行这个环境中所有测试的系统集成持续构建。
5、管理这个环境的责任应该落在项目团队身上。
6、向这个环境中部署构建的频率大约是以天计算。
7、自动部署应用程序。
试机环境
试机环境用来验证应用程序可以部署为产品，而且工作正常。为了达到这个目的，试机环境应该完全复制产品环境，包括网络配置、路由器、交换机以及计算机性能等等。在瀑布项目中这个环境往往需要“预订”也要有一个计划，计划在这个环境中进行多少次部署以及何时进行部署。敏捷项目对这个环境不像对开发环境和集成环境那样依赖；不过在项目的整个生命周期中，还是需要常常进行部署。
试机环境应该考虑以下几点：
1、这里的数据应该是产品数据的完整副本，每次应用程序部署前都要更新。
2、用它来验证UAT， 性能测试和非功能测试（稳定性、可靠性等等）
3、向这个环境中部署构建的频率大约是以迭代计算，如每两周一次。
4、管理这个环境的人应该就是管理产品环境的人，让他提前接触应用程序并进行知识传递。
5、自动部署应用程序。
产品环境
产品环境是应用程序正式上线时的环境。产品校验测试就在这个环境中执行，同时会做一些度量以检验测试成果。瀑布项目和敏捷项目在这里的区别不大。在敏捷项目中，发布过程会尽力做到自动化，为向产品环境中频繁发布提供条件。
产品环境应该考虑以下几点：
1、在应用程序正式上线之前，在产品环境中做回归测试。
2、要做度量，以检验测试成果，例如在前三个月到六个月之前，用户报告了多少问题，问题的严重性如何。
无论是哪种项目，要保证时间期限，就都得做到在需要用到环境的时候就有一个环境可供使用。瀑布项目会设法遵守严格的计划，便于对环境做安排。敏捷项目的灵活性更强。也许有了足够的功能就可以进入试机环境了，或者业务人员会决定产品提前上线。为了做到向试机环境快速部署，然后进入产品环境，就要有系统集成环境以及有关过程的辅助。
问题管理
问题包括缺陷（bug）和变更请求。瀑布项目有着严格的缺陷和变更请求管理，而敏捷项目饱含变化，所以就没有那么严格的变更管理。如果需要有变更，就创建一个（或是一些）故事，放到待处理事项里面。高优先级的故事会放到下一次迭代中完成。
缺陷管理在敏捷项目中依然适用。如果有人发现一个正在开发故事有缺陷，大家就会进行非正式的沟通，发现缺陷的人把它告诉开发人员，缺陷立刻被修复。如果某个缺陷并不属于当前迭代中开发的故事，或者属于当前故事，但并不严重，那就用缺陷跟踪工具记录下来。这个缺陷会被当做故事处理；也就是说，会创建一张故事卡，让客户排优先级，放待处理故事里面。团队需要进行权衡：要找问题所在，为大家理解这个问题并安排优先级提供足够的信息，但又不能在一个对客户而言优先级并不是很高的缺陷上面花太多时间。
瀑布项目和敏捷项目的缺陷内容（描述、组件、严重程序等）是一样的，除了一个字段以外：敏捷项目多了一个字段- 业务价值，如果可能的话就用币值描述。这个字段表示如果缺陷被解决的话可以带来多少业务价值。将业务价值跟缺陷关联以后，客户就更好地判断这个缺陷跟新功能相比是不是更有价值，是不是应该有更高的优先级。
工具
所有项目都要用到工具，只是程序不同。瀑布项目用工具来强化过程以及提高效率，这有时会造成冲突。敏捷项目用工具辅助提升效率，与过程无关。在敏捷项目中，所有的测试都应该可以在任何团队成员的个人环境中运行，也就是说，所有人都可以使用那些自动化测试用例的工具。所以敏捷项目中会经常用到开源产品，这又意味着使用这些工具需要不同的技能。开源工具不像商业工具那样有齐备的文档和完善的支持，用这些工具的人要有很强的编码能力。如果有人编程能力偏弱，就可以通过跟人结对来提升个人技能。在敏捷项目中也可以使用商业工具，但是大多数商业工具在开发的时候都没有考虑敏捷过程，所以敏捷项目匹配起来就不太容易。而且要让商业工具跟持续集成配合，可能要写很多代码才行。
项目中应该考虑为下面一些测试任务使用工具
1、持续集成（如CruiseControl， Tinderbox）
2、单元测试（如JUnit， NUnit）
3、代码覆盖率率（如Clover， PureCoverage）
4、功能测试（如：HttpUnit， Selenium， Quick Test professional）
5、用户验收测试（如：Fitness， Quick Test Professional）
6、性能测试（如：JMeter， LoadRunner）
7、问题跟踪（如：BugZilla， JIRA）
8、测试管理（如：Quality Center）
报表与度量
度量数据是用来衡量软件质量和测试成果的。在瀑布项目中，有些测试度量指标需要在测试之前就把所有测试用例都写好，而且仅在应用程序开发完毕时进行一次测试。这种指标包括：每个测试用例执行的时候发现多少缺陷，每天执行的测试用例会发现多少缺陷。这些度量数据收集起来以后，便用来判断应用程序是否已经就绪并可以发布。在敏捷项目中，功能完成的时候测试用例就已经写好且运行完毕，这就意味着用来度量瀑布项目的一些指标是无法应用在这上面的。
回到收集度量数据的原因上来-衡量软件质量和测试成果，你可以看看下面这些概念。
1、用代码覆盖率度量测试效果；这对于单元测试尤其有效。
2、在探索性测试阶段发现的缺陷数量可以说明单元测试和功能测试的效果。
3、在UAT阶段发现的缺陷表示先期的测试并不像UAT一样充分，我们应该关注业务过程， 而不是软件的bug。如果UAT发现了很多功能性问题，而不是软件的bug，这就表示团队对故事或是变化的需求理解不足。
4、故事完成以后所发现的缺陷数量能够作为衡量软件质量的好手段。这些缺陷包括在集成测试、非功能测试、性能测试和UAT测试中发现的缺陷。
5、缺陷重现率。如果缺陷常常重现，软件质量就很低。
测试角色
测试角色并不是跟单个资源一一对应的。一个资源可以担任多个测试角色，一个测试角色也可以由多个资源负责。下面列出的这些角色是确保项目测试效果所必需的。一个优秀的测试人员应该具备所有这些角色的特征。敏捷项目和瀑布项目都有这些角色，只是扮演这些角色的人不同。在敏捷项目中，所有团队成员都是怎么扮演各个角色的。这并不是强制性的规定；每个团队各有差异，不过这种做法也算得上是不错的组合。
测试分析人员要了解需求、架构、代码等各个产物，从而判断哪些需要做测试，哪些是测试要重点关注的地方。
在瀑布项目中一般是有一个（或多个）资深的资源来担任这个角色。他们检查相关文档（需求、设计、架构），编写测试计划、编写高层的测试用例描述，然后把所有的东西都交给一个初级员工，让他填补详细的测试脚本。敏捷项目鼓励所有团队成员一起担任这个角色。开发人员的关注点是通过分析代码和设计来编写单元测试，但是他们也会协助业务分析师或者测试人员编写功能测试，还会参与非功能测试和性能测试的分析。业务分析师和测试人员紧密协作，编写功能测试和用户验收测试，并执行探索性测试。客户/最终用户会被邀请参与用户验收测试。
测试脚本编写员
该角色就是编写详细测试脚本的人。这些脚本可能供手工执行，也可能被自动化。瀑布项目中的脚本编写就是个初级员工，他根据测试计划和测试用例描述来编写手册，每一步都描述的很详尽、自动化脚本编写员就得是更资深的人了，开发人员也会参与单元测试用例的编写。敏捷项目会大量使用开发人员来编写测试脚本，主要是因为测试脚本是自动化执行的。
测试执行员
不管是手工测试还是自动化测试都有这个角色，不过在自动化的时候，这个角色的扮演者就是一台电脑。测试执行员会执行详细测试脚本，判断哪些测试失败，哪些测试通过。瀑布项目一般都用测试人员来做这件事情，而敏捷项目则鼓励所有人都来参与，尤其是测试人员、业务分析量和客户。
环境管理人员
这个角色管理测试环境，包括应用程序运行的环境以及支持自动化测试的基础架构。他们还会关注外部接口和用作测试的数据。这个角色在瀑布项目和敏捷项目中很相似。
问题管理人员
问题出现以后就要解决。这个角色可以帮助筛查问题，确保它们被正确地创建，有各种属性，如严重程度、优先级、组件等等。这个角色还要管理问题的生命周期，并提供工具支持。这个角色在瀑布项目和敏捷项目中很相似。
故障检测人员
这个角色当问题出现的时候就要去做故障检测工作，判断是不是软件缺陷。如果是软件缺陷，他们就要去找出问题根源、可能的解决方案和变通措施。这个角色在瀑布项目和敏捷项目中很相似。
敏捷团队所注重的是让各个角色得到充分发挥，而比较少关心谁在做什么事情、谁对哪些事情负责。测试人员和其他团队成员之间没有界限，他们共同的目标是生产出更高质量的软件，每个成员都要尽一切可能帮助达成这个目标。在敏捷团队中，测试人员可以从所有人那里得到帮助，而他们又可以帮助其他人提高测试技能。这种方式能够确保团队中的每个人都在为交付高质量应用程序而付出。
在之前的博客中我简单给大家介绍了SVN的基础知识以及与CVS的区别。通过上两篇文章，我想大家已经意识到，SVN是有很多CVS所不具备的特点。而且，现在大多数人的观点是CVS将被SVN所代替。
在基础篇中我们大概讲了一下如何使用SVN，但大多数是在非可视化的条件下操作的，这对我们大多数同学来说，这是由一定难度的。有了不舒服的地方，肯定就有好的代替方法。今天给大家介绍一下可视化SVN的使用。
VisualSVN是VisualStudio的一个插件，通过Visual SVN 我们可以在VS中对SVN代码进行管理，在项目资源管理器重右键相应的项目或类，可以看到Update(更新) 和Commit（提交），在这里就可以完成相应的任务。
VisualSVNServer是服务端，可视化的。我们可以看到服务器中的文件。
大家只要知道他们一个是客户端，一个是服务器端即可。下面介绍使用方法。
安装就不介绍了，一路Next安装。
我们上面说了VisualSVN是VS的一个插件，所以我们当然要在VS中找他啦！
而服务端在我们的开始菜单中可以找到。
我们首先打开服务端，我们来认识一下它：
首先是库，我们在前面的文章已经介绍了。然后用户，就是给使用这个库的人注册一下。组呢，现在还没用到，是针对大型项目时把不同的小组的人分出来用的。其实，无论是用户还是组，都是为了让特定的人有特定的权限去访问或修改库中的某个文件。
下面就是建库：
右键可以看到有Create New Repository，点击建库。输入库名，OK。库就算基本建成功啦！怎么样？比上次介绍的方法简单多了吧。
库建立好了，下面来添加用户：
同样的步骤，Users右键Create New User。输入用户名和密码。即可添加成功。
库也建好了，用户也添加了，是不是我们的任务就完成了呢？重要的还没说，权限！
权限就好像是一种证件，你只能做你权限内的事情，否则岂不乱套啦？试想，我们合作开发，每个人都可以提交的话，本来这部分是我做的东西，结果你不小心给我改了，而且提交到了服务器，那我们两个的东西不就起了冲突了吗？
所以，在建立用户的时候要根据用户的具体任务分给他不同的权限。以简单三层为例，test1负责UI层，那么test1的权限只能提交UI层，BLL/DAL他是不能提交的。而更新时对所有用户都开放的。
下面来看看如何配置权限。
首先说明一下，设置权限是某用户对某个库的权限，所以是对库的属性设置。
右键库名，点击属性（Properties），点击Add把用户添加到该库的属性中。
相信大家都看到他下面的Permissons（权限）了。选中用户选择相应的权限即可。
Read/Write读写权限。
ReadOnly只读权限。
No Access，不允许，即没有权限。
Inherit fromParent，从父母继承。什么意思？这里的parent指的是这个库或者库中的文件的parent，即这个文件属于哪个库，则该用户对该文件的权限继承于该用户对这个库的权限。就是这个用户对这个文件的parent有什么权限对它就有什么权限。
现在对权限这部分特别有感触，开发之前应该要求各用户只能改自己负责部分的代码，其他的之能看，不能改。如果确实需要改，怎么办？1、自己拿出一个备份，去改。2、通知负责这部分的同事，让他改，自己只更新。这样做，可以很好的避免冲突的发生，提高合作的效率。
相关链接：
零基础学习SVN之（一）：SCM与SVN的使用（基础篇）
零基础学习SVN之（二）：CVS与SVN的区别
一、什么是软件项目管理
软件项目管理是按需求确定范围、按目标制定项目计划、按计划执行管理的过程。对软件开发各阶段加强项目管理的根本目的在于增强对软件开发的控制能力，提升软件开发的质量。软件项目的建设按软件工程的生命周期法可分为项目立项、启动、需求分析、系统设计、系统开发、系统测试、系统上线、项目验收和上线后评估等9个阶段进行。
加强软件项目管理，就是以软件工程的各个环节为管理主线，将动态项目管理贯穿其中，通过对软件开发的项目范围、项目进度、项目质量、项目沟通、人力资源、项目成本六大核心要素的集成管理，实现软件开发管理效能的最大化，从而大大提高软件开发质量。
二、软件项目进度管理的定义及实施方法
软件项目进度管理是指项目管理者围绕项目要求编制计划，付诸实施且在此过程中经常检查计划的实际执行情况，分析进度偏差原因并在此基础上，不断调整，修改计划直至项目交付使用；通过对进度影响因素实施控制及各种关系协调，综合运用各种可行方法、措施，将项目的计划控制在事先确定的目标范围之内，在兼顾成本，质量控制目标的同时，努力缩短时间。
项目进度管理可以通过以下方式完成：制定项目里程碑管理运行表；定期举行项目状态会议，由软件开发方报告进度和问题，用户方提出意见；比较各项任务的实际开始日期与计划开始日期是否吻合；确定正式的项目里程碑是否在预期完成。
三、如何编制项目进度计划
识别进度计划所有者
识别所有者或负责开发所有或部分项目进度计划的个人，对于确保开发出好的进度计划是必要的。推荐采用WBS（作业分解结构）或者组织的分解结构作为进度开发的基础，因为WBS指定范围，组织分解结构（OBS）指定交付的功能区。
决定任务和里程碑
对于每一个最低级别的WBS元素，识别任务和里程碑对应交付的元素。可交付物通常设置为里程碑，产生可交付物的活动被称为任务。里程碑是一个时间点，被用于管理检查点来测量成果。
排序工作活动
在确定了交付产品的任物和里程碑之后，他们应该被逻辑的排序，来反映将被执行的工作方式。排序建立了任物和里程碑之间的依赖，并被用于计算交付产品的的进度。
任务历时评估
任务的历时评估是项目计划中最具挑战的部分，他也是后续成本估计的关键。这是一个不断细化的过程，贯穿于计划过程，因为它直接受人员安排和成本估算活动影响。
整合任务计划
一旦任务和里程碑被识别，排序，并且有了计划的历时评估，对每一个交付的产品就有了进度计划。没有整合，每一部分的进度是独立的，并且因此不能描述与整个项目相关的时间问题。
审查批准进度计划
一个较大和复杂的进度计划需要从多个人那里获得输入，没有人拥有项目的每一个方面的所有影响进度计划因素的所有的知识，因此团队应该执行进度计划的审查，来发现问题，或完善该进度计划。
四、如何有效的控制软件项目的进度
在当前的软件项目开发的过程中，无论是开发人员还是管理人员都越来越注意到项目进度的重要性。那么如何控制项目进度。
1、项目组长或项目经理，一定对整个项目的开发周期有一个清楚的了解，把任务的划分一定要一天为单位，不要一模块为单位，而每天无论是开发人员还是测试人员，都要对自己的工作有一个大致的估计。即每天下午，有项目组长组织开发人员进行系统的了解，并且作好相应的记录。对已经解决的问题一定要一个详细的记录。而对没有解决的问题一定要重视起来。不要向后退。找到根本的原因所在。
2、沟通和交流，作为项目组长一定要多多与开发人员进行交流，要调动其的积极性，让他们学会问题该如何解决，不要让他等待问题的解决。了解其实际的进展以及对开发工具的熟练程度，这对以后的任务的重新安排有重要的借鉴意义。
3、把一些难点提出，让大家共同克服，或者有一些技术比较精通的人来解决。解决完以后一定，让大家都熟悉其编程思路。而对经常用的知识点，一定有详细的说明。这样实现资源的共享。
4、做好项目的总结，无论是难点还是不难，只要有问题，一定要提出，并且解决完以后一定让大家都熟悉，这样有助于大家的技术水平的提高。
5、做到日清日结，是保证项目进度的关键所在。
五、软件项目进度管理中的软技巧
1、树立综合协调的观念
从本质上讲，项目管理是从全局出发，以项目整体利益最大化为目标，以项目范围、成本、质量等各专项管理的协调、统一为内容，所开展的综合性管理过程。因此，开展项目管理就要有项目各要素及各专项管理，进行综合协调的观念。
首先，IT项目的范围会影响IT项目的进度。一般来讲，项目范围越大，项目所要完成的任务越多，项目耗时越长；反过来，项目范围越少，项目所要完成的任务越少，项目耗时越短。因此，如果项目进度很紧，或者进度拖延非常严重，就可以考虑与客户讨论，是否能够将范围进行收缩。如果客户同意缩小范围，那么进度能得到有效缩短。
同样的，IT项目的成本、质量也会影响进度。一般来讲，追加成本，可以增加更多的资源，比如设备和人力，从而使某些工作能够并行完成或者加班完成。
如果项目不能按进度完成，可以考虑有些原定任务是否可以外包出去，这是项目采购管理与进度管理的协调内容之一。
显然，在缩减进度时，可以考虑上述各专项管理之间的协调，即砍掉部分任务、降低部分任务的质量、分包部分任务、追加部分任务的成本等。
2、掌握正确的需求调研方法
很多项目组一提到需求调研，就马上想到与用户访谈。在项目一开始，就与用户面对面访谈，并不是一种好的需求调研方法。
正确的方法应该首先请用户提供能反映用户业务的相关资料和书籍，开始文献调研。在阅读文献的过程中，就能够搞清楚对方的一些基本业务术语，并且对用户的业务流程有一个初步认识。
其次，如果需要，请用户带领项目组参观用户现场的业务流程，从而对某些字面上不容易理解的术语和业务环节，树立一种感性认识。
第三，在此基础上，根据文献调查和实地考察中发现的问题，有针对性地列出访谈大纲，与用户进行访谈。这时访谈的效率和访谈的质量都会提高，用户也会因为项目组提到的问题很专业、有针对性，从而产生较强的信赖感。
有的项目组在访谈完后，就认为得到了用户的真实、完整的需求，从而开始项目设计。事实上，有些IT项目比较敏感，因为访谈的结果是要记录的，用户为了回避自己的“风险”，会按照“官方”的口径讲话，这样，需求就可能被扭曲。
正确的方法应该是在访谈后，继续进行第四项任务，即发放无记名需求调查表。由于是无记名的，一般都能收集到比较真实的需求信息。
掌握了正确的需求调研方法的项目组，就能很快得到高质量的需求信息，缩短调研时间，使设计和实施的时间比较富裕，从而缩短进度。
3、缩短团队组建与磨合时间
任何一个项目组从接受任务到任务完成、团队解散，一般都会经历五个阶段：组建阶段，磨合阶段，正规阶段，表现阶段，解散阶段。
在五个阶段中，解散阶段由于项目任务已经完成，对于项目的影响不大。对于一个项目经理来讲，一定要清楚，真正工作的阶段是正规和表现阶段。因而，项目经理的重要职责，就是使项目团队的组建和磨合阶段的耗时尽量短，这样，项目团队的正规和表现阶段的历时就会越长，在布置任务和执行任务时，就更加从容。
六、如何避免项目进度失控
1、进度表失控的严重后果
（1）进度失控会扰乱规划进度失控导致的直接后果是不得不推迟系统正常完成时间。这个后果会增加业主的负担，包括时间、人力、物力和财力的继续投入，严重时会造成项目停滞和搁浅。
（2）进度失控与质量失控相互影响一般来讲，质量控制和进度控制是一对孪生兄弟，是相互起连锁反应的，进度失控可能导致质量失控；同样，质量的失控也会导致进度失控。
（3）进度失控会突破项目的计划成本项目执行的进度拖后之后，需要投入更多的资源解决存在的问题，重新制定计划。即使工作量没有增加，时间的增加就是费用的增加，也就是投资的增加。
2、避免进度表滞后的几点措施
（1）锁定需求，避免无休止的变更。
每一个项目都需要在开展之前锁定需求，不这样做必将会导致项目失败。在项目开发的过程中，多多少少都会发生一些范围变更，一定要严格控制这些变更，对这些变更有一个应对方案，把变更范围控制在可控范围内，不然便会出现很多并发症，导致进度表滞后和成本的增加。
（2）重新检查进度表项目进度表的一个很重要的前提是项目估算，项目估算最大的基础是基于经验值，而软件工程的经验值反映的只是业界的常规实践，并不能够反映每一个团队。因此，在项目估算时应该以自己团队历史经验值为基础，让项目团队中的每一个成员参与估算，这样才能够保证项目计划的可行性，从而避免出现系统设计与编码实现都超出进度表的计划估算。
（3）有效的进度表检查工具糟糕的执行会给项目带来在成本和时间两方面上的失败，这会最终导致整个项目的失败。很多失败的项目开发的教训揭示了能够充分地描述项目进度的检查工具简直太重要了。我得到的最宝贵的经验是要抓住项目开发过程中的关键环节，密切注意进展情况，一旦出现问题，应该马上能拿出切实可行的措施。当出现可能严重影响进度表滞后时，就应该根据现阶段状况重新评价需求分析结果、工数估算、设计结果等。切勿匆忙采取头痛医头、脚痛医脚的措施，致使进度表滞后更严重。
（4）在各种项目目标中进行平衡进度控制的目标与成本控制的目标和质量控制的目标是对立统一的关系。项目进度、质量和成本构成一个相互制约的三角关系，需要去平衡。如果经过评估确定项目进度确实已无法控制，就应当下定决心以牺牲软件功能范围、工作成果范围、成本预算、进度计划或软件质量中的某一项目标为代价，来保住项目最重要的目标达成，最终确定一个最合适的解决方案。指望不采取纠正和干预措施，进度失控会自行消失的想法是不现实的。因此，如果这些项目参数超出项目目标的限制范围，就必须马上采取纠正措施；如果发现这些项目参数有超出项目目标的限制范围的趋势，就必须马上采取预防措施。
（5）奖罚制度的制定进度表的执行还必须有相应的控制措施来保证。例如可以制定一些奖惩制度，奖励是主要，惩罚是辅助手段，调动起所有人员的积极性。通过订立相应的评估指标，把项目执行作为项目人员的重要业绩进行考核监督，避免因为少部分人不配合工作导致项目整体延误，从制度上保障任务的顺利完成。
引言：什么是RFS——RobotFramework+selenium2library，本系列主要介绍web自动化验收测试方面。
好久没写东西了，最近没怎么弄QTP了，之前一直想找一个能方便管理QTP对象的东东，FrameworkManage用excel管理虽然是方便了一些，但是还是感觉很麻烦。
最近刚刚接触到RobotFramework，发现这个工具倒是可以满足我的要求，而且可以结合seleniumLibrary，用来做web的自动化测试相当不错。之前我也接触过selenium，不过感觉那个工具更贴近开发人员使用，有了robotFramework之后，感觉这个工具相当强大，而且是贴近测试人员的。之所以说强大，主要是这些测试脚本都可以用文本格式保存（如txt/html等）
==安装篇==
如果有想学的朋友可以自己下载以下文件安装（Google-code里可以找到大部分的安装文件）：
python-2.7.1.msi（首先要有python，请选择将Python加入Path）
wxPython2.8-win32-unicode-2.8.11.0-py27.exe（wxPython，必须要的）
robotframework-2.6.0.win32.exe（然后装robot的Framework）
robotframework-ride-0.38.1.win32.exe（robotFramework的IDE，很不错）
robotframework-seleniumlibrary-2.8.win32.exe（seleniumLibrary）
安装成功后
执行[PythonDir]\Scripts\ride.py
看到界面就是安装成功了。
如果需要AutoIt支持就下载下面2个东东。
AutoItLibrary-1.1
pywin32-216.win32-py2.7.exe
==入门篇==
安装完成了，这个框架可以说是基于keyword的操作，按F5可以看到所有加载的keyword。
首先新增一个project
然后新增suite
然后新增test case，接着在suite层级add library，把selenium library加进来，添加后按F5检验是否添加成功，如图
OK，继续在suite的setting里设置suite启动和结束的keyword，即Start Selenium Server和Stop Selenium Server，他会在运行时帮助我们自动启动seleniumserver。
接下来在test case里添加一个步骤，open browser（一般用selenium做web测试都要用这个方法来打开浏览器），添加后关键字变成蓝色表示找到关键字了，否则可能是拼写错误或者没有加载相应的library。红色表示有一个必选参数要给定输入值，具体参数可以看F5里的keyword说明。
输入参数，第二个参数默认是firefox，不过我没装，就用ie吧。
OK了，全部保存一下，然后按工具栏倒数第二个的机器人图标运行test case
额，我的运行失败了，
Timed out after 5000.0ms
原来网页加载时间太长了，selenium会一直等页面加载完成，可以修改一下默认等待时间，记得suite那里添加library么，当时添加的时候没写其他的就写了名字，下一个参数就是默认超时的时间，改个长点的，保存后执行，运行成功。
以上只是一个简单的例子，没有详细说明每个步骤的操作，只是初步介绍。后续再详细介绍。
有了这个RIDE后你可以很方便的管理你的对象和脚本，进而可以自己对测试案例分层，数据和脚本分离、流程分离等等。如果有兴趣可以自己写library，本人正在研究中，可惜RIDE对中文注释不支持，自己写的library的中文注释被转换成了\xd5\xe2之类的了。
以后再为大家介绍进阶操作。
性能测试知多少---性能测试流程
看到好多新手，在性能需求模糊的情况下，随便找一个性能测试工具，然后就开始进行性能测试了，在这种情况下得到的性能测试结果很难体现系统真实的能力，或者可能与系统真实的性能相距甚远。
与功能测试相比，性能测试在技术层面具有更大的复杂性。在以往的测试流程中，性能测试只是测试流程的一部分，是系统或验收测试的一个可选项。但随着测试技术的发展。许多公司也单独把性能测试独立出来，建立专门的性能测试小组或团队。那么性能测试在实施的过程中也需要建立独立的流程与规范。
虫师提出了自己性能测试流程，与其它书本提出的流程在些小不同。流程的实施没有绝对的对错，适合自身的流程就是正确。
下面看我所提到的流程
性能需求分析
性能需求分析是整个性能测试工作开展的基础，如果你连性能的需求都没弄清楚，后面的性能测试工具就无从谈起了。
在这一阶段，性能测试人员需要与需求人员（客户）、领导及项目相关的人员进行沟通，同时收集各种项目资料，对系统进行分析，确认测试的意图。当然，还需要客户对性能的态度。
测试需求分析阶段的主要任务是确定测试策略和测试范围。策略主要根据软件类型以及用户对系统的性能的需求来定，测试范围则主要分析系统的功能模块进行调研与分析。最终确认明确的需求。
性能测试计划
确定明确的需求之后，我们要做的工作就是制定性能测试计划。对性能测试过程中所有需要工作制定与规划。
测试计划的大体内容：
项目的简单背景描述，本次性能测试的需求与目的，性能需求分析的结果是什么。测试环境的准备，需要什么样的软硬件配置，网络状况登录。测试数据的准备，对于某些性能测试是需要事先准备测试数据的。
测试的策略，前面进行需求分析的目的是制定测试策略，也就是设计符合需求的测试场景，需要对系统的哪些业务模块进行测试，如何进行？需要设计哪些场景以及设计这些场景的目的。
最后会明确一下人员配备，比如需要开发、DBA、运维都人员的参与协助，性能测试的时间安排。
测试环境搭建
测试环境搭建，分硬件环境与软件环境，硬件环境主要是向上级审批硬件配备，在某些大型性能测试，可能需要公司购置或租用硬件设备来进行。或者是将来原有设置进行调配与重组，这个时候就需要网络工程师的参与或协助。
软件环境的搭建对于开发人员来说应该毫无压力，比如常见的三大环境，微软的windows + IIS+SQL server 2005+.NET平台、windows/linux+tomcat/weblogic+mysql+java 、linux+ apache+mysql+PHP 等环境。当然身为性能测试人员，不仅也需要会搭建软件平台，更需要对每个平台中的部分有比较深入的了解。因为性能测试的分析并不是死盯着系统应用那一层。中间件、数据库、系统、硬件都有可能成为系统的瓶颈。
性能工具的引入
其实走到这一步进才需要引入性能测试工具，我们在日常的工作中往往是先选定好测试工具然后再分析需求，制定计划进行测试。这样我们在做性能需求分析的时候往往会往往会考虑所选的工具是否能实现，无法实现可能就放弃这个需求或改变这个需求。这样以某一工具为基础点做出的性能测试结果可能是不准确的。
工具的引入分为自行开发与引入市面上的现有工具。市面上的现有工具又分为收费与开源免费，各有各的优缺点。我们要做的是对需求进行分析，从成本，购买成本，开发成本，现有开源工具的二次开发成本，人员学习使用成本以及时间成本等。
在这里再强调一点，不是只有压力测试工具属于性能工具，在性能测试过程中所用到的工具都属于性能工具，如测试数据生成工具，性能监控工具等。
测试的执行
测试的执行应该是很大范围的一块内容。也就是我在上一节中性能测试架构所提到的内容。用户行为生成-->压力产生器-->用户代理-->测试调度-->系统监控等。
我们所选择的工具如何来实现我们的需求，这个性能测试工程师对引入的有足够的了解。对协议的了解，可能需要编程的能力等。其实好多新手对性能的学习也是从某一工具的使用开始的。
测试结果的分析
这里再重复一次，测试工具只是提供多种不同的数据揭示和呈现方法而已。工具本身并不能帮我们进行性能结果的分析。
对于性能测试结果的分析，这个需要性能测试工程师对整个被测环境的各种软硬件都要有深入的了解。当然，在这个过程中我们往往需要各个岗位人员的协助，开发人员、DBA、运维等。致力成为一位资深的性能测试工程师要走路还很长。
软件硬件配置调整与优化
说的简单点这个环节属于系统调优阶段。这一项不是一个必须的环节。这个要看你本次性能测试的需求与目的。如果只是为了验证系统的能力的话。在分析完测试结果后就可以出性能测试报告了。
对于我们测试人员来说，我们对一个系统进行功能测试的目的是验证系统功能是否是符合需求并可用的，但发现了缺陷之后是需要对缺陷进行跟踪和修复的，并不是把发现的缺陷写在报告里就完事的。当然，功能缺陷与性能缺陷存在着本质的缺陷。如果在性能测试过程中发现不满足需求的缺陷，进行调优是一个不可缺少的过程。
如果要对系统进行调优的话，测试执行、结果分析、系统调优将会形成一个循环持续的过程。直到满足客户的需求为止。
-----------------------------------------------
对于上面测试流程中所列出的部分，我在后续的博文中会细讲，当然，你也可以对我提出的这个流程进行交流，欢迎留言拍砖。
相关链接：
性能测试知多少----性能测试分类之我见
性能测试知多少---并发用户
性能测试知多少---吞吐量
性能测试知多少---响应时间
性能测试知多少---了解前端性能
性能测试知多少---性能测试工具原理与架构
我不知道如何成为一个伟大的测试工程师，但从我7年的软件测试和质量的短暂的经验列表中得出一些感悟。它涉及到测试工程师和测试/质量经理两个方面。以下是8个方面：
1、阅读关于软件测试资讯和资料
尝试按时阅读诸如技术新闻，使用谷歌阅读器，使用Twitter等，即使90％的知识是多余的，有时对显示你的附加智慧会有很好的印象。第二，你就会有一个新的思路，以提高测试过程。
2、有一定的软件开发经验
有经验的编程或测试并行编程是一个非常好的经历！可以预测之前检测他们在测试过程中的一些错误。通常情况下，我们可以找出在哪些领域可能会出现错误，这些错误的类型，只知道一个功能变化的说明。如果你有一个与开发工程师的良好关系，我们可以经常给他们一个提示或如何来解决这个问题找到一个可能的解决方案 - 建立良好关系！
3、从行业内的人交谈
从业内人士的会见，会议，培训、沙龙分享等。你会看到真正的趋势，或收获一些有趣的想法。
4、自动化测试，但不依赖于它
自动化测试是好的，但过量可能会导致接受的方案，这是正确的，但用户完全无用。自动化测试将帮助你获得信心，正在运行的核心应用功能，真正的测试会给你一般意义上的一个良好的工作。
5、站在开发的角度来思考
这是非常重要的！尽量使质量和开发部门团队达成共识，开发一个完美的软件。报告每个开发人员的缺陷数量是非常糟糕的做法。尝试站在你以及开发人员角度来换位思考对待测试阶段的缺陷。如果你看到一个开发人员有一些麻烦，产生错误的代码，先和他谈谈，然后他的经理交谈。
6、眼下的事实 - 积极参与项目活动
尝试参与新功能的设计，往往你的建议会在以后减少错误的数量。了解更多有关整个项目团队，成为一名专业的顾问。
7、学习的关键应用程序的功能
你必须知道应用程序的关键路径，路径是最常见的用户执行，它是最重要的业务流程。该功能将创建方案和测试培训时特别强调，增加确定性的应用是可以接受的，并没有严重错误。
8、在你的心中始终有可用性
高级软件质量并不仅仅意味着该应用程序是没有功能的错误，但上述所有，确保我们的可用性也是在较高水平。使用可用性测试和可用性检查测试可用性为目标。尝试，以消除冗余的应用程序路径，在开发的早期阶段，它仍然这样做，那么你将有更高的可用性和错误被更容易发现。
版权声明：本文出自 linlinxu 的51Testing软件测试博客：http://www.51testing.com/?94273
相信大家看了零基础学习SVN之（一）：SCM与SVN的使用（基础篇）这篇博客之后，对版本控制就有了一定的理解，同时也应该知道SVN与CVS是比较流行的两款SCM工具。那么到底这两款工具有什么区别呢？
1、版本编号方面
例如，我们的版本库为A，其中有文件a，b，c。
在SVN中，新版本的版本号不是针对某个特定文件的，而是针对整个库而言的。提交了5次和提交了6次，文件a有可能不同，也有可能相同，即1.0版和1.1版可能相同。因为第6次提交有可能是因为文件b或c进行了修改。而在CVS中则相反，每次更新可能只对文件的版本号进行修改，即a文件的1.0版和1.1版是肯定不同。
（在这里纠正一个概念，“文件a的第2版本”这个说法是错误的，应该是“文件a的第2次修改，即第二次Commit”）
SVN的全局性版本编号为SVN带来了诸多的优势：如对目录或文件执行拷贝，无论涉及多少文件，SVN不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。
2、目录的版本控制
CVS只能对文件进行版本控制，不能对目录进行版本控制，这就导致CVS失去了很多功能：
1）没有移动操作
CVS里没有移动（move）这个操作，当人为进行文件移动操作时，CVS只能注意到，一个文件在一个位置被删除了，而在一 个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。所以使用CVS时，每个文件的位置一定要谨慎的选择。
2）没有重命名操作
CVS里没有重命名（rename）这个操作，人为的对文件进行重命名会使得命名前后的文件失去历史联系，而记录历史本来是版本管理的主要目的。
3）没有拷贝操作
CVS中没有拷贝（copy）这个操作，人为的拷贝对CVS而言，只能看到新的文件的增加，而不能记录拷贝源文件和目标文件之间的联系。
而SVN从很大程度上避免了这些不足，SVN将目录作为一类特殊的文件来处理。当目录中的子目录/文件被删除、重命名、或新的子目录/文件被创建时，目录的内容将发生改变。因此，SVN象记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，SVN能够准确记录操作前后的历史联系。同样，像对文件的不同历史版本进行比较一样，SVN支持对目录的不同历史版本的比较，清晰展现目录的变化历史。
3、原子性提交
CVS和SVN同样作为SCM版本控制管理工具，SVN的原子性提交可谓是技高一筹啊！
SVN提交文件，只有当全部文件修改都成功入库，该提交才变得有效。一旦中断，SVN将会自动执行“回滚”（rollback）操作。SVN 这种机制保证所有的修改要么全部入库生效，要么一个也不入库。由于SVN的原子性提交特性和全局版本编号方式，当提交成功完成时，一个唯一的、新的全局版本编号产生，而提交时用户提供的日志信息与该新的版本编号关联，只进行一次存储（区别于CVS的按文件重复存储）。
而CVS则采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中。但当任何原因造成批量操作的中断时，版本库往往处于一个不一致的状态。另外，CVS即使在批量提交不发生中断时也会造成不一致：假设用户A启动一个需要较长时间才能完成的批量提交；与此同时，用户B执行cvsupdate操作。此时，用户B很有可能得到一个不一致的更新，即用户B通过“更新”操作，得到用户A的部分修改文件。
4、变更集概念的支持
由于SVN提交是原子性的，每次成功提交形成的唯一的全局版本号对应此次批量提交的所有文件修改，也就是说，一个SVN版本号其实对应了一个逻辑上的变更集，该变更集可能对应于对一个BUG的修复，或者对应于对一个已有功能的改进，或者对应于一个新功能的实现。可以说，变更集是一个软件开发活动的逻辑结果，该变更集可以通过其对应的版本号在软件开发的其他过程中（如软件合并/集成过程，软件发布管理，变更管理系统，缺陷追踪系统）被引用。因此，SVN将版本管理从单纯的、单个的文件修改的层次通过逻辑上的抽象，上升到更便于理解和交流的开发活动的层次。
5、差异化的二进制文件处理
CVS最初设计是为处理文本文件（或ASCII文件，源代码文件），对文本文件进行差异化的存储、新旧版本的比较，文件合并等。但对于二进制文件，CVS则明显力不从心。在CVS的版本库中，对于二进制文件的历史版本，CVS是对不同的版本进行独立的、冗余的存储，哪怕版本之间其实只存在微小的差异。与CVS不同，SVN每次提交后版本库中只存储相对于先前版本的差异，从而可以节省大量的存储空间。更为重要的是，当客户端需要获取新的版本时，SVN只传输版本的差异，从而大大减少对网络带宽的消耗。
说了这么多，好像全是在说SVN得优点，其实它也不是那么完美。下面来分析一下SVN的一些不足之处。
1）对中文路径名的支持
cvs：支持的比较好
svn：要将权限控制文件保存为svn支持的UTF-8格式
2）本地文件与库的对应关系
cvs：可以多对多
svn：一个库可以有多个工作目录，但一个工作目录只能对应一个库，虽然可以更改库位置但是要求很严格。
3）库中文件存放方式
cvs：完全用户可见方式与客户端文件夹结构完全一直（cvs生成文件除外）
svn：看不到文件真正的内容
相关链接：
零基础学习SVN之（一）：SCM与SVN的使用（基础篇）
从事软件质量保证工作已有几个年头，经常有朋友问起软件质量保证到底是干什么的？每次总回答就是辅导和监督项目开发按照公司研发过程执行的，仔细想想实际并没有这么简单，为了让更多朋友了解质量保证这个岗位，在此结合这几年的工作经验进行如下总结，若有不对的地方欢迎大家指正与交流，谢谢！
1、什么是质量保证？
在CMMI中，质量保证的英文全称是Process and Product Quality Assurance，即过程与产品质量保证。一般大家更习惯叫质量保证或QA，它的目的是为员工和管理层提供过程和相关工作产品的客观洞察。之所以说它客观是因为：
1）质量保证人员是一个独立于项目组之外的第三方审计人员，不能是直接参与开发、测试和项目管理的人（当然实际也有例外，有些公司QA可能是兼职的）；
2）质量保证人员不受监督对象部门的绩效评价；
3）质量保证人员具有独立的问题汇报渠道（可以跨级上报——QA很重要的特权）。
2、软件质量保证工作内容？
一般设有软件质量保证岗位的公司都有一套依据自己公司实际研发现状制定的完整研发过程体系，所有的软件质量保证人员入职一家新公司，首先需要做的事情就是学习和深刻了解该公司研发过程体系，否则后续工作是无法开展的。
一般软件质量保证工作内容主要分三大块：
1）过程辅导
依据研发过程体系辅导所有开发项目/版本前期及项目过程各个环节及各环节具体活动执行（含流程、方法、模板及过程中相关工具的使用）。
辅导时机：
● 到达项目/版本计划中计划的时间点
● 触发事件驱动（如：邮件）
辅导方式：
● 口头
● 邮件
● 电话
● 通讯工具（如：QQ、RTX等）
● 必要时可以开展正式的课堂培训（一般很少）
2）过程检查
所有开发项目/版本开发过程中，依据当前的研发过程体系客观的对实际执行情况进行检查与评价。
检查的方式：
● 参加项目会议（评审会、周会）
● 与各个环节人员沟通
● 触发事件驱动（如：邮件）地进行检查
● 检查工作产品
3）过程问题记录与跟踪
记录过程检查过程中发现的不符合项，并与相关负责人进行沟通，了解产生问题的原因，跟踪不符合项确保问题得到解决。
伴随上工作过程中还会有一些其他工作内容，如下：
4）向项目组和管理层提供质量保证活动结果——风险预警与问题报告。
预警风险、及早报告项目问题，使项目免受损失或少受损失，是质量保证的重要价值体现。
有经验的质量保证人员能够基于过程中了解到的项目过程质量状况和产品质量状况，及时识别出项目过程中存在的风险和发现过程问题，并定期（一般都是一周）向项目组与管理层预警风险、报告问题。
项目组必须在规定的期限内回复质量保证人员报告的问题。
对于无法协调一致的问题要及时升级。
● 就质量保证问题的认定双方不能达成一致。
● 就质量保证问题的解决计划双方不能达成一致。
● 项目组未按计划解决质量保证问题。
● ……
管理层必须及时处理升级的问题。
● 强制项目组解决。
● 豁免。
5）严重问题根因分析
质量保证人员需要定期（如每月/季度）对记录的问题进行分类与分析，对于过程中发生的严重问题或事故，必须了解问题产生的根源才能够在后续进行规避。一般若公司有多个质量保证人员，应以部门为单位开展问题根因分析活动，必要时还可以邀请EPG小组成员一起），问题根因分析活动结束后应向相关领导出具根因分析报告，提出当前的对策及未来建议。
6）收集与反馈过程改进建议，协助过程改进
一般公司EPG（过程改进小组）大都由其它岗位人员兼职的，我就职的3家公司质量保证人员都会兼EPG中的某个角色。
质量保证人员在项目过程中会与软件生命周期各个环节的人员打交道，有心的质量保证人员在此过程中肯定能够发现很多研发过程体系不合理或不够完善的地方，同时项目结项时质量保证人员要进行质量保证总结，在总结过程中也可以收集到很多过程改进建议，质量保证人员要定期将收集到的过程改进建议反馈给EPG组长，由EPG组长规划过程的改进。
7）其它
其它依据各个公司具体情况而定，如：定期进行交叉检查，开展研发过程体系培训，度量项目过程，协助项目经理监控项目进展。
软件质量保证工作的开展是有计划有序进行的，一般项目初期（如：项目计划阶段）质量保证人员要制订质量保证计划，质量保证计划要得到项目经理、质量部门负责人的评审/审批。
同时在实际检查过程中也是有依据的——QA检查单，一般公司研发过程体系中都会制订一份完整的QA检查单模板，各个项目要依据项目过程定义进行裁剪。
3、质量保证人员的素质和能力要求
软件质量保证工作涉及到软件工程的各个方面，软件质量保证人员要与不同角色的人员进行沟通，因此软件质量保证人员除了要有较高的智商和情商外，还有具备如下的素质和能力：
1）要有控制软件质量的能力
也就是说要熟练掌握公司各种流程、标准和规范，做好第三方独立审计的工作并及时发现、纠正问题。在必要时可以利用向高层领导直接汇报的权力来“威慑”相关人员，以确保软件质量朝好的方向发展。在控制软件质量发展方向的同时要学会控制自己的情绪，因为并不是所有人员都很了解公司的研发流程、软件质量保证的工作以及如何从根本上去提高软件质量，工作中很多时候有“秀才遇到兵，有理说不清”的感觉，这时就更加需要控制自己的言语和情绪，找到合适的方式进行沟通，使问题最终得到解决。
2）对问题根源识别和归纳的能力，即透过现象看本质的能力。
3）举一反三的能力。
4）很强的沟通能力。
5）要适当强势，做好灵活性与原则性间的平衡的能力
6）客观、对事不对人的职业素养
4、质量保证人员的技能要求
● 软件工程/系统工程的理论、方法
● 工作过程标准
● 沟通、协调技能
● 基本的管理知识和技能
● 项目管理的理论、方法
● 质量保证工作的原理、方法
5、软件质量保证岗位等级
1）交警（初级）
像交警查处交通违章那样，直接向所发现的不符合项贴“罚单”即可。
2）医生（中级）
像医生那样对项目进行检查和诊断，发现问题并可以开出“药方”。
3）老师（高级）
像老师那样发现学生的弱项，并找到如何提高学生能力的方案，然后对学生进行辅导和培训。
版权声明：本文出自 mandy.wang 的51Testing软件测试博客：http://www.51testing.com/?417295
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任