Automated Testing - Suggestions

From Rosalab Wiki
Revision as of 16:56, 29 July 2013 by Euspectre (Talk | contribs) (Enhancements)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
This is a page snapshot, showing old (but not deleted) versions of images and templates.
Jump to: navigation, search

The System

The automated testing system for ROSA Linux distros operates as follows:

  1. It looks for the new ISO images for the appropriate distros on ABF. If they are found, it downloads the images to a local machine.
  2. It creates virtual machines (currently based on qemu-kvm) and checks that the OS boots in Live mode from the ISO images on these machines.
  3. It automatically installs the OS to these virtual machines from the ISO images and performs several basic adjustments and checks. For example, it checks whether SSH connection to the machine is working, tries to enable the default package repositories and perform a package update, etc.
  4. Python unittest ("PyUnit") is used to run functional tests on the live and installed systems.
  5. The results of the above steps are available at FBA

All this is currently done for ROSA Desktop Fresh, both 32- and 64-bit.


Listed here are the suggestions collected so far about the tests and the system features that could be useful, in no particular order.


  • Profile for ROSA Desktop Fresh GNOME Edition
  • Profile for ROSA Desktop Fresh LXDE Edition

Installation Options

  • /var on a separate partition
  • Installation on a RAID


  • It could be useful to test the ROSA distros with different kernel flavours available for them.


  • Xfstests and/or other file system tests - at least for ext4 FS, other file systems can also be tested this way in the future
    • ext4 with default mount options
    • ext4 with noatime and discard (commonly used for the FS on SSD drives)
    • btrfs
    •  ? XFS
    •  ? ReiserFS + Reiser4
    • fat/vfat (USB Frash drives)
    •  ? iso9660
    •  ? UDF
    • NTFS (with FUSE-based driver)
    •  ? SquashFS
    • CIFS
    •  ? NFS
  • LSB test suites (see LSB Distribution Checker) - at least libcheck and cmdcheck.
  • Mozmill tests - at least for Firefox (similar to how it is done in OpenQA for OpenSUSE)
  • Checking for errors in the kernel modules with KEDR tools
  • Regression tests for some of the bugs fixed in the distros
  •  ? Fuzz tests like Trinity, etc. (may be destructive)
  • Check the selected software, esp., the software developed by ROSA, for memory-related errors. The tests may be based on Valdrind's Memcheck or other tools.
  •  ? (What else?)


  • TODO


  • Possibility run test for specified iso-image + update specified package from specified repository. For example, we would like to use autotest for testing ROSA utilities like SimpleWelcome (development version).

Comments: it is already possible to use a particular ISO image rather than the newest one. It is also possible to write Autotest scenarios that enable the given repositories, update the specified packages from these repositories and test that software.

This is now possible. See the description and the tutorials here: English Russian

  • Distinction of known and unknown failures.
  • When the repository for pending updates is available, it will be useful to add it on the client machines to check the updates early.
  • Use some OCR facilities like tesseract or whatever to allow the tests to check if the appropriate text is displayed in the application's controls. Matching of the images that contain only text may be unreliable due to font anti-aliasing, etc.


The sources of the system are available at ABF.