A test case is a detailed procedure that fully tests a feature or an aspect of a feature. Whereas the test plan describes what to test, a test case describes how to perform a particular test. You need to develop a test case for each test listed in the test plan. Figure 2.10 illustrates the point at which test case design occurs in the lab development and testing process.
A test case includes:
- The purpose of the test.
- Special hardware requirements, such as a modem.
- Special software requirements, such as a tool.
- Specific setup or configuration requirements.
- A description of how to perform the test.
- The expected results or success criteria for the test.
Test cases should be written by a team member who understands the function or technology being tested, and each test case should be submitted for peer review.
Organizations take a variety of approaches to documenting test cases; these range from developing detailed, recipe-like steps to writing general descriptions. In detailed test cases, the steps describe exactly how to perform the test. In descriptive test cases, the tester decides at the time of the test how to perform the test and what data to use.
Most organizations prefer detailed test cases because determining pass or fail criteria is usually easier with this type of case. In addition, detailed test cases are reproducible and are easier to automate than descriptive test cases. This is particularly important if you plan to compare the results of tests over time, such as when you are optimizing configurations. Detailed test cases are more time-consuming to develop and maintain. On the other hand, test cases that are open to interpretation are not repeatable and can require debugging, consuming time that would be better spent on testing.
Test Case Design
Test Case ID:
It is unique number given to test case in order to be identified.
Test description:
The description if test case you are going to test.
Revision history:
Each test case has to have its revision history in order to know when and by whom it is created or modified.
Function to be tested:
The name of function to be tested.
Environment:
It tells in which environment you are testing.
Test Setup:
Anything you need to set up outside of your application for example printers, network and so on.
Test Execution:
It is detailed description of every step of execution.
Expected Results:
The description of what you expect the function to do.
Actual Results:
pass / failed
If pass - What actually happen when you run the test.
If failed - put in description of what you've observed.
Writing Test Cases
What is a test case
There are many ways to write test cases. Overall, we can say a test case is a code fragment that programmatically checks that another code unit - a method - functions as expected. In order to make the testing process an efficient one, it is recommended to use a testing framework. There are two major java testing framework.
- JUnit is written by Eric Gamma of the GoF fame and Kent Beck. JUnit has long been un-unchallenged in the testing framework arena.
- TestNG, written by Cedric Beust is a newer framework, which uses innovative concepts, much of which have been picked up by JUnit in the 4.x versions.
Using a framework to develop your test cases has a number of advantages, most important being that others will be able to understand test cases and easily write new ones and that most development tools enable for automated and / or one click test case execution. Which of the frameworks you'll choose, that's a matter of personal preference. Both enable you to properly test your code, are equally well supported by Java development tools that matter and both are easy to use. In this article we'll address only JUnit test case development issues.
How to Write Test Cases with JUnit
If you're using a version earlier then JUnit 4, it is mandatory for your test case to inherit from the TestCase class, like in the following code example:
public class ExampleTestCase extends TestCase {
...
}
JUnit Coding Conventions
A JUnit test case can contain multiple tests. Each test is implemented by a method. The declaration of a test method must comply to a set of conventions in order to help JUnit and associated tools to automate the discovery and execution of tests. These conventions are:
- the name of the method must begin with "test", like in "testCreateUser",
- the return type of a test method must be null,
- a test method must not throw any exception,
- a test method must not have any parameter.
Suppose you need to test the following method: public User createUser(String userName, String password1, String password2) throws PasswordDeosntMatchException { ... }. A typical test case for this method could look like this:
public class CreateUserTestCase extends TestCase {
public void testCreateUser() {v ...
}
public void testCreateUserFailPasswordDoesntMatch() {
...
}
}
How to Write a Success Test With JUnit
Why write three tests for one single method, you may ask? Well, this will be better explained in the article that explains how todevelop test cases . For now, let's just say that you must not only test that your method works as expected under normal conditions, but also that it fails as expected when current environment configuration requires it.
The first method will simply call the method then compare the returned object with the provided parameters if the user was properly created. To compare the result with reference values you should use the assert family of methods. Also, we must not forget to force the test to fail if the exception is thrown when it is not supposed to. Here is how you could implement "testCreateUser()":
public void testCreateUser() {
try {
User ret = instance.createUser("john", "pwd", "pwd");
// use assertEquals to compare the name
// of the returned User instance with the reference value
assertEquals(ret.getUserName(), "john");
// use assertEquals to compare the pasword
// of the returned User instance with the reference value
assertEquals(ret.getPassword(), "pwd");
} catch (PasswordDeosntMatchException e) {
// force the test to fail, because the exception was thrown
// and it shouldn't have
fail();
}
}
The assertEquals method will compare the two provided values and if they're not equal, it will generate an internal exception which will inform JUnit about the failure. Also, if PasswordDeosntMatchException is thrown - knowing that this should not happen with the set of parameters we have provided - the fail() method will have the same effect. In either case, JUnit will mark the test as failed and report it as such. You can pass a message to the assertEquals and fail methods. This message will be shown in the report when that particular assertion fails, helping developers to more easily identify errors. This feature can be particularly helpful if you maintain a large test base each with many assertion points. How do test case templates look like?
Software test case templates are blank documents that describe inputs, actions, or events, and their expected results, in order to determine if a feature of an application is working correctly. Test case templates contain all particulars of test cases. For example, one test case template is in the form of a 6-column table, where column 1 is the "test case ID number", column 2 is the "test case name", column 3 is the "test objective", column 4 is the "test conditions/setup", column 5 is the "input data requirements/steps", and column 6 is the "expected results".
All documents should be written to a certain standard and template. Why? Because standards and templates do help to maintain document uniformity. Also because they help you to learn where information is located, making it easier for users to find what they want. Also because, withstandards and templates, information is not be accidentally omitted from documents.
Introduction-TEST PLAN
A test plan is a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.
In software testing, a test plan gives detailed testing information regarding an upcoming testing effort, including
Scope of testing.
Schedule.
Test Deliverables.
Release Criteria.
Risks and Contingencies.
No comments:
Post a Comment