版权归作者所有，转载请注明出处
汽车控制器软件测试如何缩减？
我们今天谈一谈如何通过开发来缩减软件测试，不过我们不在这里讲自动化测试等缩减测试周期的方式，以后再讲。
首先为什么要缩减？因为缩减了时间就短了啊，作为整个开发环节的末端（在很多人心理运行起来的才叫测试，所以姑且这么讲），所有的时间压力都在你这里，项目会天天问你着催上市，开发也会天天问你（发现了bug没有，赶紧提交），在项目开展阶段所有人都会嫌弃你花了太多时间，在结束后出现问题时大家又会不约而同的想到你，所以为了不被嫌弃，需要做不懈努力~！
不过首先要分解一下软件质量，软件质量一部分是“产品是否符合用户的需求”，即用户需求的达成质量，另外一部分是“代码本身与代码目标功能间的差异”，即代码质量。对于第一部分而言，会涉及到最初所识别到的需求是否为目标用户需求，同时在用户使用过程中可能产生的潜在需求是否在设计之初有所考虑。这一部分不在今天所讲的内容之中，我们今天讲的是后一部分——代码质量的测试缩减。对于代码质量来说，在汽车行业基本上都会想到是测试的事情，为什么这么说呢？因为测试的主要任务就是发现bug，发现足够多的bug，甚至发现全部bug来使得代码质量没问题，所以当有的测试人员提出把保障代码质量交一部分给开发时，开发一定会说，“这不是你该做的吗？”，他们会觉得做这事是在承担你的工作，可事实真的如此吗？
首先测试是基于风险的活动，直白来说就是没办法保证发现所有问题。有的人会问，发现全部的问题“这不是你该做的吗？”，可是从现实来讲，光是针对一个会拥有40种诊断故障、代码量在10万行左右的控制器如果穷尽测试的话你得要几百年，而且是1秒执行一个用例的速度前提下，显然不是测试工程师不想办，实在是无能为力。可能有的人又会提出，我们有必要这么测试吗？我们可以静态审查一下程序实现情况，然后再根据需求大幅度的缩减测试用例（目标代码的功能测试），可是在从模型到代码（汽车控制器大多是基于可视化模型的编程语言开发的），再从代码到机器码，再把机器码刷到芯片里面的过程，没人能保证一定不会有问题，而很多又喜欢不会有问题，那么似乎只能测试了，可是穷尽是要时间要钱的，即便真有庞大的资源给我们用，作为一个社会经营单位来讲，还是要看看为了消灭最后一个bug而付出的代价是否真的值得。
既然测试关乎于风险，关乎于成本，那么我们可以很容易的理解开发提交的代码质量越高，发现问题的数量越少，那么为了关闭这些问题所付出的资源也就越少，所节约的资源要么我们可以用来减少项目风险缩减发布周期，要么也可以作为减少产品风险把时间用来做点别的测试，不过如果你不想做额外的测试，测试总时间一定是减少的。那么当开发所提交的代码质量足够高的时候，如果为了进一步的缩减测试成本、周期，还可以让开发对代码中的一部分做出更进一步的质量承诺，所承诺的这部分可以缩减测试甚至于不测试，不过做出承诺的前提是要有一定措施，比如开发采用了某种可靠的自动化工具，或者针对某一部分的严格可靠的作对检查机制，以及可靠的人员能力维模型并为之建立了培训机制等，不过不能为了让开发做出承诺而去要求，这对产品也是有极大风险的。
那么缩减测试除了这种针对开发的质量控制手段外，也有针对测试本身的缩减测试方法，后面我们会谈到。
