在2013年5月版需求测试过程中，我遇到“缺陷修改引起需求变更”和“其他条线的缺陷修改引起另一条线的出问题”的两种情况，对于这两种情况，处理方法具体如下：

1、缺陷修改引起需求变更

原需求：当天到期或已过期的票，银承自动解付任务流经中心岗后，没有直接提交主机记账成功，还要手工解付后才提交主机记账。此做法让操作人员重复工作，效率不好。

后来经过开发人员和业务人员沟通，程序需要修改为：当天到期或已过期的票，银承自动解付任务流经中心岗后，直接提交主机记账成功。

出现此种情况，开发人员没有提供最新需求说明书，并且没有邮件通知测试人员。

此修改，将会涉及到：需求变更、测试用例修改、工作量增加等情况。

我们测试人员具体处理方法如下：

1、           需求变更：提醒开发人员或需求分析人员需要修改需求说明书。要邮件通知测试人员、业务人员等相关人员，并且提供最新的需求说明书。

2、           测试用例修改：测试人员要根据需求变更内容进行测试用例修改，评估工作量，如果工作量太大，则要上报组长。

3、           工作量评估：如果工作量超过3天以上，那应该上报，要走需求变更审批流程。

面对这种情况，我觉得测试人员需要多思考多分析，及时上报。

面对这种情况，建议开发人员能够有意识地修改相关需求说明书及通知相关人员。

2、其他条线的缺陷修改引起另一条线的出问题

在5月版需求测试过程中，遇到一个问题：同城需求的缺陷修改，把银承的挂起任务程序改错了，造成银承自动解付的任务不能挂起。此问题涉及到平台公共部分的程序。

这种情况，开发人员不知道自己改错了。

同城对这个缺陷验证的测试人员也分析不到此问题会影响到其他条线。

我们测试人员的处理方法有如下几种方法：

1、 如果缺陷涉及到平台公共部分的程序，则缺陷验证的测试人员要思考下或是验证缺陷以外涉及的其他条线交易。如果缺陷验证的测试人员对其他条线的交易不熟悉，那可以邮件通知其他条线的组长安排人员验证。

2、 测试人员多学习平台各条线的交易。这样测试人员在测试平台公共部分，就会全方面思考啦。

3、 各条线派出代表人对平台的测试人员做培训。

面对这种情况，我觉得测试人员需要多思考、多分析、多学习。

面对这种情况，建议开发人员在修改缺陷时多分析缺陷的修改涉及面，特别是平台公共部分程序，如果涉及到多条线的程序修改，那请在缺陷修改说明中描述出来告知测试人员。