因为关联系统和测试环境导致的若干问题（更新）

beyond2525

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

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

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

[ 本帖最后由 beyond2525 于 2007-5-7 10:27 编辑 ]

beyond2525

偶从事测试行业时的师傅转发我的沟通技巧：也发上来，供大家参考。希望对大家有帮助。
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) 对自己的业务，主动提出改善计划--让上司进步。

beyond2525

如果对方是一个90%的开发和测试人员都认为难已沟通的开发~  我该怎么办？
目前来说。我最好的办法好象也只有逃避---转做别的系统测试。

beyond2525

后话，怎么处理好测试人员与开发之间的关系？
在线等待！  谢谢！  希望大家多给点宝贵意见·

xianmengxuan

不知道你要安装在WINDOWS环境呢，还上LINUX环境？

我安装的是WIN2000下的，是从网上找的资料！我这有WIN2000环境下的安装步骤，也是从网上找的，希望能对你有点帮助！

yongming566

回归测试，这2方面都要的
个人认为

beyond2525

再请教一个问题，对于回归测试我们到底要做到什么详细的程度。回归测试是只需用正常数据做为输入条件，还是也要做边界值测试呢？
在线等待！谢谢！

beyond2525

原帖由 ccc11yyy 于 2007-4-26 17:38 发表


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

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

ccc11yyy

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

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

ccc11yyy

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

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

beyond2525

还有一个问题,如果有好几个版本同时移交到测试环境,而且他们的上线日期由是同一天
我该怎么更好的处理测试这几个系统的先后顺序.

beyond2525

在改善的过程中,如果有需求的更改,或者需求未完成的现象,强制要求开发在移交版本的时候.需要以文档或者邮件方面通知测试人员和用户,并对未完成需求定出完成版本和时间点.这样的方法代替评审工作,是否是可行的?

ccc11yyy

评审确实是需要花时间做前期的准备工作。 但是这些工作对于测试来说是跑不了的， 越早确认，反而可以减少测试的工作量，发现问题后再去一一确认的工作量。

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


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


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

beyond2525

原帖由 ccc11yyy 于 2007-4-26 14:40 发表
开发和测试的环境分开管理，避免混淆冲突；

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

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

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

ccc11yyy

缺陷管理工具中的缺陷状态一般是可以定制的，可以增加一个状态，比如：pending，等待你的领导来协调解决，或通过其他途径解决。

至于测试人员的KPI，计算方法可以根据实际情况做一些调整，可以灵活处理的。

ccc11yyy

开发和测试的环境分开管理，避免混淆冲突；

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

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

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

对缺陷的级别定义明确，出现问题立刻沟通，并及时修改缺陷级别的定义文件；

beyond2525

其实现在还存在一种情况,类似的这种问题即使是上报到了最后还是被开发拒绝,然后在我们的缺陷流程管理工具中,该缺陷的状态就只有拒绝,从一定程度上就会影响到我们测试人员的缺陷质量和KPI

beyond2525

强制规定开发好象在现阶段比较困难,这个需要上头的PK~
而且还牵涉到部署部门,在这中间我应该采取什么措施去避免这些东西?

null2

强制规定需求变更必须通知测试，开发每一格版本的功能、所完成的需求，必须告知测试，如未告知，统统记入bug，影响开发考核

beyond2525

针对我们公司的这种现象,最先应该从什么流程开始改进.我该以什么方式提出我的建议类?
在线等待!