软件更改影响分析应由谁做？以测试人员为主还是开发人员为主？

[xlsong1]

背景：项目实施完成后，产品使用过程中出现问题，需产生变更，客户要求出具软件更改影响分析以确定测试范围。
争论：
1、软件更改影响分析报告对软件测试过程更有用还是对更改过程更有用？
2、软件开发人员是否有权限出具软件更改影响分析报告？
在软件工程管理中，对产品上的软件发生变更时，大家是怎么处理的？请介绍下诸位大拿公司的相关管理流程。
谢谢！

[xlsong1]

补充下： 我个人的观点是：软件测试中，是由软件开发人员对软件代码进行讲解后，软件测试人员制定测试计划、设计用例并实施测试；同时，软件测试人员对需求方来说是独立的； 基于此，确定软件测试范围应该也是制定测试计划的一个必要步骤，那么从分工上来说应该有测试人员进行影响分析；另外，由于测试的独立性，由软件测试人员出具影响分析报告更可信。

[xlsong1]

无人回应？ 有没有哪些公司有软件回归测试相关流程的？

[xlsong1]

没有人来说下自己的意见？

[对酒当歌今夕何夕]

测试是从需求角度 看影响分析 设计要从代码开发角度看影响分析 看到的东西不一样的 测试人员最后的结果是变更测试用例 开发看到的可能更多，比如变更了 底层公用模块，需要做回归测试等等 测试看的终究是表面....在我们公司 影响分析是设计做的，也就是开发 ，测试人员只是针对变更需求 ，做新的测试用例而已

[qjl1000211038]

一个软件的变更涉及到方方面面，当然开发和测试也作为其中不可缺少的 其中有业务上的业务操作评估，业务风险评估，开发难度评估，系统整体架构的评估，系统安全评估，性能评估，回归测试的评估等等，许多许多方方面面 根据修改的不能级别，会有不同的人物来评估，小功能由开发测试业务人员评估，大的功能就必须由本公司专家，业务专家评估，有的甚至还会请第三方公司来进行专业评估 总之，上了生产就是大问题，哪怕是最微小的更改，也可能导致错误，所以要谨慎对待

[xlsong1]

先谢谢xiebird和qjl1000211038 回xiebird： 我明白您说的意思，核心是因为测试人员并不清楚代码内部机理，所以回归测试由开发人员进行。 其实这是个问题，测试人员是否应对程序代码有深入的了解呢？在公司，软件开发者对代码模块提交测试之前，要就软件代码向测试组进行详细解说，使他们有足够的了解，尤其是对一些只能进行代码走查的模块，不会去执行测试用例。如果从这方面考虑的话，测试人员对程序流程是有相当的了解的。 回qjl1000211038: 您说的对，只是不晓得从管理流程上来说，该由谁首先去确定修改的级别。现在客户提出的问题是我们需提交一个分析报告来确定测试内容。对于产品软件进行的更改，最怕引入额外的BUG及影响到其他功能。对软件开发者，我们可以进行影响分析，但是担心的是我们出具的分析报告的置信度不够。所以我觉得当产品软件出现问题时，应该是以下任务分工： 1）软件开发者分析源代码、寻找故障原因、给出解决措施并进行更改有效性验证； 2）软件测试者针对更改代码进行局部测试，并与软件开发者协同进行初步影响分析，后使用专业工具和方法（是否有？）进行专业的影响分析，确定测试范围和方法，并执行测试。 再次谢谢二位。 因为问题出现后，由于责任问题及潜在的引入问题风险，客户的委托人并不愿对软件测试做太多的表态，导致软件的更改验证未能及时处理。我认为这是我们公司制度上的缺陷，如果有一套明确的产品软件更改实施流程就不会使拖延发生。

[xlsong1]

明天晚上结贴，诸位如果有关于影响分析的专业的方法就给介绍下，谢谢！

[qjl1000211038]

引用 6 楼 xlsong1 的回复:

先谢谢xiebird和qjl1000211038 回xiebird： 我明白您说的意思，核心是因为测试人员并不清楚代码内部机理，所以回归测试由开发人员进行。 其实这是个问题，测试人员是否应对程序代码有深入的了解呢？在公司，软件开发者对代码模块提交测试之前，要就软件代码向测试组进行详细解说，使他们有足够的了解，尤其是对一些只能进行代码走查的模块，不会去执行测试用例。如果从这方面考虑的话，测试人员对程序流程是有相当的了解的。 回qjl1000211038: 您说的对，只是不晓得从管理流程上来说，该由谁首先去确定修改的级别。现在客户提出的问题是我们需提交一个分析报告来确定测试内容。对于产品软件进行的更改，最怕引入额外的BUG及影响到其他功能。对软件开发者，我们可以进行影响分析，但是担心的是我们出具的分析报告的置信度不够。所以我觉得当产品软件出现问题时，应该是以下任务分工： 1）软件开发者分析源代码、寻找故障原因、给出解决措施并进行更改有效性验证； 2）软件测试者针对更改代码进行局部测试，并与软件开发者协同进行初步影响分析，后使用专业工具和方法（是否有？）进行专业的影响分析，确定测试范围和方法，并执行测试。 再次谢谢二位。 因为问题出现后，由于责任问题及潜在的引入问题风险，客户的委托人并不愿对软件测试做太多的表态，导致软件的更改验证未能及时处理。我认为这是我们公司制度上的缺陷，如果有一套明确的产品软件更改实施流程就不会使拖延发生。

我们这里一般是由生产上出现问题，提操作申请书，然后分属业务还是技术，再有相关部门发起，多方共同解决。 一般都是采用面向对象的设计，所以技术层面的测试都是测试调用或被调用的相关代码进行测试，业务层面的测试则更多的是对相关的交易进行测试。

[对酒当歌今夕何夕]

引用 7 楼 xlsong1 的回复:

明天晚上结贴，诸位如果有关于影响分析的专业的方法就给介绍下，谢谢！

回归测试不能开发做，还是要测试人做 ，这个我觉得你要多想一下。 其次 测试确实不需要知道太多底层，但是要了解或者信任开发， 不然像我这里， 测试的姐姐 三天2头要求做回归测试，就是不相信开发的改动到底有多少影响.... 她们认为你改了很多不告诉她们.... 我现在只能逼测试用 smoke test 代替回归测试 因为回归测试代价太大 ，项目成本早暴了... 软件变更管理可以说一本书的，对影响这个问题，按我之前说的，开发/测试/需求分析员 都可以评估影响， 但是我觉得应该是设计师（Designer）或者 Leader 对这个做总结，单方面 ，测试或者开发 都不可能给出完整的评估，毕竟视角有限。 这种时候技术经理（Technical Leader）应该协调总结,如果你们公司没有相应的职位，就是leader或者pm的责任了。