如何搭建满足ASPICE标准的工具链？

说到高效工作，在软件开发里面，效率比较高的必然会提到敏捷开发。虽然敏捷开发是否要引入到汽车行业还在争论不休，但我们都无法忽视一点：敏捷开发在在开发效率方面，确实有它独特的优势，所以汽车行业的工具链，至少也必须预留出，能够实现敏捷开发的入口。ASPICE的标准那么复杂，超过100页，那么究竟要如何满足哪些标准呢？我也总结了几点，供大家参考。这些也是在以前的工作中，我自己觉得难度特别高的。

第四就是变更评审。由于变更会造成整个上下游和合作方都会受到影响，所以汽车行业的变更评审一般是由变更委员会来进行共同评审的。评审通过之后，才能够正式地被放到backlog中，以待后面的开发。说到变更评审，首先是需要有多人评审，其次是需要有评审记录的。很多团队把这个过程放到线下，但需求、开发任务、测试用例等等，一般是放在线上的，而变更又直接影响了需求、开发任务、测试用例，这就导致了线上线下的不一致，或者说从线上追溯到线下，再从线下追溯到线上，可操作性很差。

第五就是线上测试管理。一般来说，测试体系的建立，相对是比较晚的，很多团队，最开始的时候都没有测试用例，完全靠工程师的经验手动随机测试，随着开发的进行才开始逐渐完善测试用例管理，实现测试自动化。在完善的过程中，很多团队还是习惯于用Excel来管理测试用例。这也造成了一个问题，如果需求、开发任务、Bug都已经在线上系统中跟踪，但是测试用例又放到了线下，线上的需求和开发任务会根据需求变化不断迭代，这就意味着，测试用例也需要不断迭代，有时候可能还需要保存测试用例的不同版本。线下管理的复杂性就会大大提高。线下管理测试用例的另一个难点就是，不方便出具测试报告。测试执行报告可能还行，但是Bug遗留的情况，Bug状态的分布，需求覆盖度、测试用例覆盖度等报告，就非常难以提供。