当一个增量迭代交付时，咋降低这个增量迭代的给系统带来的风险。或者说一个优化的逻辑和功能 ?
组件化和模块化，特别是每个组件都能够独立打包部署，组件间通过标准接口服务进行交互式解决类似问题的一个关键途径。我们简单举例来说明下类型场景和问题，假设一个系统有以下五个组件。A，B，C，D，E本次增量迭代导致的是E组件涉及到新增加功能和变更，那实际场景如下：1. E内部变更，E暴露的接口无任何变化该场景只需要测试E这个组件，其它几个组件基本不用在做测试。如果需要也只需要再跑下主体端到端流程即可。2. E内部变更，但是E暴露的接口出现变化，该接口被A和B组件使用。该场景需要测试E整个组件，同时需要对A和B两个组件中涉及到接口消费的部分功能。而对于C和D两个组件仍然是不用做过多测试。===================================================================再回来讲下你说的方法，开发从代码层面给测试提供可能影响的范围，供测试把关。这个方法本身也是可以得，但是本身就是开发很难做出完整的变更影响分析。比如说我们现在修改一个方法，如果没有类似CMMI完整的需求追踪和实现矩阵，那么开发常用的方法就是对整个项目进行搜索，看下究竟哪些地方用到了这个方法，涉及到用到该方法的地方都需要重新进行测试。即使这样，我们也很难保证测试全面，比如：function A() 出现了修改，我们可能会搜索大function B()调用了该方法，那我们是否还需要搜索所有function B()使用到的地方。我想任何一个开发在做影响范围分析的时候都很难做到如此全面，况且在没有进行组件化时候，即使有的模块每做任何变动，但是仍然进行了整个项目的重新编译，那么在编译和打包过程中是否引入新问题也很难说，因此还是不得以还是要做全功能测试。
■网友
碰到过类似问题：开发修改了一个tcp协议相关的问题导致测试不够充分（时间很紧，而且开发改动不是很多）而遗漏了一个很严重的问题。后面通过两个保障措施1，加大自动化的覆盖，这样至少保证系统的注意功能没有问题（不出低级错误）2，安排测试人员加强业务和整个背景知识的学习，并且给出系统关联表，这样修改一个地方后验证关联的模块
■网友
方向就错了，从代码角度去看测试，只是在关注代码本身是否可能出错。但同样重要的是，从用户客户的角度去看测试，测试在某个程度上就是代表功能的用户去验证这个功能能否满足他们的需要。完全存在代码一点问题没有，但是软件却无法达到用户期望，帮助他们完成他们想要完成的任务，这样的软件无疑是失败的。从用户使用这个功能的场景入手去分析，关注用户操作的过程，以及用户操作背后，看不见的我们系统之间互相交互的过程，这就是在界定影响范围。这个过程确定了，那么我们的代码需要修改哪些地方，也明确了。这些都清楚了，那么如何去测试，也基本上明确了。
■网友
这个问题首先是从系统设计上来说，合理的解耦，使得系统可以划分为若干个模块，每个规模保持在一个迭代之内可以完成一个模块。从开发的组织上来说，测试要介入需求环节，明确改动的范围和影响，然后在编写测试用例环节给够足够的时间。
■网友
【当一个增量迭代交付时，咋降低这个增量迭代的给系统带来的风险。或者说一个优化的逻辑和功能 ?】 做好回归测试呀，单元测试覆盖率达到80%
■网友
任何迭代都有风险，这就是为什么需要一系列测试，乃至continuous integration的原因。自动化测试确实是种cost，你是更喜欢更新后系统bug掉呢，在做计划的时候把写测试的时间也算上呢？不过我挺好奇的到底是什么系统修改下代码连影响范围都不能确定，这还能叫增量迭代嘛？
推荐阅读
- 同比■同比增长7.1%！2021年的第一个节你花了多少钱？
- “他是我第一个会说普通话的老师”：一对师生折射青海山村蝶变
- 有必要重新开个C店吗
- 大学再有三个月就结束了，没学到知识，参加一个软件测试培训机构好吗
- 汽车|长安UNI-K又将开创一个新的"引力"纪元？
- 神话|武汉传奇父亲：一个平行班孩子创造的高考神话（感动上万家长）
- 王者荣耀李白能不能出肉
- 直播会成为品牌传播的另一个途径么有哪些可行的方法感觉有戏又没头绪好捉急。
- 怎样成为一名合格的Python程序员?
- 知乎有没有必要增加一个特别关注功能