这个层次的测试也都是黑盒测试，不需要了解内部实现细节，只需关注输入与输出。
3.4 验收测试
验收测试，实际上已经脱离了严格意义的工程开发的范畴，在ASPICE里也没有明确定义。
但是，现在行业内越来越多地思考用户导向和用户思维，所以把验收测试单独拿了进来。
我倾向于把验收测试定义为非专业的客户评判，比如汽车行业领导或特定人员的试驾，就属于比较典型的验收测试，它是更高层级的、更贴近实际使用的一种确认，他们可能不懂软件，不懂汽车，只是从自己的需要上来给出判断。
还有个例子，你买新房交房时或者毛坯房装修后，业主要去验房，就是典型的验收测试，他们显然不那么懂装修、懂材料、懂建筑资质、懂行业标准，但他们会从使用上、美观上、感觉上去评判。
以往的汽车行业基本不太会关注终端消费者的切身体验，大家没那么多可选的，造什么买什么。现在及往后的时间，终端消费者会介入得越来越多，以新势力为领头的各大车企也会不遗余力地关注到他们的“验收”。
4、测试报告
测试报告及相应文档定义的主要的焦点在于 测试基础（需求或设计）和所有测试级别上相应的测试用例及结果之间的可跟踪性。
理论上或者说做得比较好的，这些测试相关文档都要通过配置管理管理起来。
测试执行后，得到的结果和评估结果被输入到不同格式的报告中。其中的评估必须要进行，以避免不适当的测试用例或测试环境引起的“假阳性”，就像最近持续做的核酸检测，要审核的。
测试失败的用例要建立相应的缺陷记录，以确保可追溯性。如果一个缺陷在专家评审后可以被接受，那么它也应该在测试文档中被清楚地注释。
5、测试汇总
这一部分就到了我们这条“脉络”的结尾，实际项目中很多都没有这部分，各类报告都是散落各处的、千奇百怪模板的、由各人负责的报告。
为了“客户”满意，我想这个工作包最好是有。
一份整体测试状态的汇总可以比较清晰地让内外部都知道当前的或历史的软件质量状态。
当然，做起来会有些障碍，特别是系统复杂、分工细的领域，及时且准确维护一张不断更新的大表是需要一番心力的，后续我们可以探讨下是否有改善思路。
文章有点长，但还是只能在“皮毛”和“脉络”上聊一下，毕竟测试是一门很大的学问。
最后呢，尝试总结一下这条“脉络”。
汽车软件测试是一项以寻找问题为主要目标，基于各种组织策略、测试原则和业务限制，而进行多层次验证并提供证据的管理和工程实践工作。
文章源自公众号 汽车软件质量