Sample test cases

From Yocto Project
Jump to navigationJump to search
  • ADT
  1. Relocatable SDK - g++ from ADT Installer can build C++ program and run with qemu-${ARCH} command or in target image
  2. Relocatable SDK - gcc from ADT Installer can build c program and run with qemu-${ARCH} command or in target image
  3. Relocatable SDK - install the Cross Toolchain
  4. Relocatable SDK - Launch QEMU from meta-toolchain
  5. Relocatable SDK - meta-toolchain could support native autoconf and automake
  6. Relocatable SDK - non-interactive method for toolchain installation could work
  7. User Built SDK - Use BitBake to build the toolchain
  8. User Built SDK - Launch qemu by Yocto build tree
  9. ADT-installer - Relocatable ADT
  10. ADT-installer - build IPTABLES project
  • Eclipse Plugin
  1. Install Eclipse using the Headless Build
  • Bitbake
  1. show_layers could show current layers - custom output analysts
  2. Check if AUTOPR could be export/lockdown for package build. - 2 poky environments needed
  3. Search path specification - check for certain structure in error output
  4. Sstate overwrite detection - custom shell commands
  5. bitbake-layers flattens layer configuration into a separate output directory - file constructed from other files
  6. Check if there is no python call trace error when do_patch fail - certain type of error as expected result
  7. Check if bitbake-runtask command works. - check exit status of commands
  • OE-CORE
  1. Incremental RPM image generation - complex log analysis
  2. lib64 lsb-sdk image should be built out with multilib support - modifications in local.conf; check boot status of qemu target
  3. Check if buildhistory reports error if PR of some recipes go backwards - complex output analysis; recipe editing; error as expected result
  4. Use archiver.bbclass to filter the source - multistage testing; complex on-target file analysis
  5. Test for bug 2821 - libowl do_fetch error - This is an example test case whose result is based on weather an error appears or not during the whole test suite.
  6. check ssh-server functionality without IMAGE_FEATURES = "debug_tweaks" - failed connection as expected result
  7. Allow logrotate to use a different file system from the original logs.
  8. Provide an image/recipe skeleton as a canonical example. Check if can be built and run correctly.
  9. Check if Yocto supports PAM (Pluggable Authentication Module)
  10. root user's home directory could be dynamically specified
  11. systemd - check failed services
  12. Test same architecture packages rebuild on different machine targets
  • Meta-yocto
  1. Clean obsolete sstate cache files - testing the scripts inside poky/scripts/
  2. kernel interactive targets - testing functionality of features inside new windows
  3. qemu can be started with KVM enabled - features that require special setup
  4. User could use yocto-bsp to create a new Yocto QEMU layer; User could use yocto-kernel to add patches for a BSP kernel recipe; User could use yocto-kernel to set kernel options for BSP kernel; User could use yocto-kernel to remove BSP kernel patch; User could use yocto-kernel to remove kernel options for BSP kernel - Chain of test cases
  5. Running multiple QEMU machines under UNFS - multiple qemu launches
  6. Crosstap script check - build images without sstate; use custom scripts created for a specific test
  • Build-appliance
  1. Check if build-appliance-image could launch hob - special setup and requirements;
  • Stress, Compliance, Performance
  1. LSB subset test suite - Complex operations on target BSP
  2. stress test - Helltest - Jasperforest - Machine state analysis
  3. boot time collection - Crownbay
  4. Collect build performance metrics - tests that require a stable and identical setup environment
  • QEMU specific
  1. Check rpm install/removal log file size - On-target file analysis
  2. g++ compile in sdk image - Create file on target; run command on target; interprets output from command
  3. syslog configurable - Interact with configuration files on target image
  4. video - play (ogg) - simple testing of graphical applications
  5. qt text editor application quicky; ethernet static ip set in connman - complex testing of graphical applications
  • BSP specific
  1. boot and install from USB - Interaction with GRUB
  2. sudoku-savant project compile in sdk image - download files from behind a proxy on target image
  3. vncserver for target - if VNC connection fails there is no output to analyze; 2 systems working together needed
  4. connman offline mode in connman-gnome - no ssh connection
  5. audio - play (mp3) - audio output analysis
  6. audio - play (ogg) with HDMI - output selection
  7. wifi - connect to AP - test AP needed
  8. MicroSD - mount
  9. ethernet get IP in connman via DHCP - DHCP server in test(autobuilder) environment(security issue?)