日历

« 2008-12-05  
日 一 二 三 四 五 六
 123456
78910111213
14151617181920
21222324252627
28293031   

统计信息

  • 访问量: 105
  • 日志数: 2
  • 建立时间: 2007-03-18
  • 更新时间: 2007-04-26

RSS订阅

我的最新日志

  • 测试同化现象

    2007-4-26

     该缺陷其实是一个需求并不十分明确的情况下 ，测试人员做了一个异常操作而导致的。上报QC后，开发人员认为用户需求并未明确具体的预期输出内容，不认可是缺陷，改为待裁决。由于目前QC系统中在待裁决状态后就只存在确定或者拒绝2种状态，而一般在开发不认可的情况下，我们都是将缺陷状态改为了拒绝。但是执行人员在测试过程中是耗费了相当大的工作量。

    类型这样的带裁决缺陷还有以下几种情况：

    1：关联系统的需求改动或者测试环境重启并没有通知测试相关人员。测试过程中发现系统某些功能的报错或者不可用。

      2：测试环境中，部署的时候配置文件错误或者某个脚本执行不成功，但是在需求的流程管理中，该版本已经是部署状态。测试过程中发现系统某些功能的报错或者不可用。

      3：测试案例是根据需求文档编写的，但是实际开发的内容中并没有完成该需求。主要存在于开发将原始需求拆分成几个版本上线，并没有将未完成的功能以文档形式知会测试人员。或者是在需求提交后，开发人员和用户私下沟通，更改部分需求内容没有通知测试人员的

      4：需求和案例都不明确，上报之后开发并不认可（针对一些异常操作后造成的缺陷，开发人员以用户部门需求中并未有此预期输出为理由。不认可测试人员上报的缺陷。）

      5：测试人员和开发人员对缺陷级别的看法不一致，通常该类缺陷是因为界面或者是按钮的显示问题，或者是提示信息的不友好（测试人员认为是L4，开发人员认为不是缺陷）

    针对上面的问题， 我以执行人员的心态说说我的想法。

    对于1和2是否可以要求相关系统的人员和部署组的人员在有异常的情况下能通知该系统的测试协调人，由协调人通知执行人员异常情况或者将该脚本影响到的系统功能测试案例从测试集中删除掉。在脚本执行成功后重新添加到测试集中来。

    对于3，建议如果需求有拆分上线的情况，要求开发人员在移交版本的时候一定要以文档的形式或者是邮件的方式通知测试人员和需求提交人。从而避免在测试过程中的发现问题，自己确认是问题，和开发确认时却告知该需求未实现。而浪费掉时间。对于需求更改的也做此要求。

    对于4，由于需求不明确造成分歧太大的，建议将缺陷发给用户，由用户进行裁决是否需要修复该缺陷。如果修复，是在本次版本中解决还是在以后的版本中解决。并且抄送给事件组相关系统的处理人，参考他们的意见。如果不修复，是否增加一无计划状态：在用户需求中无此内容。但是如果此类问题过多，怎么避免测试同化现象。

       对于5，个人认为可以增加一个挂起或者遗留的缺陷状态。或者是建议状态。该类缺陷并不影响到版本发布的出口标准。在开发人员有人力和时间的情况下，对此类问题进行修复或修改。因为一个产品应该是以用户为中心，不断追求完善。

       还有一个小小的建议，对于回归测试的执行，是否可以进行交叉测试：测试人员交叉测试，就可以很大程度的避免定位效应。测试执行人员在进行回归测试时互相交换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人员某些功能没有缺陷。每个系统最好是一个月或者一个季度，对产生缺陷的模块和生产环境的PIR问题做一个统计。这样的统计数据可以更好的指导测试人员抓系统的重点。

      以上所述，都是我个人的观点，还请多多指正。谢谢！！

     

     

    查看(23) 评论(0)

  • 关联系统和测试环境对系统测试的影响

    2007-4-25

      进入测试行业也有差不多2年的时间了，之前做的是游戏行业的测试。

    现在转做WEB测试，在测试过程中发现一些问题，请各位前辈和大虾们

    指点指点。

      目前所在的公司，测试部门刚刚独立出来，对测试流程和测试管理都

    在不段的改善之中。由于我们开发的产品都是面向公司的员工，因此在

    上报缺陷的过程中出现了测试人员认为是缺陷。但是开发人员以用户部门

    并未有此需求为理由。不认可测试人员上报的缺陷。具体有以下的几种

    常见的类型。

      1：关联系统的需求改动或者测试环境重启并没有通知测试相关人员。

    测试过程中发现系统某些功能的报错或者不可用。

      2：测试环境中，部署的时候配置文件错误或者某个脚本执行不成功，

    但是在需求的流程管理中，该版本已经是部署状态。测试过程中发现系

    统某些功能的报错或者不可用。

      3：测试案例是根据需求文档编写的，但是实际开发的内容中并没有

    完成该需求。主要存在于开发将原始需求拆分成几个版本上线。并没有

    将未完成的功能以文档形式知会测试人员。

      4：需求和案例都不明确，上报之后开发并不认可（针对一些异常操

    作后造成的缺陷，开发人员以用户部门需求中并未有此预期输出为理由。

    不认可测试人员上报的缺陷。

      5：测试人员和开发人员对缺陷级别的看法不一致（测试人员认为是

    L4，开发人员认为不是缺陷）

          针对上面的问题，在我们目前的测试缺陷管理工具中，一般都会将

    它们的状态直接改为拒绝。但是在实际的测试过程中。测试人员都花了很

    大的工作量。而在我们部门测试人员的KPI考核当中，测试人员发现的缺陷

    个数又是非常重要的一个指标。不知道是否有更好的办法。可以解决存在这

    中间的矛盾。即不影响开发人员的工作，又不影响考核，然后能够更好更有

    效率的完成测试工作和测试任务？

       3Q~~~~

     

     

    查看(36) 评论(0)

Open Toolbar