性能测试新手误区（一）：找不到测试点，不知为何而测

　　性能测试新手误区（二）：为什么我模拟的百万测试数据是无效的？

　　性能测试新手误区（三）：用户数与压力

　　经常会有性能测试新手问这样的问题：

　　C/S的系统如何录制，应该选择什么协议呢？

　　待测系统A的一个功能，是由B系统调用的，也需要搭建B系统的测试环境并对其录制么？

　　我的回答是，先弄清楚你想测的是什么？对它而言，压力又是什么？

　 　新手总是想着如何录制客户端的操作，如何模拟客户端的点击。这种想法应该是受到了主流测试工具影响，性能测试的入门基本都是从工具开始，比如使用最广的 LR，其最方便好用的功能应该就是录制了。但是需要清楚的是，录制只是为性能测试提供便利的一个功能（可以傻瓜式的产生向服务器施加压力的脚本），录制本 身并不是性能测试的根本或者所必需，能够产生压力的那些脚本或是程序才是关键所在。

　　第一个问题，比如一个即时通讯类的软件如何测试？

　　首先要明确你想测的是客户端还是服务端，如果是服务端，那么服务端承受的压力是什么呢？

　　是每一条消息都要经过服务器么？

　　服务器是要将消息进行存储，还是仅仅转发？

　　不同的功能，如普通会话和多人会话，从服务端来看的区别是什么？

　　客户端是如何同服务端通信的，是采用了一些标准的开源协议（如XMPP），还是经过了自己的重新扩展？

　　……

　　为了回答那两个看似很简单的问题（想测什么？压力是什么？），其实你需要了解整个系统的运行方式。这些信息完全可以从一些设计文档或者开发人员的口中获取到，并不需要你能读懂源码。

　　如果我知道了这个软件使用了XMPP协议，一条普通的会话是客户端向服务器发送了这样一条信息：

消息类型：普通 接收人：A 消息内容：XXX

　　而多人会话是客户端发送了这样的信息：

消息类型：多人 接收人：A, B, C 消息内容：XXX

　 　那么应该会知道，表面上这些不同的功能，其实只是客户端发送信息中个别字段的区别而已。那么我就可以想办法直接向服务器发送这些信息，让服务器根据接收 信息的内容去完成相应的功能。也许根本没有必要去想如何录制客户端发起一个会话并发送消息这个动作，或者发送文件、群消息等等其他操作。

　　至于如何实现，如果你有编码能力，可以将开源代码引入到自己的测试代码中（需是标准协议），否者可能需要让程序的开发人员实现一个测试程序。不 要不敢开口，开发人员协助进行性能测试是很正常的，而且这种工作量不会很大，只是把程序中的一些代码封装成一个可配置可方便调用的执行文件。

　　让开发人员来实现测试工具不丢脸，怕的是你自己不知道测试工具应该实现成什么样。（当然，如果自己可以看源码来实现工具那就更好了）

　　第二个问题，同样的，所谓的B系统调用A系统这个动作，是如何实现的？

　　会不会只是一个简单的HTTP请求？

　　或者是调用A系统的一个webservice接口？

　　你要测的是A的这个功能么？

　　如果是，那我们为什么一定要通过B系统来录制这A的这个功能呢？完全可以直接向A发送请求或者是调用接口（如LR中的webservice协议）。

　　至于具体如何做，可能有很多现成的接口测试工具，也可能仍然需要开发人员的协助。比如B与A之间传递的数据是经过加密的，那对（黑盒）测试来说就会非常困难，这种情况下，确实有可能通过B来录制会更简单。

　　在51Testing上看到的一个问题，问如何测试一个统计报表的另存为（excel）功能。

　　点这个按钮后，服务器会生成一张报表，然后弹出浏览器的另存为对话框，保存为本地文件。提问题的这个人遇到的困难是，LR中好像没法录制“另存为”这个动作。

　　之所以会有这样的问题，根本原因还是没有理解系统的运行原理，没有区分哪是服务器、哪是客户端。

　　一般来说，这个过程是这样的：

　　1、点另存为按钮时，向服务器发送了一个计算报表的请求，这个请求中会包含一些参数，如报表类型、统计时间等等。

　　2、服务器计算完成后，将结果数据返回给客户端（浏览器）。

　　3、浏览器本身的功能，将数据保存为一个本地文件。

　　（这里假设了计算过程是另存为按钮触发的，如果是打开页面时就计算完，那点按钮时甚至有可能根本没与服务器进行交互）

　　如果明白了这个过程，那么就不会纠结于录制“另存为”这种事情了，你要做的只是向服务器发送一个请求，然后接收响应数据。

　　那么就不需要生成本地文件了么？当然不是，否则怎么验证返回的数据没有问题呢。只不过这个文件的操作需要自己来实现了，创建文件、写入数据、关闭文件。

　　最后再总结一下要点：

　　● 理解系统的运行原理

　　● 区分服务端和客户端

　　● 弄清楚你要测的是什么，哪些东西其实是可有可无的

　　● 要模拟的是服务器的压力，而不是客户端的操作

　　● 录制只是一种手段，很多情况下并不是最佳选择

　　● 开发人员的协助是应当的，但前提是你要明确的知道应该如何测试

相关链接：

性能测试新手误区（一）：找不到测试点，不知为何而测

性能测试新手误区（二）：为什么我模拟的百万测试数据是无效的？

性能测试新手误区（三）：用户数与压力

　　7、void*和C结构体

　　问：你能设计一个能接受任何类型的参数并返回interger（整数）结果的函数吗？

　　答：如下：

int func(void *ptr)

　　如果这个函数的参数超过一个，那么这个函数应该由一个结构体来调用，这个结构体可以由需要传递参数来填充。

　　8、*和++操作

　　问：下面的操作会输出什么？为什么？

#include<stdio.h>    int main(void)  {      char *ptr = "Linux";      printf("\n [%c] \n",*ptr++);      printf("\n [%c] \n",*ptr);        return 0;  }

　　答：输出结果应该是这样：

[L]     [i]

　　因为“++”和“*”的优先权一样，所以“*ptr++”相当于“*(ptr++)”。即应该先执行ptr++，然后才是*ptr，所以操作结果是“L”。第二个结果是“i”。

　　9、问：修改代码片段（或者只读代码）

　　问：下面的代码段有错，你能指出来吗？

#include<stdio.h>    int main(void)  {      char *ptr = "Linux";      *ptr = 'T';        printf("\n [%s] \n", ptr);        return 0;  }

　　答：这是因为，通过*ptr = ‘T’，会改变内存中代码段（只读代码）“Linux”的第一个字母。这个操作是无效的，因此会造成seg-fault或者崩溃。

　　10、会改变自己名字的进程

　　问：你能写出一个在运行时改变自己进程名的程序吗？

　　答：参见下面这段代码：

#include<stdio.h>    int main(int argc, char *argv[])  {      int i = 0;      char buff[100];        memset(buff,0,sizeof(buff));        strncpy(buff, argv[0], sizeof(buff));      memset(argv[0],0,strlen(buff));        strncpy(argv[0], "NewName", 7);        // Simulate a wait. Check the process      // name at this point.      for(;i<0xffffffff;i++);        return 0;  }

　　11、返回本地变量的地址

　　问：下面代码有问题吗？如果有，该怎么修改？

#include<stdio.h>    int* inc(int val)  {    int a = val;    a++;    return &a;  }    int main(void)  {      int a = 10;      int *val = inc(a);      printf("\n Incremented value is equal to [%d] \n", *val);        return 0;  }

　　答：尽管上面的程序有时候能够正常运行，但是在“inc()”中存在严重的漏洞。这个函数返回本地变量的地址。因为本地变量的生命周期就是 “inc()”的生命周期，所以在inc结束后，使用本地变量会发生不好的结果。这可以通过将main()中变量“a”的地址来避免，这样以后还可以修改 这个地址存储的值。

　　12、处理printf()的参数

　　问：下面代码会输出什么？

#include<stdio.h>    int main(void)  {      int a = 10, b = 20, c = 30;      printf("\n %d..%d..%d \n", a+b+c, (b = b*2), (c = c*2));        return 0;  }

　　答：输出结果是：

110..40..60

　　这是因为C语言里函数的参数默认是从右往左处理的，输出时是从左往右。

　　摘要：12个C语言面试题，涉及指针、进程、运算、结构体、函数、内存，看看你能做出几个！

　　1、gets()函数

　　问：请找出下面代码里的问题：

#include<stdio.h>  int main(void)  {      char buff[10];      memset(buff,0,sizeof(buff));      gets(buff);      printf("\n The buffer entered is [%s]\n",buff);      return 0;  }

　　答：上面代码里的问题在于函数gets()的使用，这个函数从stdin接收一个字符串而不检查它所复制的缓存的容积，这可能会导致缓存溢出。这里推荐使用标准函数fgets()代替。

　　2、strcpy()函数

　　问：下面是一个简单的密码保护功能，你能在不知道密码的情况下将其破解吗？

#include<stdio.h>  int main(int argc, char *argv[])  {      int flag = 0;      char passwd[10];      memset(passwd,0,sizeof(passwd));      strcpy(passwd, argv[1]);      if(0 == strcmp("LinuxGeek", passwd))      {          flag = 1;      }      if(flag)      {          printf("\n Password cracked \n");      }      else      {          printf("\n Incorrect passwd \n");      }      return 0;  }

　 　答：破解上述加密的关键在于利用攻破strcpy()函数的漏洞。所以用户在向“passwd”缓存输入随机密码的时候并没有提前检查“passwd” 的容量是否足够。所以，如果用户输入一个足够造成缓存溢出并且重写“flag”变量默认值所存在位置的内存的长“密码”，即使这个密码无法通过验 证，flag验证位也变成了非零，也就可以获得被保护的数据了。例如：

$ ./psswd aaaaaaaaaaaaa  Password cracked

　　虽然上面的密码并不正确，但我们仍然可以通过缓存溢出绕开密码安全保护。

　　要避免这样的问题，建议使用 strncpy()函数。

　　作者注：最近的编译器会在内部检测栈溢出的可能，所以这样往栈里存储变量很难出现栈溢出。在我的gcc里默认就是这样，所以我不得不使用编译命令‘-fno-stack-protector’来实现上述方案。

　　3、main()的返回类型

　　问：下面的代码能 编译通过吗？如果能，它有什么潜在的问题吗？

#include<stdio.h>    void main(void)  {      char *ptr = (char*)malloc(10);        if(NULL == ptr)      {          printf("\n Malloc failed \n");          return;      }      else      {          // Do some processing          free(ptr);      }        return;  }

　　答：因为main()方法的返回类型，这段代码的错误在大多数编译器里会被当作警告。main()的返回类型应该是“int”而不是“void”。因为“int”返回类型会让程序返回状态值。这点非常重要，特别当程序是作为依赖于程序成功运行的脚本的一部分运行时。

　　4、内存泄露

　　问：下面的代码会导致内存泄漏吗？

#include<stdio.h>    void main(void)  {      char *ptr = (char*)malloc(10);        if(NULL == ptr)      {          printf("\n Malloc failed \n");          return;      }      else      {          // Do some processing      }        return;  }

　　答：尽管上面的代码并没有释放分配给“ptr”的内存，但并不会在程序退出后导致内存泄漏。在程序结束后，所有这个程序分配的内存都会自动被处理掉。但如果上面的代码处于一个“while循环”中，那将会导致严重的内存泄漏问题！

　　提示：如果你想知道更多关于内存泄漏的知识和内存泄漏检测工具，可以来看看我们在Valgrind上的文章。

　　5、free()函数

　　问：下面的程序会在用户输入'freeze'的时候出问题，而'zebra'则不会，为什么？

#include<stdio.h>    int main(int argc, char *argv[])  {      char *ptr = (char*)malloc(10);        if(NULL == ptr)      {          printf("\n Malloc failed \n");          return -1;      }      else if(argc == 1)      {          printf("\n Usage  \n");      }      else      {          memset(ptr, 0, 10);            strncpy(ptr, argv[1], 9);            while(*ptr != 'z')          {              if(*ptr == '')                  break;              else                  ptr++;          }            if(*ptr == 'z')          {              printf("\n String contains 'z'\n");              // Do some more processing          }           free(ptr);      }        return 0;  }

　　答：这里的问题在于，代码会（通过增加“ptr”）修改while循环里“ptr”存储的地址。当输入“zebra”时，while循环会在执 行前被终止，因此传给free()的变量就是传给malloc()的地址。但在“freeze”时，“ptr”存储的地址会在while循环里被修改，因 此导致传给free()的地址出错，也就导致了seg-fault或者崩溃。

　　6、使用_exit退出

　　问：在下面的代码中，atexit()并没有被调用，为什么？

#include<stdio.h>    void func(void)  {      printf("\n Cleanup function called \n");      return;  }    int main(void)  {      int i = 0;        atexit(func);        for(;i<0xffffff;i++);        _exit(0);  }

　　这是因为_exit()函数的使用，该函数并没有调用atexit()等函数清理。如果使用atexit()就应当使用exit()或者“return”与之相配合。

LoadRunner 11：

http://219.239.26.11/download/8009651/9327422/3/zip/49/108/1286952922673_876/Software_HP_LoadRunner_11.00_T7177_15013.zip

http://h30316.www3.hp.com/prdownloads/Software_HP_LoadRunner_11.00_T7177_15013.z01?ordernumber=520699787&itemid=1&downloadid=57459549&merchantId=SGBU_ECATALOG&dlm=ON

 

官方地址

https://h10078.www1.hp.com/cda/hpdc/display/main/secure/download_bin.jsp?zn=bto&cp=54_4012_100__

破解方法：
安装好loadrunner11后
1)退出程序，把下载文件中的lm70.dll和mlr5lprg.dll覆盖掉..\HP\LoadRunner\bin下的这两个文件
2) 注意，win7的话一定要以管理员身份运行启动程序，启动后，点击 configuration->loadrunner license，此时可能会有两个许可证信息存在，退出程序，点击deletelicense.exe文件，来删除刚才得许可证信息（即时原来没有 lisense最好也运行一下）
3）再次打开程序， configuration->loadrunner license->new license，在弹出的输入框中输入license序列号AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB，点击确定，验证通过后，则破解成功！

注册码：golba-100: AEAMAUIK-YAFEKEKJJKEEA-BCJGI
        web-10000: AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB
提供一个超级license 最高支持6.5w个并发：AEACFSJI-YJKJKJJKEJIJD-BCLBR



qtp 11:

http://www.genilogix.com/downloads/unified-functional-testing/quicktest-professional-11.iso

 

 

功能性：

做测试做了8年，前两年做的是与硬件产品相关的测试，质量管理比软件行业要严格的多的多，原因是，大部分的应用软件代码出错，改下代码重新编译，打补丁，就ok了，而一旦硬件设计出错，或者零件用错，造成的成本损失会很大，严重的可能是电路板报废，更严重的是导致整批产品的报废。当然，软件出错也能造成无可挽回的损失，只是某些特定领域会要求很严格，知识相对于硬件来说，程序修改要比电路板的维修成本相对低一些。

因为这种现象的存在，所以很多国内企业，尤其是一些小型的企业，对测试重视程度不够，甚至没有专门的测试人员，可能有的是为了项目需要，设立了测试团队，1人测试团队也屡见不鲜，我就知道好多企业是一人测试组，而且还是应届生的也有。对于这样的企业，您无法想象测试人员的地位会是什么样，老板都觉得设置测试人员是组织架构需要，而不是为了质量需要，那开发人员对测试人员自然也是不太看得起。

由于专职测试人员并不参与产品的代码编写，所以给人一种非生产劳动力的感觉，而且大多企业都是用一些编码能力较弱的人去做测试。

在很多外企中，对测试相对国内会重视一些，对测试人员素质要求也较高，对测试人员培训也较重视，但是并不代表测试人员地位就高，一样是会有开发人员看不起测试的情况，这种看不起并不会流于表面，而是骨子里的，没人说出来，但是会存在，大家心知肚明。

然而我们有时候也会听到有开发人员说某某测试人员挺厉害的，那么怎么样才能做一名让开发人员佩服的测试人员呢？

一，编程语言

你至少要掌握一门语言，不管是简单的php，java，还是C++也好，或者其他的脚本语言python，perl还是shell也好，至少你用一种语言真正的做过一些事情，而且能拿来就用。

二，数据库

你至少要掌握一种数据库的DBA，对SQL的操作要熟悉，至少能熟练的运用JOIN进行查询，知道基本的HAVING的用法，如果你能写存储过程，并且能优化存储过程那当然更好了，测试人员离不开数据库的管理和数据库的操作。

三，操作系统

作为测试人员，各种操作系统你应该很熟悉，系统安装，配置，管理，一个都不能少，对于Linux，你至少要对一种系统做过系统管理，熟悉常用的命令行操作，具体要会哪些，建议google一下，用Linux的时候，尽量能用命令行，就不要去点鼠标，因为它不是windows，要改变这样的习惯。能在Linux下能安装和配置软件，最好建议大家自己下载source code，亲自编译，了解make file的原理。

四，扎实的软件测试理论

这是做为测试人员最基本的，不要连开发人员都知道的一些测试方法，我们测试人员竟然没听过，很多测试人员觉得理论知识我看过，以为自己就了解了，其实做过一段时间之后，你再回头去看理论，会有更多的收获，我工作多年之后再看测试方面的书籍，发现还是会有不同的收获，理论是实践经验的总结，不能说最好，但是如果说你设计测试用例的时候，如果每种方法都有涉及到，你肯定会发现用例覆盖率会高，而且容易发现bug。

五，尽量自己分析问题

发现问题了，怎么办？可以找相关的开发人员帮忙分析，但是我想说的是，在发现问题之后，能自己尽量的寻找线索，首先要确定非环境因素，比如检查配置是否全部正确，网络是否有问题等等，然后确定非环境因素后，保护现场，保存记录系统提示信息，如果有日志功能，那自己先根据日志查找一些线索，并把自己检查过的地方和做过的分析信息尽可能多的提供给开发人员，而不是仅仅把错误日志或者错误信息丢给开发人员让他们分析就不管了。

六，多涉猎一些项目之外的知识

不要做一个项目，就两耳不闻窗外事，做测试的就是要涉猎的广，跟开发不同，测试是要能接受任何类型的项目，因为测试是一门方法学，方法学是不受某个产品或者领域限制的，但是如果你对其他领域也了解的多，对你做测试是有帮助的，前沿技术你也要了解一些。

七，掌握一些安全方面的知识

往往系统安全是很重要的，如果你能提出一些系统安全方面的漏洞，那别人自然会觉得你考虑的比较全面，至于安全方面需要哪些知识，我觉得首先从网络安全入手，了解一些密码学方面的知识，比如了解常用的加密算法原理，比如报文加密传输协议原理，建议看一下hash的方法，这个简单容易理解，还比较容易举一反三。

八，提高沟通能力，懂得尊重开发人员

测试人员要面对的人员很多，客户，项目经理，开发人员，产品经理等，有时候你会全部都接触的到，那么沉默就不一定是金，有良好正确的沟通能力，会帮助你提高在其他人心目中的好印象，沟通不是能说就行，要正确的沟通，高效的沟通，就是能用最简洁的语言把事情描述清楚，沟通的好，你的人缘就会好，就自然会受到大家的欢迎，其他人也愿意与你合作，千万不要在背后评论开发人员，即使评论，也评论别人的优点有哪些值得我们学习，懂得尊重开发人员，即使是你技术比别人强，懂得尊重别人的人才能被别人尊重。

九，不要自己把自己的地位降低

很多测试人员觉得自己做的测试工作本身就没有技术含量，觉得自己的工作创造的价值少，没有挑战性，其实如果连你自己都看不起自己，那如何让别人看得起你呢？

总之，做测试，是一门技术，也是一门艺术，我们把世界分为三个层次：技术（Technology），科学（Science），艺术（Art），技术是底层的，科学高一层，艺术是最高层的，技术可以通过短时间内学会，而如果把技术上升为科学，是需要大量的研究和积累的，而艺术的层次，这个不是学的来的，你需要有天赋，比如乔布斯，他就是因为有了艺术的天赋才造就了成功的苹果。

看着上面这些，你会不会觉得做测试要比开发需要学习的东西更多呢？如果你这么想，那就是正确的，真正优秀的测试人员，绝对是要在综合能力方面超过开发人员的，因为，你懂得的不仅仅是一门技术，你已经掌握了一门艺术。

杨柳@ 广州

杨柳博客网原文链接：http://www.yangliu.cc/?p=311

银行系统性能测试策略探讨

一、      性能测试的四个方面

在一般的性能测试讨论中大家通常只围绕三个方面进行提问和总结：测试脚本如何编写，被测系统如何监控，性能瓶颈如何调优。大部分刚刚接触性能测试的人会纠结于脚本的编写，如何设置参数化、如何设置关联、何时插入检查点，各种论坛和讨论群里不断有人提出也不断有人解答。经过一段时间的经验积累后就会遇到如何监控被测系统，如何确定瓶颈并调优等问题，各种操作系统、中间件、数据库的监控和调整方法也被口耳相传。但我认为在性能测试的讨论中我们却忽略了另一个重要的方面：如何制定性能测试策略。

我认为完整的性能测试可以分为四个方面：1、测试策略制定；2、性能脚本编写；3、被测系统监控4、性能瓶颈调优。从流程来看这四个方面有先后顺序的关系，从领域来看这四个方面都有可深入研究的内容。

1、测试策略决定了性能测试如何开展，负载目标是否正确，场景模拟是否合理，好比战场上的指挥部，从全局设计战争的方向。

2、测试脚本编写决定了性能测试能否顺利执行，压力发起是否正确，好比战场上直面敌人的作战单位，需要真刀真枪的去拼杀。

3、测试监控决定了关注范围是否合理，能否发现瓶颈所在，好比潜入敌后的地下组织，要设置在关键的脉络上实时收集情况。

4、性能调优并不是所有项目都需要的，但一旦发现问题，调优就决定了测试能否完美收官，如战场上的特种兵，用专业的技能解决各种难题，非一时所能练成，所以我们大部分人都执著于此。

本文以笔者实际项目经验为基础，尝试探讨并总结银行系统性能测试策略制定过程中必经的步骤和所需考虑的内容。

二、      测试需求分析

1.       业务场景分析

测试银行核心系统时将柜员签到、签退、业务操作、批量等众多交易放在同一场景中执行，这样的场景在现实中是否存在？测试POS、ATM等渠道时将查询、动账类交易各按50%的比例分配，这样的比例是否正确？所有的性能测试都是以复现实际业务场景为目标。因此业务场景分析和选取务必严谨。业务场景应该从时间和空间两个角度考虑：

1.1  时间角度

分别以一年、一月、一天的角度观察，被测系统是否存在业务高峰时段。各高峰时段的重点交易是什么，交易比例如何。

1.2 空间角度

根据各分行业务特点不同，被测系统是否存在不同的高峰场景和交易，操作交易的柜员数量及一般操作时间是多少。

业务场景分析阶段应向业务、研发、运维等多部门了解被测系统需求，但就数据准确度而言，应多参考生产日志。对升级改造类系统，场景分析的数据可从老系统的生产日志中获取；对新开发的系统，分析数据可从业务上有关联的其他系统中获取，同时参考业务部门意见。典型业务场景可以不止一个，但一定要明确各场景中的交易和比例，不要模拟一个不存在的大混合！

2.       负载目标计算

与项目管理中的SMART原则类似，业务场景需转换成可量化、可衡量、可实现的负载目标才能进行性能测试，而负载目标要根据不同场景分别计算。根据上阶段收集到“原始”数据，本阶段可计算或指定出各种间接和直接的负载目标值，一般负载目标多从两种角度考虑：

2.1 前端角度

在线用户数量：间接负载目标值，可理解为所有能操作被测交易的用户（柜员）数量。

平均操作时间（思考时间）：间接负载目标值，与在线用户数量一同计算业务并发数量。

业务并发数量：典型场景中集中操作（不是绝对并发）交易的用户（柜员）数量。

2.2 后端角度

每秒交易数量（TPS）：根据日志计算出的被测系统应承受的每秒交易数量。

交易响应时间（TRT）：与TPS对应，负载场景下交易应达到的响应时间。

吞度量（Throughout）：LoadRunner中吞度量是以每秒收到的字节数计算，其实TPS也是吞吐量的一种，根据不同被测系统计算对应的吞吐量。

系统并发数量：区别于业务并发数量，系统并发数量更趋近于绝对并发。对长连接系统来说系统并发就等于允许的连接数，对短连接系统来说更多取决于架构。

被测系统CPU、Mem、Disk等指标值：多为指定值，如CPU利用率不高于80%等。

前端负载目标需要通过大量、广泛的业务和日志统计才能得出，如需记录下高峰时段操作交易的用户数量、估算用户状态比例、统计操作习惯等，由于考虑到人的因素，因此前端负载很难计算精确。前端负载目标适合交易关联不大、操作用户分散、无具体业务量要求的系统，如内控管理、培训考核、网银主页等（以B/S架构为主）。

后端负载目标则比较容易计算，如当前某省对公汇兑类交易日均8万笔，则TPS=80000/(6*60*60)=3.7笔/秒（对公按6小时计算）；核心系统联机交易平均响应时间在3秒以下等。后端负载目标适合交易关联度大、操作用户相对集中、有具体业务量要求的系统，以银行核心业务系统为主。

负责目标需要针对不同类型的被测系统计算合理的目标值，同时还需考虑2/8原则，未来业务量、用户量扩展等因素，这里不做赘述。

三、      测试环境设计

1.       硬件环境设计

大部分性能测试的硬件环境与生产相去甚远，受品牌、型号、部署方式（集群个数减少，软负载均衡代替硬负载均衡）等多种因素限制，无法直接将测试环境下的性能结果向生产环境做比例放大，因此硬件环境设计主要关注应用架构与生产环境一致（如应用、数据库服务器必须为集群方式），尽量减少性能测试中的硬件资源瓶颈（如数据库存储必须为SAN，发压与被测系统间网络带宽必须为1000M）。

2.       软件环境设计

软件测试环境可从两个方面考虑：

2.1 基础配置

确认操作系统、中间件、数据库和被测系统的版本与补丁与生产环境一致，但操作系统、中间件、数据库的内部参数应根据测试硬件环境做适当调整，可参考生产中的设置比例。

数据库分区、索引等必须与生产或预计投产时一致。

2.2 外联系统

尽量减少外联系统，因为外联系统越多，测试链条越长，环境越难维护，问题越难定位。可适当在被测系统中做挡板程序，模拟与外联系统的应答，但必须保证被测系统中的逻辑分支没有被屏蔽。

3.       铺底数据策略

性能铺底数据量的大小和分布情况会对测试结果产生极大影响，是场景设计阶段的重中之重！测试前对铺底数据的构造可从以下四个方面考虑：

3.1 表分区情况

确认测试环境与生产环境（或预计投产后）的表分区和索引分区规划一致，结合表清理策略确认典型场景中各分区、各表中的数据存量大小和分布情况。

3.2 表清理策略

确认生产环境（或预计投产后）的数据库表（尤其业务热表）清理和备份策略，与表分区情况配合，预铺数据并确保测试数据库表中数据存量与生产保持同一量级。

3.3 表维护策略

确认当前生产数据库表（尤其热表）和索引统计值更新、rebuild和reorg等操作的频度，在数据预铺中适当更新统计值，切勿在测试环境中频繁执行统计值更新等操作，造成虚假的性能表现。

如下图，更新统计值后表和索引的相关信息会统计正确，性能将得到一定程度的提升。

3.4 合理的业务数据

确认铺底数据中的柜员、行部、角色、权限、待处理任务等业务数据是否符合实际情况，切勿为图省事而创建超级行部、全能柜员和过量的待处理任务。

四、      测试场景设计

1.       发压数据策略

测试发压数据应在数据铺底时一同考虑，但发压数据需要和压力工具配合使用，可从以下四个方面考虑：

1.1 表分区情况

确认发压数据覆盖各表分区，且在分区中也需尽量离散，不要集中操作（主要是查询）同一范围内的数据。

1.2 表维护策略

通常生产环境中数据库表在日终结束后执行统计值更新，对应第二天营业时的数据状态，除柜员签到外，其余典型场景均发生在更靠后的营业时段，因此不要在刚刚执行完统计值更新的环境中执行正式的性能测试，建议再执行一段时间的数据预铺，模拟行部营业一段时间后的业务，这时再执行正式的性能测试，并记录结果。

1.3 被测交易分支

在能力允许的情况下应尽量多的阅读被测交易源码，或向开发人员了解程序逻辑和交易分支，确认发压数据可覆盖程序中所有重点路径。避免造成该复现的问题没有复现，该出现的瓶颈没有出现。

1.4 合理的业务数据

与发压工具配合，确认在测试过程中没有同一柜员并发操作交易，没有超出合理范围的待处理任务，以日峰TPS为负载目标时不要同时执行疲劳测试，这样会导致交易量远远大于实际。

2.       测试并发设计

并发设计与负载目标紧密关联，同样可分为前端、后端两种方式：

2.1 前端角度

使用工具模拟的并发数量代表业务并发用户数量，一个并发进程或线程即模拟一个操作交易的柜员，脚本中设置thinktime模拟平均操作时间，维持典型场景中各交易的用户比例，并做等比例递增，关注此时被测系统的处理能力。但需注意的是，受thinktime和响应时间等影响，业务并发数量≠系统并发数量，所以不能在结论中说“被测系统只能承受XX并发”。且业务并发数量与在线用户数量的换算不可能完全精确，所以也不能用类似10个业务并发即代表100个在线用户的粗略换算为结论。

2.2 后端角度

使用工具模拟的并发数量不代表用户数量，也不完全等价于系统并发数量，它仅通过并发的形式对被测系统产生压力。由于后端角度更关注TPS，因此并发递增时各交易之间的并发比例可能会变化，响应时间变慢的交易会增加更多并发以维持预期TPS。

后端角度重点关注并发增加时的TPS和响应时间变化趋势，确定被测系统的处理能力。

五、      测试策略维护

测试策略应在测试执行前确定，执行过程中不做大的变更，但仍需根据测试结果不断反思和维护策略，确保性能测试能够真实复现生产场景。

六、      总结

工欲善其事必先利其器，在性能测试中我们的武器不仅仅是发压和调优工具，还有测试的思想！性能测试不是一个流水化作业的过程，它必须深入被测领域，对业务和技术进行全面了解才能正确执行。本文探讨并总结了银行系统性能测试策略的制定，由于经验有限，难免会有偏颇和遗漏，请批判阅读，同时对其他领域的策略制定也是抛砖引玉。

     ERP(Enterprise Resource Planning)企业资源计划系统，是指建立在信息技术基础上，以系统化的管理思想，为企业决策层及员工提供决策运行手段的管理平台。

　　一天中午，丈夫在外给家里打电话：“亲爱的老婆，晚上我想带几个同事回家吃饭可以吗？” (订货意向)

　　妻子：“当然可以，来几个人，几点来，想吃什么菜？”

　　丈夫：“6个人，我们7点左右回来，准备些酒、烤鸭、番茄炒蛋、凉菜、蛋花汤……。你看可吗？” (商务沟通)

　　妻子：“没问题，我会准备好的。” (订单确认)

　　妻子记录下需要做的菜单 (MPS计划) ，具体要准备的东西：鸭、酒、番茄、鸡蛋、调料…… (BOM物料清单) ，发现需要：1只鸭蛋，5瓶酒，4个鸡蛋…… (BOM展开) ，炒蛋需要6个鸡蛋，蛋花汤需要4个鸡蛋 (共用物料) 。

　　打开冰箱一看 (库房) ，只剩下2个鸡蛋 (缺料) 。

　　来到自由市场，妻子：“请问鸡蛋怎么卖？” (采购询价)

　　小贩：“1个1元，半打5元，1打9.5元。”

　　妻子：“我只需要8个，但这次买1打。” (经济批量采购)

　　妻子：“这有一个坏的，换一个。” (验收、退料、换料)

　　回到家中，准备洗采、切菜、炒菜…… (工艺线路) ，厨房中有燃气灶、微波炉、电饭煲…… (工作中心) 。

　　妻子发现拨鸭毛最费时间 (瓶颈工序，关键工艺路线) ，用微波炉自己做烤鸭可能来不及 (产能不足) ，于是阅览室在楼下的餐厅里买现成的 (产品委外) 。

　　下午4点，接到儿子的电话：“妈妈，晚上几个同学想来家里吃饭，你帮忙准备一下。” (紧急订单)

　　“好的，你们想吃什么，爸爸晚上也有客人，你愿意和他们一起吃吗？”

　　“菜你看着办吧，但一定要有番茄炒鸡蛋，我们不和大人一起吃，6：30左右回来。” (不能并单处理)

　　“好的，肯定让你们满意。” (订单确定)

　　“鸡蛋又不购了，打电话叫小店送来。” (紧急采购)

　　6：30，一切准备就绪，可烤鸭还没送来，急忙打电话询问：“我是李太，怎么订的烤鸭还不送来？” (采购委外单跟催)

　　“不好意思，送货的人已经走了，可能是堵车吧，马上就会到的。”

　　门铃响了。

　　“李太太，这是您要的烤鸭。请在单上签一个字。” (验收、入库、转应付账款)

　　6：45，女儿的电话：“妈妈，我想现在带几个朋友回家吃饭可以吗？” (呵呵，又是紧急订购意向，要求现货)

　　“不行呀，女儿，今天妈已经需要准备两桌饭了，时间实在是来不及，真的非常抱歉，下次早点说，一定给你们准备好。” (哈哈，这就是ERP的使用局限，要有稳定的外部环境，要有一个起码的提前期) 。

　　…… ……

　　送走了所有客人，疲惫的妻子坐在沙发上对丈夫说：“亲爱的，现在咱们家请客的频率非常高，应该要买些厨房用品了 (设备采购) ，最好能再雇个小保姆 (连人力资源系统也有缺口了) 。

　　丈夫：“家里你做主，需要什么你就去办吧。” (通过审核)

　　妻子：“还有，最近家里花销太大，用你的私房钱来补贴一下，好吗？” (最后就是应收货款的催要)

　　现在还有人不理解ERP吗？记住，每一个合格的家庭主妇都是生产厂长的有力竞争者。

本文转自：我在这里个人博客

http://www.51testing.com/?action/viewspace/itemid/84586.html

Parasoft白盒测试工具集

工具名	支持语言环境	简介
Jtest	Java	代码分析和动态类、组件测试
Jcontract	Java	实时性能监控以及分析优化
C++ Test	C,C++	代码分析和动态测试
CodeWizard	C,C++	代码静态分析
Insure++	C,C++	实时性能监控以及分析优化
.test	.Net	代码分析和动态测试

Compuware白盒测试工具集

工具名	支持语言环境	简介
BoundsChecker	C++,Delphi	API和OLE错误检查、指针和泄露错误检查、内存错误检查
TrueTime	C++,Java,Visual Basic	代码运行效率检查、组件性能的分析
FailSafe	Visual Basic	自动错误处理和恢复系统
Jcheck	M$ Visual J++	图形化的纯种和事件分析工具
TrueCoverage	C++,Java,Visual Basic	函数调用次数、所占比率统计以及稳定性跟踪
SmartCheck	Visual Basic	函数调用次数、所占比率统计以及稳定性跟踪
CodeReview	Visual Basic	自动源代码分析工具

Xunit白盒测试工具集

工具名	支持语言环境	官方站点
Aunit	Ada	http://www.libre.act-europe.fr
CppUnit	C++	http://cppunit.sourceforge.net
ComUnit	VB,COM	http://comunit.sourceforge.net
Dunit	Delphi	http://dunit.sourceforge.net
DotUnit	.Net	http://dotunit.sourceforge.net
HttpUnit	Web	http://c2.com/cgi/wiki?HttpUnit
HtmlUnit	Web	http://htmlunit.sourceforge.net
Jtest	Java	http://www.junit.org
JsUnit(Hieatt)	Javascrīpt 1.4以上	http://www.jsunit.net
PhpUnit	Php	http://phpunit.sourceforge.net
PerlUnit	Perl	http://perlunit.sourceforge.net
XmlUnit	Xml	http://xmlunit.sourceforge.net

主流黑盒功能测试工具集

工具名	公司名	官方站点
WinRunner	HP-Mercury	http://www.mercuryinteractive.com
Astra Quicktest	HP-Mercury	http://www.mercuryinteractive.com
Robot	IBM Rational	http://www.rational.com
QARun	Compuware	http://www.compuware.com
SilkTest	Segue	http://www.segue.com
e-Test	Empirix	http://www.empirix.com

主流黑盒性能测试工具集

工具名	公司名	官方站点
WAS	M$	http://www.micro$oft.com
LoadRunner	Mercury	http://www.mercuryinteractive.com
Astra Quicktest	Mercury	http://www.mercuryinteractive.com
Qaload	Compuware	http://www.empirix.com
TeamTest:SiteLoad	IBM Rational	http://www.rational.com
Webload	Radview	http://www.radview.com
Silkperformer	Segue	http://www.segue.com
e-Load	Empirix	http://www.empirix.com
OpenSTA	OpenSTA	http://www.opensta.com

测试管理工具典型产品的比较

工具名称	QC/TD	ClearQuest	BMS	Bugzilla
流程定制	Y	Y	N	Y
查询功能定制	Y	Y	Y	Y
功能域定制	Y	Y	Y	Y
用户权限分级管理	Y	Y	Y	Y
Email通知	Y	Y	Y	Y
构架模式	B/S	C/S,B/S	B/S	B/S
报表定制功能	Y	强,集成Crystal Report	有标准报表和高级报表,定制功能不够	Y
支持平台	Windows	Windows, Unix	Windows	Linux, FreeBSD
支持数据库	Oracle, M$ Access, SQL Server等	Oracle, M$ Access, SQL Server	SQL Server等MSDE	MySQL
安装配置的复杂度	简单	有些复杂	容易	不复杂
许可证费用	昂贵	昂贵	适中	免费
售后服务	国内有多家代理公司提供相关服务	在国内有分公司提供技术支持	技术支持和服务体系完备	可自行修改源代码
与其他工具集成	本身又是测试需求、测试案例管理工具, 与winRunner, LoadRunner集成，并且具有多种主流Case工具接口Add-In	与rational公司的其它产品无缝集成，特别与Clear Case配合以可实现UCM的配置管理体系	M$ VSS, Project	开源配置管理工具CVS
公司背景	世界主流测试软件提供商	已被IBM合并,世界著名软件公司	微软与上海市政府新成立的软件企业	世界著名开源项目

 软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。
1 数据和数据库完整性测试
数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
数据库完整性原即：
主码完整性：主码不能为空；
外码完整性：外码必须等于对应的主码或者为空。
数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支1持测试的工具和技术。
比如，有两张表：部门和员工。部门中有部门编号，部门名称，部门经理等字段，主码为部门编号；员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。
员工类型如下定义：0：职工，1：职员，2：实习生。但数据类型为Int，我们都知道Int占有4个字节，如果定义成char(1).就比原来节约空间。

2 白盒测试
白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
2.1 静态白盒测试
利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下：
Function NameGet(){
….
}
这是属于不符合开发规范的错误。
有这样一段代码:
if (i<0) & (i>=0)
…
这段代码交集为整个数轴，IF语句没有必要
I=0;
while(I>100){
J=J+100;
T=J*PI;
}
在循环体内没有I的增加,bug产生。
2.2 动态白盒测试
利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
看一段代码
if(I<0){
P1
}else{
P2
}
在调试中输入I=-1,P1程序段通过， P2程序段未通过，属于动态黑盒测试的缺陷

3.功能测试
功能测试指测试软件各个功能模块是否正确，逻辑是否正确。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。

4.UI测试
UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关
比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。

5.性能测试
性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试
5.1负载测试
负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？
5.2强度测试
强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。
5.3数据库容量测试
数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。
数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。
比如，在电子商务系统中，通过insert customer 往user表中插入10 000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100 000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；如果在规定的时间内显示出来，可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
5.4基准测试
基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。
5.5竞争测试
软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？

6. 安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。
6.1应用程序级别的安全性
可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？
6.2系统级别的安全性
可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？

7.故障转移和恢复测试
故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。
故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？

8.配置测试
又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等）
下面列出主要配置测试
8.1浏览器兼容性
测试软件在不同产商的浏览器下是否能够正确显示与运行；
比如测试IE，Natscape浏览器下是否可以运行这套软件？
8.2操作系统兼容性
测试软件在不同操作系统下是否能够正确显示与运行；
比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？
8.3硬件兼容性
测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用.
比如在INTER,舒龙CPU芯片下系统是否能够正常运行？
这样的测试必须建立测试实验室，在各种环境下进行测试。

9.安装测试
安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。

10.多语种测试
又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。
本地化测试还要考虑：
l 当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
l 要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。
l 要考虑各个国家的民族习惯，比如龙个美国中被理解邪恶的象征，但翻译到中国，中国人认为为吉祥的象征。

11.文字测试
文字测试测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。
比如：“比如，请输入正确的证件号码！”何谓正确的证件号码，证件可以为身份证，驾驶证，也可为军官证，如果改为“请输入正确的身份证号码！”用户就比较容易理解了。

12.分辨率测试
测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。

13发布测试
主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试
13.1说明书测试
主要为语言检查，功能检查，图片检查
语言检查：检查说明书语言是否正确，用词是否易于理解；
功能检查：功能是否描述完全，或者描述了并没有的功能等；
图片检查:：检查图片是否正确
13.2宣传材料测试
主要测试产品中的附带的宣传材料中的语言，描述功能，图片
13.3帮助文件测试
帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能。
13.4广告用语
产品出公司前的广告材料文字，功能，图片，人性化的检查

14 文档审核测试
文档审核测试目前越来越引起人们的重视，软件质量不是检查出来的，而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料：
文档审核测试主要包括需求文档测试，设计文档测试，为前置软件测试测试中的一部分。
14.1需求文档测试
主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；
14.2设计文档测试
测试设计是否符合全部需求以及设计是否合理。

总结
据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计，得出这样一个结论：软件缺陷在开发前期发现比在开发后期发现资金，人力上节约90%；软件缺陷在推向市场前发现比在推出后发现资金，人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的，可以根据产品的具体情况进行组装测试不同的类型。

前段时间公司招聘软件测试人员，虽然基本上都是招的应届毕业生，但我还是从现实以及网络上找到了一些应聘软件测试/QA的面试问题集，当然这个也都不会有标准答案的，现在只是以偶的一点理解加上网上的一些内容列举出来供有需要的XDJM们作一下参考：
1. 首先一般都是比较老套点的问题：介绍一下你的经历。
   HOHO......这个问题我想谁都被问过吧，注意一下重点，不要紧张慢慢说就OK了。
2. 老套话说了就可以马上切入正题了。根据你的经验说说你对软件测试/质量保证的理解？
    这个就要仁者见仁、智者见智了，也基本上都是书上的东东，如果能有一些自己独特的想法那就最好啦，呵呵 。
3. 理解完了那当然就要问一下是不是对软件测试了解啰。这就轮到问软件测试的流程是什么，你原先的公司又是怎么的流程了？
    前面个问题也还是书本上的东西，一般介绍软测的书上都有，实际上国内一般的中小公司根本就达不到书上所说的那些个测试规范，测试流程也是如此，没办法，这就是现在我们整个大的测试环境，这个问题照着书上说的办就行了，后面那个知道该怎么做了吧，尽量把原来公司的测试流程言简意赅的表达出来。
4. 接着问题就可以有一大堆了，这些问题很多都是要看自己的测试经验以及对测试的理解来作答了，如：
    (1) 你对SQA的职责和工作活动(如软件度量)的理解：
SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程（如果有相应的CMM规程），对于不符合项及时提出建议和改进方案，必要是可以要高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。ＳＱＡ主要的工作活动包括制定
SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等；
   (2) 说说你对软件配置管理的理解：
项目在开发的过程中要用相应的配置管理工具对配置项（包括各个阶段的产物）进行变更控制，配置管理的使用取决于项目规模和复杂性能及风险的水平。软件的规模越大，配置管理就显得越重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并且只有经过授权后才能变更这个标准。配置管理工具主要有CC,VSS,CVS等，偶只用过CVS，对其它的不熟悉
   (3) 怎样写测试计划和测试用例：
简单点，测试计划里应有详细的测试策略（测试方法等），合理详尽的资源安排等，至于测试用例，那是依赖于需求（包括功能与非功能需求）是否细化到功能点，是否可测试等。 
   (4) 说说主流的软件工程思想(如CMM，CMMI，RUP，XP，PSP，TSP等)的大致情况以及你对它们的理解：

   CMM:SW Capability Maturity Model 软件能力成熟度模型,其作用是用于软件过程的改进、评估及软件能力的评鉴

   CMMI:Capability Maturity Model Integration　能力成熟度模型集成　CMMI融入了大部分最新的软件管理实践，同时弥补了SW-CMM模型中的缺陷
RUP:rational unified process 是软件工程化过程。它提供了在开发机构中分派任务和责任的纪律化方法.它的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品,个人认为：它的核心观念是开发的迭代，每个公司可以根据自身的软件开发的流程和待开发项目的特点对RUP进行适当的剪裁，制定出符
合自己的软件开发流程。
    ＸＰ：extreme program，即极限编程的意思，适用于小型团队的软件开发，想上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性，强调测试（重点是单元测试）先行的理念。编程可以明显提高代码的质量，持续集成对于快速定位问题很有好处。
    PSP ,TSP 分别是个体软件过程（Personal Software Process），群组软件过程（Team Software Process）大家都知道，CMM只是告诉你怎么做但并没有告诉你如何做，所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做，PSP强调建立个人技能（如何制定计划、控制质量及如何与其他人相互协作等等）而TSP着重于生产并交付高质量的软件产品（如何有效地规划和管理所面临的项目开发任务等等）
总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。
   (5) 对项目管理、白盒测试、单元测试、自动测试、性能测试、压力测试工具的了解程度和实际使用经验。(其实基本上也就是MI和Rational工具)：
这个就要看个人的了，没法说了
   (6) 其它一些具体的技术知识(如各种计算机语言的了解程度、数据库等)；
5. 还有问一下你是怎样保证软件质量的，也就是说你觉得怎样才能最大限度地保证软件质量？
测试并不能够最大限度的保证软件的质量，软件的高质量是开发和设计出来的，而不是测试出来的，它不仅要通过对软件开发流程的监控，使得软件开发的各个阶段都要按照指定的规程进行，通过对各个阶段产物的评审，QA对流程的监控，对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方
式，是软件质量保证工程的一个重要组成部分。
6. 然后紧接着就基于目前中国的国情，大多数公司的软件项目进度紧张、人员较少、需求文档根本没有或者很不规范，你认为在这种情况下怎样保证软件的质量？(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量，因为这些公司一般就是这种情况-----既不想投入过多又想保证质量，faint )
出现以上的情况，如果仅仅想通过测试来提高软件质量，那几乎是不可能，原因是没有足够的时间让你去测试，少而不规范的文档导致测试需求无法细化何谈足够且有针对性进行测试。所以，作为公司质量保证的你应该先后项目经理确定符合项目本身最适合的软件生命周期模型（比如RUP的剪裁，原型法）,明确项目的开发流程并督促项目组按照此流程开展工作，所有项目组成员（项目经理更加重要）都要制定出合理的工作计划，加强代码的单元测试，在客户既定的产品交付日期范围之内，进行产品的持续集成等等，如果时间允许可以再配合客户进行必要的系统功能测试。
7. 差不多了就该问一些只和软件测试相关的问题了，如：
   (1) 你觉得怎样才能做一个(或者，怎样才能算一个)优秀的测试工程师？(faint，这个问题好像是必问的，答案也无非是什么要求全面的技术能力、缜密的逻辑思维、出色的沟通能力、还要有怀疑精神、幽默感、洞察力等等。啥叫优秀啊？该有的能力都有，不该有的也有，而且个个能力还都是出色的，这就是优秀，呵呵，
开玩笑的，反正这个问题差不多就这样，具体的什么要求网络上也到处都有。
    (2) 还有其它的如对自己优缺点的评价、自己的职业理想、为何离开上一家公司、自己在职业生涯中印象最深的事情、能否出差和加班、能否承受压力和挑战、薪水要求、何时能到岗等等这些啥面试都要回答的问题，这个就只能自己斟琢着办了。
    (3) 另外还有一个重要的问题就是语言能力啦，尤其是英语水平，这个的话每个具体的公司都有不同的要求，也就没啥好说的了。
差不多基本上就是这些了，如果有需要的可以有针对性的google一下，hoho...仅供参考!

做好软件测试的一些关键点
本文作者 未知 摘自 机电之家
1.测试人员必须经过测试基础知识和理论的相关培训。
2.测试人员必须熟悉系统功能和业务。
3.测试必须事先要有计划，而且测试方案要和整个项目计划协调好
4.必须事先编写测试用例，测试执行阶段必须根据测试用例进行
5.易用性，功能，分支，边界，性能等功能性和非功能性需要都要进行测试
6.对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据
7.测试设计的一个重要内容是要准备好具体的测试数据，清楚这个测试数据是测哪个场景或分支的
8.个人任务平均每三个测试用例至少应该发现一个BUG，否则只能说明测试用例质量不好
9.除了每日构建的冒烟测试可以考虑测试自动化外，其它暂时都不要考虑去自动化。


软件测试员自身素质培养
　　（1） 首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。
　　（2） 善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是
对的。
　　（3） 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。
　　（4） 保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。
　　（5） 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。
　　（6） 灵活一些，聪明一点，多制造一些容易产生bug的例子。
　　（7） 在有条件的情况下，多和客户沟通，他们身上有你所需要的。
　　（8） 设身处地为客户着想，从他们的角度去测试系统。
　　（9） 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。
　　（10） 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。
　　（11） 提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。
　　（12） 追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。
　　（13） 幽默感，能和开发小组?br />

写这篇文章主要有两个目的。
　　1、 对自己这一年零八个月的工作进行回顾和总结，把第一份工作的记忆都写下来；
　　2、 自己做了一年多的软件测试工程师，对软件测试工作算是有一定程度的了解，希望与大家分享我的感受和经历。
　　
　　先介绍一下我的背景：通信类院校05年毕业、本科、计算机专业，毕业后进入一家大型通信设备商工作，任职软件测试工程师。
　　
　　一、T项目执行
　　
　　05年7月13日入部门，此时才知道自己被分配到了测试部。部门主管把我领走后，就把我交给了导师。
　　
　　入部门的头几天，主要熟悉公司的工作环境，认识部门同事，了解产品知识。由于我们是做传输设备的，所以当时学习的产品知识主要以SDH原理为主，包括SDH的帧结构、网络的保护和倒换等。
　　
　　下面介绍一下我所做的项目。
　　项目名称：T软件
　　
　　项目概况：该项目是在PC和Sun工作站上开发的软件，属于CS结构。Client端用Java开发(开始使用JDK1.3，后来改用JDK1.4)，实现跨平台；Server端用C++开发，使用ACE实现跨平台（Windows和Unix）。
　　人力投入：开发好像是9人，测试3人。（我来的时候是产品的第2个版本，人力投入大概如此）
　　
　　我入部门几天后，T项目就进入了测试阶段。我的任务就是执行分配给我的测试用例。当时我只知道根据测试用例描述的内容，去点鼠标，如果发现程序出现错误或异常，就填写问题单。我就这样没有任何思考的按着测试用例点了3个月的鼠标 : )
　　
　　现在想起当初的测试工作，实在有太多的不足，和待改进点。
　　
　　1、 测试用例。对于一个软件的测试来讲，测试用例是至关重要的。测试用例要覆盖所有测试规格，而且测试用例要易于理解、易于执行，简单的讲就是要描述的规范。而当时我们的测试用例却是一团糟，最糟糕的是用例的质量很差，使用这些测试用例，根本无法保证产品质量。测试用例的预置条件、操作步骤、预期结果的描述也是乱糟糟的，而且用于存储测试用例的Excel表格设计的很差，界面很不友好，从一定程度上降低了测试效率。
　　
　　2、 产品知识。T软件虽然是在PC和工作站上运行的，但是开发T软件的目的是为产品服务的，所以我们必须具备产品知识，才能更好的对T软件进行测试。恰巧当时包括我导师在内的3个人，都不太了解产品，所以就造成我们无法判断某些测试用例是否验证通过。从而导致了与开发人员的多次争吵。

　3、 软件测试的重点不明确。软件测试是软件工程中的一项重要活动，它尽可能发现程序中存在的缺陷，保证程序的质量。但软件作为一种商业品，有它的发布时限，老板说这个软件要1月份发布，你总不能测到12月份再给他发布吧。当时我们在一些小问题上与开发人员纠缠过多，而很多重点却没有得到重视，一些严重问题暴露的比较晚，导致测试时间延了又延，版本测了一个又一个，想起那些日子，只能如此描述：“累并痛苦着”。 : (

4、 测试流程的把握。7月份中旬，T项目从开发部转到测试部，进入了测试阶段，实际当时的产品质量并不能达到转测试的标准，而我们却让他们通过了转测试，结果就给我们自己带来了巨大的痛苦。而且后续的几个版本也如此，我们是测了一轮又一轮，测的我们都要绝望了。回头想一想，T软件还真的是我们测出来的，而不是开发写出来的 : )

5、 缺少针对性测试。软件也可以分很多种，不同的软件有不同的特点，自然就需要针对性的测试了，譬如GUI的软件与嵌入式软件的测试方法肯定有很大不同。最初我们在做T项目测试时，就缺少针对性方法。有两个教训让我们刻骨铭心：1、界面测试，T软件发布后没多久，其他组同事就发现某界面一个按钮的单词拼写错误——“rollback”被写成“roolback”；2、效率测试，软件测试到后期才发现T软件在实际环境中运行效率很低，根本无法满足达实际应用的需要。从那以后我们就准备了专门针对T软件的测试项目，包括：界面测试、效率测试、资料测试、稳定性测试等。

6、 沟通问题。自从工作开始，开发人员和测试人员的争吵从来就没有停止过。最初是什么问题都吵，很多没有意义的争吵甚至非理性的争吵，庆幸的是现在的争吵大多是有针对性的、理性的。个人觉得以前无为争吵过多的原因是：开发人员、测试人员的工作技能和职业素养都比较欠缺。吵了大半年后，人员提升了工作技能和职业素养后，吵架都吵的比较有默契了。当然最重要的是开发人员和测试人员的目标要一致：保证产品的质量，满足客户需求。

二、自动化测试
　　06年过完年后，我被主管派到一个大组去学习自动化测试技术。这个测试组是个比较大的测试组，总共有几十号人，其中有很多牛人。他们的自动化测试框架就是由几个牛人耗时1年多开发出来的。到现在，他们的自动化用例覆盖率约50％，应用率好像有70％，总之这个自动化测试框架还是满牛X的，不过就是整个框架实现太复杂了，涉及的编程脚本就用了三种 : (
　　
　　下面简单介绍一下该GUI自动化测试框架。
　　测试工具：IBM Rational Robot
　　自动化测试技术：第三代自动化测试框架，叫什么DDE，具体什么意思已经记不住了 : )
　　测试脚本：Robot中使用的是sqabasic脚本（基于basic的一种脚本），另外还使用了TCL、COM组建等，并自行开发了一个抓包工具用于自动化测试。还有我们测试的产品界面是使用Java开发的，如果要让Robot能够正常识别界面，还需涉及到Java编程。呵呵，实现上可是够复杂的 : (
　　
　　学习自动化的头一个星期，我只是学习该测试组的产品知识，学习如何使用自动化测试。后面的几个星期就开始承担自动化测试的建设任务了。想想当初自己还是满辛苦的，白天上班学习产品知识，晚上回家就对着电脑看basic脚本的语法，周末还去公司无偿加班看代码。

在技术文档的选择上，我基本只看英文的，单词不懂就拿金山词霸查，实在看不懂了才会去找些中文的资料看。为什么要选择英文的呢？因为很多中国写书的人很浮躁，只想着快点把书出版了好赚钱，所以很多中文的资料质量很差。首先要贬低的就是那本谭教授的《C语言程序设计》。记得读大学时，照着谭教授的书敲程序，没多少程序能编译通过的，真是误人子弟。
　　当时带我学习自动化的导师姓L，他是个大忙人，有时一整天都在开会。L的师傅姓W，W是该自动化创始人之一。我呢，充其量算是徒孙一辈，呵呵。由于L太忙，而且不那么爱说话，于是乎我就只能自己对着文档看代码。
　　当时对我比较有用的文档就只有两篇：一篇是汇集型的chm文档，是篇比较全面的介绍，其中包括自动化框架的介绍，原理的介绍，各模块介绍，自动化执行的流程等；另外一篇则是由W写的自动化建设指导书，写的还是满不错的，在我有一定基础后，照着指导书就能完成简单的自动化建设。

在我整个学习过程中，是按照以下的过程开展的：1、初步了解整个自动化和产品知识，尝试使用自动化进行测试；2、熟悉sqabasic语法；3、对着文档读代码，尝试调试脚本，跟踪到代码的最底层。
　　其实最好的学习方式就是实践，去做自动化建设。当有一定基础后，去完成导师交给的自动化建设任务，就是最好的学习方式。后来，我教别人的时候，也是安排实际任务给他做，然后再进行相应的引导。
　　在我的学习期间，有件事情让我满讨厌的。就是我必须给原部门的主管和测试组人员讲课，然后那些家伙会不停的提问，以检验我的学习效果。虽然这招很BT，但是对个人的成长还是满有利的。假设你学会了一项技能，此时你可能只在第一个层次上，如果你能够把这项技能教会别人，那么你的层次上升了一个档次。
　　记得当时是06年2月初去参加学习的，4月初就应急被调回原测试组了。总共不到两个月的时间，我总共完成了3个模块的自动化建设，第1个模块搞了3个多星期，第2个模块不到2个星期，第3个模块一个星期就搞完了（第3个模块算是友情支援呢，哈哈）。
　　4月初被调回原测试组后，就一直做救火的工作。差不多5月份的时候才正是开始做我们T项目的自动化。其实也就是把我学习的自动化框架移植过来，做T项目自动化测试。
　　另我比较遗憾的是，T项目的测试一直都很紧，而自动化测试并没有被推广和充分利用。直到我离职前，测试组为应付测试部自动化考核指标，才得到重视。

这里我谈一下自己对自动化测试的理解。
　　1、 自动化测试用于提高测试效率；
　　2、 自动化测试可以完成一些无法手工完成的测试，例如长时间不间断的测试；
　　3、 自动化虽然能够发现问题，但主要是对继承的功能进行测试，保证以前的老功能。（这个跟项目有关， GUI自动化测试比较复杂，如果是嵌入式设备或芯片的自动化测试，对自动化测试的理解可能会不一样）

三、开发小工具
　　我在自动化学习期间，表现出来的专业技能和良好的学习能力，得到了同事和主管的认可。鉴于此，在4月中旬的时候，测试组的Leader给我安排一个任务，使用Excel表格开发一个工具，用于收集和统计记录的数据。要求该工具能够代替手工计算，提升测试效率。任务完成的截至日期是五一。给我安排的时间大概为一周。
　　该工具的实现方式并不难，就是设计一个Excel表格，然后在里面嵌入VBA脚本，以宏的方式代替手工计算。对我来说最大的挑战就是：1、短时间内学会VBA编程；2、提取需求，设计Excel表格的格式，使该工具具有较好的易用性。
　　当我接到任务后，下班回家就开始到网上搜集关于VBA资料。当时我找了一个星期，都没有让我满意的文档。最终只找到一篇国人写的PDF文档，但是那篇PDF文档只是让我初步了解了VBA是个什么东东，并不能满足我的实际需求。最终，在写VBA脚本期间，我还是参考微软自带的帮助文档搞定的。（搞忘球当初是否装了MSDN）

本来计划是在四月底的一个星期开展该项任务，但实际上直到4月的最后两天我才有时间。记得当时，我花了一天半的时间与我的客户——也就是我的同事，共同讨论需求，并设计Excel表格的格式，让其评审。最终写脚本花费了4月的最后一个下午，以及五一期间的三个下午的时间，总计4个下午的时间，完成该工具的开发。而且我五一期间的工作并没有申报加班，是无偿劳动啊 : (
　　另外，令我欣喜的是，从此我成了我们组的“牛人”，哈哈哈哈。。。。。。
　　其实工具开发完成后，还是有些问题，如：
　　1、 程序崩溃（不小心除了0，呵呵，加入异常处理就OK了）；
　　2、 有1/3的功能基本没有被使用（郁闷，花那么大精力。。。我的五一啊）；
　　3、自动生成的表格，奇丑无比（直到现在，我都没改，哈哈）。
　　
　　记得当时有个做了5年以上C++的开发人员，看到我写的Excel表格，居然说“诶，这东西还满神奇的嘛”。我当时的一个感觉就是，晕，这个家伙工作效率肯定不高。
　　Excel还真是好用，功能强大啊！

四、负责M项目测试
　　06年10月份，我开始独立负责M项目的测试工作。M项目是个小项目，大体情况如下：
　　代码量：大约10K行
　　开发语言：C#
　　软件环境：Windows PPC 2003
　　硬件环境：hp的PDA（具体型号忘了，反正是便宜货，大概1000块）
　　人力投入：开发3人，测试就我1人
　　M项目的测试需求分析、测试设计、测试用例编写、测试执行到测试报告，全部由我一个人搞定。
　　
　　06年10月～12月中旬这段时间，主要是完成前期的测试分析与设计。12月中旬，就进入了实际的测试阶段，07年1月底，软件发布。回顾这4个月的工作，有做的好的，也有做的差的。下面对这些进行总结。
　　做的比较好的：
　　1、 测试进度把握比较好，在规定时间内，甚至提前完成了测试任务；
　　2、 与开发人员的沟通较好，使问题能够较顺利的解决，基本没有内耗，双方合作愉快；
　　3、 测试的重点把握较好，把很多严重问题，在测试前期就给暴露出来了；

做的不好的，待改进的：
　　1、 前期的测试分析能力较弱，测试规格分析不全，测试用例编写质量不是高。到后期测试时，才发现很多规格没有覆盖到，需要补充测试用例。而且之前写的测试用例与实际测试情况，有些偏差，用例的可用性差，又花了很多时间去修改用例。
　　2、 前期的测试计划制定比较差，实际工作较之计划偏差过大。反正10月、11月那段时间，M项目的工作是乱七八糟的，还好关键时间点的把握还算到位。
　　3、 测试对象选择上疏忽，导致漏测。M程序是个工具软件，主要用于查询和设置设备的某些参数或配置。我当时只考虑到对所有支持的设备进行遍历，却未考虑到设备上所有单板的遍历。结果技术支持工程师到香港试用该工具时，发现某块叫PM1D的单板无法识别。后续，我们对大部分单板进行了遍历，还发现了很多隐藏的问题。这是一项较大的疏忽。
　　4、 在做内部模拟试验局测试时，对测试环境的选择有较大疏忽，导致漏测。在做内部试验局的时候，我为了偷懒只选择了3个不同设备的组网测试，而没有考虑到大规模组网情况下的测试。后来，技术支持工程师拿M软件到广州试用时，程序的某项功能就不正常了，原因就是大规模组网时，通信数据的传输是多包的，而M程序的底层函数没有对多包的情况进行处理，导致该项功能不正常。当时，在其他实验室是有类似环境的，而我却为了偷懒 : (
　　
　　虽然M项目的测试有很多不足，但是总体情况良好，我对产品的质量有信心 : )

五、救火
　　大概是06年7月份时，我们组组长跟我说，要派我到B组去学习3个星期。等我去了B组才发现自己是被派来救火的。来B组支援测试，主要是完成一项测试任务，说具体点，就是把一件事情干600多次，没任何技术含量。我当时真是郁闷坏了 : (
　　
　　虽然心底是比较郁闷，但毕竟也就3个星期，想着忍忍就过去了。
　　具体的任务很简单：大概有80种板子，每种板子大概有8套软件，用T工具对80多块板子把8套软件都加一次，观察软件加载过程中，业务是否正常，板子加完软件后，运行是否正常。
　　
　　还有一个也是其他组借调过来的新员工，跟我一起干这件事情。我600多次，他也差不多600次。还好这个家伙，心态很好，做事情也很勤奋。
　　
　　最初B组给的方案是这样的：先用第1套软件把80多个板子加载一遍，再用第2套，第3套，直到第8套。
　　
　　开始工作几天，我们就按这种方案执行，但按这种方案执行的效率很差。主要因为实验室常用的板子差不多只有30块，其他的板子都藏在箱子里，而且有些板子B组根本没有，需要到其他项目组去借，这样针对软件版本，对80多块板子进行轮循加载，效率就很低，因为每加一套软件，就要去寻找80多块板子。
　　
　　当时，我和那个新员工都很愁，按照这种做法，这项任务3个星期根本就无法完成。B组负责带我们的两个员工，也表示比较无奈。
　　
　　郁闷过的第2天一早，我就直接找B组的老大谈话，“按照你们提供的这种方案，我们在三个星期内根本无法完成任务，而且还有诸多其他困难：1、部分板子是坏的；2、某些板子实验室里根本就没有；3、对设备不熟悉。”
　　
　　就这样，B组老大把组内相关骨干人员都叫过来开会，重新商讨了一套方案，并要求他们全力支持我们的工作。
　　
　　开了会后，B组的人就比较支持我们的工作了，启用新的方案后，还提前了1天时间把工作完成 : )
　　
　　这里我体会比较深的是：在做一份工作前，一定要弄清楚这项任务到底要做些什么、要怎么做、要做到什么程度，工作中还要定期汇报工作（基本上以日报、周报的形式，用邮件发送），如果出现了解决不了的困难，一定要向老大汇报，如果老大也解决不了，那他也不能责怪你无能 : )

六、工作中的陷阱
　　在辞职前的几个月，有个师弟也是老乡X君，得知我做过自动化项目后，便来向我了解自动化测试相关的情况。
　　
　　从与X的聊天过程中了解到，他也正在做自动化，他们组测试的产品规模比较大，不过做自动化的只有两个新人，而且是使用一种新的GUI测试工具。他在给我讲他们具体工作时，了解到他们的自动化测试非常原始，就是针对一个用例录制一套脚本，几百个测试用例，大概录制几百个脚本，根本没有对公共进行提取，更别提有什么自动化测试框架了。X君与另外一个人，在自动化方面都是新手，没有相关经验，他们不知道这样做会给后期的维护带来多大的麻烦。而且他们主管也不太懂GUI测试的自动化，只是每天要他们汇报工作进度，期望在两个月内完成那几百个脚本。
　　
　　经过我细致询问后，我猜测他们做这项自动化工作，基本上是为了应付部门自动化考核而做的，而并非为了提高测试效率，保证产品质量。
　　
　　我也可以体谅X君主管的难处：测试组人力本来就紧张，而部门又要考核自动化指标，他只有弄两个人来应付一下部门的考核了。
　　这样说来，X君和他另外一位同事就是受害者了，被安排做一件这么没意义的事情。对他们我只能表示同情了。
　　
　　对于这类BT主管吩咐的没啥意义的事情，我的体会就是能推掉不做就不做，如果实在推不掉，就完全按照他的意思做，他要怎么做就怎么做，要做成什么样就做成什么样。实在搞郁闷了就老板炒鱿鱼吧。
　　
七、其他
　　记得刚进公司那一阵，对我们新员工有这样那样的培训，估计转正前至少被培训了20门课吧。具体讲的都是产品知识、测试技能、编程方面的东东。那些讲课的老师水平也参差不齐，PPT写的水准也有好有坏。总体感觉就是那些培训是在浪费时间，如果自己看这些资料效果都要好很多。
　　
　　在转正前，作为新员工要给部门的“老”员工讲课，讲自己所学习过的知识，然后下面的“老”员工会发狂了似的问你问题。现在我感觉这种方式真的是一种非常好的检验方法，不但检验了你的学习情况还锻炼了你讲解PPT的能力。
　　
　　通过这种方式，我觉得自己在很多方面有提高：
　　1、 写PPT的水平。后续工作中，写PPT汇报工作，做的是又快，又漂亮。
　　2、 沟通能力。最初别人问我一个问题，我还没完全理解他的意图，就以自己的理解，淅沥哗啦的说了一堆别人不想知道的东东，搞得别人一头雾水。此后，别人每问我一个问题，我都会先把他的意图或意思搞搞清楚了，确认后，再以最精练的语言来回答他的问题。
　　3、 懂就是懂，不懂就别乱说。记得最早“老”员工问我一个我自己不是很懂的问题，我通常是按自己的理解方式，跟他胡吹一通。结果他再一细问，我就傻了。知道就知道，不知道就别乱说，这点很重要，尤其是在参加面试的时候，如果自己不是很动，别人一问你就会露馅。
　　
　　写到这里，第一份工作的感受也写的差不多了。总的来说可以如此形容我这份工作：任务重、压力大、加班多，虽然公司也存在各种各样让人非常不爽的事情，但打心眼里我还是感谢它的——是它让我明白了什么是工作，锻炼了我的学习能力、抗压能力、沟通能力，培养了我的职业素养。虽然也有非常多的人在骂公司，但我希望它还是能越走越好！！！