WO1998027490A1 - Systeme et procede de commande du processus de test d'un logiciel - Google Patents

Systeme et procede de commande du processus de test d'un logiciel Download PDF

Info

Publication number
WO1998027490A1
WO1998027490A1 PCT/US1997/020401 US9720401W WO9827490A1 WO 1998027490 A1 WO1998027490 A1 WO 1998027490A1 US 9720401 W US9720401 W US 9720401W WO 9827490 A1 WO9827490 A1 WO 9827490A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
release
load
control system
software
Prior art date
Application number
PCT/US1997/020401
Other languages
English (en)
Inventor
David F. Carrier, Iii
R. John K. Gillespie
Janet Kwai Fun Lui
Donald L. Weeks, Jr.
Original Assignee
Alcatel Usa Sourcing, L.P.
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 Alcatel Usa Sourcing, L.P. filed Critical Alcatel Usa Sourcing, L.P.
Priority to AU52503/98A priority Critical patent/AU5250398A/en
Publication of WO1998027490A1 publication Critical patent/WO1998027490A1/fr

Links

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Definitions

  • This invention is related in general to the field of computer software systems. More particularly, the invention is related to a software testing process control system and method.
  • some engineers may be coding source modules for version 3.1 of a software product X, while some engineers may be incorporating newer features into source modules for version 4.0, and still some engineers may be providing a fix to some problems reported in source modules of version 2.1. Note that it is possible to have overlap between the three groups of engineers, so that an engineer may be involved in all three efforts.
  • Compounding the problem is the fact that each version of a software product must pass through multiple developmental stages prior to its release, where advancing to the next stage requires the passing of some predetermined testing and approval process.
  • To be tested some or all the source modules for . that version of the software product must be collected and built into a load.
  • the process of load building is also called compiling and linking of all the source modules.
  • the resultant load or build is the software product to be tested or to be delivered to the customers when all the developmental stages have been passed.
  • the test inputs or test cases must be tailored to the specific version and release of the load being tested or directed toward specific fixes or features that were incorporated into the load.
  • apparatus and method for software testing control that automates and stream lines the process.
  • apparatus and method for software testing control are provided which eliminates or substantially reduces the disadvantages associated with prior systems and methods .
  • a software test process control method has the steps of receiving and storing check-in data related to test cases checked into a version control system, and tagging the test cases with a unique label indicative of a specific version and release of a software product.
  • the load built from source modules of the software product and the tagged test cases are then downloaded to a test device.
  • an automated method for software file release with test process control having the steps of receiving and storing check- in data related to source modules checked into a version control system, and receiving and storing check- in data related to test cases checked into the version control system.
  • the source modules are then tagged with a unique label indicative of a specific version and release of a software product, and the test cases are also tagged with the unique label.
  • a load is then built from the tagged source modules and the load and the tagged test cases are downloaded to a test device for testing.
  • the system includes test cases having data input for testing a load checked into a version control system.
  • a test controller is adapted for tagging the test cases with a unique label indicative of a specific version and release of a software product, for downloading the load and tagged test cases to a test device, and for receiving test results from the test device and storing the test results in a predetermined directory in the version control system.
  • FIGURE 1 is a simplified block diagram of an exemplary software release control system constructed according to the teachings of the present invention
  • FIGURES 2A and 2B are an exemplary flowchart of a software release control process according to the teachings of the present invention.
  • FIGURE 3 is a block diagram illustrating the software release control process
  • FIGURE 4 is a diagram illustrating the users of software release control system
  • FIGURE 5 is an exemplary flowchart of a process to attach source modules to release forms
  • FIGURE 6 is an exemplary flowchart of a process to assign release forms to a build
  • FIGURE 7 is an exemplary flowchart of a create new product process
  • FIGURE 8 is an exemplary flowchart of a process to create a build
  • FIGURE 9 is an exemplary flowchart of a process for defect tracking
  • FIGURE 10 is a block diagram illustrating defect tracking
  • FIGURE 11 is a simplified block diagram of a remote access to software release control system
  • FIGURE 12 is a simplified block diagram of a software testing control system according to the teachings of the present invention.
  • FIGURES 1-12 a block diagram of a software release control system 10 constructed according to the teachings of the present invention is shown.
  • Software release control system 10 uses a version control subsystem 12 to manage the numerous versions of software modules or files developed by software engineers.
  • Version control subsystem 12 may be coupled to software release control system 10 and a number of workstations, personal computers, terminals, or any suitable data display and entry device 14, via a computer network 16.
  • version control subsystem 12 At least two databases or files are included in version control subsystem 12 - source files 18 for storing source modules being developed or modified, and third party files 20 for storing source modules of third party software that will be incorporated into the load.
  • versions control subsystem 12 generally keeps track of what changes were made to the file. Examples of available version control subsystems include ClearCase by Pure Atria Software of Shaumburg, Illinois; Control Version System by Free Software Foundation of Cambridge, Massachusetts; DSEE by Hewlett Packard of Palo Alto, California.
  • Another data display and entry device 22 provided for configuration administrator (s) , who has authority to initiate and oversee the load building process.
  • Problem reporting tool 24 is used to record problems reported by customers, test engineers, and other sources. Each problem report is assigned a unique problem report number for tracking and auditing purposes.
  • Software release control system 10 includes a number of tools, including a load builder 30 and a defect tracker 32.
  • a number of files or databases are also included for storing a variety of data: check-in data 40, approved files 42, deferred files 44, submitted files 46, load list 50, and build report 52.
  • Check-in data database 40 stores records associated with source modules that have been checked into version control subsystem 12.
  • Check-in data 40 may include the developer's name, file name, check-in number, product, release, check-in time, total number of lines, number of lines changed, etc.
  • Approved files database 42 stores data associated with source modules that have received approval for inclusion into a build
  • deferred files database 44 stores data associated with source modules that have been denied inclusion into a build.
  • Submitted files database 46 stores data associated with those source modules that have been attached to release forms. Release forms are logical groupings of source modules collected and submitted for the build process.
  • Load list file 50 contains a list of built modules and third party software that have been identified to go onto deliverable media. The load list is used during generation of the deliverable media.
  • Build report database 52 stores data generated from the load building process. Hard copy reports may then be generated from data stored in build report database 52.
  • a load After a load is built, it may be downloaded to a portable storage medium 60, such as a tape 62 and compact disc 64. Storage medium 60 containing a load may then be tested on a test bed 66. In addition, the load may be electronically transferred to a remote site 68, via telecommunications networks or computer networks, for operations and/or testing.
  • a portable storage medium 60 such as a tape 62 and compact disc 64.
  • Storage medium 60 containing a load may then be tested on a test bed 66.
  • the load may be electronically transferred to a remote site 68, via telecommunications networks or computer networks, for operations and/or testing.
  • FIGURES 2A and 2B is a flowchart describing the process of software release control 100. References may also be made to various system components shown in FIGURE 1 and to the diagram in FIGURE 3 providing an illustration of the process.
  • a user typically a software engineer engaged in the development, modification, or testing of software code, logs into system 10 and selects a software product from a displayed list of existing or developing software products, as shown in block 102. If the source module that the engineer desires to work on is already checked into version control subsystem 12, then it is checked out therefrom, as shown in block 104. The engineer then codes or modifies the source module, as shown in block 106. At the end of the work session, the source module is checked back into version control subsystem 12 in block 108. When a source module is checked into version control subsystem 12, a trigger sends check- in data to software release control system 10, as shown in block 110. This check-in process is shown in FIGURE 3, where source modules 160 are checked into version control subsystem 12 and causing triggers to be invoked and received by software release control system 10.
  • the check-in data are stored by software release control system 10. If the source module is completed, then its associated check-in data may be attached to open release form 166 and 168, as shown in block 116 and illustrated in FIGURE 3.
  • a release form is a logical grouping of check-in data associated with source modules checked into version control subsystem 12.
  • a release form is typically associated with a particular problem report number or feature specification documentation number.
  • the source modules associated therewith are developed or modified in response to the problem reported.
  • the source modules associated therewith are typically developed for a new release.
  • Software release control system 10 preferably provides a graphical and menu-driven user interface for prompting for data entry and displaying options.
  • the user may select from a list of possible functions related to release forms, such as listing of currently open release forms, creating a new release form, attaching check-in data to a release form, submitting a release form, etc .
  • a pointing device such as a mouse may be used to select the desired option from the list.
  • the user may select the appropriate option, which brings up a list of currently open release forms for selection. The selection of a release form then causes a list of unattached check-in data for the software product in question that are associated with the particular user.
  • an electronic notification message may be automatically generated and sent to designated personnel having the responsibility of assigning and approving submitted release form(s) to a particular build, such as a configuration administrator.
  • the configuration administrator may then assign the release form to a build and approve the build, as shown in block 122.
  • the release forms are sorted according to approval - those release forms approved for a build and those release forms not approved for a build, as shown in blocks 124 and 126.
  • the release forms not approved for a build may be deferred for a later build, and the associated data are stored, as shown in block 128.
  • release forms may also be disapproved or rejected for a number of reasons, which may be unsubmitted or deleted from system 10 after a predetermined time period.
  • the approved release forms are then provided in a list, which is used to tag or label all source modules 160 stored in database 18 that are to be included in build 170, as shown in block 132 and FIGURE 3.
  • the build label identifies the product, version, and build in which the tagged source modules will be incorporated.
  • System 10 further provides for the permanent identification 171 of versions of source modules 160 with a specific build 170 of a product.
  • a configuration administrator may initiate a build after all necessary release forms have been submitted, approved, assigned, and tagged.
  • Software release control system 10 first retrieves source modules that bear the appropriate build label from version control subsystem 12, as shown in block 134, and also retrieves any third party software from version control subsystem 12, as shown in block 136.
  • a build script is then invoked and executed to compile and link the source modules, third party software, and any other files necessary for the execution of the resultant software product, as shown in block 138.
  • the built load may be in any one of development stages 176: development, integration test, system test, verification, and field deployment, and is so identified in its load number or part number identifier.
  • a load number may indicate, sequentially, the customer identifier, part number, release, point release, maintenance release, feature release, development state V, and version number.
  • Development state V may indicate the verification stage, for example.
  • the build may then be downloaded to a portable storage medium for delivery to a customer, electronically transferred to a desired destination for delivery or testing, or downloaded to a test bed for testing purposes.
  • a build report summarizing information related to the build may also be generated. It may be seen that software release control system 10 preferably provides a number of security levels to users having differing needs and assigned tasks. Referring to FIGURE 4, users 200 of system 10 may be assigned roles, such as system 202, administration 204, manager 206, and regular 208.
  • regular users 208 may have access to those functions related to creating release forms, attaching the source modules to release forms, and submitting release forms.
  • Manager users 206 may have the additional ability to assign release forms to builds for those software products for which they have authorization during selected development stages, such as development and integration test.
  • Administration users 204 may additionally have access to build administration functions, such as initiating the tagging source modules with build labels and specifying third party software.
  • System users 202 may have unrestricted access to all resources.
  • FIGURE 5 provides additional details on an exemplary process to attach a source module to a release form 220.
  • the user may select one or more release forms, as shown in block 222.
  • a listing of source modules associated with the user and checked into version control subsystem 12 are then displayed for the user's selection, as shown in block 224.
  • the user is prompted to provide certain predetermined information, such as whether a preliminary inspection, for example Fagan inspection, was performed and date of the inspection, as shown in block 226.
  • the user will also be prompted to enter problem report number (s) or feature specification document number (s) associated with the source module, as shown in block 228.
  • Software release control system 10 then groups the selected source module with the selected release form.
  • the attachment process ends in block 230.
  • a list of release forms submitted for a given product is displayed, as shown in block 242.
  • the user such as build administrator, selects a release form from the list, as shown in block 244.
  • details of check-in data associated with the selected release form are then displayed, so that the user may review the details and indicate his/her approval, as shown in block 248.
  • an electronic message may be generated and sent to the developer (s) associated with the source modules so that appropriate action may be taken, as shown in block 250.
  • a list of builds for the selected software product is displayed, as shown in block 254. The user may then select the build that will incorporate the approved release form, as shown in block 256.
  • the process ends in block 258 thereafter.
  • system 10 prompts for the product identifier and release number, as shown in block 272.
  • a sequence number and a build index number are then set by system 10, as shown in blocks 274 and 276. For example, sequence number may be set to 1 and the build index number may be set to 0.
  • the process ends in block 278.
  • error messages may be displayed.
  • FIGURE 8 shows an exemplary process for creating a new build 290.
  • the screen displays a prompt for the user to identify the owner of the build, as shown in block 292.
  • system 10 queries and obtains from the check-in database information on software products and previous builds known to be related to the owner identifier entered by the user, as shown in block 294.
  • the result is displayed for the user to select the software product and a build, as shown in block 296.
  • Dependencies such as operating system and environment variables which specify certain values to be used in the build are either copied from an existing build and modified or entered by the user for the new build, as shown in block 298. Other information such as specifying third party software may also be entered at this time.
  • a build label for the new build is then generated, based on the information given, as shown in block 300.
  • the create new build process ends in block 302.
  • FIGURE 1 An exemplary process 320 performed by defect tracker 32 (FIGURE 1) is shown in FIGURE 9. References are also made to FIGURE 10, which provides a graphical illustration of the process.
  • a product and a build are first specified or selected from lists displayed by system 10, as shown in blocks 322 and 324. With this information, defect tracker 32 obtains a list of all check-in data of all source modules associated with the selected build and product, as shown in block 326. Problem report numbers that are specified in the check- in data are then obtained, as shown in block 328. As identified by the problem report numbers, those problem reports stored in problem reporting tool 24
  • FIGURE 1 are labeled with the build label of the present build, as shown in block 330. It may be seen in FIGURE 10 that source module check- in data 360 and 362, a release form 364 that includes check-in data 360 and 362, and load 366 are all tagged with a build label 370-376. In determining which check-in data and correspondingly, which source module contains the code for fixing a known defect, a problem report number 384 associated with check-in data 360 is used to identify a problem report 368 with the problem report number identifier 380. Problem report 368 is then tagged with a build label 388 that corresponds to load 366. Therefore, the proper association between a load and problem report (s) is made.
  • FIGURE 11 shows that a software release control system 400 may also be accessed from a site 410 located remotely from system 400.
  • Software release control system 400 includes a load builder 401, a defect tracker 402, and a database 403, which stores a number of files as described above in conjunction with FIGURE 1.
  • a version control subsystem 404 having a database storing source files 405 is coupled to system 400.
  • a workstation 406 may also be coupled to system 400 to provide administrator access thereto.
  • a second version control subsystem 411 storing source files 412 generated and/or maintained by software engineers at remote site 410 is provided.
  • Version control subsystem 411 is coupled to developer workstations, personal computers, and other suitable tools 416 which facilitate code development.
  • a software engineer checks in source modules to remote version control subsystem 411, which are then stored in source files database 412.
  • a trigger is invoked and sent to software release control system 400. Similar to the local site application as shown in FIGURE 1, the trigger includes check-in data.
  • the trigger may be transmitted over telecommunications networks, computer networks, or a dedicated line, as deemed suitable.
  • packets containing the contents of source files database 412 are electronically copied to source files database 405 of local version control subsystem 404 to synchronize the databases, so that the contents thereof are essentially identical over time.
  • a user When a user has completed the source modules, he/she may attach them to one or more release forms and then submit the release forms for a build, in the same manner as described above.
  • release forms When release forms are approved for a build, the corresponding source modules stored in remote source files database 412 that make up the release form are tagged with the appropriate build label.
  • the load building process obtains approved files or source modules from remote version control subsystem 411 to build the load. Defect tracking for the remote site is performed in a similar manner as described above, where a build label becomes associated with problem reports. Constructed in this manner, developers may submit source files from one or more remote sites to one local software release control system for load building and defect tracking.
  • System 510 includes a load builder 530 described in detail above, and additionally a test controller 532.
  • Compiled and linked source modules and other files generated during the load building process are stored in a build directory 544 at the end of the load building process.
  • Build directory 544 functions as a staging area for downloading the files to deliverable storage media (not shown) , or test devices 560 such as a desk top test machine 562, or an automated test driver 564 that drives testing executed on a test bed 566.
  • System 510 further includes test cases 540 and project file documents 542.
  • Project file documents 542 may include a number of documents that are associated with the software product under development and testing.
  • project file documents 542 may include meeting minutes, engineering specification documents, engineering memoranda, test cases 540, test reports 550, and build documents, some of which are shown explicitly in FIGURE 12, some are not.
  • Test cases 540 are test inputs and test reports 550 are the result or output of the tests.
  • Build report and build log 552 were generated during the load building process, where the build log records events, messages, actions, and results during the build process, and the build report is a summary of selected information from the build log.
  • Project file documents 542 are stored in version control subsystem 12, of which test cases 520 are shown explicitly.
  • test controller 532 downloads the built load from build directory 544 and test cases 540 to test device 560.
  • desk top test machine 562 is used to test portions of the software product, and automated test driver 564 and test bed 566 are used to test the entire software product.
  • Test device 560 may be co-located with system 510 or may be located remotely in which the transfer of the load and test cases 540 may be done electronically via a computer or telecommunications network. Test device 560 receives the load and test cases 540 and performs the test or tests. Results of the tests are sent back to test controller 532 and checked into version control subsystem 12. Typically, test reports 550 are stored at predetermined locations or subdirectories in project file documents 542.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

Un système et un procédé (510) de commande du processus de test d'un logiciel comprennent un dispositif de commande (532) de test qui reçoit des tests élémentaires (540) enregistrés dans un système (12) de contrôle de version. Les tests élémentaires sont étiquetés avec une étiquette unique qui indique une version spécifique et la version d'un produit logiciel. Une charge construite à partir de modules sources du produit logiciel et les tests élémentaires étiquetés (540) sont ensuite transférés à un dispositif de test. Les résultats (550) des tests sont reçus et enregistrés dans le système (12) de contrôle de version puis mis en mémoire dans un répertoire prédéterminé (442).
PCT/US1997/020401 1996-12-18 1997-11-07 Systeme et procede de commande du processus de test d'un logiciel WO1998027490A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU52503/98A AU5250398A (en) 1996-12-18 1997-11-07 Software testing process control system and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US76922596A 1996-12-18 1996-12-18
US08/769,225 1996-12-18

Publications (1)

Publication Number Publication Date
WO1998027490A1 true WO1998027490A1 (fr) 1998-06-25

Family

ID=25084850

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/020401 WO1998027490A1 (fr) 1996-12-18 1997-11-07 Systeme et procede de commande du processus de test d'un logiciel

Country Status (2)

Country Link
AU (1) AU5250398A (fr)
WO (1) WO1998027490A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100373326C (zh) * 2005-09-13 2008-03-05 华为技术有限公司 一种自动化测试系统及其方法
CN104298597A (zh) * 2014-10-11 2015-01-21 无锡天脉聚源传媒科技有限公司 一种开发过程中进行包管理的方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4558413A (en) * 1983-11-21 1985-12-10 Xerox Corporation Software version management system
EP0323707A2 (fr) * 1987-11-25 1989-07-12 Westinghouse Electric Corporation Méthode de vérification et de validation de logiciel

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4558413A (en) * 1983-11-21 1985-12-10 Xerox Corporation Software version management system
EP0323707A2 (fr) * 1987-11-25 1989-07-12 Westinghouse Electric Corporation Méthode de vérification et de validation de logiciel

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"SOFTWARE PACKAGING AND VERIFICATION AID", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 36, no. 6A, 1 June 1993 (1993-06-01), pages 223 - 225, XP000372411 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100373326C (zh) * 2005-09-13 2008-03-05 华为技术有限公司 一种自动化测试系统及其方法
CN104298597A (zh) * 2014-10-11 2015-01-21 无锡天脉聚源传媒科技有限公司 一种开发过程中进行包管理的方法及装置

Also Published As

Publication number Publication date
AU5250398A (en) 1998-07-15

Similar Documents

Publication Publication Date Title
US5903897A (en) Software documentation release control system
US5950209A (en) Software release control system and method
US5960196A (en) Software release metric reporting system and method
EP0657045B1 (fr) Systeme a base de scripts pour tester un systeme informatique multi-utilisateurs
US6223343B1 (en) Computer system and method to track and control element changes throughout application development
EP1680741B1 (fr) Appareil de test comprenant une matrice de tracabilite multidimensionnelle automatique permettant de mettre en place et de valider des systemes logiciels complexes
US20030182652A1 (en) Software building and deployment system and method
RU2210803C2 (ru) Компьютерное устройство для выполнения прикладных программ
US6182245B1 (en) Software test case client/server system and method
US6964044B1 (en) System and process for management of changes and modifications in a process
US20050204201A1 (en) Method and system for testing software development activity
US6966052B1 (en) Method and apparatus for top-down testing based on end user documentation
US7797334B2 (en) Automated downloading from mainframe to local area network
US20040267814A1 (en) Master test plan/system test plan database tool
WO1998027487A1 (fr) Systeme et procede de controle de la liberation et du transfert de logiciels vers des supports
WO1998027490A1 (fr) Systeme et procede de commande du processus de test d'un logiciel
JP3429609B2 (ja) 設計情報管理装置
CA2422682A1 (fr) Systeme et methode de creation et de mise en application de logiciel
CN116204219A (zh) 软件版本更新的处理方法、电子设备及存储介质
CN114090419A (zh) 一种程序测试方法、系统、装置、电子设备以及存储介质
CN117591164A (zh) 一种一站式应用软件配置协同与交付的方法
Wilson Region and database management for HANDI 2000 business management system
IBM FEDERAL SECTOR DIV GAITHERSBURG MD Environment Capability Matrix for the Software Technology for Adaptable, Reliable Systems
MXPA06004919A (en) Testing tool comprising an automated multidimensional traceability matrix for implementing and validating complex software systems
Wagner et al. Integrated Information Support System (IISS). Volume 3. Configuration Management. Part 7. SCM Administrator's Manual

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH KE LS MW SD SZ UG ZW AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase