WO2016016975A1 - 開発支援システム - Google Patents

開発支援システム Download PDF

Info

Publication number
WO2016016975A1
WO2016016975A1 PCT/JP2014/070123 JP2014070123W WO2016016975A1 WO 2016016975 A1 WO2016016975 A1 WO 2016016975A1 JP 2014070123 W JP2014070123 W JP 2014070123W WO 2016016975 A1 WO2016016975 A1 WO 2016016975A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
program
development
support system
test case
Prior art date
Application number
PCT/JP2014/070123
Other languages
English (en)
French (fr)
Inventor
前岡　淳
中村　秀樹
晶 田中
Original Assignee
株式会社日立製作所
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 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US14/782,881 priority Critical patent/US9703692B2/en
Priority to JP2015541720A priority patent/JP5970617B2/ja
Priority to PCT/JP2014/070123 priority patent/WO2016016975A1/ja
Priority to CN201480020875.6A priority patent/CN105453050A/zh
Publication of WO2016016975A1 publication Critical patent/WO2016016975A1/ja

Links

Images

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
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing
    • 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
    • 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
    • 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/362—Software debugging
    • G06F11/3644—Software debugging by instrumenting at runtime

Definitions

  • the present invention relates to a software development technique, and more particularly to a technique that is effective when applied to a development support system that extracts a test case in a test for checking a defect of a program.
  • tests include defects due to human error.
  • tests Prior to shipment of program products, tests are typically performed to search for and correct defects contained in the program. For example, the test is executed by sequentially executing test cases, which are test programs that are executed by setting various conditions for the test target program, thereby generating a defect, so that a defect in the test target program is detected. Clarify location and cause.
  • CI continuous integration
  • a program developed by a plurality of people is centrally managed in a storage area called a repository on a central storage server.
  • the test case is automatically executed to check whether there is any defect in the registered program, thereby ensuring the quality of the program.
  • Patent Document 1 stores information about test cases of tests performed in the past, and analyzes the information and the target program.
  • a technique is described in which a regression test is performed by automatically extracting a portion to be preferentially tested according to a place where a program is changed by combining the obtained dependency relationships.
  • Patent Document 2 Japanese Patent Laid-Open No. 2010-134463 holds the importance and execution time as attributes of the test case in the repository, and changes the source configuration management tool that received the source registration from the developer to the CI tool.
  • the change file passed from the CI tool is analyzed, the analysis result is stored in the repository, the execution importance level and the execution time threshold passed from the CI tool, and stored in the repository.
  • a technique for selecting a test case to be executed based on the importance of the test case and the actual execution time is described.
  • test cases in consideration of the program development status, development phase, etc., such as the early stage, middle stage, and late stage. Also, test cases cannot be extracted in consideration of test contents such as the operator who performs the test and the test execution viewpoint and the execution status.
  • an object of the present invention is to provide a development support system that extracts important test cases according to the development status of a program, the status of testing, and the like.
  • a development support system is a development support system that tests a program by executing one or more test cases, and manages the program and each test case by holding them in a repository.
  • the test case is managed in the repository in association with the type of information.
  • the unit determines the development status of the program, sets a priority for each test case based on the development status, and the test execution unit extracts the test case to be executed based on the priority To do.
  • the execution of the test case can be made more efficient by executing only the important test cases, but the program development status and test status It is not possible to consider.
  • the contents to be tested may differ depending on the progress of the development process (for example, between the early stage of development and the late stage of development) and the maturity of the program itself over time.
  • the content you want to test can be different between when you register (commit) changes made to a program at a high frequency or when the correction amount (difference) is small and when the registration frequency is low or when the correction difference is large.
  • the prior art lacks the viewpoint of determining the importance in consideration of the development situation including such a temporal viewpoint.
  • the viewpoint to be tested may differ between a local unit test by a developer and an overall verification test by program integration.
  • the prior art lacks the viewpoint of determining the importance in consideration of the contents of such test execution.
  • FIG. 2 is a diagram for explaining the outline of the problem to be solved by the development support system according to the embodiment of the present invention described above.
  • branching which is an area for managing programs for each development unit, and an example of registration (commit) status for programs developed in a branch from left to right Shown in chronological order.
  • a state is shown in which developers A and B branch off from the main branch to create their own branch for development, and are integrated (merged) into the main branch after the development is completed.
  • FIG. 3 shows a state where the development branch 402 (branch name “develop”), which is the main branch for development, is branched from the master branch 401 and created. Further, a branch for development of function A 403 (branch name “feature_A”), which is a development branch for function A, is branched from the development branch 402, and further, “XXX” is created from the branch for development of function A 403.
  • a branch for function A developer XXX 404 (branch name “feature_A_XXX”), which is a branch for developers named “”, is created by branching.
  • FIG. 4 is a diagram showing an outline of an example of branch integration in social coding.
  • the function A developer branch 403 that is the branch source is merged with the function A developer XXX branch 404 that is created by branching.
  • the contents of the program registered in the function A developer XXX branch 404 are merged with the function A development branch 403 by overwriting.
  • FIGS. 2 to 4 as the development progresses, the development proceeds while branching to a plurality of branches or integrating a plurality of branches.
  • a test is performed at each stage of development.
  • an extraction method that considers the development status of a program including a temporal viewpoint is illustrated in FIG.
  • it includes extracting appropriate types of test cases according to the progress of development (such as the early stage of development and maturity).
  • the commit frequency is high (the interval is short) or the amount of modification differences is large, test cases are thinned out and extracted, or multiple tests are distributedly executed. It is included.
  • the extraction method considering the viewpoint of test execution is performed according to the target branch as shown in (3) of FIG. This includes extracting appropriate test cases (for example, a local unit test in the case of a developer branch, and an overall verification test after integrating programs in the case of a main branch) by changing the target.
  • appropriate test cases for example, a local unit test in the case of a developer branch, and an overall verification test after integrating programs in the case of a main branch
  • FIG. 1 is a diagram showing an outline of a configuration example of a development support system according to an embodiment of the present invention.
  • the development support system 1 is configured such that, for example, a plurality of development clients 200 used by each user are connected to the development support server 100 via a network such as a LAN (Local Area Network) and can communicate with each other.
  • a network such as a LAN (Local Area Network) and can communicate with each other.
  • the development support server 100 is, for example, a server system having functions such as test case extraction and automatic test execution.
  • the development support server 100 is implemented by a general server device or a virtual server built on a cloud computing environment.
  • Each component includes a configuration management unit 110 and a test execution unit 120 that are implemented by a software program that runs on middleware such as an OS (Operating System), a DBMS (DataBase Management System), and a Web server program.
  • middleware such as an OS (Operating System), a DBMS (DataBase Management System), and a Web server program.
  • the repository 130 is a storage area such as a database for storing and centrally managing programs and various deliverables developed by a plurality of developers.
  • the repository 130 includes, for example, a developed program 133, an extracted / created test case 134, and a test result 135 that is a test execution result, in addition to tables such as a branch management table 131 and a test case management table 132 described later. Etc. are stored.
  • the configuration management unit 110 has a function of managing the overall configuration of program development, and includes, for example, a server program of a system or tool that provides a social coding function, a repository management function, a version management function, and the like. As these tools, for example, commonly used tools such as Git can be applied.
  • the configuration management unit 110 registers the developed program 133 in the repository 130 based on, for example, a request from the development client 200 described later. At this time, information that can grasp changes and differences from the previous registration is also stored as history information. Further, the test case 134 created for the program 133 is registered in the repository 130 and the test case management table 132 is updated.
  • the branch management table 131 also has a function of managing the created branch information.
  • the test execution unit 120 has a function of automatically executing a test based on a test case 134 registered in the repository 130 according to an instruction from the configuration management unit 110.
  • a test framework such as JUnit that is widely used Etc. can be applied.
  • efficient testing can be performed by extracting high-priority test cases 134 among the test cases 134 by using the method described later, and performing tests by focusing on the extracted test cases 134.
  • the test case 134 to be executed is managed by the test case management table 132, and the test result 135 obtained as a result of the test execution is also stored and managed in the repository 130.
  • the development client 200 is, for example, an information processing terminal such as a PC (Personal Computer) on which each user such as a developer performs work such as development of the program 133 and creation of the test case 134.
  • Each unit includes a Web browser 210, a code description unit 220, a configuration management operation unit 230, and the like, which are implemented by a software program that runs on the computer.
  • the code description unit 220 has a function for a developer to develop and create the program 133 or to create the test case 134.
  • a widely used program development tool such as Eclipse, a development environment, etc. Can be used as appropriate.
  • the program 133 developed and created by the developer using the code description unit 220, the test case 134, and the test case additional information 201, which is information related to the test case 134, are transmitted to the development support server 100 by the configuration management operation unit 230 described later. It is registered in the repository 130 above.
  • the configuration management operation unit 230 communicates with the configuration management unit 110 of the development support server 100, and transmits the program 133, test case 134, test case additional information 201, and the like developed and created by the code description unit 220 to the repository 130. Has the function to register.
  • Git when Git is used as the configuration management unit 110 of the development support server 100, it can be implemented by a Git client or the like.
  • the web browser 210 is a web browser program that provides a user interface for a developer to perform work such as program development and review using the code description unit 220 and the configuration management operation unit 230 in social coding. Can be used as appropriate. You may have a function which communicates with the structure management part 110 etc. of the development support server 100 via the web server program on the development support server 100 which is not illustrated.
  • FIG. 5 is a flowchart showing an outline of an example of a process flow for creating a test case.
  • a test case creator uses the development client 200 to create a test case 134 by the code description unit 220 and registers it in the repository 130 via the configuration management unit 110 of the development support server 100 (S01).
  • the configuration management unit 110 assigns related information including the type of the test case 134 and registers it in the test case management table 132 described later (S02).
  • FIG. 6 is a flowchart showing an overview of an example of a flow of test execution processing based on the created test case 134.
  • the developer of the program 133 uses the development client 200 to register (commit) the developed program 133 in the repository 130 of the development support server 100 by using the code description unit 220 and the configuration management operation unit 230 (S11). ).
  • the registration here can be, for example, a format for registering only differences relating to changes and modifications.
  • Information on the registered program 133 is managed for each branch by a branch management table 131 described later.
  • the history of registering the program 133 is managed by a commit history 131a described later.
  • the configuration management unit 110 or the test execution unit 120 of the development support server 100 prioritizes each test case 134 registered in the test case management table 132 for the registered program 133.
  • the degree is calculated by a predetermined method, and the test case management table 132 is updated with the calculated priority value (S12). The contents of the priority calculation process will be described later.
  • step S21 If it is determined in step S21 that the branch is the main branch, the regression test (regression test) is executed on the whole, and the test case 134 having the test type “regression test” is selected. Extract (S22). At the time of extraction, the priority may be increased to a maximum value or the like so that the target test case 134 is always an execution target. That is, raising the priority of the target test case 134 to the maximum value or the like is equivalent to directly extracting the target test case 134.
  • the type of the test case 134 may be determined based on, for example, contents registered in the test case management table 132 described later, or may be given to the information on the folder in which the test case 134 is stored or the test case 134. The determination may be made based on the annotation information.
  • step S21 If it is determined in step S21 that the branch is a functional branch, the test corresponding to the target function is selected and extracted from the test cases 134 as a test related to the target function. (S23). Again, the priority of the target test case 134 may be increased to a maximum value or the like.
  • the function type of the test case 134 may be determined based on, for example, the contents registered in the test case management table 132 and the function master 137, which will be described later, or the program 133 and the test case 134 related to the target function are stored. The determination may be made based on the information of the existing folder, annotation information, or the like.
  • step S21 If it is determined in step S21 that the branch is a developer branch, a normal test is performed. First, it is determined whether or not the elapsed time from the previous commit has elapsed for a predetermined time or more (whether the latest degree is high) for the target program 133 (S24). Instead of the elapsed time from the previous commit, the average time of the intervals of the past several commits may be used. If the specified time has not elapsed, it is estimated that the time has not passed much since the previous test (the most recent degree is high). In order to adjust, a timer for a predetermined time is started (S25).
  • the priority calculation process is terminated and the test is automatically performed (after step S13 in FIG. 6). Note that the priority of these test cases 134 is set higher so that test cases 134 different from the previously performed test cases 134 are extracted instead of deferring the execution of the tests when the latest degree is high. May be.
  • step S24 if it is determined in step S24 that a predetermined time or more has passed since the previous commit (the degree of closestness is low), it is next determined whether or not the difference amount of the changed part of the target program 133 is greater than or equal to the predetermined (S26). ). If the difference amount is less than the predetermined amount, it is determined that the necessity of performing the test is low, and the process proceeds to step S25 to postpone execution of the test. If the difference amount is greater than or equal to the predetermined value in step S26, the timer is canceled to execute the test (S27), and the test case 134 is extracted (S28).
  • the priority can be set for each test case 134 using the following viewpoints so that the one with the higher priority is extracted. For example, as a test case having a high degree of association with the development part, a test case related to the corresponding function can be selected or assigned to the developer who developed the target program 133 depending on the type of function that can be determined from the branch naming rules. These associated test cases 134 can be selected based on the task, role, etc. being assigned. That is, depending on whether the developer is a developer in charge of the P layer (presentation layer) in the application or a developer in charge of the F layer (function layer) or D layer (data layer), The priority of the test case 134 corresponding to the F layer and the D layer can be increased.
  • the priority of the test case 134 created by the developer of the target program 133 may be increased.
  • the test cases 134 that have not been executed at the time of the previous test or the test cases 134 that have not been executed for a predetermined time since the previous execution have not been tested for a certain period.
  • the priority may be set high so that
  • the work content is determined based on whether the test target branch is the main branch, the functional branch, or the developer branch, and the method of extracting the test case 134 (priority setting) is switched.
  • the work content of the branch is not limited to the above, and it may be determined that the work content is other work content such as bug countermeasures, release preparation, and a review request.
  • the work content can also be determined based on the type of commit that triggered the test. For example, when the target commit is a merge commit of a plurality of branches, all test cases may be executed because it is presumed that the function integration work is being performed. When the target commit is a normal commit, it is estimated that the development contents have been updated. Therefore, the priority of the corresponding test case 134 may be increased so that the regression test is executed. Furthermore, in addition to the type of commit, for example, the priority of the related test case 134 may be increased based on the type of issue (Trigger) that triggered the creation of the developer branch.
  • Trigger type of issue
  • Priority can also be set so that related test cases 134 are extracted based on the progress (maturity) of program development. For example, if the degree of progress is scored according to the number of reviews for the developed program (source code) and the result (number of OK / NG), and the degree of progress is determined to be lower than a predetermined level, When all the test cases 134 are executed and it is determined that the degree of progress is higher than a predetermined level, the priority can be set so that only the important test cases 134 are executed.
  • FIG. 8 is a flowchart showing an outline of an example of a review process flow for the program 133.
  • the requester of the review acquires the program 133 to be reviewed from the repository 130 of the development support server 100 using his / her development client 200 and displays the page of the target location on the Web browser 210 (S41). ).
  • the review requester inputs comments, review points, and the like for the reviewer (S42, S43), and commits the program 133, thereby transmitting a review request to the development support server 100 (S44).
  • the development support server 100 receives the review request and registers information related to the request in, for example, a review management table 136 (to be described later) on the repository 130. After that, when the reviewer uses the development client 200 to acquire the relevant part of the target program 133 from the repository 130 and performs a review (S46), the configuration management unit 110 of the development support server 100 based on the review result. Etc. update the contents of the review management table 136 (S47).
  • the degree of completion of the source code to be calculated can be used as an index for judging the progress of program development.
  • the degree of review progress on the test case 134 related to the target program 133, and the like can be used as an index for judging the progress of program development.
  • the result of the test performed last time for example, the ratio of the result of success or failure, the number of successful cases, etc. can also be used.
  • FIG. 9 is a diagram showing an overview of the data configuration of the test case management table 132 held on the repository 130 of the development support server 100 and an example of specific data.
  • the test case management table 132 is a table that holds related information including the type of the test case 134 and the like. , Test class, function type, test type, creator, and priority.
  • the test class item holds name information for specifying a test program (class) to be executed as the target test case 134.
  • the function type item holds information such as a code value that specifies the type of function on the application corresponding to the target test case 134.
  • names such as “UI (User Interface) system”, “DB system”, and “logic system” are used.
  • the item of test type holds information such as a code value for specifying the type of test corresponding to the target test case 134.
  • names such as “regression”, “normal system”, and “abnormal system” are shown.
  • the creator item holds information such as an ID for identifying a user such as a developer who created the target test case 134. This identification information is set in the developer master 138 described later.
  • the priority item holds information on the priority calculated by the priority calculation process as shown in FIG. 7 for the target test case 134.
  • the priority value is “1” (extraction target) or “ ⁇ 1” (non-extraction target).
  • the priority setting method is not limited to this, and for example, “1”. It is also possible to set a numerical range such as “10” or “1” to “100”, or a rank such as “A”, “B”, “C”.
  • FIG. 10 is a diagram showing an overview of the data configuration of the branch management table 131 held on the repository 130 and an example of specific data.
  • the branch management table 131 is a table for managing branches created on the repository 130 of the development support server 100, and includes items such as a branch name and a file list.
  • the item of branch name holds name information that can uniquely identify each branch. This name is set based on a predetermined naming rule, for example, as shown in FIG. 3, and the type of the target branch and the work content can be determined from the name.
  • the item of the file list holds information including a list of files including the program 133 registered in the target branch. In the example of FIG. 10, the file names are listed as data for convenience, but the data structure is not limited to this as long as it is a data structure that can specify all target files (program 133).
  • FIG. 11 is a diagram showing an outline of the data structure of the commit history 131a held on the repository 130 and specific data examples.
  • the commit history 131a is a table that holds information on the history of registration (commitment) of the program 133 in the branch, and includes items such as a branch name, a commit date, and correction contents.
  • the branch name item holds information on the branch name that identifies the branch in which the program 133 is registered.
  • the information on the branch name is registered in the branch management table 131 shown in FIG.
  • the item of commit date / time holds information on a time stamp when the program 133 is committed to the target branch.
  • the item of correction content holds information on the file name including the program 133 committed as a correction / change to the target branch.
  • FIG. 12 is a diagram showing an overview of the data structure of the function master 137 and specific data examples.
  • the function master 137 is a table that holds master information about functions to be developed, and includes items such as a function name and a function type.
  • the function name item holds information such as an ID and a name for uniquely identifying the target function. This name is used in the branch naming rules described above.
  • the function type item holds information such as a code value for specifying the type of the target function, similarly to the function type item in the example of FIG.
  • FIG. 13 is a diagram showing an overview of the data structure of the developer master 138 and an example of specific data.
  • the developer master 138 is a table that holds master information about each developer, and includes, for example, each item of a user name and a task in charge.
  • the item of the user name holds identification information such as an ID that can uniquely identify the target developer.
  • the item of work in charge holds information such as a code value for specifying one or more work, task, role, etc. for which the target developer is in charge of program development.
  • FIG. 14 is a diagram showing an overview of the data configuration of the review management table 136 held on the repository 130 and an example of specific data.
  • the review management table 136 is a table for managing reviews when merging a branch including the development target program 133 into a branch source branch. For example, a merge request, a merge target, a merge destination, the number of reviews, a review score, and the like Each item.
  • the merge request item holds information such as a sequence number and ID that can uniquely identify each merge request.
  • the merge target item and the merge destination item respectively hold information on a branch name that specifies a merge source branch and a merge destination (branch source) branch to be merged.
  • the item of the number of reviews holds information on the number of reviews performed for the review request related to the merge of the target branch. It is also possible for a plurality of reviewers to review a review request in parallel.
  • the item of the review score holds information on the score of the review related to the merge of the target branch. If the score is high, it is presumed that the quality of the target program 133 is high, and it is possible to improve efficiency such as limiting the execution of the test case 134 to an important one.
  • each table shown in FIGS. 9 to 14 is merely an example, and other table configurations and data configurations may be used as long as similar data can be held and managed. It may be.
  • the development support system 1 in the social coding environment, the development status of the program 133 and various viewpoints such as test execution are important.
  • the test case 134 can be extracted or implemented with priority. As a result, it is possible to perform an efficient test without exhaustively carrying out a huge number of test cases.
  • the present invention made by the present inventor has been specifically described based on the embodiments.
  • the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the invention. Needless to say.
  • the above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described.
  • each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit.
  • Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor.
  • Information such as programs, tables, and files for realizing each function can be stored in a recording device such as a memory, a hard disk, or an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.
  • control lines and information lines indicate what is considered necessary for explanation, and not all control lines and information lines on mounting are necessarily shown. Actually, it may be considered that almost all the components are connected to each other.
  • the present invention can be used in a development support system that extracts test cases in a test for checking a program defect.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　プログラムの開発状況や、テストの状況などに応じて重要なテストケースを抽出する開発支援システムである。代表的な実施の形態は、前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、前記構成管理部は、前記プログラムの開発状況を判定して、前記開発状況に基づいて前記各テストケースに優先度を設定し、前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する。

Description

開発支援システム
　本発明は、ソフトウェア開発の技術に関し、特に、プログラムの不具合確認等のためのテストにおけるテストケースを抽出する開発支援システムに適用して有効な技術に関するものである。
　ソフトウェアプログラム（以下では単に「プログラム」と記載する場合がある）には、人為的なミスによる不良が含まれている。プログラム製品の出荷に先立って、プログラムに含まれる不良を探索し、修正するために、テストが行われるのが一般的である。テストの実施は、例えば、テスト対象のプログラムに対してさまざまな条件を設定して実行するテスト用のプログラムであるテストケースを順次実行し、不具合を発生させることで、テスト対象のプログラムにおける不良の場所および原因を明らかにする。
　さらに、例えば、テストケースの実行を自動的に行ったりするような、いわゆる継続的インテグレーション（ＣＩ：Continuous Integration）に係るツールや技術が普及してきている。ＣＩを実現するツール等では、一般的に、複数人で開発されるプログラムは、中央の記憶サーバ上のリポジトリと呼ばれる記憶領域において集中的に管理される。そして、開発者が、開発したプログラムをリポジトリに登録するたびに、自動的にテストケースを実行し、登録されたプログラムに不良が存在しないかを調べることで、プログラムの品質確保が図られる。
　また、リポジトリで管理されるプログラムのソースコードなどの関連物に対して、複数の開発者等が内容をチェックするレビューにより開発内容を承認するという仕組みが提供されているものがある。このような複数の開発者による共同開発やレビューによるソフトウェア開発の手法はソーシャルコーディングと呼ばれる。
　一方、テストの実施に際しては、テストケースの量に伴い実行時間が増大するという課題が有る。プログラムの不良は、通常は特定の条件のみで発生するため、これを探索するには、あらゆる条件を想定した多数のテストケースを準備して実行する必要があることから、テストケースの実行に多くの時間を要する。
　この課題に対して、例えば、特開２００８－２０４４０５号公報（特許文献１）には、過去に行われたテストのテストケースについての情報を保存しておき、その情報と対象プログラムを解析して得られた依存関係を組み合わせることにより、プログラムを変更した箇所に応じて優先的にテストすべき部分を自動的に抽出してリグレッションテストを行う技術が記載されている。
　また、特開２０１０－１３４６４３号公報（特許文献２）には、リポジトリにテストケースの属性として重要度および実行実績時間を保持させ、開発者からソース登録を受けたソース構成管理ツールからＣＩツールにソース変更の通知があったときに、ＣＩツールから渡された変更ファイルの解析を行い、解析結果をリポジトリに格納し、ＣＩツールから渡された実施重要度および実施時間閾値と、リポジトリに格納されたテストケースの重要度および実行実績時間とから実行すべきテストケースを選択する技術が記載されている。
特開２００８－２０４４０５号公報 特開２０１０－１３４６４３号公報
　上述した従来技術によるテスト方法は、いずれも、テストケースのうち重要なものに限定して実行することで、テストケースの実施に時間を要するという上記課題を解決しようとするものである。
　しかしながら、従来技術によるテスト方法では、例えば、開発初期段階、中期段階、後期段階といったプログラムの開発状況や開発フェーズなどを考慮してテストケースを抽出することができない。また、テストを実施する操作者や、テスト実施の観点等といったテストの内容や実施状況などを考慮してテストケースを抽出することができない。
　そこで本発明の目的は、プログラムの開発状況や、テストの状況などに応じて重要なテストケースを抽出する開発支援システムを提供することにある。
　本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
　本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
　本発明の代表的な実施の形態による開発支援システムは、１つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、前記構成管理部は、前記プログラムの開発状況を判定して、前記開発状況に基づいて前記各テストケースに優先度を設定し、前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出するものである。
　本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
　すなわち、本発明の代表的な実施の形態によれば、プログラムの開発状況や、テストの状況などに応じて重要なテストケースを抽出することが可能となる。
本発明の一実施の形態である開発支援システムの構成例について概要を示した図である。 本発明の一実施の形態における開発支援システムが解決しようとする課題について概要を説明する図である。 ソーシャルコーディングにおけるブランチの作成例について概要を示した図である。 ソーシャルコーディングにおけるブランチの統合例について概要を示した図である。 本発明の一実施の形態におけるテストケース作成の処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるテスト実行の処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態における優先度算出処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるプログラムに対するレビューの処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるテストケース管理テーブルのデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態におけるブランチ管理テーブルのデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態におけるコミット履歴のデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態における機能マスタのデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態における開発者マスタのデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態におけるレビュー管理テーブルのデータ構成と具体的なデータの例について概要を示した図である。
　以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
　上述したように、ネットワークを介して複数の開発者がプログラムの開発を行うソーシャルコーディングの環境において、テストの自動実行などのＣＩを実現するツール等が普及してきているが、自動実行とは言いながらも、膨大な数のテストケースを全て実行するには非常に時間がかかり非効率である。そこで、重要な部分のみに限定してテストケースを実行する、もしくは重要な部分を優先的に実行できるようにしたいという要望がある。
　ここで、上述した特許文献等の従来技術では、テストケースのうち重要なものに限定して実行することで、テストケースの実施を効率化することができるものの、プログラムの開発状況や、テスト状況などを考慮することまではできていない。例えば、開発状況の考慮として、同一のプログラムにおいても、開発工程の進捗度（例えば、開発初期と開発後期との間など）や時間経過によるプログラム自体の成熟度に応じてテストしたい内容は異なり得る。また、プログラムに加えた修正を登録（コミット）する頻度が高い場合や修正量（差分）が小さい場合と、登録頻度が低い場合や修正差分が大きい場合との間でも、テストしたい内容は異なり得る。従来技術では、このような時間的観点を含む開発状況を考慮して重要度を判断するという観点が欠落している。
　また、テスト状況の考慮として、同一のプログラムにおいても、例えば、開発者によるローカルでの単体テストと、プログラム統合による全体検証テストとの間では、テストしたい観点は異なり得る。従来技術では、このようなテスト実施の内容を考慮して重要度を判断するという観点が欠落している。
　そこで、本発明の一実施の形態である開発支援システムは、ソーシャルコーディングの環境において、プログラムの開発状況や、テスト実施の観点に基づき、重要なテストケースを抽出し、あるいは優先的に実施できるようにするものである。これにより、膨大な数のテストケースを網羅的に全て実施することなく、効率的なテストの実施を可能とする。
　図２は、上述した本発明の一実施の形態である開発支援システムが解決しようとする課題について概要を説明する図である。図中では、ソーシャルコーディングやバージョン管理、リポジトリ管理において、開発単位毎のプログラムを管理する領域であるブランチの分岐例と、ブランチにおいて開発したプログラムについての登録（コミット）の状況の例を左から右方向への時系列で示している。ここでは、メインブランチから開発者ＡおよびＢのそれぞれが自身の開発のためのブランチを分岐させて作成し、開発が完了した後にメインブランチに統合（マージ）している状態を示している。
　プログラムは、上述したように、開発用途や開発者などの単位で個別に設けられたブランチ上で管理される。図３は、ソーシャルコーディングにおけるブランチの作成例について概要を示した図である。図中では、マスタとなるプログラムが登録されているマスタブランチ４０１（ブランチ名“ｍａｓｔｅｒ”）に、“Ａ．ｊａｖａ”および“Ｂ．ｊａｖａ”などのプログラム（ソースコード）が登録されていることを示している。新しいブランチは、任意のタイミングで作成することができ、例えば、既存のリポジトリをコピーすることで作成することができる。この場合、作成されたブランチは元のブランチから分岐したものとなる。なお、最初のブランチは新規に作成する。
　図３の例では、マスタブランチ４０１から、開発用のメインブランチである開発用ブランチ４０２（ブランチ名“ｄｅｖｅｌｏｐ”）を分岐させて作成した状態を示している。さらに、開発用ブランチ４０２から、機能Ａについての開発用のブランチである機能Ａ開発用ブランチ４０３（ブランチ名“ｆｅａｔｕｒｅ＿Ａ”）を分岐させて作成し、さらに、機能Ａ開発用ブランチ４０３から、“ＸＸＸ”という名称の開発者用のブランチである機能Ａ開発者ＸＸＸ用ブランチ４０４（ブランチ名“ｆｅａｔｕｒｅ＿Ａ＿ＸＸＸ”）を分岐させて作成した状態を示している。
　また、作成したブランチは、例えば開発対象のプログラムの完成など、任意のタイミングで分岐元のブランチに統合（マージ）することができる。図４は、ソーシャルコーディングにおけるブランチの統合例について概要を示した図である。図中では、分岐元である機能Ａ開発用ブランチ４０３に対して、分岐して作成した機能Ａ開発者ＸＸＸ用ブランチ４０４をマージした状態を示している。マージにより、機能Ａ開発用ブランチ４０３に対して、機能Ａ開発者ＸＸＸ用ブランチ４０４に登録されたプログラムの内容が上書きでマージされる。図２～図４に示したように、開発の進展に伴って、複数のブランチに分岐したり、複数のブランチを統合したりしながら開発が進められる。
　開発の各段階でテストが行われるが、上述した、重要なテストケースを抽出する際の考慮点のうち、時間的観点を含むプログラムの開発状況を考慮した抽出の手法については、例えば、図２の（１）に示したように、開発の進捗度（開発初期や成熟期など）に応じて適当な種類のテストケースを抽出することが含まれる。また、図２の（２）に示したように、コミットの頻度が多い（間隔が短い）場合や修正差分の量が多い場合にテストケースを間引いて抽出したり、複数のテストを分散実行したりすることなどが含まれる。
　一方、重要なテストケースを抽出する際の考慮点のうち、テスト実施の観点を考慮した抽出の手法については、例えば、図２の（３）に示したように、対象のブランチに応じてテスト対象を変えて適当なテストケース（例えば、開発者ブランチの場合はローカルでの単体テスト、メインブランチの場合はプログラムを統合した後の全体検証テストなど）を抽出することが含まれる。
　＜システム構成＞
　図１は、本発明の一実施の形態である開発支援システムの構成例について概要を示した図である。開発支援システム１は、例えば、開発支援サーバ１００に対して、ＬＡＮ（Local Area Network）などのネットワークを介して、各ユーザがそれぞれ使用する開発用クライアント２００が複数接続され、相互に通信可能な構成を有する。
　開発支援サーバ１００は、例えば、テストケースの抽出やテストの自動実行などの機能を有するサーバシステムであり、一般的なサーバ機器やクラウドコンピューティング環境上に構築された仮想サーバなどにより実装され、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアプログラムにより実装される構成管理部１１０およびテスト実行部１２０などの各部を有する。
　また、複数の開発者により開発されたプログラムや各種成果物を記憶して集中的に管理するデータベース等の記憶領域であるリポジトリ１３０を有する。リポジトリ１３０には、例えば、後述するブランチ管理テーブル１３１やテストケース管理テーブル１３２などのテーブルの他に、開発されたプログラム１３３や、抽出・作成されたテストケース１３４、テスト実施結果であるテスト結果１３５などの各種データが保持される。
　構成管理部１１０は、プログラム開発の全体的な構成を管理する機能を有し、例えば、ソーシャルコーディング機能やリポジトリ管理機能、バージョン管理機能などを提供するシステムやツールのサーバプログラムによって構成される。これらのツールとしては、例えば、Ｇｉｔなどの一般に普及しているものを適用することができる。構成管理部１１０は、例えば、後述する開発用クライアント２００からの要求等に基づいて、開発されたプログラム１３３をリポジトリ１３０に登録する。このとき、前回の登録時からの変更や差分が把握できるような情報を履歴情報として併せて格納する。また、プログラム１３３に対して作成されたテストケース１３４をリポジトリ１３０に登録するとともに、テストケース管理テーブル１３２を更新する機能も有する。また、作成されたブランチの情報をブランチ管理テーブル１３１によって管理する機能も有する。
　テスト実行部１２０は、構成管理部１１０からの指示により、リポジトリ１３０に登録されたテストケース１３４に基づいてテストを自動実行する機能を有し、例えば、ＪＵｎｉｔなどの一般に普及しているテストフレームワークなどを適用することができる。本実施の形態では、後述する手法により、テストケース１３４のうち優先度が高いものを抽出して、抽出されたテストケース１３４に絞ってテストを実施することで、効率的なテストの実施を可能とする。実行するテストケース１３４については、テストケース管理テーブル１３２によって管理し、また、テストの実行の結果として得られるテスト結果１３５についてもリポジトリ１３０に格納して管理する。
　開発用クライアント２００は、例えば、開発者等の各ユーザがプログラム１３３の開発やテストケース１３４の作成などの作業を行うＰＣ（Personal Computer）等の情報処理端末であり、図示しないＯＳなどのミドルウェア上で稼働するソフトウェアプログラムにより実装されるＷｅｂブラウザ２１０やコード記述部２２０、構成管理操作部２３０などの各部を有する。
　コード記述部２２０は、開発者がプログラム１３３を開発・作成したり、テストケース１３４を作成したりするための機能を有し、例えば、Ｅｃｌｉｐｓｅなどの一般に普及しているプログラム開発ツールや開発環境などを適宜利用することができる。コード記述部２２０を利用して開発者により開発・作成されたプログラム１３３やテストケース１３４、テストケース１３４に関する情報であるテストケース付加情報２０１は、後述する構成管理操作部２３０により、開発支援サーバ１００上のリポジトリ１３０に登録される。
　構成管理操作部２３０は、開発支援サーバ１００の構成管理部１１０と通信し、コード記述部２２０により開発・作成されたプログラム１３３やテストケース１３４、テストケース付加情報２０１などを送信してリポジトリ１３０に登録する機能を有する。例えば、開発支援サーバ１００の構成管理部１１０としてＧｉｔを用いている場合には、Ｇｉｔクライアントなどにより実装することができる。
　Ｗｅｂブラウザ２１０は、ソーシャルコーディングにおいて開発者がコード記述部２２０や構成管理操作部２３０を用いたプログラム開発やレビュー等の作業を実施するためのユーザインタフェースを提供するＷｅｂブラウザプログラムであり、一般に普及しているものを適宜用いることができる。図示しない開発支援サーバ１００上のＷｅｂサーバプログラムを介して開発支援サーバ１００の構成管理部１１０等と通信を行う機能を有していてもよい。
　＜処理フロー（テストケース作成）＞
　以下では、本実施の形態におけるテスト実施の際の各処理について説明する。図５は、テストケース作成の処理の流れの例について概要を示したフローチャートである。まず、テストケースの作成者が、開発用クライアント２００を利用して、コード記述部２２０によりテストケース１３４を作成し、開発支援サーバ１００の構成管理部１１０を介してリポジトリ１３０に登録する（Ｓ０１）。このとき、構成管理部１１０では、テストケース１３４の種類などを含む関連情報を割り当てて、後述するテストケース管理テーブル１３２に併せて登録する（Ｓ０２）。
　＜処理フロー（テスト実行）＞
　図６は、作成されたテストケース１３４に基づくテスト実行の処理の流れの例について概要を示したフローチャートである。まず、プログラム１３３の開発者が、開発用クライアント２００を利用して、コード記述部２２０および構成管理操作部２３０により、開発したプログラム１３３を開発支援サーバ１００のリポジトリ１３０に登録（コミット）する（Ｓ１１）。ここでの登録は、例えば、変更や修正に係る差分のみを登録する形式とすることができる。登録したプログラム１３３の情報は、ブランチ毎に後述するブランチ管理テーブル１３１によって管理する。また、プログラム１３３を登録した履歴は、後述するコミット履歴１３１ａによって管理する。
　プログラム１３３がリポジトリ１３０に登録されると、開発支援サーバ１００の構成管理部１１０もしくはテスト実行部１２０が、登録されたプログラム１３３について、テストケース管理テーブル１３２に登録された各テストケース１３４に係る優先度を所定の手法によりそれぞれ算出し、算出した優先度の値によってテストケース管理テーブル１３２を更新する（Ｓ１２）。優先度算出処理の内容については後述する。
　その後、開発支援サーバ１００のテスト実行部１２０が、初期処理としてテスト経過時間をリセットした上で（Ｓ１３）、テストを実施する（Ｓ１４）。テストの実施の際は、テストケース管理テーブル１３２に登録された優先度が高いものから順に、もしくは優先度が所定の値より大きいものを、テストケース１３４とプログラム１３３をリポジトリ１３０から読み込んで実行し、テスト結果１３５をリポジトリ１３０に格納する。その後、テストの開始から所定の制限時間が経過したか否かを判定する（Ｓ１５）。所定の制限時間が経過していない場合は、ステップＳ１４に戻ってテスト実施を継続する。一方、所定の制限時間が経過している場合は、テスト実行を終了する。
　以上の処理により、優先度の高いテストケース１３４に絞り込んでテストを実施することができ、テストの効率化を図ることができる。なお、ステップＳ１５で所定の制限時間の経過により実行されなかったテストケース１３４については、例えば、そのリストを保持しておき、夜間の定時処理などによって実施するようにしてもよい。また、所定の制限時間内でのステップＳ１４の実行においていずれかのテストケース１３４の実行が失敗した場合は、例えば、テスト実行処理の終了後、優先度が低いために実行をスキップしたテストケース１３４に対応するコミットについてもテストを実施し、どの時点で対象のテストケース１３４が失敗していたかを検証するのが望ましい。
　＜処理フロー（優先度算出処理）＞
　図７は、図６に示したテスト実行の処理フローにおける優先度算出処理（Ｓ１２）の流れの例について概要を示したフローチャートである。まず、開発支援サーバ１００の構成管理部１１０もしくはテスト実行部１２０が、テストの対象のプログラム１３３が登録されているリポジトリ１３０上のブランチの作業内容を判定する（Ｓ２１）。ブランチの作業内容は、例えば、図３に示したように、ブランチのネーミングルールに基づいて判断することができる。
　ステップＳ２１でブランチがメインブランチであると判定された場合は、全体について回帰テスト（リグレッションテスト）を実行するものとして、テストケース１３４のうち、テスト種別が「回帰テスト」であるものを選択して抽出する（Ｓ２２）。抽出に際しては、対象のテストケース１３４が必ず実行対象となるよう、優先度を最大値等に上げるようにしてもよい。すなわち、対象のテストケース１３４の優先度を最大値等に上げることは、対象のテストケース１３４を直接抽出することと等価である。テストケース１３４の種別は、例えば、後述するテストケース管理テーブル１３２に登録された内容によって判断してもよいし、テストケース１３４が格納されているフォルダの情報や、テストケース１３４に対して付与されたアノテーションの情報等に基づいて判断してもよい。
　ステップＳ２１でブランチが機能ブランチであると判定された場合は、対象の機能に関連したテストを実行するものとして、テストケース１３４のうち、機能種別が対象の機能に対応するものを選択して抽出する（Ｓ２３）。ここでも、対象のテストケース１３４の優先度を最大値等に上げるようにしてもよい。テストケース１３４の機能種別は、例えば、後述するテストケース管理テーブル１３２や機能マスタ１３７に登録された内容によって判断してもよいし、対象の機能に係るプログラム１３３やテストケース１３４等が格納されているフォルダの情報や、アノテーションの情報等に基づいて判断してもよい。
　ステップＳ２１でブランチが開発者ブランチであると判定された場合は、正常系のテストを実施する。まず、対象のプログラム１３３について前回のコミットからの経過時間が所定時間以上経過しているか否か（直近度が高いか否か）を判定する（Ｓ２４）。前回のコミットからの経過時間に代えて、過去数回のコミットの間隔の平均時間を用いてもよい。所定時間以上経過していない場合は、前回のテスト実施から時間があまり経過していない（直近度が高い）と推測されることから、テストの実行を行わずに先送りして間引くことでテスト間隔を調整するため、所定時間のタイマーを起動する（Ｓ２５）。
　タイマーが終了するまでに次のテスト実行のトリガーが発生しない場合は、優先度算出処理を終了してテストの実施（図６のステップＳ１３以降）を自動的に行う。なお、直近度が高い場合に、テストの実行を先送りするのではなく、前回実施したテストケース１３４とは異なるテストケース１３４が抽出されるよう、これらのテストケース１３４の優先度を高くするようにしてもよい。
　一方、ステップＳ２４で前回のコミットから所定時間以上経過している（直近度が低い）場合は、次に、対象のプログラム１３３の変更部分の差分量が所定以上あるか否かを判定する（Ｓ２６）。差分量が所定より少ない場合は、テスト実施の必要度が低いと判断し、ステップＳ２５に進んでテストの実行を先送りする。ステップＳ２６で差分量が所定以上ある場合は、テストを実行するためにタイマーを解除し（Ｓ２７）、テストケース１３４の抽出を行う（Ｓ２８）。
　テストケース１３４の抽出では、下記の観点を用いて各テストケース１３４に優先度を設定して優先度の高いものが抽出されるようにすることができる。例えば、開発部分との関連度の高いテストケースとして、ブランチのネーミングルールから判別できる機能の種類によって、対応する機能に関連するテストケースを選択したり、対象のプログラム１３３を開発した開発者に割り当てられているタスクやロールなどに基づいて、これらの関連するテストケース１３４を選択することができる。すなわち、開発者がアプリケーションにおけるＰ層（プレゼンテーション層）を担当する開発者であるか、Ｆ層（ファンクション層）やＤ層（データ層）を担当する開発者であるかに応じて、Ｐ層、Ｆ層、Ｄ層に対応するテストケース１３４の優先度を高くすることができる。
　また、対象のプログラム１３３の開発者自身が作成したテストケース１３４について優先度を高くするようにしてもよい。また、前回のテスト実施時に実行されなかったテストケース１３４、もしくは前回実施されてから所定時間以上実施されていないテストケース１３４について、一定期間テストがされていないことから、これらのテストケース１３４が抽出されるよう優先度を高く設定するようにしてもよい。
　なお、図７の例では、テスト対象のブランチがメインブランチか機能ブランチか開発者ブランチかによって作業内容を判定し、テストケース１３４の抽出（優先度の設定）の手法を切り替えているが、対象となるブランチの作業内容としては上記のものに限らず、例えば、バグ対策やリリース準備、レビュー依頼など他の作業内容であることを判定するようにしてもよい。
　また、ブランチの内容によるもの以外に、テストを実施するトリガーとなったコミットの種類に基づいて作業内容を判定することもできる。例えば、対象のコミットが複数のブランチのマージコミットである場合は、機能統合の作業を行っていると推測されることから、全テストケースが実行されるようにしてもよい。また、対象のコミットが通常コミットの場合は、開発内容のアップデートがあったと推測されることから、回帰テストが実行されるよう、対応するテストケース１３４の優先度を高くするようにしてもよい。さらに、コミットの種類の他に、例えば、開発者ブランチが作成されるトリガーとなった課題（Ｉｓｓｕｅ）の種別に基づいて関連するテストケース１３４の優先度を高くするようにしてもよい。
　また、プログラム開発の進捗度（成熟度）に基づいて関連するテストケース１３４が抽出されるように優先度を設定することもできる。例えば、開発したプログラム（ソースコード）に対するレビューの件数や、その結果（ＯＫ／ＮＧの件数）に応じて、進捗度をスコアリングし、進捗度が所定のレベルより低いと判定される場合には全てのテストケース１３４が実行され、進捗度が所定のレベルより高いと判定される場合には重要なテストケース１３４のみ実行されるように優先度を設定することができる。
　図８は、プログラム１３３に対するレビューの処理の流れの例について概要を示したフローチャートである。まず、レビューの要求者が、自身の開発用クライアント２００を用いて、レビュー対象のプログラム１３３を開発支援サーバ１００のリポジトリ１３０から取得し、対象箇所のページをＷｅｂブラウザ２１０上などに表示させる（Ｓ４１）。その後、レビュー要求者が、レビュアーに対するコメントやレビューポイントなどを入力し（Ｓ４２、Ｓ４３）、プログラム１３３をコミットすることによって、レビュー要求を開発支援サーバ１００に対して送信する（Ｓ４４）。
　開発支援サーバ１００では、レビュー要求を受信して、当該要求に係る情報を、例えば、リポジトリ１３０上の後述するレビュー管理テーブル１３６に登録する。その後、レビュアーが、自身の開発用クライアント２００を用いて対象のプログラム１３３の該当箇所をリポジトリ１３０から取得してレビューを実施すると（Ｓ４６）、レビュー結果に基づいて開発支援サーバ１００の構成管理部１１０等がレビュー管理テーブル１３６の内容を更新する（Ｓ４７）。
　上記のようなレビューの件数や結果の情報の他にも、プログラム開発の進捗度を判断する指標としては、例えば、ソースコード中のいわゆる“ＴＯＤＯコメント”の数や空メソッドの数などに基づいて算出するソースコードの完成度や、対象のプログラム１３３に関連するテストケース１３４に対するレビューの進捗度などを用いることができる。また、前回実施したテストの結果、例えば成否の結果の割合や、成功の件数などを用いることもできる。
　＜データ構成＞
　図９は、開発支援サーバ１００のリポジトリ１３０上に保持されるテストケース管理テーブル１３２のデータ構成と具体的なデータの例について概要を示した図である。テストケース管理テーブル１３２は、テストケース１３４の種類などを含む関連情報を保持するテーブルであり、例えば、Ｎｏ．、テストクラス、機能種別、テスト種別、作成者、および優先度などの各項目を有する。
　Ｎｏ．の項目は、各テストケース１３４を一意に識別することができるよう割り振られたシーケンス番号などの情報を保持する。テストクラスの項目は、対象のテストケース１３４として実行するテスト用プログラム（クラス）を特定する名称の情報を保持する。機能種別の項目は、対象のテストケース１３４が対応するアプリケーション上の機能の種別を特定するコード値等の情報を保持する。図９の例では、便宜上、“ＵＩ（User Interface）系”や、“ＤＢ系”、“ロジック系”などの名称によって示されている。
　テスト種別の項目は、対象のテストケース１３４が対応するテストの種別を特定するコード値等の情報を保持する。図９の例では、便宜上、“リグレッション”、“正常系”、“異常系”などの名称によって示されている。作成者の項目は、対象のテストケース１３４を作成した開発者等のユーザを識別するＩＤ等の情報を保持する。この識別情報は、後述する開発者マスタ１３８に設定されている。優先度の項目は、対象のテストケース１３４に対して、上記の図７において示したような優先度算出処理によって算出された優先度の情報を保持する。図９の例では、優先度の値は“１”（抽出対象）もしくは“－１”（非抽出対象）となっているが、優先度の設定方法はこれに限らず、例えば、“１”～“１０”や“１”～“１００”等の数値範囲として設定したり、“Ａ”、“Ｂ”、“Ｃ”のようなランクにより設定したりすることも可能である。
　図１０は、リポジトリ１３０上に保持されるブランチ管理テーブル１３１のデータ構成と具体的なデータの例について概要を示した図である。ブランチ管理テーブル１３１は、開発支援サーバ１００のリポジトリ１３０上に作成されたブランチを管理するテーブルであり、例えば、ブランチ名、およびファイルリストなどの各項目を有する。
　ブランチ名の項目は、各ブランチを一意に識別することができる名称の情報を保持する。この名称は、例えば、図３に示したように、所定のネーミングルールに基づいて設定され、名称から対象のブランチの種別や作業内容等を判別することができるものとする。ファイルリストの項目は、対象のブランチに登録されているプログラム１３３が含まれるファイルのリストからなる情報を保持する。図１０の例では、便宜上ファイル名を列挙したデータとしているが、対象の全ファイル（プログラム１３３）を特定することができるデータ構造であればこれに限定されない。
　図１１は、リポジトリ１３０上に保持されるコミット履歴１３１ａのデータ構成と具体的なデータの例について概要を示した図である。コミット履歴１３１ａは、ブランチにプログラム１３３を登録（コミット）した履歴の情報を保持するテーブルであり、例えば、ブランチ名、コミット日時、および修正内容などの各項目を有する。
　ブランチ名の項目は、プログラム１３３が登録されたブランチを特定するブランチ名の情報を保持する。ブランチ名の情報は、上述した図１０のブランチ管理テーブル１３１に登録されている。コミット日時の項目は、対象のブランチにプログラム１３３がコミットされたタイムスタンプの情報を保持する。修正内容の項目は、対象のブランチに対して修正・変更分としてコミットされたプログラム１３３が含まれるファイル名の情報を保持する。
　図１２は、機能マスタ１３７のデータ構成と具体的なデータの例について概要を示した図である。機能マスタ１３７は、開発対象の機能についてのマスタ情報を保持するテーブルであり、例えば、機能名、および機能種別などの各項目を有する。機能名の項目は、対象の機能を一意に識別するためのＩＤや名称等の情報を保持する。この名称は、上述したブランチのネーミングルールにおいて用いられるものである。機能種別の項目は、上述の図９の例における機能種別の項目と同様に、対象の機能の種別を特定するコード値等の情報を保持する。
　図１３は、開発者マスタ１３８のデータ構成と具体的なデータの例について概要を示した図である。開発者マスタ１３８は、各開発者についてのマスタ情報を保持するテーブルであり、例えば、ユーザ名、および担当業務の各項目を有する。ユーザ名の項目は、対象の開発者を一意に識別することができるＩＤ等の識別情報を保持する。担当業務の項目は、対象の開発者がプログラム開発において担当する１つ以上の業務やタスク、ロール等を特定するためのコード値等の情報を保持する。
　図１４は、リポジトリ１３０上に保持されるレビュー管理テーブル１３６のデータ構成と具体的なデータの例について概要を示した図である。レビュー管理テーブル１３６は、開発対象のプログラム１３３を含むブランチを分岐元のブランチにマージする際のレビューについて管理するテーブルであり、例えば、マージ要求、マージ対象、マージ先、レビュー件数、およびレビュースコアなどの各項目を有する。
　マージ要求の項目は、各マージ要求を一意に識別することができるシーケンス番号やＩＤ等の情報を保持する。マージ対象およびマージ先の項目は、それぞれ、マージの対象となるマージ元のブランチ、およびマージ先（分岐元）のブランチを特定するブランチ名の情報を保持する。レビュー件数の項目は、対象のブランチのマージに係るレビュー要求に対して実施されたレビューの件数の情報を保持する。レビュー要求に対して複数のレビュアーが並行的にレビューを行うことも可能である。レビュースコアの項目は、対象のブランチのマージに係るレビューのスコアの情報を保持する。スコアが高ければ対象のプログラム１３３の品質は高いものと推測され、テストケース１３４の実行を重要なものに限定して行うなどの効率化を図ることも可能となる。
　なお、上述の図９～図１４で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。
　以上に説明したように、本発明の一実施の形態である開発支援システム１によれば、ソーシャルコーディングの環境において、プログラム１３３の開発状況や、テスト実施といった各種観点を考慮した上で、重要なテストケース１３４を抽出し、あるいは優先的に実施することが可能である。これにより、膨大な数のテストケースを網羅的に全て実施することなく、効率的なテストの実施が可能である。
　以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
　また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
　本発明は、プログラムの不具合確認等のためのテストにおけるテストケースを抽出する開発支援システムに利用可能である。
１…開発支援システム、
１００…開発支援サーバ、１１０…構成管理部、１２０…テスト実行部、１３０…リポジトリ、１３１…ブランチ管理テーブル、１３１ａ…コミット履歴、１３２…テストケース管理テーブル、１３３…プログラム、１３４…テストケース、１３５…テスト結果、１３６…レビュー管理テーブル、１３７…機能マスタ、１３８…開発者マスタ、
２００…開発用クライアント、２０１…テストケース付加情報、２１０…Ｗｅｂブラウザ、２２０…コード記述部、２３０…構成管理操作部、
３００…ネットワーク
４０１…マスタブランチ、４０２…開発用ブランチ、４０３…機能Ａ開発用ブランチ、４０４…機能Ａ開発者ＸＸＸ用ブランチ
 
 
 
 
 
 
 

Claims (15)

  1. 　１つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、
    　前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、
    　前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、
    　前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、
    　前記構成管理部は、前記プログラムの開発状況を判定して、前記開発状況に基づいて前記各テストケースに優先度を設定し、
    　前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する、開発支援システム。
  2. 　請求項１に記載の開発支援システムにおいて、
    　前記構成管理部は、前記プログラムが登録されているブランチに基づいて前記開発状況を判定する、開発支援システム。
  3. 　請求項１に記載の開発支援システムにおいて、
    　前記構成管理部は、前記プログラムを対応するブランチにコミットした際の当該コミットの種別に基づいて前記開発状況を判定する、開発支援システム。
  4. 　請求項１に記載の開発支援システムにおいて、
    　前記構成管理部は、前記プログラムの開発に係る課題の種別に基づいて前記開発状況を判定する、開発支援システム。
  5. 　請求項１に記載の開発支援システムにおいて、
    　前記構成管理部は、前記プログラムの開発者に割り当てられているタスクの種別に基づいて前記開発状況を判定する、開発支援システム。
  6. 　１つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、
    　前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、
    　前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、
    　前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、
    　前記構成管理部は、前記プログラムの開発の進捗度を算出して、前記進捗度に基づいて前記各テストケースに優先度を設定し、
    　前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する、開発支援システム。
  7. 　請求項６に記載の開発支援システムにおいて、
    　前記構成管理部は、ブランチに登録された前記プログラムに対するレビューの件数に基づいて前記進捗度を算出する、開発支援システム。
  8. 　請求項６に記載の開発支援システムにおいて、
    　前記構成管理部は、ブランチに登録された前記プログラムに対するレビューのスコアに基づいて前記進捗度を算出する、開発支援システム。
  9. 　請求項６に記載の開発支援システムにおいて、
    　前記構成管理部は、ブランチに登録された前記プログラムにおけるＴＯＤＯコメントの記載の数に基づいて前記進捗度を算出する、開発支援システム。
  10. 　１つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、
    　前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、
    　前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、
    　前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、
    　前記構成管理部は、前記プログラムがブランチに登録されたタイミングに基づいて、登録の直近度を算出して、前記直近度に基づいて前記各テストケースに優先度を設定し、
    　前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する、開発支援システム。
  11. 　請求項１０に記載の開発支援システムにおいて、
    　前記構成管理部は、前記プログラムがブランチに前回登録されたタイミングから、今回登録されたタイミングまでの時間間隔に基づいて前記直近度を算出する、開発支援システム。
  12. 　請求項１０に記載の開発支援システムにおいて、
    　前記構成管理部は、前記プログラムがブランチに登録された過去の所定の回数における、登録間の時間間隔の平均値に基づいて前記直近度を算出する、開発支援システム。
  13. 　請求項１０に記載の開発支援システムにおいて、
    　前記構成管理部は、ブランチに登録された前記プログラムにおける前回の登録からの差分量に基づいて前記直近度を算出する、開発支援システム。
  14. 　請求項１０に記載の開発支援システムにおいて、
    　前記構成管理部は、前記直近度が高い場合に、前記テスト実行部により前記テストケースが抽出されないようにする、開発支援システム。
  15. 　請求項１０に記載の開発支援システムにおいて、
    　前記構成管理部は、前記直近度が高い場合に、前回のテスト実施時に実行された前記テストケースとは異なる前記テストケースの前記優先度を高くする、開発支援システム。
PCT/JP2014/070123 2014-07-30 2014-07-30 開発支援システム WO2016016975A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US14/782,881 US9703692B2 (en) 2014-07-30 2014-07-30 Development supporting system
JP2015541720A JP5970617B2 (ja) 2014-07-30 2014-07-30 開発支援システム
PCT/JP2014/070123 WO2016016975A1 (ja) 2014-07-30 2014-07-30 開発支援システム
CN201480020875.6A CN105453050A (zh) 2014-07-30 2014-07-30 开发辅助***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/070123 WO2016016975A1 (ja) 2014-07-30 2014-07-30 開発支援システム

Publications (1)

Publication Number Publication Date
WO2016016975A1 true WO2016016975A1 (ja) 2016-02-04

Family

ID=55216918

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/070123 WO2016016975A1 (ja) 2014-07-30 2014-07-30 開発支援システム

Country Status (4)

Country Link
US (1) US9703692B2 (ja)
JP (1) JP5970617B2 (ja)
CN (1) CN105453050A (ja)
WO (1) WO2016016975A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108241580A (zh) * 2016-12-30 2018-07-03 深圳壹账通智能科技有限公司 客户端程序的测试方法及终端
JP2019506682A (ja) * 2016-06-07 2019-03-07 株式会社日立製作所 アプリケーションの頻度及び変化量に基づいて適切なｉｔリソース上にアプリケーションを配備するための方法及び装置
WO2022190772A1 (ja) * 2021-03-10 2022-09-15 株式会社日立製作所 ソフトウェア性能検証システム、およびソフトウェア性能検証方法

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9740585B2 (en) 2015-06-23 2017-08-22 International Business Machines Corporation Flexible configuration and control of a testing system
CN106227658A (zh) * 2016-07-15 2016-12-14 珠海市魅族科技有限公司 一种测试用例的管理方法、***及装置
EP3497574A4 (en) 2016-08-09 2020-05-13 Sealights Technologies Ltd. SYSTEM AND METHOD FOR THE CONTINUOUS EXAMINATION AND PROVISION OF SOFTWARE
CN106372514A (zh) * 2016-08-30 2017-02-01 东软集团股份有限公司 一种安全漏洞维护方法及***
CN110447018B (zh) * 2017-03-23 2023-02-10 日本电气株式会社 操作管理服务器、开发操作支持***及其方法以及存储其程序的非暂时性计算机可读介质
US10365994B2 (en) * 2017-04-24 2019-07-30 Facebook, Inc. Dynamic scheduling of test cases
CN107622017B (zh) * 2017-10-13 2020-09-15 深圳市视维科技股份有限公司 一种通用自动化软件测试的解析方法
US11573885B1 (en) * 2019-09-26 2023-02-07 SeaLights Technologies LTD System and method for test selection according to test impact analytics
CN111274126B (zh) * 2020-01-14 2022-10-04 华为云计算技术有限公司 测试用例筛选方法、装置及介质
US11263120B2 (en) * 2020-02-12 2022-03-01 Capital One Services, Llc Feature-based deployment pipelines
US11321083B2 (en) * 2020-02-18 2022-05-03 The Toronto-Dominion Bank Automated branching workflow for a version control system
US11307975B2 (en) 2020-02-20 2022-04-19 International Business Machines Corporation Machine code analysis for identifying software defects
US11176026B2 (en) 2020-02-20 2021-11-16 International Business Machines Corporation Assignment of test case priorities based on combinatorial test design model analysis
US11663113B2 (en) * 2020-02-20 2023-05-30 International Business Machines Corporation Real time fault localization using combinatorial test design techniques and test case priority selection
US11792482B2 (en) 2020-10-14 2023-10-17 Dish Network L.L.C. Visual testing based on machine learning and automated workflow
CN112817848B (zh) * 2021-01-28 2024-03-12 北京达佳互联信息技术有限公司 一种测试信息展示方法、装置、电子设备和存储介质
US11989120B2 (en) * 2021-05-25 2024-05-21 Dish Network L.L.C. Visual testing issue reproduction based on communication of automated workflow
US11709765B1 (en) * 2022-01-04 2023-07-25 Bank Of America Corporation Intelligent test cases generation based on voice conversation
CN117435512B (zh) * 2023-12-21 2024-03-08 摩尔元数(福建)科技有限公司 一种基于Junit5自动切换不同数据库类型的单元测试方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7568183B1 (en) * 2005-01-21 2009-07-28 Microsoft Corporation System and method for automation testing and validation

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8561036B1 (en) * 2006-02-23 2013-10-15 Google Inc. Software test case management
US20070220479A1 (en) * 2006-03-14 2007-09-20 Hughes John M Systems and methods for software development
JP2008003985A (ja) * 2006-06-26 2008-01-10 Dainippon Screen Mfg Co Ltd 開発支援システム、開発支援方法および開発支援プログラム
US7913230B2 (en) * 2007-01-31 2011-03-22 Oracle International Corporation Computer-implemented methods and systems for generating software testing documentation and test results management system using same
JP4939973B2 (ja) 2007-02-22 2012-05-30 富士通株式会社 試験制御装置、試験制御方法及び試験制御プログラム
JP2009181536A (ja) * 2008-02-01 2009-08-13 Dainippon Screen Mfg Co Ltd ソフトウェアの障害管理装置、テスト管理装置、ならびにそれらのプログラム
US20090265694A1 (en) * 2008-04-18 2009-10-22 International Business Machines Corporation Method and system for test failure analysis prioritization for software code testing in automated test execution
US8276123B1 (en) * 2008-07-22 2012-09-25 Juniper Networks, Inc. Adaptive regression test selection within testing environments
CN101727385A (zh) * 2008-10-31 2010-06-09 国际商业机器公司 用于处理用户接口信息变化的方法和***
US20100131497A1 (en) * 2008-11-26 2010-05-27 Peterson Michael L Method for determining which of a number of test cases should be run during testing
JP5213671B2 (ja) 2008-12-03 2013-06-19 株式会社日立ソリューションズ テストケースの選択方法及び選択システム
US8645341B2 (en) * 2010-03-31 2014-02-04 Salesforce.Com, Inc. Method and system for automatically updating a software QA test repository
US8826239B2 (en) * 2010-10-06 2014-09-02 International Business Machines Corporation Asynchronous code testing in integrated development environment (IDE)
JP5479389B2 (ja) * 2011-03-04 2014-04-23 エンカレッジ・テクノロジ株式会社 情報処理システム、プログラム改修装置、プログラム改修方法、及びプログラム
JP5629239B2 (ja) * 2011-05-23 2014-11-19 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ ソフトウェアの動作をテストする装置及び方法
CN103257918A (zh) * 2012-02-16 2013-08-21 广州博纳信息技术有限公司 基于软件测评平台的项目测试过程管理方法
US9092578B2 (en) * 2012-12-20 2015-07-28 Sap Se Automated end-to-end testing via multiple test tools
US9311223B2 (en) * 2013-05-21 2016-04-12 International Business Machines Corporation Prioritizing test cases using multiple variables

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7568183B1 (en) * 2005-01-21 2009-07-28 Microsoft Corporation System and method for automation testing and validation

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KIM, TAESOO ET AL.: "Optimizing unit test execution in large software programs using dependency analysis", PROCEEDINGS OF THE 4TH ASIA-PACIFIC WORKSHOP ON SYSTEMS (APSYS '13, 2013, pages 1 - 6 *
MASAYUKI HIRAYAMA ET AL.: "Software Quality Improvement Techniques", TOSHIBA REVIEW, vol. 56, no. 11, 1 November 2001 (2001-11-01), pages 47 - 55 *
SHUN TAJIMA ET AL.: "Source Code Koshin Joho o Mochiita Test Chakushu Jiki no Yosoku", IPSJ SIG NOTES, 11 March 2013 (2013-03-11), pages 1 - 7 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019506682A (ja) * 2016-06-07 2019-03-07 株式会社日立製作所 アプリケーションの頻度及び変化量に基づいて適切なｉｔリソース上にアプリケーションを配備するための方法及び装置
CN108241580A (zh) * 2016-12-30 2018-07-03 深圳壹账通智能科技有限公司 客户端程序的测试方法及终端
WO2022190772A1 (ja) * 2021-03-10 2022-09-15 株式会社日立製作所 ソフトウェア性能検証システム、およびソフトウェア性能検証方法
JP7514785B2 (ja) 2021-03-10 2024-07-11 株式会社日立製作所 ソフトウェア性能検証システム、およびソフトウェア性能検証方法

Also Published As

Publication number Publication date
US9703692B2 (en) 2017-07-11
JP5970617B2 (ja) 2016-08-17
JPWO2016016975A1 (ja) 2017-04-27
CN105453050A (zh) 2016-03-30
US20160378647A1 (en) 2016-12-29

Similar Documents

Publication Publication Date Title
JP5970617B2 (ja) 開発支援システム
US10642599B1 (en) Preemptive deployment in software deployment pipelines
US11048688B2 (en) Deleting configuration items in a configuration management database
US8312430B2 (en) Guarding code check-in with test case execution results
CN107102916B (zh) 在服务的次要位置重放作业
US20160191332A1 (en) Management infrastructure analysis for cloud migration
US9754242B2 (en) Deployment mechanism for non-versioning business process artifacts
US8661418B2 (en) Setting program, workflow creating method, and work flow creating apparatus
US10877846B2 (en) Performing a closure merge operation
US20140207920A1 (en) Virtual server migration plan making method and system
US9892019B2 (en) Use case driven stepping component automation framework
An et al. An empirical study of crash-inducing commits in mozilla firefox
US11099834B2 (en) Software builds using a cloud system
US11989539B2 (en) Continuous integration and deployment system time-based management
JP6385471B2 (ja) 移行および遠隔ランタイム統合
US10599424B2 (en) Committed program-code management
JP6336919B2 (ja) ソースコードレビュー方法及びそのシステム
CN110321132B (zh) 一种代码发布方法和装置
US10684881B2 (en) Batch processing of computing elements to conditionally delete virtual machine(s)
US20230409386A1 (en) Automatically orchestrating a computerized workflow
CN117648198B (zh) 应用适配方法及装置、设备及存储介质
US20240256397A1 (en) Service/Workload Recovery And Restoration In Container Orchestration Systems
KR101866086B1 (ko) 재사용 기반의 가상 클러스터 구축 방법 및 장치
JP2017091027A (ja) システム開発支援システム
US20200349043A1 (en) Software Installation System, Software Installation Method, and Software Installation Program

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201480020875.6

Country of ref document: CN

ENP Entry into the national phase

Ref document number: 2015541720

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14782881

Country of ref document: US

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

Ref document number: 14898680

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: 14898680

Country of ref document: EP

Kind code of ref document: A1