Sample test cases

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