【精品博文】闲聊代码测试
最近时不时和TL聊一些怎么提高开发效率的东西，不是说具体而微的技术，大都是抽象层面的，包括软件的maintainence、FCI（function component implementation）、FCF（function component functionality）等，用一个词概括的话，大概可以说是软件工程。今天聊一聊代码测试，算是一个小的总结。
1）FCI test
想要谈针对FCI的测试，不得不先聊一下什么是Implementation。
1.1）什么是Implementation？
Implementation的关键字有3个，分别为：logic、standard、code，串起来：按照一定的编程规则将所设计的逻辑转化为代码的过程。定义本身很形象地描述了ECU软件的coding过程。实际上我们对Implementation的定义是暗合软件工程方法的——IEEE对软件工程的定义是：软件工程是将系统性的、规范化的、可定量的方法应用于软件开发、运行和维护。
1.2）怎样完成Implementation？
没有人强制你按照什么样的方式去开发，老板只会问你要结果。所以，你可以拿到需求直接就在脑子里建模，开始编码。也可以不管代码，首先高屋建瓴，考虑软件的架构、复用性、需不需要高级的设计方法等问题，设计出software concept，然后在此基础上进行function design，最后再把function design转化为code。
按照尽量frontloading的思维方式，我们应该把更多的时间放在function design上，而不是代码本身。前期花更多的精力设计software concept和function design，coding就很简单了，只要把设计好的逻辑转化成代码就可以了。如果采用图形化编程工具（如ASCET、MATLAB SIMULINK等）完成function design，可以通过code generator直接生成代码，而不用手动编码。代码出炉之后，怎样保证代码质量呢？
1.3）test against Implementation
完成了Implementation，紧接着要做相应的test去保证代码质量。当然你也可以先不做，后期做其他测试或许可以cover掉，或者说是prove in use。但是，如果你的代码有了问题，需要返工，那么这期间所有的工作都白费了，并不是所有开发都可以随心所欲的trial and error...
针对Implementation的概念，也必然要从两个方面去考察代码质量：
- standard
实际上就是常说的静态代码检查，通常是使用一系列代码检查工具对代码进行分析，对不符合既定规则的语句进行评估，并给出warning&error report。静态检查是针对编程规则而言的，所以规则不同，检测结果也不尽相同。除了公司自有的工具，我知道的静态检查工具有PC-Lint，不过没用过。
- logic
逻辑的检查需要在代码运行过程中进行检查，也不一定非得做HIL测试，仿真层面就可以验证逻辑的正确性，我想这也是图形化编程工具的优势之一，在功能模块开发完成之后，不需要联合调试就可以保证自身的正确性。在后期进行集成测试时，出错的概率就很小了。
总而言之，FCI test是为了尽可能早地发现设计存在的问题，从而降低软件更改成本。
2）FCF test
FCF是针对需求的测试。说到需求，就有意思了——对于不同的人来说，需求是不同的，不同的人对需求的理解也是不同的。举个简单的例子，一个项目涉及三个人：客户、系统工程师、软件工程师。在拿到客户需求后，系统工程师会和客户进行沟通，并按照自己的理解将客户需求进行转化，设计相应的物理概念、软件概念，然后把软件需求输出给软件工程师。这样经系统工程师转了一手，到软件工程师手里的需求，有时候会变得很尴尬。比如，有时候我们会接到这种需求：把项目1里的A功能模块移植到项目2里。拿到这样一个任务的时候，我们该怎么做FCF test？我们是应该问清楚客户的需求，去针对客户需求做测试，还是针对移植本身做测试？流程细化之后，这也是个不得不面对的问题，有些时候为了完成工作本身而开展的所谓的测试，是不是真正需要的测试？
上面这个例子有点狗血了，因为对客户而言，系统工程师和软件工程师是一个整体，客户眼中只有XX公司，他不会管你做了多少测试、用什么样的方式保证代码质量，人家只要质量有保证的代码。所以作为一个team而言，最终需要完成的还是针对客户需求的测试，从而保证代码的正确性。
怎样更好滴完成FCF测试？
人们都喜欢待在让自己舒适的环境里，软件工程师也一样，会不由自由地进行逻辑测试、代码调试，然而这些并非是FCF测试，因为FCF应该是针对需求的。我们不应该站在自身的角度进行测试，而应该换位思考，站在用户的角度对自己的产品进行测试。
一种好的方法是在需求分析过程中和客户一起讨论有哪些use case。这样做有几个好处：一是use case写完之后，test case基本上也成型了，而且这时候工程师的大脑还没有被代码“污染”，test case不会强调没必要的细节；二是，use case是由客户确认的，软件释放之后，客户不能摆摆手说这不是我想要的。
3）关于开发效率
- 为了更正确地进行FCF测试，前期要花时间和精力设计use case和test case
- 花更多的精力进行function design而非code design
- 完成编码后，正确地进行FCI测试，保证代码的正确性，而不是直接将功能集成进系统，进行功能测试，那样容易陷入trial and error的恶性循环
做到以上几点，一方面可以提高开发效率，另一方面可以保证代码质量。这样子开发，是不是更科学一些呢？