汽车电控软件开发流程ASPICE之Checklist检查清单

wmwlove

一、概述
      在日常工作中，由于状态、心情、工作的熟练程度等等因素，人都会犯错误，特别在非常关键的领域，犯错误将导致人身伤害，财产损失。而在汽车领域，软件设计过程中，人为的因素导致的错误轻则导致开发成本直线上升，重则带来汽车安全事故。通过检查清单Checklist，通过检查清单的交叉确认，可以大幅降低人的因素导致的软件bug，而又不需要付出太多的人力、时间及金钱成本。从而使得Checklist一定小巧方便使用、内容及其关键、不会耗费太多时间的文档。


因此，在ASPICE标准流程中，在关键的开发及管理过程都会涉及到检查清单，将该元素深度的融入到整个标准中去。

SYS.2 系统需求分析  

包含系统需求分析流程检查清单、系统需求分析计划检查清单、系统需求规格书检查清单等。

SYS.3 系统架构设计  

包含系统架构设计检查清单、系统架构设计流程检查单等。

SWE.3 软件详细设计

包含软件详细设计检查清单等。

SWE.4 软件单元测试  

包含软件单元测试流程检查清单、软件单元测试计划检查清单、软件单元测试检查清单、软件单元测试代码评审检查清单等。

二、示例

例如软件单元测试的检查清单必须检查项

测试规范、测试报告等文档

1.用例是否按照公司规定的模板进行编写？

2.文档是否参考之前规范性文档的编制方法？

3.文档命名是否规范？

4.文档模板是不是最新模板？

测试用例

1.每条需求是否都有用例覆盖?

2.测试用例测试是否都有正反面用例?

3.用例设计是否采用了边界值、等价类和错误推测主要的用例设计方法？

4.用例是否定义优先级？

5.测试用例的设计是否考虑了测试场景

6.用例是否清晰地描述了预置条件？

7.用例是否清晰地描述了操作步骤？

8.用例是否清晰地描述了预期结果以及预期结果是否可以验证？

9.用例设计是否考虑了正向和反向两方面的情况？

10.用例是否根据多输入条件的组合情况，逐一编写测试用例？  

11.测试用例及测试需求的追溯性是否存在？

12.测试用例与需求编号是否按照命名规则进行命名？

13.用例是否经过评审？

测试问题管理

1.测试问题是否都已记录？

2.测试问题是否都已修复，并且写明了故障原因及修复手段？

3.测试问题管理表中是否明确描述了问题？

4.测试问题是否写了检出日期已经对应的代码模块？

三、总结
      在使用检查清单Checklist的过程中，不需要建立非常细节的检查项，会导致工作繁琐，失去Checklist的本身价值，而是需要对检查项进行提炼，方便使用，起到提醒和纠正的作用。检查项的来源主要来自于个人工作经验、技术经验、个人错误、各种关键的信息、团队对于自己工作的要求等等。它不仅仅可以用于指导自己，也可以用于指导自己的团队成员，避免一些人为错误。