标签: 软件工程

版权声明： 本文由博主 “cuter” 发布。欢迎转载，但不得擅自更改博文内容，也不得用于任何盈利目的。转载时不得删除作者简介和版权声明。如有盗用而不说明出处引起的版权纠纷，由盗用者自负。 博客官方地址： ChinaAET ： http://blog.chinaaet.com/cuter521 EDN China ： http://bbs.ednchina.com/BLOG_cuter521_356737.HTM     最近时不时和 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 实际上就是常说的静态代码检查，通常是使用一系列代码检查工具对代码进行分析，对不符合既定规则的语句进行评估，并给出 warningerror 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 的恶性循环 做到以上几点，一方面可以提高开发效率，另一方面可以保证代码质量。这样子开发，是不是更科学一些呢？

我这么说并不是玩笑：软件工程师的能力问题在这样一个广泛连通的世界里只会变得越来越紧迫。 就在不久前，一个四年制计算机科学与工程专业的毕业生还可以在专业软件工程机构找到一个入门级职位，然后与同事、经理一起工作并享有培训机会，当然最重要的是还可以掌握正规的开发方法和最佳实践。 而通常来说，这样的员工需要经过约一年的培训和实践后才能给团队带来效益。 而当今社会则充斥着大量零散的工作需要软件程序员来处理，因此，对软件程序员的巨大需求使得软件工程领域的这种事实上的学徒制方法变得越来越少见或者消失了，因为在日趋紧张的交付时间要求下，这种学徒制方法简直就是一种奢望。 最终人们会发现，所有的热情、编程马拉松和冲刺都无法弥补个人在专门技能方面的缺失与不足。而软件团队通常会掩盖个人在技能方面的不足，但这仅仅是因为其他成员帮助弥补了那些技能不足者的低生产率。 实际上，根据软件质量与度量领域专家、Pyxis Systems International公司总裁G.Gordon Schulmeyer先生所言，当前形势非常严峻，所有大型项目中都可能存在着一些Schulmeyer称之为“净负生产程序员(NNPP)”的人，而这些人所做的破坏要超过他们的产值。 在《净负生产程序员》(The Net Negative Producing Programmer)一文中，Schulmeyer写道：“负生产并不仅仅适用于极端案例。假设在一个十人团队中，三名成员的缺陷率都高到足以列入净负生产程序员的行列，那么，在技能常态分布的情况下，一个十人团队中没有一人是净负生产程序员的可能性为零。而如果你不幸分到一个缺陷率高的项目团队中(即每1000行可执行码中有30个~60个缺陷)，那么你所在的团队中，有可能一半的成员都是净负生产程序员。 那么，如何才能知道自己是否是一名合格的软件工程师？如何才能让公司、经理和团队成员知道你不是一名净负生产程序员呢？   Jacob Beningod在他最近的一篇博客 《硬件工程师该如何成为软件专家》 里给出了很多建议，其中一条就是获得行业认证。这似乎是个好主意，所以我要好好琢磨一下为什么实际上很少看到有人这么做，为什么相当少的软件从业者拿到了行业认证。 如果说仅仅一小部分在职软件工程师曾经学过四年的软件工程课程，这话并无偏颇。事实上，在美国只有22个这样的课程设计。我们绝大多数软件工程师都是在接受正规的计算机科学教育后再接受在职训练，但计算机科学教育并不同于软件工程。 Construx Software公司首席顾问兼IEEE计算机学会认证委员会主席Steve Tockey说：“你不会派一位化学专业人员去解决化工问题，同样，为什么我们要让计算机科学家去解决软件工程问题呢？” Tockey所在的委员会负责如下IEEE认证项目(引自IEEE计算机学会)： ● 初级软件工程师职业资格认证(CSDA)—针对应届软件工程师和初级软件从业人员。 ● 软件工程师职业认证(CSDP)—针对希望证明其软件开发能力进一步拓展事业的中高级软件从业人员。 Tockey说：“这背后的问题是，雇员和雇主们都对必需的技能和知识缺乏了解。做出雇用决定的人常常不知道这些东西。所以要帮助他们弄清楚。” CSDA/CSDP项目代表的技能与知识体现在软件工程知识体系(SWEBOK)指南中，该指南包含了人们普遍认可的软件工程核心知识。ISO/IEC 24773于2008年发布了这一国际权威指南，从而使CSDA/CSDP被全球广泛承认。 实际上，IEEE计算机学会还特别针对印度和中国推出了SWEBOK认证项目(SCP)。按IEEE计算机学会的说法，印度有约130万名软件、计算机科学和计算机工程专业的学生，每年要毕业数十万相关专业的大学生，然而最近对超过5.5万名工科生的抽样调查表明，只有17%的学生符合任职条件。 SWEBOK Guide初版于2004年推出，现正在修订。但现在已有SWEBOK Guide V3讨论稿，据Tockey说，SWEBOK Guide V3很可能在今年年底稍做修改即公开发布。 Tockey说，从2004年的指南到V3版，最显著的变化包括： ● 增加了新进展，比如敏捷开发； ● 更强调安全； ● 与CSDA/CSDP知识同步。 V3中的另一变化是将2004年版中的大量核心参考文献裁减到了可控范围。事实上，即便你不想付出太多，怎么也得把SWEBOK Version 3 Consolidated Reference List吃透了。如果你想提升自己的技能，不妨就从这里开始。 正如Tockey所说，认证并不保证你能胜任什么，但它减少了你被淘汰的风险。有时候，知道这一点就够了。 《电子技术设计》网站版权所有，谢绝转载