ACT476 Professional Project II Test Case Development Team Name Project Tester

Transcription

1 unique-test-case-id: User-Login and Permissions Check Purpose: Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information into the feature descriptions. Test the login screen for correct inputs and valid user test. Steps for this procedure listed below. This test can be modified to check new user sign-up. Prerequisites: Assumptions that must be met before the test case can be run. E.g., "Valid user list exists in database", "guest logging allowed", "user testuser exists". Test Data: List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each combination of values. These values are written in set notation, one per line. E.g.: loginid = {Valid loginid, invalid loginid, valid , invalid , empty} loginid = {min 6 characters, must be alpha-numeric no special characters} password = {valid, invalid, empty} password = {min 6 characters, must contain at least one number (0-9) and one special character form the following list; ($&!_-), these characters not allowed; (%@#^*)} Steps: Steps to carry out the test. See step formatting rules below. 1. visit LoginPage 2. enter loginid 3. enter password 4. click login button 5. see the terms of use page 6. click agree radio button at page bottom 7. click submit button 8. see PersonalHomePage 9. verify that welcome message is correct username Notes and Questions: In this section enter any thing that happened that would indicate that the code is not working according to design specifications. QUESTIONs Format of test steps: Each step can be written very tersely using the following keywords: login [as ROLE-OR-USER] Log into the system with a given user or a user of the given type. Usually only stated explicitly when the test case depends on the permissions of a particular role or involves a workflow between different users. visit LOCATION Visit a page or screen. For web applications, LOCATION may be a hyperlink. The location should be a well-known starting point (e.g., the Login screen), drilling down to specific pages should be part of the test. enter FIELD-NAME [as VALUE] [in SCREEN-LOCATION] Fill in a named form field. VALUE can be a literal value or the name of a variable defined in the "Test Data" section. The FIELD-NAME itself can be a variable name when the UI field for that value is clear from context, e.g., "enter password". enter FIELDS Fill in all fields in a form, check use case for input restrictions, Check to make sure that the context on the page clearly indicates to the use the information expected. Indicate any fields not tested stating that their specific values are not important in this test case (if they are not important they can probably be removed from the form). click "LINK-LABEL" [in SCREEN-LOCATION] Follow a labeled link or press a button. The screen location can be a predefined panel name or descriptive phrase. Predefined page or section names are based on GUI class names, master template names, or labels of boxes on the page.

2 click BUTTON-NAME [in SCREEN-LOCATION] Press a named button. This step should always be followed by a "see" step to check the results. see SCREEN-OR-PAGE The tester should see the named GUI screen or web page. The general correctness of the page should be testable based on the feature description from the use case. verify CONDITION The tester should see that the condition has been satisfied. This type of step usually follows a "see" step at the end of the test case. verify CONTENT [is VALUE] The tester should see the named content on the current page, the correct values should be clear from the test data, or given explicitly. This type of step usually follows a "see" step at the end of the test case. perform TEST-CASE-NAME This is like a subroutine call. The tester should perform all the steps of the named test case and then continue on to the next step of this test case. Every test case must include a verify step at the end so that the expected output is very clear. A test case can have multiple verify steps in the middle or at the end. Having multiple verify steps can be useful if you want a smaller number of long tests rather than a large number of short tests. Choosing Test Data In system testing, test data should cover the possible values of each parameter based on the requirements. Since testing every value is impractical, a few values should be chosen from each equivalence class. An equivalence class is a set of values that should all be treated the same. Ideally, test cases that check error conditions are written separately from the functional test cases and should have steps to verify the error messages and logs. Realistically, if error test cases are not yet written, it is OK for testers to check for error conditions when performing normal functional test cases. It should be clear which test data, if any, is expected to trigger errors. Example equivalence classes: Strings empty string String consisting solely of white space String with leading or trailing white space syntactically legal: short and long values syntactically legal: semantically legal and illegal values syntactically illegal value: illegal characters or combinations Make sure to test special characters such as #, ", ', &, and < Numbers 0 Make sure to test "Foreign" characters typed on international keyboards empty string, if possible in range positive, small and large in range negative, small and large out of range positive out of range negative with leading zeros

3 Identifiers Radio buttons Checkboxes syntactically invalid (e.g., includes letters) empty string syntactically legal value syntactically legal: reference to existing ID, invalid reference syntactically illegal value one item checked nothing checked, if possible checked unchecked Drop down menus Scrolling Lists File upload select each item in turn select no item, if possible select each item in turn select combinations of items, if possible select all items, if possible blank 0 byte file long file short file name long file name syntactically illegal file name, if possible (e.g., "File With Spaces.tar.gz") Functionality: In testing the functionality of the web sites the following should be tested: 1. Links: {Internal Links; External Links; Mail Links; Broken Links} 2. Forms: {Field validation, Error message for wrong input, Optional and Mandatory fields} 3. Database: {Testing should be done on the database integrity and accessibility} 4. Cookies: {Testing will be done on the client system side, on the temporary Internet files} 5. Performance : {Performance testing can be applied to understand the web site s scalability, or to benchmark the performance in the environment of third party products such as servers and middleware for potential purchase} 6. Connection Speed: {Tested over various networks like Dial Up, ISDN etc.} Load: {What is the max no. of users per time? Check for peak loads and how system

4 behaves Large amount of data accessed by user} 7. Stress: {Continuous Load, Performance of memory, CPU, file handling etc.} 8. Usability: {Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction such as: 1)Ease of learning 2)Navigation 3)Subjective user satisfaction 4)General appearance 9. Server Side Interface: {In web testing the server side interface should be tested. This is done by verify that communication is done properly. Compatibility of server with software, hardware, network and database should be tested.} 10. Client Side Compatibility: {The client side compatibility is also tested in various platforms, using various browsers etc.} 11. Security: {The primary reason for testing the security of a web is to identify potential vulnerabilities and subsequently repair them such as: 1)Network Scanning 2)Vulnerability Scanning 3)Password Cracking 4)Log Review 5)Integrity Checkers 6)Virus Detection}

5 Test Case Name Purpose: Prerequisites: Test Data: Steps: Notes and Questions: