|
| 1 | +Definition of terms |
| 2 | +=================== |
| 3 | + |
| 4 | +This section defines the terms used in this document and correlates them with |
| 5 | +what is currently used on QEMU. |
| 6 | + |
| 7 | +Automated tests |
| 8 | +--------------- |
| 9 | + |
| 10 | +An automated test is written on a test framework using its generic test |
| 11 | +functions/classes. The test framework can run the tests and report their |
| 12 | +success or failure [1]_. |
| 13 | + |
| 14 | +An automated test has essentially three parts: |
| 15 | + |
| 16 | +1. The test initialization of the parameters, where the expected parameters, |
| 17 | + like inputs and expected results, are set up; |
| 18 | +2. The call to the code that should be tested; |
| 19 | +3. An assertion, comparing the result from the previous call with the expected |
| 20 | + result set during the initialization of the parameters. If the result |
| 21 | + matches the expected result, the test has been successful; otherwise, it has |
| 22 | + failed. |
| 23 | + |
| 24 | +Unit testing |
| 25 | +------------ |
| 26 | + |
| 27 | +A unit test is responsible for exercising individual software components as a |
| 28 | +unit, like interfaces, data structures, and functionality, uncovering errors |
| 29 | +within the boundaries of a component. The verification effort is in the |
| 30 | +smallest software unit and focuses on the internal processing logic and data |
| 31 | +structures. A test case of unit tests should be designed to uncover errors due |
| 32 | +to erroneous computations, incorrect comparisons, or improper control flow [2]_. |
| 33 | + |
| 34 | +On QEMU, unit testing is represented by the 'check-unit' target from 'make'. |
| 35 | + |
| 36 | +Functional testing |
| 37 | +------------------ |
| 38 | + |
| 39 | +A functional test focuses on the functional requirement of the software. |
| 40 | +Deriving sets of input conditions, the functional tests should fully exercise |
| 41 | +all the functional requirements for a program. Functional testing is |
| 42 | +complementary to other testing techniques, attempting to find errors like |
| 43 | +incorrect or missing functions, interface errors, behavior errors, and |
| 44 | +initialization and termination errors [3]_. |
| 45 | + |
| 46 | +On QEMU, functional testing is represented by the 'check-qtest' target from |
| 47 | +'make'. |
| 48 | + |
| 49 | +System testing |
| 50 | +-------------- |
| 51 | + |
| 52 | +System tests ensure all application elements mesh properly while the overall |
| 53 | +functionality and performance are achieved [4]_. Some or all system components |
| 54 | +are integrated to create a complete system to be tested as a whole. System |
| 55 | +testing ensures that components are compatible, interact correctly, and |
| 56 | +transfer the right data at the right time across their interfaces. As system |
| 57 | +testing focuses on interactions, use case-based testing is a practical approach |
| 58 | +to system testing [5]_. Note that, in some cases, system testing may require |
| 59 | +interaction with third-party software, like operating system images, databases, |
| 60 | +networks, and so on. |
| 61 | + |
| 62 | +On QEMU, system testing is represented by the 'check-acceptance' target from |
| 63 | +'make'. |
| 64 | + |
| 65 | +Flaky tests |
| 66 | +----------- |
| 67 | + |
| 68 | +A flaky test is defined as a test that exhibits both a passing and a failing |
| 69 | +result with the same code on different runs. Some usual reasons for an |
| 70 | +intermittent/flaky test are async wait, concurrency, and test order dependency |
| 71 | +[6]_. |
| 72 | + |
| 73 | +Gating |
| 74 | +------ |
| 75 | + |
| 76 | +A gate restricts the move of code from one stage to another on a |
| 77 | +test/deployment pipeline. The step move is granted with approval. The approval |
| 78 | +can be a manual intervention or a set of tests succeeding [7]_. |
| 79 | + |
| 80 | +On QEMU, the gating process happens during the pull request. The approval is |
| 81 | +done by the project leader running its own set of tests. The pull request gets |
| 82 | +merged when the tests succeed. |
| 83 | + |
| 84 | +Continuous Integration (CI) |
| 85 | +--------------------------- |
| 86 | + |
| 87 | +Continuous integration (CI) requires the builds of the entire application and |
| 88 | +the execution of a comprehensive set of automated tests every time there is a |
| 89 | +need to commit any set of changes [8]_. The automated tests can be composed of |
| 90 | +the unit, functional, system, and other tests. |
| 91 | + |
| 92 | +Keynotes about continuous integration (CI) [9]_: |
| 93 | + |
| 94 | +1. System tests may depend on external software (operating system images, |
| 95 | + firmware, database, network). |
| 96 | +2. It may take a long time to build and test. It may be impractical to build |
| 97 | + the system being developed several times per day. |
| 98 | +3. If the development platform is different from the target platform, it may |
| 99 | + not be possible to run system tests in the developer’s private workspace. |
| 100 | + There may be differences in hardware, operating system, or installed |
| 101 | + software. Therefore, more time is required for testing the system. |
| 102 | + |
| 103 | +References |
| 104 | +---------- |
| 105 | + |
| 106 | +.. [1] Sommerville, Ian (2016). Software Engineering. p. 233. |
| 107 | +.. [2] Pressman, Roger S. & Maxim, Bruce R. (2020). Software Engineering, |
| 108 | + A Practitioner’s Approach. p. 48, 376, 378, 381. |
| 109 | +.. [3] Pressman, Roger S. & Maxim, Bruce R. (2020). Software Engineering, |
| 110 | + A Practitioner’s Approach. p. 388. |
| 111 | +.. [4] Pressman, Roger S. & Maxim, Bruce R. (2020). Software Engineering, |
| 112 | + A Practitioner’s Approach. Software Engineering, p. 377. |
| 113 | +.. [5] Sommerville, Ian (2016). Software Engineering. p. 59, 232, 240. |
| 114 | +.. [6] Luo, Qingzhou, et al. An empirical analysis of flaky tests. |
| 115 | + Proceedings of the 22nd ACM SIGSOFT International Symposium on |
| 116 | + Foundations of Software Engineering. 2014. |
| 117 | +.. [7] Humble, Jez & Farley, David (2010). Continuous Delivery: |
| 118 | + Reliable Software Releases Through Build, Test, and Deployment, p. 122. |
| 119 | +.. [8] Humble, Jez & Farley, David (2010). Continuous Delivery: |
| 120 | + Reliable Software Releases Through Build, Test, and Deployment, p. 55. |
| 121 | +.. [9] Sommerville, Ian (2016). Software Engineering. p. 743. |
0 commit comments