GBS Automated Testing Guide

From Tizen Wiki
Jump to: navigation, search

Introduction

This document provides information about how to perform automated testing by using Jenkins and OBS in Tizen development tools team, including the following:

  • Jenkins Job Details
  • Installation and Upgrading Testing
  • Code Function Testing
  • Unmerged Patches with Cases Testing
  • Case Testing
  • Sanity(Pre-deployment) Testing
  • Local Full Build Testing
  • Debug with Jenkins Job

Jenkins Job Details

This section describes the functions of three Jenkins Jobs we are using now, they are:

+----+---------------------------+----------------------------------------------------------+
| No.|     Jenkins Job           |   Url of Jenkins Job                                     |
+====+===========================+==========================================================+
| 1  | iTest-GBS-install-upgrade | https://otctools.jf.../ci/job/iTest-GBS-install-upgrade/ |
+----+---------------------------+----------------------------------------------------------+
| 2  |        iTest-GBS          | https://otctools.jf.../ci/job/iTest-GBS/                 |
+----+---------------------------+----------------------------------------------------------+
| 3  |  iTest-GBS-patch-verify   | https://otctools.jf.../ci/job/itest-GBS-patch-verify/    |
+----+---------------------------+----------------------------------------------------------+
| 4  |     gbs-patch-debug       | https://otctools.jf.../ci/job/gbs-patch-debug/           |
+----+---------------------------+----------------------------------------------------------+
| 5  |   OTC-Tools-Tester-gbs    | https://otctools.jf.../ci/job/OTC-Tools-Tester-gbs/      |
+----+---------------------------+----------------------------------------------------------+

ITest-GBS-Install-Upgrade

This jenkins job realized installation and upgrading testing for gbs and its dependency packages on supported distros.Simply,the installation test is install packages from a repo,upgrading test is install packages from old repo,then upgrade packages to new repo. Now upgrading testing function realized installation and upgrading together. Aim is to compare the pkgs' version differences between install from old repo directly and upgrade from old repo to new repo.

The tests with this job are manually,the parameters of this job are configured on the page `Configure`.Including set build parameters,add labels and combination filter(if you want to test on specified distros), and the Executeshell.

The whole test process is transfer the build parameters to script run-install-upgrade-test.sh by the **Execute shell** in `Configure` page,the functions in run-install-upgrade-test.sh realized installation and upgrading actions.

In each install or upgrade test job, kvm slaves are new created and configured. The run-install-upgrade-test.sh script is under tools-testing project in `Gerrit`.

iTest-GBS-install-upgrade job including three build parameters:

   - package_name : the pkg needs to install or upgrade.
   - install_repo : where pkgs install from
   - upgrade_repo : where pkgs upgrade to

ITest-GBS

This jenkins job realized cases testing automatically everyday, the test process is installing gbs from Tools:/Devel repo,using the command **runtest** (provided by pkg itest-core) to run all cases from devel branch of itest-cases-gbs project on all distros.This test method could expose both problems of gbs code and cases.

The kvm slaves are new created and configured during each new triggered job in iTest-GBS, three packages are basic for cases test, they are gbs, itest-core, itest-cases-gbs. The default repos of them are Tools:/Devel, itest:/Devel, itest:/Devel respectively.During new version release period, repos will be changed according to requirements.

The parameters are set in configure on the page `iTest-GBS`, this job uses the script run-itest-kvm.sh which realized specified pkgs' installing and cases running. The command in **Execute shell** including proxies,parameters about pkgs with repos and cases.

The job `iTest-GBS-for-release` is copied from the job `iTest-GBS`, difference is the former one is for cases testing during gbs new version release period, we will specified different repos to install gbs package; the latter one is for everyday's cases testing, at this point gbs is installed from devel repo,and usually we don't modify the configure of job `iTest-GBS` but use the job `iTest-GBS-for-release` for testing.

The script run-itest-kvm.sh is under tools-testing project in `Gerrit`.

iTest-GBS job including one build parameters:

   - args : the parameters will be transfered to script run-itest-kvm.sh,
     which could include pkgs with repos or cases.

ITest-GBS-Patch-Verify

This jenkins job realized testing unmerged gbs patches and cases, the cases including new added ones for gbs patches or several already merged cases. The test process is get the pkgs and repos as variable by parameters, from the repos we are able to install the latest pkgs(gbs and itest-cases-gbs) built with applied unmerged patches. Then trigger the job `iTest-GBS-patch-verify`, transfer the variable to the job. The next step is the same as 2.2 part, install three packages, run cases specified.

This job relates to the script run-itest-kvm.sh, which work in `iTest-GBS` job, details refer to 2.2 part.

iTest-GBS-patch-verify including seven build parameters:

   - GERRIT_PROJECT_CASE  : the project of gbs cases, which could find in `Gerrit`.
   - GERRIT_REFSPEC_CASE  : the patch mark of some case patch in `Gerrit`.
   - GERRIT_PROJECT_TOOLS : the project of gbs, which could find in `Gerrit`.
   - GERRIT_REFSPEC_TOOLS : the patch mark of some gbs patch in `Gerrit`.
   - GERRIT_EVENT_TYPE    : the type corresponds to the patch status in `Gerrit`.
   - GERRIT_BRANCH        : the branch of merged case
   - cases                : the merged cases

Gbs-Patch-Debug

This jenkins job is for debugging work, mainly for debugging the errors occur in the jobs `iTest-GBS`, as well as the script.

For debugging, we usually add the distros in the job `gbs-patch-debug` which built failed in the jobs `iTest-GBS`.Such as add labels **Debian_7-i586-debug** and **Debian_7-i586**,debug machine means Debian_7-i586 kvm slave will be created in open server worker Tester-***,ip of which is **.**.**.**. With this server we are authorized to log in it by ssh, we also could connect the running slaves by vnc viewer with format ip:vnc_number, vnc_number is reported in jenkins concole log.

Non-debug machine means Debian_7-i586 kvm slave will be created in other servers, about those slaves,we only could connect the running slaves by vnc viewer.You can get the address of worker from jenkins, worker-xyz means ip address **.**.**.**,the vnc_number is reported in concole log.

Based on the connection kvm slave ways,we could check environment configuration of slaves during build period.

gbs-patch-debug job including one build parameters:

   - args : the parameters will be transfered to script run-itest-kvm.sh,
     which could include pkgs with repos or cases.

Installation and Upgrading Testing

This section describes the installation and upgrading testing.

Repo Table

All testing works are based on Repos, there're two types of repos, internal OBS live repos and external repos synced from internal OBS live repos.

GBS frequently used internal OBS live repos are:

+----+----------------------------------------------------------------+----------------------------+-----------------------------------------------------+
| No.|               OBS Live repos                                   |   Branch of packages       | Projects in OBS                                     |
+====+================================================================+============================+=====================================================+
| 1  | http://download.otctools.jf.../Tools:/Devel/                   |   devel                    |  Tools:Devel                                        |
+----+----------------------------------------------------------------+----------------------------+-----------------------------------------------------+
| 2  | http://download.otctools.jf.../Tools:/Pre-release/             |   release-*                |  Tools:Pre-release                                  |
+----+----------------------------------------------------------------+----------------------------+-----------------------------------------------------+
| 3  | http://download.otctools.jf.../Tools/                          |   master                   |  Tools                                              |
+----+----------------------------------------------------------------+----------------------------+-----------------------------------------------------+
| 5  | http://download.otctools.jf.../home:/tester:/Tools-gbs-****.2/ |   gerrit unmerged patches  |  home:tester:Tools-<gbs|mic>-<changes-No>-<set-No>  |
+----+----------------------------------------------------------------+----------------------------+-----------------------------------------------------+

GBS frequently used internal archive live repo:

+----+---------------------------------------------------------------+----------------------------+------------------------------------------------------------------+
| No.|             archive internal live repo                        |   OBS Live repos           |  Sync Jenkins Job                                                |
+----+---------------------------------------------------------------+----------------------------+------------------------------------------------------------------+
| 1  | http://download.otctools.jf.../staging/tools/archive/         |   Tools                    |  http://otctools.jf.../ci/view/Release/job/Tools-release/        |
+----+---------------------------------------------------------------+----------------------------+------------------------------------------------------------------+

GBS frequently used external repos:

The first column is the external repos, second column is the internal repos, third column show the jenkins job sync using internal repo to external repo.

+----+---------------------------------------------------+----------------------------------------------------+----------------------------------------------------------------------+
| No.|               external released repos             |               OBS Live repos                       |      Sync Jenkins Job                                                |
+====+===================================================+====================================================+======================================================================+
| 1  | http://download.tizen.org/tools/latest-release/   | http://download.otctools.jf.../Tools               |   https://otctools.jf.../ci/view/Release/job/Tools-release/          |
+----+---------------------------------------------------+----------------------------------------------------+----------------------------------------------------------------------+
| 2  | http://download.tizen.org/tools/pre-release/      | http://download.otctools.jf.../Tools:/Pre-release/ |   https://otctools.jf.../ci/view/Release/job/Tools-prerelease/       |
+----+---------------------------------------------------+----------------------------------------------------+----------------------------------------------------------------------+
| 3  | http://download.tizen.org/tools/archive/          | http://download.otctools.jf.../Tools               |   https://otctools.jf.../ci/view/Release/job/Tools-release/          |
+----+---------------------------------------------------+----------------------------------------------------+----------------------------------------------------------------------+

The GBS upgrading testing can be classified into six categories, as shown in the orientation table below,each test needs two args--OLD_REPO and NEW_REPOS.

+----+---------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------+
| No.|                      OLD_REPO                     |                          NEW_REPO                                             |               Purpose              |
+====+===================================================+===============================================================================+====================================+
| 1  | http://download.tizen.org/tools/latest-release/   | http://download.otctools.jf.../Tools:/Devel/                                  | Normal development testing         |
+----+---------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------+
| 2  | http://download.tizen.org/tools/latest-release/   | http://download.tizen.org/tools/pre-release/                                  | pre-release stage testing          |
+----+---------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------+
| 3  | http://download.tizen.org/tools/latest-release/   | http://download.otctools.jf.../Tools/                                         | Normal development                 |
+----+---------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------+
| 4  | http://download.tizen.org/tools/latest-release/   | http://download.otctools.jf.../staging/tools/archive/<num>                    | Sync job verification              |
+----+---------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------+
| 5  | http://download.tizen.org/tools/latest-release/   | http://download.tizen.org/tools/archive/<num>                                 | Sync job verification              |
+----+---------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------+
| 6  | http://download.tizen.org/tools/archive/<num>     | http://download.tizen.org/tools/latest-release/                               | Sync job verification              |
+----+---------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------+

Itest-core and Itest-cases-gbs frequently used internal live repos are:

+----+-----------------------------------------------------------------------------------+----------------------------+-----------------------------------------------------------------------+
| No.|               OBS Live repos                                                      |   Branch of packages       | Projects in OBS                                                       |
+====+===================================================================================+============================+=======================================================================+
| 1  | http://download.otctools.jf.../itest:/Devel/                                      |   devel                    |  itest:Devel                                                          |
+----+-----------------------------------------------------------------------------------+----------------------------+-----------------------------------------------------------------------+
| 2  | http://download.otctools.jf.../itest:/Pre-release/                                |   release-*                |  itest:Pre-release                                                    |
+----+-----------------------------------------------------------------------------------+----------------------------+-----------------------------------------------------------------------+
| 3  | http://download.otctools.jf.../home:/tester:/Tools-itest-itest-cases-gbs-*****.5/ |   gerrit unmerged patches  |  home:tester:Tools-itest-itest-cases-<gbs|mic>-<changes-No>-<set-No>  |
|    | http://download.otctools.jf.../home:/tester:/Tools-itest-itest-core-****.6/       |                            |  home:tester:Tools-itest-itest-core-<changes-No>-<set-No>             |
+----+-----------------------------------------------------------------------------------+----------------------------+-----------------------------------------------------------------------+

Performing Installation and Upgrading Testing

This section describes the procedures of installation and upgrading testing with jenkins job `iTest-GBS-install-upgrade`,totally including six types of upgrading test.Dased on the introduction about Installer jenkins job above,the detail steps pls follow from 3.2.1 to 3.2.6:

Performing Upgrade to Tools:/Devel Repo Testing

Upgrade testing for `Tools:/Devel` live repo occurs regular development. To perform upgrade to Tools:/Devel testing, following procedure:

Start the testing process,here take upgrade to Tools:/Devel repo as an example.

   -  With the jenkins job `iTest-GBS-install-upgrade`.
   -  Click **Build with Parameters**.
   -  Configure the package_name<gbs>,install_repo and upgrade_repo.
      + pakcage_name : gbs
      + install_repo : -i http://download.tizen.org/tools/latest-release/
      + upgrade_repo : -u http://download.otctools.jf.../Tools:/Devel/
   -  Click **Build** to start the automated testing process.
   -  Click the **HTML Report** to review the test report.

For information about how to review the test report, refer to Appendix.

Performing Upgrade to Pre-Release Repo Testing

To perform upgrade to `tizen_pre-release` repo testing, following procedure:

1. Monitor the packages build status on the OBS.

  By url https://build.otctools.jf.../project/monitor?project=Tools%3APre-release
  Expected results are SUCCEEDED

2. Monitor the repo synchronization status.

  By url https://otctools.jf.../ci/view/Release/job/Tools-prerelease/
  Check whether the latest version pkgs have been rsynced to tools/pre-release/
  in console log,which generates from the new triggered job.
  Expected result is SUCCESS.

3. Start the testing process.

   -  With the jenkins job `iTest-GBS-install-upgrade`.
   -  Click **Build with Parameters**.
   -  Configure the package_name<gbs>,install_repo and upgrade_repo.
   -  Click **Build** to start the automated testing process.
   -  Click the **HTML Report** to review the test report.

For information about how to review the test report, refer to Appendix.

Performing Upgrade to Tools Repo Testing

To perform upgrade to `Tools` repo testing, following procedure:

1. Monitor the packages build status on the OBS.

  By url https://build.otctools.jf.../project/monitor?project=Tools
  Expected results are SUCCEEDED

2. Start the testing process.

   -  With the jenkins job `iTest-GBS-install-upgrade`.
   -  Click **Build with Parameters**.
   -  Configure the package_name<gbs>,install_repo and upgrade_repo.
   -  Click **Build** to start the automated testing process.
   -  Click the **HTML Report** to review the test report.

For information about how to review the test report, refer to Appendix.

Performing Upgrade to internal archive Repo Testing

To perform upgrade to `internal_archive` repo testing, following procedure:

Start the testing process.

   -  With the jenkins job `iTest-GBS-install-upgrade`.
   -  Click **Build with Parameters**.
   -  Configure the package_name<gbs>,install_repo and upgrade_repo.
   -  Click **Build** to start the automated testing process.
   -  Click the **HTML Report** to review the test report.

For information about how to review the test report, refer to Appendix.

Performing Upgrade to external archive Repo Testing

To perform upgrade to `external_archive` repo testing, following procedure:

Start the testing process.

   -  With the jenkins job `iTest-GBS-install-upgrade`.
   -  Click **Build with Parameters**.
   -  Configure the package_name<gbs>,install_repo and upgrade_repo.
   -  Click **Build** to start the automated testing process.
   -  Click the **HTML Report** to review the test report.

For information about how to review the test report, refer to Appendix.

Performing Upgrade to latest-release Repo Testing

To perform upgrade to `latest-release` repo testing, following procedure:

Start the testing process:

   -  With the jenkins job `iTest-GBS-install-upgrade`.
   -  Click **Build with Parameters**.
   -  Configure the package_name<gbs>,install_repo and upgrade_repo.
   -  Click **Build** to start the automated testing process.
   -  Click the **HTML Report** to review the test report.

For information about how to review the test report, refer to Appendix.

Code Function Testing

This section describes the code function testing which should be performed with an unmerged patch on Gerrit, and write new cases if needed.Git fetch patches to local vm manually,run required cases to test whether there are other bugs caused by new patches. Meanwhile,if there are any cases failed,this way could expose grammar mistakes,any changed raise error messages directly; And let write or modify the cases convenintly by debugging new code function.

Automatically test gbs patch and cases for patch with jenkins job please refer to 4.1 part.

To perform function testing, following procedure:

- Fetch the patch to local disk.

- Install GBS/GBP/depanneur/obs-build package locally and switch to the itest project to run required cases by executing the following command :

 If fetch GBS/GBP project patch, run all export and import cases:
 ::
    $ sudo python setup.py install
    $ runtest -v export import
 If fetch depanneur/obs-build project patch, run several required cases:
 ::
    $ sudo make install
    $ runtest -v <case> (for example:runtest -v cases/build/test_build_noinit_clean_ia32.case)

Unmerged patches with cases Testing

The unmerged gbs patches with cases testing on `Gerrit`,the related jenkins job is `iTest-GBS-patch-verify`,detailed function of this job has been introduced in 2.3 chapter.

This section will take two patches as an example to show how to test with jenkins job:

The gbs patch: https://otctools.jf.../review/#/c/1000/

The case patch: https://otctools.jf.../review/#/c/1001/

   -  With the jenkins job `iTest-GBS-patch-verify`.
   -  Click **Build with Parameters**.
   -  Configure the parameters:
      + If test unmerged gbs patch with unmerged cases:
        ::
          * GERRIT_PROJECT_CASE  : itest/itest-cases-gbs
          * GERRIT_REFSPEC_CASE  : refs/changes/21/1000/1
          * GERRIT_PROJECT_TOOLS : gbs
          * GERRIT_REFSPEC_TOOLS : refs/changes/70/1001/1
          * GERRIT_EVENT_TYPE    : patchset-created
          * GERRIT_BRANCH        : devel
          * cases                :
      + If test unmerged gbs patch with several old cases from devel branch:
        ::
          * GERRIT_PROJECT_CASE  :
          * GERRIT_REFSPEC_CASE  :
          * GERRIT_PROJECT_TOOLS : gbs
          * GERRIT_REFSPEC_TOOLS : refs/changes/70/1001/1
          * GERRIT_EVENT_TYPE    : patchset-created
          * GERRIT_BRANCH        : devel
          * cases                : cases/export/gbs_export_VCS.case,cases/export/gbs_export_commit_tag.case
                                 : cases/export
                                 : daily
   -  Click **Build** to start the automated testing process.
   **Note:** Parameter patchset-created of GERRIT_EVENT_TYPE corresponds to unmerged patch in `Gerrit`,default value by now. There are three cases input ways: specific to some case, run all cases under some directory, run fast or daily cases.
             If specific to some cases, please separated them by comma.

Cases testing

Cases testing,the related jenkins job is `iTest-GBS-for-release`,the detailed function of this job has been introduced in 2.2 chapter.So this section mainly in showing how to use this job to test cases.

`iTest-GBS-for-release` job uses the script run-itest-kvm.sh to realize cases testing,command in **Execute shell** on configure page of `iTest-GBS-for-release` shows how to use this script, you can see how to use the subcommands of run-itest-kvm.sh by using this command:

  $ pwd
  tools-testing
  $ ./run-itest-kvm.sh -h

With -m option to specify memory size.

With -t option to specify cases to test.

With -p opthon to specify packages install in vm. This option has four parameters:

  -p home_project,package_name,project,external_repo
     home_project : Tools-<package_name>-<changes-No>-<set-No> in OBS home live repo.
     package_name : package name
     project      : project name of OBS live repo(itest:/Devel,Tools:/Devel,Tools:/Pre-release,Tools)
     external_repo: external repo usually from http://download.tizen.org/tools/(pre-release,archive,latest-release)

- If install package from one repo(home_project or project),the external_repo is blank:

   -p home_project,package_name (eg. -p Tools-gbs-1000.1,gbs)
   -p ,package_name,project (eg. -p ,itest-core,itest:/Devel)

- If install package from two repos(home_project and project),the external_repo is blank:

   -p home_project,package_name,project (eg. -p Tools-gbs-1000.1,gbs,Tools:/Devel)

- If install package from external repo,the home_project and project are blank:

   -p ,package_name,,external_repo (eg. -p ,gbs,,http://download.tizen.org/latest-release)

For example:

- For daily cases testing in daily work, we use three packages from Devel repotest all cases.

   /usr/bin/run-itest-kvm.sh /srv/itest/cases/gbs -m 4096 -p ,itest-core,itest:/Devel -p ,itest-cases-gbs,itest:/Devel -p ,gbs,Tools:/Devel $RUN_ITEST_KVM_ARGV $args
  • Annotation:
   /usr/bin/run-itest-kvm.sh        : script for the whole cases testing.
   /srv/itest/cases/gbs             : cases directory after install pkg itest-cases-gbs in kvm slaves.
   -p ,itest-core,itest:/Devel      : install pkg itest-core from `itest:/Devel` repo.
   -p ,itest-cases-gbs,itest:/Devel : install pkg itest-cases-gbs from `itest:/Devel`_ repo.
   -p ,gbs,Tools:/Devel             : install pkg gbs from `Tools:/Devel` repo.
   $RUN_ITEST_KVM_ARGV              : blank by default.
   $args                            : blank by default.

- During release period, repos and cases should be changed according to different release stages.Based on the daily cases testing, the changed repos and cases could be transfered to run-itest-kvm.sh script by **args** in command. The script work mechanism is the **-p** parameters in **RUN_ITEST_KVM_ARGV** or **args** will cover write the **-p** parameters in previous.

 Take an example to analyze the args of this job:
   + With the jenkins job `iTest-GBS`.
   + Click **Build with Parameters**.
   + Configure the parameters:
     ::
       * args: -p ,itest-cases-gbs,itest:/Pre-release -p ,itest-core, itest:/Pre-release -p ,gbs,,http://download.tizen.org/tools/pre-release/ -t daily
   + Click **Build** to start the automated testing process.
  • Annotation:
   -p ,itest-cases-gbs,itest:/Pre-release  : install pkg itest-cases-gbs from `itest:/Pre-release`_ repo.
   -p ,itest-core,itest:/Pre-release       : install pkg itest-core from `itest:/Pre-release`_ repo.
   -p ,gbs,,http://download.tizen.org/tools/pre-release/ : install package gbs from `tizen pre-release` repo.
   -t daily                                : run daily cases(all cases)
  • Note: fast, pre-release and daily are defined in settings.py in itest-cases-gbs directory.

Sanity(Pre-deployment) Testing

Detail procedure please refer to the document https://wiki.tizen.org/wiki/Release_Process.

Local Full Build Testing

There are two kinds of local full build testings:

1. Daily testing: this testing should be arranged everyday and running in automatically(or manually first) the source that repo sync from is according to the manifest(build.conf and gbs.conf) from review.tizen.org

2. Specified(repo) testing: this testing means the source is from some specified repo from download.tizen.org.

In release progress, local full build testing is needed in each step(devel, pre-release, master).

Debug with Jenkins Job

The function of this job has been introduced in 2.4 part,this part mainly focus on how to debug with jenkins jobs.

- During build period,perhaps the testing process would be blocked by some configuration,such as proxy issues,which leads to testing failed,if in cases like this, let's show how to debug:

  + With the jenkins job `itest-GBS`.
  + Click **configure**.
  + Add Labels in Slaves part of Configuration Matrix.
  + Click **Build with Parameters**.
  + Configure the parameters: 
     Add packages with repos and cases in args as example in 6 part or modify the command in **Execute shell** on configure page directly.
  + Click **Build** to start the automated testing process.
  + Get the vnc number from jenkins console log.
  + Open vnc viewer on your pc.
  + Fill the Server blank with ip and vnc number as format: **.**.**.**:port.
  + Log in with usr:root and passwd:******.
  + Now you could check the envrionment configure of this kvm slave,such as the proxy and tmp repo in /etc dirctory and so on. Because the environment configuration is set by script,comparing with issue log,you could find some clues from script command to
    help find out the problem point.

- If test cases in kvm slave environment,please follow the procedure:

  + ssh itest@**.**.**.**
  + usr:root,passwd:******
  + mkdir test
  + tar SxfO - < /var/lib/jenkins/kvm-seed-hdb.tar > test/kvm-hdb
  + sudo qemu-kvm -name openSUSE_12.2-x86_64 -M pc -cpu core2duo -m 2048 -net nic,macaddr=ac:ac:ac:ac:ac:a1 -net user -drive file=/var/lib/jenkins/kvm-seed-hda-openSUSE_12.2-x86_64-debug snapshot=on -drive file=test/kvm-hdb -vnc :45
    You can see the subcommands of qemu-kvm by using the command:
      $ qemu-kvm -h
    Some parameters need to be pay attentions:
      -name,-cpu and -dirve file=distro drive image path :
                   if arch of distro is i586, then cpu value is pentium3;
                   if arch of distro is x86_64, then cpu value is core2duo
      -net macaddr and -vnc :
                   mac address value should be new in each new kvm slave' set up
      -drive file=kvm hdb image path :
                  create a new dir,get hdb image from uncompressing
                  hdb tarball to this new dir,such as test/kvm-hdb.
                  pen vnc viewer on your pc.
  + Open vnc viewer on your pc.
  + Fill the Server blank with ip and vnc number as format: **.**.**.**:45.
  + Log in with usr:root and passwd:******.
  + Set up proxy:
     export http_proxy=http://*******************:911
     export https_proxy=$http_proxy
     export no_proxy="...,\*...,..,localhost"
  + Add gbs install repo in tmp repo:
     If Ubuntu or debian distro: /etc/apt/source.list.d/tmp.list
     If openSuse distro: /etc/zypp/repo.d/tmp.repo
     If fedora or centos distro: /etc/yum.repos.d/tmp.repo
  + Update tmp repo:
     If Ubuntu or debian distro: apt-get update
     If openSuse distro: zypper --non-interactive ref
     If fedora or centos distro: yum clean all; yum makecache
  + Install gbs:
     If Ubuntu or debian distro: apt-get install -y --force-yes gbs
     If openSuse distro: zypper --non-interactive install gbs
     If fedora or centos distro: yum -y install gbs
  + Install itest-core and itest-cases-gbs packages in kvm slave as install gbs above.
  + Run the cases you choose, such as:
     $ cd /srv/itest/cases/gbs
     $ runtest -vv cases/export/gbs_ex_normal.case
  + Now you could check whether the case result is right,of course you also could reproduce other issues in kvm slave by this debug method.

Appendix

Key points of reviewing HTML report are as follows:

  • "Before" and "After" columns in the HTML report correspond to " OLD_REPO" and "NEW_REPO" columns in the Automated Testing Orientation Table.
  • The version number in blue indicates that the corresponding package has been upgraded.
  • Minor difference of the revision numbers between "After" and "Install" column will cause the number in "Install" column displayed in blue,indicating that tools may not need the latest version of certain package for the time being.
  • Comparison of the "After" and "Install" columns is must-have every time the upgrade to new repo is successfully performed. It's crucial that the major revision numbers in the two columns are exactly the same, the difference of minor revision numbers is not big issue. For example, it's all right that the revision numbers of GBS in the two columns are "0.19-2.1" and "0.19-3.1", respectively, because the major revision number are identical, both of which are 0.19.