首先在我们回顾下这2个问题：

　　问题1:如何最大限度的降低需求的变更对测试质量的影响？

问题2:有没有什么有效的方法来降低测试用例的不断修改率？

　　记得好像测试用例PK里面也提出这2个问题，而且这些问题对于测试人员在工作过程中也是比较难以解决的，同样需要不断的尝试与探索新的方法与流程来增加问题解决的可能性。其实我觉得这2个问题是有一定的共性，第一个问题解决了，第二个问题也就解决了一大半了。那我就首先谈谈个人对第一个问题的理解：

　　注意看题目的几个关键词：一个是“最大限度的降低”，另一个是“需求的变更”。最后一个是“测试质量”。我们要解决好这个问题，必须要很好的理解这个几个关键词的内在含义。我想并不是所有人都能很好的理解这些术语。

　　那什么叫需求的变更呢？顾名思义就是项目需求发生了变化与修改(先不谈什么原因)，对应测试这边测试需求也就相应的变化。这里可不要忘了一个重要的时间点，那就是一旦PRD评审通过后。其后任何一个时间点，不管是UC设计还是测试设计或是什么，只要需求发生了变化，这都属于需求的变更。

　　那什么叫测试质量呢？这个概念比较大，一般我们讲软件质量，这个就与我们测试人员的工作职责相关的。而对于测试质量，个人认为包括2大块，一个是测试各个阶段的产出的高质量，一个是测试各个阶段的控制的高效性。解释一下第一个是各个阶段的产出的文档的高质量，这里面包括文档的规范性，完整性，正确性，统一性。第二个是各个阶段的进度控制和项目管理的高效率。包括测试目标以及发现缺陷，甚至是缺陷预防的持续改进等。

　　想必大家都知道需求变更不是个好东西吧，那我们就要想办法减少需求变更。首先需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更，可最后需求变更总是会出现。在需求并更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。因此，在需求人员(PD)同用户代表或用户部门主管人员接触时，就应该向他们挑明态度，和他们协商好，特别是应该让他们清楚软件的定价应该与软件的功能相关，以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。简单说让客户明白减少需求变更的重要性后，需求分析人员应该采取合适的方法同客户交流，帮助他们明确他们的需求。

　　还有一个就是我们要规范需求文档，需求文档应该按照一定的格式和规范来写，而且应该具备完整性、一致性、基线控制、历史记录等特性。需求变更发生后，也应该生成相应的文档，并且这些文档的书写也应该采用规范的形式来写。

　　前面说到得是减少需求变更的方法，这个不是一个人能做到的，是整个项目组成员共同努力的。正如前面所说，需求变更不可避免的会发生，那么当需求变更发生后我们测试人员应该如何应对呢？一般来讲，需求的变更通常意味着需求的增加，需求的减少相对很少，而且处理也比较容易。而且发现现在开发人员和PM对需求变更起主导作用，同时需求的变更并不能实时反馈到测试人员。这就需要流程的监控了，之前也

　　说了一旦出现什么样的需求变更，就相应的走需求变更的流程(相信这里应该充分考虑测试人员的参与度)。充分的与开发人员沟通加上SQA的实时跟踪也许会减少需求的变更对测试质量的影响。

我们说到了对测试质量的影响，那么有哪些呢？一个测试设计与测试用例的文档的修改；一个是与开发沟通需求变更的成本；再一个是测试人员重复测试执行的成本。另外最关键的是由于需求变更带来的测试覆盖率的风险，特别是在测试执行后期阶段，时间计划都已经安排的很合理，这时由于需求变更，其影响可想而知。

　　那总结下解决第一个问题的思路：

　　减少需求变更

　　规范需求文档

　　与开发及时沟通需求问题

　　需求变更流程控制执行到位

　　尽量避免需求变更在测试后期阶段(成本大，风险大)

及时采取办法应对需求变更(时间延期，覆盖率，评估需求变更)

　　至于第二个问题就要搞清楚为什么测试用例需要修改，个人理解大概有这些情况：一个是上面说的由于需求变更，之前根据之前的需求写的测试用例肯定要修改；一个是由于理解需求有误导致测试用例本来就写错了，但测试用例评审没有发现问题；另一个是比较小的修改，就是一些测试用例的细节与测试执行时得到的结果描述有偏差(最常见的就是报错信息内容)；最后一个是自己在测试执行时，通过探索性测试发现了bug，而且没有测试用例，这时就需要增加测试用例。等等。

　　搞清楚了原因，那么我们就可以有针对性的解决测试用例的修改率问题。比如第一个就需要把控需求变更的问题；或延长测试设计的时间，增加需求理解的正确性；还有就是加强测试用例的评审力度和监控力度；多关注测试用例的细节，用例设计时要求开发给出明确的输出信息。

这里同样的是测试用例的修改也是不可避免的，这样做的目的就是要做好测试用例的基线，更好的管理和维护测试用例，更好的回归测试日常需求。更好的加强自己以后在测试设计时思维角度的多变性。

　　以上是自己对这2个问题的理解，其实这2个问题也是在测试领域比较难以量化和解决的，这些解决思路都需要不断的探索和思考，去不断的总结，加上自己Team内部管理的一些规范，共同探索出适合自己的解决办法。