• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新文件

• 从excel中取数据
• 在webtable中检查每一行的checkbox是否被
• 关于Webcheckbox属性赋值
• 转：qtp学习心得
• 数据驱动在QTP的运用
• Web的系统测试方法 二（转）
• Web的系统测试方法 一（转）

我的最新书签

• 转载：Rational Robot 的自动化功能测试
• 《LoadRunner 没有告诉你的》和《JMeter

我的最新日志

• 转载：要做好性能测试，该掌握些什么？

  2008-7-10

  http://www.cnblogs.com/jackei/archive/2008/06/27/1231307.html

  查看(50) 评论(0)

• 转载：关于测试人员的考核

  2008-7-09

  http://www.51testing.com/?1592/action_viewspace_itemid_82438.html

  查看(71) 评论(0)

• 如何有效的选择回归测试用例？

  2008-7-09

   今天看到51testing上有这个问题，觉得很值得探讨一下，就在此谈谈我的看法。

  关于这个问题，我粗粗的搜索以下网上的关于这个问题的说法，大都是空空理论之谈，实际操作起来并不一定适合。

  说到回归测试用例，先说什么是回归测试。顾名思义，回归测试就是修改完bug之后对程序的新的一轮测试，据微软的统计，按照他们的经验，一般开发人员解决3~4个bug会衍生出一个新的bug，这就是必须作回归测试的原因。简单的说，就是检测一下解决了bug之后有没有带进新的问题，以免把聋子给治成哑巴，就得不偿失了~~

  一般的软件测试的流程是后期快速迭代的，bug在后期是快速收敛的，debug和测试的周期也是越来越短，频率是越来越高，譬如说第一轮测试需要花上10天跑用例，那么到后期就没那么长的时间，可能就是1~2天的测试时间，在后期有时候一天就有一个新的版本，这时候就要求测试人员能快速的进行一轮回归测试。

  一般来说，覆盖越高，风险越低，但是效率就越差，反之亦然。所以如果时间允许的话，能把所有的用例都再跑一边是最好不过的，但是一般不会有那么多的时间，这就需要在效率和覆盖之间有一个适当的平衡，选择其中一部分测试用例用来作回归测试。

  选择回归测试的时候，首先要确定的是，回归测试用例的比例，这个要根据时间情况了，100%是最好了，我个人一般这个比例在60%左右。然后要确定回归测试用例的优先级。根据我的经验，一般有如下必须回归的用例：

  第一，新修改的功能，这个显然是重点

  第二，新修改的功能的关联功能，就是有耦合的部分，这个一般最好咨询一下开发人员

  第三，程序最有卖点或者说亮点的部分，这个地方一旦有问题，会使程序质量大打折扣

  第四，程序中最致命的部分，譬如说安全隐患，数据泄露，加密注册，

  第五，程序中比较脆弱的部分，这个要咨询开发人员，一般就是他们心中最没底的地方

  第六，程序的主干功能

  第七，如果以上做完，还有时间的话，最好把用例中级别比较高的用例再执行一遍。

  OK ，以上是回归测试用例的选择优先级。

  其实，即使这样做，还是有风险的。最根本的解决方法是自动化测试工具加上手工测试。具体就是常用的程序主干功能，主要功能，用自动化测试，保证每一个版本都能够执行一遍，其他修改频繁的小功能手工测试了。

  说了这么多，好像比较乱，总结一下。

  个人觉得解决这个回归测试的终极解决方案是：

  a.作每日构建

  b.基线功能自动化

  c.编写用例时一定要分级（按照风险度，常用度，重要度）

  d.手工执行回归测试用例（就是我上面说的7项）

  查看(62) 评论(1)

• 转载：微软测试有感

  2008-7-09

  最近和微软一哥们聊微软的测试，很有感触，记下来，和大家共同分享。

  全文如下：

  开头语：

  作测试很久了，一直为一些问题所困扰，也一直对微软有一种顶礼膜拜的向往，终于有一天，近距离的接触了微软的测试，感觉不是以前想象中那么遥不可及，却又难以企及。于是把个人觉得微软值得借鉴的地方整理了一下，希望能对大家有所帮助。

   

  1．  测试流程

  首先说说测试流程，微软的测试流程也没什么新的东西，和大多数的测试流程一样。

  大致是先进行测试准备，然后是Testcase的编写，然后是白盒测试（不一定每个项目都有），然后是功能测试阶段，然后是验收测试，最终release。

  如果看流程的话，和一般公司大同小异，没什么新花样。但是我觉得值得借鉴的是两点。

  第一，   微软的流程执行的非常认真。

  这点非常值得提倡，我们都知道，测试的最终质量决定于测试流程和测试人员素质，要想测试质量有保证，要么是流程很完善，要么你流程不行，但是个人能力超强。如果有一个很好的流程，就算执行的人稍微差点，最终的质量也不会差到哪里去。所以流程是很重要的。

  但是，看国内的公司欠缺的就是这个，要么是没有流程，要么流程是个花架子，没认真执行过。我想微软的测试人都是超级牛人，但是人家还是老老实实的忠实按照流程来走，我觉得这点非常好。（在IBM 也是这样，笔者以前在IBM作项目的时候，发现他们的文档写的特认真，流程特认真），所以说忠实的执行一个好的流程是成功的一大半。

  第二，   在整个流程中，微软非常强调测试尽早介入。微软在这方面是一致提倡的，按照我们国内IT业的恶习，一般都是软件主体差不多成型了，拉几个测试人员过来点点，其实这是非常不好的。微软的测试人员在项目一开始就和开发人员同步介入，在需求阶段就开始介入，进行需求评审。在开发人员开始编码的时候，测试人员就开始编写Test case，并开发一些测试工具，或者写一些配套的测试代码（不要奇怪，微软的测试人员都能写很好的代码）。微软的理念就是：预防bug比解决bug好，所以非常提倡测试尽早介入，把一部分bug消灭在需求阶段。

  2．  自动化流程

  说到自动化，大家可能以为我是说微软的自动化测试工具多牛，其实微软内部用到的自动化测试工具倒是不多，就算有也都是内部开发的，非常实用的，他们不会去用MI的工具。

          说微软的自动化程度高，主要是体现在流程方面，譬如说整个自动

      构建流程，在开发人       员代码check in之后，系统自动发邮件，邮

      件内容就是一个change list，包括代码更新list以及一个编译者添加的comment，其内容是该版本功能的变化或者修改掉的bug ID。整个测试过程中能用自动化的地方都尽可能采用自动化，尽可能减少人为失误，并且可

      以使人和机器并行工作。个人觉得，这点很值得我们国内的测试公司借鉴，能自动化的流程都自动化，减少一些不必要的沟通。

   

  3．  质量控制机制

  说到质量控制是个大问题，需要整个团队和流程提高素质。那么微软的质量控制可以借鉴的是什么呢？是他们的机制。在微软的测试流程当中，在开发的早期，项目中所有的问题都是Dev leader和PM商量说了算（当然也要参考需求方的意见），但是到后期，具体就是功能测试之后，项目的主动权都在测试这边，某个bug的要不要解决，或者项目进度控制都是测试leader说了算。这和国内的大多数软件公司是不一样的，在微软，测试人员要对最终的软件质量负责任，但是也有相应的权利来约束开发人员。当然，他们也肯定有一些bug是产生争议的，这个时候的仲裁机制就是PM，这个不是我们传统的PM（Project manager），而是一种具有微软特色的PM（全称是Program manager）。这样，测试人员在对一些争议bug的处理上有相当的话语权。

   

  4．  测试用例及管理

  微软的测试用例倒没什么特别的，不过看过他们用例之后，还是觉得写的详细，认真，但是又不冗长拖沓，这个需要很高深的水平。另外，微软的测试用例管理用的是微软自己开发的用例管理工具。

  另外值得说明的是，微软的每个用例都进行了分级，并且功能所在的模块都标的很清楚。

   

  5．  效率

  在效率方面，微软的测试效率非常高！高的让人惊叹，我问一个在微软工作的哥们，“你们那边测试的最大特点是什么”，他说“最大特点是快！”，就是效率很高，具体就是在测试后期过程中测试和开发之间的反馈非常快，开发修改一定量的bug，提交一个新的版本。测试人员往往能在很快的时间内把测试结果反馈出来，一般是在1天之内就能把用例快速run一遍，这样就能减少某些后期才发现bug导致的项目delay。在国内很多项目的通病是，开发解决问题带进一个新问题，测试人员整个遍历一遍用例之后才能发现，这样来回反复就消耗了大量的时间。

  但微软是如何才能实现快速反馈呢？

  第一，   测试人员对程序的了解，微软的测试人员对程序内部结构都非常熟悉，修改某一个地方，可能引起什么问题，哪些用例需要重新测试，测试人员非常清楚，能快速的执行最可能出错的地方。如果某些模块不熟悉，那么他们会和开发人员在一起沟通这次修改可能引起的问题。

  第二，   工具！还是工具，在微软的测试中，测试人员用各种工具帮助测试，提高测试效率是占到很大的比重。

  第三，   时间意识。微软的测试人员有强烈的时间意识。

   

  6．  测试工具

  测试工具能很大程度上提高测试效率，这个作为测试人员都很清楚。当然测试工具在微软的测试中也应用非常广泛，但是请注意，微软并不是像我们国内的公司一样使用的都是LR或QTP这类的录制回放工具，反而这种工具倒是用的不多，就跟微软不屑CMM一样，可能是不想屈尊自己IT老大的身份吧。

  但是微软的测试工具最大的特点是实用。他们用的测试工具都是确实能提高效率，确实能办事情的工具，都不是类似WR和QTP的很大很系统的工具，而是比较小的，很灵活，实用的小工具（譬如：Fiddler、Drip、httpwatch、IE DevToolBar、PaintNotNet、procexp etc.）。甚至有一些测试工具是测试人员在开发人员协助下根据项目需要临时开发的，不过大多数工具都是微软内部已经共享出来的，在微软内部各种各样的小工具特别多。

  总体给我的感觉是，不是为了用测试工具而用，而是根据实际的需要，确实能提高效率而用到，在用的过程中确实也很大的提高了效率。

   

  7．  测试人员的专业素质

  微软测试给我印象最深刻的还有他们测试人员的专业水准，在测试过程中，测试人员在一些技术上并不逊色于开发人员，在一些bug的处理上，能提出很多合理的很有建设性的建议。

   

  8．  微软的白盒测试

  微软的白盒测试怎么执行呢？让我略微有点吃惊的是，微软的一半测试人员基本不做白盒测试，除非有些不能做黑盒的模块，另外也不是所有的产品都作白盒测试。

  微软的白盒测试一般还是由专门的白盒测试人员来做，但是开发人员要对测试人员的白盒测试代码进行Review，另外微软对开发人员的代码，效率也都有一套详细的考核机制，所以开发人员对自己的代码也是非常负责任的，都进行很认真的进行测试。

   

  9．  意识（时间，质量）

  另外微软的测试还有很好的一点就是意识，时间和质量的意识都是非常强。在控制时间成本上，意识非常强，这点非常值得我们国内同仁学习，另外，风险管理的机制和意识都是非常好。在微软，项目组的每个成员都被明确告知，如果这个项目每delay一天，就会损失多少个million的美元，所以整个项目组都有比较好的时间意识。

  另外，在微软，项目组人员的质量意识都是比较强的。怎么样更好服务用户，让用户体验更好，怎么样更好的改进，这种意识比较强。

   

  10． 微软的培训

  在微软内部，员工外训的机会比较少，大多都是内部互训，各人培训自己的强项，有比较好的互相分享的习惯。另外微软的内部有非常丰富的各种培训文档。以后我会上传上去和大家分享。

   

  11 ．测试数据记录

  微软的测试数据记录是非常全的，也都是系统自动的，每天都是由系统自动统计当天的bug情况，然后发送一个report到每个项目组成员的邮箱里。最后到测试总结的时候，这些测试数据将变得非常有用。

  编后感：在深入了解微软的测试之前，对微软这个IT业界巨无霸的测试感觉是顶礼膜拜，高不可攀，总觉得可能很神秘，用很牛的技术或者很高深的手段。深入了解之后，发现微软的测试也是和我们做一样的事情，只不过人家做的更认真，更细，更实用，更有效率。再回过头来看时，微软的测试给我留下印象最多的是，流程，效率，意识，工具，素质！也就是这几项，成为我们国内IT企业亟需跨越的。

  查看(257) 评论(2)

• 转载：如何进行升级测试

  2008-6-13

   

  什么是升级测试？比如说你们公司开发的产品现已经发布的是V1.0，由于被发现存在缺陷，这时就需开发Patch或Hot Fix，并进行升级测试，然后发布V1.1。

  升级测试听起来似乎挺平常的，但它其实也是软件测试中比较重要的一部分，它通常包括以下内容：

  • 安装测试
  • 数据库测试
  • 应用测试
  • 文档测试

  安装测试

  当发布一个系统的新版本时，程序代码肯定是被修改过了，安装测试的目的是确保安装完成后修改过的文件被复制到了正确的位置，比如说某个文件夹包含了所有更新的HTML文件，这时就要检查相关的CSS文件夹下的文件是不是更新了，如果只更新了HTML而没更新CSS，那么相应的颜色/字体就不能正确地显示。

  如果公司研发过程比较规范，安装测试通常是在配置管理员的配合下完成的。首先，是文件夹级的测试，检查安装过程中复制到系统中的文件夹的时间戳是否变化；其次，检查被修改过的文件的大小，并和之前的版本进行比较，当然，这分两种测试，如果是白盒测试，测试人员要打开相应的文件确认新代码和改过的代码，如果是黑盒测试，那就要检查文件大小应与旧版本的不同。

  数据库测试

  很多情况下，系统的升级都是伴随着数据库脚本的更新，数据库测试通常也是由DBA人员或在DBA的配合下进行。升级前要停止数据库并做备份，然后执行升级脚本，之后测试人员需要查看数据库日志，并检查库中被修改的记录是否正确。如果升级脚本是在库中创建一个新的Table或是新的Relation，那么数据库测试应该关注对空库的测试，比如先建一个空库V1.0，只包含一些空的Table和Relation，而不包含任何数据，然后测试人员执行升级脚本，并查看日志文件里是否有报错，如果没有报错一切ok，则通过应用程序连到数据库上执行一些功能测试用例来确保数据的Inset或Update都是正确的。

  应用测试

  当安装测试和数据库测试都通过之后，进行应用测试，有两种方法：

  方法一：先配一个空的数据库（即除了一些必需的初始化数据再没有其他数据），然后把应用程序升级一下，执行业务流程测试看系统是否能够正常运行。

  方法二：也是先配好数据库，但库里存有一些实际数据，然后把程序升级一下（比如从V1.0升至V1.1），运行应用程序，检查那些已有的数据在V1.1上是否也能被正确的展现和使用，最后执行业务流程测试看系统是否能够正常运行。

  有的时候升级完后还要手工修改库中已有的记录，比如一个网上银行的系统，它里面有很多支付或转帐的数据，在做升级测试时，就可能要修改那些在上一版本中生成的数据，因为它们可能涉及到多个表之间的数据转换或一二级约束。

  文档测试

  文档测试主要是验证相关的版本说明或者安装手册等文档是否和系统升级相匹配，这点很重要，因为客户通常都是根据版本说明和安装手册进行系统的安装或升级。

  进行文档测试必须理解详细的升级步骤，比如文档中应建议用户升级前要备份数据库、数据文件、配置文件等，再比如升级需要复制某些文件到特定目录，应当在版本说明中有所体现，总之，升级时任何必要的说明都应当在版本说明或安装手册内阐述清楚，安装时可以做什么以及不可以做什么都应在版本发布前得到确认。

  查看(40) 评论(0)

• 懒人第一笔

  2007-7-30

  欢迎光临寒舍。。。

  查看(22) 评论(0)