需求链及其应用的系统和方法与流程

本公开大体涉及软件需求，并且更具体地，涉及确定软件需求链并在测试生成处理中应用需求链。

背景技术：

可以测试一些软件应用和软件包以确定软件应用是否符合或满足一组软件需求。在某些情况下，可能需要测试软件应用或软件包以满足特定或强制需求测试覆盖范围。例如，一个或多个软件认证标准可能需要安全关键软件，以满足特定限定的软件需求测试覆盖范围，安全关键软件包括但不限于航空软件。

因此，需要一种能够解决上述问题的系统和方法，其能够有效地确定软件需求链并在测试生成处理中应用需求链。

技术实现要素：

根据本公开的方面，提供一种系统，包括：存储器，存储器在其中存储可执行程序指令；和处理器，处理器与存储器通信，处理器能够操作以执行程序指令，从而：接收对于软件应用的一组需求，一组需求包括为软件应用所识别的多个软件需求；分析一组需求，以确定一组需求中的多个软件需求之间的从属性；生成一组需求中的多个软件需求之间的所确定的从属性和测试边界的可视化(visualization)；和将一组需求中的多个软件需求之间的所确定的从属性和测试边界的所生成的可视化储存在记录中。

附图说明

当参考附图阅读以下详细描述时，将更好地理解本公开的实施例的这些和其他特征和方面，其中相同的字符在整个附图中表示相同的部分，其中：

图1是根据一些实施例的整个处理的说明性流程图；

图2是根据一些实施例的处理的说明性流程；

图3是根据一些实施例的一组需求的说明性示例；

图4-9分别是根据一些实施例的示出需求链处理的一些方面的一组需求的说明性示例；

图10是根据一些实施例的为图3的一组需求所识别和确定的测试边界的说明性示例；和

图11是根据一些实施例的设备的框图。

具体实施方式

当介绍本发明的各种实施例的元件时，冠词“一”，“一种”，“该”和“所述”旨在表示存在一个或多个元件。术语“包含”，“包括”和“具有”旨在是包含性的，并且意味着可能存在除所列元件之外的其他元件。

在一些方面，本公开涉及一种系统和处理，该系统和处理提供例如包括软件应用或软件包的需求分析的技术优点，包括确定需求如何彼此相关；向实体(例如，工程师或其他人员，自动测试系统等)提供需求关系/从属性的可视化反馈或表示；和使用需求关系来优化测试程序的测试步骤并生成测试程序。实施本文公开的处理的系统被改进，从而例如以更有效和完整的方式分析和确定软件需求及其之间的从属性(即，需求链)，以及能够应用需求链以改进软件测试生成。

在一些方面，复杂的软件需求(例如，航空软件应用)可具有许多且复杂的从属性，例如包括多级从属性。在一些实例中，待测试的目标部件可具有内部需求(即，指定部件的中间行为的需求)，而不指定外部输入/输出。因此，由于没有为内部需求提供外部输入/输出信息，这些内部需求不能独立测试。在本文的一些方面，内部需求可以与指定外部输入/输出行为的其他需求组合，以获得可用于完成测试生成的可测试参数。在本文的一些实施例中，本公开包括识别软件应用或软件包(即，软件)的软件需求的关联或链，以及进一步，包括链信息的应用，以例如优化测试步骤并生成可执行的测试程序的系统和方法。在一些方面，本公开描述了两种类型的链，水平链和竖直链，以及其对测试生成的含义。

本公开的一些方面描述了构建需求(例如，水平和竖直链式需求)的可视化表示(例如，需求图)并从需求图中识别测试边界的方法。

在一些方面，软件需求可取决于其他软件需求。例如，一个需求可以与另一个需求共享变量。如这里所使用的，不同需求之间的相互从属的行为被称为需求链。链式需求可以为自动测试生成(atg)处理提供有用的信息，其中这样的信息可以用于生成和/或优化测试程序。

在一些方面，给定我们想要生成测试程序的一组需求，我们可能需要分析需求之间的关系。分析可包括：确定哪些需求使用其他需求的输出；这组需求的内部和外部输入/输出是什么；这些需求是如何相关的；以及提供示出确定的需求关系的可视化反馈。分析结果可用于生成测试程序和/或优化测试程序的测试步骤。

在一些实施例中，可能存在两种类型的需求链——水平链和竖直链。需求的水平链指的是仅限定内部变量行为的需求，其中内部变量无法进行外部监控或控制。因此，“内部”需求可以是能够测试的，内部需求可以与限定软件应用或部件的外部输入和输出的行为的其他(即，外部)需求链接。

在一些方面，一些需求可以被称为“分解需求”，其中分解需求的行为未被完全限定。相反，分解需求依赖于其他较低级别的需求来完全限定其行为。在一些方面，分解需求可以例如(至少部分地)以抽象术语表达而不是明确地限定。将分解需求与较低级别需求相关联、连结或以其他方式链接来完全地限定它们的行为可以提供生成分解需求的具体测试程序的机制。这里，这种类型的需求链被称为竖直链。

在关于水平链的一些实施例中，atg分析一组需求并通过在需求之间共享的变量来识别形成连接部件的需求组。每个连接部件在本文称为需求边界，其中需求边界包括一组外部输入/输出变量和边界内的一组需求。在一些实施例中，可以为每个需求边界生成边界图，以例如帮助或促进用户(例如，帮助需求工程师等)检查和/或确定需求是否被充分正确地链接，或外部输入/输出是否被正确限定。

在一些实施例中，本文确定的需求边界可以应用于atg处理的一个或多个区域中。示例atg应用可以包括以下区域：(1)来自atg的测试程序生成，其仅包括外部输入的设置和外部输出的检查，其中每个需求边界引入一个测试程序文件；(2)测试步骤优化，其考虑需求链，以便例如可以在一个测试步骤中测试共享相同外部输入/输出设置的多个测试用例。

在关于竖直链的一些实施例中，atg处理通过识别在分解需求中是否存在限定分解函数的行为的较低级别需求来识别竖直链。注意，较低级别需求使用相应分解函数的输入和返回参数作为需求的监控和控制变量。在某些情况下，可能存在多个级别的竖直链。在某些方面，atg处理迭代所有级别的竖直链并确定完全限定分解需求的行为的一组较低级别需求。

在一些实施例中，竖直链信息还可以与水平链信息一起表示在边界图中。在某些方面，用户(例如，需求工程师等)可以检查边界图，并且如果有的话，识别其中呈现的竖直链中的错误。

在一些实施例中，竖直链可以应用于一个或多个区域中的atg处理，例如包括：(1)生成用于测试用例的测试程序，其中分解函数完全由竖直链接的较低级别需求限定；以及(2)测试程序步骤优化，其考虑竖直链，使得例如可以在一个测试步骤中，测试共享相同外部输入/输出设置的多个测试用例。

图1是根据一些实施例的本文的处理的流程图的说明性示例。处理100是本公开的多个方面的概述。在一些实施例中，处理100可以由包括执行计算机指令的处理器的系统来实施，以实现处理100的操作。在操作105处，可以接收对于软件应用或软件部件的一组需求。该组需求可以包括为软件应用所识别的多个软件需求。在操作105之前或作为其一部分，该组需求可以由实体(例如，工程师或其他人员，自动化系统/处理及其组合)正式地捕获，并且以适合于其使用和应用的人和/或机器可读格式来表示。

操作110包括分析该组需求以确定该组需求中的多个软件需求之间的从属性。如上所述，从属性可以包括水平链接的从属性和竖直链接的从属性。下面将讨论关于一组需求的示例性分析的附加细节。

在操作115处，生成该组需求中的多个软件需求之间的所确定的从属性的可视化。可视化可以由用户(例如，人和/或机器)使用，以验证和确认在操作110处针对该组需求所确定的从属性的准确性和/或完整性。在一些实例中，可以执行进一步修改(即，操作105)，以响应于用户对可视化的审查来校正和/或完成多个软件需求之间的从属性。

在操作120处，可以将该组需求中的多个软件需求之间的所确定的从属性的所生成的可视化的记录存储在存储器或其他数据储存器中。该记录可以包括有形的、已知的或未来开发的数据结构。在一些情况下，包括在该组需求中的多个软件需求之间的所确定的从属性表示的可视化的记录可以从其存储的位置检索并用于其他操作、处理以及进一步的分析和报告。

在一些实施例中，根据本文的一些实施例，在图2的示例流程图中示出了需求链及其相关联的测试生成的处理。处理200可以开始于需求工程师(或其他人员或系统)以机器可读的形式语言(例如，结构化，非结构化或其组合)捕获或以其他方式表示对于软件应用或部件的需求。捕获或写入的需求记录了对于软件应用的一组需求的限定，其中每个需求的限定指定了限定每个相应需求的变量的行为。

在操作210处，使用写入的需求来构建需求图，该需求图可视地表示和描述需求如何在它们之间共享变量。在一些实施例中，表示需求图的数据结构可以包括描述需求图中的需求之间的关系的附加信息(例如，元数据)。在一些实施例中，每个需求是节点，并且如果两个需求共享变量，则这些需求将通过共享变量连接。

在操作215处，应用边界识别处理，以识别在操作210处生成的需求图中的边界，并且将会生成具有所识别的边界的图以供需求工程师(或其他人员)在操作220处审查。如果在215处，边界识别模块识别出不完整的边界(即，一些内部变量没有到外部输入和输出变量的路径)，则在220处，识别模块将通知需求工程师，以便在205处，他们可以修改写入的需求，从而添加缺失或不完整的需求。在处理200的自动化部分中，如果识别模块在225处识别到不完整的边界(对于水平需求)或在230处识别到未完全限定的分解需求，则处理200还可以通知用户(例如，需求工程师或其他人员)修改写入的需求，并返回操作205，以便测试生成处理200可以继续。

在事件操作225和230没有识别到任何问题的情况下，处理200可以前进到操作235，其中基于需求的测试策略可以应用于单独的需求以生成测试用例。可以通过考虑所确定的边界来进一步分析所生成的测试用例，以确定哪些测试用例组(如果有的话)可以一起测试(即，优化)，其中相同的外部输入/输出分配激活一组测试用例。然后，可以在操作245处为每个测试用例组生成测试程序，其中仅写入外部输入/输出分配，以便测试程序可以在目标测试平台中执行。

参考图3，对于包括一组需求300的需求图识别或以其他方式确定测试接口。在该说明性示例中，测试接口在需求本体中被识别为接口定义的一部分，并且属性可以被限定为“test_input”，“test_output”，“test_input_output”或“no_test_interface”。参考图3的示例，外部测试接口被示出为输入端口(例如，305，310，315，320和325)和输出端口(例如，330，335和340)。

图4-9涉及一组需求300的示例，并且操作以公开边界识别处理或模块(例如，图2，215)如何识别该组需求的测试边界的示例，其中每个图示出了根据本文的一些实施例的链处理的一些方面。

在识别出测试接口之后，下一步是识别用于测试的“黑盒”(即，测试边界)，其满足例如以下标准：(i)所有受控变量具有测试输出；(ii)所有监控变量都有测试输入；(iii)所有监控变量都有包括在黑盒中的从属控制变量。作为可以被链接的一组需求300的示例，我们可以从选择受控变量(即，输出)开始，例如如图4所示的output_1(405)。

对于该组需求300继续该示例，图5示出了受控变量405的需求505和监控变量的识别(如果有的话)，直到它们在所识别的测试输入(510，515)处终止为止。可以在该组需求300的第二次迭代或遍历期间，识别或以其他方式确定图5中突出显示的需求和监控变量。

在该组需求300的第三次迭代期间，识别出测试输入510和515上的任何从属控制变量和需求。如图6所示，受控变量615(即“output_3”)和需求605和610取决于测试输入515(即“input_1”)。

在该组需求300的第四次迭代期间，识别受控变量615的任何需求和监控变量，直到它们在测试输入处终止。如图7所示，需求705和710以及监控变量(即，测试输入)715和720被识别为与受控变量615相关(即，链接)。

在该组需求300的第五次迭代期间，识别测试输入715和720上的任何从属控制变量和需求。如图8所示，需求805和受控变量(即，输出)810被识别为取决于测试输入720。

在该组需求300的第六次迭代期间，识别或以其他方式确定受控变量810(即，“output_2”)的任何需求和监控变量，直到它们在测试输入处终止。在图9的说明性描绘中，监控变量905(即，“input_2_0”)被识别为被链接到受控变量810。如图9所示，没有附加的未识别的测试从属性。因此，可以识别需求图300中的一组需求的测试边界。

图10是识别为本示例的一组需求的测试边界的“块盒”。如本详述示例所示，该组需求的所有从属和相互关联的需求已被组合或减少为监控变量(例如，1005，1010，1015，1020和1025)和受控变量(例如，1030，1035和1040)，其可以被监控和控制以用于测试目的。

图11是根据一些实施例的计算系统1100的框图。系统1100可以包括通用或专用计算设备、平台或架构，并且可以执行程序代码或指令以实现本文描述的任何方法、操作和功能。系统1100可以包括一个或多个系统和处理(例如，100和200)的实施。根据一些实施例，系统1100可以包括未示出的其他元件。

系统1100包括可操作地联接到通信装置1120，数据存储装置1130，一个或多个输入装置1140，一个或多个输出装置1150和存储器1160的处理器1110。通信装置1120可以促进与外部装置(诸如数据服务器和其他数据源和/或数据流)的通信。输入装置1140可以包括例如键盘，小键盘，鼠标或其他指示装置，麦克风，旋钮或开关，红外(ir)端口，扩展坞和/或触摸屏。输入装置1140可以用于例如由用户或其他授权人员将信息输入系统1100。输出装置1150可以包括例如显示器(例如，显示屏)，扬声器和/或打印机。

数据存储装置1130可以包括任何适当的永久存储装置，包括磁存储装置(例如，磁带，硬盘驱动器和闪存)，光存储装置，只读存储器(rom)装置等的组合，同时存储器1160可以包括随机存取存储器(ram)，存储级存储器(scm)或任何其他快速存取存储器。

需求链引擎1132可以包括由处理器1110执行的程序代码，以使系统1100执行本文描述的处理中的任何一个或多个。实施例不限于由单个设备执行。需求图可以存储在数据存储装置1120中。在一些实例中，数据存储装置可以包括数据库。数据存储装置1130还可以存储其他数据和其他程序文件1136，用于提供附加功能和/或系统1100的操作所需的功能，例如装置驱动器，操作系统文件等。

本文讨论的所有系统和处理可以体现在存储在一个或多个非暂时性计算机可读介质上的程序代码中。这种介质可以包括例如软盘，cd-rom，dvd-rom，闪存驱动器，磁带和固态随机存取存储器(ram)或只读存储器(rom)存储单元。因此，实施例不限于硬件和软件的任何特定组合。

本文描述的实施例仅用于说明的目的。本领域技术人员将认识到，可以通过对上述实施例的修改和变更来实践其他实施例。

本书面描述使用示例来解释本公开，包括最佳模式，并且还使本领域技术人员能够实践本公开，包括制造和使用任何装置或系统以及执行任何结合的方法。本公开的可专利范围由所附权利需求限定，并且可包括本领域技术人员想到的其他示例。如果这些其他示例具有与权利需求的字面语言没有不同的结构元件，或者如果它们包括与权利需求的字面语言无实质差别的等效结构元件，则这些其他示例意图落入权利需求的范围内。

本发明的进一步方面通过以下条项的主题提供：

1.一种系统，包括：存储器，所述存储器在其中存储可执行程序指令；和处理器，所述处理器与所述存储器通信，所述处理器能够操作以执行所述程序指令，从而：接收对于软件应用的一组需求，所述一组需求包括为所述软件应用所识别的多个软件需求；分析所述一组需求，以确定所述一组需求中的所述多个软件需求之间的从属性；生成所述一组需求中的所述多个软件需求之间的所确定的从属性和测试边界的可视化；和将所述一组需求中的所述多个软件需求之间的所确定的从属性和测试边界的所生成的可视化储存在记录中。

2.根据任何在前条项的系统，进一步包括使对于所述软件应用的所述一组需求的定义文档化，每个需求的所述定义指定限定每个相应的需求的变量行为。

3.根据任何在前条项的系统，其中指定限定所述需求的所述变量行为的需求的所述定义严格地限定：所述软件应用的内部变量的行为是所述软件应用的内部需求，所述内部需求的所述内部变量在所述软件应用外部是不可控制或不可监控的。

4.根据任何在前条项的系统，其中在所述一组需求的所述分析期间，所述内部需求与所述软件应用的至少一个外部需求相关，所述至少一个外部需求中的每一个外部需求限定至少一个外部输入和外部输出的行为，所述至少一个外部输入和外部输出在所述软件应用外部是可控制或可监控的。

5.根据任何在前条项的系统，其中基于对于所述软件应用的至少一个较低级别需求是所述软件应用的分解需求，指定限定所述需求的所述变量行为的需求的所述定义被完全限定。

6.根据任何在前条项的系统，其中所述至少一个较低级别需求使用所述分解需求的输入和返回参数作为其可监控和可控制的变量。

7.根据任何在前条项的系统，进一步包括将所述一组需求中的所述多个软件需求之间的所确定的从属性和测试边界的所述记录用于以下中的至少一个：(i)优化测试程序中的测试步骤，以满足所述软件应用的需求测试覆盖范围；和(ii)生成可执行的测试程序，所述可执行的测试程序运用所述软件应用的外部输入和输出。

8.一种计算机实现的方法，包括：接收对于软件应用的一组需求，所述一组需求包括为所述软件应用所识别的多个软件需求；分析所述一组需求，以确定所述一组需求中的所述多个软件需求之间的从属性；生成所述一组需求中的所述多个软件需求之间的所确定的从属性和测试边界的可视化；和将所述一组需求中的所述多个软件需求之间的所确定的从属性和测试边界的所生成的可视化存储在记录中。

9.根据任何在前条项的方法，进一步包括使对于所述软件应用的所述一组需求的定义文档化，每个需求的所述定义指定限定每个相应的需求的变量行为。

10.根据任何在前条项的方法，其中指定限定所述需求的所述变量行为的需求的所述定义严格地限定：所述软件应用的内部变量的行为是所述软件应用的内部需求，所述内部需求的所述内部变量在所述软件应用外部是不可控制或不可监控的。

11.根据任何在前条项的方法，其中在所述一组需求的所述分析期间，所述内部需求与所述软件应用的至少一个外部需求相关，所述至少一个外部需求中的每一个外部需求限定至少一个外部输入和外部输出的行为，所述至少一个外部输入和外部输出在所述软件应用外部是可控制或可监控的。

12.根据任何在前条项的方法，其中基于对于所述软件应用的至少一个较低级别需求是所述软件应用的分解需求，指定限定所述需求的所述变量行为的需求的所述定义被完全限定。

13.根据任何在前条项的方法，其中所述至少一个较低级别需求使用所述分解需求的输入和返回参数作为其可监控和可控制的变量。

14.根据任何在前条项的方法，进一步包括将所述一组需求中的所述多个软件需求之间的所确定的从属性和测试边界的所述记录用于以下中的至少一个：(i)优化测试程序中的测试步骤，以满足所述软件应用的需求测试覆盖范围；和(ii)生成可执行的测试程序，所述可执行的测试程序运用所述软件应用的外部输入和输出。

15.一种非暂时性计算机可读介质，所述非暂时性计算机可读介质在其中存储有可执行指令，所述介质包括：接收对于软件应用的一组需求的指令，所述一组需求包括为所述软件应用所识别的多个软件需求；分析所述一组需求以确定所述一组需求中的所述多个软件需求之间的从属性的指令；生成所述一组需求中的所述多个软件需求之间的所确定的从属性和测试边界的可视化的指令；和将所述一组需求中的所述多个软件需求之间的所确定的从属性和测试边界的所生成的可视化储存在记录中的指令。

16.根据任何在前条项的介质，其中所述一组需求包括使对于所述软件应用的所述一组需求的定义文档化，每个需求的所述定义指定限定每个相应的需求的变量行为。

17.根据任何在前条项的介质，其中指定限定所述需求的变量行为的需求的定义严格地限定：所述软件应用的内部变量的行为是所述软件应用的内部需求，所述内部需求的所述内部变量在所述软件应用外部是不可控制或不可监控的。

18.根据任何在前条项的介质，其中在所述一组需求的所述分析期间，所述内部需求与所述软件应用的至少一个外部需求相关，所述至少一个外部需求中的每一个外部需求限定至少一个外部输入和外部输出的行为，所述至少一个外部输入和外部输出在所述软件应用外部是可控制或可监控的。

19.根据任何在前条项的介质，其中基于对于所述软件应用的至少一个较低级别需求是所述软件应用的分解需求，指定限定所述需求的变量行为的需求的定义被完全限定，并且其中所述至少一个较低级别需求使用所述分解需求的输入和返回参数作为其可监控和可控制的变量。

20.根据任何在前条项的介质，进一步包括将所述一组需求中的所述多个软件需求之间的所确定的从属性和测试边界的所述记录用于以下中的至少一个的指令：(i)优化测试程序中的测试步骤，以满足所述软件应用的需求测试覆盖范围；和(ii)生成可执行的测试程序，所述可执行的测试程序运用所述软件应用的外部输入和输出。