scholarly journals Evaluating the Effect of Control Flow on the Unit Testing Effort of Classes: An Empirical Analysis

2012 ◽  
Vol 2012 ◽  
pp. 1-13 ◽  
Author(s):  
Mourad Badri ◽  
Fadel Toure
Keyword(s):  
Operating Characteristic ◽  
Control Flow ◽  
Software Systems ◽  
Test Cases ◽  
Unit Testing ◽  
Testing Effort ◽  
Logistic Regression Method ◽  
Predicted Model ◽  
Object Oriented Systems ◽  
The Relationship

The aim of this paper is to evaluate empirically the relationship between a new metric (Quality Assurance Indicator—Qi) and testability of classes in object-oriented systems. The Qi metric captures the distribution of the control flow in a system. We addressed testability from the perspective of unit testing effort. We collected data from five open source Java software systems for which JUnit test cases exist. To capture the testing effort of classes, we used different metrics to quantify the corresponding JUnit test cases. Classes were classified, according to the required testing effort, in two categories: high and low. In order to evaluate the capability of the Qi metric to predict testability of classes, we used the univariate logistic regression method. The performance of the predicted model was evaluated using Receiver Operating Characteristic (ROC) analysis. The results indicate that the univariate model based on the Qi metric is able to accurately predict the unit testing effort of classes.

Investigating the Effect of Aspect-Oriented Refactoring on the Unit Testing Effort of Classes: An Empirical Evaluation

2017 ◽  
Vol 27 (05) ◽  
pp. 749-789 ◽  
Author(s):  
Mourad Badri ◽  
Aymen Kout ◽  
Linda Badri
Keyword(s):  
Statistical Tests ◽  
Source Code ◽  
Empirical Evaluation ◽  
Software Systems ◽  
Test Cases ◽  
Unit Testing ◽  
Unit Test ◽  
Testing Effort ◽  
Using Data ◽  
The Impact

This paper aims at investigating empirically the effect of aspect-oriented (AO) refactoring on the unit testability of classes in object-oriented software. The unit testability of classes has been addressed from the perspective of the unit testing effort, and particularly from the perspective of the unit test cases (TCs) construction. We investigated, in fact, different research questions: (1) the impact of AO refactoring on source code attributes (size, complexity, coupling, cohesion and inheritance), attributes that are mostly related to the unit testability of classes, (2) the impact of AO refactoring on unit test code attributes (size, assertions, invocations and data creation), attributes that are indicators of the effort involved to write the code of unit TCs, and (3) the relationships between the variations observed after AO refactoring in both source code and unit test code attributes. We used in the study different techniques: correlation analysis, statistical tests and linear regression. We performed an empirical evaluation using data collected from three well-known open source (Java) software systems (JHOTDRAW, HSQLBD and PETSTORE) that have been refactored using AO programming (AspectJ). Results suggest that: (1) overall, the effort involved in the construction of unit TCs of refactored classes has been reduced, (2) the variations of source code attributes have more impact on methods invocation between unit TCs, and finally (3) the variations of unit test code attributes are more influenced by the variation of the complexity of refactored classes compared to the other class attributes.

scholarly journals On the correlation between testing effort and software complexity metrics

2018 ◽  
Author(s):  
Adnan Muslija ◽  
Eduard P Enoiu
Keyword(s):  
Embedded System ◽  
Execution Time ◽  
Test Cases ◽  
Code Size ◽  
Software Complexity ◽  
Test Execution ◽  
Complexity Metrics ◽  
Cyclomatic Complexity ◽  
Testing Effort ◽  
The Relationship

Software complexity metrics, such as code size and cyclomatic complexity, have been used in the software engineering community for predicting quality metrics such as maintainability, bug proneness and robustness. However, not many studies have addressed the relationship between complexity metrics and software testing and there is little experimental evidence to support the use of these code metrics in the estimation of test effort. We have investigated and evaluated the relationship between test effort (i.e, number of test cases and test execution time) and software complexity metrics for industrial control software used in an embedded system. We show how to measure different software complexity metrics such as number of elements, cyclomatic complexity, and information flow for a popular programming language named FBD used in the safety critical domain. In addition, we use test data and test suites created by experienced test engineers working at Bombardier Transportation Sweden AB to evaluate the correlation between several complexity measures and the testing effort. We found that there is a moderate correlation between software complexity metrics and test effort. In addition, the results show that the software size (i.e., number of elements in the FBD program) provides the highest correlation level with the number of test cases created and test execution time. Our results suggest that software size and structure metrics, while useful for identifying parts of the system that are more complicated, should not be solely used for identifying parts of the system for which test engineers might need to create more test cases. A potential explanation of this result concerns the nature of testing, since other attributes such as the level of thorough testing required and the size of the specifications can influence the creation of test cases. In addition, we used a linear regression model to estimate the test effort using the software complexity measurement results.

scholarly journals On the correlation between testing effort and software complexity metrics

2018 ◽  
Author(s):  
Adnan Muslija ◽  
Eduard P Enoiu
Keyword(s):  
Embedded System ◽  
Execution Time ◽  
Test Cases ◽  
Code Size ◽  
Software Complexity ◽  
Test Execution ◽  
Complexity Metrics ◽  
Cyclomatic Complexity ◽  
Testing Effort ◽  
The Relationship

Software complexity metrics, such as code size and cyclomatic complexity, have been used in the software engineering community for predicting quality metrics such as maintainability, bug proneness and robustness. However, not many studies have addressed the relationship between complexity metrics and software testing and there is little experimental evidence to support the use of these code metrics in the estimation of test effort. We have investigated and evaluated the relationship between test effort (i.e, number of test cases and test execution time) and software complexity metrics for industrial control software used in an embedded system. We show how to measure different software complexity metrics such as number of elements, cyclomatic complexity, and information flow for a popular programming language named FBD used in the safety critical domain. In addition, we use test data and test suites created by experienced test engineers working at Bombardier Transportation Sweden AB to evaluate the correlation between several complexity measures and the testing effort. We found that there is a moderate correlation between software complexity metrics and test effort. In addition, the results show that the software size (i.e., number of elements in the FBD program) provides the highest correlation level with the number of test cases created and test execution time. Our results suggest that software size and structure metrics, while useful for identifying parts of the system that are more complicated, should not be solely used for identifying parts of the system for which test engineers might need to create more test cases. A potential explanation of this result concerns the nature of testing, since other attributes such as the level of thorough testing required and the size of the specifications can influence the creation of test cases. In addition, we used a linear regression model to estimate the test effort using the software complexity measurement results.

scholarly journals Pengembangan sistem otomatisasi pembangkitan kasus uji dengan algoritma genetika dan test case generation method

Teknologi ◽  
2020 ◽  
Vol 10 (1) ◽  
pp. 1
Author(s):  
Moh Arsyad Mubarak Setyawan ◽  
Fajar Pradana ◽  
Bayu Priyambadha
Keyword(s):  
Software Testing ◽  
Directed Graph ◽  
Control Flow ◽  
Test Case Generation ◽  
Test Case ◽  
Test Cases ◽  
Unit Testing ◽  
Control Flow Graph ◽  
Population Number ◽  
Flow Graph

Pengujian perangkat lunak merupakan salah satu bagian penting dari pembuatan perangkat lunak. Pada pengujian perangkat lunak terdapat pengujian unit. Pengujian unit merupakan proses pengujian komponen yang berfokus untuk memverifikasi unit terkecil pada perancangan perangkat lunak. Pada tahap pengujian unit terdapat proses pembangkitan kasus uji. Selama ini, pembangkitan kasus uji dari suatu kode program dilakukan secara manual se-hingga membutuhkan waktu yang lama. Hal ini dikarenakan banyaknya kemungkinan jalur pada kode sumber yang akan diuji.  Dalam penelitian ini dibangun suatu sistem otomatis untuk membangkitkan kasus uji. Alur kerja sistem dimulai dari analisa kode sumber dengan Spoon Library, selanjutnya dibentuk CFG (Control Flow Graph) dan DDG (Dynamic Directed Graph). Dari DDG tersebut akan dibangkitkan jalur layak yang terdapat pada DDG, dengan menggunakan algoritma genetika diharapkan dapat mengoptimalkan penentuan jalur independen. Dari masing-masing jalur independen akan dibangkitkan kasus ujinya dengan metode test case generation. Pengujian akurasi sistem pada sistem otomatisasi pembangkit kasus uji dengan jumlah populasi 5, 10 dan 15 serta jumlah maksimum generasi 50, 100, 200 dan 250 dihasilkan jumlah populasi paling optimal yaitu 10 dan maksimum generasi optimal yaitu 200 dengan akurasi 93,33%. Pada jumlah populasi dan maksimum generasi sesudahnya tidak terjadi peningkatan akurasi yang signifikan. Tiap peningkatan jumlah populasi dan maksimum generasi dapat meningkatkan akurasi sistem.  Software testing is one of the most important part of making software. On the software testing there are unit testing. Unit Testing is a process for verifying component, focusing on the smallest unit of software design. In the unit testing phase contained test case generation process. During this time, the generation of test cases of a program code is done manually. In this study, constructed an automated system to generate test cases. The workflow system starts from the analysis of the source code with the library spoon and then create CFG (Control Flow Graph) and DDG (Dynamic Directed graph). From the DDG will be raised feasible path using a genetic algorithm. Furthermore, from fea-sible path sought independenth path which is a path base d on the level of uniqueness of the path to the other path. From each independenth path raised the test case with a test case generation method. Testing accuracy of the system on the automation system generating test cases with populations of 5,10 and 15 as well as the maximum number of generations 50, 100, 200 and 250 produced the most optimal population number is 15 and the most optimal maximum generation is 200 with accuracy 93.33%. Each increase in the number of population and maximum generation can improve the accuracy of the system. Level accuracy with population number over 10 and maximum generation over 200 has no increace accuracy significant.

scholarly journals Internal Quality Evolution of Open-Source Software Systems

2021 ◽  
Vol 11 (12) ◽  
pp. 5690
Author(s):  
Mamdouh Alenezi
Keyword(s):  
Open Source ◽  
Open Source Software ◽  
Software Evolution ◽  
Quality Metrics ◽  
Internal Quality ◽  
Software Systems ◽  
Software Metric ◽  
Significant Difference ◽  
The Relationship

The evolution of software is necessary for the success of software systems. Studying the evolution of software and understanding it is a vocal topic of study in software engineering. One of the primary concepts of software evolution is that the internal quality of a software system declines when it evolves. In this paper, the method of evolution of the internal quality of object-oriented open-source software systems has been examined by applying a software metric approach. More specifically, we analyze how software systems evolve over versions regarding size and the relationship between size and different internal quality metrics. The results and observations of this research include: (i) there is a significant difference between different systems concerning the LOC variable (ii) there is a significant correlation between all pairwise comparisons of internal quality metrics, and (iii) the effect of complexity and inheritance on the LOC was positive and significant, while the effect of Coupling and Cohesion was not significant.

scholarly journals Snoring: a source of noise pollution and sleep apnea predictor

SLEEP ◽  
2019 ◽  
Vol 43 (6) ◽  
Author(s):  
Mudiaga Sowho ◽  
Francis Sgambati ◽  
Michelle Guzman ◽  
Hartmut Schneider ◽  
Alan Schwartz
Keyword(s):  
Sleep Apnea ◽  
Operating Characteristic ◽  
Area Under The Curve ◽  
Noise Pollution ◽  
Apnea Hypopnea Index ◽  
Sleep Study ◽  
Sound Levels ◽  
Obstructive Sleep ◽  
Single Night ◽  
The Relationship

Abstract Snoring is a highly prevalent condition associated with obstructive sleep apnea (OSA) and sleep disturbance in bed partners. Objective measurements of snoring in the community, however, are limited. The present study was designed to measure sound levels produced by self-reported habitual snorers in a single night. Snorers were excluded if they reported nocturnal gasping or had severe obesity (BMI > 35 kg/m2). Sound was measured by a monitor mounted 65 cm over the head of the bed on an overnight sleep study. Snoring was defined as sound ≥40 dB(A) during flow limited inspirations. The apnea hypopnea index (AHI) and breath-by-breath peak decibel levels were measured. Snore breaths were tallied to determine the frequency and intensity of snoring. Regression models were used to determine the relationship between objective measures of snoring and OSA (AHI ≥ 5 events/h). The area under the curve (AUC) for the receiver operating characteristic (ROC) was used to predict OSA. Snoring intensity exceeded 45 dB(A) in 66% of the 162 participants studied, with 14% surpassing the 53 dB(A) threshold for noise pollution. Snoring intensity and frequency were independent predictors of OSA. AUCs for snoring intensity and frequency were 77% and 81%, respectively, and increased to 87% and 89%, respectively, with the addition of age and sex as predictors. Snoring represents a source of noise pollution in the bedroom and constitutes an important target for mitigating sound and its adverse effects on bed partners. Precise breath-by-breath identification and quantification of snoring also offers a way to risk stratify otherwise healthy snorers for OSA.

scholarly journals The serum homocysteine level in patients with acute ischemic stroke (AIS) after thrombolysis and its relationship with clinical outcomes

2018 ◽  
Vol 64 (5) ◽  
pp. 438-442 ◽  
Author(s):  
Ling-Cong ◽  
Hong-Zhao ◽  
Yu-Wang ◽  
Yu-Li ◽  
Xin-Sui
Keyword(s):  
Clinical Outcomes ◽  
Operating Characteristic ◽  
Characteristic Curve ◽  
Thrombolytic Treatment ◽  
Neurological Outcomes ◽  
High Level Group ◽  
Serum Homocysteine ◽  
High Level ◽  
The Relationship ◽  
Level Group

SUMMARY OBJECTIVE The present study aims to investigate whether hyperhomocysteinemia (HHcy) affects the outcomes of the thrombolytic treatment for patients with AIS. METHODS A sample of 120 AIS patients were recruited and grouped according to their serum homocysteine (Hcy) levels. The National Institute of Health Stroke Scale (NIHSS) was obtained before treatment and 7 days after it to evaluate neurological outcomes; modified Rankin Scale (mRS) was obtained 12 weeks later to assess functional outcomes. Receiver operating characteristic curve (ROC) was used to demonstrate the relationship between serum Hcy level and the outcomes after tPA treatment. RESULTS The serum Hcy level of 120 patients was of 27.57±20.17μmol/L. The NIHSS scores of the patients in the low Hcy level group were remarkably lower compared to those in the high-level group (p<0.05), after 7 days of treatment. In addition, the mRS scores of the patients in the low Hcy level group, after 12 weeks, were remarkably lower compared to those in the high-level group (p<0.01). ROC demonstrated that the serum Hcy level is related to the clinical outcomes of thrombolytic treatment with moderate specificity (80.3%) and sensitivity (58.2%). CONCLUSION In conclusion, higher serum Hcy levels can indicate poorer clinical outcomes of thrombolytic treatment in patients with AIS.

The value of neutrophil-to-lymphocyte ratio as a marker of renal damage in patients with H-type hypertension

2021 ◽  
Author(s):  
Zhen-Ni Chen ◽  
Yi-Ran Huang ◽  
Xing Chen ◽  
Kun Liu ◽  
Si-Jin Li ◽  
...  
Keyword(s):  
Regression Analysis ◽  
Renal Damage ◽  
Operating Characteristic ◽  
Estimated Glomerular Filtration Rate ◽  
Characteristic Curve ◽  
Linear Regression Analysis ◽  
Significant Negative Correlation ◽  
Neutrophil To Lymphocyte Ratio ◽  
Lymphocyte Ratio ◽  
The Relationship

Aim: To explore the relationship between the neutrophil-to-lymphocyte ratio (NLR) and renal damage in patients with H-type hypertension. Materials & methods: A total of 618 patients between 2017 and 2019 were analyzed retrospectively. Results: NLR was significantly correlated with renal damage in hypertension patients. Appropriate cut-off value for NLR (2.247) was determined by receiver operating characteristic curve; linear regression analysis showed that NLR and estimated glomerular filtration rate, blood urea nitrogen/creatinine has a significant negative correlation in H-type hypertension group (p < 0.05); logistic regression analysis showed that the risk of renal damage increased by 10% for each 1 umol/l increase of homocysteine, and 51% for each 1.0 increase of NLR in H-type hypertension patients. Conclusion: NLR worth popularizing in prediction of renal damage in patients with H-type hypertension.

SOX9 stands for a bio-marker for prostate cancer detection

2020 ◽  
Author(s):  
Hao Zi ◽  
Wen-Lin Tao ◽  
Lei Gao ◽  
Zhao-Hua Yu ◽  
Xiao-Dong Bai ◽  
...  
Keyword(s):  
Prostate Cancer ◽  
Cancer Detection ◽  
Roc Curve ◽  
Operating Characteristic ◽  
Diagnostic Value ◽  
Quantitative Real Time Pcr ◽  
Optimal Cutoff ◽  
Qrt Pcr ◽  
Incidence And Mortality ◽  
The Relationship

Abstract Background Prostate cancer is one of common cancers around the world, and in our country the incidence and mortality of PCa are both increasing. More and more reports have revealed that SOX9 is involved in various human cancers. In this study, we aimed to explore the relationship between SOX9 expression and diagnostic value of PCa patients. Methods In this study, quantitative real-time PCR (qRT-PCR) was performed to determine the expression of SOX9 of the 131 PCa patients and 74 healthy volunteers. And receiver operating characteristic (ROC) curve was used to determine the diagnostic value of SOX9 for PCa patients. Results The results of qRT-PCR showed that the expression of serum SOX9 in PCa patients was higher than that in healthy controls (P < 0.05). And the expression of SOX9 was significantly associated with PSA (P = 0.001), differentiation (P = 0.000), and lymph node metastasis (P = 0.000). Besides, the area under the ROC curve (AUC) was 0.966 with the sensitivity of 93.2% and specificity of 87.8% respectively. The optimal cutoff value of SOX9 was 2.34. Conclusions Our results found that SOX9 is a novel oncogene for PCa, and may be a novel and effective biomarker for the diagnosis of patients with PCa.

Sign in / Sign up

Export Citation Format

Share Document