WO2020107142A1 - 一种软件质量度量方法及系统 - Google Patents

一种软件质量度量方法及系统 Download PDF

Info

Publication number
WO2020107142A1
WO2020107142A1 PCT/CN2018/117388 CN2018117388W WO2020107142A1 WO 2020107142 A1 WO2020107142 A1 WO 2020107142A1 CN 2018117388 W CN2018117388 W CN 2018117388W WO 2020107142 A1 WO2020107142 A1 WO 2020107142A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
quality
attribute
metric
data
Prior art date
Application number
PCT/CN2018/117388
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 PCT/CN2018/117388 priority Critical patent/WO2020107142A1/zh
Publication of WO2020107142A1 publication Critical patent/WO2020107142A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software

Definitions

  • the present invention relates to a software quality measurement method and system, and more particularly, to a software quality measurement method and system for vehicle control software.
  • MISRA Automotive Software Process Improvement Capacity and Capacity Evaluation is a joint initiative of major European car manufacturers for automotive
  • ASPICE Automotive Software Process Improvement Capacity and Capacity Evaluation is a joint initiative of major European car manufacturers for automotive
  • the process evaluation model of the industry aims to improve and evaluate the quality of the system and software development of automotive electronic controllers
  • MISRA C (2012) (MISRA: The Motor, Industry, Software, Reliability, Association of Automotive Industry Software Reliability Association is a multinational automobile located in the UK Industry Association, the MSIRA C series specification proposed by the association has become a widely recognized and adhered to the C code specification in the international automotive industry) and MAAB (MathWorksAutomotiveAdvisoryBoardMax Walker Automotive Advisory Committee, the control algorithm modeling specification proposed by the committee is the automobile Software MBD (Model-Based Development Model-based software development) must comply with the specifications) and so on.
  • a method for automatically measuring software quality includes: acquiring software characteristics of software to be measured; selecting quality measurement attributes based on the acquired software characteristics; Each quality measurement attribute in the quality measurement attribute is assigned a weight; obtaining software development process quality data and software operation and maintenance process quality data; based on at least one of the acquired software development process quality data and software operation and maintenance process quality data, for Calculating a quality attribute metric value for each of the quality metric attributes; calculating a weighted quality metric value for the software based on the quality attribute metric value and its corresponding weight; and determining the quality of the software based on the weighted quality metric value .
  • a system for automatically measuring software quality includes: a software test management unit for generating and storing software development process quality data; a software operation and maintenance data management unit, Used to generate and store software operation and maintenance process quality data; software quality measurement unit for software development process quality data obtained from the software test management unit and software operation and maintenance process obtained from the software operation and maintenance data management unit Quality data measures the quality of the software to be measured; and a user interface unit for providing an interface for users to interact with the software test management unit, the software operation and maintenance data management unit, and the software quality measurement unit.
  • a computer-readable storage medium having computer-executable instructions stored thereon, the computer-executable instructions when executed by a computer are used for automatic measurement as described in the present invention Method of software quality.
  • the present invention uses software quality metrics for vehicle software as an example to describe the principles, embodiments, and specific technical means of the present invention.
  • software quality measurement method and system of the present invention are not limited to software for vehicles, but can be generally applied to the quality measurement of any software, and are particularly suitable for the quality assessment of software developed based on models.
  • the present invention solves at least the following problems:
  • the present invention achieves at least the following technical effects:
  • the present invention provides a method and system for software quality measurement based on model development (especially for functional safety software);
  • the present invention provides a method and system for software unit-level quality measurement, and also implements quality measurement for the entire software life cycle;
  • the present invention provides a quality measurement method and system that considers compliance with software standards.
  • the present invention provides a method and system for automatically obtaining software quality data for quality measurement in combination with a software test management unit and a software operation and maintenance data management unit.
  • FIG. 1 is a structural block diagram of a software quality measurement system according to an embodiment of the present invention.
  • FIG. 2 shows an exemplary software development process quality data structure according to an embodiment of the present invention.
  • FIG. 3 illustrates exemplary software development process quality attributes according to one embodiment of the invention.
  • FIG. 4 is a flowchart of a method for generating quality data of a software development process according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of a method for generating quality data of a software operation and maintenance process according to an embodiment of the present invention.
  • FIG. 6 is a flowchart of a method for performing software quality measurement according to an embodiment of the present invention.
  • FIG. 1 is a structural block diagram of a software quality measurement system 100 according to an embodiment of the present invention.
  • the software quality measurement system 100 may include a user interface unit 102, a software test management unit 104, a software operation and maintenance data management unit 106, and a software quality measurement unit 108.
  • the above four units are shown as independent units. However, those skilled in the art should be able to understand that the above-mentioned units can be arbitrarily combined and integrated as needed, or can be further split according to needs and functions.
  • the user interface unit 102 can serve as a unified interface for the software test management unit 104, the software operation and maintenance data management unit 106, and the software quality measurement unit 108, and is used to provide interfaces for software development engineers, software test engineers, data analysis engineers, and software quality measurement engineers Execute software upload, test request initiation, test case writing, test triggering, data management and analysis, software quality measurement model design, etc.
  • the interface may be implemented as a software client, a web-based user interface, or any other user interface suitable for facilitating user access to the vehicle control software quality measurement system.
  • the system may be designed to have different clients for different units.
  • the software test management module, the software operation and maintenance data management module, and the software quality measurement module may be designed for the software test management unit 104, the software operation and maintenance data management unit 106, and the software quality measurement unit 108, respectively.
  • Different users can log in to different modules according to their different identities and job responsibilities.
  • This design method is suitable for the situation in which the software test management unit 104, the software operation and maintenance data management unit 106, and the software quality measurement unit 108 are distributed and deployed in corresponding places. In this case, the user responsible for software testing only needs to install the part of the system related to the software testing management unit 104.
  • the system can also be designed to have a unified user login interface.
  • This design method is suitable for the case where the software test management unit 104, the software operation and maintenance data management unit 106, and the software quality measurement unit 108 are centrally deployed on the server/cloud. For example, when different users access the system through a unified client or through the web, after logging in under the unified login interface, the system can automatically jump to the corresponding module and present the corresponding user interface according to their identity and job responsibilities.
  • the software test management unit 106 is mainly used to generate quality data of the software development process. To this end, according to an embodiment of the present invention, the software test management unit may consider and manage various elements related to software development and testing. Elements include but are not limited to: software requirements, software to be tested, test cases/configuration, and continuous Integration, and testing tool chain.
  • Software requirements derived from product requirements and managed in a demand management tool is the basis for software development and software testing.
  • the software development engineer can develop the software according to the software requirements and upload the software to the file management system of the software test management unit 106 (for example, Subversion (SVN for short), an open source version control system management tool).
  • SVN Subversion
  • Test cases The software test engineer can develop test requirements and write test cases according to the software requirements, and upload the test cases to the file management system of the software test management unit 106.
  • Test configuration The software test engineer can set the parameters of the test tool chain, select and sequence the required test items, select the required test cases, select the controlled object model used to build the closed-loop system, and select all The test report template needs to be selected, and the relevant personnel who receive the test result emails should be selected.
  • the software test management unit 106 can call the software test tool chain for software testing based on event triggering (such as automatic triggering or automatic timing triggering when the software to be tested or test cases are updated and uploaded), and automatically generate test reports and output Structured software development process quality data.
  • event triggering such as automatic triggering or automatic timing triggering when the software to be tested or test cases are updated and uploaded
  • Test tool chain tools that can be called by the software test management unit to perform software testing. These tools may include categories as listed in Table 1 below, and include but are not limited to example tools listed in each category.
  • FIG. 2 shows an exemplary software development process quality data structure according to an embodiment of the present invention.
  • the quality data of the software development process may include, but is not limited to, the structured information listed in FIG. 2.
  • the data structure can be divided into architecture, unit, model static verification, code static verification, model test, code test, PIL (Processor-in-Loop processor-in-the-loop) test, and requirement verification according to the software development process. Waiting for eight nodes, each node can be set with a different number of child nodes.
  • unit nodes can be added according to the actual number of software units; task subnodes (such as model static verification, code static verification, model testing, code testing, PIL testing, and requirements verification mentioned above) can be based on the actual number of software tasks Add to.
  • task subnodes such as model static verification, code static verification, model testing, code testing, PIL testing, and requirements verification mentioned above
  • the above-mentioned nodes and structured information may be allocated, combined, or increased or decreased in any other suitable form, and the present invention is not limited to the actual structure of the illustrated structured information.
  • the aforementioned software development process quality data structure contains a variety of structured information. Table 2 below gives examples of the format of these structured information values. It should be noted that those skilled in the art can understand that the present invention is not limited to the specific format of the illustrated structured information value. Table 2 Example of formatted information value format for quality data of software development process
  • the above structured information can be stored and managed using XML language (but not limited to XML language).
  • XML language but not limited to XML language.
  • the structured information name corresponds to an element or attribute in the XML language
  • the structured information value corresponds to a text or attribute value (Attr.Value) in the XML language.
  • the software operation and maintenance data management unit 106 can store and manage the vehicle operation data sent by the vehicle control unit and collected and uploaded by the vehicle-mounted terminal. These vehicle operating data can be analyzed to obtain structured software operation and maintenance process quality data.
  • the quality data of the software operation and maintenance process may mainly include but not limited to the structured information listed in Table 3 below. Unlike the quality data at the software development stage, the quality data structure at the software operation and maintenance stage is relatively simple. Similarly, those skilled in the art can understand that the present invention is not limited to the specific format of the structured information values listed in the table. This information can be managed together with the quality data of the software development stage using XML language.
  • the software quality measurement unit 108 can communicate with the software test management unit 104 and the software operation and maintenance data management unit 106 through the network, which means that the software quality measurement unit 108 can both communicate with the software test management unit 104 and the software operation and maintenance
  • the data management units 106 are deployed together in the same local area network, or can be distributed in different locations and communicatively coupled through the Internet. No matter what communication coupling method is adopted, the software quality measurement unit 108 may obtain the above-mentioned software development process quality data and software operation and maintenance process quality data through the network. Subsequently, the software quality measurement unit 108 may use the quality data processing function to process the acquired data and assign quality measurement attributes of one or more dimensions.
  • quality measurement attributes such as standard compliance, functional compliance, performance compliance, reliability, and maintainability
  • quality measurement attributes such as standard compliance, functional compliance, performance compliance, reliability, and maintainability
  • a specific quality measurement algorithm can be used and the corresponding quality measurement weights can be assigned to calculate the quality measurement of the software from the above five dimensions and form the final software quality measurement result, and automatically generate the software quality measurement report.
  • Software quality measurement results and reports can be displayed to relevant users in the form of emails or web pages.
  • the software quality measurement platform and method described in the present invention are not limited to the quality measurement of vehicle control software, but can be applied to the quality measurement of any software.
  • an automated quality measurement for the entire life cycle of the software can be realized by using the basic architecture and method of the quality measurement platform described in the present invention and designing a corresponding quality measurement model.
  • the present invention provides an exemplary quality metric model design.
  • the quality measurement model may include elements such as quality measurement attributes, quality data processing functions, quality measurement algorithms, quality measurement weights, and quality decision rules.
  • the quality data of the aforementioned software development process and software operation and maintenance process can be assigned to five quality measurement attributes such as standard compliance, functional compliance, performance compliance, reliability, and maintainability according to different data types, and their distribution methods As shown in Figure 3.
  • FIG. 3 illustrates exemplary software development process quality attributes according to one embodiment of the invention.
  • the software quality measurement attributes are divided into five levels, namely first-level attributes, second-level attributes, third-level attributes, fourth-level attributes, and fifth-level attributes, and a multi-level sequence number pair in the format of "ijklm" is used Each quality measurement attribute is uniquely distinguished. It should be noted that the above-mentioned quality measurement attributes can be organized and distributed in other forms, and the present invention is not limited to the listed classification methods of the quality measurement attributes.
  • Quality measurement processing refers to the process of processing software quality data (original values) of different types and different formats into normalized quality data measurement values through a specific quality data processing function.
  • the independent variable of the quality data processing function is the original value of the quality data
  • the dependent variable is the measurement value of the quality data.
  • Different types of quality data have different processing functions, but they should follow the following common rules:
  • the range of the quality data processing function should be one of [p, q], [p, q), (p, q], p and q can be arbitrarily specified, but must be fixed in a set of quality measurement models
  • the quality measurement algorithm refers to a method of calculating the quality measurement result using a linear weighting method based on the aforementioned quality data measurement value.
  • the metric weights involved in the linear weighting method will be described in more detail in a later section.
  • the software quality measurement algorithm is mainly affected by the following three aspects of software characteristics.
  • model-level quality data such as model specification compliance rate data
  • code-level quality data such as coding specification compliance rate data
  • the process of the software is the development process or the operation and maintenance process.
  • the development process can also be subdivided into more sub-processes according to the "V" model.
  • the operation and maintenance process can also be divided into two sub-processes: trial operation process and operation and maintenance process. Examples of the impact of different software processes on quality measurement algorithms are as follows:
  • MC/DC coverage data may not be used, and so on.
  • the software quality measurement engineer can tailor the quality measurement attributes such as shown in FIG. 3 on the basis of fully understanding the above-mentioned software characteristics to form a specific quality measurement attribute subset required to meet the software to be measured.
  • Software quality measurement algorithms should be developed based on this specific subset of quality measurement attributes.
  • the present invention is not limited to the specific tailoring method of the listed quality metric attribute subsets. The following describes the general principle of the quality measurement algorithm based on a certain quality measurement attribute subset C.
  • the quality measurement attribute subset C has x first-level attributes
  • the quality measurement algorithm can be divided into the following five steps:
  • Step 1 Measure the four-level attribute based on the five-level attribute measurement value respectively, in which the calculation formula of the four-level attribute measurement number of the i.j.k.l is:
  • SQM ijkln The measurement value of the five-level attribute with serial number ijkln;
  • Step 2 Based on the measurement values of the fourth-level attributes, measure the attributes of the third-level attributes respectively.
  • the calculation formula of the measurement values of the third-level attributes with the sequence number i.j.k is:
  • Step 3 Measure the second-level attributes based on the measurement values of the third-level attributes.
  • the calculation formula of the second-level attributes with the sequence number i.j is:
  • Step 4 Measure the first-level attributes based on the metric values of the second-level attributes.
  • the formula for calculating the metric values of the first-level attributes with sequence number i is:
  • Step 5 Calculate the final quality metric based on the metric values of x first-level attributes.
  • the calculation formula is:
  • quality metric weights can be assigned for each dimension of software quality metrics.
  • the weight distribution can be carried out according to the APH (Analytic Hierarchy) level analysis method commonly used in the field, or manually according to the experience of engineers.
  • the present invention is not limited to a specific weight distribution scheme. However, it should be noted that the weight distribution of quality metrics should preferably consider the following principles:
  • Quality judgment refers to judging the software quality measurement conclusion SQC based on the above SQM value.
  • This patent divides SQ into three grades of Good, Acceptable and Bad, so two SQM thresholds are set accordingly, th and tl, respectively, as software quality judgment Guidelines. The relationship between them is shown in Table 5. It should be noted that the SQM threshold used as a criterion for software quality judgment can be increased or decreased as needed, and the present invention is not limited to the specific number and value of the SQM thresholds listed.
  • the software quality measurement process can be designed to be roughly divided into two stages of software quality data generation and software quality measurement.
  • FIG. 4 is a flowchart of a method 400 for generating software development process quality data according to an embodiment of the present invention.
  • the generation of quality data of the software development process may be performed by a software test management unit (for example, the software test management unit 104 in FIG. 1 ).
  • the method 400 starts at step 402 where the software test management unit can read the file management system (eg SVN). More specifically, the software test management unit can read from the file management system the software to be tested and the test cases that have been uploaded to the file management system before.
  • the file management system eg SVN
  • the software test management unit may detect whether a test trigger event has occurred.
  • the test trigger event may include, for example, a file management system in which the software to be tested or the test case is updated and uploaded to the software test management unit.
  • the test triggering event may also include automatic test timing coming. For example, you can set the software to be tested or test cases to be tested at fixed intervals.
  • the software testing management unit may perform software testing.
  • the software test management unit 104 may perform software testing on the software to be tested or test cases by invoking the software testing tool chain.
  • the software test management unit may generate software development process quality data based on the test results.
  • generating software development process quality data may include automatically generating test packages, and outputting structured software development process quality data.
  • the software development process quality data may be stored and managed using XML language or any other suitable structured language.
  • FIG. 5 is a flowchart of a method 500 for generating quality data of a software operation and maintenance process according to an embodiment of the present invention.
  • the generation of the software operation and maintenance process quality data may be performed by the software operation and maintenance data management unit (for example, the software operation and maintenance data management unit 106 in FIG. 1 ).
  • the method 500 starts at step 502, where the software operation and maintenance data is read.
  • the software to be tested is vehicle software
  • software operation and maintenance data is vehicle terminal data.
  • the vehicle-mounted terminal data may be vehicle operation data collected by the vehicle-mounted terminal from the vehicle control unit and uploaded to the software operation and maintenance data management unit.
  • step 504 the read software operation and maintenance data can be analyzed, and in step 506, software operation and maintenance process quality data is generated.
  • software operation and maintenance data (such as vehicle operation data) can be manually analyzed by a data analysis engineer, or can be automatically analyzed by a software operation and maintenance data management unit based on predetermined data analysis rules and algorithms.
  • the generated software operation and maintenance process quality data can adopt structured data structure. These data can be stored and managed in the same structured language (eg XML language) as the quality data in the software development stage.
  • FIG. 6 is a flowchart of a method 600 for performing software quality measurement according to an embodiment of the present invention.
  • the generation of software operation and maintenance process quality data may be performed by a software operation and maintenance data management unit (for example, the software quality measurement unit 108 in FIG. 1 ).
  • the method 600 starts at step 602, where the software characteristics of the software to be measured are obtained.
  • software characteristics may include software development methods, the processes in which the software is located, and quality measurement levels (such as ASIL levels).
  • the quality metric attributes may be tailored to form a specific subset of quality metric attributes that meet the requirements of the software to be measured.
  • a unified quality measurement platform may be designed to use a considerable number of measurement attributes that contain multiple levels. However, for specific testing needs, not all measurement attributes need to be measured.
  • the step of tailoring the subset of quality measurement attributes is optional, and it is also feasible to directly consider all the quality measurement attributes in the designed quality measurement model as attributes to be considered, for example At the design stage of the quality measurement model, the design can only include the measurement attributes necessary for the specific requirements of the software under test.
  • each quality metric attribute in the clipped quality attribute subset may be assigned a weight.
  • the present invention is not limited to a specific weight distribution scheme. Under certain circumstances, it is also possible not to set weights (that is, the weights are equally divided in all measurement dimensions).
  • steps 606 and 608 software development process quality data and software operation and maintenance process quality data are acquired, respectively.
  • the software development process quality data may be received by the software quality measurement unit 108 from the software test management unit 104 through the network
  • the software operation and maintenance process quality data may be received from the software operation and maintenance data management unit 106 through the network.
  • step 610 After receiving the software development process quality data and software operation and maintenance process quality data, in step 610, for each item of data received, a software quality attribute metric is calculated. The calculation of the metric value can be performed based on the quality data processing function described previously. Subsequently, in step 612, a weighted software quality metric is calculated based on the calculated software quality attribute metric and the corresponding weight. Finally, in step 614, according to the preset quality judgment criteria, the quality of the software can be judged, and a judgment structure is given, such as Good, Acceptable or Bad.
  • the software quality measurement method and system proposed by the present invention increases the special measurement attribute of the compliance of vehicle software standards by referring to the special standards of automotive software, and considers the influence of different ASIL levels on the weight of software quality measurement.
  • the software quality measurement method and system proposed in the present invention combines the software development process and software operation and maintenance process quality data generated by the software test management unit and the software operation and maintenance data management unit, and can obtain software quality data in an automated manner and Objectively measure the entire life cycle quality of software in an automated manner.
  • the software quality measurement method and system proposed by the present invention are not only applicable to vehicle control software developed based on handwritten codes, but also particularly applicable to vehicle control software developed based on models.
  • the software quality measurement method and system proposed by the present invention can not only measure the quality of the software architecture, but also measure the software unit, which is conducive to grasping all aspects of software quality.
  • the present invention can assist enterprises to comprehensively and objectively grasp the quality of the entire life cycle of software products, which is beneficial to improve software quality, reduce batch problems, and avoid recalls.

Landscapes

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

Abstract

本发明提供了一种用于自动度量软件质量的方法和系统。系统可包括:软件测试管理单元,用于生成和存储软件开发过程质量数据;软件运维数据管理单元,用于生成和存储软件运维过程质量数据;软件质量度量单元,用于基于从所述软件测试管理单元获取的软件开发过程质量数据和从所述软件运维数据管理单元获取的软件运维过程质量数据对待度量软件的质量进行度量;以及用户接口单元,用于为用户提供接口以与所述软件测试管理单元、所述软件运维数据管理单元、以及所述软件质量度量单元进行交互。

Description

一种软件质量度量方法及系统 技术领域
本发明涉及软件质量度量方法及系统,更具体地,涉及针对车用控制软件的软件质量度量方法及系统。
背景技术
汽车的研发趋势是使得汽车能够越来越智能,能够为驾驶员提供越来越多的驾驶辅助功能,直至完全自动驾驶。这些附加功能的提供需要通过软件和硬件的配合来实现,其中软件方面的进步相对硬件而言是更显著的。相对于普通的软件(例如在个人电脑或智能手机上使用的软件),汽车上使用的软件在安全性、实时性、可靠性等方面的要求显然要高得多。为此,汽车行业针对汽车软件存在行业标准,例如ISO 26262-2011、GB/T 34590-2017、ASPICE 3.0(ASPICE:Automotive Software Process Improvement and Capacity dEtermination是由欧洲的主要汽车制造商共同策定的面向汽车行业的流程评估模型,旨在改善和评估汽车电子控制器的系统和软件开发质量)、MISRA C:2012(MISRA:The Motor Industry Software Reliability Association汽车工业软件可靠性联合会是位于英国的一个跨国汽车工业协会,该协会提出的MSIRA C系列规范已经成为国际汽车行业广泛认可并遵守的C编码规范)以及MAAB(MathWorks Automotive Advisory Board麦斯沃克汽车咨询委员会,该委员会提出的控制算法建模规范是汽车软件MBD(Model Based Development基于模型的软件开发)所必须遵守的规范)等等。
然而,目前针对汽车软件的质量评估主要依赖于评估人员进行人工评估,这导致评估耗费的时间较长且成本较高,并且还不可避免地存在一定的主观性。此外,这些问题也不仅仅存在于车用软件,对于普通的软件的质量评估也存在类似的问题。因此,需要一种全新的能够自动对软件的质量进行度量的方法和系统。
发明内容
提供本发明内容以便以简化形式介绍将在以下具体实施方式中进一步描述的一些概念。本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征,也不旨在用于帮助确定所要求保护的主题的范围。
根据本发明的一个实施例,提供了一种用于自动度量软件质量的方法,所述方法包括:获取待度量的软件的软件特性;基于所获取的软件特性选择质量度量属性;为所选择的质量度量属性中的每一个质量度量属性分配权重;获取软件开发过程质量数据以及软件运维过程质量数据;基于所获取的软件开发过程质量数据以及软件运维过程质量数据中的至少一者,为所述每一个质量度量属性计算质量属性度量值;基于所述质量属性度量值及其相应的权重,计算所述软件的加权质量度量值;以及基于所述加权质量度量值判定所述软件的质量。
根据本发明的另一实施例,提供了一种用于自动度量软件质量的系统,所述系统包括:软件测试管理单元,用于生成和存储软件开发过程质量数据;软件运维数据管理单元,用于生成和存储软件运维过程质量数据;软件质量度量单元,用于基于从所述软件测试管理单元获取的软件开发过程质量数据和从所述软件运维数据管理单元获取的软件运维过程质量数据对待度量软件的质量进行度量;以及用户接口单元,用于为用户提供接口以与所述软件测试管理单元、所述软件运维数据管理单元、以及所述软件质量度量单元进行交互。
根据本发明的又一实施例,提供了一种其上存储有计算机可执行指令的计算机可读存储介质,所述计算机可执行指令在由计算机执行时如本发明中所描述的用于自动度量软件质量的方法。
为了便于描述和理解,本发明以针对车用软件的软件质量度量为例来描述本发明的原理、实施例及具体的技术手段。然而,本领域技术人员应当理解,本发明的软件质量度量方法及系统不仅限于应用于车用软件,而是能够普遍应用于任何软件的质量度量,尤其适合于基于模型开发的软件的质量评估。
与现有技术相比,本发明至少解决了以下几方面问题:
一、软件的客观质量度量问题;
二、采用基于模型开发的软件的质量度量问题;
三、软件单元级质量的度量问题;
四、软件全生命周期质量的度量问题;以及
五、软件质量数据的自动化获取和质量度量自动化执行的问题。
相应地,本发明获得了至少如下的技术效果:
一、从质量度量方法广度看,本发明提供了针对基于模型开发的软件质量度量(特别是针对功能安全软件的质量度量)的方法和系统;
二、从质量度量方法深度看,本发明提供了针对软件单元级质量度量的方法和系统,并且还实现了对软件全生命周期的质量度量;
三、从质量度量模型设计看,本发明提供了考虑软件标准符合性的质量度量方法和系统。
四、从质量度量数据来源看,本发明提供了结合软件测试管理单元和软件运维数据管理单元自动化获取软件质量数据进行质量度量的方法和系统。
通过阅读下面的详细描述并参考相关联的附图,这些及其他特点和优点将变得显而易见。应该理解,前面的概括说明和下面的详细描述只是说明性的,不会对所要求保护的各方面形成限制。
附图说明
为了能详细地理解本发明的上述特征所用的方式,可以参照各实施例来对以上简要概述的内容进行更具体的描述,其中一些方面在附图中示出。然而应该注意,附图仅示出了本发明的某些典型方面,故不应被认为限定其范围,因为该描述可以允许有其它等同有效的方面。
图1是根据本发明的一个实施例的软件质量度量系统的结构框图。
图2示出了根据本发明的一个实施例的示例性软件开发过程质量数据结构。
图3示出了根据本发明的一个实施例的示例性软件开发过程质量属性。
图4是根据本发明的一个实施例的用于生成软件开发过程质量数据的方法的流程图。
图5是根据本发明的一个实施例的用于生成软件运维过程质量数据的方法的流程图。
图6是根据本发明的一个实施例的用于执行软件质量度量的方法的流程图。
具体实施方式
下面结合附图详细描述本发明,本发明的特点将在以下的具体描述中得到进一步的显现。
图1是根据本发明的一个实施例的软件质量度量系统100的结构框图。如图1中所示,软件质量度量系统100可包括用户接口单元102、软件测试管理单元104、软件运维数据管理单元106、以及软件质量度量单元108。为了便于说明,在图1中,上述四个单元被示为相互独立的单元。然而,本领域技术人员应当能够理解,上述单元可根据需要任意组合和集成,也可根据需要和功能被进一步拆分。
用户接口单元
用户接口单元102可作为软件测试管理单元104、软件运维数据管理单元106和软件质量度量单元108的统一接口,用于为软件开发工程师、软件测试工程师、数据分析工程师和软件质量度量工程师提供接口,分别执行软件上传、测试请求发起、测试用例编写、测试触发、数据管理与分析、软件质量度量模型设计等工作。作为非限制性示例,接口可以被实现为软件客户端、基于web的用户界面、或者任何其它适合便于用户访问车用控制软件质量度量系统的用户界面。
根据本发明的一个实施例,系统可被设计成针对不同的单元有不同的客户端。例如,可以设计成分别针对软件测试管理单元104、软件运维数据管理单元106和软件质量度量单元108的软件测试管理模块、软件运维数据管理模块、以及软件质量度量模块。不同的用户根据其不同的身份和工作职责可分别登录不同的模块。这种设计方式适合用于软件测试管理单元104、软件运维数据管理单元106和软件质量度量单元108被分布式地部署在相应场所的情形。在这种情况下,负责软件测试的用户只需要安装系统的与软件测试管理单元104有关的部分。
替代地,系统也可被设计为具有统一的用户登录界面。这种设计方式适合用于软件测试管理单元104、软件运维数据管理单元106和软件质量度量单元108被集中部署在服务器/云端的情形。例如,当不同的用户通过统一的客户端或通过web访问系统时,在统一的登录界面下登录后,系统可根据其身份和工作职责自动跳转至相应的模块并呈现相应的用户界面。
软件测试管理单元
软件测试管理单元106主要用于生成软件开发过程质量数据。为此,根据本发明的一个实施例,软件测试管理单元可考虑和管理与软件的开发与测试有关的各种要素,要素包括但不限于:软件需求、待测软件、测试用例/配置、持续集成、以及测试工具链等。
软件需求:来源于产品需求,在需求管理工具中进行管理,是软件开发和软件测试的依据。
待测软件:软件开发工程师可根据软件需求开发软件,并将软件上传至软件测试管理单元106的文件管理系统(例如开放源代码的版本控制系统的管理工具Subversion,简称SVN)。
测试用例:软件测试工程师可根据软件需求开发测试需求并编写测试用例,并将测试用例上传至软件测试管理单元106的文件管理系统。
测试配置:软件测试工程师可对测试工具链的参数进行设置,对所需测试项目进行选择和排序,对所需测试用例进行选择,对用于构建闭环系统的被控对象模型进行选择,对所需测试报告模板进行选择,以及对接收测试结果邮件的相关人员进行选择。
持续集成:软件测试管理单元106可以基于事件触发(例如待测软件或测试用例更新并上传时自动触发或自动定时触发)的方式,调用软件测试工具链进行软件测试,自动生成测试报告,并输出结构化的软件开发过程质量数据。
测试工具链:可被软件测试管理单元调用的进行软件测试的工具,这些工具可包括如以下的表1所列的分类,并且包括但不限于每个分类所列出的示例工具。
表1 测试工具链分类
Figure PCTCN2018117388-appb-000001
Figure PCTCN2018117388-appb-000002
图2示出了根据本发明的一个实施例的示例性软件开发过程质量数据结构。本领域技术人员可理解的,软件开发过程质量数据可包括但不仅限于图2所列出的结构化信息。如图2中所示,数据结构可按照软件开发流程划分为架构、单元、模型静态验证、代码静态验证、模型测试、代码测试、PIL(Processor-in-Loop处理器在环)测试、需求验证等八个节点,每个节点下又可以设置有数量不等的子节点。例如,其中,单元节点可按软件实际单元数添加;任务子节点(例如上文提到的模型静态验证、代码静态验证、模型测试、代码测试、PIL测试、需求验证)可按软件实际任务数添加。需要注意的是,本领域技术人员可以理解,上述节点和结构化信息可以按照任何其它适合的形式进行分配、合并或增减,本发明并不受限于所例示的结构化信息的实际结构。前述软件开发过程质量数据结构中包含多种结构化信息,以下的表2给出了这些结构化信息值格式的示例。需要注意的是,本领域技术人员可以理解,本发明并不受限于所例示的结构化信息值的具体格式。表2 软件开发过程质量数据结构化信息值格式示例
Figure PCTCN2018117388-appb-000003
Figure PCTCN2018117388-appb-000004
Figure PCTCN2018117388-appb-000005
Figure PCTCN2018117388-appb-000006
Figure PCTCN2018117388-appb-000007
上述结构化信息可以使用XML语言(但不限于XML语言)进行存储和管理。以XML语言为例,上述结构化信息名称对应XML语言中的元素(Element)或属性(Attribute),结构化信息值对应XML语言中的文本(Text)或属性值(Attr.Value)。
软件运维数据管理单元
软件运维数据管理单元106可存储和管理通过车载终端采集并上传的由车辆控制单元发出的车辆运行数据。这些车辆运行数据可被分析以获得结构化的软件运维过程质量数据。软件运维过程质量数据可主要包括但不限于以下的表3所列出的结构化信息。不同于软件开发阶段质量数据,软件运维阶段质量数据结构比较简单。同样,本领域技术人员可以理解,本发明不受限于表中所列出的结构化信息值的具体格式。这些信息可与软件开发阶段质量数据统一使用XML语言进行管理。
表3 软件运维阶段质量数据结构
Figure PCTCN2018117388-appb-000008
软件质量度量单元
如上文中提到的,软件质量度量单元108可以通过网络与软件测试管理单元104和软件运维数据管理单元106通信,这意味着软件质量度量单元108既可以与软件测试管理单元104和软件运维数据管理单元106一同部署在同一局域网内,也可以分布式地部署在不同地点并通过互联网通信地耦合。无论采用 何种通信耦合方式,软件质量度量单元108可通过网络获取上述软件开发过程质量数据和软件运维过程质量数据。随后,软件质量度量单元108可采用质量数据处理函数对获取的数据进行处理,并分配一个或多个维度的质量度量属性。例如,可根据特定的软件质量评估标准分配标准符合性、功能符合性、性能符合性、可靠性、可维护性等五个维度的质量度量属性。针对每一个质量度量属性,可采用特定的质量度量算法并分配相应的质量度量权重,以便对软件从上述五个维度进行质量度量计算,并形成最终的软件质量度量结果,并自动生成软件质量度量报告。软件质量度量结果和报告可通过诸如邮件或网页等形式向相关用户进行展示。
质量度量模型设计
本领域技术人员可以理解,本发明所描述的软件质量度量平台和方法并不受限于车用控制软件的质量度量,而是可以适用于任何软件的质量度量。针对不同的软件质量度量需求,可以通过使用本发明所描述的质量度量平台的基本架构和方法以及设计相应的质量度量模型来实现自动化的针对软件的全生命周期的质量度量。作为一个示例,本发明提供了一种示例性的质量度量模型设计。
根据本发明的一个实施例,质量度量模型可包括质量度量属性、质量数据处理函数、质量度量算法、质量度量权重、质量判定规则等要素。
1、质量度量属性
前述软件开发过程和软件运维过程质量数据,按照数据类别的不同,可分配到标准符合性、功能符合性、性能符合性、可靠性、可维护性等五个质量度量属性,它们的分配方法可如图3中所示。
图3示出了根据本发明的一个实施例的示例性软件开发过程质量属性。在图3中,将软件质量度量属性分为五个级别,分别为一级属性、二级属性、三级属性、四级属性和五级属性,并使用格式为“i.j.k.l.m”的多级序号对每个质量度量属性进行唯一区分。需要注意的是,上述质量度量属性可以按其它形式进行组织和分配,本发明不受限于所列举的质量度量属性的分类方式。
2、质量数据处理函数
质量度量处理是指将不同类型不同格式的软件质量数据(原始值)通过特 定的质量数据处理函数处理成归一化的质量数据度量值。质量数据处理函数的自变量为质量数据原始值,因变量为质量数据度量值。不同类型的质量数据的处理函数形式不同,但它们应遵循以下共性规则:
1)质量数据处理函数的值域应为[p,q]、[p,q)、(p,q]三者之一,p和q可任意指定,但一套质量度量模型中必须保持固定,为便于理解,可以取p=0,q=1,本申请的说明书的后续内容均以此为示例来描述;
2)质量数据处理函数必须为单调函数,但不必为严格单调函数;
3)函数的单调性应使得:软件质量越高,则质量数据度量值越大。
不同类型质量数据的处理函数示例见以下的表4。需要注意的是,本发明不受限于所列举的质量数据处理函数,只需满足上述共性规则即可。
表4 质量数据处理函数示例
Figure PCTCN2018117388-appb-000009
注:a为参数
3、质量度量算法
质量度量算法是指根据前述质量数据度量值,采用线性加权方法,计算质量度量结果的方法。线性加权方法涉及到的度量权重在后一小节中将更详细地描述。软件质量度量算法主要受以下三方面的软件特性所影响。
1)软件开发方式:基于模型,或基于手写代码,或两者兼而有之。不同开发方式对质量度量算法的影响举例如下:
a)对于基于模型开发的软件,在质量度量时,可采用模型层面的质量数据(例如建模规范符合率数据),也可采用代码层面的质量数据(例如编码规范符合率数据),也可采用两个层面的质量数据;
b)对于基于手写代码开发的软件,在质量度量时,只能采用代码层面的质量数据。
2)软件所处过程:开发过程或运维过程,开发过程还可按“V”模型细分为更多的子过程,运维过程还可分为试运行过程和运维过程两个子过程。软件所处不同过程对质量度量算法的影响举例如下:
a)对于处于软件开发过程的软件,只能采用软件开发过程质量数据;
b)对于处于软件运维过程的软件,应采用开发过程和运维过程的质量数据。
3)质量度量等级:为说明方便,以下以ISO26262标准所要求的汽车安全完整性等级ASIL为例,按照功能安全标准,不同ASIL等级对软件质量要求的严格程度是不同的。ASIL等级对质量度量算法的影响举例如下。
a)对于ASIL等级为QM的软件,所有安全相关的质量数据都可不采用;
b)对于ASIL等级为A、B、C的软件,可不采用MC/DC覆盖率数据,等等。
对于采用确定的开发方式进行开发,处于某个确定过程,并具有确定ASIL等级的待度量软件。软件质量度量工程师可在充分理解上述软件特性的基础上,对诸如图3所示的质量度量属性进行裁剪,以形成满足待度量软件所需的特定质量度量属性子集。软件质量度量算法应基于此特定质量度量属性子集开展。本发明不受限于所列举的质量度量属性子集的具体裁剪方法。以下基于某个确 定的质量度量属性子集C,描述质量度量算法的一般原理。
不失一般性,假设:
1)质量度量属性子集C有x个一级属性;
2)每个一级属性下有若干个二级属性,且序号为i的一级属性下有y i个二级属性(1≤i≤x);
3)每个二级属性下有若干个三级属性,且序号为i.j的二级属性下有z j个三级属性(1≤j≤y i);
4)每个三级属性下有若干个四级属性,且序号为i.j.k的三级属性下有u k个四级属性(1≤k≤z j);
5)每个四级属性下有若干个五级属性,且序号为i.j.k.l的四级属性下有v l个五级属性(1≤l≤u k)
则质量度量算法可分为以下五个步骤:
第一步:基于五级属性的度量值分别对所属四级属性进行度量,其中序号为i.j.k.l的四级属性的度量值计算公式为:
Figure PCTCN2018117388-appb-000010
其中:
SQM ijkl——序号为i.j.k.l的四级属性的度量值;
SQM ijkln——序号为i.j.k.l.n的五级属性的度量值;
w ijkln——序号为i.j.k.l.n的五级属性的度量权重
第二步:基于四级属性的度量值分别对所属三级属性进行度量,其中序号为i.j.k的三级属性的度量值计算公式为:
Figure PCTCN2018117388-appb-000011
其中:
SQM ijk——序号为i.j.k的三级属性的度量值;
SQM ijkn——序号为i.j.k.n的四级属性的度量值;
w ijkl——序号为i.j.k.n的四级属性的度量权重
第三步:基于三级属性的度量值分别对所属二级属性进行度量,其中序号为i.j的二级属性的度量值计算公式为:
Figure PCTCN2018117388-appb-000012
其中:
SQM ij——序号为i.j的二级属性的度量值;
SQM ijn——序号为i.j.n的三级属性的度量值;
w ijn——序号为i.j.n的三级属性的度量权重
第四步:基于二级属性的度量值分别对所属一级属性进行度量,其中序号为i的一级属性的度量值计算公式为:
Figure PCTCN2018117388-appb-000013
其中:
SQM i——序号为i的一级属性的度量值;
SQM in——序号为i.n的二级属性的度量值;
w in——序号为i.n的二级属性的度量权重
第五步:基于x个一级属性的度量值计算最终质量度量值,计算公式为:
Figure PCTCN2018117388-appb-000014
其中:
SQM——最终质量度量值;
SQM n——序号为n的一级属性的度量值;
w n——序号为n的一级属性的度量权重
需要注意的是:
1)若实际质量度量子集的最高级别与上述质量度量子集C有所不同,则算法步骤也应做相应变化;
2)若某个质量度量属性没有任何下级属性,则该质量度量属性的度量值 必然直接来源于质量度量函数,因此无需套用上述公式进行计算。
4、质量度量权重
对于上述的软件质量度量的多个维度,在不同标准或需求下可能存在不同的侧重。因此,可针对软件质量度量的每一个维度分配质量度量权重。权重分配可按照领域内常用的APH(Analytic Hierarchy Process)层次分析法进行,也可根据工程师经验人工进行,本发明不受限于具体的权重分配方案。然而,需要注意的是,质量度量权重分配优选地应考虑以下原则:
1)质量度量权重分配应在确定了质量度量属性子集后进行;
2)对于ASIL等级较高的软件,安全相关的质量度量属性的权重应酌情设高,反之亦然;
3)某一度量属性的所有下级度量属性的权重之和应等于1。
5、质量判定准则
质量判定是指根据上述SQM值,判断软件质量度量结论SQC,本专利将SQ分为Good、Acceptable和Bad三个等级,因此相应设置了两个SQM阈值,分别为th和tl,作为软件质量判定准则。他们之间的关系如表5所示。需要注意的是,用于作为软件质量判定准则的SQM阈值可以根据需要做增减,本发明不限于所列举的具体SQM阈值数量和数值。
表5 质量判定准则
Figure PCTCN2018117388-appb-000015
软件质量度量流程设计
与软件质量度量模型设计类似的,为了对软件质量进行度量,还需要进行合适的软件质量度量流程的设计。作为一个示例,本发明提供了一种示例性的质量度量流程设计。然而,本领域技术人员可以理解,在不背离本发明所描述 的本发明所描述的质量度量平台的基本架构和方法的情况下,可以针对不同的软件质量度量需求来设计具体的软件质量度量流程,以便实现自动化的针对软件的全生命周期的质量度量。
根据本发明的一个实施例,软件质量度量流程可被设计为大致分为软件质量数据生成和软件质量度量两个阶段。
对于软件质量数据生成,如之前提到的,又可以进一步分为软件开发过程质量数据生成和软件运维过程质量数据生成。
图4是根据本发明的一个实施例的用于生成软件开发过程质量数据的方法400的流程图。如上文中描述的,软件开发过程质量数据的生成可由软件测试管理单元(例如,图1中的软件测试管理单元104)来执行。方法400开始于步骤402,在步骤402,软件测试管理单元可读取文件管理系统(例如SVN)。更具体地,软件测试管理单元可从文件管理系统中读取之前已上传至文件管理系统中的待测软件以及测试用例。
随后,在步骤404,软件测试管理单元可检测是否发生了测试触发事件。如上文提到的,测试触发事件可包括例如待测软件或测试用例被更新并上传至软件测试管理单元的文件管理系统。替代地或附加地,测试触发事件还可包括自动测试定时来临。例如,可以设定每隔一固定时间间隔就固定对待测软件或测试用例进行测试。回到步骤404,如果软件测试管理单元未检测到测试触发事件,则流程返回至步骤402。如果在步骤404,软件测试管理单元检测到测试触发事件发生,则流程前进至步骤406。
在步骤406,软件测试管理单元可进行软件测试。例如,软件测试管理单元104可通过调用软件测试工具链来对待测软件或测试用例进行软件测试。最后,在步骤408,软件测试管理单元可基于测试的结果生成软件开发过程质量数据。根据一个实施例,生成软件开发过程质量数据可包括自动生成测试包干,以及输出结构化的软件开发过程质量数据。根据一个实施例,软件开发过程质量数据可采用XML语言或其它任何适合的结构化语言来存储和管理。
图5是根据本发明的一个实施例的用于生成软件运维过程质量数据的方法500的流程图。如上文中描述的,软件运维过程质量数据的生成可由软件运维数据管理单元(例如,图1中的软件运维数据管理单元106)来执行。方法500 开始于步骤502,在步骤502,读取软件运维数据。在待测软件是车用软件的上下文中,软件运维数据是车载终端数据。如之前描述的,车载终端数据可以是由车载终端从车辆控制单元采集并上传至软件运维数据管理单元的车辆运行数据。随后,在步骤504,读取的软件运维数据可被分析,并在步骤506,生成软件运维过程质量数据。如之前描述的,软件运维数据(例如车辆运行数据)可由数据分析工程师人工分析,也可由软件运维数据管理单元基于预定的数据分析规则和算法自动分析。生成的软件运维过程质量数据可采用结构化数据结构。这些数据可采用与软件开发阶段质量数据相同的结构化语言(例如XML语言)来进行存储和管理。图6是根据本发明的一个实施例的用于执行软件质量度量的方法600的流程图。如上文中描述的,软件运维过程质量数据的生成可由软件运维数据管理单元(例如,图1中的软件质量度量单元108)来执行。方法600开始于步骤602,在步骤602,获取待度量软件的软件特性。如之前提到的,软件特性可包括软件开发方式、软件所处过程以及质量度量等级(如ASIL等级)。随后,在步骤604,质量度量属性可被裁剪以形成满足待度量软件所需的特定质量度量属性子集。如之前在图3中呈现的,一个统一的质量度量平台可能设计采用包含有多个层级的数量相当大的度量属性,然而针对特定的测试需求,并不是所有的度量属性都需要被度量。因此,根据需要仅选择需要的属性作为度量属性子集将显著提升测试的效率并节省相关的资源。当然,如本领域技术人员可以理解的,裁剪质量度量属性子集这一步骤是可选的,直接将所设计的质量度量模型中的所有质量度量属性都作为要考虑的属性也是可行的,例如可在质量度量模型设计阶段就设计仅包含针对待测软件的特定需求所必须的度量属性。
随后,在步骤606,可为所裁剪的质量属性子集中的每一个质量度量属性分配权重。如之前所提到的,本发明不受限于具体的权重分配方案。在特定情况下,不设权重(也即权重在所有的度量维度上等分)也是可以的。
接着,在步骤606和608,分别获取软件开发过程质量数据以及软件运维过程质量数据。例如,软件开发过程质量数据可由软件质量度量单元108通过网络从软件测试管理单元104处接收,而软件运维过程质量数据可通过网络从软件运维数据管理单元106处接收。
在接收了软件开发过程质量数据和软件运维过程质量数据之后,在步骤610,针对接收到的每一项数据,计算软件质量属性度量值。度量值的计算可基于之前描述的质量数据处理函数来进行。随后,在步骤612,根据计算出的软件质量属性度量值以及相应的权重,计算加权的软件质量度量值。最后,在步骤614,根据预先设置的质量判定准则,可对软件的质量进行判定,并给出判定结构,例如Good、Acceptable还是Bad。
以上描述了本发明的用于车辆控制系统软件的客观质量度量的方法和系统。与现有技术相比,本发明提供的技术方案至少具有以下创新点及有益效果:
(1)本发明提出的软件质量度量方法及系统参考汽车软件特殊标准增加了车用软件标准符合性的特殊度量属性,并考虑了不同ASIL等级对软件质量度量权重的影响。
(2)本发明提出的软件质量度量方法及系统结合了软件测试管理单元和软件运维数据管理单元的生成的软件开发过程和软件运维过程质量数据,能够以自动化的方式获取软件质量数据并以自动化的方式对软件全生命周期质量进行客观度量。
(3)本发明提出的软件质量度量方法及系统既适用于基于手写代码开发的车用控制软件,也特别适用于基于模型开发的车用控制软件。
(4)本发明提出的软件质量度量方法及系统既能够对软件架构进行质量度量,也能对软件单元进行度量,有利于了对软件质量的全方面把握。
基于上述创新点,本发明能够辅助企业对软件产品全生命周期的质量进行全面客观把握,有利于提升软件质量,减少批量问题,避免召回。
以上所已经描述的内容包括所要求保护主题的各方面的示例。当然,出于描绘所要求保护主题的目的而描述每一个可以想到的组件或方法的组合是不可能的,但本领域内的普通技术人员应该认识到,所要求保护主题的许多进一步的组合和排列都是可能的。从而,所公开的主题旨在涵盖落入所附权利要求书的精神和范围内的所有这样的变更、修改和变化。

Claims (34)

  1. 一种用于自动度量软件质量的方法,其特征在于,所述方法包括:
    获取待度量的软件的软件特性;
    基于所获取的软件特性选择质量度量属性;
    为所选择的质量度量属性中的每一个质量度量属性分配权重;
    获取软件开发过程质量数据以及软件运维过程质量数据;
    基于所获取的软件开发过程质量数据以及软件运维过程质量数据中的至少一者,为所述每一个质量度量属性计算质量属性度量值;
    基于所述质量属性度量值及其相应的权重,计算所述软件的加权质量度量值;以及
    基于所述加权质量度量值判定所述软件的质量。
  2. 如权利要求1所述的方法,其特征在于,所述软件特性包括以下中的至少之一:
    软件开发方式;
    软件所处过程;以及
    质量度量等级。
  3. 如权利要求1所述的方法,其特征在于,所述质量度量属性包括多个层级,并且每一层级可包括一个或多个质量度量属性。
  4. 如权利要求3所述的方法,其特征在于,所述多个层级中的第一级的一个或多个质量度量属性中的每一个对应于软件度量的一个维度。
  5. 如权利要求4所述的方法,其特征在于,所述维度包括以下中的至少一个:
    标准符合性、功能符合性、性能符合性、可靠性、以及可维护性。
  6. 如权利要求1所述的方法,其特征在于,所述基于所获取的软件特性选择质量度量属性进一步包括:
    基于所获取的软件特性从多个质量度量属性中裁剪用于度量所述软件的质量的质量度量属性子集。
  7. 如权利要求1所述的方法,其特征在于,所述权重基于以下原则中的至少一个来分配:
    1)所述软件的质量度量等级越高,与安全相关的质量度量属性被分配的权重越高;以及
    2)任何一个度量属性的所有下级度量属性的权重之和等于1。
  8. 如权利要求1所述的方法,其特征在于,所述方法还包括生成软件开发过程质量数据,包括:
    从文件管理系统中读取所述待度量软件或测试用例;
    检测是否发生了测试触发事件;
    响应于检测到测试触发事件的发生,对所述待度量软件或测试用例进行测试;以及
    生成所述软件开发过程质量数据。
  9. 如权利要求8所述的方法,其特征在于,所述测试触发事件包括:
    所述待度量软件或测试用例被上传至所述文件管理系统;
    所述待度量软件或测试用例被更新;以及
    预定的测试定时来临。
  10. 如权利要求1所述的方法,其特征在于,所述方法还包括生成软件运维过程质量数据,包括:
    读取软件运维数据;
    对读取的软件运维数据进行分析;以及
    生成所述软件运维过程质量数据。
  11. 如权利要求1所述的方法,其特征在于,所述软件开发过程质量数据和所述软件运维过程质量数据使用结构化语言来存储。
  12. 如权利要求1所述的方法,其特征在于,为所述每一个质量度量属性计算质量属性度量值进一步包括:
    基于与每一个所述质量度量属性相关联的质量数据处理函数来计算其每一个所述质量度量属性的质量属性度量值。
  13. 如权利要求1所述的方法,其特征在于,所述软件的加权质量度量值是所选择的每一个质量度量属性的质量度量值的加权和。
  14. 如权利要求3所述的方法,其特征在于,所述软件的加权质量度量值是所述多个层级中的第一级的每一个质量度量属性的质量度量值的加权和;并且
    其中具有下级质量度量属性的质量度量属性的质量度量值是该质量度量属性的每一个下级质量度量属性的质量度量值的加权和,而不具有下级质量度量属性的质量度量属性的质量度量值是基于与该质量度量属性相关联的质量数据处理函数计算出的质量属性度量值。
  15. 如权利要求1所述的方法,其特征在于,基于所述加权质量度量值判定所述软件的质量进一步包括:
    基于一个或多个预先设定的阈值来确定所述软件的质量度量结果。
  16. 如权利要求1所述的方法,其特征在于,进一步包括:
    自动生成软件质量度量报告并呈现给用户。
  17. 一种用于自动度量软件质量的系统,其特征在于,所述系统包括:
    软件测试管理单元,用于生成和存储软件开发过程质量数据;
    软件运维数据管理单元,用于生成和存储软件运维过程质量数据;
    软件质量度量单元,用于基于从所述软件测试管理单元获取的软件开发过程质量数据和从所述软件运维数据管理单元获取的软件运维过程质量数据对待度量软件的质量进行度量;以及
    用户接口单元,用于为用户提供接口以与所述软件测试管理单元、所述软件运维数据管理单元、以及所述软件质量度量单元进行交互。
  18. 如权利要求17所述的系统,其特征在于,所述软件测试管理单元还包括文件管理系统,并且所述软件测试管理单元被配置成:
    从所述文件管理系统中读取待度量软件或测试用例;
    检测是否发生了测试触发事件;
    响应于检测到测试触发事件的发生,对所述待度量软件或测试用例进行测试;
    生成所述软件开发过程质量数据。
  19. 如权利要求18所述的系统,其特征在于,所述测试触发事件包括:
    所述待度量软件或测试用例被上传至所述文件管理系统;
    所述待度量软件或测试用例被更新;以及
    预定的测试定时来临。
  20. 如权利要求17所述的系统,其特征在于,所述软件运维数据管理单元被配置成:
    读取软件运维数据;
    对读取的软件运维数据进行分析;以及
    生成所述软件运维过程质量数据。
  21. 如权利要求17所述的系统,其特征在于,软件质量度量单元被配置成:
    获取待度量的软件的软件特性;
    基于所获取的软件特性选择质量度量属性;
    为所选择的质量度量属性中的每一个质量度量属性分配权重;
    从所述软件测试管理单元获取所述软件开发过程质量数据;
    从所述软件运维数据管理单元获取所述软件运维过程质量数据;
    基于所获取的软件开发过程质量数据以及软件运维过程质量数据中的至少一者,为所述每一个质量度量属性计算质量属性度量值;
    基于所述质量属性度量值及其相应的权重,计算所述软件的加权质量度量值;以及
    基于所述加权质量度量值判定所述软件的质量。
  22. 如权利要求21所述的系统,其特征在于,所述软件特性包括以下中的至少之一:
    软件开发方式;
    软件所处过程;以及
    质量度量等级。
  23. 如权利要求21所述的系统,其特征在于,所述质量度量属性包括多个层级,并且每一层级可包括一个或多个质量度量属性。
  24. 如权利要求23所述的系统,其特征在于,所述多个层级中的第一级的一个或多个质量度量属性中的每一个对应于软件度量的一个维度。
  25. 如权利要求24所述的系统,其特征在于,所述维度包括以下中的至少一个:
    标准符合性、功能符合性、性能符合性、可靠性、以及可维护性。
  26. 如权利要求21所述的系统,其特征在于,所述基于所获取的软件特性选择质量度量属性进一步包括:
    基于所获取的软件特性从多个质量度量属性中裁剪用于度量所述软件的质量的质量度量属性子集。
  27. 如权利要求21所述的系统,其特征在于,所述软件质量度量单元还被配置成基于以下原则中的至少一个来分配权重:
    1)所述软件的质量度量等级越高,与安全相关的质量度量属性被分配的权重越高;以及
    2)任何一个度量属性的所有下级度量属性的权重之和等于1。
  28. 如权利要求17所述的系统,其特征在于,所述软件开发过程质量数据和所述软件运维过程质量数据使用结构化语言来存储。
  29. 如权利要求21所述的系统,其特征在于,为所述每一个质量度量属性计算质量属性度量值进一步包括:
    基于与每一个所述质量度量属性相关联的质量数据处理函数来计算其每一个所述质量度量属性的质量属性度量值。
  30. 如权利要求21所述的系统,其特征在于,所述软件的加权质量度量值是所选择的每一个质量度量属性的质量度量值的加权和。
  31. 如权利要求21所述的方法,其特征在于,所述软件的加权质量度量值是所述多个层级中的第一级的每一个质量度量属性的质量度量值的加权和;并且
    其中具有下级质量度量属性的质量度量属性的质量度量值是该质量度量属性的每一个下级质量度量属性的质量度量值的加权和,而不具有下级质量度量属性的质量度量属性的质量度量值是基于与该质量度量属性相关联的质量数据处理函数计算出的质量属性度量值。
  32. 如权利要求21所述的系统,其特征在于,基于所述加权质量度量值判定所述软件的质量进一步包括:
    基于一个或多个预先设定的阈值来确定所述软件的质量度量结果。
  33. 如权利要求21所述的系统,其特征在于,所述软件质量度量单元被进一步配置成:
    自动生成软件质量度量报告并经由所述用户接口单元呈现给用户。
  34. 一种其上存储有计算机可执行指令的计算机可读存储介质,所述计算机可执行指令在由计算机执行时执行如权利要求1-16中的任意一项所述的方法。
PCT/CN2018/117388 2018-11-26 2018-11-26 一种软件质量度量方法及系统 WO2020107142A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/117388 WO2020107142A1 (zh) 2018-11-26 2018-11-26 一种软件质量度量方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/117388 WO2020107142A1 (zh) 2018-11-26 2018-11-26 一种软件质量度量方法及系统

Publications (1)

Publication Number Publication Date
WO2020107142A1 true WO2020107142A1 (zh) 2020-06-04

Family

ID=70852463

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/117388 WO2020107142A1 (zh) 2018-11-26 2018-11-26 一种软件质量度量方法及系统

Country Status (1)

Country Link
WO (1) WO2020107142A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11708049B2 (en) 2020-10-27 2023-07-25 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for preventing an operation of a car application that reduces a quality of service of a computer system of a vehicle

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102096633A (zh) * 2010-12-10 2011-06-15 东华大学 一种面向应用领域的软件质量基准测评方法
CN103279831A (zh) * 2013-06-27 2013-09-04 李岩 用于评价软件测试质量和开发能力的管理系统实现方法
CN104461878A (zh) * 2014-11-28 2015-03-25 中国航空无线电电子研究所 一种基于自定义模型的软件质量评价方法
CN105468512A (zh) * 2014-09-05 2016-04-06 北京畅游天下网络技术有限公司 一种对软件质量进行评估的方法和系统
CN106406870A (zh) * 2016-09-06 2017-02-15 北京航空航天大学 一种基于软件复杂网络的四维软件演化度量分析方法
CN108509340A (zh) * 2018-03-27 2018-09-07 中国人民解放军海军大连舰艇学院 一种舰艇指控系统软件质量要素的确定与量化评估方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102096633A (zh) * 2010-12-10 2011-06-15 东华大学 一种面向应用领域的软件质量基准测评方法
CN103279831A (zh) * 2013-06-27 2013-09-04 李岩 用于评价软件测试质量和开发能力的管理系统实现方法
CN105468512A (zh) * 2014-09-05 2016-04-06 北京畅游天下网络技术有限公司 一种对软件质量进行评估的方法和系统
CN104461878A (zh) * 2014-11-28 2015-03-25 中国航空无线电电子研究所 一种基于自定义模型的软件质量评价方法
CN106406870A (zh) * 2016-09-06 2017-02-15 北京航空航天大学 一种基于软件复杂网络的四维软件演化度量分析方法
CN108509340A (zh) * 2018-03-27 2018-09-07 中国人民解放军海军大连舰艇学院 一种舰艇指控系统软件质量要素的确定与量化评估方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11708049B2 (en) 2020-10-27 2023-07-25 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for preventing an operation of a car application that reduces a quality of service of a computer system of a vehicle

Similar Documents

Publication Publication Date Title
CN107193876B (zh) 一种基于最近邻knn算法的缺失数据填补方法
Hamraz et al. Industrial evaluation of FBS Linkage–a method to support engineering change management
Ensan et al. Goal-oriented test case selection and prioritization for product line feature models
CN106682350B (zh) 一种基于三维模型的多属性决策质量检测方法
CN105224447A (zh) 发动机控制器软件诊断模块测试方法及测试系统
CN108345670B (zh) 一种用于95598电力工单的服务热点发现方法
CN110942086A (zh) 数据预测优化方法、装置、设备及可读存储介质
CN103631788A (zh) 基于共享数据库的车辆制造质量问题诊断系统
CN111125946A (zh) 一种基于mdo技术的上车体结构优化方法
Zhang et al. A generic data analytics system for manufacturing production
CN101520746A (zh) 一种用于多种软件形态的质量评估方法及系统
WO2020107142A1 (zh) 一种软件质量度量方法及系统
US10572931B2 (en) Approving group purchase requests
JP5439296B2 (ja) 変更影響予測方法及び変更影響予測装置
CN109669777B (zh) 工业互联网大数据元需求服务提供方法与系统
TWI627597B (zh) 風險管理之專家分析系統及其操作方法
CN103577940A (zh) 对业务模型进行诊断的方法和装置
Schönwald et al. Improvement of collaboration between testing and simulation departments on the example of a motorcycle manufacturer
Qureshi et al. A timed automata-based method to analyze east-adl timing constraint specifications
CN104765602B (zh) 非功能需求实现策略的量化选择方法
CN111221720A (zh) 一种软件质量度量方法及系统
Moris et al. Simplification and aggregation strategies applied for factory analysis in conceptual phase using simulation
Rodrigues et al. The definiton of a testing process to small-sized companies: the Brazilian scenario
Lind et al. Automotive system development using reference architectures
CN117556187B (zh) 基于深度学习的云数据修复方法、系统及可读存储介质

Legal Events

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

Ref document number: 18941621

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

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 18941621

Country of ref document: EP

Kind code of ref document: A1