这几天登陆51testing，发现了一些小小的变化，登陆的时候需要验证（个人觉得有点麻烦）；二是查看自己的日志时发现多了个评分级别（以后有的玩啦）；个人觉得51testing的这种改善精神特别可贵，相信51testing一定会越来越繁荣起来，:-)。。。。。

  不由得想起GOOGLE的一个变化----GOOGLE的在线翻译，刚开始的时候你必须要去选择语言，哪种语言---》哪种语言，我是个不折不扣的懒人，觉得很麻烦啊，于是不到万不得已的时候就不用这个在线翻译了，但是因为时常看一些外文资料，碰到一些生僻或之前没见过的词汇，有时候还是要看下，后来，忽然有一天发现GOOGLE这个语言后面多了个“转换”按钮，而且，它默认的是 英语--》中文；当时觉得特别感动。想起来佳能相机的广告词：佳能，感动常在。

   自己现在也在测试产品，真希望公司的产品也能多多作出些让客户感动的闪光点。

云”为企业开发人员及提供相关服务和工具的供应商带来了新机遇。对于测试团体来说，在面临新挑战的同时，他们也将得到新工具以解决Soasta公司CEO所说的关键问题：可以正式启动了吗？

位于加利福尼亚洲圣马迪奥的Keynote Systems公司副总裁Vik Chaudhary说：“测试人员必须能够有效率地对所有层面进行测试——从应用到云服务供应商。”

根据市场研究公司IDC的调查，到2012年，在云服务上的消费将提高三倍，达到420亿美元。IDC指出，在所有IT消费中，云计算占到25%的比例，并且到2013年，这一比例还将提高到三分之一。

IDC在概念上对“云服务”和“云计算”做了区分。他们认为，云服务是指“可以在网络上实时交付并使用的产品、服务和方案”。而相对的，云计算则被定义为用于开发和部署“可以在网络上实时交付并使用的产品、服务和方案”的基础设施或软件系统。

Chaudhary对此做了如下解释：“Schwab、Travelocity等企业多年来一直在开发自己的数据中心。而其中的关键问题是要对扩展性极强的应用程序进行管理，并保证最好的客户体验。为此，他们聘用了大量人员来做监控、测试和添加服务等工作。”而最近云设施技术的发展，比如Google App Engine，使得其它企业可以在Google的设施上运行他们的应用。“这意味着在云中部署应用的门槛已经相当低了。你不再需要数据中心或操作团队，而可以全力以赴地开发应用和功能。这是一种应用开发范例的转变。”

对于测试人员来说，这同样意味着一种转变。Chaudhary举例道：“比如你构建了一个应用，可以通过黑莓手机使用，并托管于一家云公司（Salesforce），Salesforce要运行一定量的测试以保证服务可以正常使用。但是，对于应用本身来说，它是运行在1部手机上还是50部手机上呢？你是否需要加载一个非常大的页面呢？”另外，云托管公司可能会使用第三方的服务来提高性能。其对于测试结果就是，终端用户的体验将受到公司、云供应商和所有其它相关团体的影响。

减少测试成本

Lounibos说，加利福尼亚山景城的Soasta公司有一个正在逐渐扩大的客户群，他们没有自己的服务器，所有的操作都在云环境下进行，“尽管如此，他们的大部分操作还是比较传统的；他们与托管服务供应商合作，对云领域只做适度地深入。”然而，他也指出，基于云的测试也是企业了解云并减少测试成本的一个途径。

“传统的客户认为测试是一个扔钱的无底洞。他们一直在寻找可以减少成本的方法。对于公司来说，云计算的主要问题是，它是否足够可靠。而测试不同。云环境下的测试只是模拟真实的情况，它并不涉及与生产相关的问题。但是它确实可以减少成本。”

Lounibos说，通过云计算，测试人员“能够访问并使用大量的计算资源，而这正是测试所需要的。这个主意实在是太诱人了：你可以在5到8分钟内准备好125台服务器，但只需要按测试时间支付费用。你再也不需要为Web应用准备大型测试实验室了。”

比如，可以使用Soasta的CloudTest虚拟云环境测试实验室或设备。它支持负载、性能、功能和Web UI/Ajax测试。

而Keynote公司则为测试和分析互联网云上的Web应用提供了KITE (Keynote Internet Testing Environment)。通过KITE，可以在桌面及地理位置不同的各个位置随时进行测试。

Chaudhary认为，互联网应用的性能测试特别需要在云环境下进行。“对于互联网应用来说，这不只是应用本身的问题，它涉及所有相关的供应商。你无法决定用户是使用DSL还是拨号，或者是移动设备。性能测试本来就是取决于环境的。”
对于移动应用，Chaudhary认为，性能测试和功能测试都应该在云环境下进行。他说：“对于移动应用来说，功能测试同样也取决于供应商。你有一个可以登录的显示屏，即使应用可以正常运行，网页的大小、显示屏的大小，以及所有供应商也都会对其产生影响。”通过在云环境下进行测试，企业就能更容易地对上百种设备进行测试，同时节省更多的成本。

市场研究公司Enterprise Management Associates副总裁Dennis Drogseth认为，对于在云环境中的应用来说，“你要测试与应用有关的网络性能、服务器性能、数据库性能、软件性能，以及它在客户端上的缓存情况。如果你只有在某个位置上运行的一个应用，你当然可以在一个位置上对其进行测试。但是对于Amazon或Facebook来说，应用分布在许多不同且无法预测的位置上。这种情况显然要比运行一个基于单一服务器的应用测试脚本复杂得多。”

我们所面临的问题就是，要在各个不同的组件和地理位置上运行测试以确定问题，而“企业的应用开发通常无法使用这种环境。因此，Keynote（以及其它类似公司）就为这些测试人员提供了一个可用的环境，让他们可以利用互联网云和各种可能出现的情况，使用真实的网络和桌面。”

对新测试工具的需求

Drogseth认为现在需要新型测试工具。“你不能再使用为LAN或独立服务器准备的测试工具来进行云计算。所以，我们需要可以让我们了解网络和桌面等相关问题的工具。我们要让开发人员进入网络环境。”

Lounibos也认为，“在将来五年的时间里，所有的测试工具供应商都会进入到云领域。届时将产生新一代的测试公司。云计算是一块有巨大潜力的市场，因为这就是我们使用服务的方式。”

   一、一定要提交！！ 
    1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
    2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
    3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
    4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
    5． 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。

    二、程序不是测试人员写的，出问题也不是测试人员的原因。
    至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。

    测试人员的任务只是尽力重现问题，而不是必须重现！！

    三、下次再遇到的时候，拉他们来看就可以了。
    因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。

    而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )

    四、你可以告诉程序员，测试过程是没有错误的。
    测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。

    需要让程序员理解，测试人员是帮助他们的，不是害他们的。

    客户那里发现问题比测试员发现问题结果要严重的多。

    五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。
    在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。

    问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。

    实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。

    至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现（仅仅出现一次）。

    这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有bug，是否可以说程序员工作不到位的呀）。

    六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。
    我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。

    其实只要自己尽到心就可以了，管别人怎么说呢。

    七、我们使用的状态有：
    程序员处理的状态（由测试员提交的Action）：等待处理的，再次出现的。

    测试员处理的状态（由程序员提交的Action）：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。

    经理处理的状态（由测试员提交Action）：管理员处理的。经理还可以删除记录。

    按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。

    最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”（由测试员或经理确认）和“暂不修改的”（比如下一个版本处理等）。

    呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。

    八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：

  

测试挂起/恢复条件

  测试挂起条件为：当测试执行过程中发现有阻塞用例的时候，改测试系统被挂起。

  测试恢复条件为：测试被挂起的条件已经被解决                              

 

 

 用例最后的结果状态有4个：失败（不符合预期结果）、成功（不符合预期结果）、阻塞（当测试步骤中有一步异常，不能执行下去）、另外一个就是删除（用例和需求有冲突，或用例已经不再适合更新的需求）；

 

  测试挂起即用例阻塞，即用例执行不下去了，我们的开发说，不会出现阻塞，要么就报BUG，然后修正，要么就通过，事实上并不是这样的，如果一个功能或设置是其它好多功能的验证时的条件，但是就是这个功能或设置不能通过，那么，就会引起挂起事件；当然也还会有另外一种更糟糕的情形，那就是数据库除了问题，或者系统经常崩溃，测试的执行根本执行不下去，那也要引起挂起事件；

 

  因此，测试挂起的条件应该如下：

  1》测试执行中用例出现阻塞

  2》数据库出现比较严重的处理问题---数据库处理问题时经常出错

  3》系统经常崩溃

 

出现以上问题，必须出新的版本，将问题修复了，再进行测试。

为什么要写测试用例？写了测试用例有什么好处？好的测试用例是什么样子？

写测试用例的目的，首先是出于验证设计功能、性能点的需要，而必须要有针对性地给出每个功能点、性能点的验证方法，用例即是一种验证方法，基于这样的出发点，写测试用例的首先要满足的点是：测试用例必须覆盖所有的功能点、性能点，然后才是通过各种测试用例的设计方法，设计出好的测试用例。

好的测试用例是什么样子？测试艺术一书中这样说，好的测试用例就是能够发现至今为止没有发现过的错误，可是这样的测试用例是需要费很多时间的，而且，真正的设计严密的用例，只是一个具有严密逻辑的用例，看上去是好的，但是也未必，因为用户的法则是多种多样的，而且有很多时候，好的用例也许只是自己临时的一个闪念而已，但是就是这突如其来的灵感，能找出至今从未发现的BUG，所以，我觉得，好的测试用例，首先保证覆盖性，然后是保证正反用例的需求，最后是保证用例的严密逻辑性。

于是，测试用例的好处，首先，它能保证你测试的时候不遗漏测试功能点、性能点；然后它还可以在执行了N多个似乎重复的用例后显得很疲倦时，它还有一个牵引作用，让人毫不费力地按照用例所写的步骤执行下去；它还是一个发散点，所有的自由灵活的测试，都是基于一个用例点开始，让我们去想到很多；当然它还是一份最基本的文档，这份文档告诉我们的项目经理，按照一般的代码量，我的用例数有没有达到，我们都做了哪些测试。

最后要引用一句测试达人说的话：测试的目的是为了让客户不发现 bug ，而不是因为寻找 bug 才进行测试。

对这句话，我深信不疑，所以，面对所有的问题时，首先想的是用户，而不是一味的钻牛角尖。

 

    第一次自己接受一个新项目的测试跟踪，整个项目有三方参与，开发方、产品方、以及测试。

首先开发方给一个大的需求，当时看到这个大的需求文档，觉得写得比较粗，看不出产品的会是什么样子。

完了之后产品给出每个模块的需求，每个功能都标出来了，我一看乐了，这样对我写用例有好处，用例写完了，等着测试呗。。。。。

测试版本终于出来了，我一看傻眼了，很多东西变了，不是我之前从详细需求文档里看到的样子，可是还是得测试，我逐个地跟开发核对信息，才知道他们在开发过程中自个变更了需求设计，而我对这些毫无所知，没办法，用例是边修改边测试.......哎，冒汗啦.........

通过这件事得出以下2个结论：

一、需求文档一定要参与评审，对里面有疑问或是觉得不合理的地方赶紧提（开发以及测试），避免之后需求大规模的变更；另外，模块之间的交叉部分也得留意。

二、制定需求变更信息表，一旦需求变更，开发方应该在测试之前通知测试，这样一来，测试这边就可以修改用例