第三方维护审核不给出款怎么办 载人航天软件质量控制和软件测试
APP宣发
啄木鸟软件测试培训网：
载人航天的软件是高安全、高可靠性的软件，其需要严格的测试作为后盾，这与现在比较火爆的互联网软件测试还是有很大区别的。这里介绍一下航天软件质量控制和软件测试方法。
说起载人航天，经过神舟五、六、七、八和九号每次发射在各大媒体的报道后，大家可能都有些了解。比如载人航天工程的八大系统：航天员、空间应用、载人飞船、运载火箭、发射场、测控通信、着陆场和空间实验室。其中，载人飞船系统和空间实验室系统是由航天科技集团公司第五和第八研究院为主负责研制；运载火箭系统由航天科技集团公司第一研究院负责研制；空间应用系统由中国科学院有关研究所为主负责研制；航天员、发射场、测控通信及着陆场系统由相关研究单位负责研制建设；测控通信设备主要由电子科技集团公司有关厂所负责研制。
对于每个系统，又能分成多个分系统，再细分往下到设备、单机、单板…，层层分解到最下层，涉及到的软件是很多很多的。既有天上飞的，也有地面控制的，通信的…，小到几百行的引导程序，几千行的单板控制程序，大到百万行的数据汇接处理程序。
对于整个载人航天的大工程，载人航天工程有如下整体特点：
l涉及学科领域广；
l参与人员多；
l工程认识差异大；
l结构复杂；
l协同实时性要求高。
各系统的特点：
l工程任务不同；
l应用环境各异；
l工作模式多样；
l安全、可靠性要求高；
l系统间协同要求苛刻。
软件的特点：
l软件类型多；
l软件运行平台多；
l软件安全关键等级高；
l软件实时性和安全及可靠性高；
l软件数量多、规模大。
所以在质量管理上，也是要分类分级地针对不同的软件采用不同的管理制度。
7.2.1历史回顾
在介绍之前，我们先来回顾一下中国航天工程的历史。
载人航天工程以前代号是叫921工程，因为是1992年9月21日开始的。但是在整个载人航天工程里，真正把软件质量提出并且和硬件质量相等同的地位来看待，并不是一开始就重视的，这要追溯到1996年。
1996年，欧洲航空航天局首次发射阿丽亚娜五型火箭，正好我国921工程的一批领导们前往现场参观发射，目的是学习先进国家的航天技术。然后发生了本书第7.3.5节介绍的事故。1996年6月4日，阿利亚娜五型火箭首次发射升空，发射40秒后，在大约3700米高空，火箭脱离飞行轨道发生了爆炸，四亿美金变成一个巨大的烟花。
在不到一个月时间就迅速定位到了原因：软件复用时的数据溢出。在测量火箭水平速率的时候，把浮点转换成整形数。编写四型软件的时候，他们计算了这个速率不会超过16位有符号整形数，于是就用16位有符号整形数赋值了。可是五型火箭升级了，水平速率超过了这一数值，溢出的结果是变成负速度，然后就触发上面这个悲剧。
这个事故给我国921工程的领导们的触动是相当大的，眼睁睁的看着欧洲人花了四亿美金研制的火箭，就这么炸了。前车之覆、后车之鉴，我国921的火箭还没有发射。基于我国的经济水平，一次爆炸都经不起。阿丽亚娜这么一炸，国内马上对症下药，总后装备部921办公室要求在921工程中全面实施软件质量控制。
航天工程自身在软件工程上的经验也不太多，八十年代第一次和巴西合作中巴资源卫星项目的时候，在巴方的要求下才开始重视软件工程标准，在资源卫星这一个项目上实施了软件工程。后来断断续续也有一些项目管理的经验，但很多软件还是非常差的。由于的国际形势逼迫，又有阿丽亚娜这个事故在前面，加之总后装备部921办公室也发出了要求，没有人不敢不重视航空软件的产品质量。原航天工业总公司在1996年发布了《实施航天软件工程化管理要求》，实施”抓评测，促工程”的策略，建立了航天的软件评测体系：“一个中心，多个院级评测点，以及下面各所的评测点这样一个复杂的树状结构”。
神舟一号是1999年发射的。在神舟一号，直到要上交文档的时候，按照刚建立起来的软件工程化管理要求一查，《软件设计文档》、《软件测试报告》等各个单位倒是都准备上了，但是再仔细一看，就知道全是后来补上的。
“神舟”系列火箭一发接着一发地发，软件工程工作也一步接着一步地往下推。到现在，虽然也还是有一些文档是先做后补的，但基本上还是走上正轨了。
l2000年的时候，成立了航天领域的第一届软件专家组并作为常设机构，要求所有型号产品在出厂前必须开展软件专项评审。
l2001年，航天科技集团发文《航天型号实施软件工程的技术规定》（科质【2001】0077号），要求集团公司所有型号软件必须实施工程化工作管理。这就是现在航天软件工程非常重要的著名的77号文件。
l2005年，发布实施航天企业标准Q/QJA30-2005《航天型号软件工程化管理要求》2013年，这个标准进行改版。
一直到现在为止，只要从航天出身的专家们讲到软件工程，十有八九会在PPT里会提到阿丽亚娜五型火箭，基本上可以看出阿丽亚娜这个事故给航天软件质量控制留下了多么深刻的印记。
7.2.2具体操作
接下来，介绍一下具体航天软件领域是如何操作的。
载人航天推动了航天的软件工程化的进展，航天中的诸多型号（不仅仅是载人航天，还有各种弹、箭、星、船等）也反向促进了载人航天的质量技术各个标准的改进。
在质量管理方面，载人航天《软件研制工作管理规定》有这样的要求：
l软件列入工程产品配套表；
l软件按其关键程度分级管理；
l明确各级在软件研制过程中的职责；
l规定软件研制过程及各阶段要求；
l规定FPGA软件研制过程及各阶段要求；
l安全性与可靠性要求；
l软件安全保密性要求；
l验证与确认要求；
l第三方评测要求；
l外协与外购要求；
l软件在轨维护要求。
7.2.2.1软件列入工程产品配套表
承认软件是产品，就是提升了软件的地位。既然作为工程产品，那就要按产品来管理，要有相关的质量要求。
7.2.2.2根据安全关键性等级，软件产品分为ABCD四个等级。
这个直接影响到相关文档的要求和软件测试的要求。
“投入最大精力，作最重要的事”。载人航天工程那么大，众多软件又参差不齐。比如：火箭发射场的空调通风也是有软件控制的，这个软件和发射点火的控制软件级别能一样吗？
曾经听专家提过一句，大致意思是当时整个921工程里，最后在天上飞的软件，绝大多数是AB级的；地面运行的软件，也有小部分是AB级的。而且AB级代码虽然小规模的不少，大规模甚至巨大规模的也不是没有的。比如某个星上对接软件就号称百万行代码。最开始的时候只是模糊的分为AB级，CD级。因为当时对A级和B级的规定是一样的，都要做到覆盖率三个一百，也就是说，语句覆盖率，分支覆盖率，MC/DC覆盖率均达到百分之百，才可以提交给第三方进行软件测试。而C级和D级的没有这么多要求，不需要第三方软件测试，甚至不需要做单元测试。现在的新标准，把A级和B级在具体要求上区分得更仔细了，比如要求在A级上必须做集成测试。单元测试虽然A级B级都要求做MC/DC覆盖，高级语言必须做到目标码覆盖，但B级非嵌入式软件可以特批允许只做关键部分模块代码的目标码覆盖等。
7.2.2.3在软件研制中，各级各单位，有这么几个不同的职责角色
从横向来看，所有的单位无非以下三种类型：
l软件交办方，行话里称为总体单位，类似于甲方的概念。这个是相对而言的，相对于单板来说，整机就是总体。相对于整机来说，分系统就是总体。相对于整个载人航天，总装就是交办方。
l软件承制方，就是具体干活的单位，也就是乙方。不管单板整机分系统，总都有对应的承制方。
l软件第三方评测机构，不管哪个单位开发的产品，只要是AB级的软件，或者部分C级飞行在天上的软件，都被要求被第三方做评测，只有拿到第三方评测报告才准予通过。
换句话来说，除了不可达的代码，如说嵌入式代码里一些预置处理，为了保证发生事故后的软件还能回到起点的，正常逻辑不可达到的，航天里是AB级的软件要求是必须做到全覆盖的。没覆盖到的，要求给出说明原因，是不可达代码要求开发工程师去说明原因解释：为什么有不可达代码？如果是冗余没有用的代码就去掉；有用的比如像前面提及的就需要举个例子，进行解释。这个要求不止是航天，航空，铁路也是需要的。
安全关键级别最高的，如铁路上的，SIL-4级软件也是要求100%的目标码覆盖。这就是按照软件安全关键级别划分的区别。比如铁路通信软件控制系统是SIL-4级，要铁路订票系统高。也是要求分级的，其中的A级标准其实要求就跟航天的A级差不多，跟铁路的SIL-4也差不多，作单元测试的时候，DO-178B-A也是要求单元测试的语句、分支、MC/DC都要达到100%的。
接下来我们谈谈岗位职责。刚刚说到三种角色，交办方,承制方和第三方评测。对应的有：
l交办方负责系统设计分析，提交软件研制任务书，定制软件关键级别，提第三方评测任务书，审核承制方质量保证能力，组织软件验收和系统联试等。
l承制方负责软件开发、软件测试、产品保证和维护。
l第三方评测负责软件第三方评测，参与重要研制节点的质量控制，对被评测软件产品的质量负责，换句话来说，第三方评测给了通过的结论，就要承担质量连带风险。
921办公司负责审核各评测机构的资质——大致类似CNAS的认证，但是比CNAS的实验室认证要严格一些。对于像探月、921等这些大型号都各自有各自的认证第三方评测机构。通过总体认证之后的评测机构才能接下来做该型号下面的软件评测，软件与软件之间的衔接是系统联试的范畴了，第三方评测一般只做到配置项级别。
刚刚把横向的各角色说完，接着三大系统。纵向贯穿所有单位。
l型号指挥系统
型号总指挥对整个大系统的质量、进度、经费、安全保密和研制队伍实行全面管理和调度。一般的会安排一名副总指挥来负责整系统软件研制的调度管理。然后层层往下分解，到每个对应的承制方单位都有对口的调度人员。
l型号设计师系统
总设计师俗称总师，负责总体把握技术，一般的也要安排一名副总师来负责整系统软件的技术实施和管理。然后层层往下分解到对应的承制方单位，都有对口的设计师/主任设计师。
l型号质量管理系统
负责质量管理，软件问题报告，质量问题归零。航天的每个承制方单位都有自己的质量处，质量数据每年除了供本单位使用，还要分型号分内容汇总到集团公司质量部。
7.2.2.4软件研制过程
整个航天型号的研制，从五六十年代开始，比如从事导弹研制，纯硬件走的过程就是：先方案设计->可行分析->关键技术攻关->危险分析->确定最终要做出些什么目标，最后形成产品配套表，就转初样。
初样阶段是主要设计工作，基本要成型了。研制过程受控，技术受控，质量归零那就转正样。正样基本上不作太大的改动了。非军方型号这就是最终版，军方的话还要过定型实验最后一关。
既然软件也按产品要求，那么软件的研制流程也要跟着整个航天型号，把方案->初样->正样->定型（最后一个定型仅限军用）几个阶段全部流转一遍。
从软件测试工程师的角度上来看，目前压力最大的是软件初样转正样的转换阶段，因为这个阶段要求完成开发方的全部单元、集成、配置项和系统测试，完成第三方软件测试，完成质量归零。不过不是所有的软件都得这么流转一大圈。因为软件是可以复用的。
提到复用，大家有没有又想起最开始那个阿丽亚娜的故事？这个教训时刻提醒着中国航天人。所以目前中国航天里对复用是分了这么四类来严格要求的：
I类：沿用：不加修改即可再次使用，需要经过沿用可行性分析与审批，在系统需求分析与设计的时候即提出可沿用，做沿用可行性分析。沿用状态复核之后直接参与分系统联试（验收测试）。
II类：只修改装订参数：任务书可能重新出也可能不变，可执行代码不变，需要完成适用性分析、状态符合及参数修订、实施、回归测试等验证活动，在系统需求分析与设计时候可能需要重新出版任务书，做更改可行性分析和影响域分析，及对应的软件状态复核和影响域分析评审。确定只更改参数即可。
然后根据影响域分析做软件回归测试。再做分系统联试等后续工作。应有的第三方评测也要同步开展。
III类：少量的修改；任务书必须要重新出，需求设计等侧重更改，技术状态控制等，这个对于研发一个新功能对软件测试工程师来说区别就不太大了，逐级需求/概要设计/详细设计更改评审，回归测试和第三方软件测试都要求做。部分单位甚至在总体上最基础的要求上提升了更严格的要求，只要改动了一点点，全部代码重测。
IV类：全新研制，完成全部软件过程流程。
7.2.2.5 FPGA
可能很多人听到这里就奇怪了，这名词不是书硬件上的吗？但是毕竟可编程逻辑语言它也是代码，近些年来航天航空和各军兵种都陆续把FPGA也归入到了软件研制来一起管理
7.2.3归零问题
下面我们来讨论航天人最头疼的质量归零问题。但是不是所有软件测出的问题都算作需要归零处理的。
首先先说个质量问题分类：
l一般质量问题；
l归零质量问题。
由质量系统根据严重程度来判定到底是一般质量问题还是归零质量问题。
比如，软件测试里发现开发工程师编码的时候由于手误，把“if(a==b)”敲成了“if(a=b)”。一般情况下这就是个一般质量问题，报了问题单，设计人员更改了，一切可以了。但是如果这个问题频繁发生，那就不能算一般质量问题了，需要归零。具体两者的分界和把握，有点像是ISO 9000体系的一般不符合和严重不符合/体系不符合的区别，就看具体质量人员的分寸了。一次两次把“==”敲成“=”,没关系；但是频繁出现同样的问题那就要做检查了，是不是开发工程师的技术不过关。
归零是航天里对性质比较严重的问题的处理方式。字面意思，通过处理，最终要让它归为零，再也不出现。假如出现了一个需要归零的质量问题了。那么下一步，这个问题是技术归零还是管理归零？
7.2.3.1技术归零
我们先来看看相对比较轻松的技术归零。是这样要求的：
为了彻底解决问题，避免重复发生，必须按”定位准确、机理清楚、故障复现、措施有效、举一反三”五条标准逐项落实，并最后形成文件也就是要求写归零报告。
l定位准确：是根据实际情况和需要，对在航天产品研制的过程中发生的所有软件质量问题，要准确确定发生问题的部位，即定位到软件基本单元。
l机理清楚：是指质量问题一旦定位后，要通过地面试验即软件单元测试、配置项测试、系统联试或故障注入测试等和理论分析等各种手段，弄清问题发生的根本原因。
l故障复现：是指在定位准确和机理清楚后，通过地面模拟试验或其它试验方法如单独的软件测试试验；或与硬件系统的联试，但能与硬件系统确切隔离来复现问题发生的现象，从而验证定位的准确性和机理分析的正确性。
l措施有效：是指在定位准确和机理清楚的基础上，制订出有针对性的、具体可行的纠正措施、实施计划及回归测试计划。对影响任务成败的重大问题，其措施要经过评审，并返回所属系统，进行系统级的试验验证。
l举一反三：是把发生的质量问题的信息反馈给本单位、本系统、本型号（由本单位质量部门负责）和其它单位、其它系统、其它型号（由上一级质量部门负责），从而防止同类事件的再发生。
发现了一个问题，必须得定位清楚到底是什么原因，哪里造成的。
曾经有人问，假如软件测试过程中发现了一个不可复现的问题怎么办？航天软件测试是不允许出现“不可复现”的问题。只要发生过问题，刨根问底也必须找出来。因为只有找准了原因（或者说只要找准了原因），这个问题才可能按要求复现出来。复现不出来，说明找的原因还不对，还需要继续找。
最终找到这个原因，确实按这个原因来执行每次都能复现，那就是问题。然后再制定纠正措施（纠正措施绝大多数都要过评审，一般是问题发生单位与其总体单位参审，严重的可能总师系统也要来人），纠正完了调试，确保问题不再复现。再根据纠正措施的影响域过回归测试等一系列流程。
最后，还有个举一反三。那就是通告所有相关单位，本型号所有相类似的设计统统按此问题修改，修改范围非常大。可能其他类似设计并没有发生问题，但是有隐患就要统统排除，完成以上全部操作，最后写成文字性的归零报告，总体上质量处都要留存的。
可是，即使这样，为什么还要说，技术归零还是相对比较轻松的呢？
7.2.3.2管理归零
我们来看看质量问题如果编为管理归零，有哪些要求。为了彻底解决问题，避免重复发生，必须按”过程清楚、责任明确、措施落实、严肃处理、完善规章”五条标准逐项落实，并形成文件。
l过程清楚：是查明质量问题发生、发展的全过程，从有关的每一个环节中，分析问题产生的原因，查找软件管理上的薄弱环节或漏洞。这是管理归零工作的基础，要做到实事求是、过程事实准确。
l责任明确：是在过程清楚的基础上，分清造成软件质量问题各环节和有关部门人员应承担的责任，并从主观和客观、直接和间接方面区别责任的主次、大小。这是管理归零工作的依据，要做到具体明确、主次分明。
l措施落实：是要针对出现的软件管理问题，迅速制定并落实相应有效的具体纠正和预防措施，堵塞管理漏洞，举一反三，杜绝类似问题的重复发生。这是管理归零的基本内容，要做到措施具体、有效。
l严肃处理：首先是在思想上、态度上要严肃、认真地抓紧对质量问题的处理和改进管理工作，避免走形式，敷衍了事；其次是对由于人为责任问题、重复性故障以及明显因有章不循、违章操作等原因造成软件质量问题的有关责任人员，要根据责任和影响的大小，按有关规定给予一定的行政处分或经济处罚。这是做好归零工作的重要管理手段和有力保障。
l完善规章：是在查找问题、分析原因、落实措施、严肃处理的基础上，针对管理漏洞，修订和健全规章制度，落实到有关岗位和管理工作的有关环节上，约束和规范管理行为和软件开发活动，杜绝质量问题的重复发生，这是改进和提高管理水平的根本途径。
过程清楚，措施落实，完善规章，这些都是亡羊补牢性质的。但责任明确，严肃处理这两条是非常严厉的。
跟技术归零不同。技术问题，交代清楚问题成因，技术人员就算是过去了。毕竟技术上总有很多不可控的风险。
管理归零的话，那就要处分几个人的。该撤的撤，该罚的罚。一旦出了管理归零，基本上就有一批人被开除。
如何来判断合适采用技术归零还是管理归零是由质量人员来决定。
l问题一旦出现，纯技术的可以处理一般的来说采用技术归零，技术归零可以单归零。
l管理归零基本上都是双归零，也就是说，管理归零必然伴随着技术归零。
所以在航天领域质量人员的权利是非常大的。
7.2.4软件测试技术要求
后面的技术要求，摘自载人航天工[]程软件工程化技术标准的目录：
lCMS-RW-01软件研制过程；
lCMS-RW-02软件文档编制；
lCMS-RW-03软件评审细则；
lCMS-RW-04软件测试细则；
lCMS-RW-05软件验收、移交和保障细则；
lCMS-RW-06软件配置管理细则；
lCMS-RW-07软件设计和编程指南；
lCMS-RW-08软件研制技术流程；
lCMS-RW-09软件安全性细则；
lCMS-RW-10软件安全保密性细则；
lCMS-RW-11外购软件选用细则；
lCMS-RW-12 FPGA软件研制技术要求。
这是一本500多页的白皮书，其实本质上的东西跟一般的软件工程教材差别不太大。
总体来说，每项标准要求都是找得到原始来源的（比如编程指南，C语言基本脱胎于MISRA C之类的，参见附录C）。
软件测试这边，921办公室首先把所有的软件分成两大类：处理器软件（也就是我们常规意义上的软件）和FPGA软件。处理器软件，要求按软件测试级别来说，单元测试、集成测试、配置项测试、系统集成四大级别都要做。所有的软件工程做起来其实都大同小异，理念差不多，麻烦的是那些小异的地方，编写这类文档是非常费力的。航天软件，包括军方的，都是要求把一个一个的软件单元函数集成起来，成为的那个能独立运行具有自有功能的软件，就是软件配置项。可以把它认为是单个软件，然后软件跟硬件去作软硬件集成测试，或者有互操作的各软件之间的系统集成测试。按软件测试方法来说：
l静态测试：包括文档审查，代码走查，代码审查，代码规则检查，静态分析等。
l动态测试：包括功能测试、性能测试、外部接口软件测试、余量软件测试、边界软件测试等，必要时还有人机界面软件测试、强度软件测试、可靠性测试、安全性测试、恢复性软件测试、安装性测试、互操作性软件测试和敏感性软件测试等。
静态测试很多时候都要用到工具，代码规则检查和静态分析基本全用到工具，审查走查是人工。其中对逻辑测试的要求也就是覆盖率要求，前面提了，三个百分之百。高级语言的AB级别的软件还要加上目标码覆盖百分之百。
需要做何种软件测试，总体在书写开发任务书的时候也要给第三方软件测试单位确定测试任务书，评审软件测试需求的时候就要确定下来。
说到软件研制过程，像ISO 9000那样规定了不同的过程控制，每个过程都有对应的输入输出产品。软件研制分为九个过程分别是：
l系统分析与设计；
l分系统分析与设计；
l软件需求；
l软件设计；
l软件实现；
l软件测试；
l验收交付；
l试验验证；
l运行维护。
系统设计是把系统功能划分成不同配置项。这里的系统可能是软硬件结合的一个单板，甚至可能是单机设备甚至更高层。
对于FPGA研制过程管理。这是最近几年才新定的。作为质量管理的过程，分得越细，管理起来肯定更严格，但对应的质量管理成本也越高。
我们国家制定的这些标准参考了先进国家的经验，现在可以看查到并且能看的无非就是NASA跟ESA。NASA对FPGA研制分的六大过程。ESA分得细一些，有十三大过程。总后装备部921办公室决定向ESA学习：质量第一位，哪怕前期多投点钱。
所以FPGA研制分为十一个过程，这十一个过程则是：
l任务分析；
l需求分析；
l设计及验证环境实现；
l功能验证；
l综合及布局布线；
l时序验证；
l编程下载；
l设计确认；
l验收交付；
l固化落焊；
l运行维护。
顾翔凡言：
想做软件测试，最好先去做两到五年开发
啄木鸟软件测试培训中心，主打五门课：
初级：
1，你也想成为软件测试工程师吗～软件测试基础教程
中级：
2，软件测试工程师必须掌握的技能～软件测试设计方法实战。
高级：
3，让你的程序跑得更快～软件性能测试
4，让你找出更多的bug～探索式软件测试
5，让用户迷上你的产品～用户体验式测试
