电子发烧友App
美女看嵌入式工具市场的发展
我想紧接着上一篇就嵌入式软件测试的现状谈一下，首先从中国的国情来说，当国外的研发人员为自己没有把软件缺陷降到最低而苦闷的时候，我们的研发人员则还是为了温饱而苦闷，为什么国内很多研发人员到35岁左右他们就想转行或投身于销售或转做管理，难道是因为他们已经做不了研发，因为公司没有给他们职业规划，他们找不到自己的晋升机会，因为到了这个年龄生活已经不是一个人的事情了，由此导致我们国内IT技术人员放弃多年的研发经验投身于别的产业，这难道不是技术人才的浪费吗？
让我们再看看软件行业的的研发人员和软件测试人员的人员配置比例，据调查国外软件行业的比例是1：1或1：3，在国内的实际比例是10：1，就工资而言国内的测试人员的工资比研发人员的还低，所以测试人员和开发人员面临同样的问题就是技术熟练的时候转行。测试之所以产生是因为研发不能够把软件缺陷降到最低，所以才有了测试人员，他们的价值因为软件缺陷而存在。缺陷存在，测试存在，缺陷消失，测试也会消失，当然后者是永远不可能的！所以我们中国的软件质量的腾飞就全靠我们的研发人员和测试人员了！相信中国的软件企业也会对越来越对软件质量加以重视，给我们的研发测试人员给予努力的动力！
我现在就从上一篇文章中我介绍过测试方法，里面有些概念我想在这里做了个解释方便没有做过测试的人了解，也给正在做测试做个参考选择，哪个阶段应该采用哪种测试。希望能对你们有有用的信息。
黑盒测试 (Black box testing) ── 不考虑内部设计和代码，根据需求和功能进行测试。
白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。
部件测试 (Unit testing) ── 最小范围的测试，针对特定的函数和代码模块进行测试。因为需要了解程序的设计和代码的细节才能进行，所以部件测试一般是由程序员，而不是由测试人员来做。除非应用软件的结构设计良好，而且代码也写得清楚，否则部件测试并非易事。也许需要开发测试驱动模块或测试工具。
递增的综合测试 (incremental integration testing) ── 不断进行的测试过程，每增加一个新的功能模块，都进行测试。这要求一个应用软件在最终完成之前，各功能模块要相对独立，或者已根据需要开发出测试驱动软件。这种测试可由程序员或测试人员进行。
综合测试 (integration testing) ── 对应用软件的各个部件进行组合测试，来检查各功能模块在一起工作是否正常。“部件”可以是代码模块、独立的应用程序、也可以是网络中的客户/服务器应用软件。这种测试特别适用于客户/服务器环境和分布式系统。
功能测试 (functional testing) ── 对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。)
系统测试 ── 针对全部需求说明进行黑盒测试，包括系统中所有的部件。
端到端测试 (end-to-end testing) ── 类似于系统测试，但测试范围更“宏观”一些。模仿实际
应用环境，对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、
应用程序和系统之间的相互作用是否满足要求。
健全测试 (sanity testing) ── 是一种典型的初始测试。判断一个新的软件版本的运行是否正常，是否值得对它作进一步的测试。例如，如果一个新的软件每 5 分钟就破坏系统、大大降低系统的运行速度、或者破坏数据库，那么这样的软件就算不上是“健全”的，不值得在目前状态下进行进一步的测试。
回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。
认同测试 (acceptance testing) ── 基于说明书的、由最终用户或顾客来进行的测试。或者由最
终用户/顾客来进行一段有限时间的使用。
负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。
压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。
性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。
可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感
觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。
安装/卸载测试 (install/uninstall testing) ── 对安装/卸载进行测试 (包括全部、部分、升级操作)。
恢复测试 (recovery testing) ── 在系统崩溃、硬件故障、或者其他灾难发生之后，重新恢复系统的情况。
安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。
兼容性测试 (compatability testing) ── 测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。
认同测试 (acceptance testing) ── 看顾客是否对软件满意。
比较测试 (comparison testing) ── 与竞争产品进行比较，以找出弱点和优势。
alpha测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小
的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
beta测试 (beta testing) ── 当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
从我们公司从事嵌入式软件测试及软件测试的工具推广来的经验来看，为了更好的遵循一些标准和规则，使代码更具有具有可读性和可维护性，建议对于写 C 和 C++ 代码开发的人员可以参考一下建议：当然不太适合一切情况，仅供参考！
1、减少或排除全局变量的使用。
2、使用说明性的函数和方法名 —— 使用大、小写字符，避免用缩写，使用满足要求的说明文字来进行充分的描述 (使用超过 20 个字符也不致超行)。取名要与功能一致。
3、使用说明性的变量名 —— 使用大、小写字符，避免用缩写，使用满足要求的说明文字来进行充分的描述 (使用超过 20 个字符也不致超行)。取名要与功能一致。
4、函数和方法的大小要尽可能小 —— 最好不超过 100 行，少于 50 行最好。
5、在函数代码前面的函数的说明文字应当清楚。
6、书写代码应便于阅读。
7、在水平方向和垂直方向都留出足够的空间
8、每行代码字符数不超过 70 个
9、每条语句占 1 行
10、一个程序内的代码风格应一致 (在使用括弧、缩排、和命名方式等方面)
11、注释内容宁多勿少，通常注释行的数量 (包括开始部分) 应当不少于代码行的数量
12、不管应用程序多么小，都应有文档，包括程序功能的概述和流程图 (哪怕只有几行字，也比没有要好)。如果可能的话，最好有单独的流程图和详细的程序文档。
13、尽最大可能使用错误处理过程，并对状况和错误进行记录。
14、在使用 C++ 时，为了减少复杂程度和提高可维护性，应当避免类的继承的层数过多 (这取决于应用程序的大小和复杂程度)。除要尽量减少继承的层次以外，还应少用超负荷运算符 (minimize use of operator overloading)。使用 Java 语言可以消除多级继承和运算符超负荷。
15、在使用 C++ 时，保持类的方法不要太大，对于每各类的方法，代码行不超过 50 行为最佳。
16、在使用 C++ 时，应自由进行例外的处理 (make liberal use of exception handlers)
软件测试是个大工程，需要开发人员和测试人员协调配合完成，如果开发人员在编程的时候能按照一定准则去编程，这对后面的单元，集成测试也是减少很多压力，当然每个编程人员的编程习惯不一样，所以会按照规范去做，会和自己多年的编程的风格有冲突，所以推动规范还是一件比较有挑战的工作。这也是很多企业遇到的问题。
下面我就上一篇提到的QAC这个软件测试工具做个介绍；它是英国Programming Research公司的，PR公司是专业从事软件设计方法学和软件编程规范研究的公司，是MISRA的主要起草者，QA C/C++/Java分别是针对三种源代码语言的代码规则检查和静态分析工具，用于鉴别C/C++/Java语言使用过程中出现的问题，这些问题包括语言中比较危险、过于复杂、不可移植、难于维护的特性，或者是编码不符合特定的规则。而这些问题是不能靠编译器或开发工具识别的。为什么要做代码规则检查？是标准要求必须进行的软件质量保证过程。军标Z121、DO-178B标准、CMM/CMMI认证都要求强制进行代码规则检查。GJB5369更进一步规定了C语言编程规范。自动代码规则检查能在软件开发早期早期自动检测出软件错误和安全隐患，能够在软件开发的早期有效保证软件代码的质量；而且可以在同一个开发团队形成统一的代码风格，减少代码维护性和单元/集成测试时间，增加团队凝聚力和提高生产效率。
下面简单衔接一下关于行业内的常见一些认证及标准做了个简要解释；
1、SEI = “软件工程研究所 (Software Engineering Institute)”，设在卡内基梅隆大学，为改善软件开发过程，由美国国防部创建。
2、CMM = “性能完善模型 (Capability Maturity Model)”，由 SEI 开发。它是一个分 5 级的、可以描述结构完善程度的模型，用它来说明所交付的软件的效能。它适用于大的机构，例如美国国防部的承包商。所以，它所涉及的许多质量控制过程适用于任何机构，如果合理地利用它，将会获益不浅。一个机构经过权威评审机构的评估，可以得到CMM 等级 (CMM ratings)。
3、1 级──表现混乱，定期需要应急措施，需要经过很大努力才能完成项目。很少有适当的过程，成功不可重复。
4、 2 级──软件项目跟踪、需求管理、合理计划、以及结构管理过程适当，成功可以重复。
5、3 级──标准软件开发和维护处理过程完整地在整个机构内贯彻。有一个软件工程处理组来坚实软件过程，开
设培训课程来确保理解和一致性。
6、4 级──对生产、处理和产品进行跟踪，项目的特性是可预见的，非常重视质量。
7、5 级──重视持续地改善处理过程。新的处理过程和新技术的效果是可预见的，在需要时使用它们便可提高效率。
(关于 CMM 等级的前景：1992-1996 年间，共有 533 个机构经过评估。其中 62% 的机构属于 1 级，23% 为 2 级，13% 为 3 级，2% 为 4 级，0.4% 是 5 级。中等大小的机构有 100 个工程师/维护人员；31% 的机构是美国国防部的承包商。在那些CMM 等级为 1 级的机构里，有问题的关键处理领域在于软件质量保障。)
8、ISO = “国际标准化组织 (International Organisation for Standards)” ── ISO9001、9002 和9003是针对质量系统的标准，由外部的评估人员进行评价，适用于许多类型的生产和制造机构，而不仅仅适用于软件开发。其中最复杂的是 9001，它被广泛用于软件开发机构。9001 涵盖文档、设计、开发、生产、测试、安装、服务和其他过程。ISO 9000-3 (不是9003) 是 ISO 9001 用于软件开发机构时的指导方针。美国版的 ISO 9000 系列标准与国际版完全相同，被称为 ANSI/ASQ Q9000 系列。美国版可以直接从美国质量协会 (ASQ ── American Society for Quality) 或者 ANSI 购买。一个机构要想获得 ISO 9001 认证，需要有第三方的评价人员进行评估，所获得的认证的有效期为 3 年，届时需要进行再评估。注意：ISO 9000 并不是表明产品质量所必需的，它只是表示文档所规定的处理过程都
被遵循。
9、 IEEE = “电学和电子工程师协会 (Institute of Electrical and Electronics Engineers)” ── 除作其他事情以外，还制定了以下标准：
10、IEEE/ANSI Standard 829 ── 软件测试文档标准
11、IEEE/ANSI Standard 1008 ── 软件部件测试 (Unit Testing) 标准
12、 IEEE/ANSI Standard 730 ── 软件质量保障计划
以及其他一些标准。
13、 ANSI = “美国国家标准协会 (American National Standards Institute)” ── 是美国主要的工业标准实体；与 IEEE 和 ASQ (American Society for Quality ── 美国质量协会) 协力，也出版了一些与软件有关的标准。
14、除 CMM 或 ISO 9000 以外，其他的软件开发过程评估方法有：SPICE，Trillium，TickIT。和Bootstrap
MISRA (The Motor Industry Software Reliability Association 汽车工业软件可靠性联会) 是位于英国的一个跨国汽车工业协会，其成员包括了大部分欧美汽车生产商。其核心使命是为汽车工业提供服务和协助，帮助厂方开发安全的、高可靠性的嵌入式软件。这个组织最出名的成果是所谓的MISRA C Coding Standard，这一标准中包括了127条C语言编码标准，通常认为，如果能够完全遵守这些标准，则你的C代码是易读、可靠、可移植和易于维护的。
DO-178B标准：飞机分成二类：军用飞机与民用飞机。每个国家对军用飞机的研制都有自己的标准和质量监督体系；但对于民用飞机说，由于一个国家研制的飞机会飞到其它国家去，这就要求有一个能够被国际普遍认可的标准和质量体系来保证飞机的安全。具体地说，飞机通常需要通过四个认证以后才可真正投入运营：也即定型认证（Type Certificate）、生产认证（Production Certificate）、适航认证（Airworthiness Certificate）、运营认证（Operational Certificate）。这四个质量认证涉及的标准有很多，构成一整套标准体系，而DO-178B标准则是对机载软件进行适航认证时适用的标准，是整个民航标准体系的比较重要的一个标准。
执行DO-178B标准质量认证的权威机构在不同的国家和地区不尽相同。在欧洲，该质量认证由EASA（European Aviation Safety Agency）来执行；在美国由FAA（Federal Aviation Administration）执行；在加拿大则由Transport Canada来执行。通常，被一个机构认证通过的飞机在一定条件下也会被另外一个机构默认通过。
Def Stan 00-55, 1997年9月英国国防颁发了Def Stan 00-55“防务装备中与安全性有关的软件要求”，对如何保证装备安全性对软件提出具体要求。
工商网监
评论