diff options
| author | Scott Rifenbark <srifenbark@gmail.com> | 2017-03-30 07:51:19 -0700 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2017-04-12 19:35:00 +0100 |
| commit | 43fefd121163e82575709fd75a318fe7f36c1e20 (patch) | |
| tree | 844e0ba569f5f7b6159d030e6c2d2ee0cfce3e1d | |
| parent | c53ba427ef1d21cb5bd5412e9291e37d2e681a4c (diff) | |
| download | poky-43fefd121163e82575709fd75a318fe7f36c1e20.tar.gz | |
ref-manual: Added section on test and QA infrastructure
Fixes [YOCTO #10887]
There needed to be an overview of the test and QA infrastructure
used by the YP development team for releases and that is visible
to the developer. I added a new section for this information into
the existing section on YP release processes.
(From yocto-docs rev: 17b3d6898b37bdbfbd23a333a4d659a9746696d0)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
| -rw-r--r-- | documentation/ref-manual/ref-release-process.xml | 131 |
1 files changed, 131 insertions, 0 deletions
diff --git a/documentation/ref-manual/ref-release-process.xml b/documentation/ref-manual/ref-release-process.xml index 1b337f8bd7..fe3ba0933e 100644 --- a/documentation/ref-manual/ref-release-process.xml +++ b/documentation/ref-manual/ref-release-process.xml | |||
| @@ -117,6 +117,137 @@ | |||
| 117 | </para> | 117 | </para> |
| 118 | </section> | 118 | </section> |
| 119 | 119 | ||
| 120 | <section id='testing-and-quality-assurance'> | ||
| 121 | <title>Testing and Quality Assurance</title> | ||
| 122 | |||
| 123 | <para> | ||
| 124 | Part of the Yocto Project development and release process is quality | ||
| 125 | assurance through the execution of test strategies. | ||
| 126 | Test strategies provide the Yocto Project team a way to ensure a | ||
| 127 | release is validated. | ||
| 128 | Additionally, because the test strategies are visible to you as a | ||
| 129 | developer, you can validate your projects. | ||
| 130 | This section overviews the available test infrastructure used in the | ||
| 131 | Yocto Project. | ||
| 132 | For information on how to run available tests on your projects, see the | ||
| 133 | "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>" | ||
| 134 | section in the Yocto Project Development Manual. | ||
| 135 | </para> | ||
| 136 | |||
| 137 | <para> | ||
| 138 | The QA/testing infrastructure is woven into the project to the point | ||
| 139 | where core developers take some of it for granted. | ||
| 140 | The infrastructure consists of the following pieces: | ||
| 141 | <itemizedlist> | ||
| 142 | <listitem><para> | ||
| 143 | <filename>bitbake-selftest</filename>: | ||
| 144 | A standalone command that runs unit tests on key pieces of | ||
| 145 | BitBake and its fetchers. | ||
| 146 | </para></listitem> | ||
| 147 | <listitem><para> | ||
| 148 | <link linkend='ref-classes-sanity'><filename>sanity.bbclass</filename></link>: | ||
| 149 | This automatically included class checks the build environment | ||
| 150 | for missing tools (e.g. <filename>gcc</filename>) or common | ||
| 151 | misconfigurations such as | ||
| 152 | <link linkend='var-MACHINE'><filename>MACHINE</filename></link> | ||
| 153 | set incorrectly. | ||
| 154 | </para></listitem> | ||
| 155 | <listitem><para> | ||
| 156 | <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>: | ||
| 157 | This class checks the generated output from builds for sanity. | ||
| 158 | For example, if building for an ARM target, did the build | ||
| 159 | produce ARM binaries. | ||
| 160 | If, for example, the build produced PPC binaries then there | ||
| 161 | is a problem. | ||
| 162 | </para></listitem> | ||
| 163 | <listitem><para> | ||
| 164 | <link linkend='ref-classes-testimage*'><filename>testimage.bbclass</filename></link>: | ||
| 165 | This class performs runtime testing of images after they are | ||
| 166 | built. | ||
| 167 | The tests are usually used with | ||
| 168 | <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>QEMU</ulink> | ||
| 169 | to boot the images and check the combined runtime result | ||
| 170 | boot operation and functions. | ||
| 171 | However, the test can also use the IP address of a machine to | ||
| 172 | test. | ||
| 173 | </para></listitem> | ||
| 174 | <listitem><para> | ||
| 175 | <ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'><filename>ptest</filename></ulink>: | ||
| 176 | Runs tests against packages produced during the build for a | ||
| 177 | given piece of software. | ||
| 178 | The test allows the packages to be be run within a target | ||
| 179 | image. | ||
| 180 | </para></listitem> | ||
| 181 | <listitem><para> | ||
| 182 | <filename>oe-selftest</filename>: | ||
| 183 | Tests combination BitBake invocations. | ||
| 184 | These tests operate outside the OpenEmbedded build system | ||
| 185 | itself. | ||
| 186 | The <filename>oe-selftest</filename> can run all tests by | ||
| 187 | default or can run selected tests or test suites. | ||
| 188 | <note> | ||
| 189 | Running <filename>oe-selftest</filename> requires | ||
| 190 | host packages beyond the "Essential" grouping. | ||
| 191 | See the | ||
| 192 | "<link linkend='required-packages-for-the-host-development-system'>Required Packages for the Host Development System</link>" | ||
| 193 | section for more information. | ||
| 194 | </note> | ||
| 195 | </para></listitem> | ||
| 196 | </itemizedlist> | ||
| 197 | </para> | ||
| 198 | |||
| 199 | <para> | ||
| 200 | Originally, much of this testing was done manually. | ||
| 201 | However, significant effort has been made to automate the tests so | ||
| 202 | that more people can use them and the Yocto Project development team | ||
| 203 | can run them faster and more efficiently. | ||
| 204 | </para> | ||
| 205 | |||
| 206 | <para> | ||
| 207 | The Yocto Project's main Autobuilder | ||
| 208 | (<filename>autobuilder.yoctoproject.org</filename>) publicly tests | ||
| 209 | each Yocto Project release's code in the OE-Core, Poky, and BitBake | ||
| 210 | repositories. | ||
| 211 | The testing occurs for both the current state of the | ||
| 212 | "master" branch and also for submitted patches. | ||
| 213 | Testing for submitted patches usually occurs in the | ||
| 214 | "ross/mut" branch in the <filename>poky-contrib</filename> repository | ||
| 215 | (i.e. the master-under-test branch) or in the "master-next" branch | ||
| 216 | in the <filename>poky</filename> repository. | ||
| 217 | <note> | ||
| 218 | You can find all these branches in the Yocto Project | ||
| 219 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>. | ||
| 220 | </note> | ||
| 221 | Testing within these public branches ensures in a publicly visible way | ||
| 222 | that all of the main supposed architectures and recipes in OE-Core | ||
| 223 | successfully build and behave properly. | ||
| 224 | </para> | ||
| 225 | |||
| 226 | <para> | ||
| 227 | Various features such as <filename>multilib</filename>, sub | ||
| 228 | architectures (e.g. <filename>x32</filename>, | ||
| 229 | <filename>poky-tiny</filename>, <filename>musl</filename>, | ||
| 230 | <filename>no-x11</filename> and and so forth), | ||
| 231 | <filename>bitbake-selftest</filename>, and | ||
| 232 | <filename>oe-selftest</filename> are tested as part of | ||
| 233 | the QA process of a release. | ||
| 234 | Complete testing and validation for a release takes the Autobuilder | ||
| 235 | workers several hours. | ||
| 236 | <note> | ||
| 237 | The Autobuilder workers are non-homogeneous, which means regular | ||
| 238 | testing across a variety of Linux distributions occurs. | ||
| 239 | The Autobuilder is limited to only testing QEMU-based setups and | ||
| 240 | not real hardware. | ||
| 241 | </note> | ||
| 242 | </para> | ||
| 243 | |||
| 244 | <para> | ||
| 245 | Finally, in addition to the Autobuilder's tests, the Yocto Project | ||
| 246 | QA team also performs testing on a variety of platforms, which includes | ||
| 247 | actual hardware, to ensure expected results. | ||
| 248 | </para> | ||
| 249 | </section> | ||
| 250 | |||
| 120 | </chapter> | 251 | </chapter> |
| 121 | <!-- | 252 | <!-- |
| 122 | vim: expandtab tw=80 ts=4 | 253 | vim: expandtab tw=80 ts=4 |
