在软件开发过程中，ASPICE SWE.4的单元验证及其证据留存，往往容易被做成表面功夫，不少项目将单元验证简单视作开发人员随手一测，或是仅保留几张工具截图，但从ASPICE的视角出发，SWE.4更强调的是软件单元是否依据详细设计进行了验证，测试方法是否恰当，结果能否追溯，以及发现的问题是否形成了一个闭环，所以单元验证不能只盯着执行了没有，还要去关注验证的对象、内容、结果，还有证据链够不够完整。

　　一、ASPICE SWE.4单元验证怎么做

　　ASPICE SWE.4的核心任务，在于检查软件单元与软件详细设计能不能对得上，软件单元这个说法，可以指函数、类、模块，也可以是任何能单独验证的逻辑块，在项目启动时，得先划清楚哪些内容归到单元验证的范围里，然后再依据每个单元的特性去挑选合适的方法。

　　1、明确单元验证范围

　　在开始单元验证之前，先把软件单元怎么划分给搞明白，像普通的业务逻辑、状态机、诊断处理、接口转换，还有算法计算这些，一般都得纳入验证的范围，就算是自动生成的代码、第三方的代码或是配置类的代码，也不能轻飘飘地说一句“不测”就过去了，而要解释清楚是靠静态分析、评审、集成测试，还是供应商的证据来兜着底。

　　2、建立设计和用例关系

　　围绕【软件详细设计】和【单元测试用例】，把每个软件单元的输入、输出、接口、边界条件和异常处理对应起来。

　　这样做的目的，是为了防止测试用例只贴着代码去编，却不回头对照设计的要求，就例如详细设计里头写了状态切换、错误返回和超时处理，那在测试用例里就得能瞧见这些对应的场景才说得过去。

　　3、选择合适验证方法

　　单元验证不光就是跑动态测试，它还可以搭配静态分析、代码评审、控制流检查和边界值测试一块儿来用，对于核心算法、状态机，还有跟安全搭边的逻辑，通常得拿测试用例去验一下运行的结果，而编码规范、复杂度、没初始化的变量、死代码这类问题，倒是能通过静态分析来帮着查一查，选什么验证方法倒不必全是一个模子，但总得能说清楚为什么这么选。

　　二、ASPICE SWE.4单元验证证据怎么留存

　　SWE.4的证据不能光留下一句“测试通过”就收场，在评估那会儿，更被看重的是这些证据能不能讲清楚测了些什么、是怎么测的、结果又怎么样，还有查出来的问题是咋处置的，证据要是能一路往回追到设计和代码上头，那它可信的分量就更高了。

　　1、保留验证计划和范围说明

　　单元验证的计划倒不一定要写成长篇大论，可好歹也得把验证的范围、方法、测试环境、进入条件、退出条件，还有谁是责任人给交代明白，这样一来，等到后面再翻看测试结果的时候，才能知道这些结果是在什么环境底下跑出来的，也好去掂量验证的深浅是不是对得上项目风险的那个程度。

　　2、保存测试用例和执行结果

　　在【单元测试报告】中，应保留测试用例编号、测试输入、预期结果、实际结果、执行状态、执行时间和执行人等信息。

　　要是用上了单元测试工具，那工具的版本、编译的配置、桩函数或者模拟对象的说明，这些也得一块儿存下来，针对嵌入式软件来说，宿主机上测试、目标机上测试，还有用模拟器来测试，这几种环境里的差别，也需要简单讲上几句。

　　3、留存追溯关系

　　追溯关系呢，得把软件单元、详细设计、测试用例、执行结果，还有缺陷记录一一串成线，当你瞅见一个设计点的时候，应该能顺着去查到它到底验过了没有，反过来，瞧见一个测试用例时，也能知道它验的是哪一个设计内容，要是这条追溯的线断掉了，哪怕测试用例攒得再多，也容易被人看成证据不够瓷实。

　　三、ASPICE SWE.4单元验证怎么避免形式化

　　好多项目在SWE.4上出的毛病，倒不是压根儿没做过测试，而是测试跟设计、缺陷、版本这些东西之间没有搭上桥，乍一看材料堆了不少，可真要一根根往下追，就露了馅儿：用例的来路不明不白，结果对的是旧版本，缺陷这边刚关掉，那头却没有复测的记录。

　　1、不要只追求覆盖率数字

　　代码覆盖率这个东西，是有一点参考的价值，可它绝对顶替不了测试是不是真的充分，覆盖率挺高，顶多只说明代码给跑过了，但不代表那些边边角角的条件、异常的分支，还有设计里头的用意，全都被验到了，项目更应该去瞧瞧关键逻辑是不是被盖住了，异常的场景有没有被琢磨过，跟安全勾连的单元有没有被摆上更严的一把尺子。

　　2、把缺陷和复测结果闭环

　　要是在单元验证的时候揪出了问题，那就要把问题的现象、它碍着了哪个单元、改了些什么东西，还有复测的结果，一桩桩给记下来，可不能光在报告里头甩一句“已修复”就算了，还得让人翻得到缺陷的记录、代码修改的记录，还有复测跑通的证据，这么着，才能说问题是真的被摆平了，而不是简简单单给关掉了事。

　　3、检查证据版本一致性

　　在提交评估之前，得去仔细盘一盘，测试报告、代码基线、缺陷记录，还有覆盖率的结果，这几样东西是不是全对得上卯，好些扣分的地方，根子都在细处上，好比报告的日期比代码修改的日子还赶在前头，测试结果拴在了旧的版本上，缺陷关掉之后压根儿瞧不见复测的记录，这些问题倒不一定是说测试没跑过，但它会把证据的可信程度给拉低一大截。

　　总结

　　总起来看，ASPICE SWE.4的单元验证该如何去执行，以及其证据要怎样去保留，关键的一步是把软件详细设计、单元测试用例、执行的成果、覆盖率的数据，还有缺陷的闭环，一块儿攒成一条线，单元验证这东西，既不是开发人员顺手那么一测，也不是单靠着几张工具截图就能证明完事了，它得能交代出每一个关键的软件单元到底验了哪一块、为什么挑这种方式去验、结果是不是通过了、查出来的问题有没有复测并且关严实了，只要证据链是明明白白的，SWE.4才更容易扛起ASPICE评估和往后质量追溯的那份责任。