{% extends "QAWeb/index.html" %} {% block MainTitle %}How it works{% endblock %} {% block SecondTitle %}How it works{% endblock %} {% block topbox %}{% endblock%} {% block desc %} {% endblock %} {% block content %}
The System Architecture | Setup and Installation | Using a Python Script | Choosing the Correct IDs | Access to the Admin Panel |
The graph below shows the proposed architecture for the usage of QAWeb. Usually, QA Testers have to test the software under different platforms and configurations. That in practice could mean that they must perform testing on different physical devices (e.g. laptops, thin clients, PCs, etc.). The assumption here is that all these devices are in a common network and they can reach a main server via SSH. The main server (i.e. center of the graph) is the one that hosts QAWeb in a webserver, giving access to python scripts that provide access to the Django models and can alter QAWeb's database directly. In this way, we create a linkage between the web interface and the output of tests. These tests can run in any remote device and just communicate all the information via SSH to QAWeb for generating and presenting the statistics. The described solution is not over-sophisticated, but it gives a lot of flexibility to anyone that uses scripting languages for test automation (i.e. probably the majority of QA Testers).
Auto-SSH (via ssh-keys = no password) to the server that hosts QAWeb.
Execute a single dedicated python script at the WebServer's side, create or update a Test Case and the statistics will be auto-updated.
You MUST provide a unique Test Case ID, to either update or create a Test Case.
QA Testers invoke the python script via SSH, for each Test Case that they want to appear in the QAWeb statistics.
Testers only need to add a few lines of code under each Test Case they run.
QAWeb does not care about the reporting structure, instead it provides One! Database is fully controlled and easily maintainable.
Statistics are reflected on a "real-time base", as the database gets updated via the script calls.
Any system can use the tool from any location, as long as it has SSH Access and Permission to the webserver that hosts the QAWeb.
Adding more teams name, project name or states is very easy, it can be done via the admin panel.
There might be more...
Need ssh-keys-pairs per machine (Not ideal, but not the end of the world:).
Adding or Removing model fields to the existing Test Case structure, means changes to the QAWeb database and to the python script(s).
Backward compatibility with the database (if we perform often model changes), becomes harder! (Of course, not impossible)
QAWeb does not maintain (at the least, not at the moment) history of the QA statistics. It's just the real reflection of the QAWeb database, at any given time.
There might be more...
This section cannot bring you up-to-speed with all the Django internals and therefore it assumes some kind of familiarity with the framework. If you are not familiar with Django, you are advised to visit the official Django Documentation. This will help you to understand better how QAWeb functions internally and it will allow you to customize it easier, based on your needs.
The following part is just a sample of basic configuration that you can use for the lighttpd webserver. Of course, you are free to use any other webserver. Guidelines for the configuration of webserver such as apache or nginx, could be found in the offical Django Documentation website.
$HTTP["host"] =~ "qaweb.localhost.com"{ # you should adjust it
server.document-root = "/var/www/portal/" # you should adjust it
# Fastcgi modules should be enabled.
fastcgi.server = (".fcgi" => ((
"bin-path" => "/var/www/portal/portal.fcgi", # you should adjust it
"socket" => "/tmp/portal.sock",
"check-local" => "disable",
"min-procs" => 1,
"max-procs" => 4,
)))
alias.url = (
"/static" => "/var/www/portal/portal/static/", # you should adjust it
"/media" => "/var/www/portal/portal/static/media/", # you should adjust it
)
url.rewrite-once = (
"^(/media.*)$" => "$1",
"^(/static.*)$" => "$1",
"^/favicon\.ico$" => "/static/favicon.ico",
"^(/.*)$" => "/portal.fcgi$1",
)
}
The provided tarball for downloading QAWeb contains the entire django project for QAWeb and not just the django app. This is not ideal, but it will let you setup QAWeb without major effort. By just untarring the project, adjusting the paths into the lighttd.conf, the database passwords/names/paths into the settings.py file and the portal.fcgi, you should be able to host QAWeb. The more familiar you become with Django, the easiest would be to setup QAWeb into your system. Main requirement is that you have already installed some additional python packages used for the search engine and the creation of the graphs:
As we already described on the System Architecture section, the access will be given via SSH-Key-Pairs on a per machine base. That will allow automatic ssh-login without a password and it will give the ability to the testers to call the python script from inside the source code of their tests. In order to obtain ssh access, you should generate your ssh-key-pair by using ssh-keygen (see SSH Key Pairs HOWTO).
The key-point here is that we are able to write python scripts that have access to the defined Django models of QAWeb, without necessarily these scripts being part of the QAWeb core code. You could think these scripts as "external" python scripts that import the Django packages and QAWeb models, and let us perform certain tasks, such as creating entries in the database or sending an email notificaton. In our case, we use two such scripts, namely : reportTestCase.py and emailTestCases.py
The reportTestCase.py is the python script that will create or update the QAWeb database entries, based on the test case ID. There are two proposed ways of usage for this script. Both ways are remote via SSH and they are using the reportTestCase.py. The difference is that on the first case the QA Tester should pass directly the arguments for the options to the reportTestCase.py, while on the second case the options can be passed indirectly on a bash script. Obviously, the first option means that the QA Testers should integrate the SSH call inside their code, while the second method is more flexible since it could just integrate a bash script call with parameters, keeping as clean as possible their code. Think the first approach as multiple points of SSHing and calling reportTestCase.py and the second one as a single point for SSHing and calling reportTestCase.py with different parameter every time. Of course, there is a lot of freedom on that part and someone could customize the calls as it is desired. That's why we believe that QAWeb architecture is quite flexible.
1. Adding the script call to the Test Case code
#!/bin/bash |
2. Invoking an external bash script with parameters from the Test Case code
#!/bin/bash |
The emailTestCases.py is just a script that can be scheduled via a cron system job and it will send an email with all the graphs attached to the specified users. It was written as a proof of concept that you could receive easily a daily e-mail notification with the status of all the Test Cases that exist in QAWeb. It is part of the given tarball and you could experiment with it.
The table that follows, contains all the Project Names, Team Names and Test Case States that exist on the system, together with their corresponding IDs. As it was described on the above section for the Python Script, each tester will have to pass a number of options. That table constitutes the most updated reference (real time read of the database) for making sure that a Test Case will be categorized correctly. If for any reason the IDs are mixed, that will causea incorrect statistics. Test Cases will end up being on the wrong Project, Team, or with a false State. Therefore, it is very important that the ID options passed to the python script are double checked and verified via the provided table. Project Names, Team Names and Test Case States, can be added easilly from the admin panel. When a new Project Name, Team Name or a Test Case State are added to the system, then a new ID number is created for them. On the other hand, when an existing name is deleted, the ID number belonging to that name, stops to be relevant anymore. Hopefully, the system capabilities will become clearer, as you start using QAWeb.
|
|
|
Access to the admin panel should be given only to a few people, in order to avoid any issues. The panel provides a certain flexibility and it gives ways to update, edit and extend the Web Portal content in a very easy way. The screenshot below shows all the Test Cases that exist in the system admin environment. The administrator can again edit, add or delete manually a Test Case. The screenshot below shows the general admin panel view. Here the administrator can choose to add, delete or even rename, a Team's Name, a Project's Name or a Test Case State.