雷达软件测试文档追踪系统的关键技术研究

2014-04-29帅建锋

计算机时代 2014年1期

帅建锋

摘要：雷达软件规模日益庞大，其软件测试也变得非常复杂，测试需求追踪逐步变成非常困难的任务，目前急需解决雷达软件中测试需求追踪管理、文档自动生成等问题。通过对软件测试需求的识别与定位、软件测试任务的分派，实现了雷达软件测试需求的跟踪、追溯，以及按标准模板产生相应的文档，重点对实现该追踪系统的关键技术进行了分析和描述。

关键词：雷达软件；软件测试；文档追踪；需求管理；文档生成

中图分类号：TP391.9 文献标志码：A 文章编号：1006-8228（2014）01-01-03

0 引言

未来战场日益复杂的环境，促使雷达探测能力、环境适用能力得到显著提升，随着雷达软件规模日益庞大，相应的软件测试也变得非常复杂，软件测试需求追踪逐步变成非常困难的任务[1-2]。

软件测试是一项工程化工作，按阶段分为：软件测试需求分析、软件测试策划、软件测试设计、软件测试执行和软件测试总结阶段。软件测试依据项目软件需求规格说明进行测试分析，产生软件测试需求规格说明，再依据测试需求规格说明进行测试设计，设计抽象软件测试用例和具体的测试实例，再执行测试用例并作测试记录，随后对测试结果进行统计分析，形成最终的测试报告[3]。

按照测试充分性要求，软件测试需要覆盖软件需求规格说明中所规定的每一项能力需求，从而验证该能力需求是否得以实现以及实现的效果。软件需求覆盖情况需要通过在每个文档中建立需求追踪矩阵来证明，包括《软件需求规格说明》与《软件测试需求规格说明》（或《软件测试计划》）的双向追踪矩阵，《软件测试需求规格说明》（或《软件测试计划》）与《软件测试说明》的双向追踪矩阵，《软件测试说明》与《软件测试记录》的双向追踪矩阵。

测试人员通过人工的方式建立需求追踪矩阵是一项很耗时的工作，一个双向追踪矩阵往往需要几个小时才能完成，并且在建立过程中容易出错，查找错误也非常费时。而雷达系统所包含的软件数量众多、规模较大，并且军用软件对软件测评具体工作也提出很高要求，软件文档规模迅速增大，由原来的几十页增至数百页，甚至上千页，对此由人工完成追踪工作，已经变成非常困难的任务。

1 关键技术分析

1.1 目标表的识别与定位分析

软件测试需求、软件测试计划、软件测试说明和软件测试记录中均包含数量众多、类型各异的表，除测试记录外，其余文档中均存在各种不同形状的表，即使是测试记录文档，表的形状也不完全相同。若在读取目标表内容的过程中，误读了被合并后的单元格，将造成程序异常。由此，首先需要解决的问题是在指定文档中识别出目标表，我们所采取的算法过程[4]如下。

⑴ 确定识别指定目标表的条件：

⑵ 建立条件数组，并將目标表条件集存入数组：

⑶ 根据以下公式计算出文档中所有的表：

⑷ 识别文档中符合要求的目标表：

1.2 大文档处理分析

Microsoft Word在处理文件过程中，会定时自动产生许多临时文件，当出现意外断电时，Word可通过这些临时文件达到意外出错时恢复文件的效果[5]；当然，Word为了文件恢复而运行这些临时文件是以牺牲速度为代价的。

软件测试需求规格说明、软件测试计划、软件测试说明和软件测试记录文档，描述的内容较多，文档规模很容易达到上百页。这些文档包含有大量的表、图形等内容，在处理过程中，由于Word缓冲数据、进行页面分析、重新分页等任务造成速度较慢，而此时Word运行仍在运行大量临时文件，造成响应速度非常慢。为此，软件测试文档追踪系统采取措施减少临时文件，以提高Word运行速度。

⑴ 计算出文档中的目标表：

⑵ 文档处理：

在系统设计过程中，考虑到大文档的特性，对于规模T达到K文档，可以建立文档规模、计算机配置和处理时机之间的关系表。只要知道其中的两个，就可以查出第三个的具体数值。

1.3 估计测试用例执行日期

由于软件测试用例与软件测试记录存在很大的相关性，故通过软件测试说明能够生成出软件测试记录模板。依据历史数据的统计，通常测试人员的工作效率是能够估计出来的，测试执行过程中，每天执行的测试用例数量也相差无几，但由于现场测试条件或其他工作任务的干预，测试用例数量规模较多（多于100个）与规模较小时（100个以内），测试过程的可控偏差也不相同，导致每天执行的测试用例也不完全相同。按照PERT法估计[6]后，分派测试用例过程如下。

⑴ 依据测试项目策划，定义相应测试周期：

⑵ 确定每天工作量偏差范围：

⑶ 确定预期的每天测试工作量：

⑷ 确定每个测试用例的执行日期：

2 仿真运算结果

2.1 目标表的识别与定位运行结果

在目标表的识别和定位设计时，要注意条件之间的组合性，以及找不到符合条件表的处理。以波束调度软件为例，根据不同的条件组合，得出的目标表数组PTA如表1所示。

通常情况，在实际软件测试过程中，很少有表的行数、列数是始终不变的，第1行的列数与第2行、第5行或其他任意行的列数各不相同。如果直接按行列读取，当读取到不存在的单元格时，就会出现程序异常。为此，需要解决读取指定单元格的问题。测试项表、测试用例表、测试记录表等，行数未知，列数也不能确定，故需采取异常处理机制，当出现异常时，程序仍然能够正常向下执行。

2.2 大文档处理运行结果

按照MS Word处理时间最优进行测试，对于不同的计算机硬件配置，程序优化的性能测试结果见表2与表3。

将性能测试数据进行汇总，得到每个CSCI平均运行时间，如图1和图2所示。

处理结果：

2.3 估计测试用例执行日期运行结果

在生成测试记录模板过程中，确定每个测试用例的执行时间是按照测试计划确定的时间范围进行初步确定，再依据一定的比例范围进行偏差调整，由此确定测试记录模板的时间。测试人员在执行用例过程中，能够按照此测试时间安排每天测试工作任务。

雷达资源管理、航迹跟踪、波束调度CSCI的估计测试用例执行日期如图3、图4和图5所示。

3 结束语

软件测试需求管理是软件需求管理的一个重要组成部分。随着雷达软件规模的不断扩大，其软件测试需求管理的重要性也日益突出。本文研究了雷达软件测试需求跟踪与验证技术的关键技术，针对一些关键技术进行了详细的阐述，同时给出了实现途径。

采用本文给出的方法所设计的软件测试文档追踪系统已经在多个型号产品上使用，该系统能够快速完成各级软件需求追踪、按模板要求自动产生测试文档，极大提升了软件测试人员的工作效率，取得了良好的效果。进一步的研究是针对各军兵种雷达软件的不同要求，完善软件测试文档追踪系统，以进一步适应软件管理需求。

参考文献：

[1] 何友，张晶炜.雷达数据处理及应用[M].电子工业出版社，2009.