无用代码.docx
《无用代码.docx》由会员分享，可在线阅读，更多相关《无用代码.docx（12页珍藏版）》请在冰点文库上搜索。
无用代码
无用代码
——DO-178B/ED-12B学习笔记之一
1.无用代码的定义
DO-178B/ED-12B对无用代码（Deadcode）的定义是：
Executableobjectcode（ordata）which,asaresultofadesignerrorcannotbeexecuted（code）orused（data）inaoperationalconfigurationofthetargetcomputerenvironmentandisnottraceabletoasystemorsoftwarerequirement.Anexceptionisembeddedidentifiers.
试译如下：
因设计错误而产生的，在目标机环境的运行配置中不能执行的（代码）或不能使用的（数据），并且不能追踪到一个系统或软件需求的可执行的目标代码（或数据）。
嵌入的标识符号除外。
为了准确把握无用代码的定义，还需了解DO-178B/ED-12B对目标码和源码的定义。
DO-178B/ED-12B对目标码（ObjectCode）的定义是：
Alow-levelrepresentationofthecomputerprogramnotusuallyinaformdirectlyusablebythetargetcomputerbutinaformwhichincludesrelocationinformationinadditiontotheprocessorinstructioninformation.
试译如下：
计算机程序的一种低级表示，其格式通常不是目标（target）计算机直接可用的，而是包含了计算机指令信息以及重定位信息。
DO-178B/ED-12B对源码（Sourcecode）的定义是：
Codewritteninsourcelanguages,suchasassemblylanguageand/orhighlevellanguage,inamachine-readableformforinputtoanassembleroracompiler.
试译如下：
用源语言（如汇编语言或高级语言）编写的代码，其格式是机器可读的，以作为汇编程序或编译程序的输入。
DO-178B/ED-12B没有定义可执行的目标码（executableobjectcode）。
那么按照上述目标码的定义和常识，可执行的目标码应是目标码经过连接程序（linker）处理后生成的目标（target）计算机直接可用的代码。
由此可见：
——无用代码是针对可执行的目标码而不是源码定义的；
——无用代码包括代码和数据；
——认定为无用代码有两个条件，一是执行不到，即程序的控制流达不到该代码或数据流达不到该数据；二是追踪不到，即从该代码或数据不能追踪到任何一条系统或软件需求。
针对可执行的目标码来定义无用代码，这可能因为最终装机的是可执行的目标码，而源码与目标码不是一一对应的。
然而，为了消除可执行的目标码中的无用代码，我们首先要消除源码中的无用代码。
源码中有些语句，如类型定义，不会直接产生目标码，因此也不会变成无用代码。
但是，从软件验证角度有必要分析这些没有使用的语句，可能从中发现其它问题。
从代码追踪到系统或软件需求有时是很困难的，尤其是当需求描述不够详细时。
DO-178B/ED-12B的软件需求包括高级需求和低级需求，还有派生需求（derivedrequirements）。
有些代码往往只能追踪到派生需求。
无用代码的两个条件是与的关系还是或的关系？
从文字上看好像是与的关系。
但是，如果要两个条件都成立，那么能追踪但不能执行的就不算无用代码？
2.无用代码的识别
我们在DO-178B/ED-12B和DO-248B/ED-94B中只找到了以下两段与无用代码的识别有关联的论述。
DO-178B/ED-12B在6.4.4.3条的开头有这样一句，“Structuralcoverageanalysismayrevealcodestructurethatwasnotexercisedduringtesting.”。
DO-248B/ED-94B在FAQ#74中谈论MC/DC时有这样一句，“Additionally,anydeadcodeorunreachablepathsinthecodemaybeidentified.”。
由此可见：
——DO-178B/ED-12B和DO-248B/ED-94B都没有明确规定识别的方法或途径
——结构覆盖分析可以（may）但不是必定揭示无用代码
为了理解无用代码识别与结构覆盖分析的关系，需要理解DO-178B/ED-12B对结构覆盖分析的论述。
DO-178B/ED-12B规定了三种结构覆盖，即语句覆盖、判定覆盖、MC/DC。
DO-178B/ED-12B的6.4.4.2.b条的第一句：
ThestructuralcoverageanalysismaybeperformedontheSourceCode,unlessthesoftwarelevelisAandthecompilergeneratesobjectcodethatisnotdirectlytraceabletoSourceCodestatements.Then,additionalverificationshouldbeperformedontheobjectcodetoestablishthecorrectnessofsuchgeneratedcodesequences.（试译如下：
一般情况下，可以只对源代码进行结构覆盖分析。
但是，当软件等级是A级，以及编译器产生了不能直接追踪到源代码语句的目标码，还应对目标码进行额外验证以确定所产生的代码序列的正确性。
）
这三种结构覆盖都是面向可执行语句的，可以揭示未执行的代码，但不一定能揭示未使用的数据。
因此还需要使用面向数据的覆盖测试技术，如数据覆盖测试[3][4]等，来识别未使用的数据。
DO-178B/ED-12B的6.4.2.1条论述了NormalRangeTestCases（正常范围测试用例），6.4.2.2条论述了RobustnessTestCases（健壮性测试用例）。
这两类测试用例也可能揭示未使用的数据。
以下用一个例子说明结构覆盖不足以揭示未使用的数据。
设有如下C函数：
intconvert_1（inti）
{
intr;
if（i==1）
r=10;
elseif（i==2）
r=20;
elseif（i==3）
r=30;
else
r=0;
returnr;
}
设输入参数i分别为1、2、3、4，用这样4个测试用例测试函数convert_1，可以达到语句覆盖，并测试了其中的3个转换因子10、20、30。
如果把代码改写为：
intconvert_2（inti）
{
staticintfactor_array[3]={10,20,30};
intr;
if（i>=1&&i<=3）
r=factor_array[i-1];
else
r=0;
returnr;
}
这样用2个测试用例就可以达到语句覆盖，但不能揭示数组factor_array的三个分量是否都被使用了。
如果是以下形式的代码：
typedefstruct
{
intfactor_1;
intfactor_2;
intfactor_3;
}factor_t;
factor_tfactor_record={10,20,30};
intconvert_3（inti）
{
if（i==1）returnfactor_record.factor_1;
elsereturnfactor_record.factor_2;
}
某些静态数据流分析工具不能揭示factor_record.factor_3未被使用的问题。
3.无用代码的处理
DO-178B/ED-12B的6.4.4.3.c条规定：
Deadcode:
Thecodeshouldberemovedandananalysisperformedtoassesstheeffectandtheneedforreverification.
试译如下：
无用代码：
应消除这种代码，并进行分析以评定消除后的影响以及是否需要重新验证。
DO-248B/ED-94B的FAQ#28强调和诠释了上述要求：
ItisimportanttorealizethatDO-178B/ED-12Bnotonlystatesthatdeadcode“shouldberemoved”:
Section6.4.4.3ccontinueswiththestatementthat"ananalysis（shouldbe）performedtoassesstheeffect（ofremovingthedeadcode）andtheneedforreverification."
由此可见，无用代码处理包括两件事，一是消除，二是分析，必要时还要做第三件事——重新验证。
参考文献
[1]DO-178B/ED-12B,SoftwareConsiderationsinAirborneSystemsandEquipmentCertification,December1,1992
[2]DO-248B/ED-94B，FinalReportforClarificationofDO-178B,October12,2001
[3]古乐、史九林，软件测试技术概论，清华大学出版社，2004
[4]ElfriedeDustin，JeffRashka,JohnPaul,AutomatedSoftwareTesting,1999
本文来自CSDN博客，转载请标明出处：
软件等级
——DO-178B/ED-12B学习笔记之六
1.软件等级的定义
DO-178B/ED-12B的第2.2.2条定义了软件等级：
a.LevelA:
Softwarewhoseanomalousbehavior,asshownbythesystemsafety assessmentprocess,wouldcauseorcontributetoafailureofsystemfunction resultinginacatastrophicfailureconditionfortheaircraft.
b.LevelB:
Softwarewhoseanomalousbehavior,asshownbythesystemsafety assessmentprocess,wouldcauseorcontributetoafailureofsystemfunction resultinginahazardous/severe-majorfailureconditionfortheaircraft.
c.LevelC:
Softwarewhoseanomalousbehavior,asshownbythesystemsafety assessmentprocess,wouldcauseorcontributetoafailureofsystemfunction resultinginamajorfailureconditionfortheaircraft.
d.LevelD:
Softwarewhoseanomalousbehavior,asshownbythesystemsafety assessmentprocess,wouldcauseorcontributetoafailureofsystemfunction resultinginaminorfailureconditionfortheaircraft.
e.LevelE:
Softwarewhoseanomalousbehavior,asshownbythesystemsafety assessmentprocess,wouldcauseorcontributetoafailureofsystemfunction withnoeffectonaircraftoperationalcapabilityorpilotworkload.Oncesoftware hasbeenconfirmedaslevelEbythecertificationauthority,nofurther guidelinesofthisdocumentapply.
网上流传的中译文把它翻译为：
a.A级可能引起或导致系统功能失效进而引起航空器灾难性失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。
b.B级可能引起或导致系统功能失效进而引起航空器危险的/严重的失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。
c.C级可能引起或导致系统功能失效进而引起航空器较重失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。
d.D级可能引起或导致系统功能失效进而引起航空器较轻失效状态的异常状态的软件，这种异常状态可通过系统安全性评估过程来表明。
e.E级可能引起或导致系统功能失效的异常状态的软件。
这种异常状态可通过系统安全性评估过程来表明。
它不会影响航空器的工作性能或驾驶员工作量。
一旦软件由合格审定机构定位E级，本文件就不再提供进一步的指南。
上述翻译有两个问题。
以A级定义为例，第一句简化定语后变成“异常状态的软件”。
如果加上主语则变成“A级是……的异常状态的软件”。
笔者理解原文的意思是，如果A级软件出现异常状态，那么这种异常状态可能引起或导致系统功能失效进而引起航空器灾难性失效状态。
显然，A级软件不是必然出现异常状态。
第二句译文使人以为系统安全性评估过程表明A级软件存在异常状态。
但根据2.2.2条的第一句：
Softwarelevelisbaseduponthecontributionofsoftwaretopotentialfailureconditions asdeterminedbythesystemsafetyassessmentprocess.
可知系统安全性评估过程不是表明软件是否存在异常状态，而是表明软件的异常状态将引起或促成什么样的航空器失效状态。
还要注意原文中的“causeorcontribute”，这可理解为软件异常状态可能是引起航空器失效状态的主要原因或部分原因。
试译A级定义的原文如下：
A级如系统安全性评估过程所表明，该级软件的异常状态可能造成或促成系统功能失效从而酿成航空器灾难性失效状态。
2.航空器失效状态与软件等级
以下是资料[1]中对航空器失效状态的一种解释，有助于我们理解软件异常产生的后果。
DO-178B
LevelE
LevelD
LevelC
LevelB
LevelA
MILSTD882
NA
CategoryIV
CategoryIII
CategoryII
CategoryI
ClassificationOfFailure
None
Minor
Major
Hazardous
Catastrophic
EffectonAircraft
Noeffectonoperationalcapabilitiesorsafetymargin
Slightreductioninoperationalcapabilitiesorsafetymargin
Significantreductioninoperationalcapabilitiesorsafetymargin
Largereductioninoperationalcapabilitiesorsafetymargin
Safeflightandlandingprevented,usuallywithlossofaircraft
EffectonPassengers
Inconvenience
Physicaldiscomfort
Physicaldistress,possiblyincludinginjuries
Seriousorfatalinjurytoasmallnumberofoccupants
Multiplefatalities
EffectonFlightCrew
None
Slightincreaseinworkloadoruseofemergencyprocedures
Physicaldiscomfortorasignificantincreaseinworkload
Physicaldistressorexcessiveworkloadimpairingabilitytoperformtasks
Fatalitiesorincapacitation
InterpretedQualitativeProbability
NA
Probable
Remote
ExtremelyRemote
ExtremelyImprobable
InterpretedQuantitativeProbability
NA
10-3perflighthour
10-5perflighthour
10-7perflighthour
10-9perflighthour
下图说明航空器失效状态与出现概率的关系。
下图说明航空器失效状态与软件等级的关系。
3.软件等级的确定
DO-178B/ED-12B的第2.2.３条说明了软件等级的确定：
Initially,thesystemsafetyassessmentprocessdeterminesthesoftwarelevel（s） appropriatetothesoftwarecomponentsofaparticularsystemwithoutregardto systemdesign.
网上的中译文是：
系统安全性评估过程首先要确定与特定系统中的软件有关的软件等级，而不考虑系统设计。
原文中softwarelevel后面有（s），这表示可能有多个软件等级。
这些软件等级是针对系统中的一个或多个软件部件所确定的。
试译原文如下：
系统安全性评估过程最初确定与特定系统中的软件部件相适应的一个或多个软件等级，而不考虑系统设计。
法译文是：
Initialement,l'analysedesécuritédusystèmedéterminele（s）niveau（x）logiciel（s）d'un systèmeparticuliersanstenircomptedelaconceptiondusystème.
法译文中没有翻译softwarecomponents，不知是遗漏还是故意省略。
法译文中也没有翻译appropriate。
按法译文，此句是：
系统安全性评估过程最初确定特定系统的一个或多个软件等级，而不考虑系统设计。
参考资料
[1] AlanC.Tribble,StevenP.Miller,andDavidL.Lempia,SofwtareSafetyAnalysisofsFlightGuidanceSystem.
ARP4754是系统总体的安全性指导原则，ARP4761是推荐的实施方法。
而DO-178B是在4754之下的关于分配给软件的更加具体的安全性指导原则。
升级会员 