设计开发验证与确认的检测证据怎么区分

结论：验证对的是设计输入，确认对的是使用需求

这两个词在中文里都带「证」字，实际含义差得很远。

验证回答：输出满足输入了吗。 设计输入写了某项指标，产品做出来测一下达没达到。参照系是你自己写的设计输入文件。

确认回答：产品满足使用需求了吗。 拿到真实或模拟的使用条件下试，看能不能解决用户的问题。参照系是使用者的实际需求。

差别在于：验证可能全部通过，而确认仍然失败——每项指标都达标，但产品在实际场景里不好用、解决不了问题。这种情况在实务中并不罕见。

两者的证据形式

第五行是确认最容易打折的地方。 由研发工程师自己做确认，他们熟悉产品、知道怎么用，得出的结论往往偏乐观。真实使用者第一次接触产品时遇到的困难，工程师感受不到。

确认的数据怎么取

确认的证据形式比验证多样，常见的有：

模拟使用测试。 在实验室搭建接近真实的使用场景，按典型使用流程操作，记录问题。这是最常用的形式。

可用性评价。 由代表性使用者操作，观察并记录使用错误、困难点、理解偏差。这一类数据对说明书和界面设计特别有价值。

临床或实际使用数据。 在真实环境中收集，说服力较强但成本和周期也高。

与已上市同类产品的对比。 在相同条件下与参照产品对比表现。

无论哪种，确认都应当有客观记录，而不只是一份「满足需求」的结论。用户满意度问卷可以作为补充，但单靠它不够。

常见的混淆表现

一是把验证当确认。 做了全套性能测试，直接写「确认通过」。缺的是使用条件下的整体表现。

二是确认在实验室条件下做。 名义上做了确认，但条件与实际使用差距很大，结论的适用性有限。

三是确认样品用样机。 确认应当用定型产品，用样机做的确认代表不了量产品的使用体验。

四是把培训当确认。 有些企业用「使用者经培训后能正确操作」作为确认证据，但如果产品的预期使用场景中使用者未必受过培训，这个结论就不成立。

检测安排上怎么区别对待

验证类的检测，重点是覆盖完整、条件受控、数据准确。按设计输入逐条对应，每条都有实测值。

确认类的检测，重点是条件贴近实际。安排时要考虑：使用环境的温湿度、光照、噪声；使用者的操作习惯与能力范围；使用的时长与频次；可能的误用情形。

确认阶段的一个常见发现是误用。 使用者用了设计者没想到的方式操作，而这种方式可能带来风险。这类发现应当反馈到风险分析，成为新的风险控制措施的来源。

与风险管理的联动

验证和确认都与风险管理相关，但方式不同：

验证证明的是风险控制措施按设计实现了；确认证明的是这些措施在实际使用中确实有效。

举例来说，为了防止误操作加了一个联锁，验证测的是联锁功能是否正常动作，确认测的是有了联锁之后使用者是否还会误操作。联锁功能正常但使用者仍然出错，这种情况确认阶段才会暴露。

变更之后的重做判断

产品变更后，验证和确认的重做判断标准不同：

验证的重做看变更是否影响了对应的设计输入项；确认的重做看变更是否影响使用方式或使用体验。

有些变更不影响任何指标，但改变了操作方式（比如按键位置调整），此时验证可以不重做，确认却应当重做。这一点容易被漏掉，因为变更评审通常按指标影响来判断。

确认的样本量与代表性

确认涉及使用者时，样本量和构成都影响结论。样本太少，个体差异会主导结果；构成不贴近目标人群，结论的适用性有限。

建议按使用者的能力分布来组织：如果产品面向的人群在年龄、操作能力上跨度较大，样本应当覆盖这个跨度，而不是集中在中间段。边缘人群往往是问题暴露得最明显的——操作能力较弱的使用者遇到的困难，恰恰是设计需要改进的地方。

确认发现问题之后

确认阶段发现的问题，处理路径与验证不同。验证不通过是指标没达到，改到达到即可；确认不通过可能意味着需求理解有偏差，改动范围可能更大。

所以确认应当尽早做，不要排在所有验证之后。在设计还能调整的阶段做一次初步确认，比等产品定型后再发现使用问题要好得多。

两者的时间顺序

一般顺序是先验证后确认：指标都达标了，再看整体使用效果。但这个顺序不是绝对的。

对于使用方式复杂、人因风险较高的产品，可以在验证尚未全部完成时先做一轮初步确认，用样机在模拟场景里走一遍流程。这样能尽早发现方向性问题，避免把全部验证做完才发现产品思路需要调整。

代价是初步确认的结论不能直接作为正式证据，后面仍要用定型产品重做一次。

我们的做法

我们承接的委托多数属于验证类，但也会配合委托方做模拟使用条件下的测试。这类测试需要委托方提供使用场景的描述——场景描述不清楚，模拟就无从设计。

实务上比较有效的做法是：委托方给出典型使用流程和环境条件，我们据此设计测试条件并在报告中明确记录，这样数据才能支撑确认的结论。如果只说「按实际使用条件测」，双方对「实际」的理解可能完全不同。

如果你在准备设计确认的证据，或者不确定某项该归入验证还是确认，可以把设计输入和使用场景描述发过来一起理，或者直接联系：132 4819 8029。能力范围见服务介绍，流程见检测流程，更多内容见知识库。

English version

Conclusion. Verification asks whether the output meets the input: a design input specifies a figure, the product is measured against it, and the reference is your own design input document. Validation asks whether the product meets user needs: it is tried under real or simulated use conditions to see whether it solves the user's problem, and the reference is actual need. The consequence is that verification can pass entirely while validation still fails, with every indicator met and the product still awkward or ineffective in its intended setting. That situation is not rare.

Forms of evidence. Verification references the design input document, runs under laboratory conditions, produces measured values item by item, may use a representative prototype, is performed by technical staff and is judged against specified values. Validation references user need, runs under simulated or actual use conditions, produces evidence about overall performance in use, should use definitive product, should involve actual users where possible, and is judged against need.

The involvement of real users is where validation most often falls short. Development engineers performing their own validation know the product and how to use it, so their conclusions skew optimistic. The difficulties a genuine user encounters on first contact are invisible to them.

Obtaining validation data. Simulated use testing builds a realistic scenario in the laboratory and follows typical workflows while recording problems; this is the most common form. Usability evaluation has representative users operate the product while use errors, difficulties and misunderstandings are observed and recorded, which is particularly valuable for instructions and interface design. Clinical or actual use data are the most persuasive but cost the most in time and money. Comparison against a marketed equivalent under identical conditions is another option. Whichever is used, validation needs objective records rather than a bare statement that needs are met; a satisfaction questionnaire may supplement but cannot carry the conclusion alone.

Common confusions. Treating verification as validation, running the full performance suite and writing that validation passed, with nothing addressing overall performance in use. Performing validation under laboratory conditions so remote from actual use that the conclusion has limited applicability. Performing validation on prototypes, which cannot represent the experience of production units. And treating training as validation, concluding that users operate correctly after training when the intended use scenario does not assume trained users.

Arranging testing differently. Verification testing emphasises complete coverage, controlled conditions and accurate data, with every design input matched to a measured value. Validation testing emphasises realism of conditions: ambient temperature and humidity, lighting, noise, user habits and capabilities, duration and frequency of use, and foreseeable misuse. A frequent finding at validation is misuse, where users operate the product in ways the designer did not anticipate and which may create risk. Such findings should feed back into the risk analysis as the source of new controls.

Linkage with risk management. Verification demonstrates that risk controls were implemented as designed; validation demonstrates that those controls are actually effective in use. If an interlock was added to prevent a use error, verification tests whether the interlock functions, while validation tests whether users still make the error despite it. An interlock that functions correctly while users continue to err is a situation only validation exposes.

Deciding what to repeat after a change. The criteria differ. Verification is repeated where the change affects the corresponding design input. Validation is repeated where the change affects how the product is used or experienced. A change that affects no specified figure but alters operation, such as relocating a control, may require no repeat verification and does require repeat validation. This is easily missed, because change review usually assesses impact in terms of specifications.

How we handle it. Most of our work is verification, but we also support simulated use testing. That requires the client to describe the use scenario, since without a clear description the simulation cannot be designed. The effective arrangement is for the client to provide typical workflows and environmental conditions, from which we design and document the test conditions so that the data can support a validation conclusion. An instruction simply to test under actual use conditions leaves both sides with different ideas of what actual means.

Send us the design inputs and a description of the use scenario and we will work through it. Phone or WeChat: +86 132 4819 8029.