Before we get into the exact testing approaches that we use, we’d want to talk about the different levels of granular testing.
Let’s look at a software system, which is made up of interconnected components. The first level of testing that we consider in testing is Unit Testing, which involves testing individual components in isolation.
Integration Testing is the next step, which involves examining numerous components and their interactions. Know more about how Embold can be used by QA teams.
And after the integration testing, the next step is to test the complete system as a whole. It includes both functional and non-functional testing.
Performance testing is an important aspect of testing since it aids in the improvement of performance. It’s a type of non-functional software testing that ensures software programs will run smoothly under the predicted load. The goal of performance testing is not only to find bugs but also to eliminate performance bottlenecks. Performance testing examines the speed, scalability, and stability of a software program. Every new version is subjected to performance testing by Embold.
Acceptance testing and regression testing are two more types of testing.
Acceptance testing is the validation of software against the customer requirements. So, this is the testing that makes sure that the system does what the customer wants it to do.
And the last type of testing is Regression testing. It is a type of testing or retesting that we perform every time that we change our system and make sure that the changes behave as intended and the unchanged code is not negatively affected by the modification by these changes.
So, for many projects, the test processes that run, occupy a significant amount of time during the construction phase. These tests could be a mix of unit and integration tests, with the latter taking the most time.
How we, at Embold, do granular performance testing by analysing the performance of every component?
Before every release, Embold carries out an automated performance testing for all major languages. With each new version, we have more rules introduced that influence the scan performance. But our goal is to ensure that the difference in performance is as small as possible.
Test data consists of large, medium, and small-size open-source repositories. We benchmark the performance to the scan time for the last release for repositories with similar lines of code.
In case there is an improvement in scan performance, we consider that as our new benchmark.
But if the scan performance has deteriorated, we do a more granular performance testing. Embold scan process consists of multiple small components which perform the following tasks
- Parsing
- Metric Calculation
- Issue Detection
- Relevance Calculation
- Duplication
- Code Issues Rating
- Design Issues Rating
- Metric Rating
- Publishing
Our testing team carries out performance testing on all these individual components to understand the exact cause of the performance drop. Once our testing team has completed the test, our development team will get to work on it and resolve the issues as soon as possible. This method aids us in improving our performance.
Have a look at the performance report of our last two scans:
| Project_Name | Repo_Name | Repo_URL | Language | Download_Source | Start_Scan | Parsing | Preprocessing_Parser_Data | Metric_Calculation | Unit_Test | Issue_Detection | Relevance_Calculation | Data_Aggregation | Consolidation | Total_Time | Duplication | Code_Issues_Rating | Design_Issues_Rating | Metric_Rating | Overall_Rating | totalLoc | eloc | components | Code Issues Count | Design Issues Count | Duplication Loc |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| performance | openjdk | https://github.com/saurabhacellere/jdk | JAVA | 236.136 | 0.04 | 762.625 | 4.847 | 744.932 | 17.571 | 23.088 | 11.41 | 72.207 | 333.904 | 2467.492 | 2.64 | 0.75 | 1.71 | 0.23 | 1.21 | 2605355 | 1181381 | 13998 | 36807 | 50982 | 197395 |
| performance | openjdk | https://github.com/saurabhacellere/jdk | JAVA | 37.252 | 0.518 | 619.728 | 2.376 | 273.189 | 0.367 | 7.995 | 9.394 | 103.263 | 1527.296 | 2951.673 | 2.64 | -2.51 | 1.69 | 0.23 | 0.87 | 2611003 | 1184842 | 14091 | 175719 | 50963 | 197745 |
| Difference; | 198.884 | -0.478 | 142.897 | 2.471 | 471.743 | 17.204 | 15.093 | 2.016 | -31.056 | -1193.392 | -484.181 | 0 | 3.26 | 0.02 | 0 | 0.34 | -5648 | -3461 | -93 | -138912 | 19 | -350 |
Conclusion: As Code issue count has increased by 0.3 million with duplication increase of 350 data aggregation and consolidation time will increase as they are directly proportional.
For more updates keep visiting Embold.io.
Comments are closed.