51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6214|回复: 22
打印 上一主题 下一主题

[原创] 因为关联系统和测试环境导致的若干问题(更新)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-4-25 20:29:35 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
进入测试行业也有差不多2年的时间了,之前做的是游戏行业的测试。
现在转做WEB测试,在测试过程中发现一些问题,请各位前辈和大虾们
指点指点。
  目前所在的公司,测试部门刚刚独立出来,对测试流程和测试管理都
在不段的改善之中。由于我们开发的产品都是面向公司的员工,因此在
上报缺陷的过程中出现了测试人员认为是缺陷。但是开发人员以用户部门
并未有此需求为理由。不认可测试人员上报的缺陷。具体有以下的几种
常见的类型。
现在我们公司已经采取以下几项措施改进:
  1:关联系统的需求改动或者测试环境重启并没有通知测试相关人员。
测试过程中发现系统某些功能的报错或者不可用。
  测试环境和关联系统有任何异常必须通知测试组长,由组长通知相关
测试人员。
  
2:测试环境中,部署的时候配置文件错误或者某个脚本执行不成功,
但是在需求的流程管理中,该版本已经是部署状态。测试过程中发现系
统某些功能的报错或者不可用。
  通知相关系统的开发人员和测试人员。
3:测试案例是根据需求文档编写的,但是实际开发的内容中并没有
完成该需求。主要存在于开发将原始需求拆分成几个版本上线。并没有
将未完成的功能以文档形式知会测试人员。
  建议开发在进行需求类问题的沟通时,邮件抄送测试人员。
  4:需求和案例都不明确,上报之后开发并不认可(针对一些异常操
作后造成的缺陷,开发人员以用户部门需求中并未有此预期输出为理由。
不认可测试人员上报的缺陷。
  此类问题计算为需求缺陷(需求缺陷以后是考核需求人员的重要指标)
  5:测试人员和开发人员对缺陷级别的看法不一致(测试人员认为是
L4,开发人员认为不是缺陷)
双方PK,然后重点听取需求人员和生产环境问题处理人员的意见      

针对上面的问题,在我们目前的测试缺陷管理工具中,一般都会将
它们的状态直接改为拒绝。但是在实际的测试过程中。测试人员都花了很
大的工作量。而在我们部门测试人员的KPI考核当中,测试人员发现的缺陷
个数又是非常重要的一个指标。不知道是否有更好的办法。可以解决存在这
中间的矛盾。即不影响考核,又不影响开发人员的工作,然后能够更有效率
的完成测试工作和测试任务?
   3Q~~~~

也许以上都不是很好的解决,但是从最近的工作来看,还是有一定效果的 。
谢谢各位测友对本帖的支持,希望大家在度过一个开心,轻松的假期之后。
有个不错的工作状态。
  :)

[ 本帖最后由 beyond2525 于 2007-5-7 10:27 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2007-4-25 20:40:07 | 只看该作者
请各位大虾看过之后,多多指点一下!谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2007-4-25 23:23:38 | 只看该作者

回复 #3 xiaomayi0323 的帖子

因为我们部门是刚刚独立出来的,测试流程和测试管理一直在寻找适合自己的方式。
你可以提供一些好的建议吗?
在线等待中!
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-4-26 10:53:59 | 只看该作者
改进流程,明确责任
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2007-4-26 13:37:33 | 只看该作者
针对我们公司的这种现象,最先应该从什么流程开始改进.我该以什么方式提出我的建议类?
在线等待!
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2007-4-26 13:50:15 | 只看该作者
强制规定需求变更必须通知测试,开发每一格版本的功能、所完成的需求,必须告知测试,如未告知,统统记入bug,影响开发考核
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2007-4-26 13:58:05 | 只看该作者
强制规定开发好象在现阶段比较困难,这个需要上头的PK~
而且还牵涉到部署部门,在这中间我应该采取什么措施去避免这些东西?
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2007-4-26 14:02:20 | 只看该作者
其实现在还存在一种情况,类似的这种问题即使是上报到了最后还是被开发拒绝,然后在我们的缺陷流程管理工具中,该缺陷的状态就只有拒绝,从一定程度上就会影响到我们测试人员的缺陷质量和KPI
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2007-4-26 14:40:49 | 只看该作者
开发和测试的环境分开管理,避免混淆冲突;

发现严重的问题立刻上报。由于制度不完善,很多事情不是测试执行人员可以“扛”下来的,要让你的主管协调解决;

增加需求评审、设计评审、测试用例评审活动,测试提早进入,减少三者之间的差异,或与大家达成共识;

可以建立需求跟踪矩阵,保证所有的需求都被实现并能够被跟踪;

对缺陷的级别定义明确,出现问题立刻沟通,并及时修改缺陷级别的定义文件;
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2007-4-26 14:45:51 | 只看该作者
缺陷管理工具中的缺陷状态一般是可以定制的,可以增加一个状态,比如:pending,等待你的领导来协调解决,或通过其他途径解决。

至于测试人员的KPI,计算方法可以根据实际情况做一些调整,可以灵活处理的。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
 楼主| 发表于 2007-4-26 15:00:16 | 只看该作者
原帖由 ccc11yyy 于 2007-4-26 14:40 发表
开发和测试的环境分开管理,避免混淆冲突;

发现严重的问题立刻上报。由于制度不完善,很多事情不是测试执行人员可以“扛”下来的,要让你的主管协调解决;

增加需求评审、设计评审、测试用例评审活动,测 ...



需求评审、设计评审、测试用例评审---这些评审是只要大型项目还是一般的常规版本需要.
但是如果每个版本都做这些规范评审的话.是否比较耗费测试人力?
在线等待,谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2007-4-26 15:16:28 | 只看该作者
评审确实是需要花时间做前期的准备工作。 但是这些工作对于测试来说是跑不了的, 越早确认,反而可以减少测试的工作量,发现问题后再去一一确认的工作量。

提前达成共识,在执行测试的时候也会有据可依,避免被拒绝的情况发生。


评审的另一个好处是提供一个沟通平台,借此测试人员可以宣导测试的思想,测试的目标,让大家对测试工作逐渐重视起来。


可以根据实际情况逐步的添加评审,是否耗费人力要去做才能评估。这个过程是需要不断改进的。
回复 支持 反对

使用道具 举报

该用户从未签到

13#
 楼主| 发表于 2007-4-26 15:23:00 | 只看该作者
在改善的过程中,如果有需求的更改,或者需求未完成的现象,强制要求开发在移交版本的时候.需要以文档或者邮件方面通知测试人员和用户,并对未完成需求定出完成版本和时间点.这样的方法代替评审工作,是否是可行的?
回复 支持 反对

使用道具 举报

该用户从未签到

14#
 楼主| 发表于 2007-4-26 15:30:42 | 只看该作者
还有一个问题,如果有好几个版本同时移交到测试环境,而且他们的上线日期由是同一天
我该怎么更好的处理测试这几个系统的先后顺序.
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2007-4-26 17:38:44 | 只看该作者
原帖由 beyond2525 于 2007-4-26 15:30 发表
还有一个问题,如果有好几个版本同时移交到测试环境,而且他们的上线日期由是同一天
我该怎么更好的处理测试这几个系统的先后顺序.


这个是在制定测试Schedule的时候应该考虑的问题,从什么时候开始测试,测试多长时间,测试到什么程度,能满足客户上线的日期和质量的要求。
如果开发delay,原则上开始测试时间点可以相应的延后,测试总时长保证不变。
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2007-4-26 17:42:32 | 只看该作者
原帖由 beyond2525 于 2007-4-26 15:23 发表
在改善的过程中,如果有需求的更改,或者需求未完成的现象,强制要求开发在移交版本的时候.需要以文档或者邮件方面通知测试人员和用户,并对未完成需求定出完成版本和时间点.这样的方法代替评审工作,是否是可行的?



需求评审是指需求第一次完成,要开始进行设计前进行的活动。改善过程中的变更属于变更管理,如果改动的比较大,可以组织一场需求评审,否则个人认为没有必要了。
回复 支持 反对

使用道具 举报

该用户从未签到

17#
 楼主| 发表于 2007-4-26 18:38:46 | 只看该作者
原帖由 ccc11yyy 于 2007-4-26 17:38 发表


这个是在制定测试Schedule的时候应该考虑的问题,从什么时候开始测试,测试多长时间,测试到什么程度,能满足客户上线的日期和质量的要求。
如果开发delay,原则上开始测试时间点可以相应的延后,测试总时 ...


可能我还没将问题说清楚,我们公司的系统一般2个星期发布一次版本,而且所有的系统都是在一天内发布,这样就导致在同一段时间内要进行N个系统的测试.版本延迟发布在我们公司基本上很少有先例的.所以在这样的情况和环境下,我该怎样处理先后顺序.
是按平时系统改动时,出现的缺陷来判断.
还是按这几个系统的需求数和案例数来判断.
或者是其他的情况进行判断?
回复 支持 反对

使用道具 举报

该用户从未签到

18#
 楼主| 发表于 2007-4-27 10:38:41 | 只看该作者
再请教一个问题,对于回归测试我们到底要做到什么详细的程度。回归测试是只需用正常数据做为输入条件,还是也要做边界值测试呢?
在线等待!谢谢!
回复 支持 反对

使用道具 举报

  • TA的每日心情
    郁闷
    2014-11-5 22:10
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    19#
    发表于 2007-4-27 15:33:25 | 只看该作者
    回归测试,这2方面都要的
    个人认为
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2007-4-29 04:40:04 | 只看该作者
    不知道你要安装在WINDOWS环境呢,还上LINUX环境?

    我安装的是WIN2000下的,是从网上找的资料!我这有WIN2000环境下的安装步骤,也是从网上找的,希望能对你有点帮助!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-24 07:33 , Processed in 0.096019 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表