最近时不时和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的恶性循环
做到以上几点,一方面可以提高开发效率,另一方面可以保证代码质量。这样子开发,是不是更科学一些呢?
联系客服