CN113204484B - 一种面向软件生命周期的装备软件测试性设计方法 - Google Patents

一种面向软件生命周期的装备软件测试性设计方法 Download PDF

Info

Publication number
CN113204484B
CN113204484B CN202110484004.1A CN202110484004A CN113204484B CN 113204484 B CN113204484 B CN 113204484B CN 202110484004 A CN202110484004 A CN 202110484004A CN 113204484 B CN113204484 B CN 113204484B
Authority
CN
China
Prior art keywords
testability
software
design
test
stage
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110484004.1A
Other languages
English (en)
Other versions
CN113204484A (zh
Inventor
孟小娟
高玉峰
高金梁
陈漠
闫陈静
马亮
薛琼
牟迪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Aerospace Academy Of Systems Science And Engineering
Original Assignee
China Aerospace Academy Of Systems Science And Engineering
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Aerospace Academy Of Systems Science And Engineering filed Critical China Aerospace Academy Of Systems Science And Engineering
Priority to CN202110484004.1A priority Critical patent/CN113204484B/zh
Publication of CN113204484A publication Critical patent/CN113204484A/zh
Application granted granted Critical
Publication of CN113204484B publication Critical patent/CN113204484B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3676—Test management for coverage analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/24—Classification techniques
    • G06F18/241—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Evolutionary Biology (AREA)
  • Evolutionary Computation (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明提供一种面向软件生命周期的装备软件测试性设计方法，属于软件测试性研究技术领域。该方法步骤包括：首先根据软件生命周期各个阶段的研制任务以及软件开发设计的实际需求，制定软件测试性设计准则的分类方案；然后按照分类方案，考虑软件测试性的影响因素，设计出装备软件测试性通用设计准则；结合层次分析法，构建软件测试性度量框架；采用模糊综合评价方法度量应用设计准则后的软件测试性；本发明可以提升软件的测试效率和有效性，使软件开发活动和过程更加规范化、程序化和标准化，确保软件质量最终满足要求。

Description

一种面向软件生命周期的装备软件测试性设计方法
技术领域
本发明属于软件测试性研究技术领域，特别涉及面向软件生命周期的装备软件测试性设计方法，面向软件生命周期，制定软件测试性设计准则的分类方案，并设计出装备软件测试性通用设计准则。
背景技术
计算机技术的发展带来各行各业的变革，原来机械式的武器装备逐渐向电子化、智能化发展。随着信息化要求和程度不断的提高，软件逐渐代替了许多原来由硬件实现的功能，使得软件所占的比重越来越大，所起到的作用和地位也变得更加重要。然而，由于软件存在质量问题，经常引发事故，导致人员伤亡以及产生巨大的经济损失。因此，高质量的软件是装备系统按照规定要求完成任务功能、执行作战和保障任务的重要影响因素，同时也是保障人员安全、减少经济损失的重要影响因素。
测试性是软件质量特性的重要特性之一，是一种设计特性，是软件内在的一种固有属性。软件测试性可以确定软件产品的状态，使软件变得易于测试和暴露缺陷，能够有效改善软件测试的质量和效率，达到提高软件质量的目的，并且在软件研制阶段越早考虑软件的测试性，越能发挥其重要的效能。虽然在研制阶段会增加一些成本，但是从整个软件生命周期来看还是降低了成本的。然而，目前还缺少面向软件生命周期的装备软件测试性设计方法。
发明内容
本发明解决的技术问题是：针对现有技术的不足，本发明提供一种面向软件生命周期的装备软件测试性设计方法，提出了面向软件生命周期的装备软件测试性的通用设计准则，解决现有装备软件没有面向软件生命周期的通用测试性设计准则，已有的准则只针对某一点或某一阶段，规范不全面，且实操性不强等技术问题。
本发明的上述目的通过以下方案实现：
一种面向软件生命周期的装备软件测试性设计方法，包括以下步骤：
(1)明确软件生命周期每个阶段的任务和要求；
(2)根据软件生命周期各阶段的任务和要求，制定软件测试性设计准则的分类方案；
(3)按照分类方案，面向软件生命周期，考虑软件测试性的影响因素，设计装备软件测试性通用设计准则；
(4)结合层次分析法，构建软件测试性度量框架；
(5)采用模糊综合评价方法度量应用设计准则后的软件测试性。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(1)中，软件生命周期包括系统分析、需求分析、设计、编码、测试验证和运行维护六个阶段，每个阶段的任务和要求包括：
(1.1)系统分析阶段，分析用户需要，明确软件开发的目的和要达到的目标，尽可能地确定软件的功能和性能指标要求，从顶层策划的角度给出软件开发要求。
(1.2)需求分析阶段，确定软件的功能和性能要求，明确软件开发的运行环境，策划软件的开发计划和软件测试工作计划。
(1.3)设计阶段，根据需求规格说明对软件的体系结构、功能模块和接口进行设计，制定初步的软件集成测试计划。给出各功能模块接口的数据结构，并描述功能模块的过程，给出功能模块的算法和数据结构等内部细节，为软件编码提供依据。
(1.4)编码阶段，依据软件设计说明进行单元程序编码，开展软件单元的静态分析和单元测试，验证软件单元的实现与软件设计说明的一致性，并将经过单元测试的软件模块进行逐步集成和调试，实现软件系统的集成。
(1.5)测试验证阶段，在软件完成单元测试、满足质量要求并纳入软件配置管理后，根据集成测试计划，对软件进行集成测试。完成集成测试后，针对软件的全部功能和性能要求进行确认测试。之后将进行非常重要的一项工作就是系统联试，实现软件与大系统的对接。
(1.6)运行维护阶段，主要涉及到软件安装、升级、排故等工作。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(2)中，根据软件生命周期各阶段的任务和要求，软件测试性设计准则的分类方案包括：
(2.1)系统分析阶段，基于用户需求，侧重软件开发要求，将设计准则分类为系统级测试性要求类，进一步，可确定为测试性要求子类。
(2.2)需求分析阶段，该阶段的任务是明确软件的功能、性能和接口，输出需求规格说明文档。由此，将设计准则划分为功能类、性能类、接口类和文档类。进一步，功能类分为输入测试性、输出测试性、查错测试性子类；性能类分为容量(时间、存储、吞吐量等)测试性、精度(时间精度、数据精度、测试精度)测试性子类；接口类分为外部接口(与硬件的接口)测试性、内部接口(模块间的接口)测试性、数据测试性、通讯测试性子类；文档类分为标准符合性测试性、逻辑测试性、内容测试性子类。
(2.3)设计阶段，该阶段的目标是设计软件的体系结构、功能模块和接口，关注数据结构和算法等具体设计，输出设计说明文档。基于此，将设计准则划分为体系结构类、接口类、模块设计类、文档类。进一步，体系结构类分为体系结构测试性子类；接口类分为输入测试性、输出测试性、数据测试性、通信测试性子类；模块设计类分为单元逻辑测试性、中断测试性、数据接口测试性、自检测设计测试性、复杂性控制测试性子类；文档类分为标准符合性测试性、逻辑测试性、内容测试性子类。
(2.4)编码阶段，该阶段是实现阶段，将设计准则划分为软件源代码类一大类，进一步，分为数据测试性、逻辑测试性、接口测试性、中断测试性、注释测试性、复杂性控制测试性子类。
(2.5)测试验证阶段，使测试效率更高，测试更充分，关注测试方法的设计，输出测试相关文档。由此，将设计准则划分为文档类、测试方法类。进一步，文档类分为标准符合性测试性、逻辑测试性、内容测试性子类；测试方法类分为内建式测试的测试性子类。
(2.6)运行维护阶段，该阶段的任务主要是软件安装、升级、排故等。考虑到任务的操作性，将设计准则划分为修复升级类、功能升级类、故障排除类。进一步，修复升级类分为缺陷修复测试性子类；功能升级类分为功能扩展测试性子类；故障排除类分为硬件排故测试性、软件排故测试性子类。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(3)中，根据制定的分类方案，面向软件生命周期，考虑软件测试性的影响因素，每个阶段的测试性设计准则包括：
(3.1)系统分析阶段：
(3.1.a)需求分析方面，对已确定的需求提出明确、完整、详细的测试性要求，如：为达到良好的测试性设计，逐一列出需满足的标准、规范等，并明确具体的设计要求；
(3.1.b)需求分析方面，对未明确的需求，或在后续工作中可能出现的新增需求，除按(3.1.a)已列出的标准、规范和设计要求外，新增的标准、规范和设计要求需相应增加；
(3.1.c)使用环境方面，明确软件运行的系统环境的要求；
(3.1.d)使用环境方面，明确与硬件环境的接口，便于观察软件测试时所产生的中间数据和不能直接观测到的输出数据；
(3.1.e)软件文档方面，要求种类齐全、文实一致、文文相符，无二义性；
(3.1.f)软件文档方面，检查、分析和评审各阶段编制的必要文档，并实行配置管理。
(3.2)需求分析阶段：
(3.2.a)功能类：
(3.2.a.1)输入测试性，明确输入信号的来源、接收方式和信号发生的最短时间间隔；
(3.2.a.2)输入测试性，结合系统需求和硬件设计，明确重要输入信号的检测监控需求，以及检测监控结果提示的需求；
(3.2.a.3)输出测试性，明确输出信号的发送方法和发送对象，以及发送时间间隔；
(3.2.a.4)输出测试性，结合系统需求和硬件设计，明确重要输出信号的检测监控需求，以及检测监控结果提示的需求；
(3.2.a.5)输出测试性，软件文件输出方面，尽量采用标准、通用的格式输出，如xml、txt等格式；
(3.2.a.6)查错测试性，检测点设置方面，对重要的接口信息状态设置检测点；
(3.2.a.7)查错测试性，检测点设置方面，对要求控制(包括自动控制)过程或设备的状态和控制结果设置检测点；
(3.2.a.8)查错测试性，检测点设置方面，对总线通讯状态设置检测点；
(3.2.a.9)查错测试性，检测结果方面，对故障状态(故障类型、源、时间等)进行上报和记录，并给出检测报告；
(3.2.a.10)查错测试性，检测结果方面，对自测试、自诊断结果给出结果报告。
(3.2.b)性能类：
(3.2.b.1)容量测试性，余量方面，确定有关软件功能的存储量，满足系统规定的余量要求，一般要求应留有不少于20％的余量；
(3.2.b.2)容量测试性，余量方面，确定软件处理时间要求，满足系统规定的余量要求，一般要求应留有不少于20％的余量；
(3.2.b.3)容量测试性，余量方面，结合具体的被控对象，确定软件工作的时序安排，确保软件的工作时序之间留有足够的余量，以满足系统规定和使用的要求,一般要求应留有不少于20％的余量；
(3.2.b.4)容量测试性，确定输入输出通道的吞吐能力，满足系统规定的要求；
(3.2.b.5)精度测试性，确定系统本身的时间精度、数据精度；
(3.2.b.6)精度测试性，确定软件测试要求的时间、数据精度。
(3.2.c)接口类：
(3.2.c.1)外部接口测试性，明确与所设计软件的外部交联系统；
(3.2.c.2)外部接口测试性，明确外部数据传输信息的格式和内容；
(3.2.c.3)外部接口测试性，明确外部接口的来源、类型、范围、单位、目的地等内容；
(3.2.c.4)内部接口测试性，明确内部数据传输信息的格式和内容；
(3.2.c.5)内部接口测试性，明确内部接口的类型、范围、单位等内容；
(3.2.c.6)数据测试性，使软件的满刻度和零表示都与任何数字到模拟、模拟到数字、数字到同步、和/或同步到数字转换器完全兼容；
(3.2.c.7)数据测试性，明确数据正确性和完整性校验的方式、方法；
(3.2.c.8)数据测试性，明确数据的接收方式和信息处理方法；
(3.2.c.9)数据测试性，明确数据传输的封装方式、方法或传输协议；
(3.2.c.10)数据测试性，明确数据传输率、周期或非周期、传输间隔、优先级；
(3.2.c.11)通讯测试性，协议方面，采用确定的方式实现协议；
(3.2.c.12)通讯测试性，协议方面，使用的通讯协议要一致、完整；
(3.2.c.13)通讯测试性，协议方面，采用自同步或自稳定协议。
(3.2.d)需求文档类：
(3.2.d.1)标准符合性方面，文档的格式和内容应符合在系统分析阶段所规定的标准、规范；
(3.2.d.2)文档逻辑方面，结构清晰唯一，内容前后逻辑关系清晰、一致；
(3.2.d.3)文档内容方面，合理划分软件需求的功能点，使每个功能点能独立完成某一功能，且不互相冲突，前后描述一致；
(3.2.d.4)文档内容方面，非功能需求(包括性能、余量、安全性等需求)设置合理，易于测试，满足系统要求，且不互相冲突，前后描述一致；
(3.2.d.5)文档内容方面，对软件功能、性能、特性等描述内容详细、准确、无二义性、易于理解和使用，内容可验证、可修改，具有可追踪性；
(3.2.d.6)文档内容方面，与顶层文档文文相符，并且文实一致。
(3.3)设计阶段：
(3.3.a)体系结构类：
(3.3.a.1)体系结构方面，软件结构必须清晰，并且模块化程度高，可读性好；
(3.3.a.2)CSCI设计方面，明确CSCI的模块和过程结构的关系，表述清晰、完整，逻辑关系正确；
(3.3.a.3)CSCI设计方面，明确CSCI计划使用的计算机硬件资源，如处理机能力、内存能力、输入/输出设备能力、辅存能力以及通信/网络设备能力等；
(3.3.a.4)软件单元设计方面，明确软件单元间的动态关系，即软件运行期间软件单元间的相互作用情况。
(3.3.b)接口类：
(3.3.b.1)输入测试性，接收数据必须严格按照通讯协议进行处理；
(3.3.b.2)输入测试性，对所有模拟和数字的输入进行范围和合理性检查设计；
(3.3.b.3)输入测试性，对重要关键输入信号，为防止干扰，应进行滤波处理；
(3.3.b.4)输出测试性，对所有模拟和数字的输出进行范围和合理性检查设计；
(3.3.b.5)输出测试性，软件文件输出设计时，尽量采用标准、通用的格式输出，如xml、txt等格式；
(3.3.b.6)数据测试性，确定足够的数据有效位，以保证运算所要求的精度；
(3.3.b.7)数据测试性，明确每个数据元素的特征，包括数据类型、大小与格式、计量单位、取值范围、准确性和精度、优先级、定时、频率、容量、序列以及其他约束条件、来源和接受者等特征；
(3.3.b.8)数据测试性，明确每个数据元素组合体的特征，包括数据元素及其结构、数据组合体之间的关系、优先级、定时、频率、容量、序列以及其他约束条件、来源和接受者等特征；
(3.3.b.9)数据测试性，数据命名统一、规范、易于理解，含义明确，且前后一致；
(3.3.b.10)数据测试性，数据信息传输时，必须包含一个字或字符串指明数据类型及信息内容，以保证数据传输的正确性；
(3.3.b.11)数据测试性，数据信息传输时，明确数据传输率、周期或非周期、传输间隔、优先级；
(3.3.b.12)通信测试性，人机界面设计方面，向操作员提供的显示信息、图标及其他人机交互方式必须清晰、简明，且无二义性；
(3.3.b.13)通信测试性，人机界面设计方面，显示应考虑颜色、字体大小和位置等因素，符合人机工程要求；
(3.3.b.14)通信测试性，人机界面设计方面，基于任务需求将信息分配到不同的格式或者页面；
(3.3.b.15)通信测试性，人机界面设计方面，对于包含在不同页面的所有必要信息相互一致；
(3.3.b.16)通信测试性，人机界面设计方面，页面的显示内容不宜太多；
(3.3.b.17)通信测试性，人机接口设计方面，明确地阐述CHI设计的安全关键方面，包括对预想的单个或多个操作员失效的分析；
(3.3.b.18)通信测试性，人机接口设计方面，进行人的因素、人类工程学和认知科学的分析(例如认知过载、显示信息的模糊性)；
(3.3.b.19)通信测试性，人机接口设计方面，确保无效的操作员请求被加上标记，并向操作员指明；
(3.3.b.20)通信测试性，人机接口设计方面，要求最少两条独立的命令来执行安全关键功能，在启动任何安全关键指令序列之前考虑是否要求一个操作员响应或授权；
(3.3.b.21)通信测试性，人机接口设计方面，避免在操作员未知的情况下改变系统的安全状态；
(3.3.b.22)通信测试性，人机接口设计方面，安全关键状态变更时，确保有状态变更报告；
(3.3.b.23)通信测试性，人机接口设计方面，能清晰区别关键输入，检查输入的范围和合法性；
(3.3.b.24)通信测试性，人机接口设计方面，允许撤销和恢复。行动应能撤销，错误应能恢复；
(3.3.b.25)通信测试性，人机接口设计方面，提供适当且及时的反馈。如果操作完成，则应给出指示。如果将出现进一步的选项或者行动，则也应说明之。应使操作员能够感觉到对系统的控制以及系统对其行动的响应；
(3.3.b.26)通信测试性，人机接口设计方面，提供表明软件正在运行的实时指示；
(3.3.b.27)通信测试性，人机接口设计方面，在需要若干秒或更长时间的处理功能期间，软件必须向操作员提供一个状态指示。
(3.3.c)模块设计类：
(3.3.c.1)单元逻辑测试性，依据软件功能，合理划分单元，单元数与软件功能相匹配，逻辑关系前后一致，无矛盾冲突，且具有可扩展性；
(3.3.c.2)单元逻辑测试性，如果软件单元包含逻辑，应给出软件单元的逻辑，包括启动条件、控制传递条件、输入响应时间、操作顺序、动态控制序列等内容；
(3.3.c.3)单元逻辑测试性，通过合理的设计，降低DD-路径数目；
(3.3.c.4)中断测试性，给出中断信号的数量、优先级；
(3.3.c.5)中断测试性，必须屏蔽不用的中断源；
(3.3.c.6)中断测试性，避免从中断服务子程序中使用非中断返回语句返回；
(3.3.c.7)数据接口测试性，模块的参数个数与模块接受的输入变量个数一致；
(3.3.c.8)数据接口测试性，模块的参数属性与模块接受的输入变量属性匹配；
(3.3.c.9)数据接口测试性，模块的参数单位与模块接受的输入变量单位一致；
(3.3.c.10)数据接口测试性，模块的参数次序与模块接受的输入变量次序一致；
(3.3.c.11)数据接口测试性，传送给被调用模块的变量个数与该模块的参数个数相同；
(3.3.c.12)数据接口测试性，传送给被调用模块的变量属性与该模块参数的属性匹配；
(3.3.c.13)数据接口测试性，传送给被调用模块的变量单位与该模块参数的单位一致；
(3.3.c.14)数据接口测试性，传送给被调用模块的变量次序与该模块参数的次序一致；
(3.3.c.15)数据接口测试性，调用内部函数时，变量的个数、属性、单位和次序正确；
(3.3.c.16)数据接口测试性，不得修改只是作为输入值的变量；
(3.3.c.17)数据接口测试性，全程变量在所有引用它们的模块中都有相同的定义；
(3.3.c.18)数据接口测试性，不存在把常数当作变量来传送的情况；
(3.3.c.19)数据接口测试性，软件单元的局部数据应与软件单元的输入或输出数据分开描述；
(3.3.c.20)自检测设计测试性，对重要输入输出接口信号进行检测，并将检测结果进行上报和记录；
(3.3.c.21)自检测设计测试性，对重要交联系统或部件进行检测，并将检测结果进行上报和记录；
(3.3.c.22)自检测设计测试性，对重要功能进行检测或验证，并将检测、验证结果进行上报和记录；
(3.3.c.23)复杂性控制测试性，尽量采用模块化设计；
(3.3.c.24)复杂性控制测试性，减少公用模块设计；
(3.3.c.25)复杂性控制测试性，模块的功能划分原则尽量一个模块实现一个功能；
(3.3.c.26)复杂性控制测试性，模块出入口方面，除中断情形外，模块应使用单入口和单出口的控制结构；
(3.3.c.27)复杂性控制测试性，模块独立性方面，采用模块调用方式，而不采用直接访问模块内部有关信息的方式；
(3.3.c.28)复杂性控制测试性，模块独立性方面，适当限制模块间传递的参数个数；
(3.3.c.29)复杂性控制测试性，模块独立性方面，模块内的变量应局部化；
(3.3.c.30)复杂性控制测试性，模块独立性方面，将一些可能发生变化的因素或需要经常修改的部分尽量放在少数几个模块中；
(3.3.c.31)复杂性控制测试性，模块设计时，圈复杂度(McCabe指数)不大于10；
(3.3.c.32)复杂性控制测试性，模块设计时，考虑系统的实时性要求和运行能力，采用适合的耦合度模块设计，一般按照数据耦合、控制耦合、外部耦合、公共数据耦合、内容耦合的优先顺序进行选择；
(3.3.c.33)复杂性控制测试性，模块设计时，考虑系统的实时性要求和运行能力，采用适合的内聚度模块设计一般按照功能内聚、顺序内聚、通信内聚、时间内聚、逻辑内聚、偶然内聚的优先顺序进行选择；
(3.3.c.34)复杂性控制测试性，合理设计共享变量，减少共享变量的使用；
(3.3.c.35)复杂性控制测试性，制定适用于项目的编码规则。
(3.3.d)设计文档类：
(3.3.d.1)标准符合性方面，文档的格式和内容应符合在系统分析阶段所规定的标准、规范；
(3.3.d.2)文档逻辑方面，结构清晰唯一，文档内容前后逻辑关系清晰、一致；
(3.3.d.3)文档逻辑方面，软件流程、模块设计等内容描述逻辑关系清晰、一致；
(3.3.d.4)文档内容方面，对软件流程、模块设计等内容描述详细、准确、无二义性、易于理解，内容可验证、可修改，具有可追踪性，前后描述一致；
(3.3.d.5)文档内容方面，与顶层文档、需求文档文文相符，并且文实一致。
(3.4)编码阶段：
(3.4.a)数据测试性：
(3.4.a.1)数据有效位、数据元素、数据元素组合体的实现与设计一致，且前后一致；
(3.4.a.2)数据命名统一、规范、易于理解，含义明确，且前后一致；
(3.4.a.3)数据传输按照设计要求实现，且能验证数据的正确性。
(3.4.b)逻辑测试性：
(3.4.b.1)软件代码结构清晰，逻辑关系前后一致，无矛盾冲突；
(3.4.b.2)使用合理的实现结构，降低DD-路径数目；
(3.4.b.3)考虑可扩展性，方便后续维护。比如用宏定义常量等；
(3.4.b.4)遵循编码规则，如，书写格式要求，程序上下文联系，语句二义性，程序流程规范，减少或不用goto语句等。
(3.4.c)接口测试性：
(3.4.c.1)减少入口参数，尽量消除关联判定；
(3.4.c.2)程序出口应单一；
(3.4.c.3)减少全局变量的定义个数，且在所有引用它们的单元中都有相同的定义；
(3.4.c.4)减少单元间数据的直接引用；
(3.4.c.5)单元的参数个数与单元接受的输入变量个数一致；
(3.4.c.6)单元的参数属性与单元接受的输入变量属性匹配；
(3.4.c.7)单元的参数单位与单元接受的输入变量单位一致；
(3.4.c.8)单元的参数次序与单元接受的输入变量次序一致；
(3.4.c.9)传送给被调用单元的变量个数与该单元的参数个数相同；
(3.4.c.10)传送给被调用单元的变量属性与该单元参数的属性匹配；
(3.4.c.11)传送给被调用单元的变量单位与该单元参数的单位一致；
(3.4.c.12)传送给被调用单元的变量次序与该单元参数的次序一致；
(3.4.c.13)调用内部单元时，变量的个数、属性、单位和次序正确；
(3.4.c.14)不得修改只是作为输入值的变量；
(3.4.c.15)不存在把常数当作变量来传送的情况。
(3.4.d)中断测试性：
(3.4.d.1)避免从中断服务子程序中使用非中断返回语句返回；
(3.4.d.2)必须屏蔽不使用的中断源。
(3.4.e)注释测试性：
(3.4.e.1)每个单元的可执行代码之前，必须用一段文字注释，包括模单元名注释、单元功能注释、输入/输出注释、参数注释、调用注释、限制注释、异常结束注释、方法注释、外部环境及资源注释；
(3.4.e.2)注释应为功能性的，而非指令的逐句说明；
(3.4.e.3)注释的行数不得少于源程序代码行数的20％。
(3.4.f)复杂性控制测试性：
(3.4.f.1)每个软件单元的圈复杂度(McCabe指数)不大于10；
(3.4.f.2)每个单元的代码行数原则上不超过200行；
(3.4.f.3)尽量提高不超过200行的单元数与总单元数的比例；
(3.4.f.4)减少共享变量的使用；
(3.4.f.5)单元的扇入扇出方面，单元的扇出一般应控制在7以下；
(3.4.f.6)单元的扇入扇出方面，为避免某些程序代码的重复，可适当增加单元的扇入；
(3.4.f.7)单元的扇入扇出方面，为避免某些程序代码的重复，可适当增加单元的扇入；
(3.4.f.8)单元的扇入扇出方面，应使高层单元有较高的扇出，低层单元有较高的扇入；
(3.4.f.9)程序实现时，单元耦合度一般按照数据耦合、控制耦合、外部耦合、公共数据耦合、内容耦合的优先顺序进行选择；
(3.4.f.10)程序实现时，单元内聚度一般按照功能内聚、顺序内聚、通信内聚、时间内聚、逻辑内聚、偶然内聚的优先顺序进行选择。
(3.5)测试验证阶段：
(3.5.a)测试文档类：
(3.5.a.1)标准符合性方面，文档的格式和内容应符合在系统分析阶段所规定的标准、规范；
(3.5.a.2)文档逻辑方面，结构清晰唯一，文档内容前后逻辑关系清晰、一致；
(3.5.a.3)文档内容方面，对软件测试用例和测试方法等内容的描述详细、准确、无二义性、易于理解，内容可修改，具有可追踪性，前后描述一致；
(3.5.a.4)文档内容方面，软件测试用例设计要正确、有效，并且达到有效的覆盖充分性。黑盒测试时，可采用边界值分析法、等价类划分法、错误推测法、因果法、正交试验法、判定表驱动法等方法设计测试用例；
(3.5.a.5)文档内容方面，与顶层文档、需求文档、设计文档文文相符，并且文实一致。
(3.5.b)测试方法类：
(3.5.b.1)内建测试的测试性，内建式测试的设计应不影响软件的正常功能和性能，与系统硬件环境相匹配，能够独立的完成测试；
(3.5.b.2)内建测试的测试性，以最大置信水平完成测试，选择使软件正常运行的测试点；
(3.5.b.3)内建测试的测试性，内建式测试不需要外部激励或设备，通过系统自身的硬件环境完成测试；
(3.5.b.4)内建测试的测试性，内建测试点设置方面，根据具体要求，平衡充分性和易实现性。如，对于循环语句for、while、do…while等，一般只考虑执行1次；屏蔽永远走不到的路径，减少设置测试点的盲目性；路径覆盖测试时，只在路径的末端插入测试点；不同时使用多种设置策略，如路径和分支覆盖探针函数不同时使用；当使用高级编译器时，可使用编译器函数识别分配的内存是否存在泄漏、变量未初始化等问题，减少测试点的设置数；
(3.5.b.5)内建测试的测试性，根据系统实时性要求，设置测试状态和正常运行状态两种工作模式，降低测试对系统正常运行的影响。
(3.6)运行维护阶段：
(3.6.a)修复升级类：
(3.6.a.1)缺陷修复方面，遵循软件生命周期的每个阶段已有的相关设计准则；
(3.6.a.2)缺陷修复方面，针对需要修复的缺陷，设置合理的测试点，或设计合适的测试用例进行测试，能够确认缺陷已被修复。
(3.6.b)功能升级类：
(3.6.b.1)功能扩展方面，对已有功能的优化或扩展新的功能时，必须遵循软件生命周期的每个阶段已有的相关设计准则；
(3.6.b.2)功能扩展方面，设置合理的测试点，或合适的测试用例进行测试，确认功能扩展实现达到预期，且未引入新的软件缺陷。
(3.6.c)故障排除类：
(3.6.c.1)硬件排故方面，在保持原有软件功能不变的情况下，可将软件设置为测试维护状态，根据硬件设计原理，增加对硬件的检测功能设计，并遵循相应的设计准则；
(3.6.c.2)软件排故方面，遵循具有自检测功能模块的设计准则。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(4)中，构建包含测试性特性影响要素层、测试性特性影响因素层和测试性子特性层的软件测试性度量层次框架模型，每层度量框架包括：
(4.1)步骤(3)设计出的准则定义为测试性特性影响要素层，采用最大隶属原则，确定每条准则所属的影响因素；
(4.2)测试性特性影响因素层包括功能点指数、非功能需求书、软件单元数、单元耦合度、DD-路径、标准输入比、标准输出比、中间结果断言比、前置条件断言比等55个影响因素；
(4.3)测试性子特性层包括可控性、可理解性、可观测性、测试支持能力、简单性、可分解性、适用性和可追踪性。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(4)中，结合层次分析法，对每一层次的要素进行定量的相对重要程度的判断，再用数学方法计算出相对权重。具体计算如下：
(4.4)假设第k层选择了n个要素，根据各要素的重要程度，进行两两比较，得到一个n×n的判断矩阵：
(4.5)计算判断矩阵每行所有元素的几何平均值：
得：
(4.6)将归一化，即计算：
得：
即为所求特征向量的近似值，也是第k层中各要素关于总目标的相对权重，且
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(5)中，建立测试性特性影响因素集U＝{U1，U2，…，Un}，综合反映出软件测试性。这些指标满足U＝U1∪U2∪…∪Us，其中Ui＝{Ui1，Ui2，…，Uim}，任意i≠j，i，j＝1，2，…s。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(5)中，确定测试性评判集V＝{V1，V2，…，Vn}，根据实际需要，将软件测试性特性划分为4级，包括：好、较好、一般、差，表示为V＝{V1，V2，V3，V4}。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(5)中，运用模糊综合评估法，进行单指标模糊评估和多指标综合评估，确定软件测试性的程度。具体包括：
(5.1)单指标模糊评估就是从一个单独的指标出发，研究目标对象属于各评估等级的隶属度，即确定隶属函数L1(Ui)、L2(Ui)、L3(Ui)、L4(Ui)对每个特性Ui进行量化，隶属函数通过逻辑推理方式得到，建立从U到V的模糊映射U→V，由单个影响因素评价集组成单指标评估的模糊关系矩阵：
式中rij表示第i个特性Ui属于评估等级Vj的隶属度，rij∈[0，1]。通过模糊矢量rij可以刻画被评估对象在某个影响因素Uij方面的表现。
在等级V1，V2，V3，V4上的隶属函数分别为：
(5.2)综合评估的目的是求解综合评估结果，也就是利用模糊合成算子合成测试性影响因素权重向量与模糊评估矩阵R，获得软件测试性的模糊综合评估结果向量B：
通过以上方法，得到软件测试性的综合评估结果，其中bj代表从整体上看，软件测试性属于评估等级集元素Vj的隶属程度。通常情况下，综合评估的最终评估结果根据最大隶属度的原则给出。
(5.3)将综合评价得到的向量B归一化作为权重B′：
(5.4)将等级划分采用1分制量化为V′＝{1.0，0.8，0.6，0.4}，采用加权法计算得到最终的评估结果：
ST＝B′*V′T。
本发明与现有技术相比，具有以下优点：
(1)本发明一种面向软件生命周期的装备软件测试性设计方法，是面向软件全生命周期的一种设计方法，从软件研制的早期开始指导设计人员进行经济有效的测试性设计，非常有效的提升设计人员(尤其新设计人员)的测试性设计水平，并改变以往测试性设计和软件设计“两张皮”的现象，改善软件的测试性，使软件质量得到保证；
(2)本发明提出的度量方法不仅可以准确评价软件测试性，还能精确地比较不同软件的测试性程度的大小；
(3)本发明提出的测试性设计准则具有切实可行的实操性，并且可以根据不同类型软件进行裁剪，设计准则更具有通用性。
附图说明
图1为本发明的面向软件生命周期的装备软件测试性设计方法流程图；
图2为本发明的装备软件测试性设计准则剪裁方法图。
具体实施方式
下面结合附图和具体实例对本发明作进一步详细的描述。但不应将此理解为本发明上述主题的范围仅限于以下实施例，凡基于本发明内容的技术均属于本发明的范围。
本发明面向软件生命周期，根据各个阶段研制任务以及实际需求，制定软件测试性设计准则的分类方案，考虑软件测试性的影响因素，最后设计出装备软件测试性通用设计准则，提升软件的测试效率和有效性，确保软件质量最终满足要求。
一种面向软件生命周期的装备软件测试性设计方法，如图1、2所示，包括以下步骤：
(1)明确软件生命周期每个阶段的任务和要求；
(2)根据软件生命周期各阶段的任务和要求，制定软件测试性设计准则的分类方案；
(3)按照分类方案，面向软件生命周期，考虑软件测试性的影响因素，设计装备软件测试性通用设计准则；
(4)结合层次分析法，构建软件测试性度量框架；
(5)采用模糊综合评价方法度量应用设计准则后的软件测试性。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(1)中，软件生命周期包括系统分析、需求分析、设计、编码、测试验证和运行维护六个阶段，每个阶段的任务和要求包括：
(1.1)系统分析阶段，分析用户需要，明确软件开发的目的和要达到的目标，尽可能地确定软件的功能和性能指标要求，从顶层策划的角度给出软件开发要求。
(1.2)需求分析阶段，确定软件的功能和性能要求，明确软件开发的运行环境，策划软件的开发计划和软件测试工作计划。
(1.3)设计阶段，根据需求规格说明对软件的体系结构、功能模块和接口进行设计，制定初步的软件集成测试计划。给出各功能模块接口的数据结构，并描述功能模块的过程，给出功能模块的算法和数据结构等内部细节，为软件编码提供依据。
(1.4)编码阶段，依据软件设计说明进行单元程序编码，开展软件单元的静态分析和单元测试，验证软件单元的实现与软件设计说明的一致性，并将经过单元测试的软件模块进行逐步集成和调试，实现软件系统的集成。
(1.5)测试验证阶段，在软件完成单元测试、满足质量要求并纳入软件配置管理后，根据集成测试计划，对软件进行集成测试。完成集成测试后，针对软件的全部功能和性能要求进行确认测试。之后将进行非常重要的一项工作就是系统联试，实现软件与大系统的对接。
(1.6)运行维护阶段，主要涉及到软件安装、升级、排故等工作。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(2)中，根据软件生命周期各阶段的任务和要求，软件测试性设计准则的分类方案包括：
(2.1)系统分析阶段，基于用户需求，侧重软件开发要求，将设计准则分类为系统级测试性要求类，进一步，可确定为测试性要求子类。
(2.2)需求分析阶段，该阶段的任务是明确软件的功能、性能和接口，输出需求规格说明文档。由此，将设计准则划分为功能类、性能类、接口类和文档类。进一步，功能类分为输入测试性、输出测试性、查错测试性子类；性能类分为容量(时间、存储、吞吐量等)测试性、精度(时间精度、数据精度、测试精度)测试性子类；接口类分为外部接口(与硬件的接口)测试性、内部接口(模块间的接口)测试性、数据测试性、通讯测试性子类；文档类分为标准符合性测试性、逻辑测试性、内容测试性子类。
(2.3)设计阶段，该阶段的目标是设计软件的体系结构、功能模块和接口，关注数据结构和算法等具体设计，输出设计说明文档。基于此，将设计准则划分为体系结构类、接口类、模块设计类、文档类。进一步，体系结构类分为体系结构测试性子类；接口类分为输入测试性、输出测试性、数据测试性、通信测试性子类；模块设计类分为单元逻辑测试性、中断测试性、数据接口测试性、自检测设计测试性、复杂性控制测试性子类；文档类分为标准符合性测试性、逻辑测试性、内容测试性子类。
(2.4)编码阶段，该阶段是实现阶段，将设计准则划分为软件源代码类一大类，进一步，分为数据测试性、逻辑测试性、接口测试性、中断测试性、注释测试性、复杂性控制测试性子类。
(2.5)测试验证阶段，使测试效率更高，测试更充分，关注测试方法的设计，输出测试相关文档。由此，将设计准则划分为文档类、测试方法类。进一步，文档类分为标准符合性测试性、逻辑测试性、内容测试性子类；测试方法类分为内建式测试的测试性子类。
(2.6)运行维护阶段，该阶段的任务主要是软件安装、升级、排故等。考虑到任务的操作性，将设计准则划分为修复升级类、功能升级类、故障排除类。进一步，修复升级类分为缺陷修复测试性子类；功能升级类分为功能扩展测试性子类；故障排除类分为硬件排故测试性、软件排故测试性子类。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(3)中，根据制定的分类方案，面向软件生命周期，考虑软件测试性的影响因素，每个阶段的测试性设计准则包括：
(3.1)系统分析阶段：
(3.1.a)需求分析方面，对已确定的需求提出明确、完整、详细的测试性要求，如：为达到良好的测试性设计，逐一列出需满足的标准、规范等，并明确具体的设计要求；
(3.1.b)需求分析方面，对未明确的需求，或在后续工作中可能出现的新增需求，除按(3.1.a)已列出的标准、规范和设计要求外，新增的标准、规范和设计要求需相应增加；
(3.1.c)使用环境方面，明确软件运行的系统环境的要求；
(3.1.d)使用环境方面，明确与硬件环境的接口，便于观察软件测试时所产生的中间数据和不能直接观测到的输出数据；
(3.1.e)软件文档方面，要求种类齐全、文实一致、文文相符，无二义性；
(3.1.f)软件文档方面，检查、分析和评审各阶段编制的必要文档，并实行配置管理。
(3.2)需求分析阶段：
(3.2.a)功能类：
(3.2.a.1)输入测试性，明确输入信号的来源、接收方式和信号发生的最短时间间隔；
(3.2.a.2)输入测试性，结合系统需求和硬件设计，明确重要输入信号的检测监控需求，以及检测监控结果提示的需求；
(3.2.a.3)输出测试性，明确输出信号的发送方法和发送对象，以及发送时间间隔；
(3.2.a.4)输出测试性，结合系统需求和硬件设计，明确重要输出信号的检测监控需求，以及检测监控结果提示的需求；
(3.2.a.5)输出测试性，软件文件输出方面，尽量采用标准、通用的格式输出，如xml、txt等格式；
(3.2.a.6)查错测试性，检测点设置方面，对重要的接口信息状态设置检测点；
(3.2.a.7)查错测试性，检测点设置方面，对要求控制(包括自动控制)过程或设备的状态和控制结果设置检测点；
(3.2.a.8)查错测试性，检测点设置方面，对总线通讯状态设置检测点；
(3.2.a.9)查错测试性，检测结果方面，对故障状态(故障类型、源、时间等)进行上报和记录，并给出检测报告；
(3.2.a.10)查错测试性，检测结果方面，对自测试、自诊断结果给出结果报告。
(3.2.b)性能类：
(3.2.b.1)容量测试性，余量方面，确定有关软件功能的存储量，满足系统规定的余量要求，一般要求应留有不少于20％的余量；
(3.2.b.2)容量测试性，余量方面，确定软件处理时间要求，满足系统规定的余量要求，一般要求应留有不少于20％的余量；
(3.2.b.3)容量测试性，余量方面，结合具体的被控对象，确定软件工作的时序安排，确保软件的工作时序之间留有足够的余量，以满足系统规定和使用的要求,一般要求应留有不少于20％的余量；
(3.2.b.4)容量测试性，确定输入输出通道的吞吐能力，满足系统规定的要求；
(3.2.b.5)精度测试性，确定系统本身的时间精度、数据精度；
(3.2.b.6)精度测试性，确定软件测试要求的时间、数据精度。
(3.2.c)接口类：
(3.2.c.1)外部接口测试性，明确与所设计软件的外部交联系统；
(3.2.c.2)外部接口测试性，明确外部数据传输信息的格式和内容；
(3.2.c.3)外部接口测试性，明确外部接口的来源、类型、范围、单位、目的地等内容；
(3.2.c.4)内部接口测试性，明确内部数据传输信息的格式和内容；
(3.2.c.5)内部接口测试性，明确内部接口的类型、范围、单位等内容；
(3.2.c.6)数据测试性，使软件的满刻度和零表示都与任何数字到模拟、模拟到数字、数字到同步、和/或同步到数字转换器完全兼容；
(3.2.c.7)数据测试性，明确数据正确性和完整性校验的方式、方法；
(3.2.c.8)数据测试性，明确数据的接收方式和信息处理方法；
(3.2.c.9)数据测试性，明确数据传输的封装方式、方法或传输协议；
(3.2.c.10)数据测试性，明确数据传输率、周期或非周期、传输间隔、优先级；
(3.2.c.11)通讯测试性，协议方面，采用确定的方式实现协议；
(3.2.c.12)通讯测试性，协议方面，使用的通讯协议要一致、完整；
(3.2.c.13)通讯测试性，协议方面，采用自同步或自稳定协议。
(3.2.d)需求文档类：
(3.2.d.1)标准符合性方面，文档的格式和内容应符合在系统分析阶段所规定的标准、规范；
(3.2.d.2)文档逻辑方面，结构清晰唯一，内容前后逻辑关系清晰、一致；
(3.2.d.3)文档内容方面，合理划分软件需求的功能点，使每个功能点能独立完成某一功能，且不互相冲突，前后描述一致；
(3.2.d.4)文档内容方面，非功能需求(包括性能、余量、安全性等需求)设置合理，易于测试，满足系统要求，且不互相冲突，前后描述一致；
(3.2.d.5)文档内容方面，对软件功能、性能、特性等描述内容详细、准确、无二义性、易于理解和使用，内容可验证、可修改，具有可追踪性；
(3.2.d.6)文档内容方面，与顶层文档文文相符，并且文实一致。
(3.3)设计阶段：
(3.3.a)体系结构类：
(3.3.a.1)体系结构方面，软件结构必须清晰，并且模块化程度高，可读性好；
(3.3.a.2)CSCI设计方面，明确CSCI的模块和过程结构的关系，表述清晰、完整，逻辑关系正确；
(3.3.a.3)CSCI设计方面，明确CSCI计划使用的计算机硬件资源，如处理机能力、内存能力、输入/输出设备能力、辅存能力以及通信/网络设备能力等；
(3.3.a.4)软件单元设计方面，明确软件单元间的动态关系，即软件运行期间软件单元间的相互作用情况。
(3.3.b)接口类：
(3.3.b.1)输入测试性，接收数据必须严格按照通讯协议进行处理；
(3.3.b.2)输入测试性，对所有模拟和数字的输入进行范围和合理性检查设计；
(3.3.b.3)输入测试性，对重要关键输入信号，为防止干扰，应进行滤波处理；
(3.3.b.4)输出测试性，对所有模拟和数字的输出进行范围和合理性检查设计；
(3.3.b.5)输出测试性，软件文件输出设计时，尽量采用标准、通用的格式输出，如xml、txt等格式；
(3.3.b.6)数据测试性，确定足够的数据有效位，以保证运算所要求的精度；
(3.3.b.7)数据测试性，明确每个数据元素的特征，包括数据类型、大小与格式、计量单位、取值范围、准确性和精度、优先级、定时、频率、容量、序列以及其他约束条件、来源和接受者等特征；
(3.3.b.8)数据测试性，明确每个数据元素组合体的特征，包括数据元素及其结构、数据组合体之间的关系、优先级、定时、频率、容量、序列以及其他约束条件、来源和接受者等特征；
(3.3.b.9)数据测试性，数据命名统一、规范、易于理解，含义明确，且前后一致；
(3.3.b.10)数据测试性，数据信息传输时，必须包含一个字或字符串指明数据类型及信息内容，以保证数据传输的正确性；
(3.3.b.11)数据测试性，数据信息传输时，明确数据传输率、周期或非周期、传输间隔、优先级；
(3.3.b.12)通信测试性，人机界面设计方面，向操作员提供的显示信息、图标及其他人机交互方式必须清晰、简明，且无二义性；
(3.3.b.13)通信测试性，人机界面设计方面，显示应考虑颜色、字体大小和位置等因素，符合人机工程要求；
(3.3.b.14)通信测试性，人机界面设计方面，基于任务需求将信息分配到不同的格式或者页面；
(3.3.b.15)通信测试性，人机界面设计方面，对于包含在不同页面的所有必要信息相互一致；
(3.3.b.16)通信测试性，人机界面设计方面，页面的显示内容不宜太多；
(3.3.b.17)通信测试性，人机接口设计方面，明确地阐述CHI设计的安全关键方面，包括对预想的单个或多个操作员失效的分析；
(3.3.b.18)通信测试性，人机接口设计方面，进行人的因素、人类工程学和认知科学的分析(例如认知过载、显示信息的模糊性)；
(3.3.b.19)通信测试性，人机接口设计方面，确保无效的操作员请求被加上标记，并向操作员指明；
(3.3.b.20)通信测试性，人机接口设计方面，要求最少两条独立的命令来执行安全关键功能，在启动任何安全关键指令序列之前考虑是否要求一个操作员响应或授权；
(3.3.b.21)通信测试性，人机接口设计方面，避免在操作员未知的情况下改变系统的安全状态；
(3.3.b.22)通信测试性，人机接口设计方面，安全关键状态变更时，确保有状态变更报告；
(3.3.b.23)通信测试性，人机接口设计方面，能清晰区别关键输入，检查输入的范围和合法性；
(3.3.b.24)通信测试性，人机接口设计方面，允许撤销和恢复。行动应能撤销，错误应能恢复；
(3.3.b.25)通信测试性，人机接口设计方面，提供适当且及时的反馈。如果操作完成，则应给出指示。如果将出现进一步的选项或者行动，则也应说明之。应使操作员能够感觉到对系统的控制以及系统对其行动的响应；
(3.3.b.26)通信测试性，人机接口设计方面，提供表明软件正在运行的实时指示；
(3.3.b.27)通信测试性，人机接口设计方面，在需要若干秒或更长时间的处理功能期间，软件必须向操作员提供一个状态指示。
(3.3.c)模块设计类：
(3.3.c.1)单元逻辑测试性，依据软件功能，合理划分单元，单元数与软件功能相匹配，逻辑关系前后一致，无矛盾冲突，且具有可扩展性；
(3.3.c.2)单元逻辑测试性，如果软件单元包含逻辑，应给出软件单元的逻辑，包括启动条件、控制传递条件、输入响应时间、操作顺序、动态控制序列等内容；
(3.3.c.3)单元逻辑测试性，通过合理的设计，降低DD-路径数目；
(3.3.c.4)中断测试性，给出中断信号的数量、优先级；
(3.3.c.5)中断测试性，必须屏蔽不用的中断源；
(3.3.c.6)中断测试性，避免从中断服务子程序中使用非中断返回语句返回；
(3.3.c.7)数据接口测试性，模块的参数个数与模块接受的输入变量个数一致；
(3.3.c.8)数据接口测试性，模块的参数属性与模块接受的输入变量属性匹配；
(3.3.c.9)数据接口测试性，模块的参数单位与模块接受的输入变量单位一致；
(3.3.c.10)数据接口测试性，模块的参数次序与模块接受的输入变量次序一致；
(3.3.c.11)数据接口测试性，传送给被调用模块的变量个数与该模块的参数个数相同；
(3.3.c.12)数据接口测试性，传送给被调用模块的变量属性与该模块参数的属性匹配；
(3.3.c.13)数据接口测试性，传送给被调用模块的变量单位与该模块参数的单位一致；
(3.3.c.14)数据接口测试性，传送给被调用模块的变量次序与该模块参数的次序一致；
(3.3.c.15)数据接口测试性，调用内部函数时，变量的个数、属性、单位和次序正确；
(3.3.c.16)数据接口测试性，不得修改只是作为输入值的变量；
(3.3.c.17)数据接口测试性，全程变量在所有引用它们的模块中都有相同的定义；
(3.3.c.18)数据接口测试性，不存在把常数当作变量来传送的情况；
(3.3.c.19)数据接口测试性，软件单元的局部数据应与软件单元的输入或输出数据分开描述；
(3.3.c.20)自检测设计测试性，对重要输入输出接口信号进行检测，并将检测结果进行上报和记录；
(3.3.c.21)自检测设计测试性，对重要交联系统或部件进行检测，并将检测结果进行上报和记录；
(3.3.c.22)自检测设计测试性，对重要功能进行检测或验证，并将检测、验证结果进行上报和记录；
(3.3.c.23)复杂性控制测试性，尽量采用模块化设计；
(3.3.c.24)复杂性控制测试性，减少公用模块设计；
(3.3.c.25)复杂性控制测试性，模块的功能划分原则尽量一个模块实现一个功能；
(3.3.c.26)复杂性控制测试性，模块出入口方面，除中断情形外，模块应使用单入口和单出口的控制结构；
(3.3.c.27)复杂性控制测试性，模块独立性方面，采用模块调用方式，而不采用直接访问模块内部有关信息的方式；
(3.3.c.28)复杂性控制测试性，模块独立性方面，适当限制模块间传递的参数个数；
(3.3.c.29)复杂性控制测试性，模块独立性方面，模块内的变量应局部化；
(3.3.c.30)复杂性控制测试性，模块独立性方面，将一些可能发生变化的因素或需要经常修改的部分尽量放在少数几个模块中；
(3.3.c.31)复杂性控制测试性，模块设计时，圈复杂度(McCabe指数)不大于10；
(3.3.c.32)复杂性控制测试性，模块设计时，考虑系统的实时性要求和运行能力，采用适合的耦合度模块设计，一般按照数据耦合、控制耦合、外部耦合、公共数据耦合、内容耦合的优先顺序进行选择；
(3.3.c.33)复杂性控制测试性，模块设计时，考虑系统的实时性要求和运行能力，采用适合的内聚度模块设计一般按照功能内聚、顺序内聚、通信内聚、时间内聚、逻辑内聚、偶然内聚的优先顺序进行选择；
(3.3.c.34)复杂性控制测试性，合理设计共享变量，减少共享变量的使用；
(3.3.c.35)复杂性控制测试性，制定适用于项目的编码规则。
(3.3.d)设计文档类：
(3.3.d.1)标准符合性方面，文档的格式和内容应符合在系统分析阶段所规定的标准、规范；
(3.3.d.2)文档逻辑方面，结构清晰唯一，文档内容前后逻辑关系清晰、一致；
(3.3.d.3)文档逻辑方面，软件流程、模块设计等内容描述逻辑关系清晰、一致；
(3.3.d.4)文档内容方面，对软件流程、模块设计等内容描述详细、准确、无二义性、易于理解，内容可验证、可修改，具有可追踪性，前后描述一致；
(3.3.d.5)文档内容方面，与顶层文档、需求文档文文相符，并且文实一致。
(3.4)编码阶段：
(3.4.a)数据测试性：
(3.4.a.1)数据有效位、数据元素、数据元素组合体的实现与设计一致，且前后一致；
(3.4.a.2)数据命名统一、规范、易于理解，含义明确，且前后一致；
(3.4.a.3)数据传输按照设计要求实现，且能验证数据的正确性。
(3.4.b)逻辑测试性：
(3.4.b.1)软件代码结构清晰，逻辑关系前后一致，无矛盾冲突；
(3.4.b.2)使用合理的实现结构，降低DD-路径数目；
(3.4.b.3)考虑可扩展性，方便后续维护。比如用宏定义常量等；
(3.4.b.4)遵循编码规则，如，书写格式要求，程序上下文联系，语句二义性，程序流程规范，减少或不用goto语句等。
(3.4.c)接口测试性：
(3.4.c.1)减少入口参数，尽量消除关联判定；
(3.4.c.2)程序出口应单一；
(3.4.c.3)减少全局变量的定义个数，且在所有引用它们的单元中都有相同的定义；
(3.4.c.4)减少单元间数据的直接引用；
(3.4.c.5)单元的参数个数与单元接受的输入变量个数一致；
(3.4.c.6)单元的参数属性与单元接受的输入变量属性匹配；
(3.4.c.7)单元的参数单位与单元接受的输入变量单位一致；
(3.4.c.8)单元的参数次序与单元接受的输入变量次序一致；
(3.4.c.9)传送给被调用单元的变量个数与该单元的参数个数相同；
(3.4.c.10)传送给被调用单元的变量属性与该单元参数的属性匹配；
(3.4.c.11)传送给被调用单元的变量单位与该单元参数的单位一致；
(3.4.c.12)传送给被调用单元的变量次序与该单元参数的次序一致；
(3.4.c.13)调用内部单元时，变量的个数、属性、单位和次序正确；
(3.4.c.14)不得修改只是作为输入值的变量；
(3.4.c.15)不存在把常数当作变量来传送的情况。
(3.4.d)中断测试性：
(3.4.d.1)避免从中断服务子程序中使用非中断返回语句返回；
(3.4.d.2)必须屏蔽不使用的中断源。
(3.4.e)注释测试性：
(3.4.e.1)每个单元的可执行代码之前，必须用一段文字注释，包括模单元名注释、单元功能注释、输入/输出注释、参数注释、调用注释、限制注释、异常结束注释、方法注释、外部环境及资源注释；
(3.4.e.2)注释应为功能性的，而非指令的逐句说明；
(3.4.e.3)注释的行数不得少于源程序代码行数的20％。
(3.4.f)复杂性控制测试性：
(3.4.f.1)每个软件单元的圈复杂度(McCabe指数)不大于10；
(3.4.f.2)每个单元的代码行数原则上不超过200行；
(3.4.f.3)尽量提高不超过200行的单元数与总单元数的比例；
(3.4.f.4)减少共享变量的使用；
(3.4.f.5)单元的扇入扇出方面，单元的扇出一般应控制在7以下；
(3.4.f.6)单元的扇入扇出方面，为避免某些程序代码的重复，可适当增加单元的扇入；
(3.4.f.7)单元的扇入扇出方面，为避免某些程序代码的重复，可适当增加单元的扇入；
(3.4.f.8)单元的扇入扇出方面，应使高层单元有较高的扇出，低层单元有较高的扇入；
(3.4.f.9)程序实现时，单元耦合度一般按照数据耦合、控制耦合、外部耦合、公共数据耦合、内容耦合的优先顺序进行选择；
(3.4.f.10)程序实现时，单元内聚度一般按照功能内聚、顺序内聚、通信内聚、时间内聚、逻辑内聚、偶然内聚的优先顺序进行选择。
(3.5)测试验证阶段：
(3.5.a)测试文档类：
(3.5.a.1)标准符合性方面，文档的格式和内容应符合在系统分析阶段所规定的标准、规范；
(3.5.a.2)文档逻辑方面，结构清晰唯一，文档内容前后逻辑关系清晰、一致；
(3.5.a.3)文档内容方面，对软件测试用例和测试方法等内容的描述详细、准确、无二义性、易于理解，内容可修改，具有可追踪性，前后描述一致；
(3.5.a.4)文档内容方面，软件测试用例设计要正确、有效，并且达到有效的覆盖充分性。黑盒测试时，可采用边界值分析法、等价类划分法、错误推测法、因果法、正交试验法、判定表驱动法等方法设计测试用例；
(3.5.a.5)文档内容方面，与顶层文档、需求文档、设计文档文文相符，并且文实一致。
(3.5.b)测试方法类：
(3.5.b.1)内建测试的测试性，内建式测试的设计应不影响软件的正常功能和性能，与系统硬件环境相匹配，能够独立的完成测试；
(3.5.b.2)内建测试的测试性，以最大置信水平完成测试，选择使软件正常运行的测试点；
(3.5.b.3)内建测试的测试性，内建式测试不需要外部激励或设备，通过系统自身的硬件环境完成测试；
(3.5.b.4)内建测试的测试性，内建测试点设置方面，根据具体要求，平衡充分性和易实现性。如，对于循环语句for、while、do…while等，一般只考虑执行1次；屏蔽永远走不到的路径，减少设置测试点的盲目性；路径覆盖测试时，只在路径的末端插入测试点；不同时使用多种设置策略，如路径和分支覆盖探针函数不同时使用；当使用高级编译器时，可使用编译器函数识别分配的内存是否存在泄漏、变量未初始化等问题，减少测试点的设置数；
(3.5.b.5)内建测试的测试性，根据系统实时性要求，设置测试状态和正常运行状态两种工作模式，降低测试对系统正常运行的影响。
(3.6)运行维护阶段：
(3.6.a)修复升级类：
(3.6.a.1)缺陷修复方面，遵循软件生命周期的每个阶段已有的相关设计准则；
(3.6.a.2)缺陷修复方面，针对需要修复的缺陷，设置合理的测试点，或设计合适的测试用例进行测试，能够确认缺陷已被修复。
(3.6.b)功能升级类：
(3.6.b.1)功能扩展方面，对已有功能的优化或扩展新的功能时，必须遵循软件生命周期的每个阶段已有的相关设计准则；
(3.6.b.2)功能扩展方面，设置合理的测试点，或合适的测试用例进行测试，确认功能扩展实现达到预期，且未引入新的软件缺陷。
(3.6.c)故障排除类：
(3.6.c.1)硬件排故方面，在保持原有软件功能不变的情况下，可将软件设置为测试维护状态，根据硬件设计原理，增加对硬件的检测功能设计，并遵循相应的设计准则；
(3.6.c.2)软件排故方面，遵循具有自检测功能模块的设计准则。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(4)中，构建包含测试性特性影响要素层、测试性特性影响因素层和测试性子特性层的软件测试性度量层次框架模型，每层度量框架包括：
(4.1)步骤(3)设计出的准则定义为测试性特性影响要素层，采用最大隶属原则，确定每条准则所属的影响因素；
(4.2)测试性特性影响因素层包括功能点指数、非功能需求书、软件单元数、单元耦合度、DD-路径、标准输入比、标准输出比、中间结果断言比、前置条件断言比等55个影响因素；
(4.3)测试性子特性层包括可控性、可理解性、可观测性、测试支持能力、简单性、可分解性、适用性和可追踪性。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(4)中，结合层次分析法，对每一层次的要素进行定量的相对重要程度的判断，再用数学方法计算出相对权重。具体计算如下：
(4.4)假设第k层选择了n个要素，根据各要素的重要程度，进行两两比较，得到一个n×n的判断矩阵：
(4.5)计算判断矩阵每行所有元素的几何平均值：
得：
(4.6)将归一化，即计算：
得：
即为所求特征向量的近似值，也是第k层中各要素关于总目标的相对权重，且
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(5)中，建立测试性特性影响因素集U＝{U1，U2，…，Un}，综合反映出软件测试性。这些指标满足U＝U1∪U2∪…∪Us，其中Ui＝{Ui1，Ui2，…，Uim}，任意i≠j，i，j＝1，2，…s。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(5)中，确定测试性评判集V＝{V1，V2，…，Vn}，根据实际需要，将软件测试性特性划分为4级，包括：好、较好、一般、差，表示为V＝{V1，V2，V3，V4}。
上述的一种面向软件生命周期的装备软件测试性设计方法，在步骤(5)中，运用模糊综合评估法，进行单指标模糊评估和多指标综合评估，确定软件测试性的程度。具体包括：
(5.1)单指标模糊评估就是从一个单独的指标出发，研究目标对象属于各评估等级的隶属度，即确定隶属函数L1(Ui)、L2(Ui)、L3(Ui)、L4(Ui)对每个特性Ui进行量化，隶属函数通过逻辑推理方式得到，建立从U到V的模糊映射U→V，由单个影响因素评价集组成单指标评估的模糊关系矩阵：
式中rij表示第i个特性Ui属于评估等级Vj的隶属度，rij∈[0，1]。通过模糊矢量rij可以刻画被评估对象在某个影响因素Uij方面的表现。
在等级V1，V2，V3，V4上的隶属函数分别为：
(5.2)综合评估的目的是求解综合评估结果，也就是利用模糊合成算子合成测试性影响因素权重向量与模糊评估矩阵R，获得软件测试性的模糊综合评估结果向量B：
通过以上方法，得到软件测试性的综合评估结果，其中bj代表从整体上看，软件测试性属于评估等级集元素Vj的隶属程度。通常情况下，综合评估的最终评估结果根据最大隶属度的原则给出。
(5.3)将综合评价得到的向量B归一化作为权重B′：
(5.4)将等级划分采用1分制量化为V′＝{1.0，0.8，0.6，0.4}，采用加权法计算得到最终的评估结果：
ST＝B′*V′T。
本发明的面向软件生命周期的装备软件测试性设计方法，以某指控中心总控软件为例，具体包括以下步骤：
(1)指控类软件测试性设计准则剪裁
指控系统是一种“人-机”结合的信息交互系统，使得指控软件的内部结构复杂，软件架构层次多样，功能需求繁多，技术上主要是以数据管理、分布式计算、信息传输、保障实时性等为重点，存在体系结构需整合、系统功能需完善等问题。通过分析，指控类软件更关注体系结构、“人-机”界面、“人-机”操作、软件功能、软件性能、接口、运行维护等方面的设计准则，据此裁剪出指控类软件测试性设计准则。
(2)分析某指控中心总控软件的不足
经过与软件开发人员进行沟通和交流，充分了解指控中心总控软件的功能。通过分析，目前指控中心总控软件存在如下不足：
(2.1)需求描述方面，缺少内部接口需求描述。
(2.2)需求描述方面，缺少内部数据需求描述。
(2.3)需求描述方面，缺少软件质量因素描述。
(2.4)调试日志方面，需求中缺少相应描述，且产生的调试日志内容记录不全面。
(2.5)自检测方面，软件需求和设计中没有自检测要求和设计。
(2.6)数据传输方面，缺少数据验证和校验设计。
(2.7)编码方面，只对注释率进行了要求，但对代码注释的内容没有明确要求。
(3)软件测试性设计准则的应用
考虑软件存在的不足，从功能和性能完成的角度，选取某指控中心总控软件的三个典型软件功能模块(与分控中心某总控软件通信功能、数据存储控制、指挥模式切换)从软件需求分析阶段、设计阶段、测试验证阶段进行测试性设计。主要包括以下步骤：
(3.1)软件需求分析阶段：
考虑指控类软件测试性设计准则，对某指控中心总控软件需求规格说明中的三个典型软件功能模块(与分控中心某总控软件通信功能、数据存储控制、指挥模式切换)、内部接口需求和内部数据需求的需求进行设计完善，具体情况如下：
(a)与分控中心某总控软件通信功能
向分控中心某总控软件发送指挥控制指令功能的原功能描述：
通信协议见《某网络系统接口约定》，目前发送的指令为“-1分钟发射”，“进入热戒备”，“越级2”，“越级2链路切换好”，“升级”，“升级链路切换好”，“平级接替”，“平级接替链路切换好”。要求发送指令可配置。
使用软件需求分析阶段的功能类(3.2.a.7)和(3.2.a.9)设计准则，对原功能进行测试性设计，功能描述更改为：
通信协议见《某网络系统接口约定》，对发送的指令设置检测点,检测指令的状态是否正常，并给出指令发送状态提示，异常情况(异常发生时间、指令名称、异常描述)记入日志。目前发送的指令为“-1分钟发射”，“进入热戒备”，“越级2”，“越级2链路切换好”，“升级”，“升级链路切换好”，“平级接替”，“平级接替链路切换好”。要求发送指令可配置。
接收分控中心某总控软件测试状态和指令功能的原功能描述：
通信协议见《某网络系统接口约定》，接收测试状态和指令，指令包括：“越级2具备执行条件”，“越级2好”，“升级具备执行条件”，“升级好”，“平级接替具备执行条件”，“平级接替好”。
使用软件需求分析阶段的功能类(3.2.a.7)(3.2.a.9)设计准则和接口类(3.2.c.7)设计准则，对原功能进行测试性设计，功能描述更改为：
通信协议见《某网络系统接口约定》，接收测试状态和指令，设置检测点，检测接收的数据包有无漏发和丢包，并给出提示信息；对接收的指令设置检测点,按照接口约定对接收的指令进行数据正确性校验，并给出指令状态提示，异常情况(异常发生时间、指令名称、异常描述)记入日志。指令包括：“越级2具备执行条件”，“越级2好”，“升级具备执行条件”，“升级好”，“平级接替具备执行条件”，“平级接替好”。
(b)数据存储控制
数据存储控制功能的原功能描述：
通信帧结构与《某网络系统接口约定》相同，控制指令包括：“启动存储”，“启动存储(长期加电)”和“停止存储”，接收数据包括：“存储启动状态”和“心跳计数”，要求控制指令和数据都可配置；
接收数据存储软件1和数据存储软件2周期性发送的状态数据，并分别在界面显示。
使用软件需求分析阶段的功能类(3.2.a.7)(3.2.a.9)设计准则、接口类(3.2.c.7)(3.2.c.10)设计准则，对原功能进行测试性设计，功能描述更改为：
通信帧结构与《某网络系统接口约定》相同，设置检测点，检测接收的数据包有无漏发和丢包，并给出提示信息；对接收的指令设置检测点,按照接口约定对接收的指令进行数据正确性校验，并给出指令状态提示，异常情况(异常发生时间、指令名称、异常描述)记入日志。控制指令包括：“启动存储”，“启动存储(长期加电)”和“停止存储”，接收数据包括：“存储启动状态”和“心跳计数”，要求控制指令和数据都可配置；
接收数据存储软件1和数据存储软件2周期性(周期为5s)发送的状态数据，并分别在界面显示。
(c)指挥模式切换
非升级总控功能的原功能描述：
接收到越级1指令，根据要越级的井号，首先向被越级的分中心总控软件发送越级1指令(有可能会超时)，之后将与被越级的分中心总控软件的通信切换为与指控中心越级总控软件通信，之后向越级总控软件转发越级1指令。
使用软件需求分析阶段的功能类(3.2.a.7)(3.2.a.9)设计准则，对原功能进行测试性设计，功能描述更改为：
接收到越级1指令，根据要越级的井号，首先向被越级的分中心总控软件发送越级1指令(有可能会超时，提示指令发送超时，并将异常情况(异常发生时间、指令名称、异常描述)记入日志)，之后将与被越级的分中心总控软件的通信切换为与指控中心越级总控软件通信，之后向越级总控软件转发越级1指令。
(d)内部接口需求和内部数据需求
使用指控类软件测试性设计准则软件需求阶段的接口类和文档类的设计准则，在软件需求描述中增加内部接口需求和内部数据需求两部分内容的设计描述。
(3.2)软件设计阶段
首先按照指控类软件的软件设计阶段测试性设计准则，将软件需求分析阶段中完善的需求描述落实到软件概要设计和详细设计中，并在软件详细设计中给出具体的实现方法和过程。
接着，在指挥模式切换功能模块设计时，应用指控类软件测试性设计准则软件设计阶段接口类(3.3.b.25)设计准则，在“非升级总控”和“升级总控”的功能设计中“等待集成通信设备回复链路切换好”时增加“正在等待集成通信设备回复”的提示设计。
在内部接口和内部数据设计时，按照指控类软件测试性设计准则软件设计阶段接口类的输入测试性、输出测试性和数据测试性设计准则进行测试性设计。
在软件详细设计说明中，第4节编码规则中增加软件设计阶段的注释和复杂性控制的测试性要求。包括注释内容、软件单元的圈复杂度、模块独立性等要求。使用的设计准则包括软件设计阶段的模块设计类的测试性设计准则和软件编码阶段的源代码类的注释测试性设计准则。
(3.3)编码阶段：
按照软件编码阶段的源代码类的测试性设计准则，通过编码实现软件需求分析阶段完善的需求、软件设计阶段的设计要求以及编码规则中增加的注释和复杂性控制的测试性要求。
(3.4)软件测试验证阶段：
采用软件测试验证阶段的(3.5.b)设计准则，设置测试状态和正常运行状态两种工作模式，在测试状态下，进行接口测试，检测接口状态和数据传输是否正常。增加或修改原有三个典型软件功能模块的测试用例，进行软件配置项测试，并统计测试中发现的软件缺陷数。
(4)软件测试性评估
在对某指控中心总控软件的测试性进行评估时，首先评估软件测试性子特性，评估时需要按照最大隶属原则确定设计准则影响的测试性因素，再根据软件测试性子特性评价软件测试性，测试性子特性的评估结果是软件测试性评估的输入。在软件测试性度量层次框架模型中，根据某指控中心总控软件测试性设计情况，剪裁出受设计准则影响的测试性子特性：可控性、可理解性、可观测性、测试支持能力和简单性，确定测试性的评估指标特性因素集U＝{U1，U2，U3，U4，U5}＝
{可控性U1，可理解性U2，可观测性U3，测试支持能力U4，简单性U5}，进一步地，确定测试性子特性的评估指标影响因素集：
可理解性U2＝
{需求/设计一致度U21，设计/
实现一致度U22，需求一致度U23，平均需求完整度U24，平均外部接口详细度U25}；可观测性U3＝{外部输出数U31，标准输出比U32，中间状态观测能力U33}；测试支持能力U4＝
{标准输出比U41，标准输入比U42，接口类型数U43，输出文件标准度U44}；简单性U5＝
{功能点指数U51，非功能需求数U52，外部输入数U53，外部输出数U54}。
采用9标度法构造两两判断矩阵，得到软件测试性子特性评估指标影响因素集Uij的判断矩阵为：
由(4.5)、(4.6)计算得出软件测试性子特性评估指标影响因素层的权重向量，如下：
通过逻辑推理由(5.1)得到可控性、可理解性、可观测性、测试支持能力和简单性评估指标的影响因素集的单指标模糊评判矩阵分别为R1、R2、R3、R4、R5：
由(5.1)得到软件测试性子特性层的评判指标，如下：
采用得到9标度法构造两两判断矩阵，得到软件测试性子特性集U对应的判断矩阵为：
通过(4.5)、(4.6)计算得出软件测试性子特性指标的权重为：
由软件测试性子特性层的评判指标得到可控性、可理解性、可观测性、测试支持能力和简单性五个指标的模糊评判矩阵为R。
由(5.2)得到软件测试性评价指标：
由(5.3)、(5.4)得到软件测试性指标：
ST＝B′*y′T＝0.928
按最大隶属度的原则，该软件从软件测试性总体评价上来看，评价结论为“好”。
(5)软件测试性设计准则的应用效果
通过软件测试性设计准则的应用，在软件配置项测试的过程中，软件易于测试的程度和测试效率得到明显提升，原来测试这些功能点所需工期为28工时，现在所需工期为24工时，测试效率提升14％。软件需求阶段接口类和文档类设计准则的应用使内部接口和内部数据的测试覆盖率达到100％。在软件缺陷发现方面，未应用软件测试性设计准则前，配置项测试中发现软件缺陷数为1个。应用软件测试性设计准则后，测试中又暴露出1个内部接口方面的软件缺陷，并得到软件开发人员的确认，软件缺陷数发现率提升一倍。
以上所述，仅为本发明一个具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。
本发明说明书中未作详细描述的内容属于本领域专业技术人员的公知技术。

Claims (6)

1.一种面向软件生命周期的装备软件测试性设计方法，其特征在于，包括以下步骤：
(1)明确软件生命周期每个阶段的任务和要求；
(2)根据软件生命周期各阶段的任务和要求，制定软件测试性设计准则的分类方案；
(3)按照分类方案，面向软件生命周期，考虑软件测试性的影响因素，设计装备软件测试性通用设计准则；
(4)结合层次分析法，构建软件测试性度量框架；
(5)采用模糊综合评价方法度量应用设计准则后的软件测试性；
在步骤(1)中，软件生命周期包括系统分析、需求分析、设计、编码、测试验证和运行维护六个阶段，每个阶段的任务和要求包括：
(1.1)系统分析阶段，分析用户需要，明确软件开发的目的和要达到的目标，确定软件的功能和性能指标要求，从顶层策划的角度给出软件开发要求；
(1.2)需求分析阶段，确定软件的功能和性能要求，明确软件开发的运行环境，策划软件的开发计划和软件测试工作计划；
(1.3)设计阶段，根据需求规格说明对软件的体系结构、功能模块和接口进行设计，制定初步的软件集成测试计划；给出各功能模块接口的数据结构，并描述功能模块的过程，给出功能模块的算法和数据结构等内部细节，为软件编码提供依据；
(1.4)编码阶段，依据软件设计说明进行单元程序编码，开展软件单元的静态分析和单元测试，验证软件单元的实现与软件设计说明的一致性，并将经过单元测试的软件模块进行逐步集成和调试，实现软件系统的集成；
(1.5)测试验证阶段，在软件完成单元测试、满足质量要求并纳入软件配置管理后，根据集成测试计划，对软件进行集成测试；完成集成测试后，针对软件的全部功能和性能要求进行确认测试；最后进行系统联试，实现软件与大系统的对接；
(1.6)运行维护阶段，进行软件安装、升级、排故；
在步骤(4)中，构建包含测试性特性影响要素层、测试性特性影响因素层和测试性子特性层的软件测试性度量层次框架模型，每层度量框架包括：
(4.1)步骤(3)设计出的准则定义为测试性特性影响要素层，采用最大隶属原则，确定每条准则所属的影响因素；
(4.2)测试性特性影响因素层包括功能点指数、非功能需求书、软件单元数、单元耦合度、DD-路径、标准输入比、标准输出比、中间结果断言比、前置条件断言比；
(4.3)测试性子特性层包括可控性、可理解性、可观测性、测试支持能力、简单性、可分解性、适用性和可追踪性；
在步骤(5)中，建立测试性特性影响因素集U＝{U1，U2，…，Un}，综合反映出软件测试性；这些指标满足U＝U1∪U2∪…∪Us，其中Ui＝{Ui1，Ui2，…，Uim}，任意i≠j，i，j＝1，2，…s；
在步骤(5)中，确定测试性评判集V＝{V1，V2，…，Vn}，根据实际需要，将软件测试性特性划分为4级，包括：好、较好、一般、差，表示为V＝{V1，V2，V3，V4}；
在步骤(2)中，根据软件生命周期各阶段的任务和要求，软件测试性设计准则的分类方案包括：
(2.1)系统分析阶段，基于用户需求，侧重软件开发要求，将设计准则分类为系统级测试性要求类，进一步确定测试性要求子类；
(2.2)需求分析阶段，该阶段的任务是明确软件的功能、性能和接口，输出需求规格说明文档；由此，将设计准则划分为功能类、性能类、接口类和文档类；进一步，功能类分为输入测试性、输出测试性、查错测试性子类；性能类分为容量测试性、精度测试性子类；接口类分为外部接口测试性、内部接口测试性、数据测试性、通讯测试性子类；文档类分为标准符合性测试性、逻辑测试性、内容测试性子类；
(2.3)设计阶段，设计软件的体系结构、功能模块和接口，关注数据结构和算法设计，输出设计说明文档；基于此，将设计准则划分为体系结构类、接口类、模块设计类、文档类；接口类分为输入测试性、输出测试性、数据测试性、通信测试性子类；模块设计类分为单元逻辑测试性、中断测试性、数据接口测试性、自检测设计测试性、复杂性控制测试性子类；文档类分为标准符合性测试性、逻辑测试性、内容测试性子类；
(2.4)编码阶段，该阶段是实现阶段，将设计准则划分为软件源代码类，包括数据测试性、逻辑测试性、接口测试性、中断测试性、注释测试性、复杂性控制测试性子类；
(2.5)测试验证阶段，进行测试方法的设计，输出测试相关文档；由此，将设计准则划分为文档类、测试方法类；
(2.6)运行维护阶段，进行软件安装、升级、排故，将设计准则划分为修复升级类、功能升级类、故障排除类。
2.根据权利要求1所述的一种面向软件生命周期的装备软件测试性设计方法，其特征在于，在步骤(4)中，结合层次分析法，对每一层次的要素进行定量的相对重要程度的判断，再用数学方法计算出相对权重；具体计算如下：
(4.4)假设第k层选择了n个要素，根据各要素的重要程度，进行两两比较，得到一个n×n的判断矩阵：
(4.5)计算判断矩阵每行所有元素的几何平均值：
得：
(4.6)将归一化，即计算：
得：
即为所求特征向量的近似值，也是第k层中各要素关于总目标的相对权重，且
3.根据权利要求1所述的一种面向软件生命周期的装备软件测试性设计方法，其特征在于，在步骤(5)中，运用模糊综合评估法，进行单指标模糊评估和多指标综合评估，确定软件测试性的程度；具体包括：
(5.1)单指标模糊评估就是从一个单独的指标出发，研究目标对象属于各评估等级的隶属度，即确定隶属函数L1(Ui)、L2(Ui)、L3(Ui)、L4(Ui)对每个特性Ui进行量化，隶属函数通过逻辑推理方式得到，建立从U到V的模糊映射U→V，由单个影响因素评价集组成单指标评估的模糊关系矩阵：
式中rij表示第i个特性Ui属于评估等级Vj的隶属度,rij∈[0,1]，通过模糊矢量rij刻画被评估对象在某个影响因素Uij方面的表现；
(5.2)利用模糊合成算子合成测试性影响因素权重向量与模糊评估矩阵R，获得软件测试性的模糊综合评估结果向量B：
进而得到软件测试性的综合评估结果，其中bj代表从整体上看，软件测试性属于评估等级集元素Vj的隶属程度；
(5.3)将综合评价得到的向量B归一化作为权重B′：
(5.4)将等级划分采用1分制量化为V′＝{1.0,0.8,0.6,0.4}，采用加权法计算得到最终的评估结果：
ST＝B′*V′T。
4.根据权利要求1所述的一种面向软件生命周期的装备软件测试性设计方法，其特征在于，文档类分为标准符合性测试性、逻辑测试性、内容测试性子类；测试方法类分为内建式测试的测试性子类。
5.根据权利要求1所述的一种面向软件生命周期的装备软件测试性设计方法，其特征在于，修复升级类分为缺陷修复测试性子类；功能升级类分为功能扩展测试性子类；故障排除类分为硬件排故测试性、软件排故测试性子类。
6.根据权利要求3所述的一种面向软件生命周期的装备软件测试性设计方法，其特征在于，在等级V1，V2，V3，V4上的隶属函数分别为：
CN202110484004.1A 2021-04-30 2021-04-30 一种面向软件生命周期的装备软件测试性设计方法 Active CN113204484B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110484004.1A CN113204484B (zh) 2021-04-30 2021-04-30 一种面向软件生命周期的装备软件测试性设计方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110484004.1A CN113204484B (zh) 2021-04-30 2021-04-30 一种面向软件生命周期的装备软件测试性设计方法

Publications (2)

Publication Number Publication Date
CN113204484A CN113204484A (zh) 2021-08-03
CN113204484B true CN113204484B (zh) 2023-11-14

Family

ID=77029681

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110484004.1A Active CN113204484B (zh) 2021-04-30 2021-04-30 一种面向软件生命周期的装备软件测试性设计方法

Country Status (1)

Country Link
CN (1) CN113204484B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116991746B (zh) * 2023-09-25 2023-12-22 航天中认软件测评科技（北京）有限责任公司 一种软件通用质量特性评估方法和装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060113168A (ko) * 2005-04-29 2006-11-02 엘지전자 주식회사 표준 코딩 규칙 적용을 위한 소스 코드 분석방법
CN101847123A (zh) * 2010-05-26 2010-09-29 北京航空航天大学 一种机载计算机软件测试通用体系的构建方法
CN101976222A (zh) * 2010-11-03 2011-02-16 北京航空航天大学 一种基于框架的实时嵌入式软件可测试性测量方法
CN110020403A (zh) * 2017-11-23 2019-07-16 中国电力科学研究院有限公司 一种配电自动化设备测试综合评价方法及系统
CN110717654A (zh) * 2019-09-17 2020-01-21 合肥工业大学 基于用户评论的产品质量评价方法和系统
CN111177004A (zh) * 2019-12-30 2020-05-19 中信百信银行股份有限公司 软件测试综合评价方法、装置、电子设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060113168A (ko) * 2005-04-29 2006-11-02 엘지전자 주식회사 표준 코딩 규칙 적용을 위한 소스 코드 분석방법
CN101847123A (zh) * 2010-05-26 2010-09-29 北京航空航天大学 一种机载计算机软件测试通用体系的构建方法
CN101976222A (zh) * 2010-11-03 2011-02-16 北京航空航天大学 一种基于框架的实时嵌入式软件可测试性测量方法
CN110020403A (zh) * 2017-11-23 2019-07-16 中国电力科学研究院有限公司 一种配电自动化设备测试综合评价方法及系统
CN110717654A (zh) * 2019-09-17 2020-01-21 合肥工业大学 基于用户评论的产品质量评价方法和系统
CN111177004A (zh) * 2019-12-30 2020-05-19 中信百信银行股份有限公司 软件测试综合评价方法、装置、电子设备及存储介质

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
The importance of life cycle modeling to defect detection and prevention;J.H. van Moll;《10th International Workshop on Software Technology and Engineering Practice》;1-7 *
一种基于模糊评估分层模型的构件可测试性评价方法;刘哲;《中国优秀硕士学位论文全文数据库信息科技辑》;I138-138 *
基于模糊层次分析法的软件易用性过程综合评价方法;赵倩;《计算机应用研究》;2730-2735,2739 *
手机软件自动化测试方案的设计与实现;张哲铭;《中国优秀硕士学位论文全文数据库 (信息科技辑)》;I138-224 *
软件的可测试性设计;于洁,杨海燕,高仲仪,李成友;计算机工程与应用(第03期);第124-126页 *

Also Published As

Publication number Publication date
CN113204484A (zh) 2021-08-03

Similar Documents

Publication Publication Date Title
US6697961B1 (en) Method and system for describing predicates in disjuncts in procedures for test coverage estimation
US6385765B1 (en) Specification and verification for concurrent systems with graphical and textual editors
US20150095890A1 (en) Automated management of software requirements verification
Ahamed Studying the feasibility and importance of software testing: An Analysis
CA2774575A1 (en) System and method for display of software quality
Alaqail et al. Overview of software testing standard ISO/IEC/IEEE 29119
CN117009243A (zh) 芯片性能自动化测试方法、装置、计算机设备及存储介质
CN110347580A (zh) 一种构建非嵌入式软件可靠性测试过程模型的方法
CN113204484B (zh) 一种面向软件生命周期的装备软件测试性设计方法
CN117130910A (zh) 一种测试开源鸿蒙操作系统任务调度能力的方法
Baresi et al. Test oracles for simulink-like models
KR100869886B1 (ko) 메인프레임 시스템 환경을 개방형 시스템 환경으로전환하는 리호스팅 방법
WO2024040934A1 (zh) 测试用例集的演化方法、装置、计算设备集群及存储介质
Gleirscher et al. Qualification of proof assistants, checkers, and generators: Where are we and what next?
Jaskolka et al. Repository mining for changes in Simulink and Stateflow models
CN114116471A (zh) 一种自动化代码扫描方法、系统、电子设备与存储介质
CN115176233A (zh) 以确定性顺序执行测试
Wu et al. Defining a test coverage criterion for model-level testing of FBD programs
Menghi et al. Theodore: A trace checker for cps properties
Singh et al. Exploring problems and solutions in estimating testing effort for non functional requirement
CN118394313B (zh) 一种适用多种人员的应用程序快速构建方法
Lopes et al. Static analysis tools, a practical approach for safety-critical software verification
Ben Hafaiedh et al. A formal model-based approach to design failure-aware Internet of Things architectures
Kocka New Interface for ATLAS L1-Trigger Menu Testing
CN116303038A (zh) 一种软件可测试性分析、设计与评价的方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant