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

beyond2525

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

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

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

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

beyond2525

请各位大虾看过之后，多多指点一下！谢谢！

beyond2525

因为我们部门是刚刚独立出来的，测试流程和测试管理一直在寻找适合自己的方式。
你可以提供一些好的建议吗？
在线等待中！

null2

改进流程，明确责任

beyond2525

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

null2

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

beyond2525

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

beyond2525

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

ccc11yyy

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

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

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

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

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

ccc11yyy

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

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

beyond2525

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

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

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

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

ccc11yyy

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

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


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


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

beyond2525

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

beyond2525

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

ccc11yyy

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

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

ccc11yyy

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

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

beyond2525

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


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

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

beyond2525

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

yongming566

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

xianmengxuan

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

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