WO2016016975A1 - 開発支援システム - Google Patents
開発支援システム Download PDFInfo
- 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
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
図1は、本発明の一実施の形態である開発支援システムの構成例について概要を示した図である。開発支援システム1は、例えば、開発支援サーバ100に対して、LAN(Local Area Network)などのネットワークを介して、各ユーザがそれぞれ使用する開発用クライアント200が複数接続され、相互に通信可能な構成を有する。
以下では、本実施の形態におけるテスト実施の際の各処理について説明する。図5は、テストケース作成の処理の流れの例について概要を示したフローチャートである。まず、テストケースの作成者が、開発用クライアント200を利用して、コード記述部220によりテストケース134を作成し、開発支援サーバ100の構成管理部110を介してリポジトリ130に登録する(S01)。このとき、構成管理部110では、テストケース134の種類などを含む関連情報を割り当てて、後述するテストケース管理テーブル132に併せて登録する(S02)。
図6は、作成されたテストケース134に基づくテスト実行の処理の流れの例について概要を示したフローチャートである。まず、プログラム133の開発者が、開発用クライアント200を利用して、コード記述部220および構成管理操作部230により、開発したプログラム133を開発支援サーバ100のリポジトリ130に登録(コミット)する(S11)。ここでの登録は、例えば、変更や修正に係る差分のみを登録する形式とすることができる。登録したプログラム133の情報は、ブランチ毎に後述するブランチ管理テーブル131によって管理する。また、プログラム133を登録した履歴は、後述するコミット履歴131aによって管理する。
図7は、図6に示したテスト実行の処理フローにおける優先度算出処理(S12)の流れの例について概要を示したフローチャートである。まず、開発支援サーバ100の構成管理部110もしくはテスト実行部120が、テストの対象のプログラム133が登録されているリポジトリ130上のブランチの作業内容を判定する(S21)。ブランチの作業内容は、例えば、図3に示したように、ブランチのネーミングルールに基づいて判断することができる。
図9は、開発支援サーバ100のリポジトリ130上に保持されるテストケース管理テーブル132のデータ構成と具体的なデータの例について概要を示した図である。テストケース管理テーブル132は、テストケース134の種類などを含む関連情報を保持するテーブルであり、例えば、No.、テストクラス、機能種別、テスト種別、作成者、および優先度などの各項目を有する。
100…開発支援サーバ、110…構成管理部、120…テスト実行部、130…リポジトリ、131…ブランチ管理テーブル、131a…コミット履歴、132…テストケース管理テーブル、133…プログラム、134…テストケース、135…テスト結果、136…レビュー管理テーブル、137…機能マスタ、138…開発者マスタ、
200…開発用クライアント、201…テストケース付加情報、210…Webブラウザ、220…コード記述部、230…構成管理操作部、
300…ネットワーク
401…マスタブランチ、402…開発用ブランチ、403…機能A開発用ブランチ、404…機能A開発者XXX用ブランチ
Claims (15)
- 1つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、
前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、
前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、
前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、
前記構成管理部は、前記プログラムの開発状況を判定して、前記開発状況に基づいて前記各テストケースに優先度を設定し、
前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する、開発支援システム。 - 請求項1に記載の開発支援システムにおいて、
前記構成管理部は、前記プログラムが登録されているブランチに基づいて前記開発状況を判定する、開発支援システム。 - 請求項1に記載の開発支援システムにおいて、
前記構成管理部は、前記プログラムを対応するブランチにコミットした際の当該コミットの種別に基づいて前記開発状況を判定する、開発支援システム。 - 請求項1に記載の開発支援システムにおいて、
前記構成管理部は、前記プログラムの開発に係る課題の種別に基づいて前記開発状況を判定する、開発支援システム。 - 請求項1に記載の開発支援システムにおいて、
前記構成管理部は、前記プログラムの開発者に割り当てられているタスクの種別に基づいて前記開発状況を判定する、開発支援システム。 - 1つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、
前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、
前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、
前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、
前記構成管理部は、前記プログラムの開発の進捗度を算出して、前記進捗度に基づいて前記各テストケースに優先度を設定し、
前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する、開発支援システム。 - 請求項6に記載の開発支援システムにおいて、
前記構成管理部は、ブランチに登録された前記プログラムに対するレビューの件数に基づいて前記進捗度を算出する、開発支援システム。 - 請求項6に記載の開発支援システムにおいて、
前記構成管理部は、ブランチに登録された前記プログラムに対するレビューのスコアに基づいて前記進捗度を算出する、開発支援システム。 - 請求項6に記載の開発支援システムにおいて、
前記構成管理部は、ブランチに登録された前記プログラムにおけるTODOコメントの記載の数に基づいて前記進捗度を算出する、開発支援システム。 - 1つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、
前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、
前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、
前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、
前記構成管理部は、前記プログラムがブランチに登録されたタイミングに基づいて、登録の直近度を算出して、前記直近度に基づいて前記各テストケースに優先度を設定し、
前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する、開発支援システム。 - 請求項10に記載の開発支援システムにおいて、
前記構成管理部は、前記プログラムがブランチに前回登録されたタイミングから、今回登録されたタイミングまでの時間間隔に基づいて前記直近度を算出する、開発支援システム。 - 請求項10に記載の開発支援システムにおいて、
前記構成管理部は、前記プログラムがブランチに登録された過去の所定の回数における、登録間の時間間隔の平均値に基づいて前記直近度を算出する、開発支援システム。 - 請求項10に記載の開発支援システムにおいて、
前記構成管理部は、ブランチに登録された前記プログラムにおける前回の登録からの差分量に基づいて前記直近度を算出する、開発支援システム。 - 請求項10に記載の開発支援システムにおいて、
前記構成管理部は、前記直近度が高い場合に、前記テスト実行部により前記テストケースが抽出されないようにする、開発支援システム。 - 請求項10に記載の開発支援システムにおいて、
前記構成管理部は、前記直近度が高い場合に、前回のテスト実施時に実行された前記テストケースとは異なる前記テストケースの前記優先度を高くする、開発支援システム。
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108241580A (zh) * | 2016-12-30 | 2018-07-03 | 深圳壹账通智能科技有限公司 | 客户端程序的测试方法及终端 |
JP2019506682A (ja) * | 2016-06-07 | 2019-03-07 | 株式会社日立製作所 | アプリケーションの頻度及び変化量に基づいて適切なitリソース上にアプリケーションを配備するための方法及び装置 |
WO2022190772A1 (ja) * | 2021-03-10 | 2022-09-15 | 株式会社日立製作所 | ソフトウェア性能検証システム、およびソフトウェア性能検証方法 |
Families Citing this family (19)
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)
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)
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 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | ソフトウェアの動作をテストする装置及び方法 |
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 |
-
2014
- 2014-07-30 CN CN201480020875.6A patent/CN105453050A/zh active Pending
- 2014-07-30 WO PCT/JP2014/070123 patent/WO2016016975A1/ja active Application Filing
- 2014-07-30 JP JP2015541720A patent/JP5970617B2/ja not_active Expired - Fee Related
- 2014-07-30 US US14/782,881 patent/US9703692B2/en not_active Expired - Fee Related
Patent Citations (1)
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)
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2019506682A (ja) * | 2016-06-07 | 2019-03-07 | 株式会社日立製作所 | アプリケーションの頻度及び変化量に基づいて適切なitリソース上にアプリケーションを配備するための方法及び装置 |
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 |