From Fedora Project Wiki

(TEST CASE refactoring: moved test cases from test plan to separate wikis, added links to those)
m
Line 2: Line 2:
  
 
{{admon/important|If you can somehow improve quality of this document, please join the fight and help}}
 
{{admon/important|If you can somehow improve quality of this document, please join the fight and help}}
 +
  
  
Line 11: Line 12:
 
|-
 
|-
 
|}
 
|}
 +
  
 
== Testing ABRT ==
 
== Testing ABRT ==

Revision as of 21:15, 17 August 2009

Warning.png
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.
Important.png
If you can somehow improve quality of this document, please join the fight and help


DATE TIME WHERE
2009-08-20 From 12:00 to 21:00 UTC (8am - 5pm EDT, 14:00 - 23:00 CET) #fedora-qa (webirc)


Testing ABRT

Today's installment of Fedora Test Day will focus on Automated Bug Reporting Tool (ABRT). This tool should help non-power users with bug reporting, making it as easy as a few mouse clicks. ABRT is a daemon that watches for application crashes. When a crash occurs, it collects the crash data (core file, application's command line etc.) and takes action according to the type of application that crashed and according to the configuration in the abrt.conf configuration file. Bottom line: do not hunt the bugs with a pitchforks, rather use bugzappers/big light source to draw them from the dark and kill them easily at close range.

ABRT should be easy for users and very useful for developers and admins. Ease of crash/bug reporting and quick response from maintainers based on info from ABRT should make Fedora more stable and thus more attractive for users.

We will test:

  • ABRT GUI;
  • compiled (C/C++) programs support;
  • Python programs support;
  • detection if apps are from supported packages;
  • using configured plugins:
    • database plugin;
    • bugzilla plugin (report crash to bugzilla);
    • file transfer plugin (transfer crash data via network);
    • mailx plugin (send mail when crash happens);
    • kernel oops plugin;
    • RunApp plugin (run arbitrary application when crash happens).

Who's available

The following people will be available for testing, workarounds, bug fixes, and general discussion:

Prerequisite for Test Day

You will need to get current ABRT (select your method):

  1. install latest ABRT from Rawhide
  2. install latest ABRT from its development repository on Fedora 11

<<FIXME: for now we have only internal RedHat IP server, setup public repository!>>. For Redhat internal abrt development server create /etc/yum.repos.d/abrt.repo containing:

[abrt]
name=ABRT
baseurl=http://10.34.33.153/$releasever/$basearch/
gpgcheck=0
enabled=1
  1. download and burn ABRT Testing CD (ISO images will be available at least 24 hours before the test day starts)
Important.png
Note: for reporting to work well, you should have a fully-updated system (Fedora 11 or Rawhide). Reporting uses -debuginfo packages, which have to match the version of the corresponding crashed program's packages. This also avoids reporting a bug which has already been fixed in a later version of the software.


ABRT Documentation

How to start using ABRT

Install abrt and plugins:

# yum install abrt-desktop

This is not needed when you will use ABRT TestDay Live CD.

Important.png
After installation of ABRT you should reboot your computer to have everything working properly.
# chkconfig abrt on 
# reboot

Test basic functionality

Now if something crashes, ABRT will handle the crash. If you want to test this, crash something, for example:

$ xfontsel &
$ killall -6 xfontsel

An icon will appear in the notification area. You can now run the GUI:

$ abrt-gui &

Now select the crash, click "report" to report it, or click "delete" to delete it.

ABRT Test Cases to be tested

Available tests include:

ABRT_Test_Cases might have more TestCases in the future.


Known issues

Consult list of active tickets before reporting an issue. The most common issues are listed below:

  • Recreate Report for same crash - if you want to recreate a report of same crash, you have to remove ABRT's db and cache (rm -r /var/cache/abrt/*) and make a crash gain
  • Nothing happened? - if it seems to do nothing, try to disable PGP checking and restart daemon
  • Graphical warnings - gui writes some gtk warnings
  • rpm %requires - it needs rpm >= 4.7.0-1
  • you cannot use abrt to catch crashes of OpenOffice, KDE and Java apps -- they are catching those crashes themselves.
  • if you're updating from version <= 0.0.5-6 make sure you remove /var/abrt/cache/abrt-db (we've changed the db fomrat and not yet implemented automatic updating mechanism)
  • GUI doesn't inform you about success of failure of a reporting. But you can find results in ABRT's db (default path /var/cache/abrt, it is sqlite3 db, table name is "abrt")

Test Results

Issues that were identified

Tester Description Bug references
User:FasUser ..... #xxx

Things that work alright

Tester Description
User:FasUser ..............


Warning.png
TODO: some tools/scripts/icons for users to help with testing. Let the user easily monitor what is going on, or give him some tools so he can test ABRT even without command line tools. Or is this a bad idea? Please help us with this!
Warning.png
TODO: should users during ABRT test day report bugs directly into Bugzilla? How can we delete all such "bugs" later if they will eat too much space? Or will we use another Bugzilla? Where? How? ? Who can help?