51Testing软件测试论坛

标题: 因为关联系统和测试环境导致的若干问题(更新) [打印本页]

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

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

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

[ 本帖最后由 beyond2525 于 2007-5-7 10:27 编辑 ]
作者: beyond2525    时间: 2007-4-25 20:40
请各位大虾看过之后,多多指点一下!谢谢!
作者: beyond2525    时间: 2007-4-25 23:23
标题: 回复 #3 xiaomayi0323 的帖子
因为我们部门是刚刚独立出来的,测试流程和测试管理一直在寻找适合自己的方式。
你可以提供一些好的建议吗?
在线等待中!
作者: null2    时间: 2007-4-26 10:53
改进流程,明确责任
作者: beyond2525    时间: 2007-4-26 13:37
针对我们公司的这种现象,最先应该从什么流程开始改进.我该以什么方式提出我的建议类?
在线等待!
作者: null2    时间: 2007-4-26 13:50
强制规定需求变更必须通知测试,开发每一格版本的功能、所完成的需求,必须告知测试,如未告知,统统记入bug,影响开发考核
作者: beyond2525    时间: 2007-4-26 13:58
强制规定开发好象在现阶段比较困难,这个需要上头的PK~
而且还牵涉到部署部门,在这中间我应该采取什么措施去避免这些东西?
作者: beyond2525    时间: 2007-4-26 14:02
其实现在还存在一种情况,类似的这种问题即使是上报到了最后还是被开发拒绝,然后在我们的缺陷流程管理工具中,该缺陷的状态就只有拒绝,从一定程度上就会影响到我们测试人员的缺陷质量和KPI
作者: ccc11yyy    时间: 2007-4-26 14:40
开发和测试的环境分开管理,避免混淆冲突;

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

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

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

对缺陷的级别定义明确,出现问题立刻沟通,并及时修改缺陷级别的定义文件;
作者: ccc11yyy    时间: 2007-4-26 14:45
缺陷管理工具中的缺陷状态一般是可以定制的,可以增加一个状态,比如:pending,等待你的领导来协调解决,或通过其他途径解决。

至于测试人员的KPI,计算方法可以根据实际情况做一些调整,可以灵活处理的。
作者: beyond2525    时间: 2007-4-26 15:00
原帖由 ccc11yyy 于 2007-4-26 14:40 发表
开发和测试的环境分开管理,避免混淆冲突;

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

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



需求评审、设计评审、测试用例评审---这些评审是只要大型项目还是一般的常规版本需要.
但是如果每个版本都做这些规范评审的话.是否比较耗费测试人力?
在线等待,谢谢!
作者: ccc11yyy    时间: 2007-4-26 15:16
评审确实是需要花时间做前期的准备工作。 但是这些工作对于测试来说是跑不了的, 越早确认,反而可以减少测试的工作量,发现问题后再去一一确认的工作量。

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


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


可以根据实际情况逐步的添加评审,是否耗费人力要去做才能评估。这个过程是需要不断改进的。
作者: beyond2525    时间: 2007-4-26 15:23
在改善的过程中,如果有需求的更改,或者需求未完成的现象,强制要求开发在移交版本的时候.需要以文档或者邮件方面通知测试人员和用户,并对未完成需求定出完成版本和时间点.这样的方法代替评审工作,是否是可行的?
作者: beyond2525    时间: 2007-4-26 15:30
还有一个问题,如果有好几个版本同时移交到测试环境,而且他们的上线日期由是同一天
我该怎么更好的处理测试这几个系统的先后顺序.
作者: ccc11yyy    时间: 2007-4-26 17:38
原帖由 beyond2525 于 2007-4-26 15:30 发表
还有一个问题,如果有好几个版本同时移交到测试环境,而且他们的上线日期由是同一天
我该怎么更好的处理测试这几个系统的先后顺序.


这个是在制定测试Schedule的时候应该考虑的问题,从什么时候开始测试,测试多长时间,测试到什么程度,能满足客户上线的日期和质量的要求。
如果开发delay,原则上开始测试时间点可以相应的延后,测试总时长保证不变。
作者: ccc11yyy    时间: 2007-4-26 17:42
原帖由 beyond2525 于 2007-4-26 15:23 发表
在改善的过程中,如果有需求的更改,或者需求未完成的现象,强制要求开发在移交版本的时候.需要以文档或者邮件方面通知测试人员和用户,并对未完成需求定出完成版本和时间点.这样的方法代替评审工作,是否是可行的?



需求评审是指需求第一次完成,要开始进行设计前进行的活动。改善过程中的变更属于变更管理,如果改动的比较大,可以组织一场需求评审,否则个人认为没有必要了。
作者: beyond2525    时间: 2007-4-26 18:38
原帖由 ccc11yyy 于 2007-4-26 17:38 发表


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


可能我还没将问题说清楚,我们公司的系统一般2个星期发布一次版本,而且所有的系统都是在一天内发布,这样就导致在同一段时间内要进行N个系统的测试.版本延迟发布在我们公司基本上很少有先例的.所以在这样的情况和环境下,我该怎样处理先后顺序.
是按平时系统改动时,出现的缺陷来判断.
还是按这几个系统的需求数和案例数来判断.
或者是其他的情况进行判断?
作者: beyond2525    时间: 2007-4-27 10:38
再请教一个问题,对于回归测试我们到底要做到什么详细的程度。回归测试是只需用正常数据做为输入条件,还是也要做边界值测试呢?
在线等待!谢谢!
作者: yongming566    时间: 2007-4-27 15:33
回归测试,这2方面都要的
个人认为
作者: xianmengxuan    时间: 2007-4-29 04:40
不知道你要安装在WINDOWS环境呢,还上LINUX环境?

我安装的是WIN2000下的,是从网上找的资料!我这有WIN2000环境下的安装步骤,也是从网上找的,希望能对你有点帮助!
作者: beyond2525    时间: 2007-4-30 13:06
后话,怎么处理好测试人员与开发之间的关系?
在线等待!  谢谢!  希望大家多给点宝贵意见·
作者: beyond2525    时间: 2007-4-30 15:45
如果对方是一个90%的开发和测试人员都认为难已沟通的开发~  我该怎么办?
目前来说。我最好的办法好象也只有逃避---转做别的系统测试。
作者: beyond2525    时间: 2007-5-3 23:22
偶从事测试行业时的师傅转发我的沟通技巧:也发上来,供大家参考。希望对大家有帮助。
1.沟通的目的:
(1) 控制下属的行为(遵守公司政策);
(2) 激励员工、该善绩效(参与管理时代--不要一天到晚做到办公室或一直坐在电脑前,会失去沟通、失去激励);
(3) 表达情感(分享挫折与满足);
(4) 流通信息(日本的移交与中国情报--信息不可以断裂,离职时的工作备忘录)。

2 沟通的基本问题是"心态":
(1) 自私:关心只在五伦以内;e.g: 当看到别人看地图,要主动去问他是否迷路了,需不需要帮忙。
(2) 自我:别人的问题与我无关;
(3) 自大:我的想法就是答案。

3 沟通的基本原理是"关心":
(1) 注意他的状况与难处;
(2) 注意他的需求与不便;
(3) 注意他的痛苦与问题。

4 沟通的基本要求是"主动":
(1) 主动的支援;
(2) 主动的反馈;
(3) 你看我需要怎么和你配合呢?
(4) 你看有什么东西我需要努力的?

5 利用反馈:
(1) 事前问清楚;
(2) 事后负责任.

6 简化语言:
(1) 讲话要有重点(一个人的注意力只有十分钟!如果客户给你2小时、1小时、半小时、10分钟、5分钟、1句话,你该怎么说?);
(2) 善用比喻.

7 主动倾听:
(1) 两只耳朵,一张嘴,分析与思考;
(2) 不要在客户面前打手机。
(3) 和手下沟通时,要放下一切--集中精神。
(4) 跟别人面谈,要避免哪些"小动作"?(not talking about secret)
    提示:角落;关门;低声;狼顾;亲密关系

8 往上沟通:
(1) 时间安排+任何地点(不是等他下命令);
(2) 准备对策/答案(两个以上,最好让他选择;以及你自己的个人倾向和原因);
(3) 优劣对比+可能后果.

9 往下沟通:
(1) 了解状况(瓶颈)--多学习、多了解、多询问、多做功课;
(2) 要求反思(言之有物);
(3) 提供方法+紧盯过程;
(4) 接受意见+共谋对策;
(5) 给予尝试机会。

10 水平沟通:
(1) 主动+体谅+谦让;
(2) 自己先提供协助+再要求对方配合;
(3) 分析利弊+双赢结果.

11 上司要了解下属:
(1) 你喜欢我给你的这个工作和任务吗?
(2) 你觉得我发挥了你的长处吗?
(3) 如果将来有机会再调,你想调什么工作?

12 你的上司怎么看你?
(1) 自动报告你的工作进度--让上司知道。
(2) 对上司的询问,有问必答,并且清楚--让上司放心。
(3) 充实自己,努力学习,才能了解上司的言语--让上司轻松。(上司
(4) 接受批评,不犯三次过错--让上司省事。
(5) 不忙的时候,主动帮助他人--让上司有效。(麦当劳排队)
(6) 毫无怨言地接受任务--让上司圆满。
(7) 对自己的业务,主动提出改善计划--让上司进步。




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2