测试是需要标准的，测试是严谨的，测试不是对的，就是错的。这些都是显而易见，不可否认的问题。但是在实际项目中，似乎要把所有这些都推翻。

    我自认为是个严谨的人，对每一处细节都力求完美。我也知道，正是因为这个原因，使别人认为我不够变通，甚至我自己有时候也很难说出为什么做事要如此按部就班。可我又相信，测试就是应该这么做的。

    有些人，是完全的实用派。写什么测试用例，需求一直变，写了也白搭。这个听上去很不专业，但是事实何尝不是这样呢？关于测试的理论知识，一艘一大堆，可以找到无数反驳这种“不专业”的做法。但这些人，似乎用最少的力气，完成了实际的任务。

    如何在两者间平衡呢？我觉得一个人的性格，和职业成长环境很有关系。我的性格是追求完美，公正无私。而我的职业生涯中，一直都在和电信，金融，实时系统等不容有半点错误的系统在打交道。之后又经过51testing的培训。使得本来就已经很严谨的我，更是接受了先进理念的熏陶，导致我现在“走火入魔”了吗？

    突然到了一家以小项目为主，快速追求利益的公司。我以前深得领导认可的，但也多少有点让领导讨厌的特点，现在似乎完全是讨厌多于认可了。经理两次跟我谈，让我要灵活变通，不要指望有标准，我们要控制时间，控制成本。唉，可我不知道怎么的，我乱啊，没有方向了。我走火入魔了吗？

    如何找到严谨和实用之间的平衡点，是我目前最紧急的事情。如何把严谨的态度灌输给团队，又如何在项目中用最小的代价，完成最多的任务。真是该清醒一下了。

    近日，新接了一个项目。是做一个小型的ERP系统。为期半年左右。开发6人，测试三人。外加一个PM，一个ERP顾问，一个PPQA。其中，顾问和PPQA都是兼顾好几个项目。

    在需求调研阶段，参与的人员为：PM，顾问，1个开发。调研结束后，生成了一批UserCase。其中以场景描述为主，类似一个原始需求。之后，没有进行分析，生成SRS。

    需求算是这样结束了，PM要求测试做做需求跟踪矩阵。要求将所有的UserCase进行分析，分析出所有的功能点，并加以细化，细化到每个字段。有点像是要我们生成SRS了。但我们不了解需求。通过阅读了大概一个星期的UserCase后，接受了一次需求培训。培训是按照各个功能点来解释，但没有总体的流程，因此我们对需求还是不太清楚。好在该项目是从一个老版本中，进行升级工作。我们根据老系统，想象着新系统的轮廓。当然，中间有着无数的疑问。

    但我们在做需求细化工作的时候，开发人员正在学习老系统的架构。约2周后，我们完成了需求细化的初稿。但我担心的是，在我们做需求细化工作，并生成RTM文档结构的时候，开发一点也没有参与。并且，开发人员已经进入了设计工作阶段。他们是怎么得知需求的呢？我去问PM，他们如何获取需求。PM回答道：他们会很清楚的。我就是很不理解，开发做开发的，测试做测试的，到时候，开发做出来的设计，和测试写出来的用例，能对的起来吗？

    还有一点，我们写出来的需求，并没有真正细化到可以写出测试用例。我看最多也就是定一个测试项的程度。而且也不能保证我们对需求的理解是正确的。更严重的是，需求还正在变化，开发人员似乎私下决定了一些变化。虽然我知道，这个工作肯定是逐步细化的，不可能一次完成。但是，我似乎看到了混乱的预兆。

    测试和开发间如何沟通？我提议PM进行RTM工作的评审，让测试和开发对需求的理解尽可能达成一致。PM答应下周评审。希望评审能达到效果。

    还有一点，PPQA的工作似乎看不到效果。我们的PPQA是从测试转PPQA的，不到2个月时间，可能经验上不足。按照我们的项目计划，我们采用双V模型。因此，PPQA应该保证我们的过程是经过验证和确认的。但是，似乎她没这个意识。

    在这种情况下，测试组应该如何保证质量？希望大家能给些意见。其实，这种情况也不少见，只是我经验不足，希望在这次项目中能有所锻炼，以后再碰到这种情况，能够成竹在胸。

    今日想学习一下JSP技术，结果看了点相关资料。其中介绍了SERVLET。作为起步阶段的我，对WEB开发可以说是一窍不通，所以在配置TOMCAT时，遇到了麻烦。开发人员又忙，没时间帮助我解决这些弱智问题。在晚上唰唰地搜，找到了一些零碎的资料，说得不详细。经过近2小时的不断尝试，终于配置成功。现在就总结一下，希望对初学者有帮助，至少能少花点时间在这种弱智问题上～

    首先，安装TOMCAT6.0。我下载了最新版本，没试过其他版本，第一从用TOMCAT。一路上点击下一步，结束。然后配置环境变量，在CLASSPATH下，增加 TOMCAT安装目录\lib\servlet-api.jar; 然后，就可以成功编译servlet了。不会再出现找不到javax包的错误了。

    我自己写了一个Servlet， BasicServlet.java，编译完后，生成.class文件。到TOMCAT的webapps\ROOT目录下，找到WEB-INF目录。进去后，新建一个classes目录，将之前生成的.class文件，放到classes目录下。不要问为什么，TOMCAT自己就会去那里找。然后回到WEB－INF目录，里面有一个WEB.XML文件。打开它，编辑。

加入：

<servlet>
        <servlet-name>BasicServlet</servlet-name>
        <servlet-class>BasicServlet</servlet-class>
  </servlet>
 
  <servlet-mapping>
        <servlet-name>BasicServlet</servlet-name>
        <url-pattern>/myServlets/BasicServlet</url-pattern>
  </servlet-mapping>

保存，重启TOMCAT。打开IE，在地址栏输入http://localhost:8080/myServlets/BasicServlet，你的Servlet就成功运行了！

我总结一下在这个过程中，我遇到的麻烦

第一就是不理解sevlet-name, servlet-class, serletmapping的意思。

sevlet-name可以随便叫你喜欢的名字，等于是一个代号

servlet-class一定要是你的class文件的名字

servlet-mapping就是将上面定义的servlet，映射成URL

servlet-mapping元素中的sevlet-name,就是你要对应的sevlet的代号，这里只有一个servlet，就是BasicServlet

url-pattern就是你在浏览器中，调用这个servlet所要输入的地址。设置成/myServlets/BasicServlet，那么链接地址就是http://localhost:8080/myServlets/BasicServlet

设置成/BasicServlet的话，那么调用地址就是

http://localhost:8080/BasicServlet

OK，现在明白了没？

第二就是把servlet-name和映射URL写错了。别以为不可能，我就是写错了～很郁闷。

唉，新手就是新手。希望这个总结对刚开始学习的兄弟们，能有所帮助。

    最近细细品味QTP的帮助文档，对于Windows API的调用吸引了我。因为我之前一直在研究VBS，想提高一下编程能力，加强QTP的脚本编写能力。当时就在想，VBS中似乎不能调用Windows API，而VB却可以。那么QTP中要调用Windows API，是不是和VB一样呢？我把我总结的东西说明一下。不一定都正确，我也在琢磨中，希望大家指正批评啊：）

先从VB中调用API开始

首先要声明需要调用的函数名和函数所在的.dll文件

Declare   Function   函数名   Lib   "libname"   [Alias   "alias"]   [([[ByVal]   variable   [As   type]   [,[ByVal]   variable   [As   type]]...])]   As   Type  

这里的Function，说明是带返回值的，若不带返回值，用Sub。这和VB函数一个概念

函数名： 就是你想注册的函数名。这个名字是随便取的，你爱叫啥就叫啥，只是命名规范要符合VB的规范，如不能特殊字符，不能和关键字相同等等。这里必须和Alias 同时解释。

Alias： Alias后面跟的，其实是真正的API函数名。是真正的啊，不是随便叫的哦！

        可以带Alias，也可以不带Alias。什么时候必须带呢？

        1. API函数参数带有String类型   原因：String类型可以分为ANSI和UNICODE两种。因此，一个函数就有ANSI和UNICODE两种版本。后面加A的，代表ANSI版本。加W的，代表UNICODE版本。例如CopyFileA，CopyFileW分别是两个API函数，支持不同的String类型参数，他们的功能则是完全一样的。

        2. API函数不符合VB的命名规范。API函数中，有些是奇怪的名字，如下划线开头的。_XXX，这在VB中显然是不合法的。哦，天哪，我前面忘说了，如果不带Alias，那么之前的那个函数名，必须和API函数的真正的名字相同。因此，如果API函数名不符合VB的规范，显然就没法用了。所以一定要使用Alias，在Alias后跟的真正的API函数名，是不受VB命名规范的限制的。这样，只要保持前面的函数名是规范的就行。

Lib： 表示指定API函数是在那个.dll文件中。这是必须的，否则上哪儿去调呀。如果引用的过程属于   Windows核心库（User32、Kernel32或GDI32），则可以不包含文件扩展名。而其他的，则最好用全路径加上文件名.dll。

好了，之后在VB中，直接用函数名来调用API的真正函数就行了。

其实很简单吧，就是自己想个函数名出来，然后将它与真正的API函数关联。在代码中，调用你想出来的那个函数，就等于调用了API函数：）

下面说QTP中的调用吧。看了一下帮助文档，晕了我一下。Extern.Declare micHwnd, "GetForeGgroundWindow", "user32.dll", "GetForeGgroundWindow"什么东西呀。镇定一下，哦，原来也差不多嘛。

猜一下它的申明格式： extern.Declare 返回值， 函数名，.dll文件， Alias

搞定，就是这样，呵呵。其实就是和VB一样的概念啦，只是申明的样子变了一下。还有啊，它的数据类型比较奇怪，我也不是很清楚，在下面的例子中会有的。

下面给出在VB和QTP中调用同一个API的例子：调用kernel32.dll中的CopyFILEA函数。

VB：

Private Declare Function myCopyFile Lib "kernel32" Alias "CopyFileA"(ByVal lpExistingFileName As String, ByVal lpNewFileName As String, ByVal bFailIfExists As Long) As Long

在代码里用myCopyFile，就等于条用了kernel32.dll中的CopyFileA。myCopyFile可以是任意的，只要你高兴，叫它aaa也行～～当然也可以不带Alias，但是函数名就必须是CopyFileA了

Private Declare Function CopyFileA Lib "kernel32" (ByVal lpExistingFileName As String, ByVal lpNewFileName As String, ByVal bFailIfExists As Long) As Long

QTP:

Extern.Declare micLong, "myCopyFile", "kernel32.dll", "CopyFileA", micString, micString, micLong

这里"myCopyFile"是自己起的名字，"CopyFileA"就是kernel32.dll中的真正的函数。只是这里的数据类型，为什么都是mic打头的呢？反正不太清楚怎么回事，在前面加上mic就拉到吧。。。

好了，希望对大家有帮助啊，互相讨论哦：）

    这几天一直没什么写作的感觉。但今天和以前的同事聊了会儿天，谈到了测试的苦恼。说测试经理老是催问测试通过了没。唉，这让我想到了以前工作的时候，也是忍受着这种折磨啊！不知道各位有没有也遇到这种烦恼呢？

    记得有一次，领导又来问，通过了没？我问他，怎么算通过了？他说你觉得差不多没问题，就算通过了。我真是晕倒！连个起码的测试通过标准都没有，还在吵吵闹闹的！心里这么想，当然不能这么说啦，只好说尽快。过了会儿，开发人员又来催了，说通过了没有啊，通过了我好提交版本了。我终于被迫无奈，为了赶上提交时间，停止了测试。转到客户手里，发现了许多的Bug后，又会听到“怎么做测试的”之类难听的话。当我发现一个Bug后，测试经理，开发人员，都会显得不太高兴，说怎么还没通过。而我说通过了，没问题了，他们则会皆大欢喜。然而最后客户发现了缺陷，他们一齐拿矛头指向我！真是无比郁闷的事情呀！

    问题在哪里？我认为最根本的原因，就是没有制定一个测试通过的标准。而把软件通过的标准，作为测试评定的依据。

    软件通过标准中，可能规定：没有重大缺陷，次要缺陷少于10个，再次要点的少于20个等等。

    我们测试是干什么的？找缺陷啊！我找到的缺陷多，说明我工作效率高啊，而不是说怎么又没通过！其实他们觉得，我找到了缺陷，就意味着需要更多的时间来修复缺陷。而测试经理和开发人员，都是关心项目进度的。也就是说，他们要保证软件能按时，按质量提交给客户。而怎么算达到了软件质量要求？那就是符合软件通过标准。所以他们在评价测试工作的时候，会拿着软件通过标准来作为评价测试工作的依据。

    是不是觉得很荒谬？但这种情况非常的普遍。如果你告诉你的测试经理，你发现了新版本中有10个缺陷，和你告诉测试经理，新版本中只有1个缺陷。你觉得哪个他会比较高兴？绝大多数是后者吧！

    你在新版本中，发现了10个缺陷，肯定比发现1个的工作量要大，而且说明你的测试质量更高。但在测试经理和开发人员眼里，反而觉得是你在拖项目的后腿。

    明白了吧，这就是他们对测试通过标准和软件通过标准的混淆，导致了错误评估测试工作。而且很好笑，你发现的错误少了，说明你工作好。你发现的错误多了，说明你工作不好。

    所以，一定要在测试前，就做好具体的测试通过标准。前往不能那软件通过标准来作为测试的通过标准！

    今天试着拿出以前公司的需求文档，想利用最近被洗涤过的测试思想，来重新设计一把用例。首先挑了段简单的SRS，是描述登录需求的。具体内容不便透露，呵呵。下面简单描述一下：

系统登录要求输入席位号，密码，并插入CA证书（U盘），输入CA密码。

    席位号：要求1到8位。不足8位，系统会自动左边补"0"，直到达到8位。席位状态冻结，则提示“席位已冻结”，登录操作失败。每个席位都对应固定IP，若IP对应补正确，则提示“安全验证失败”，系统登录失败。

    密码：8到16位。若密码错误，则提示“密码错误”。若密码过期，则提示“密码已过期”。

    CA密码：如果没有插入，提示“检测不到CA证书！”。CA密码错误，提示“CA密码错误”，系统登录失败。

这段需求其实写得狠烂，条理混乱（原文并没有按照各个输入框分别描述，而是东一句，西一句，没有任何归纳），有些情况根本没做交代。如CA密码的长度。

     这种情况，立刻想到了等价类加边界值的方法。   

     记得之前在公司写用例时，也是用的这种方法，但是并没有现在对等价类和边界值的思想理解得透彻。那时就是划分成有效等价类，无效等价类。结束了，没有考虑过输入条件。这样根据想象划出的等价类，根本就不知道是不是覆盖了所有的情况。

     今天就利用了真正的等价类划分法，来设计了一下。

     输入              输入条件        有效等价类          无效等价类

    席位号             1－8位          1－7位             0位

                                      8位               大于8位

                      必填             填                不填

                      是否冻结          否                 是

                      是否对应IP        是                 否

    密码              8－16位           8－16位            1－7位

                                                         大于16位

                      必填             填                  不填

                      是否过期          否                  是

                      是否正确          正确                不正确

   CA：               是否安装          安装                 不安装

                                                           CA损坏

                      密码是否正确      正确                  不正确

                       必填             填                   不填

    到这里，我的划分结束了。接下来选取数据就没继续了。感觉确实比以前的用例考虑得更透彻了，心里一阵高兴。希望各位高手指点指点，我的划分如何：） 

    现在的很多公司，做起项目来，需求变化速度之快，实在是让人防不胜防。而且基本上对SRS的修改，都是先斩后奏。开发人员一般都是直接和客户交流，直接改代码。更过分的是，他们改完之后，从来就不会第一时间通知需求组，通知测试组。感觉就像整个项目组都应该围着他转一样。

    这里我不想讨论需求为什么变化那么快，为什么会允许这样随意地变更。因为许多公司的现状就是如此，让他们形成配置管理的意识，不是一天两天能解决的事。或者有些企业，虽然知道配置管理的重要性，但是真正到了要落实的时候，就把原本订的配置管理流程束之高阁了。

    在需求变化频繁的情况下，作为测试人员，最重要的就是要搞清楚以下几点：

    1.哪些需求发生了变化

    2.这些需求变化后，对测试工作会产生哪些影响。包括会不会影响测试用例，如果影响，会对哪些用例产生影响。当发生较大改动时，还要明确是不是影响到了测试方案，甚至是测试计划？

    3.明确这些变化，会对自己的工作进度产生多大的影响。当发现自己的大部分用例都受到影响，需要修改时，应该第一时间向上级反映情况。由他定夺解决方案，而不是自作主张，或是一声不响。

    关于如何确定哪些需求发生了变化，最好的工具当然是需求跟踪矩阵了。需求跟踪矩阵是从开发和测试两条线，同时进行跟踪的。但是，要实现需求跟踪矩阵，可不是容易的事情。尤其对于需求变化频繁的公司来说，基本可以断定他们是没有配置管理的。那么需求跟踪矩阵就根本没有实现的可能。但是，公司没有，不代表我们自己没有。

    公司的测试任务分配，一般都是按照子系统或者是模块来分的。比如TesterA测试子系统A，TesterB测试子系统B。那么这时，我们完全可以只针对自己测试的子系统，完成需求跟踪矩阵。我们只需要自己维护测试线的需求跟踪，至于开发线，那可是管不着了。但是这里还是有点问题。我们一般理解的需求跟踪矩阵，是将SRS分成子SRS，然后针对每个子SRS，建立跟踪关系。但是忽略了各个子SRS之间的关联关系。要想把各个子SRS划分得没有一点联系，那是不太可能得。如果有两个子SRS，称为SRS1和SRS2，你测试的是SRS1相关模块，而SRS2相关模块是别人测的。当SRS1相关开发人员告诉你需求已变更后，你分析后得知影响到了SRS2，那么你必须和测试SRS2相关模块的测试人员及时沟通。你能保证做到这点，但是对方未必会在SRS2发生变化时，及时通知你SRS1受影响的部分。这时你需要事先和测试组的其他人员充分沟通，让他们及时通知可能会影响到你的变更。如果他们不及时通知，你就完全有推卸责任的理由了。对于开发人员也是一样，他们擅自改了程序，不通知变更SRS，或者不及时通知变更，你也完全有理由推卸责任了。

    我们的目标肯定是要把测试工作做好，而不是自己没有责任就好了。当建立了自己的需求跟踪矩阵以后，就可以快速定位变更部分，而且目前企业没有配置管理的理念，所以可以及时变更你的用例，方案，甚至是计划。当发现受变更影响的部分非常多时，应该及时通知上级，让他们了解情况，并做出决策。

    总结一下的：需求变化快，测试工作需要重新写用例，方案，甚至计划。这时遇到问题：

    1.得不到及时通知

      解决方案：没有办法，只能事先和开发人员以及测试组内部人员事前声明，不及时通知的部分，一概不付责任

    2.不知道需求变化后，对哪些工作产生了影响

      解决方案：公司没有配置管理，没有需求跟踪，那么就建立自己的小的需求跟踪。只跟踪测试线。把自己的工作做好，并及时通知其他受影响的测试人员。

    3.发现自己大部分用例，方案，甚至计划要重新修改，而没有充足时间

     解决方案：及时通知上级，让他给解决方案，而不是自己苦干。

   之前从来没有玩过blog，呵呵。看到那么多测试方面的高手，在这华山论剑，不免有点手痒了。希望从各位高手那边学到点看家本领，好让自己有一天也变成高手：）

    今天就谈谈我为什么会选择做测试吧。其实，也不是我自己选择的啦。我实习时，就被安排到了测试职位。那时听部门经理介绍，说测试怎么怎么好，多么多么有前景。当时也不肖一顾，心理想测试那么好，为什么都没人做呢！肯定是看我新来的，先让我从测试做起，熟悉一下公司的开发环境。

    没想到，这一做就做了1年半。起初，只是接受了一些简单的培训，基本上也不能算是培训！只是听了测试经理介绍了一下bug跟踪的流程。之后立即走马上任！加入到一个大型项目的测试工作。说来也真幸运，一个没有任何经验的测试员，加入到了一个由上海电信，ＩＢＭ，ＳＩＢＥＬ等那么多大公司共同合作的项目。但是之后才知道，所谓的IXXM，根本就是LJ。没有需求，更没有概设，没有详设。BUG就是靠嘴巴流转！要知道，那可是个百人以上开发团队的项目啊！简直是不敢想象。我的工作流程就是：把自己当作用户，操作系统，猜测系统要实现的功能，实在猜不出就去问那个IXXM的LJ项目经理（他也不是很清楚，要去转问开发的）。就着样折腾了1年半，唉！简直是浪费了青春。

    之后到了另一家金融行业的公司。虽然新公司的测试流程比之前公司有了较大好转，但实在是有很多我看不上眼的地方。当时我也没有接受过任何测试方面的培训，但凭我的直觉就知道，他们所谓的测试，很大程度上是在瞎搞，效率奇低！当我提出改善性意见时，遭到的就是白眼。后来知道，测试队伍中还有51Testing的学员。照理说51出来的，也不会差到哪里，但问题是他们也只是普通的测试员，没职位，没权利，根本推动不了流程的改进！我就这样郁闷了半年，忍不住了！我到底能学到些什么！我想学正宗的内功，而不是邪门歪道！

    经过心理斗争，最终选择放弃工作，来51学习。当时下了好大决心，拒绝了好几家大公司的OFFER，舍弃了看来还不错的薪资，想的就是能来51磨练自己，成为真正合格的测试工程师。

    我想对于测试行业，有很多人的经历和我一样吧。我的选择是接受培训，提高自我。但是提高自身能力后，是否能推动企业流程的改进呢？我看不见得。但至少当机会出现时，能发挥出自己的本领吧。

    培训也不是唯一出路，这是肯定的！对于招聘单位来说，经验还是第一位的（个人理解）。而且现在的企业，对测试的理解还不够深入，根本不了解自己需要什么档次的测试人员，导致盲目提高招聘要求，而给出的工资也是让人哭笑不得。比如2年以上测试工作经验，熟练使用WR，LR等测试工具。精通C＋＋，JAVA，VB等开发语言中的一种或几种。英语对话流利。求职者心理一定在想，老子有那么高水平的话，还到你这干！唉，但事实就是如此。

    世道混乱，但是我们的目标要明确！那就是不断提高自己，跟上行业的潮流。

    最后，不论你是通过培训，还是自己总结出自己的测试套路，希望多多和其他同行交流。1＋1是大于2的：）