WO2014115189A1 - Method and system for transforming specification scripts to program code - Google Patents

Method and system for transforming specification scripts to program code Download PDF

Info

Publication number
WO2014115189A1
WO2014115189A1 PCT/JP2013/000431 JP2013000431W WO2014115189A1 WO 2014115189 A1 WO2014115189 A1 WO 2014115189A1 JP 2013000431 W JP2013000431 W JP 2013000431W WO 2014115189 A1 WO2014115189 A1 WO 2014115189A1
Authority
WO
WIPO (PCT)
Prior art keywords
program code
sentence
storage means
scripts
system under
Prior art date
Application number
PCT/JP2013/000431
Other languages
French (fr)
Inventor
Chaiwat SATHAWORNWICHIT
Shigeru Hosono
Original Assignee
Nec Corporation
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 Nec Corporation filed Critical Nec Corporation
Priority to PCT/JP2013/000431 priority Critical patent/WO2014115189A1/en
Publication of WO2014115189A1 publication Critical patent/WO2014115189A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • 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

Definitions

  • This invention relates to a system, a method, and a program for transforming specification scripts to program code. More specifically, this invention relates to the transformation of specification written in a natural language to computer programs including test programs and system under test written in a programming language.
  • Software testing is the process of validating and verifying that a software product meets the requirements and specifications that lead to its design and development.
  • a software tester develops detailed knowledge of the software products by studying the product specification, identifies a set of features of the software product, and generates a number of test cases which are expected operations and results that the software product should satisfy under particular operating conditions. The tester then executes the software for each test case, compares the actual results with the expected results.
  • Unit tests cover low-level aspects of a system. For each module, we test whether each operation performs as expected. Integration Tests check whether modules work together correctly in combination. Requirements from users can be described by user stories. System tests are performed by the developers to ensure that all user stories have been implemented and function correctly. Lastly, acceptance tests performed by the users to check that delivered system meet their needs.
  • NPL Non Patent Literature 01
  • Agile software development is a methodology based on iterative and incremental development from design to working software product. At the end of every iteration, stakeholders review the working product, add or change requirements and specifications. Then, the development iterates from design to implementation and testing again.
  • Behavior-driven development [NPL 02] is an agile software development technique in which system behaviors are defined and described into test cases before the software itself is implemented.
  • BDD has some key ideas as following. No production code is written except to make a failing test pass.
  • the acceptance criteria for a user story should be specified by a test case and this test case should be written by the developer and customer together.
  • the tests should be automated so we are encouraged to run them all the time. These tests are called acceptance tests because they document what behaviors the customer will find acceptable in terms of the functionality of the system. Acceptance tests are higher-level constructs that can be used to guide developers down the path of writing unit tests that will get them to their goal. This encourages the customer to participate in a task they might otherwise skip.
  • BDD technique helps guide software developers to know what need to be tested as well as understanding what features need to be implemented to pass the tests. Its benefits also include a deeper understanding of user requirements in addition to making these requirements executable. In subsequent sections we describe a mode of operation of the present invention where BDD is used, however, it is not intended to limit to the use of BDD and this method can be applied to other techniques as well.
  • Patent Literature (PTL) 04 discloses a rule examination system.
  • PTL 05 discloses a program generating method.
  • the objective of the present invention is to provide a system, a method, and a program to solve the problem described above.
  • the above problems have been solved by a system, a method, and a program for transforming specification scripts into program code with parsing method that tagged the part of speech of each token and pattern matching method that matches tokens with pattern of labels that are tagged on the tokens, and transformation method that can transform program code with transformation rules that can generate anonymous instances to complement the implicit or incomplete information in the specification.
  • a system for transforming specification scripts to program includes specification storage means for storing specification scripts that describe specific behavior of the system under test written in a natural language, pattern storage means for storing patterns of labels which can be labeled onto constituents of a sentence in said specification scripts, transformation rule storage means for storing rules for transforming text to program code which describes test components and system under test, test components storage means for storing said program code of test components written in a programming language, system under test storage means for storing said program code of system under test written in a programming language, transformation means for transforming specification scripts to said program code which describes test components and system under test, wherein the transformation means further comprises script reading means for reading a specification scripts from the specification storage means, part of speech tagging means for tagging each word in a sentence by their part of speech, grammatical analyzing means for analyzing grammatical structure of a sentence to identify constituents of the sentence, and labeling each constituent of sentence, label sequence matching means for matching a sequence of labels of constituents to one or more
  • a method for transforming specification scripts to program code includes memorizing specification scripts that describe specific behavior of the system under test written in a natural language in specification script storage means, memorizing patterns of labels which can be labeled onto constituents of a sentence in said specification scripts, memorizing rules for transforming text to program code which describes test components and system under test written in a programming language in transformation rule storage means, reading specification scripts from the specification script storage means, tagging part of speech onto each word in a sentence by their part of speech, analyzing grammatical structure of a sentence to identify constituents of the sentence and, labeling each constituent of sentence with a defined set of labels, matching label sequence of labeled constituents to one or more transformation rules in the transformation rule storage means, generating code by applying transformation rules to transform the sentence to the program code of test components and system under test, memorizing program code of test components written in a programming language, memorizing program code of a system under test written in a programming language.
  • a program for transforming specification scripts to program code is a program installed in a computer connected to specification storage means for storing specification scripts that describe specific behavior of the system under test written in a natural language, pattern storage means for storing patterns of labels which can be labeled onto constituents of a sentence in said specification scripts, transformation rule storage means for storing rules for transforming text to program code which describes test components and system under test, test components storage means for storing said program code of test components written in a programming language, system under test storage means for storing said program code of system under test written in a programming language, the program causing the computer to perform: reading specification scripts from the specification script storage means, tagging part of speech onto each word in a sentence by their part of speech, analyzing grammatical structure of a sentence to identify constituents of the sentence and, labeling each constituent of sentence with a defined set of labels, matching label sequence of labeled constituents to one or more transformation rules in the transformation rule storage means, generating code by applying transformation rules to transform the sentence to the program
  • the effect of this invention is that the cost and effort for creating test programs for acceptance test are reduced.
  • the cost and effort for implementing system under tests are reduced.
  • the system development lifecycle can be shorten. The reason is because the present invention makes it possible to automatically generate not only stub but the logical part of test programs and its support code from specification written in natural language, and automatically generate the stub of class definition with the ability to suggest anonymous instance that is omitted or implicitly referred to in the specification.
  • FIG. 1(a) is a block diagram illustrating an embodiment of a system for transforming a language describing specification of a system into test components and the system under test, in accordance with the present invention.
  • FIG. 1(b) is a simplified block diagram illustrating an embodiment of the Transformation Module for performing the operation of the present invention.
  • FIG. 2 depicts a flow chart which outlines the steps of the methods involved in transforming specification described in a language into test components and system under test, in accordance with an embodiment of the present invention.
  • FIG. 3 is a block diagram illustrating an embodiment of test components comprising test programs and support code for the test programs.
  • FIG. 4 illustrates an example of transformation rule R01 with two transformation procedures.
  • FIG. 5 shows the result of the transformation by transformation rule R01.
  • FIG. 1(b) is a simplified block diagram illustrating an embodiment of the Transformation Module for performing the operation of the present invention.
  • FIG. 2 depicts a flow chart which outlines the steps of the methods involved in transforming specification described in a language into test
  • FIG. 6(a) illustrates an example of a specification script.
  • FIG. 6(b) illustrates an example of a class Account, a part of the SUT for which the transformation in accordance with the present invention is performed.
  • FIG. 6(c) illustrates an example of a resulting test program in part, for which the transformation in accordance with the present invention is performed.
  • FIG. 6(d) illustrates an example of a resulting support code in part, for which the transformation in accordance with the present invention is performed.
  • FIG.7 shows examples of tags and labels.
  • FIG.8 shows an example of parsing and tagging.
  • FIG.9 shows an example of a pattern and a matched input.
  • the system 100 includes a specification storage unit 102, a pattern storage unit 106, a transformation rule storage unit 108, a transformation module 104, a test components storage unit 110, and a system under test storage unit 112.
  • the specification scripts 103 are a set of text descriptions that define acceptance criteria of the system under test.
  • the text description in a specification script defines the behavior of the system under test for an acceptance criterion in a scenario.
  • the specification scripts 103 are stored in the specification storage unit 102.
  • a specification script can be created manually by entering text description into a text editor.
  • a specification script may be written in any languages or domain specific languages that can be processed by the transformation module 104.
  • An example of a specification script written in Gherkin language is shown in FIG. 6(a).
  • the specification script shown in FIG. 6(a) can be divided into three parts, namely, feature, scenario, and steps.
  • a feature is used to group a set of test scenarios.
  • a scenario comprises of steps.
  • a step is a specific behavior of the system written in a natural language such as plain English.
  • a specification script includes a single feature. Every feature starts with keyword "Feature:”, followed by title and description.
  • a feature contains a set of scenarios. Every scenario starts with keyword “Scenario:”, followed by feature title.
  • Each scenario includes a list of steps known as “Givens, Whens, and Thens”, that start with one of the keywords "Given”, “When”, “Then”, “And”, or “But”. The description in "Given” steps defines a pre-condition state of the system in a scenario.
  • the description of "When” steps defines an action that triggers the state transition, if any.
  • the description of "Then” steps defines a post-condition state or outcome of the system in a scenario.
  • the "Given” step set up the balance in "my account”
  • the "When” step trigger a “withdraw” action
  • the "Then” and “And” steps specifies an outcome that the specified amount of $20 withdrawn should be dispensed and a post-condition that the balance of "my account” becomes $80.
  • the test components 111 are the program code that may comprise of one or more software modules that are capable of interacting with the system under test 113 to drive a test scenario. That is to setup pre-condition state of the scenario, trigger the operations to be performed by the scenario, and verify the output or post-condition state of the scenario. For example, to verify a proper behavior of a scenario withdrawing money from a bank account using an ATM, the test components 111 may comprise of a software module that setups the account to be withdrawn, trigger the sequences of withdrawal operations to be performed, and verify the amount of cash dispensed and remaining balance of the account.
  • test components 111 in FIG. 1(a) is shown in more detail in FIG. 3.
  • the test components 111 as shown in FIG. 3 includes test programs 302 and support code 304.
  • the test programs 302 are the code for executing test logic.
  • the support code 304 is the code for creating and preparing the objects that are used by the test programs.
  • the test programs 302 and support code 304 are generated by transformation from specification scripts 103 by the transformation module 104.
  • the test components 111 may be stored in a test component storage unit 110.
  • a system under test (SUT) 113 is the program code of an application, being implemented to meet the specification, written in a programming language. It is the target for testing with test components 111 and may be stored in a SUT storage unit 112.
  • FIG. 6(b) illustrates an example of the program code of a class "Account” written in Ruby programming language, which is a part of the system under test for a banking application.
  • test programs 302, support code 304, and system under test 113 may be generated automatically in part from specification scripts 103 by the transformation module 104 and then modified as appropriated with a text editor.
  • the patterns 107 are sequences of labels, sequences of text, or sequences of arbitrary objects to be matched with an input sequence.
  • the patterns 107 may be stored in the pattern storage unit 106.
  • the patterns 107 may be stored as a database or files on a file system.
  • Transformation rules 109 are rules for generating test programs, support code, and system under test from the text description. Transformation rules 109 may be stored in the transformation rule storage unit 108.
  • the transformation modules 104 is the module capable of transforming specification scripts 103 to program code in test programs 302, support code 304, and system under test 113 by matching patterns as in 107 and using transformation rules as in 109.
  • the transformation modules 104 may be referred to as an transformation unit.
  • the transformation modules 104 in FIG.1(a) is shown as in FIG.1(b).
  • the transformation modules 104 includes a script reader 502, a part of speech tagger 504, a grammatical analyzer 506, a label sequence matcher 508, and a code generator 510.
  • the script reader 502 reads the specification script 103 from the specification storage unit 102.
  • the script reader 502 may be referred to as a script reading unit.
  • the part of speech tagger 504 tags each word in a sentence by their part of speech.
  • the part of speech tagger 504 may be referred to as a part of speech tagging unit.
  • the grammatical analyzer 506 analyzes grammatical structure of a sentence, identifies constituents of the sentence and labels each constituent of the sentence.
  • the grammatical analyzer 506 puts a label to each constituent(part of a sentence), not each word.
  • FIG.7 shows examples of tags and labels.
  • the grammatical analyzer 506 may be referred to as an grammatical analyzing unit.
  • the label sequence matcher 508 matches a sequence of labels of the constituents to one or more transformation rules in the transformation rule in the transformation rule storage unit 108.
  • the label sequence matcher 508 may be referred to as an label sequence matching unit.
  • the code generator 510 generates the test components and system under test.
  • the code generator 510 includes an anonymous instance managing module 512 and a writing module 514.
  • the anonymous instance managing module 512 generates a class of an anonymous instance including in such class are the methods and the attributes which are referred by the anonymous instance written in a programming language.
  • An anonymous instance is an instance that is undefined but likely exists implied from the specification scripts.
  • the anonymous instance managing module 512 may be referred to as an anonymous instance managing unit.
  • the writing module 514 writes the test components to the test components storage unit 110. And the writing module 514 writes the system under test to the system under test storage unit 112.
  • the writing module 514 may be referred to as writing unit.
  • the transformation module 104 shown in FIG.1(b) is implemented, for example, by a CPU in a computer that operates in accordance with a program for transforming specification scripts to program code.
  • the program may be stored in a computer readable information recording medium.
  • FIG. 2 outlines the steps of methods involved in transforming specification described in a language into test components and system under test, in accordance with an embodiment of the present invention.
  • the transforming process starts in step 404 by reading a specification script 402 from the specification storage unit 102 in order to transform the specification script.
  • the script reader 502 reads the specification script 402.
  • the specification scripts 402 may be, for instance, written in English and follow the syntax of the Gherkin language, so that it can be processed by Cucumber, a BDD testing tool [NPL 02].
  • An example of a specification script written in Gherkin is shown in FIG. 6(a).
  • Constituent is a word or phrase or clause forming part of a larger grammatical construction.
  • Grammatical construction is a group of words that form a constituent of a sentence and are considered as a single unit. Constituents are labeled, and word are tagged, in the present invention.
  • Part of speech (POS) tagging simplifies the task of defining what the whole sentence is because there are grammatical relationships between constituents, and there are techniques that segment a sentence into semantic groupings that form meaningful units.
  • the sentence 406 read by previous step is tagged by the part of speech (POS) tagger 504.
  • the specification script includes one scenario of a feature and one or more of "Given", "When", and "Then” steps that specify the test scenario.
  • the POS tagger 504 tags each word in the sentence.
  • the sequence of tagged words 410 is to be used for sentence structure analysis in the next step 412.
  • An example of tags that are tagged on each word may be a predefined set of tags that identify the part of speech of the token, as shown in FIG.8.
  • FIG.8 shows an example of parsing and tagging a line of Given step.
  • the input a line of a Given step, is parsed and tagged by tags which identify the part or speech of the token.
  • the parsing result is shown in the sequence of tagged words.
  • the words are shown in a form of "[ ⁇ word>: ⁇ tag>]" (See FIG.8).
  • step 412 the sequence of POS-tagged words is analyzed grammatically by the grammatical analyzer 506.
  • Grammatical construction is a group of words that form a constituent of a sentence and are considered as a single meaningful unit. Constituent is a word or phrase or clause forming part of a larger grammatical construction.
  • the grammatical analyzer 506 analyzes the sequence of POS-tagged words to determine grammatical sentence structure and identify the constituents which form the sentence structure as, for examples, actor (subject), action (verb) and target (direct object, indirect objects), etc., and then labels each constituent 414.
  • the label sequence matcher 508 matches the sequence of labels 414 with a pattern 107 stored in the pattern storage unit 106.
  • the result of matching method in step 416 is one or more transformation rules to be applied next for the matched pattern in step 420.
  • An example of matching pattern of labels is shown in FIG.9. Given that pattern P01 (See FIG.9) is a pattern in the pattern storage unit 106 and input is the sequence of tagged tokens from the previous example (See FIG.8).
  • the matching method matches the input with pattern P01 to a transformation rule, says, R01 as a result.
  • the resulting transformation rule R01 (See FIG.4) is to be referred and applied to the input in step 420 to transform and generate program code.
  • the code generator 510 generates the program code of the components 111 and the system under test 113. Parts of code are generated by executing the transformation procedures that are matched to transformation rules.
  • each line of the input sentences is applied the transformation rule 418 to which it is matched in step 416 in order to generate program code of the test components 111 and system under test 113.
  • a transformation rule in the transformation rule storage unit 109 defines one or more transformation procedures which specifies how terms in the input are transformed to program code written following the syntax of a programming language.
  • a transformation procedure may be a function that generates program code from input terms.
  • An example of a transformation rule and transforming process is shown as follow. Given that the input is the sequence of tagged tokens from the previous example (See FIG.8) and transformation rule R01 is a rule in the transformation rule storage that is the result of matching.
  • the transformation rule R01 in this example defines two transformation procedures, TP1(transformation procedure 1) and TP2(transformation procedure 2).
  • Placeholders are denoted in the form " ⁇ placeholder>".
  • Placeholders are defined optionally for readability purpose.
  • Each of the transformation procedures defines 3 functions for generating program code: (1) Function "generate_code_of_test_program” generates code that triggers the test logic.
  • the generated code is to be a part of test programs.
  • Function "generate_code_of_SUT” generates code of template class definition of the instance that is referred by the code generated from function "generate_code_of_test_program”. The generated code is to be a part of the SUT.
  • Function generates code that constructs the instance that is referred by the code generated from function "generate_support_code”. The generated code is to be a part of the support code.
  • the result of program code generated by transformation procedure TP1 and TP2 is shown.
  • the code "my_account.deposit( 100 )" is generated as the logic for test programs.
  • the class definition of "class account” is generated including the method “deposit” assuming that "my_account” is an instance of class “account”.
  • the support code that constructs the instance "my_account” is generated as "account.new". A system developer can use this result to begin the programming very quickly.
  • the result of transformation procedure TP2 in FIG. 5 shows a feature of anonymous instance that the methods of this invention provide.
  • the action “deposit” may be taken upon an instance of ATM instead of the instance "my_account", but ATM is not mentioned in the input so an anonymous instance which refers to an ATM is created.
  • the code “_anonymous_instance_01.deposit_in( my_account, 100 )” is generated as the logic for test programs.
  • the "_anonymous_instance_01" suggests the missing of an ATM in the specification.
  • the class definition "Class_of_anonymous_instance_01 account” is generated including the method “deposit_in” assuming that "_anonymous_instance_01" is an instance of "Class_of_anonymous_instance_01". Also, the support code that constructs the instance "_anonymous_instance_01” is generated as "Class_of_anonymous_instance_01.new”. The developer can use this result to begin the programming very quickly. A system developer can use this result to realize the missing of ATM and edit the code to turn "Class_of_anonymous_instance_01" it to the class definition of ATM.
  • Anonymous instances are created by the anonymous instance managing module 512.
  • the result of code generation in step 420 is program code for test components 111 including test program 302 and support code 304 and program code for system under test 113.
  • the method iterates to step 404 to process next specification script, if exists.
  • the transforming method ends when all specification scripts are processed.
  • FIG. 6(c) An example of a resulting test program from the transformation method is shown in FIG. 6(c) where the program code that drives test logic is a result of transformation of the "Given" step of the specification script in FIG. 6(a) is illustrated in part.
  • An example of a resulting support code from the transformation method is shown in FIG. 6(d).
  • the support code creates the instances referred by the generated test program.
  • the writing module 514 writes the test components to the test components storage unit 110. And the writing module 514 writes the system under test to the system under test storage unit 112.
  • the invention can be used for automatically generating test programs from specification artifacts for acceptance testing.
  • the invention can be used for aiding and guiding the development of computer software.
  • the invention can be used for automating the testing of computer software, especially but not limited to agile software development.
  • Transformation module 106 Pattern storage unit 108 Transformation rule storage unit 110 Test components storage unit 112 System under test storage unit 502 Script reader 504 Part of speech tagger 506 Grammatical analyzer 508 Label sequence matcher 510 Code generator 512 Anonymous instance managing module 514 Writing module

Abstract

The objective of the present invention is to reduce the cost and effort for system development. The part of speech tagger 504 tags each word in a sentence by their part of speech. The grammatical analyzer 506 analyzes grammatical structure of a sentence, identifies constituents of the sentence and labels each constituent of the sentence. The label sequence matcher 508 matches a sequence of labels of the constituents to one or more transformation rules. The code generator 510 generates the test components and system under test.

Description

METHOD AND SYSTEM FOR TRANSFORMING SPECIFICATION SCRIPTS TO PROGRAM CODE
This invention relates to a system, a method, and a program for transforming specification scripts to program code. More specifically, this invention relates to the transformation of specification written in a natural language to computer programs including test programs and system under test written in a programming language.
Software testing is the process of validating and verifying that a software product meets the requirements and specifications that lead to its design and development. In general software testing, a software tester develops detailed knowledge of the software products by studying the product specification, identifies a set of features of the software product, and generates a number of test cases which are expected operations and results that the software product should satisfy under particular operating conditions. The tester then executes the software for each test case, compares the actual results with the expected results. Unit tests cover low-level aspects of a system. For each module, we test whether each operation performs as expected. Integration Tests check whether modules work together correctly in combination. Requirements from users can be described by user stories. System tests are performed by the developers to ensure that all user stories have been implemented and function correctly. Lastly, acceptance tests performed by the users to check that delivered system meet their needs.
Requirements of a system change often in early phase and become more stable when the software moves towards completion. Recently, agile software development [Non Patent Literature (NPL) 01] has been widely adopted to cope with changes in requirements and to encourage fast delivery of software product. Agile software development is a methodology based on iterative and incremental development from design to working software product. At the end of every iteration, stakeholders review the working product, add or change requirements and specifications. Then, the development iterates from design to implementation and testing again.
Behavior-driven development (BDD) [NPL 02] is an agile software development technique in which system behaviors are defined and described into test cases before the software itself is implemented. BDD has some key ideas as following. No production code is written except to make a failing test pass. The acceptance criteria for a user story should be specified by a test case and this test case should be written by the developer and customer together. The tests should be automated so we are encouraged to run them all the time. These tests are called acceptance tests because they document what behaviors the customer will find acceptable in terms of the functionality of the system. Acceptance tests are higher-level constructs that can be used to guide developers down the path of writing unit tests that will get them to their goal. This encourages the customer to participate in a task they might otherwise skip.
BDD technique helps guide software developers to know what need to be tested as well as understanding what features need to be implemented to pass the tests. Its benefits also include a deeper understanding of user requirements in addition to making these requirements executable. In subsequent sections we describe a mode of operation of the present invention where BDD is used, however, it is not intended to limit to the use of BDD and this method can be applied to other techniques as well.
Patent Literature (PTL) 04 discloses a rule examination system.
PTL 05 discloses a program generating method.
US 5586020 US7992139 B2 US 7805714 B2 Japanese Patent Application Laid-Open No.2005-56183 Japanese Patent Application Laid-Open No.004-140834
Robert Cecil Martin, Agile Software Development: Principles, Patterns, and Practices, Prentice Hall PTR, 2003 The Cucumber Book: Behavior-Driven Development for Testers and Developers, Pragmatic Bookshelf, 2012
Software development typically begins from identifying specification of the system to be developed from customers' requirements. Specification artifacts, created to establish an agreement between customers and system developers, are written in natural language such as plain English. This specification is suitable to be used for acceptance testing, which is to guarantee that customers' requirements have been met and the system is acceptable. Therefore, specification artifacts should be used to guide software developers on (a) how to test the system in order to accept the system, and (b) what need to be implemented for the system in order to pass the tests.
However, the technical problem is that specification cannot be used directly to execute or drive tests in acceptance testing, because they are written in natural language which is not executable. System developers read specification artifacts and manually develop test code and implement system under test based on their understanding. Manually creating test programs this way is inefficient and takes a lot of time and effort of developers or testers.
Converting specification written in a natural language into program stubs has been made possible by related arts. However, converting specification written in natural language into executable logic is a problem because the specification written in natural language such as English is not restricted by any syntactical rules other than English grammar. This makes it difficult to transform a sentence to executable program code. Moreover, specification written in natural language is context sensitive which means there are incomplete or implicitly implied information in most sentences or phrases.
The objective of the present invention is to provide a system, a method, and a program to solve the problem described above.
In accordance with the present invention, the above problems have been solved by a system, a method, and a program for transforming specification scripts into program code with parsing method that tagged the part of speech of each token and pattern matching method that matches tokens with pattern of labels that are tagged on the tokens, and transformation method that can transform program code with transformation rules that can generate anonymous instances to complement the implicit or incomplete information in the specification.
A system for transforming specification scripts to program according to the present invention includes specification storage means for storing specification scripts that describe specific behavior of the system under test written in a natural language, pattern storage means for storing patterns of labels which can be labeled onto constituents of a sentence in said specification scripts, transformation rule storage means for storing rules for transforming text to program code which describes test components and system under test, test components storage means for storing said program code of test components written in a programming language, system under test storage means for storing said program code of system under test written in a programming language, transformation means for transforming specification scripts to said program code which describes test components and system under test, wherein the transformation means further comprises script reading means for reading a specification scripts from the specification storage means, part of speech tagging means for tagging each word in a sentence by their part of speech, grammatical analyzing means for analyzing grammatical structure of a sentence to identify constituents of the sentence, and labeling each constituent of sentence, label sequence matching means for matching a sequence of labels of constituents to one or more transformation rules in the transformation rule storage means, code generating means for applying the matched rules to transform the sentence to the program code of test components and system under test.
A method for transforming specification scripts to program code according to the present invention includes memorizing specification scripts that describe specific behavior of the system under test written in a natural language in specification script storage means, memorizing patterns of labels which can be labeled onto constituents of a sentence in said specification scripts, memorizing rules for transforming text to program code which describes test components and system under test written in a programming language in transformation rule storage means, reading specification scripts from the specification script storage means, tagging part of speech onto each word in a sentence by their part of speech, analyzing grammatical structure of a sentence to identify constituents of the sentence and, labeling each constituent of sentence with a defined set of labels, matching label sequence of labeled constituents to one or more transformation rules in the transformation rule storage means, generating code by applying transformation rules to transform the sentence to the program code of test components and system under test, memorizing program code of test components written in a programming language, memorizing program code of a system under test written in a programming language.
A program for transforming specification scripts to program code according to the present invention is a program installed in a computer connected to specification storage means for storing specification scripts that describe specific behavior of the system under test written in a natural language, pattern storage means for storing patterns of labels which can be labeled onto constituents of a sentence in said specification scripts, transformation rule storage means for storing rules for transforming text to program code which describes test components and system under test, test components storage means for storing said program code of test components written in a programming language, system under test storage means for storing said program code of system under test written in a programming language, the program causing the computer to perform: reading specification scripts from the specification script storage means, tagging part of speech onto each word in a sentence by their part of speech, analyzing grammatical structure of a sentence to identify constituents of the sentence and, labeling each constituent of sentence with a defined set of labels, matching label sequence of labeled constituents to one or more transformation rules in the transformation rule storage means, generating code by applying transformation rules to transform the sentence to the program code of test components and system under test, memorizing program code of test components written in a programming language in the test components storage means, memorizing program code of a system under test written in a programming language in the system under test storage means.
The effect of this invention is that the cost and effort for creating test programs for acceptance test are reduced. The cost and effort for implementing system under tests are reduced. The system development lifecycle can be shorten. The reason is because the present invention makes it possible to automatically generate not only stub but the logical part of test programs and its support code from specification written in natural language, and automatically generate the stub of class definition with the ability to suggest anonymous instance that is omitted or implicitly referred to in the specification.
FIG. 1(a) is a block diagram illustrating an embodiment of a system for transforming a language describing specification of a system into test components and the system under test, in accordance with the present invention. FIG. 1(b) is a simplified block diagram illustrating an embodiment of the Transformation Module for performing the operation of the present invention. FIG. 2 depicts a flow chart which outlines the steps of the methods involved in transforming specification described in a language into test components and system under test, in accordance with an embodiment of the present invention. FIG. 3 is a block diagram illustrating an embodiment of test components comprising test programs and support code for the test programs. FIG. 4 illustrates an example of transformation rule R01 with two transformation procedures. FIG. 5 shows the result of the transformation by transformation rule R01. FIG. 6(a) illustrates an example of a specification script. FIG. 6(b) illustrates an example of a class Account, a part of the SUT for which the transformation in accordance with the present invention is performed. FIG. 6(c) illustrates an example of a resulting test program in part, for which the transformation in accordance with the present invention is performed. FIG. 6(d) illustrates an example of a resulting support code in part, for which the transformation in accordance with the present invention is performed. FIG.7 shows examples of tags and labels. FIG.8 shows an example of parsing and tagging. FIG.9 shows an example of a pattern and a matched input.
While the invention is susceptible to various modifications and alternative forms, a preferred embodiment thereof is shown by way of example in the drawings and will be described herein by detail. It should be understood, however, that it is not intended to limit the invention to the particular form disclosed, but on contrary, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the accompanying claims.
Referring to FIG. 1(a), there shown is a block diagrams illustrating an embodiment of a system for transforming specification into test components and system under test in accordance with the present invention. The system 100 includes a specification storage unit 102, a pattern storage unit 106, a transformation rule storage unit 108, a transformation module 104, a test components storage unit 110, and a system under test storage unit 112.
The specification scripts 103 are a set of text descriptions that define acceptance criteria of the system under test. The text description in a specification script defines the behavior of the system under test for an acceptance criterion in a scenario. The specification scripts 103 are stored in the specification storage unit 102. A specification script can be created manually by entering text description into a text editor.
A specification script may be written in any languages or domain specific languages that can be processed by the transformation module 104. An example of a specification script written in Gherkin language is shown in FIG. 6(a). The specification script shown in FIG. 6(a) can be divided into three parts, namely, feature, scenario, and steps. A feature is used to group a set of test scenarios. A scenario comprises of steps. A step is a specific behavior of the system written in a natural language such as plain English.
In the following, with reference to the example in FIG. 6(a) explanation will be made on the specification script. The claimed invention, however, is not limited to the use of the language shown in the example, and can be applied to other forms known by those skilled in the art. A specification script includes a single feature. Every feature starts with keyword "Feature:", followed by title and description. A feature contains a set of scenarios. Every scenario starts with keyword "Scenario:", followed by feature title. Each scenario includes a list of steps known as "Givens, Whens, and Thens", that start with one of the keywords "Given", "When", "Then", "And", or "But". The description in "Given" steps defines a pre-condition state of the system in a scenario. The description of "When" steps defines an action that triggers the state transition, if any. The description of "Then" steps defines a post-condition state or outcome of the system in a scenario. In the example, the "Given" step set up the balance in "my account", the "When" step trigger a "withdraw" action, the "Then" and "And" steps specifies an outcome that the specified amount of $20 withdrawn should be dispensed and a post-condition that the balance of "my account" becomes $80.
The test components 111 are the program code that may comprise of one or more software modules that are capable of interacting with the system under test 113 to drive a test scenario. That is to setup pre-condition state of the scenario, trigger the operations to be performed by the scenario, and verify the output or post-condition state of the scenario. For example, to verify a proper behavior of a scenario withdrawing money from a bank account using an ATM, the test components 111 may comprise of a software module that setups the account to be withdrawn, trigger the sequences of withdrawal operations to be performed, and verify the amount of cash dispensed and remaining balance of the account.
An embodiment of test components 111, in FIG. 1(a) is shown in more detail in FIG. 3. The test components 111 as shown in FIG. 3 includes test programs 302 and support code 304. The test programs 302 are the code for executing test logic. The support code 304 is the code for creating and preparing the objects that are used by the test programs. The test programs 302 and support code 304 are generated by transformation from specification scripts 103 by the transformation module 104. The test components 111 may be stored in a test component storage unit 110.
A system under test (SUT) 113 is the program code of an application, being implemented to meet the specification, written in a programming language. It is the target for testing with test components 111 and may be stored in a SUT storage unit 112. FIG. 6(b) illustrates an example of the program code of a class "Account" written in Ruby programming language, which is a part of the system under test for a banking application.
The program code of test programs 302, support code 304, and system under test 113 may be generated automatically in part from specification scripts 103 by the transformation module 104 and then modified as appropriated with a text editor.
The patterns 107 are sequences of labels, sequences of text, or sequences of arbitrary objects to be matched with an input sequence. The patterns 107 may be stored in the pattern storage unit 106. The patterns 107 may be stored as a database or files on a file system.
Transformation rules 109 are rules for generating test programs, support code, and system under test from the text description. Transformation rules 109 may be stored in the transformation rule storage unit 108.
The transformation modules 104 is the module capable of transforming specification scripts 103 to program code in test programs 302, support code 304, and system under test 113 by matching patterns as in 107 and using transformation rules as in 109. The transformation modules 104 may be referred to as an transformation unit.
The transformation modules 104 in FIG.1(a) is shown as in FIG.1(b). The transformation modules 104 includes a script reader 502, a part of speech tagger 504, a grammatical analyzer 506, a label sequence matcher 508, and a code generator 510.
The script reader 502 reads the specification script 103 from the specification storage unit 102. The script reader 502 may be referred to as a script reading unit.
The part of speech tagger 504 tags each word in a sentence by their part of speech. The part of speech tagger 504 may be referred to as a part of speech tagging unit.
The grammatical analyzer 506 analyzes grammatical structure of a sentence, identifies constituents of the sentence and labels each constituent of the sentence. The grammatical analyzer 506 puts a label to each constituent(part of a sentence), not each word. FIG.7 shows examples of tags and labels. The grammatical analyzer 506 may be referred to as an grammatical analyzing unit.
The label sequence matcher 508 matches a sequence of labels of the constituents to one or more transformation rules in the transformation rule in the transformation rule storage unit 108. The label sequence matcher 508 may be referred to as an label sequence matching unit.
The code generator 510 generates the test components and system under test. The code generator 510 includes an anonymous instance managing module 512 and a writing module 514.
The anonymous instance managing module 512 generates a class of an anonymous instance including in such class are the methods and the attributes which are referred by the anonymous instance written in a programming language. An anonymous instance is an instance that is undefined but likely exists implied from the specification scripts. The anonymous instance managing module 512 may be referred to as an anonymous instance managing unit.
The writing module 514 writes the test components to the test components storage unit 110. And the writing module 514 writes the system under test to the system under test storage unit 112. The writing module 514 may be referred to as writing unit.
The transformation module 104 shown in FIG.1(b) is implemented, for example, by a CPU in a computer that operates in accordance with a program for transforming specification scripts to program code. The program may be stored in a computer readable information recording medium.
Referring to FIG. 2, FIG. 2 outlines the steps of methods involved in transforming specification described in a language into test components and system under test, in accordance with an embodiment of the present invention. The transforming process starts in step 404 by reading a specification script 402 from the specification storage unit 102 in order to transform the specification script. In step 404, the script reader 502 reads the specification script 402. The specification scripts 402 may be, for instance, written in English and follow the syntax of the Gherkin language, so that it can be processed by Cucumber, a BDD testing tool [NPL 02]. An example of a specification script written in Gherkin is shown in FIG. 6(a).
Parts of a sentence are called constituents. Constituent is a word or phrase or clause forming part of a larger grammatical construction. Grammatical construction is a group of words that form a constituent of a sentence and are considered as a single unit. Constituents are labeled, and word are tagged, in the present invention.
Part of speech (POS) tagging simplifies the task of defining what the whole sentence is because there are grammatical relationships between constituents, and there are techniques that segment a sentence into semantic groupings that form meaningful units.
Further, in step 408, the sentence 406 read by previous step is tagged by the part of speech (POS) tagger 504. In particular, the specification script includes one scenario of a feature and one or more of "Given", "When", and "Then" steps that specify the test scenario. As such, the POS tagger 504 tags each word in the sentence. The sequence of tagged words 410 is to be used for sentence structure analysis in the next step 412. An example of tags that are tagged on each word may be a predefined set of tags that identify the part of speech of the token, as shown in FIG.8. FIG.8 shows an example of parsing and tagging a line of Given step.
The input, a line of a Given step, is parsed and tagged by tags which identify the part or speech of the token. The parsing result is shown in the sequence of tagged words. The words are shown in a form of "[<word>:< tag>]" (See FIG.8).
Next, in step 412, the sequence of POS-tagged words is analyzed grammatically by the grammatical analyzer 506. Grammatical construction is a group of words that form a constituent of a sentence and are considered as a single meaningful unit. Constituent is a word or phrase or clause forming part of a larger grammatical construction. The grammatical analyzer 506 analyzes the sequence of POS-tagged words to determine grammatical sentence structure and identify the constituents which form the sentence structure as, for examples, actor (subject), action (verb) and target (direct object, indirect objects), etc., and then labels each constituent 414. Next, in step 416, the label sequence matcher 508 matches the sequence of labels 414 with a pattern 107 stored in the pattern storage unit 106. The result of matching method in step 416 is one or more transformation rules to be applied next for the matched pattern in step 420. An example of matching pattern of labels is shown in FIG.9. Given that pattern P01 (See FIG.9) is a pattern in the pattern storage unit 106 and input is the sequence of tagged tokens from the previous example (See FIG.8).
The matching method matches the input with pattern P01 to a transformation rule, says, R01 as a result. The resulting transformation rule R01 (See FIG.4) is to be referred and applied to the input in step 420 to transform and generate program code.
Next, in step 420, the code generator 510 generates the program code of the components 111 and the system under test 113. Parts of code are generated by executing the transformation procedures that are matched to transformation rules. In step 420, each line of the input sentences is applied the transformation rule 418 to which it is matched in step 416 in order to generate program code of the test components 111 and system under test 113. In particular, a transformation rule in the transformation rule storage unit 109 defines one or more transformation procedures which specifies how terms in the input are transformed to program code written following the syntax of a programming language. A transformation procedure may be a function that generates program code from input terms. An example of a transformation rule and transforming process is shown as follow. Given that the input is the sequence of tagged tokens from the previous example (See FIG.8) and transformation rule R01 is a rule in the transformation rule storage that is the result of matching.
Referring to FIG. 4, the transformation rule R01 in this example defines two transformation procedures, TP1(transformation procedure 1) and TP2(transformation procedure 2). For readability, we first define placeholders to be substituted by terms in the input. Placeholders are denoted in the form "<placeholder>". For example, "<action>" is substituted by the term "deposit" of "[verb]", "<indirect-object>" is substituted by the term "my_account" of "[possessive-pronoun]_[noun]", and so on. Placeholders are defined optionally for readability purpose. Each of the transformation procedures defines 3 functions for generating program code:
(1) Function "generate_code_of_test_program" generates code that triggers the test logic. The generated code is to be a part of test programs.
(2) Function "generate_code_of_SUT" generates code of template class definition of the instance that is referred by the code generated from function "generate_code_of_test_program". The generated code is to be a part of the SUT.
(3) Function generates code that constructs the instance that is referred by the code generated from function "generate_support_code". The generated code is to be a part of the support code.
These functions take input terms as shown with the placeholders and define output of program code they generate by substituting the placeholders with input terms.
Referring to FIG. 5, the result of program code generated by transformation procedure TP1 and TP2 is shown. In the result of transformation procedure TP1, the code "my_account.deposit( 100 )" is generated as the logic for test programs. For the SUT, the class definition of "class account" is generated including the method "deposit" assuming that "my_account" is an instance of class "account". Also, the support code that constructs the instance "my_account" is generated as "account.new". A system developer can use this result to begin the programming very quickly.
The result of transformation procedure TP2 in FIG. 5 shows a feature of anonymous instance that the methods of this invention provide. In a sentence of specification script written in natural language, it is possible to omit or implicitly imply a subject that takes an action or an object that an action is taken upon. For example, the action "deposit" may be taken upon an instance of ATM instead of the instance "my_account", but ATM is not mentioned in the input so an anonymous instance which refers to an ATM is created. Referring to the result of transformation procedure TP2, the code "_anonymous_instance_01.deposit_in( my_account, 100 )" is generated as the logic for test programs. The "_anonymous_instance_01" suggests the missing of an ATM in the specification. For the SUT, the class definition "Class_of_anonymous_instance_01 account" is generated including the method "deposit_in" assuming that "_anonymous_instance_01" is an instance of "Class_of_anonymous_instance_01". Also, the support code that constructs the instance "_anonymous_instance_01" is generated as "Class_of_anonymous_instance_01.new". The developer can use this result to begin the programming very quickly. A system developer can use this result to realize the missing of ATM and edit the code to turn "Class_of_anonymous_instance_01" it to the class definition of ATM.
Anonymous instances are created by the anonymous instance managing module 512.
The result of code generation in step 420 is program code for test components 111 including test program 302 and support code 304 and program code for system under test 113. When the transformation in step 420 of a specification script is done, the method iterates to step 404 to process next specification script, if exists. The transforming method ends when all specification scripts are processed. An example of a resulting test program from the transformation method is shown in FIG. 6(c) where the program code that drives test logic is a result of transformation of the "Given" step of the specification script in FIG. 6(a) is illustrated in part. An example of a resulting support code from the transformation method is shown in FIG. 6(d). The support code creates the instances referred by the generated test program.
The writing module 514 writes the test components to the test components storage unit 110. And the writing module 514 writes the system under test to the system under test storage unit 112.
While the invention has been illustrated and described in the drawings, foregoing descriptions and examples, such illustration and description is to be considered as exemplary for illustrative purposes only, it being understood that only the preferred embodiment and minor variants thereof have been shown and described and that all changes and modifications that come within the spirit of the invention are desired to be protected.
The invention can be used for automatically generating test programs from specification artifacts for acceptance testing. The invention can be used for aiding and guiding the development of computer software. The invention can be used for automating the testing of computer software, especially but not limited to agile software development.
102 Specification storage unit
104 Transformation module
106 Pattern storage unit
108 Transformation rule storage unit
110 Test components storage unit
112 System under test storage unit
502 Script reader
504 Part of speech tagger
506 Grammatical analyzer
508 Label sequence matcher
510 Code generator
512 Anonymous instance managing module
514 Writing module

Claims (6)

  1. A system for transforming specification scripts to program code comprising:
    specification storage means for storing specification scripts that describe specific behavior of the system under test written in a natural language,
    pattern storage means for storing patterns of labels which can be labeled onto constituents of a sentence in said specification scripts,
    transformation rule storage means for storing rules for transforming text to program code which describes test components and system under test,
    test components storage means for storing said program code of test components written in a programming language,
    system under test storage means for storing said program code of system under test written in a programming language,
    transformation means for transforming specification scripts to said program code which describes test components and system under test,
    wherein the transformation means further comprises
    script reading means for reading a specification scripts from the specification storage means,
    part of speech tagging means for tagging each word in a sentence by their part of speech,
    grammatical analyzing means for analyzing grammatical structure of a sentence to identify constituents of the sentence, and labeling each constituent of sentence,
    label sequence matching means for matching a sequence of labels of constituents to one or more transformation rules in the transformation rule storage means,
    code generating means for applying the matched rules to transform the sentence to the program code of test components and system under test.
  2. A system for transforming specification scripts to program code according to claim1,
    code generating means further includes
    anonymous instance managing means for generating a class of an anonymous instance including in such class are the methods and the attributes which are referred by the anonymous instance written in a programming language.
  3. A method for transforming specification scripts to program code comprising:
    memorizing specification scripts that describe specific behavior of the system under test written in a natural language in specification script storage means,
    memorizing patterns of labels which can be labeled onto constituents of a sentence in said specification scripts,
    memorizing rules for transforming text to program code which describes test components and system under test written in a programming language in transformation rule storage means,
    reading specification scripts from the specification script storage means,
    tagging part of speech onto each word in a sentence by their part of speech,
    analyzing grammatical structure of a sentence to identify constituents of the sentence and, labeling each constituent of sentence with a defined set of labels,
    matching label sequence of labeled constituents to one or more transformation rules in the transformation rule storage means,
    generating code by applying transformation rules to transform the sentence to the program code of test components and system under test,
    memorizing program code of test components written in a programming language,
    memorizing program code of a system under test written in a programming language.
  4. A method for transforming specification scripts to program code according to claim3, further comprising,
    generating a class of an anonymous instance including in such class are the methods and the attributes which are referred by the anonymous instance written in a programming language.
  5. A program for transforming specification scripts to program code, installed in a computer connected to specification storage means for storing specification scripts that describe specific behavior of the system under test written in a natural language, pattern storage means for storing patterns of labels which can be labeled onto constituents of a sentence in said specification scripts, transformation rule storage means for storing rules for transforming text to program code which describes test components and system under test, test components storage means for storing said program code of test components written in a programming language, system under test storage means for storing said program code of system under test written in a programming language,
    the program causing the computer to perform:
    reading specification scripts from the specification script storage means,
    tagging part of speech onto each word in a sentence by their part of speech,
    analyzing grammatical structure of a sentence to identify constituents of the sentence and, labeling each constituent of sentence with a defined set of labels,
    matching label sequence of labeled constituents to one or more transformation rules in the transformation rule storage means,
    generating code by applying transformation rules to transform the sentence to the program code of test components and system under test,
    memorizing program code of test components written in a programming language in the test components storage means,
    memorizing program code of a system under test written in a programming language in the system under test storage means.
  6. A program for transforming specification scripts to program code according to claim 5,
    the program further causing the computer to perform:
    generating a class of an anonymous instance including in such class are the methods and the attributes which are referred by the anonymous instance written in a programming language.
PCT/JP2013/000431 2013-01-28 2013-01-28 Method and system for transforming specification scripts to program code WO2014115189A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/000431 WO2014115189A1 (en) 2013-01-28 2013-01-28 Method and system for transforming specification scripts to program code

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/000431 WO2014115189A1 (en) 2013-01-28 2013-01-28 Method and system for transforming specification scripts to program code

Publications (1)

Publication Number Publication Date
WO2014115189A1 true WO2014115189A1 (en) 2014-07-31

Family

ID=47741224

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/000431 WO2014115189A1 (en) 2013-01-28 2013-01-28 Method and system for transforming specification scripts to program code

Country Status (1)

Country Link
WO (1) WO2014115189A1 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2542687A (en) * 2015-08-05 2017-03-29 Gen Electric System and method for model based technology and process for safety-critical software development
WO2017142546A1 (en) * 2016-02-19 2017-08-24 Hewlett Packard Enterprise Development Lp Natural language programming tool
US9892025B2 (en) 2015-02-19 2018-02-13 Red Hat, Inc. Using script description to encode conditional statements
CN109446100A (en) * 2018-11-12 2019-03-08 郑州云海信息技术有限公司 The method and apparatus of the script file of management equipment
US10372597B2 (en) 2017-05-03 2019-08-06 International Business Machines Corporation Software testing and verification
WO2020076726A1 (en) * 2018-10-10 2020-04-16 T-Mobile Usa, Inc. Zero coding automation with natural language processing, such as for use in testing telecommunications software and resources
CN112328226A (en) * 2020-09-17 2021-02-05 北京中数科技术有限公司 Embedded system automatic test code generation method and device
CN113051173A (en) * 2021-04-13 2021-06-29 广州虎牙科技有限公司 Test flow arrangement execution method and device, computer equipment and storage medium
US11494161B2 (en) * 2017-02-14 2022-11-08 Jong Sik Yoon Coding system and coding method using voice recognition
CN116166567A (en) * 2023-04-23 2023-05-26 成都华兴汇明科技有限公司 Test case generation method and device based on graphic programming

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04140834A (en) 1990-10-02 1992-05-14 Hitachi Ltd Program generating method and specifications input method therefor
US5586020A (en) 1994-02-23 1996-12-17 Nec Corporation Program transformation processing system and method
JP2005056183A (en) 2003-08-05 2005-03-03 Nec Corp Rule checking system, device, method, and program
US7765097B1 (en) * 2006-03-20 2010-07-27 Intuit Inc. Automatic code generation via natural language processing
US7805714B2 (en) 2005-03-30 2010-09-28 Alcatel-Lucent Usa Inc. Technique for constructing syntax-directed search and modifications in program transformation systems
US7992139B2 (en) 2006-11-29 2011-08-02 International Business Machines Corporation Method, system and program product for transforming a single language program into multiple language programs
WO2011098677A1 (en) * 2010-02-10 2011-08-18 Telys System and a method for managing and compiling a software development application framework

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04140834A (en) 1990-10-02 1992-05-14 Hitachi Ltd Program generating method and specifications input method therefor
US5586020A (en) 1994-02-23 1996-12-17 Nec Corporation Program transformation processing system and method
JP2005056183A (en) 2003-08-05 2005-03-03 Nec Corp Rule checking system, device, method, and program
US7805714B2 (en) 2005-03-30 2010-09-28 Alcatel-Lucent Usa Inc. Technique for constructing syntax-directed search and modifications in program transformation systems
US7765097B1 (en) * 2006-03-20 2010-07-27 Intuit Inc. Automatic code generation via natural language processing
US7992139B2 (en) 2006-11-29 2011-08-02 International Business Machines Corporation Method, system and program product for transforming a single language program into multiple language programs
WO2011098677A1 (en) * 2010-02-10 2011-08-18 Telys System and a method for managing and compiling a software development application framework

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"The Cucumber Book: Behavior-Driven Development for Testers and Developers", 2012, PRAGMATIC BOOKSHELF,
AGUNG FATWANTO: "Software requirements translation from natural language to object-oriented model", CONTROL, SYSTEMS&INDUSTRIAL INFORMATICS (ICCSII), 2012 IEEE CONFERENCE ON, IEEE, 23 September 2012 (2012-09-23), pages 191 - 195, XP032335933, ISBN: 978-1-4673-1022-2, DOI: 10.1109/CCSII.2012.6470499 *
MATHIAS LANDHÄUSSER ET AL: "Connecting User Stories and code for test development", 2012 THIRD INTERNATIONAL WORKSHOP ON RECOMMENDATION SYSTEMS FOR SOFTWARE ENGINEERING (RSSE), June 2012 (2012-06-01), pages 33 - 37, XP055079959, ISBN: 978-1-46-731758-0, DOI: 10.1109/RSSE.2012.6233406 *
MATHIAS SOEKEN ET AL: "Assisted Behavior Driven Development Using Natural Language Processing", 29 May 2012, OBJECTS, MODELS, COMPONENTS, PATTERNS, SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 269 - 287, ISBN: 978-3-642-30560-3, XP047004825 *
ROBERT CECIL MARTIN: "Agile Software Development: Principles, Patterns, and Practices", 2003, PRENTICE HALL PTR

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9892025B2 (en) 2015-02-19 2018-02-13 Red Hat, Inc. Using script description to encode conditional statements
US10346140B2 (en) 2015-08-05 2019-07-09 General Electric Company System and method for model based technology and process for safety-critical software development
GB2542687A (en) * 2015-08-05 2017-03-29 Gen Electric System and method for model based technology and process for safety-critical software development
WO2017142546A1 (en) * 2016-02-19 2017-08-24 Hewlett Packard Enterprise Development Lp Natural language programming tool
US11494161B2 (en) * 2017-02-14 2022-11-08 Jong Sik Yoon Coding system and coding method using voice recognition
US10372597B2 (en) 2017-05-03 2019-08-06 International Business Machines Corporation Software testing and verification
US11068382B2 (en) 2017-05-03 2021-07-20 International Business Machines Corporation Software testing and verification
US11726903B2 (en) 2018-10-10 2023-08-15 T-Mobile Usa, Inc. Zero coding automation with natural language processing, such as for use in testing telecommunications software and resources
WO2020076726A1 (en) * 2018-10-10 2020-04-16 T-Mobile Usa, Inc. Zero coding automation with natural language processing, such as for use in testing telecommunications software and resources
US11106570B2 (en) 2018-10-10 2021-08-31 T-Mobile Usa, Inc. Zero coding automation with natural language processing, such as for use in testing telecommunications software and resources
CN109446100A (en) * 2018-11-12 2019-03-08 郑州云海信息技术有限公司 The method and apparatus of the script file of management equipment
CN112328226A (en) * 2020-09-17 2021-02-05 北京中数科技术有限公司 Embedded system automatic test code generation method and device
CN113051173A (en) * 2021-04-13 2021-06-29 广州虎牙科技有限公司 Test flow arrangement execution method and device, computer equipment and storage medium
CN113051173B (en) * 2021-04-13 2024-04-19 广州虎牙科技有限公司 Method, device, computer equipment and storage medium for arranging and executing test flow
CN116166567B (en) * 2023-04-23 2023-08-11 成都华兴汇明科技有限公司 Test case generation method and device based on graphic programming
CN116166567A (en) * 2023-04-23 2023-05-26 成都华兴汇明科技有限公司 Test case generation method and device based on graphic programming

Similar Documents

Publication Publication Date Title
WO2014115189A1 (en) Method and system for transforming specification scripts to program code
US9038026B2 (en) System and method for automating test automation
Wang et al. Automatic generation of acceptance test cases from use case specifications: an nlp-based approach
US20130239098A1 (en) Source code conversion method and source code conversion program
Yue et al. An automated approach to transform use cases into activity diagrams
US20090307664A1 (en) Generating a transition system for use with model checking
Yue et al. RTCM: a natural language based, automated, and practical test case generation framework
Carvalho et al. Model-based testing from controlled natural language requirements
MacDonald et al. Model-driven development within a legacy system: an industry experience report
US10970449B2 (en) Learning framework for software-hardware model generation and verification
Kamalakar et al. Automatically generating tests from natural language descriptions of software behavior
Marko et al. Combining xtext and oslc for integrated model-based requirements engineering
Pantelic et al. A toolset for Simulink: Improving software engineering practices in development with Simulink
Sims et al. Experience report: the reactis validation tool
Brahmi et al. Industrial use of a safe and efficient formal method based software engineering process in avionics
Breunesse et al. Specifying and verifying a decimal representation in Java for smart cards
Iqbal et al. Exhaustive simulation and test generation using fuml activity diagrams
Wassyng et al. Software tools for safety-critical software development
Gupta et al. A keyword-driven tool for testing Web applications (KeyDriver)
Sarmiento-Calisaya et al. Towards the improvement of natural language requirements descriptions: the C&L tool
Lang et al. Translating FSP into LOTOS and Networks of Automata
Nikiforova et al. Towards a Business Process Model-based Testing of Information Systems Functionality.
Autili et al. Towards a graphical tool for refining user to system requirements
US9514032B2 (en) Real-time usage checking of dynamically generated program output
Duarte et al. Extraction of probabilistic behaviour models based on contexts

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13705265

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13705265

Country of ref document: EP

Kind code of ref document: A1