CN104182591A - 一种软件测试需求建模方法 - Google Patents
一种软件测试需求建模方法 Download PDFInfo
- Publication number
- CN104182591A CN104182591A CN201410444065.5A CN201410444065A CN104182591A CN 104182591 A CN104182591 A CN 104182591A CN 201410444065 A CN201410444065 A CN 201410444065A CN 104182591 A CN104182591 A CN 104182591A
- Authority
- CN
- China
- Prior art keywords
- test
- model
- testing requirement
- sut
- system under
- 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.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 32
- 238000012360 testing method Methods 0.000 claims abstract description 267
- 238000012795 verification Methods 0.000 claims abstract description 3
- 238000010586 diagram Methods 0.000 claims description 7
- 238000011990 functional testing Methods 0.000 claims description 5
- 230000004044 response Effects 0.000 claims description 5
- 238000003780 insertion Methods 0.000 claims description 4
- 230000037431 insertion Effects 0.000 claims description 4
- 230000005540 biological transmission Effects 0.000 claims description 3
- 230000008439 repair process Effects 0.000 claims description 3
- 230000008569 process Effects 0.000 description 9
- 238000013461 design Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 230000000007 visual effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000010998 test method Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 201000004569 Blindness Diseases 0.000 description 1
- 230000003542 behavioural effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 235000019580 granularity Nutrition 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 230000001502 supplementing effect Effects 0.000 description 1
Landscapes
- Debugging And Monitoring (AREA)
Abstract
提供一种软件测试需求建模方法，建立测试需求模型，在建立的测试需求模型中人为插入语义故障，对所述模型进行自动语义验证，通过建立的所述测试需求模型生成相应测试需求描述脚本，生成相应测试需求描述脚本对应的测试用例。所述方法为测试人员提供了简便有效的方式，实现高效自动化的测试，不仅能够提高测试人员的工作效率，还能够减少产品投入市场的时间。
Description
技术领域
本发明涉及计算机技术领域，具体涉及一种软件测试需求建模方法。
背景技术
在软件项目开发的过程中，测试在需求分析阶段就开始介入，不仅能帮助开发人员更有效地完善需求，也能让测试人员设计出更贴近需求的测试。同时，当需求进行了更改之后，测试人员也能及时和准确地了解需求的变化、更改测试需求。随着软件系统的复杂程度越来越高，如何有效地对软件系统进行测试成为了重点关注的问题。
发明内容
为了解决现有技术中存在的上述问题，实现本发明的目的，提出一种软件测试需求建模方法，包括：
S1.建立测试需求模型；
S2.在建立的测试需求模型中人为插入语义故障，对模型进行自动语义验证，如果验证通过，则进入步骤S3，否则返回步骤S1并报告相应错误；
S3.通过建立的所述测试需求模型生成相应测试需求描述脚本；
S4.生成相应测试需求描述脚本对应的测试用例。
特别地，所述建立测试需求模型包括建立测试需求元模型，所述测试需求元模型包括测试特征元模型、测试目标分组及描述元模型、基于被测系统用例的测试需求描述元模型、以及基于被测系统构件的测试需求描述元模型。
特别地，所述测试特征元模型包括测试特征的维度和测试约束。
其中，所述维度定义对测试特征进行度量的参数；当测试特征为系统函数的响应时间时，测所述参数包括函数一次执行的延迟、所有执行的平均延迟、和/或延迟时间的方差；当测试特征为被测系统可靠性时，所述参数包括需要修复时间和/或失效时间。
特别地，所述测试约束用于对与之相关联的测试特征的取值进行约束；
其中，测试约束包括OFFERED类型测试约束和REQUIRED类型的测试约束；所述OFFERED类型测试约束为测试系统自身需要满足的约束；所述REQUIRED类型的测试约束为被测系统的行为需满足的约束。
特别地，根据功能性测试、非功能性测试、和/或测试目标所涉及的功能模块将测试目标进行分组。
特别地，所述测试目标为测试系统与被测系统之间交互的消息序列；其中，所述消息序列包括发送消息、接收消息、拒绝消息；所述拒绝消息表示测试所不关心的消息，即不希望测试用例执行时测试系统会与被测系统就此消息进行交互。
特别地，所述基于被测系统构件的测试需求描述模型通过对被测系统相应的构件图进行标注，来描述测试需求中的被测软件实体EUT与测试端口。
特别地，所述基于被测系统用例的测试需求描述模型以被测系统的用例图为基础，根据测试目标分组及描述模型中定义的测试目标对相应的用例进行标注，向测试人员指明对此用例的测试对应于哪一测试目标。
实施本发明的有益效果是：所述方法为测试人员提供了简便有效的方式，实现高效自动化的测试，不仅能够提高测试人员的工作效率，还能够减少产品投入市场的时间。
附图说明
附图1为本发明提出的方法的流程图；
附图2为本发明提出的测试需求模型的应用场景图；
附图3为本发明提出的测试需求元模型；
附图4为本发明提出的测试特征元模型；
附图5为本发明提出的测试目标分组及描述元模；
附图6为本发明提出的基于被测系统构件的测试需求描述元模；
附图7为本发明提出的基于被测系统用例的测试需求描述元模型。
具体实施方式
下面结合附图对本发明的实施例进行详细说明。
本发明利用模型驱动的思想，定义了一种测试需求的元模型和测试需求建模方法，利用测试需求建模方法，可以得到测试需求模型，从而得到相应的测试目标，生成所对应的测试用例。
参见图1，图1示出了一种软件测试需求建模方法的流程图，包括如下步骤：
S1.建立测试需求模型；
S2.在建立的测试需求模型中人为插入语义故障，对模型进行自动语义验证，如果能够验证通过，则进入步骤S3，否则返回步骤S1并报告相应错误；
本步骤中，在测试需求模型中人为插入若干有代表性的语义故障以检测建立的所述测试需求模型能否自动识别。
S3.通过建立的所述测试需求模型生成相应测试需求描述脚本；
S4.生成相应测试需求描述脚本对应的测试用例。
参见图2，测试需求模型需要能够对测试需求进行可视化、无二义性的描述，因此该模型需要描述哪些方面是需要被测试的：模型需要具备严格的语法和语义，将测试需求和被测系统的功能以及性能需求对应。
该模型还需要是能够保证测试是完整的，这样可以通过模型检查的技术，来保证模型各部分具有一致性；测试需求模型能够指导测试的设计与测试用例的生成，这样使得测试需求具有可行性；测试需求模型还能建立起被测系统需求到测试设计的可追溯的关系。
测试需求元模型作为测试需求建模的基础，定义了测试需求模型中的各种核心概念以及核心概念之间的关系与依赖。本发明提出的实施方式提出的测试需求元模型如图3所示。如图所示，测试需求元模型主要分为4个部分：测试特征元模型(图3中的TestCharacteristicDiagram)、基于被测系统用例的测试需求描述元模型(图3中的UseCaseDiagram)、基于被测系统构件的测试需求描述元模型(图3中的SUTArchitecture)以及测试目标分组及描述元模型(图3中TestPurpose GroupDiagram)。上述模型分别从不同的方面对测试需求进行描述。这4个部分相对独立但又相互关联，对于完整的测试需求模型而言缺一不可。下面对上述模块的功能进行详细描述。
1.测试特征元模型
参见图4，测试特征的概念参考了OMG对服务质量特征的定义。测试特征(图4中的TestCharacteristic)是一组可定量表达的特性，独立于其所度量的具体元素。测试特征可以是对测试过程中被测系统行为特征的描述，如响应时间等，也可以用于描述测试系统自身的特征，如测试系统需模拟并发用户的数目以及测试数据选择策略等。
测试需求建模语言的设计使得建模人员可以将测试特征针对领域进行扩展，使得测试特征的核心内容不至于过于庞大，同时也可满足不同领域测试人员的需要。测试特征的维度(图4中的Dimension)是对测试特征描述进行量化表达的视角与方法。如当测试特征为某一系统函数的响应时间时，测试人员选择的度量方式可以是函数一次执行的延迟、所有执行的平均延迟或是延迟时间的方差。测试特征可以为若干不同维度的量化值，如被测系统可靠性这一测试特征，需要修复时间、失效时间等多维度度量方式。单一的量化值无法全面的对测试特征进行描述。因此测试特征维度的引入是十分必要的。
另外一个与测试特征密切相关的概念是测试约束。测试约束在测试目标分组与描述模型中用于对相应的测试目标进行约束。其具体内容将在后续文字中描述。
2.测试目标分组及描述元模型
参见图5，测试目标的规格说明需要具有一定的逻辑结构。在本发明提出的实施方式中，采用分组的方式对测试目标进行组织，例如可以通过区分测试目标(图5中的TestPurpose)为功能性测试还是非功能性测试、测试目标涉及哪个功能模块等方式将测试目标进行分组。对测试分组(图5中的TestGroup)的划分可以有不同的粒度，每个分组可以有自己的子分组，直至具体到相应的测试目标。
对于每一个测试目标，都需要对其进行相应的描述。测试目标是从执行某一特定的测试场景或者路径，或是验证特定需求的特性角度对测试用例的一个精确目标的描述。测试目标比测试用例更加抽象，更加简洁，更加清晰并独立于被测系统的设计与实现。本发明提出的实施方式中，对测试目标描述的定义参考了UML顺序图，采用类顺序图的形式来实现对测试目标的描述。
在本发明提出的实施方式中，测试目标实际上是测试人员所关注的测试系统与被测系统交互的消息序列，测试需求描述中的发送消息(图5中的SendMessage)与接收消息(图5中的ReceiveMessage)表示测试人员在本测试目标中所关注的消息序列，希望测试用例可以对其进行覆盖。而拒绝消息(图5中的RefuseRe ceiveMessage)表示测试人员所不关心的消息，即不希望测试用例执行时测试系统会与被测系统就此消息进行交互。同时，在测试需求描述中可以引入测试约束模型元素用于对测试目标进行约束。
再次参见图4，测试约束对与之相关联的测试特征(图4中的TestCharacteristic)的取值进行了约束。测试约束有两种类型(图5中的ConstraintConnectionType)，其中OFFERED类型为测试系统自身需要满足的约束，测试系统需满足此约束条件才能正确完成测试工作，如测试系统模拟的并发用户数目必须达到某一值，或测试系统提供的数据必须约束在某一特定区间之内。而REQUIRED类型的测试约束为被测系统的行为需满足的约束，如被测系统响应时间需小于某一确定值。
3.基于被测系统构件的测试需求描述元模型
参见图6，基于被测系统构件的测试需求描述模型通过对被测系统相应的构件图进行标注，来描述测试需求中的被测软件实体EUT与测试端口。对测试人员关注的构件(图6中Component)进行标注(图6中TestObjectEUT)表示此构件为被测软件实体，在后续的测试过程中需要对其进行相应测试；定义测试系统的端口(图6中TestObjectPort)用于标注相应的被测系统接口(图6中Interface)，并定义允许的输入消息类型与输出消息类型。
4.基于被测系统用例的测试需求描述元模型
用例图是一种基于场景的可视化表示方法，用来描述和论证系统大粒度的行为模式及其连接方式，它为高级的体系结构设计提供了系统行为框架并从体系结构的角度给系统行为赋予了一定的特征，测试人员利用它可以从较高的抽象层次来理解系统的行为。从用户的观点出发对系统建立模型是用例要完成的任务，一组用例就是从用户的角度出发对如何使用系统的描述。因此用例为测试提供了良好的基础。
基于被测系统用例的测试需求描述模型以被测系统的用例图为基础，如图7所示。根据测试目标分组及描述模型中定义的测试目标对相应的用例(图7中的UseCase)进行标注(图7中的TestPurposeForUseCase)，向测试人员指明对此用例的测试对应于哪一测试目标。通过测试目标生成相应的测试用例集之后，测试人员便可使用此测试用例集对用例进行相应测试。
总结
本发明提出的参考模型驱动测试的思想，定义了一种用于描述测试需求的可视化建模方法，用以对测试需求进行直观且无二义性的描述，作为测试活动的基础，对指导后续测试活动的开展具有重要意义。测试需求模型的引入是模型驱动测试方法学的完善和补充，在系统设计模型向测试设计模型的转换过程中，测试需求模型提供必要的信息，对转换过程起指导作用；同时，通过测试目标生成测试用例，避免了基于测试过程中通过某种覆盖准则生成测试用例的盲目性，实现了生成的测试用例向相应的被测系统需求的向上追溯，使得测试人员更好的对整个测试过程进行评估。
以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
Claims (9)
1.一种软件测试需求建模方法，其特征在于，包括：
S1.建立测试需求模型；
S2.在建立的测试需求模型中人为插入语义故障，对所述模型进行自动语义验证，如果验证通过，则进入步骤S3，否则返回步骤S1并报告相应错误；
S3.通过建立的所述测试需求模型生成相应测试需求描述脚本；
S4.生成相应测试需求描述脚本对应的测试用例。
2.如权利要求1所述方法，其特征在于：
所述建立测试需求模型包括建立测试需求元模型，所述测试需求元模型包括测试特征元模型、测试目标分组及描述元模型、基于被测系统用例的测试需求描述元模型、以及基于被测系统构件的测试需求描述元模型。
3.如权利要求2所述的方法，其特征在于：
所述测试特征元模型包括测试特征的维度和测试约束；
其中，所述维度定义对测试特征进行度量的参数；
所述测试约束用于对与之相关联的测试特征的取值进行约束。
4.如权利要去3所述的方法，其特征在于：
当测试特征为系统函数的响应时间时，所述参数包括函数一次执行的延迟、所有执行的平均延迟、和/或延迟时间的方差；当测试特征为被测系统可靠性时，所述参数包括需要修复时间和/或失效时间。
5.如权利要求3所述的方法，其特征在于：
所述测试约束包括OFFERED类型测试约束和REQUIRED类型的测试约束；所述OFFERED类型测试约束为测试系统自身需要满足的约束；所述REQUIRED类型的测试约束为被测系统的行为需满足的约束。
6.如权利要求2所述的方法，其特征在于：
根据功能性测试、非功能性测试、和/或测试目标所涉及的功能模块将测试目标进行分组。
7.如权利要去7所述的方法，其特征在于：
所述测试目标为测试系统与被测系统之间交互的消息序列；
其中，所述消息序列包括发送消息、接收消息、拒绝消息；所述拒绝消息是指不希望测试用例执行时测试系统与被测系统交互的消息。
8.如权利要求2所述的方法，其特征在于：
所述基于被测系统构件的测试需求描述模型通过对被测系统相应的构件图进行标注，来描述测试需求中的被测软件实体EUT与测试端口。
9.如权利要求2所述的方法，其特征在于：
所述基于被测系统用例的测试需求描述模型以被测系统的用例图为基础，根据测试目标分组及描述模型中定义的测试目标对相应的用例进行标注，向测试人员指明对此用例的测试对应于哪一测试目标。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410444065.5A CN104182591A (zh) | 2014-09-02 | 2014-09-02 | 一种软件测试需求建模方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410444065.5A CN104182591A (zh) | 2014-09-02 | 2014-09-02 | 一种软件测试需求建模方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN104182591A true CN104182591A (zh) | 2014-12-03 |
Family
ID=51963627
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410444065.5A Withdrawn CN104182591A (zh) | 2014-09-02 | 2014-09-02 | 一种软件测试需求建模方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104182591A (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105653443A (zh) * | 2015-12-21 | 2016-06-08 | 中电科航空电子有限公司 | 一种满足do-178c标准测试追溯目标的方法 |
| CN106446412A (zh) * | 2016-09-26 | 2017-02-22 | 杭州杉石科技有限公司 | 一种航空电子系统基于模型的测试方法 |
| CN106528100A (zh) * | 2015-08-05 | 2017-03-22 | 通用电气公司 | 用于安全关键软件开发的基于模型的技术和过程的系统和方法 |
| CN113934623A (zh) * | 2021-09-13 | 2022-01-14 | 北京控制工程研究所 | 一种基于特征表的测试脚本自动生成方法 |
-
2014
- 2014-09-02 CN CN201410444065.5A patent/CN104182591A/zh not_active Withdrawn
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106528100A (zh) * | 2015-08-05 | 2017-03-22 | 通用电气公司 | 用于安全关键软件开发的基于模型的技术和过程的系统和方法 |
| CN106528100B (zh) * | 2015-08-05 | 2020-06-09 | 通用电气公司 | 用于安全关键软件开发的基于模型的技术和过程的系统和方法 |
| CN105653443A (zh) * | 2015-12-21 | 2016-06-08 | 中电科航空电子有限公司 | 一种满足do-178c标准测试追溯目标的方法 |
| CN105653443B (zh) * | 2015-12-21 | 2018-05-11 | 中电科航空电子有限公司 | 一种满足do-178c标准测试追溯目标的方法 |
| CN106446412A (zh) * | 2016-09-26 | 2017-02-22 | 杭州杉石科技有限公司 | 一种航空电子系统基于模型的测试方法 |
| CN106446412B (zh) * | 2016-09-26 | 2019-12-06 | 杭州杉石科技有限公司 | 一种航空电子系统基于模型的测试方法 |
| CN113934623A (zh) * | 2021-09-13 | 2022-01-14 | 北京控制工程研究所 | 一种基于特征表的测试脚本自动生成方法 |
| CN113934623B (zh) * | 2021-09-13 | 2024-07-23 | 北京控制工程研究所 | 一种基于特征表的测试脚本自动生成方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10817409B2 (en) | System and method for testing software applications in a software defined network | |
| Baker et al. | Model-driven engineering in a large industrial context—Motorola case study | |
| CN104461810A (zh) | 一种提高嵌入式处理器功能验证效率的方法 | |
| WO2007001108A1 (en) | System for providing feature-oriented software product line engineering environment | |
| Savage et al. | IP Reuse in the System on a Chip Era | |
| CN104182591A (zh) | 一种软件测试需求建模方法 | |
| Nidagundi et al. | New method for mobile application testing using lean canvas to improving the test strategy | |
| Scippacercola et al. | Model-driven engineering of a railway interlocking system | |
| US20210027189A1 (en) | Method and Apparatus for Creating Tests for Execution in a Storage Environment | |
| US9619598B2 (en) | Input space reduction for verification test set generation | |
| Engels et al. | Model-based verification and validation of properties | |
| Aldalur et al. | A microservice-based framework for multi-level testing of cyber-physical systems | |
| Kerraoui et al. | MATT: multi agents testing tool based nets within nets | |
| US10031991B1 (en) | System, method, and computer program product for testbench coverage | |
| Nikiforova et al. | Towards a Business Process Model-based Testing of Information Systems Functionality. | |
| Sypsas et al. | Computing Similarities Between Virtual Laboratory Experiments Models Using Petri Nets | |
| Hilbrich et al. | Enforcing security and privacy via a cooperation of security experts and software engineers: a model-based vision | |
| US9886538B1 (en) | System and method for using heterogeneous hierarchical configurations for electronic design reuse | |
| CN110659215A (zh) | 一种开放式工业app快速开发及测试验证方法 | |
| Khatter et al. | Integration of non-functional requirements in model-driven architecture | |
| Bussenot et al. | A domain specific test language for systems integration | |
| Matsuura et al. | Automatic Verification of Behavior of UML Requirements Specifications using Model Checking. | |
| Jnanamurthy et al. | Formal specification at model-level of model-driven engineering using modelling techniques | |
| Kim | Hybrid model based testing for mobile applications | |
| Cherniltsev et al. | Review of network modeling and simulation software |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C04 | Withdrawal of patent application after publication (patent law 2001) | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20141203 |