针对以上所写的这些，我说说我的拙见，如何减少需求变更对接口测试的影响：

　　1）良好的心态。从心态上，接口测试人员应该把需求变化当作是一种项目常态，平常心应对。但是，我们也要学会控制这种需求变化的趋势，不能任其发展。

　　2）及时沟通，快知晓需求变更。和需求相关人员和开发人员做好即时沟通，第一时间知道需求的变更，及时做好测试策略更新。知道的越早对我们的影响越小，需要的测试

成本也越低。

　　3）良好的团队合作。接口测试人员和开发人员的良好合作，分工明确，对新的改动及时通知对方，短时间内开展有效的团队协作。接口测试人员要主动关注开发代码的修改

，对测试用例和测试代码及时调整，做到小粒度的修改。

　　4）接口测试人员反应快，用例代码灵活性高。接口测试人员反应快，提前做好新需求的测试规划，包括测试设计和测试执行规划，并且在设计中要考虑新需求对老需求的影响

；并且我们原测试用例和代码也要有一定的灵活，可以在一定程度上适应需求变化，将未来的新需求的影响尽量降到很小。这里不详细说了，下次具体的MC的项目说说如何增

强测试用例代码的灵活性，减少新需求对测试代码的影响。

　　5）做到及时的需求跟踪。通过测试用例代码的不断回归，尽早的主动的发现需求的变更。

　　我们接口测试人员要成熟、快速、有序、灵活、有责任心的应对需求的变化，把我们的接口测试工作做得更好。

　　5、接口测试中测试与开发的配合

　　作为一名测试人员，工作中接触频繁的应该要数开发人员了。在整个测试过程中，开发人员是与测试人员是走的近的，因为从初测试的需求到测试中发现的缺陷的处理

以及终测试的总结，都需要和开发人员紧密合作。

　　接口测试因其天生的代码亲密性，为了更好地提高产品质量，要求测试人员更加地深入到开发的工作中去（从需求出发深入到代码、页面中去），甚至是与开发并行地工作

。那么这对测试人员和开发人员的合作与互动提出了更高的要求。

　　1）测试与开发的互动应该贯穿项目始终，时刻保持和开发的联系

　　也许有人会认为开发和测试在项目中相互独立会更加好，在此对这个问题不作讨论，只想说说从始至终与开发保持联系的好处。时刻保持联系，可以使双方对于项目的进展有

一个明确的共同的理解，使项目的执行更加顺利。减少一些缺乏沟通而可能造成的工作内容的冲突，例如对于需求理解的不一致、需求变更等。

　　2）测试需求不光来自于PRD和UC，还要倾听来自开发的需求，这往往是他们担心的内容

　　诚然PRD和UC是测试需求的主要来源也是测试工作的依据，然而从PRD和UC出发的测试需求往往是功能性的，会遗漏不少细节，特别是在接口测试工作中，这些细节又往往体现

在开发的工作中，或者某些具体的实现中。因此倾听开发的测试需求，同时提出测试对于开发的要求是十分必要的。开发的需求经常是体现了在开发中他们没有把握的地方，这些

光靠分析PRD和UC是很难得到的。

　　3）测试与开发应当相互了解对方的工作内容和方式，并交换意见

　　让开发知道测试在做什么是怎么做的，当前测试的状况是什么样子的，测试也要了解开发的进度和工作内容。开发了解测试的方法和内容会有利于提高代码的可测性以及代码

的品质。测试了解开发的工作方式和进度，便于和开发进行合作加快缺陷的修复和验证。不仅要了解，在了解的基础上相互交换意见和看法，这往往能相互提高工作效率。

　　4）职责明确，测试应全面负责测试的工作环境、配置、代码，开发不应当随意改动。

　　讲了很多互动的地方，但是有些内容却不应是互动的。接口测试来说，测试环境配置和测试代码应当全部由测试工程师来维护，因为测试工程师主导整个测试的过程并对测

试的结果负责。可以请开发协助配置环境这是必要的，但是出现任何测试方面的问题，开发都不应该在没有和测试工程师沟通的情况下介入测试环境和测试代码的变更。因为这样

往往会导致测试用例无法通过，测试环境被破坏，测试结果可信度下降。会给项目进度带来不必要的影响。

　　相应的，由于接口测试的代码往往和工作代码在一个工程下，测试也不应该去改动开发的工作内容，这会带来十分严重的后果。

　5）测试应当高度关注测试持续集成的结果，第一时间分析问题，并初步定位后转交开发。

　　在此我想强调下初步定位并转交开发的问题，可能有些同学会觉得缺陷被发现后直接转交开发可以了，定位缺陷的事开发完成可以了。我有一些不同的想法，能够定位缺陷意味着对于项目有着较为深入的了解，将有助于提高缺陷修复的效率。例如，同样是查询结果异常的问题，原因可能各有不同，如果初步将问题进行定位，必定能提高这些相似但实质却不同的缺陷的解决效率。

　　6、如何简单设计接口测试用例

　　接口测试是项目测试的一部分，它测试的主要对象是接口，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。

　　如何设计接口测试用例？首先，明确出发点，和所有的测试一样，接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向，你的设计行为会尽量朝这个方向，更易发现问题

　　其次，选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口，每个接口如果分别测试，那将是很痛苦的一件事情，而且任何一个内部接口的变动，都将导致我们用例的不可用。

　　可将这些外层的接口分为两类：一类是数据进入系统的接口；一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用，模拟外部的使用；而流出的接口则是我们用例真正该验证的点。数据从哪里流出，流出时的状态如何，此时系统又是什么状态都是我们所应该验证的。

　　然后，确认完整的测试对象的功能：确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。

　　后当出发点、对象、功能都确定了，可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。

　　接口测试用例设计和测试用例设计一样，用例设计的内容应该包括：主要测试功能点、测试环境、测试数据、执行操作以及预期结果。

　　1）接口测试环境分为两种：一种是程序内部的环境；一种是程序的所调用外部接口的环境。

　　2）接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据上需要花费更多的心思。要通过好的测试数据使用例查找问题。接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列，不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据，使用例更容易发现问题。

　　3）测试功能点，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。

　　4）接口测试用例执行操作非常简单，是所测接口的调用。

　　5）预期结果验证，这也是接口用例设计的很关键的一步，应该细而不冗余。每个用例均需验证，避免一个用例中重复做相同的验证，提高测试用例的效率。