软件更新后要不要重新检测

结论：判断依据是更新影响了什么，不是更新了多少行代码

软件更新比硬件变更频繁得多——修复缺陷、增加功能、更新组件、改进界面。每次更新都做完整的重新检测不现实，但完全不评估又有风险。

判断的依据是：这次更新影响了产品的哪些特性。 影响到的特性对应的验证要重做，未影响的可以论证免测。

注意是「影响了什么特性」而不是「改了多少代码」。 改一行代码可能影响安全功能，改一千行界面代码可能什么安全相关的特性都不影响。

影响分析的做法

第一步，明确更新内容。 改了什么、为什么改。

第二步，分析影响的功能。 直接修改的功能，以及可能受牵连的功能。

第三步，分析影响的特性。 安全功能、基本性能、电磁特性、数据完整性、性能指标。

第四步，确定回归范围。 受影响特性对应的验证项目。

第五步，对未纳入的项目做免测论证。

第六步，执行回归验证并记录。

第二步的「可能受牵连的功能」是难点。 软件模块之间有依赖，改动一处可能影响其他处。这需要对软件架构有了解，也是为什么架构清晰、模块耦合低的软件更新成本更低。

各类更新的影响

「界面布局调整」的影响常被低估。 按钮位置改变可能增加误操作的风险，特别是对使用者是老年人或功能受限人群的产品。这类更新应当做可用性方面的评估。

「时钟或功耗策略」的更新对 EMC 有直接影响，而这类改动往往被当成纯软件优化，不会想到要重做 EMC。

回归范围的确定

确定范围时的考虑：

受影响功能的验证。 直接测改动涉及的功能。

接口验证。 改动模块与其他模块的接口。

集成验证。 整体功能是否仍然正常。

安全相关验证。 安全功能是否仍然有效。

性能验证。 性能指标是否受影响。

按级别确定深度。 软件安全性级别高的，回归范围相应更大。

建议维护一份「功能—验证用例」的对照表。 有了这张表，确定回归范围就是查表的工作；没有表，每次都要重新分析。

免测论证的写法

申请免测某些项目时，论证应当包含：

更新内容的具体描述。 技术细节。

影响分析的过程。 如何判断影响范围。

未受影响的理由。 为什么这些项目不受影响。

支持证据。 如果有自测数据或架构上的隔离论证，一并提供。

「架构上的隔离」是有力的论证。 如果能说明改动的模块与某些功能之间没有数据或控制上的关联，那么这些功能不受影响的论证就有依据。

与硬件测试的关系

软件更新可能影响硬件相关的测试结果：

EMC。 软件控制的时钟、功耗、通信都影响发射和抗扰度。

温升。 功耗策略改变影响发热。

单一故障。 软件实现的保护功能改变时，故障状态的表现可能改变。

电池。 功耗管理影响续航和电池行为。

这几项在软件更新时容易被认为「不涉及硬件所以不用管」，实际上软件对硬件行为的影响是实在的。建议影响分析时把这几项列入检查。

与申报义务的关系

软件更新可能构成需要申报的变更，各市场的要求不同：

影响安全或有效性的更新。 通常需要申报。

纯缺陷修复。 处理方式各市场不同。

安全补丁。 部分市场有简化的处理途径。

新增功能。 通常需要申报，可能涉及预期用途的变化。

建议建立更新的分类规则：哪类更新只需内部记录、哪类需要申报、哪类需要事前批准。规则定好之后，每次更新按规则处理，比每次重新判断要高效也更一致。

版本管理的配合

版本号规则。 用版本号体现更新的性质（重大、次要、修复）。

发布记录。 每个版本的更新内容、影响分析、验证记录。

基线管理。 哪个版本是当前的注册基线。

现场版本的追踪。 用户手上是哪些版本。

「现场版本追踪」对召回和安全通告很重要。 发现某个版本有问题时，需要知道哪些用户在用该版本。

更新的分类规则示例

建议把更新分成几类，各类对应不同的处理：

规则定好之后，每次更新先分类再处理，比每次从头分析要高效，也保证了处理的一致性。

记录的要求

每次更新应当记录：版本号与日期；更新内容；影响分析结论；回归范围与理由；验证结果；申报处理；以及批准人。这份记录在审查、追溯、以及后续的变更评估中都会用到。

我们的做法

遇到软件更新后的复测委托时，我们会先看更新说明和影响分析。如果委托方提供了详细的更新内容和影响分析，我们可以据此聚焦复测范围；如果只说「软件升级了」，通常要建议较大范围的复测，因为无法判断影响。

对于 EMC 相关项目，我们会特别问一句：这次更新是否涉及时钟、功耗管理或通信协议。 这三类改动对 EMC 有直接影响，而委托方往往不会主动提。

如果你有软件更新需要判断复测范围，可以把更新说明和影响分析发过来一起评估，或者直接联系：132 4819 8029。能力范围见服务介绍，流程见检测流程，更多内容见知识库。

English version

Conclusion. Software changes far more often than hardware, through defect fixes, new functions, component updates and interface improvements. Retesting completely at every update is impractical, while assessing nothing carries risk. The basis for deciding is which of the product's characteristics the update affects: verification relating to affected characteristics must be repeated, and the rest can be justified as exempt. Note that this concerns which characteristics are affected rather than how many lines changed: one line can affect a safety function, while a thousand lines of interface code may affect nothing safety-related.

Performing impact analysis. State the update specifically, covering what changed and why. Analyse the functions affected, both those directly modified and those that may be implicated. Analyse the characteristics affected, covering safety functions, essential performance, electromagnetic characteristics, data integrity and performance measures. Determine the regression scope, meaning the verification items relating to those characteristics. Justify exemption for items not included. And perform the regression verification and record it. Functions that may be implicated is the difficult step: software modules depend on one another and a change in one place can affect another. That requires understanding of the architecture, which is why software with clear architecture and low coupling costs less to update.

Effects by update type. Interface text changes usually have no effect, though warning content should be checked. Interface layout changes affect usability and may affect the risk of erroneous operation. Defect fixes depend on where the defect lay and how it was fixed. New functions affect themselves and their interaction with existing functions. Control logic changes affect safety functions, output characteristics and essential performance. Clock or power management changes affect electromagnetic characteristics and temperature rise. Communication protocol changes affect communication-related verification and electromagnetic compatibility. Third-party component updates depend on the component's role. And security patches affect security functions and may affect performance. Layout changes are underestimated: moving a button can increase the risk of erroneous operation, particularly for products whose users are elderly or functionally limited, so such updates warrant usability assessment. Clock and power management changes affect electromagnetic compatibility directly, while being treated as pure software optimisation with no thought of repeating electromagnetic testing.

Determining regression scope. Consider verification of affected functions, testing what the change touched. Interface verification between the changed module and others. Integration verification of whether overall function remains correct. Safety-related verification of whether safety functions still operate. Performance verification of whether measures are affected. And depth by class, since a higher software safety class implies broader regression. Maintain a function-to-test-case table: with it, determining regression scope becomes a lookup, and without it every update requires fresh analysis.

Writing the exemption justification. Include a specific description of the update with its technical detail; the impact analysis process, explaining how scope was judged; the reasons items are unaffected; and supporting evidence, whether self-test data or an architectural segregation argument. Architectural segregation is a strong argument: showing that the changed module has no data or control relationship with certain functions gives the claim that those functions are unaffected a proper basis.

Relationship to hardware testing. Software updates can affect hardware-related results. Electromagnetic compatibility is affected by software-controlled clocking, power consumption and communication, all of which bear on emissions and immunity. Temperature rise is affected by changes in power management. Single fault behaviour changes when software-implemented protection changes. And battery behaviour and range are affected by power management. These are commonly assumed not to matter because no hardware changed, whereas software's effect on hardware behaviour is real. Include them in the impact analysis checklist.

Relationship to notification obligations. A software update may constitute a notifiable change, with requirements differing by market. Updates affecting safety or effectiveness generally require notification. Pure defect fixes are handled differently in different markets. Security patches may have a simplified route in some markets. And new functions generally require notification and may involve a change of intended use. Establish classification rules for updates: which need only internal records, which need notification and which need prior approval. With rules in place, each update is handled by rule, which is quicker and more consistent than judging afresh each time.

Version management. Version numbering should reflect the nature of the update, distinguishing major, minor and fix. Release records should cover update content, impact analysis and verification. Baseline management should identify which version is the current registration baseline. And field version tracking should establish which versions users are running. Field tracking matters for recalls and safety notices: when a version is found to have a problem, you need to know which users are running it.

How we handle it. For retesting after a software update we review the update description and impact analysis first. Where the client supplies detailed content and analysis we can focus the retest scope accordingly; where the message is simply that the software was upgraded, we generally have to suggest broader retesting because the effect cannot be judged. For electromagnetic items we ask specifically whether the update touched clocking, power management or communication protocols, since all three affect electromagnetic behaviour directly and clients rarely mention them unprompted.

Send us the update description and impact analysis and we will assess the retest scope. Phone or WeChat: +86 132 4819 8029.