2.4 软件研制过程
整个航天型号的研制，从五六十年代开始，比如从事导弹研制，纯硬件走的过程就是：先方案设计->可行分析->关键技术攻关->危险分析->确定最终要做出些什么目标，最后形成产品配套表，就转初样。
初样阶段是主要设计工作，基本要成型了。研制过程受控，技术受控，质量归零那就转正样。正样基本上不作太大的改动了。非军方型号这就是最终版，军方的话还要过定型实验最后一关。
既然软件也按产品要求，那么软件的研制流程也要跟着整个航天型号，把方案->初样->正样->定型（最后一个定型仅限军用）几个阶段全部流转一遍。
从软件测试工程师的角度上来看，目前压力最大的是软件初样转正样的转换阶段，因为这个阶段要求完成开发方的全部单元、集成、配置项和系统测试，完成第三方软件测试，完成质量归零。不过不是所有的软件都得这么流转一大圈。因为软件是可以复用的。
提到复用，大家有没有又想起最开始那个阿丽亚娜的故事？这个教训时刻提醒着中国航天人。所以目前中国航天里对复用是分了这么四类来严格要求的：
I类：沿用：不加修改即可再次使用，需要经过沿用可行性分析与审批，在系统需求分析与设计的时候即提出可沿用，做沿用可行性分析。沿用状态复核之后直接参与分系统联试（验收测试）。
II类：只修改装订参数：任务书可能重新出也可能不变，可执行代码不变，需要完成适用性分析、状态符合及参数修订、实施、回归测试等验证活动，在系统需求分析与设计时候可能需要重新出版任务书，做更改可行性分析和影响域分析，及对应的软件状态复核和影响域分析评审。确定只更改参数即可。
然后根据影响域分析做软件回归测试。再做分系统联试等后续工作。应有的第三方评测也要同步开展。
III类：少量的修改；任务书必须要重新出，需求设计等侧重更改，技术状态控制等，这个对于研发一个新功能对软件测试工程师来说区别就不太大了，逐级需求/概要设计/详细设计更改评审，回归测试和第三方软件测试都要求做。部分单位甚至在总体上最基础的要求上提升了更严格的要求，只要改动了一点点，全部代码重测。
IV类：全新研制，完成全部软件过程流程。
2.5 FPGA
可能很多人听到这里就奇怪了，这名词不是书硬件上的吗？但是毕竟可编程逻辑语言它也是代码，近些年来航天航空和各军兵种都陆续把FPGA也归入到了软件研制来一起管理
三、归零问题
下面我们来讨论航天人最头疼的质量归零问题。但是不是所有软件测出的问题都算作需要归零处理的。
首先先说个质量问题分类：
· 一般质量问题；
· 归零质量问题。
由质量系统根据严重程度来判定到底是一般质量问题还是归零质量问题。
比如，软件测试里发现开发工程师编码的时候由于手误，把"if(a==b)"敲成了"if(a=b) "。一般情况下这就是个一般质量问题，报了问题单，设计人员更改了，一切可以了。但是如果这个问题频繁发生，那就不能算一般质量问题了，需要归零。具体两者的分界和把握，有点像是ISO 9000体系的一般不符合和严重不符合/体系不符合的区别，就看具体质量人员的分寸了。一次两次把"=="敲成"=",没关系；但是频繁出现同样的问题那就要做检查了，是不是开发工程师的技术不过关。
归零是航天里对性质比较严重的问题的处理方式。字面意思，通过处理，最终要让它归为零，再也不出现。假如出现了一个需要归零的质量问题了。那么下一步，这个问题是技术归零还是管理归零？
3.1 技术归零
我们先来看看相对比较轻松的技术归零。是这样要求的：
为了彻底解决问题，避免重复发生，必须按"定位准确、机理清楚、故障复现、措施有效、举一反三"五条标准逐项落实，并最后形成文件也就是要求写归零报告。
· 定位准确：是根据实际情况和需要，对在航天产品研制的过程中发生的所有软件质量问题，要准确确定发生问题的部位，即定位到软件基本单元。
· 机理清楚：是指质量问题一旦定位后，要通过地面试验即软件单元测试、配置项测试、系统联试或故障注入测试等和理论分析等各种手段，弄清问题发生的根本原因。
· 故障复现：是指在定位准确和机理清楚后，通过地面模拟试验或其它试验方法如单独的软件测试试验；或与硬件系统的联试，但能与硬件系统确切隔离来复现问题发生的现象，从而验证定位的准确性和机理分析的正确性。
· 措施有效：是指在定位准确和机理清楚的基础上，制订出有针对性的、具体可行的纠正措施、实施计划及回归测试计划。对影响任务成败的重大问题，其措施要经过评审，并返回所属系统，进行系统级的试验验证。
· 举一反三：是把发生的质量问题的信息反馈给本单位、本系统、本型号（由本单位质量部门负责）和其它单位、其它系统、其它型号（由上一级质量部门负责），从而防止同类事件的再发生。
发现了一个问题，必须得定位清楚到底是什么原因，哪里造成的。
曾经有人问，假如软件测试过程中发现了一个不可复现的问题怎么办？航天软件测试是不允许出现"不可复现"的问题。只要发生过问题，刨根问底也必须找出来。因为只有找准了原因（或者说只要找准了原因），这个问题才可能按要求复现出来。复现不出来，说明找的原因还不对，还需要继续找。
最终找到这个原因，确实按这个原因来执行每次都能复现，那就是问题。然后再制定纠正措施（纠正措施绝大多数都要过评审，一般是问题发生单位与其总体单位参审，严重的可能总师系统也要来人），纠正完了调试，确保问题不再复现。再根据纠正措施的影响域过回归测试等一系列流程。
最后，还有个举一反三。那就是通告所有相关单位，本型号所有相类似的设计统统按此问题修改，修改范围非常大。可能其他类似设计并没有发生问题，但是有隐患就要统统排除，完成以上全部操作，最后写成文字性的归零报告，总体上质量处都要留存的。
可是，即使这样，为什么还要说，技术归零还是相对比较轻松的呢？
3.2 管理归零
我们来看看质量问题如果编为管理归零，有哪些要求。为了彻底解决问题，避免重复发生，必须按"过程清楚、责任明确、措施落实、严肃处理、完善规章"五条标准逐项落实，并形成文件。
· 过程清楚：是查明质量问题发生、发展的全过程，从有关的每一个环节中，分析问题产生的原因，查找软件管理上的薄弱环节或漏洞。这是管理归零工作的基础，要做到实事求是、过程事实准确。
· 责任明确：是在过程清楚的基础上，分清造成软件质量问题各环节和有关部门人员应承担的责任，并从主观和客观、直接和间接方面区别责任的主次、大小。这是管理归零工作的依据，要做到具体明确、主次分明。
· 措施落实：是要针对出现的软件管理问题，迅速制定并落实相应有效的具体纠正和预防措施，堵塞管理漏洞，举一反三，杜绝类似问题的重复发生。这是管理归零的基本内容，要做到措施具体、有效。
· 严肃处理：首先是在思想上、态度上要严肃、认真地抓紧对质量问题的处理和改进管理工作，避免走形式，敷衍了事；其次是对由于人为责任问题、重复性故障以及明显因有章不循、违章操作等原因造成软件质量问题的有关责任人员，要根据责任和影响的大小，按有关规定给予一定的行政处分或经济处罚。这是做好归零工作的重要管理手段和有力保障。
· 完善规章：是在查找问题、分析原因、落实措施、严肃处理的基础上，针对管理漏洞，修订和健全规章制度，落实到有关岗位和管理工作的有关环节上，约束和规范管理行为和软件开发活动，杜绝质量问题的重复发生，这是改进和提高管理水平的根本途径。
过程清楚，措施落实，完善规章，这些都是亡羊补牢性质的。但责任明确，严肃处理这两条是非常严厉的。
跟技术归零不同。技术问题，交代清楚问题成因，技术人员就算是过去了。毕竟技术上总有很多不可控的风险。
管理归零的话，那就要处分几个人的。该撤的撤，该罚的罚。一旦出了管理归零，基本上就有一批人被开除。
如何来判断合适采用技术归零还是管理归零是由质量人员来决定。
· 问题一旦出现，纯技术的可以处理一般的来说采用技术归零，技术归零可以单归零。
· 管理归零基本上都是双归零，也就是说，管理归零必然伴随着技术归零。
所以在航天领域质量人员的权利是非常大的。
四、软件测试技术要求
后面的技术要求，摘自载人航天工程软件工程化技术标准的目录：
· CMS-RW-01 软件研制过程；
· CMS-RW-02 软件文档编制；
· CMS-RW-03 软件评审细则；
· CMS-RW-04 软件测试细则；
· CMS-RW-05 软件验收、移交和保障细则；
· CMS-RW-06 软件配置管理细则；
· CMS-RW-07 软件设计和编程指南；
· CMS-RW-08 软件研制技术流程；
· CMS-RW-09 软件安全性细则；
· CMS-RW-10 软件安全保密性细则；
· CMS-RW-11 外购软件选用细则；
· CMS-RW-12 FPGA软件研制技术要求。
这是一本500多页的白皮书，其实本质上的东西跟一般的软件工程教材差别不太大。
总体来说，每项标准要求都是找得到原始来源的（比如编程指南，C语言基本脱胎于MISRA C之类的，参见附录C）。
软件测试这边，921办公室首先把所有的软件分成两大类：处理器软件（也就是我们常规意义上的软件）和FPGA软件。处理器软件，要求按软件测试级别来说，单元测试、集成测试、配置项测试、系统集成四大级别都要做。所有的软件工程做起来其实都大同小异，理念差不多，麻烦的是那些小异的地方，编写这类文档是非常费力的。航天软件，包括军方的，都是要求把一个一个的软件单元函数集成起来，成为的那个能独立运行具有自有功能的软件，就是软件配置项。可以把它认为是单个软件，然后软件跟硬件去作软硬件集成测试，或者有互操作的各软件之间的系统集成测试。按软件测试方法来说：
· 静态测试：包括文档审查，代码走查，代码审查，代码规则检查，静态分析等。
· 动态测试：包括功能测试、性能测试、外部接口软件测试、余量软件测试、边界软件测试等，必要时还有人机界面软件测试、强度软件测试、可靠性测试、安全性测试、恢复性软件测试、安装性测试、互操作性软件测试和敏感性软件测试等。
静态测试很多时候都要用到工具，代码规则检查和静态分析基本全用到工具，审查走查是人工。其中对逻辑测试的要求也就是覆盖率要求，前面提了，三个百分之百。高级语言的AB级别的软件还要加上目标码覆盖百分之百。
需要做何种软件测试，总体在书写开发任务书的时候也要给第三方软件测试单位确定测试任务书，评审软件测试需求的时候就要确定下来。
说到软件研制过程，像ISO 9000那样规定了不同的过程控制，每个过程都有对应的输入输出产品。软件研制分为九个过程分别是：
· 系统分析与设计；
· 分系统分析与设计；
· 软件需求；
· 软件设计；
· 软件实现；
· 软件测试；
· 验收交付；
· 试验验证；
· 运行维护。
系统设计是把系统功能划分成不同配置项。这里的系统可能是软硬件结合的一个单板，甚至可能是单机设备甚至更高层。
对于FPGA研制过程管理。这是最近几年才新定的。作为质量管理的过程，分得越细，管理起来肯定更严格，但对应的质量管理成本也越高。
我们国家制定的这些标准参考了先进国家的经验，现在可以看查到并且能看的无非就是NASA跟ESA。NASA对FPGA研制分的六大过程。ESA分得细一些，有十三大过程。总后装备部921办公室决定向ESA学习：质量第一位，哪怕前期多投点钱。
所以FPGA研制分为十一个过程，这十一个过程则是：
· 任务分析；
· 需求分析；
· 设计及验证环境实现；
· 功能验证；
· 综合及布局布线；
· 时序验证；
· 编程下载；
· 设计确认；
· 验收交付；
· 固化落焊；
· 运行维护。
版权声明：本文来源于51Testing会员投稿。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
