Pages

15 Nov 2012

Rational Robot : A Test Automation Tool


What is Rational Robot ?

  • Rational Robot is a complete set of components for automating the testing of Microsoft Windows client or server and internal application 
  • Rational Robot is an automated functional regression testing tool.

Automated Functional Regression Testing 

  • Functional Test : Functional Tests are designed to make sure that the application performs are it was intended.
  • Regression Test : A Regression Test is a test where an application is subjected to a suite of functional tests at each build to ensure that everything that worked continues to work

Components of Rational Robot

  • Rational Administrator : Create and manage Rational projects to store your testing information .
  • Rational Test Manager : Review and analyze test result .
  • Object Properties :  View and analyze the results of verification point 
  • Rational Site Check : Manage internet and website .


THE V-MODEL OF SOFTWARE TESTING

Software testing is too  important to leave to the end of the project, and the V-Model of testing incorporates testing into
the entire software development life cycle.  In a diagram of the V-Model, the V proceeds down and then up, from
left to right depicting the basic sequence of development and testing activities. The model highlights the
existence of different levels of testing and depicts the way each relates to a different development phase.
Like any model, the V-Model has detractors and arguably has deficiencies and alternatives but it clearly illustrates that
testing can and should start at the very beginning of the project.  (See Goldsmith for a summary of the pros and cons
and an alternative.  Marrik’s articles provide criticism and an alternative.)  In the requirements gathering stage the
business requirements can verify and validate the business case used to justify the project.  The business
requirements are also used to guide the user acceptance testing.   The model illustrates how each subsequent phase
should verify and validate work done in the previous phase, and how work done during development is used to guide
the individual testing phases.  This interconnectedness lets us identify important errors, omissions, and other
problems before they can do serious harm.  Application testing begins with Unit Testing, and in the section titled

  " Types of Tests ” we will discuss each of these test phases in more detail.


How to Test Web Applications against SQL Injection Attacks


Security testing of web applications against SQL Injection, explained with simple examples – By Inder P Singh.
Many applications use some type of a database. An application under test might have a user interface that accepts user input that is used to perform the following tasks:
1: Show the relevant stored data to the user eg: the application checks the credentials of the user using the log in information entered by the user and exposes only the relevant functionally and data to the user .
Many applications use some type of a database.

 An application under test might have a user interface that accepts user input that is used to perform the following tasks:
2: Save the data entered by the user to the database e.g. once the user fills up a form and submits it, the application proceeds to save the data to the database; this data is then made available to the user in the same session as well as in subsequent sessions
Some of the user inputs might be used in framing SQL statements that are then executed by the application on the database. It is possible for an application NOT to handle the inputs given by the user properly. If this is the case, a malicious user could provide unexpected inputs to the application that are then used to frame and execute SQL statements on the database. This is called SQL injection. The consequences of such an action could be alarming.

The following things might result from SQL injection:

1. The user could log in to the application as another user, even as an administrator.
2. The user could view private information belonging to other users e.g. details of other users’ profiles, their transaction details etc.
3. The user could change application configuration information and the data of the other users.
4. The user could modify the structure of the database; even delete tables in the application database.
5. The user could take control of the database server and execute commands on it at will.
Since the consequences of allowing the SQL injection technique could be severe, it follows that SQL injection should be tested during the security testing of an application. Now with an overview of the SQL injection technique, let us understand a few practical examples of SQL injection.
Important: The SQL injection problem should be tested only in the test environment.
If the application has a log in page, it is possible that the application uses a dynamic SQL such as statement below. This statement is expected to return at least a single row with the user details from the Users table as the result set when there is a row with the user name and password entered in the SQL statement.
SELECT * FROM Users WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & “’;
If the tester would enter Babu as the strUserName (in the textbox for user name) and 123456  as strPassword (in the textbox for password), the above SQL statement would become:
SELECT * FROM Users WHERE User_Name = ‘Babu’ AND Password = '123456 ’;
If the tester would enter Babu’– as strUserName and no strPassword, the SQL statement would become:
SELECT * FROM Users WHERE User_Name = ‘Babu’– AND Password = ‘’;
Note that the part of the SQL statement after John is turned into a comment. If there were any user with the user name of Babu in the Users table, the application could allow the tester to log in as the user Babu. The tester could now view the private information of the user Babu.
What if the tester does not know the name of any existing user of the application? In such a case, the tester could try common user names like admin, administrator and sysadmin. If none of these users exist in the database, the tester could enter Babu’ or ‘x’=’x' as strUserName and 123456  or ‘x’=’x'  as strPassword. This would cause the SQL statement to become like the one below.
SELECT * FROM Users WHERE User_Name = ‘Babu’ or ‘x’='x’ AND Password = ‘123456’ or ‘x’=’x’;
Since ‘x’=’x’ condition is always true, the result set would consist of all the rows in the Users table. The application could allow the tester to log in as the first user in the Users table.
Important: The tester should request the database administrator or the developer to copy the table in question before attempting the following SQL injection.
If the tester would enter Babu’; DROP table users_details;’—as strUserName and anything as strPassword, the SQL statement would become like the one below.
SELECT * FROM Users WHERE User_Name = ‘Babu’; DROP table users_details;’ –‘ AND Password = '123456’;
This statement could cause the table “users_details” to be permanently deleted from the database.
Though the above examples deal with using the SQL injection technique only the log in page, the tester should test this technique on all the pages of the application that accept user input in textual format e.g. search pages, feedback pages etc.
SQL injection might be possible in applications that use SSL. Even a firewall might not be able to protect the application against the SQL injection technique.
I have tried to explain the SQL injection technique in a simple form. I would like to re-iterate that SQL injection should be tested only in a test environment and not in the development environment, production environment or any other environment. Instead of manually testing whether the application is vulnerable to SQL injection or not, one could use a web vulnerability scanner that checks for SQL injection.

Web and Desktop Application Security Testing Techniques

Software industry has achieved a solid recognition in this age. In the recent decade, however, cyber-world seems to be even more dominating and driving force which is shaping up the new forms of almost every business. Web based ERP systems used today are the best evidence that IT has revolutionized our beloved global village.
These days, websites are not meant only for publicity or marketing but these have been evolved into the stronger tools to cater complete business needs. Web based Payroll systems, Shopping Malls, Banking, Stock Trade application are not only being used by organizations but are also being sold as products today.
This means that online applications have gained the trust of customers and users regarding their vital feature named as SECURITY. No doubt, the security factor is of primary value for desktop applications too. However, when we talk about web, importance of security increases exponentially. If an online system cannot protect the transaction data, no one will ever think of using it. Security is neither a word in search of its definition yet, nor is it a subtle concept. However, I would like to list some complements of security.

Examples of security flaws in an application:

1) A Student Management System is insecure if ‘Admission’ branch can edit the data of ‘Exam’ branch
2) An ERP system is not secure if DEO (data entry operator) can generate ‘Reports’
3) An online Shopping Mall has no security if customer’s Credit Card Detail is not encrypted
4) A custom software possess inadequate security if an SQL query retrieves actual passwords of its users
Security Testing Definition:
Now, I present you a simplest definition of Security in my own words. “Security means that authorized access is granted to protected data and unauthorized access is restricted”. So, it has two major aspects; first is protection of data and second one is access to that data. Moreover, whether the application is desktop or web based, security revolves around the two aforementioned aspects. Let us have an overview of security aspects for both desktop and web based software applications.
Desktop and Web Security Testing:
A desktop application should be secure not only regarding its access but also with respect to organization and storage of its data. Similarly, a web application demands even more security with respect to its access, along with data protection. Web developer should make the application immune to SQL Injections, Brute Force Attacks and XSS (cross site scripting). Similarly, if the web application facilitates remote access points then these must be secure too. Moreover, keep in mind that Brute Force Attack is not only related to web applications, desktop software is also vulnerable to this.
I hope this foreword is enough and now let me come to the point. Kindly accept my apology if you so far thought that you are reading about the subject of this article. Though I have briefly explained software Security and its major concerns, but my topic is ‘Security Testing’. In order to know further details of security aspects, kindly refer to – Web application security testing article.
I will now explain how the features of security are implemented in software application and how should these be tested. My focus will be on Whats and Hows of security testing, not of security.

Security Testing Techniques:

1) Access to Application:

Whether it is a desktop application of website, access security is implemented by ‘Roles and Rights Management’. It is often done implicitly while covering functionality, e.g.in a Hospital Management System a receptionist is least concerned about the laboratory tests as his job is to just register the patients and schedule their appointments with doctors. So, all the menus, forms and screen related to lab tests will not be available to the Role of ‘Receptionist’. Hence, the proper implementation of roles and rights will guarantee the security of access.
How to Test: In order to test this, thorough testing of all roles and rights should be performed. Tester should create several user accounts with different as well multiple roles. Then he should use the application with the help of these accounts and should verify that every role has access to its own modules, screens, forms and menus only. If tester finds any conflict, he should log a security issue with complete confidence.

2. Data Protection:

There are further three aspects of data security. First one is that a user can view or utilize only the data which he is supposed to use. This is also ensured by roles and rights e.g. a TSR (telesales representative) of a company can view the data of available stock, but cannot see how much raw material was purchased for production.
So, testing of this aspect is already explained above. The second aspect of data protection is related to how that data is stored in the DB. All the sensitive data must be encrypted to make it secure. Encryption should be strong especially for sensitive data like passwords of user accounts, credit card numbers or other business critical information. Third and last aspect is extension of this second aspect. Proper security measures must be adopted when flow of sensitive or business critical data occurs. Whether this data floats between different modules of same application, or is transmitted to different applications it must be encrypted to make it safe.
How to Test Data Protection: The tester should query the database for ‘passwords’ of user account, billing information of clients, other business critical and sensitive data and should verify that all such data is saved in encrypted form in the DB. Similarly (s)he must verify that between different forms or screens, data is transmitted after proper encryption. Moreover, tester should ensure that the encrypted data is properly decrypted at the destination. Special attention should be paid on different ‘submit’ actions. The tester must verify that when the information is being transmitted between client and server, it is not displayed in the address bar of web browser in understandable format. If any of these verifications fail, the application definitely has security flaw.

3. Brute-Force Attack:

Brute Force Attack is mostly done by some software tools. The concept is that using a valid user ID, software attempts to guess the associated password by trying to login again and again. A simple example of security against such attack is account suspension for a short period of time as all the mailing applications like ‘Yahoo’ and ‘Hotmail’ do. If, a specific number of consecutive attempts (mostly 3) fail to login successfully, then that account is blocked for some time (30 minutes to 24 hrs).
How to test Brute-Force Attack: The tester must verify that some mechanism of account suspension is available and is working accurately. (S)He must attempt to login with invalid user IDs and Passwords alternatively to make sure that software application blocks the accounts that continuously attempt login with invalid information. If the application is doing so, it is secure against brute-force attack. Otherwise, this security vulnerability must be reported by the tester.
The above three security aspects should be taken into account for both web and desktop applications while, the following points are related with web based applications only.

4. SQL Injection and XSS (cross site scripting):

Conceptually speaking, the theme of both these hacking attempts is similar, so these are discussed together. In this approach, malicious script is used by the hackers in order to manipulate a website. There are several ways to immune against such attempts. For all input fields of the website, field lengths should be defined small enough to restrict input of any script e.g. Last Name should have field length 30 instead of 255. There may be some input fields where large data input is necessary, for such fields proper validation of input should be performed prior to saving that data in the application. Moreover, in such fields any html tags or script tag input must be prohibited. In order to provoke XSS attacks, the application should discard script redirects from unknown or untrusted applications.
How to test SQL Injection and XSS: Tester must ensure that maximum lengths of all input fields are defined and implemented. (S)He should also ensure that defined length of input fields does not accommodate any script input as well as tag input. Both these can be easily tested e.g. if 20 is the maximum length specified for ‘Name’ field; and input string “<p>thequickbrownfoxjumpsoverthelazydog” can verify both these constraints. It should also be verified by the tester that application does not support anonymous access methods. In case any of these vulnerabilities exists, the application is in danger.

5. Service Access Points (Sealed and Secure Open)

Today, businesses depend and collaborate with each other, same holds good for applications especially websites. In such case, both the collaborators should define and publish some access points for each other. So far the scenario seems quite simple and straightforward but, for some web based product like stock trading, things are not so simple and easy. When there is large number of target audience, the access points should be open enough to facilitate all users, accommodating enough to fulfill all users’ requests and secure enough to cope with any security-trial.
How to Test Service Access Points: Let me explain it with the example of stock trading web application; an investor (who wants to purchase the shares) should have access to current and historical data of stock prices. User should be given the facility to download this historical data. This demands that application should be open enough. By accommodating and secure, I mean that application should facilitate investors to trade freely (under the legislative regulations). They may purchase or sale 24/7 and the data of transactions must be immune to any hacking attack. Moreover, a large number of users will be interacting with application simultaneously, so the application should provide enough number access point to entertain all the users.
In some cases these access points can be sealed for unwanted applications or people. This depends upon the business domain of application and its users, e.g. a custom web based Office Management System may recognize its users on the basis of IP Addresses and denies to establish a connection with all other systems (applications) that do not lie in the range of valid IPs for that application.
Tester must ensure that all the inter-network and intra-network access to the application is from trusted applications, machines (IPs) and users. In order to verify that an open access point is secure enough, tester must try to access it from different machines having both trusted and untrusted IP addresses. Different sort of real-time transactions should be tried in a bulk to have a good confidence of application’s performance.  By doing so, the capacity of access points of the application will also be observed clearly.
Tester must ensure that the application entertains all the communication requests from trusted IPs and applications only while all the other request are rejected. Similarly, if the application has some open access point, then tester should ensure that it allows (if required) uploading of data by users in secure way. By this secure way I mean, the file size limit, file type restriction and scanning of uploaded file for viruses or other security threats. This is all how a tester can verify the security of an application with respect to its access points.

How to find a bug in application?


If you are a software tester or a QA engineer then you must be thinking every minute to find a bug in an application. And you should be!

I think finding a blocker bug like any system crash is often reward
ing! No I don’t think like that. You should try to find out the bugs that are most difficult to find and those always misleads users.

The TIPS are


1) Understand the whole application or module in depth before starting the testing.

2) Prepare good test cases before start to testing. I mean give stress on the functional test cases which includes major risk of the application.

3) Create a sufficient test data before tests, this data set include the test case conditions and also the database records if you are going to test DB related application.

4) Perform repeated tests with different test environment.

5) Try to find out the result pattern and then compare your results with those patterns.

6) When you think that you have completed most of the test conditions and when you think you are tired somewhat then do some monkey testing.

7) Use your previous test data pattern to analyse the current set of tests.

8) Try some standard test cases for which you found the bugs in some different application. Like if you are testing input text box try inserting some html tags as the inputs and see the output on display page.