软件测试
从软件生存周期看，软件测试是卡住软件质量，尤其是卡住软件可靠性的最后一道关口。但软件测试并不仅仅局限于这个阶段，而应贯穿于软件开发的全过程(见图4)。应解决这样一个认识问题——用于实时控制系统一类的复杂软件，自认为没有错误的想法是不切合实际的。因此，测试的主要目的是：
1) 对软件的质量或可接受性作出判断；
2) 发现问题。
从图4看出，会产生错误的阶段是在需求说明、设计和编程过程中。这些错误若不排除，均会遗传到测试阶段，甚至会遗传到使用阶段。利用测试用例测出问题进行故障分类、故障隔离和故障消除等步骤，直到获得满意的测试结果为止。
测试用例的编写格式和内容如图5所示。测试的设计。难就难在试图利用这组测试用例能找出软件的全部问题。格式中含有测试管理信息——测试用例标识和执行史。测试用例标识是按一定规律统一为每个测试例赋予的代号，便于需求追踪。执行史中有测试日期、测试结果(给出结论：通过/失败)、版本号和主管的测试者签字，这些都是有保存价值的资料。测试用例是需要精心设计、编写、评审、使用、管理和保存的。
软件测试要求在测试过程中，采集软件可靠性数据，并利用软件可靠性模型进行可靠性评估。分析其是否达到了预期的可靠性要求。并据此作出该软件能否放行的决断。若不满足要求，需继续进行测试，直到满足要求为止。可见这是一项十分花精力的活动。
软件验证与确认
软件验证(Verification)和确认(Validation)，简称为V＆V 或V2。验证和确认的区别在于：验证关心的是确保软件模块或功能内在的正确性；确认则表明要与规定的需求进行比较是否满足要求，它所关心的是该软件产品的价值。
软件验证与确认是贯穿于软件开发过程中十分细致的软件检验活动。每个开发阶段的结果可认为是下一开发阶段的一个规格文件，但要进入下一阶段之前必须对该结果作出确认。验证和确认的主要方法有：代码走查、审查、测试和正确性证明等。代码走查就是对软件文档进行书面检查。它通过人工模拟执行源程序的过程，检查软件设计的正确性。人工模拟也像计算机执行那样，可以仔细推敲、校验和核实每一步的执行结果，进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确性。
审查是软件验证和确认中的一个主要方法，可弥补其他方法的一些不足之处。它是一种用形式的、有效的和经济的方法查找设计和编程中的错误。审查的主要目的是1)找出软件中的缺陷；2)核实是否符合需求；3)早期生产评价；4)过程评价等。由第三方进行软件评测工作是十分重要的，其评测工具软件对软件进行静态的和动态的评测，能发现软件设计的缺陷、瓶颈和多余物等。值得指出的是，用于软件测试的各种方法、技术、工具和措施等，对提高软件的可靠性都是必要的，但不是充分的。这就表明，其中任何一个手段，均不能绝对保障软件的可靠性，但只要能发现软件中任何一个微小的错误，就起到了它的作用。
软件评审
从某种意义上说，软件中的多数错误是人为的。软件评审是软件生产过程中过滤软件错误的一个“滤波器”。软件评审涉及评审的组织机构、管理、准则、类别、内容、文件和要求等。
一般要求在软件研制阶段的里程碑点进行软件评审。评审的主要类别有：软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现评审和软件验收评审等。
评审的原则：
·某阶段未通过阶段评审不得进入下一个软件研制阶段；
·评审时对事不对人，评审的是产品，而不是评审生产者；
·评审就要挑刺，找问题、缺陷和隐患；
·评审组的人员面越广越好；
·评审组不作无休止的争论和辩驳，将争论点记录下来，供以后甄别；
·评审只是提出问题，没有解决问题的任务；
·使用“评审检查单”以提高评审的效果；
评审的作用：
·技术把关，避免软件人员的想当然；
·概念沟通，吸收用户和总体人员参加，审查软件人员理解的正确性；
·集思广益，吸收有关的分系统人员参加，从不同侧面确认软件的协调性；
·总结汇报，使实时控制系统总指挥、总设计师了解软件生产的进度、问题和要求，作出新的部署。
评审很容易走过场、走形式。评审效果的好坏，与当事人(软件人员)密切相关。基于有问题才需要评审，不能轻信自己的软件，导致对评审产生对立情绪。对评审出的问题进行整理、分类和汇总，不忽视任何一个细小的疑点。
软件管理
科学的管理能够出可靠性、出效果、出效益。软件的管理工作不完善、不严格，是引起意外事故的原因之一。软件管理主要包括软件项目管理、软件配置管理、软件可靠性管理和软件质量管理等方面。
软件项目管理的内容包括软件开发过程管理、软件可靠性度量、风险管理(包括风险分析和估计)、确定项目任务、建立可操作的工程计划等。软件项目管理是软件管理工作的第一层。需要强调的是，它不是一个阶段，也不仅仅是个步骤，而是贯穿于整个软件开发工程中的一个层次。从其管理内容来看，这是一种十分重要的管理工作。其管理的好坏，直接影响产品的质量。这项管理尚处于起步状态，是个薄弱环节。软件配置管理是软件人员和管理人员确定、组织和开展软件修改的手段，目的是在软件修改过程中设法少犯差错来最大限度地提高软件产品的生产率。软件配置管理涉及软件配置项和基线的确定。
软件配置项可理解为在软件生产的某个阶段应具备的软件文档和保存软件的介质等。软件基线(基准)又称里程碑。软件配置项经软件验证、确认、评审和认定后，形成了软件基线，也就成了该阶段的一个基准。下一个阶段只能在这个基准上进行开发活动。
软件配置管理要求：
·软件修改必须遵循软件更改规范；
·未经批准的更改，任何人无权修改；
·更改后必须测试、验证和确认；
·软件验收，必须对相应的软件进行评审。
具备评审的条件包括：相对该基线的软件配置项齐全、有测试结果和测试分析报告及软件优化报告。
文档管理是一项十分艰巨而又琐碎的工作，要求：文档编写必须规范、文实相符、文文相符、描述具有一致性、确切性和简明性、签署完整、职责明确。软件可靠性管理作了一些初步的尝试。在软件生产过程中，设计了软件可靠性数据采集表格。对软件中的需求、模型、设计、编码和定义域等方面的错误均要填表。填写产生该错误的时间(计算机执行的累计时间)、错误性质、出错原因和排除错误的结果等。
主要问题与解决方法
对实时控制系统软件工程化的重要性的认识尚处于起步阶段，重视程度也不平衡。主要问题：
(1)部分系统的软件开发由硬件人员承担。硬件、软件、模型设计均由一个组完成，仍是典型的“自编、自导、自演”小作坊的工作方式。
(2) 还不太习惯于软件工程化、规范化、结构化和模块化的软件生产方法。往往跳过了软件设计阶段，而是先有编码，为了软件检查才补设计。
(3)缺少配套的软件测试工具。试图利用实时控制系统进行软件的调试、测试、验证、确认和试验工作，这样的软件测试必然是不完整的，也是有局限性的，更是不科学的。
(4)实时控制系统软件可靠性工程的研究是自发的，未纳入实时控制系统研制计划，影响这项工作的深入开(5)需要解决实时控制系统软件工程化方面的若干模糊认识：
·软件就是编程；
·没有测试工具照样可以开发出软件；
·舍不得在软件可靠性上化成本；
·出了问题，才发现软件似乎比硬件更重要。
(6)实时控制系统软件可靠性指标不好定。原因是软件可靠性的评估涉及模型、方法、工具和条件等问题。当前，要求软件的可靠性为100％，对软件是不公正的，也是过于苛刻的。
建议
(1) 软件可靠性工程也是一项涉及面很广的系统工程，应加强这项技术的研究力度。尤其要结合具体实时控制系统设置研究课题，使实时控制系统软件的生产过程同时也是软件可靠性工程的实施过程。使自发的可靠性工作成为有计划、有组织和有目标的研究工作。
(2) 适用于嵌入式计算机的实时软件，例如实时操作系统、Ada语言等，应像美国国防部那样，要强制推行。
(3)计算机技术发展很快，软件技术及软件可靠性工程技术也发展很快，应对重点实时控制系统的软件人员定期组织培训。
(4)为了解决软件生产的小作坊问题，可否考虑逐步推行实时控制系统软件人员考核制，作出资格认证。
