stqa manual 2018-19 · laboratory mannual contents this manual is intended for the third year...

JawaharlalNehruEngineeringCollege

Laboratory Manual

LAB VI SOFTWARE TESTING AND QUALITY ASSURANCE

For

TE IT Students

FORWARD

It is my great pleasure to present this laboratory manual for Third year engineering students for the practical subject of Lab VI Software Testing and Quality Assurance Computing keeping in view the vast coverage required for visualization of concepts of software testing using c langanguage, Selenium testing tool, Bugzilla and Jmeter software with examples. As a student, many of you may be wondering with some of the questions in your mind regarding the subject and exactly what has been tried is to answer through this manual. As you may be aware that MGM has already been awarded with ISO 9001-2015 certification and it is our endure to -technically equip our students taking the advantage of the procedural aspects of ISO 9001-2015 Certification. Faculty members are also advised that covering these aspects in initial stage itself, will greatly relived them in future as much of the load will be taken care by the enthusiasm energies of the students once they are conceptually clear.

Dr. H. H. Shinde Principal

LABORATORYMANNUALCONTENTS

This manual is intended for the Third year students of IT engineering branch in the subject of Lab VI Software Testing and Quality Assurance. This manual typically contains practical/Lab Sessions related Software Testing and Quality Assurance covering various aspects related the subject to enhanced understanding. Although, as per the syllabus, software testing examples are prescribed, we have made the efforts to cover various aspects of Software Testing and Quality Assurance. Students are advised to thoroughly go through this manual rather than only topics mentioned in the syllabus as practical aspects are the key to understanding and conceptual visualization of theoretical aspects covered in the books. Good Luck for your Enjoyable Laboratory Sessions D.K.Budhwant Information Technology Department

SUBJECTINDEX

1. Study of Manual and Automated Testing.

2. Write a program in C for Matrix multiplication and check its failure also introspect the causes for its

failure and write down the possible reasons for its failure.

3. Take any system (e.g. ATM system) and study its system specifications and report the various bugs.

4. Write the test cases for any known application (e.g. Banking application)

5. Create a test plan document for any application (e.g. Library Management system)

6. Test any one web application using Selenium testing tool.

7. Study of any bug tracking tool (e.g. Bugbit)

8. Test any Java application using JMeter.

9. Creating a test report using BugZilla.

10. Design and Develope test cases for Mobile application.

DO’s and Don’ts in Laboratory: 1. Do not handle any equipment before reading the instructions/Instruction manuals 2. Read carefully the power ratings of the equipment before it is switched on whether Ratings 230 V/50 Hz or 115V/60 Hz. For Indian equipments, the power ratings are Normally 230V/50Hz. If You have equipment with 115/60 Hz ratings, do not insert Power plug, as our normal supply is 230V/50 Hz, which will damage the equipment. 3. Observe type of sockets of equipment power to avoid mechanical damage 4. Do not forcefully place connectors to avoid the damage 5. Strictly observe the instructions given by the teacher/Lab Instructor Instruction for Laboratory Teachers:: 1. Submission related to whatever lab work has been completed should be done during the next lab session. The immediate arrangements for printouts related to submission on the day of practical assignments. 2. Students should be taught for taking the printouts under the observation of lab teacher. 3. The promptness of submission should be encouraged by way of marking and evaluation patterns that will benefit the sincere students.

Experiment 1

Study of Manual and Automated Testing.

1. Testing is a process of executing a program with the intent of finding anerror. 2. A good test case is one that has a high probability of finding an as yet undiscoverederror. 3. A successful test is one that uncovers an as yet undiscoverederror.

Testing of software can be done in both Automation and Manual testing method, but it’s totally depends on the project requirement, budget associated with the project, and which testing method will be benefited to the project. This article provides basic information about Manual Testing and Automation Testing, enjoy reading it and let us know in the comment about which one is best for your project. Automation Testing: The method takes automation tool support to execute the test cases is known as Automation Testing. Automated testing is good for large project. It is a method which uses automation tools to run tests that repeat predefined actions, matches the developed program’s probable and real results. If the project prospects and results align, your project is behaving as it should, and you are likely bug free. If the two don’t align, still, there is a problem that requires to be addressed. You’ll have to take a look at your code, alter it, and continue to run tests until the actual and expected outcomes align. Manual Testing: Manual testing is a method used by software developers to run tests manually. There are many manual testing types which are carried out manually as well as automatically. These are, Black Box Testing – It is a testing method to test functionalities and requirements of the system. It does not test the internal part of the system. White Box Testing – It is a testing method based on information of the internal logic of an application’s code and also known as Glass box Testing. It works on Internal working code of the system. Tests are based on coverage of code statements, branches, paths, conditions. Integration Testing – Integrated modules testing method to verify joint functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially applicable to client/server and distributed systems. System Testing – It is a technique to test whole system.

Comparison between Automation Testing and Manual testing

Automation Testing Manual Testing

Automation testing perform the same operation each time

Manual testing is not reliable. Using this method test execution is not accurate all the time.

Automation testing is very much helpful regressions in testing where code changes frequently.

To execute the test cases first time using manual testing will be very much useful. But it is not sure that it will catch the regression defects under frequently changing requirements.

Automation testing will be useful to execute the set of test cases frequently.

Manual testing will be useful when the test case only needs to run once or twice.

After making Automation test suites, fewer testers required to execute the test cases.

To execute the test cases every time tester requires the same amount of time.

Automation testing can also be done on different machine with different OS platform combination, concurrently.

Using manual testing,testing on different machine with different OS platform combination is not possible, concurrently. To execute such task different testers are required.

Using Automation testing, testers can test complicated application too.

It does not involve in programming task to fetch hidden information.

Automation runs test cases significantly faster than human resources.

Manual testing is slower than automation. Running tests manually can be very time consuming.

Some time it is not helpful in UI testing It is very much helpful in UI testing

Automation testing is very useful for automating the Build Verification Testing (BVT) & it is not mundane and tiresome.

To execute the Build Verification Testing (BVT) is very mundane and tiresome in manual testing.

Initial cost of automation testing is more than manual testing but useful always.

Manual testing requires less cost than automation.

Experiment 2 A program written in c language for matrix multiplication fails “Introspectthe causes for its failure and write down the possible reasons for itsfailure”.

#include<stdio.h> #include<conio.h> void main() { int a[3][3],b[3][3],c[3][3],i,j,k,m,n,p,q; clrscr(); printf(― Enter 1stmatrix no.of rows & cols‖ ) scanf(―%d%d‖ ,&m,&n); printf(― Enter 2ndmatrix no.of rows & cols‖ ) scanf(―%d%d‖ ,&p,&q);

printf("\n enter the matrix elements"); for(i=0;i<m;i++); { for(j=0;j<n;j++); { scanf("%d",&a[i][j]); } }

printf("\n a matrix is\n"); for(i=0;i<m;i++) { for(j=0;j<n;j++) { printf("%d\t",a[i][j]); } printf("\n"); } for(i=0;i<p;i++) { for(j=0;j<q;j++) { scanf("%d\t",&b[i][j]); } } printf("\n b matrix is\n");

for(i=0;i<p;i++) { for(j=0;j<q;j++) { printf("%d\t",b[i][j]); } printf("\n"); }

for(i=0;i<m;i++) { for(j=0;j<q;j++) { c[i][j]=0; for(k=0;k<n;k++) { c[i][j]=c[i][j]+a[i][k]*b[k][j]; } } }

for(i=0;i<m;i++) { for(j=0;j<q;j++) { printf("%d\t",c[i][j]);

} printf("\n"); }

getch(); }

Output:

Enter Matrix1: 1 11

1 11 1 1 1

Enter Matrix2: 1 11

1 11 1 1 1

Actual Output : 3 33 3 33 3 3 3

Test cases:

Test case no: 1 Test case name: Equal no.of rows & cols

Input Expectedoutput Actualoutput Remarks

Matrix1 rows & cols= 33 Matrix2 rows & cols= 33

Matrix1: 1 1 1 11 1 3 3 3 33 3 11 1 3 3 3 33 3 Success

3 3 3 33 3 Matrix2: 1 11

1 11 1 11

Test case no:2 Test case name: Cols of 1stmatrix not equal to rows of 2ndmatrix

Input Expected output Actual output Remarks


Operation Can‘t be Performed

fail

Test case no: 3

Test case name: Out of range values testing


1234567891 2222222222 2234567891 2222222221

234567891 22222221533 213242424 56456475457

Experiment 3 Take any system (e.g. ATM system) and study its system specifications and report the variousbugs.

Program:

Features to be tested:

1. Validity of thecard. 2. Withdraw Transaction flow ofATM. 3. Authentication of theuser’s. 4. Dispense the cash from theaccount. 5. Verify the balanceenquiry. 6. Change of PINnumber.

Bugs Identified:

Bug-Id BugName ATM_001 Invalid Card

ATM_002 Invalid PIN

ATM_003 Invalid Account type

ATM_004 Insufficient Balance

ATM_005 Transaction Limit

ATM_006 Day limit

ATM_007 Invalid money denominations

ATM_008 Receipt not printed

ATM_009 PIN change mismatch

Bug Report:

Bug Id:ATM_001 Bug Description: Invalid card Steps to reproduce: 1. Keep valid card in the ATM. Expected Result: Welcome Screen Actual Result: Invalid card Status : Pass/Fail

Bug Id: ATM_002 Bug Description: Invalid PIN entered Steps to reproduce: 1. Keep a valid card inATM. 2. Enter the authorizedPIN. 3. Menu screen should bedisplayed.

Expected Result: Menu screen displayed Actual Result: Invalid PIN screen is displayed Status : Pass/Fail

Bug Id: ATM_003 Bug Description: Invalid Account type selected. Steps to reproduce: 1. Enter a valid user PINnumber. 2. Select the withdraw option on the mainmenu. 3. Choose the correct type of account (either savings or currentaccount). Expected Result: Enter the Amount screen displayed Actual Result: Invalid Account type screen is displayed. Status : Pass/Fail

Bug Id: ATM_004 Bug Description: Insufficient Balance Steps to reproduce: 1. Menu screen should bedisplayed. 2. Select the withdrawoption. 3. Select the correct type ofaccount. 4. Enter the sufficient amount to withdraw from theaccount. 5. Dispense the cash screen & amount to be deducted fromaccount Expected Result: Collect the amount screen displayed Actual Result: Insufficient balance in the account Status : Pass/Fail

Bug Id: ATM_005 Bug Description: Withdraw Limit per transaction. Steps to reproduce: 1. Menu screen should bedisplayed. 2. Select the withdrawoption. 3. Select the correct type ofaccount. 4. Enter sufficient amount to withdraw from the account Transaction within thelimit. 5. Dispense the cash screen & amount to be deducted fromaccount. Expected Result: Cash is dispensed and collect the receipt Actual Result: Transaction limit exceeded screen is displayed Status : Pass/Fail

Bug Id: ATM_006 Bug Description: Withdraw limit per day Steps to reproduce: 1. Keep a valid card inATM. 2. Enter the authorizedPIN. 3. Enter the amount to withdraw from theaccount. 4. Amount enter is over the day limit(>40000) 5. Amount enter is over the day limit and display screen isdisplayed. Expected Result: Cash is dispensed and collect the receipt. Actual Result: Day limit exceeded screen is displayed. Status : Pass/Fail

Bug Id: ATM_007

Bug Description: Amount enter denominations Steps to reproduce: 1. Keep a valid card inATM. 2. Enter the authorizedPIN. 3. Enter the amount which should be in multiples of100. 4. Cash Dispenser screen is displayed. Expected Result: Collect the amount screen is displayed. Actual Result: Amount enter not in required denominations. Status : Pass/Fail

Bug Id: ATM_008 Bug Description: Statement not printed Steps to reproduce: 1. Keep a valid card inATM. 2. Enter the authorizedPIN. 3. Select the ministatement. 4. Current balance is displayed on thescreen. 5. Collect printed receipt of the statement. Expected Result: Collect the mini statement receipt Actual Result: receipt notprinted. Status : Pass/Fail

Bug Id: ATM_009 Bug Description: PIN mismatch Steps to reproduce: 1. Keep a valid card inATM. 2. Enter the authorizedPIN. 3. Select the change PIN option on themenu. 4. Enter the currentPIN. 5. Enter the newPIN. 6. Retype the newPIN 7. PIN successfully changed displayed on thescreen. Expected Result: PIN change successful. Actual Result: PIN mismatched due to wrong PIN entered Status : Pass/Fail

Experiment 3 Write the test cases for any known application (e.g. Banking application)

APPLICATION NAME

TEST CASE ID

TEST SCENARIO

TEST CASE

EXPECTED RESULT

ACTUAL RESULT

STATU S

TEST DATA

S B I ONL I NE B A N K I N G A P P L I C A T I O N

1 Validate the login page enter invalid/ wrong user name and valid password

Enter invalid user name and valid password in SBI online Banking login page

System should not allow the customer to login the SBI online Banking login page and it should display the message like ”please enter valid user name and password”

Customer is not able to login SBI online banking account

Pass Ex: UID:a bcdef PWD:x yz123

2 validate the login page enter invalid user name and invalid password

Enter invalid user name and invalid pass word in SBI online Banking login page

System should not allow the customer to login the SBI online Banking login page and it should display the message like “ please enter valid user name and password

Customer is not able to login SBI online Banking account

Pass Ex: UID:a bcd PWD:x yz12

3 Validate the login page enter valid user name and invalid password

Enter valid user name and invalid password in SBI online Banking login page

System should allow the user to login the SBI online Banking login page

Customer is logged in to SBI online Banking login page

Pass Ex: UID:a bcdefg PWD:x yz123 4

4 Validate the login page enter valid user name and valid password

Enter valid user name and valid password in SBI online Banking login page

System should allow the user to login the SBI online Banking login page

Customer is logged into SBI online Banking login page

Pass Ex: UID:a bcdefg PWD:x yz 123

5 Validate the user information or detail in the profile page

a) User should able to login SBI login page Usershould able to click on profile link

c) On clicking profile link uses should able to see all user detailslike 1) User

/custome r name

2) User/customer address details

b) User/customer phone number

a) User/customer should able to

login SBI login page with valid

b) Customer should be able to click profile link.

c) Customer should see all the custome r informat ion once he clicking on profile

hyper link

Customer is not able to see phone or mobile number

fail

Experiment 5 Create a test plan document for any application (e.g. Library Management System)

VERSION HISTORY [Provide information on how the development and distribution of the Test Plan, up to the final point of approval, was controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.]

Versio n #

Implemented By

Revision Date

Approved

By

Approval Date

Reason

1.0 <Author name>

<mm/dd/yy >

<name> <mm/dd/yy >

Test Plan draft

1 INTRODUCTION

PURPOSE OF THE TEST PLANDOCUMENT [Provide the purpose of the Test Plan Document. This document should be tailored to fit a particular project’s needs.] The Test Plan document documents and tracks the necessary information required to effectively define the approach to be used in the testing of the project’s product. The Test Plan document is created during the Planning Phase of the project. Its intended audience is the project manager, project team, and testing team. Some portions of this document may on occasion be shared with the client/user and other stakeholder whose input/approval into the testing process is needed.

2 COMPATIBILITYTESTING

TEST RISKS / ISSUES [Describe the risks associated with product testing or provide a reference to a document location where it is stored. Also outline appropriate mitigation strategies and contingency plans.]

ITEMS TO BE TESTED / NOTTESTED [Describe the items/features/functions to be tested that are within the scope of this test plan. Include a description of how they will be tested, when, by whom, and to what quality standards. Also include a description of those items agreed not to betested.]

Item to Test Test Description Test Date Responsibility

TESTAPPROACH(S) [Describe the overall testing approach to be used to test the project’s product. Provide an outline of any planned tests.]

TEST REGULATORY / MANDATECRITERIA [Describe any regulations or mandates that the system must be tested against.]

TEST PASS / FAIL CRITERIA [Describe the criteria used to determine if a test item has passed or failed its test.]

TEST ENTRY / EXITCRITERIA [Describe the entry and exit criteria used to start testing and determine when to stop testing.]

TESTDELIVERABLES [Describe the deliverables that will result from the testing process (documents, reports, charts, etc.).]

TEST SUSPENSION / RESUMPTIONCRITERIA [Describe the suspension criteria that may be used to suspend all or portions of testing. Also describe the resumption criteria that may be used to resume testing.]

TEST ENVIRONMENTAL / STAFFING / TRAININGNEEDS [Describe any specific requirements needed for the testing to be performed (hardware/software, staffing, skills training, etc).)]

3 CONFORMANCETESTING


ITEMS TO BE TESTED / NOTTESTED

[Describe the items/features/functions to be tested that are within the scope of this test plan. Include a description of how they will be tested, when, by whom, and to what quality standards. Also include a description of those items agreed not to betested.]









4 FUNCTIONALTESTING











5 PERFORMANCETESTING











6 REGRESSIONTESTING

TEST RISKS /ISSUES [Describe the risks associated with product testing or provide a reference to a document location where it is stored. Also outline appropriate mitigation strategies and contingency plans.]









TEST ENVIRONMENTAL / STAFFING / TRAININGNEEDS [Describe any specific requirements needed for the testing to be performed

(hardware/software, staffing, skills training, etc).)]

7 SYSTEMTESTING











8 UNITTESTING

TEST RISKS / ISSUES [Describe the risks associated with product testing or provide a reference to a document

location where it is stored. Also outline appropriate mitigation strategies and contingency plans.]










9 USER ACCEPTANCETESTING


ITEMS TO BE TESTED / NOTTESTED [Describe the items/features/functions to be tested that are within the scope of this test plan. Include a description of how they will be tested, when, by whom, and to what quality

standards. Also include a description of those items agreed not to betested.]








TEST ENVIRONMENTAL / STAFFING / TRAININGNEEDS [Describe any specific requirements needed for the testing to be performed (hardware/software, staffing, skills training,etc).)]

TEST PLAN APPROVAL The undersigned acknowledge they have reviewed the <Project Name>Test Plan document and agree with the approach it presents. Any changes to this Requirements Definition will be coordinated with and approved by the undersigned or their designated representatives.

[List the individuals whose signatures are required. Examples of such individuals are Business Steward, Technical Steward, and Project Manager. Add additional signature lines asnecessary.]

Signature: Date: Print Name: Title Role

Signature: Date:

Print Name: Title Role

Signature: Date:

Print Name: Title Role

Appendix A: References

[Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.] The following table summarizes the documents referenced in this document.

Document Name and Version

Description Location

<Document Name and VersionNumber>

[Provide description of the document]

<URL or Network path where document is located>

Experiment 6 Test any one web application using Selenium testing tool.

Selenium is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior. One of Selenium‘s key features is the support for executing one‘s tests on multiple browser platforms. Selenium Components Selenium is composed of three major tools. Each one has a specific role in aiding the development of web application test automation. Selenium-RC provides an API (Application Programming Interface) and library for each of its supported languages: HTML, Java, C#, Perl, PHP, Python, and Ruby. This ability to use Selenium-RC with a high-level programming language to develop test cases also allows the automated testing to be integrated with a project‘s automated build environment. Selenium-Grid Selenium-Grid allows the Selenium-RC solution to scale for large test suites or test suites that must be run in multiple environments. With Selenium-Grid, multiple instances of Selenium-RC are running on various operating system and browser configurations;Eachof these when launching register with a hub. When tests are sent to the hub they are then redirected to an available Selenium-RC, which will launch the browser and run the test. This allows for running tests in parallel, with the entire test suite theoretically taking only as long to run as the longest individual test. * Tests developed on Firefox via Selenium-IDE can be executed on any other supported browser via a simple Selenium-RC command line. ** Selenium-RC server can start any executable, but depending on browser security settings there may be technical limitations that would limit certain features. Flexibility and Extensibility Selenium is highly flexible. There are multiple ways in which one can add functionality to Selenium‘s framework to customize test automation for one‘s specific testing needs. This is, perhaps, Selenium‘s strongest characteristic when compared with proprietary test automation tools and other open source solutions. Selenium-RC support for multiple programming and scripting languages allows the test writer to build any logic they need into their automated testing and to use a preferred programming or scripting language of one‘schoice. Selenium-IDE allows for the addition of user-defined ―user-extensions‖ for creating additional commands customized to the user‘s needs. Also, it is possible to re-configure how the Selenium-IDE generates its Selenium-RC code. This allows users to customize the generated code to fit in with their own test frameworks. Finally, Selenium is an Open Source project where code can be modified and enhancements can be submitted for contribution. Test Suites A test suite is a collection of tests. Often one will run all the tests in a test suite as one continuous batch-job. When using Selenium-IDE, test suites also can be defined using a simple HTML file. The syntax again is simple. An HTML table defines a list of tests where each row defines the filesystem path to each test. An example tells itall.

<html> <head> <title>Test Suite Function Tests – Priority 1</title> </head><body> <table> <tr><td><b>Suite Of Tests</b></td></tr> <tr><td><a href=‖ ./Login.html‖>Login</a></td></tr> <tr><td><a href=‖ ./SearchValues.html‖>Test Searching for Values</a></td></tr><tr><td><a href=‖./SaveValues.html‖>TestSave</a></td></tr> </table> </body></html> A file similar to this would allow running the tests all at once, one after another, from the Selenium-IDE.

Test suites can also be maintained when using Selenium-RC. This is done via programming and can be done a number of ways. Commonly Junit is used to maintain a test suite if one is using Selenium-RC with Java. Additionally, if C# is the chosen language, Nunit could be employed. If using an interpreted language like Python with Selenium-RC than some simple programming would be involved in setting up a test suite.SincethewholereasonforusingSel-RCistomakeuseofprogramminglogicforyour testing this usually isn‘t a problem. Few typical Selenium commands.

open – opens a page using a URL. click/clickAndWait – performs a click operation, and optionally waits for a new page to load. verifyTitle/assertTitle – verifies an expected page title. verifyTextPresent – verifies expected text is somewhere on the page. verifyElementPresent – verifies an expected UI element, as defined by its HTML tag, is present on the page. verifyText – verifies expected text and it‘s corresponding HTML tag are present on the page. verifyTable – verifies a table‘s expected contents. waitForPageToLoad – pauses execution until an expected new page loads. Called automatically when clickAndWait is used. waitForElementPresent – pauses execution until an expected UI element, as defined by its HTML tag, is present on the page.

Experiment 7 Study of Any Bug Tracking Tool (Bugzilla)

Bugzilla is a ―Bug Tracking System‖ that can efficiently keep track of outstandingbugs in

a product. Multiple users can access this database and query, add and manage these bugs. Bugzilla essentially comes to the rescue of a group of people working together on a product as it enables them to view current bugs and make contributions to resolve issues. Its basic repository nature works out better than the mailing list concept and an organized database is always easier to workwith.

Advantage of Using Bugzilla:

1. Bugzilla is very adaptable to various situations. Known uses currently include IT support queues, Systems Administration deployment management, chip design and development problem tracking (both pre-and-post fabrication), and software and hardware bug tracking for luminaries such as Redhat, NASA, Linux-Mandrake, and VA Systems. Combined with systems such as CVS, Bugzilla provides a powerful, easy-to-use solution to configuration management and replicationproblems.

2. Bugzilla can dramatically increase the productivity and accountability of individual employees by providing a documented workflow and positive feedback for good performance. Ultimately, Bugzilla puts the power in user‘s hands to improve value to business while providing a usable framework for natural attention to detail and knowledge store toflourish.

The bugzilla utility basically allows to do the following: Add a bug into the database Review existing bug reports Manage the content

Bugzilla is organised in the form of bug reports that give all the information needed about a

particular bug. A bug report would consist of the following fields. Product–>Component Assigned to Status (New, Assigned, Fixed etc) Summary Bugpriority Bug severity (blocker, trivialetc) Bugreporter

Using Bugzilla:

Bugzilla usage involves the following activities Setting Parameters and Default Preferences

• Creating a NewUser • Impersonating aUser • AddingProducts • Adding Product

Components Modifying Default FieldValues Creating a NewBug Viewing Bug Reports

Setting Parameters and Default Preferences:

When we start using Bugzilla, we‘ll need to set a small number of parameters

and preferences. At a minimum, we should change the following items, to suit our

particular need: ▪ Set themaintainer ▪ Set themail_delivery_method ▪ Set bug changepolicies ▪ Set the display order of bugreports To set parameters and default preferences:

1. Click Parameters at the bottom of thepage. 2. Under Required Settings, add an email address in the maintainerfield. 3. Click SaveChanges. 4. In the left side Index list, clickEmail. 5. Select from the list of mail transports to match the transport we‘re using. If evaluating a

click2try application, select Test. If using SMTP, set any of the other SMTP options for your environment. Click SaveChanges.

6. In the left side Index list, click Bug ChangePolicies. 7. Select On for commentoncreate, which will force anyone who enters a new bug to enter a

comment, to describe the bug. Click SaveChanges. 8. Click Default Preferences at the bottom of thepage. 9. Select the display order from the drop-down list next to the When viewing a bug, show

comments in this order field. Click SubmitChanges. Creating a New User

Before entering bugs, make sure we add some new users. We can enter users very easily, with a minimum of information. Bugzilla uses the email address as the user ID, because users are frequently notified when a bug is entered, either because they entered the bug, because the bug is assigned to them, or because they‘ve chosen to track bugs in a certain project.

To create a new user:

1. ClickUsers. 2. Click add a newuser. 3. Enter the Login name, in the form of an emailaddress. 4. Enter the Real name, a password, and then clickAdd. 5. Select the Group access options. we‘ll probably want to enable the following

options in the row titled User is a member of thesegroups: canconfirmed itbugseditcomponents

6. Click Update when done with settingoptions. Impersonating a User

Impersonating a user is possible, though rare, that we may need to file or manage a bug in an area that is the responsibility of another user when that user is not available. Perhaps the user is on vacation, or is temporarily assigned to another project. We can impersonate the user to create or manage bugs that belong to that user.

Adding Products

We‘ll add a product in Bugzilla for every product we are developing. To start with, when we first login to Bugzilla, we‘ll find a test product called TestProduct. We should delete this and create a newproduct.

To add a product:

1. At the bottom of the page, clickProducts.

2. In the TestProductlisting, clickDelete. 3. Click Yes,Delete. 4. Now click Add aproduct. 5. Enter a product name, such as ―Widget Design Kit.‖ 6. Enter adescription. 7. Click Add. A message appears that you‘ll need to add at least onecomponent.

Adding Product Components

Products are comprised of components. Software products, in particular, are typically made up of many functional components, which in turn are made up of program elements, like classes and functions. It‘s not unusual in a software development team environment for differentindividuals to be responsible for the bugs that are reported against a given component. Even if there are other programmers working on that component, it‘s not uncommon for one person, either a project lead or manager, to be the gatekeeper for bugs. Often, they will review the bugs as they are reported, in order to redirect them to the appropriate developer or even another team, to review the priority and severity supplied by the reporter, and sometimes to reject bugs as duplicates or enhancement requests, for example.

To add a component:

1. Click the link add at least one component in the message that appears after creating a newproduct.

2. Enter the Componentname. 3. Enter aDescription. 4. Enter a default assignee. Use one of the users we‘ve created. Remember to enter the

assignee in the form of an emailaddress. 5. ClickAdd. 6. To add more components, click the name of product in the message that reads edit other

components of product <productname>.

Modifying Default Field Values Once we begin to enter new bugs, we‘ll see a number of drop-down lists containing

default values. Some of these may work just fine for our product. Others may not. We can modify the values of these fields, adding new values and deleting old ones. Let‘s take a look at the OS category.

To modify default field values:

1. At the bottom of the page, in the Edit section, click FieldValues. 2. Click the link, in this case OS, for the field we want to edit. The OS field contains a list of

operating system names. We are going to add browsers to this list. In reality, we might create a custom field instead, but for the sake of this example, just add them to the OS list.

3. Click Add a value. In the Value field, enter ―IE7.‖ ClickAdd. 4. Click Add a valueagain. 5. In the Value field, enter ―Firefox3.‖ 6. ClickAdd. 7. Where it reads Add other values for the op_sys field, clickop_sys. 8. This redisplays the table. We should now see the two new entries at the top of

the table. These values will also appear in the OS drop-down list when we create a newbug.

Creating a New Bug

Creating bugs is a big part of what Bugzilla does best.

To create a new bug: 1. In the top menu, click New. 2. If we‘ve defined more than one component, choose the component from the component list. 3. Select a Severity and a Priority. Severity is self-explanatory, but Priority is generally

assumed to be the lower the number, the higher the priority. So, a P1 is the highest priority bug, ashowstopper.

4. Click the OS drop-down list to see the options, including the new browser names we entered.

5. Select one of theoptions. 6. Enter a summary and a description. We can add any other information of choice, but it is

not required by the system, although we may determine that our bug reporting policy requires certaininformation.

7. Click Commit. Bugzilla adds our bug report to the database and displays the detail page for thatbug.

Viewing Bug Reports

Eventually, we‘ll end up with thousands of bugs listed in the system. There are several ways to view the bugs. The easiest is to click the My Bugs link at the bottom of the page. Because we‘ve only got one bug reported, we‘ll use the standard Search function.

To find a bug:

1. ClickReports. 2. Click the Search link on the page, not the one in the top menu. This opens a pagetitled ―Find a Specific Bug.‖

3. Select theStatus. 4. Select the Product. 5. Enter a word that might be in the title of thebug. 6. Click Search. If any bugs meet the criteria that we have entered, Bugzilla displays them in

a listsummary. 7. Click the ID number link to view the full bugreport.

Modifying Bug Reports

Suppose we want to change the status of the bug. We‘ve reviewed it and have determined that it belongs to one of the users we have created earlier

To modify a bug report:

1. ScrolldownthefullbugdescriptionandenteracommentintheAdditionalComments field.

2. Select ―Reassign bug to‖ and replace the default user ID with one of the other user IDs you created. It must be in the format of an emailaddress

Experiment 8

Test any Java application using JMeter.

JMeter Performance Apache JMeter is an open source application tool designed to load test functional behavior and measure performance on static pages, dynamic resources, and web applications. It can be used to simulate a heavy load on a server or group of servers, database, or network to test its strength, or to analyze overall performance under different load types.

In this post, I'll provide an introduction to JMeter with the goal to get you up and running (and testing!), more quickly and easily. Much of what is below is taken directly from the JMeter documentation with additional caveats.

Getting Started, Requirements, Installation JMeter can be used for test plan building, load test running, and load test analysis. It has a GUI mode that allows you to create test plans manually, choose from a variety of templates, or record the application from a browser session. GUI mode also allows for debugging and viewing results.

Once your test plan is ready, you can use the non-GUI mode to run a load test from the command line. You can generate a CSV or XML file containing results and have JMeter generate an HTML report from that data.

JMeter is a 100% Java application and should run correctly on any system that has Java installed correctly. It does require Java version 8. For JDBC testing, you will need to add your database vendor's JDBC driver to the classpath, or include the jar file in the jmeterlib folder. Make sure the file is a jar file, not a zip. To install Java, get the latest version 8 of the JRE or JDK from Oracle's Java download site.

For Windows, download the exe file and run it. On CentOS 7.x, download the latest rpm and run yum localinstall jdk-8u152-linux-x64.rpm. On Ubuntu 16.x, run sudo apt-get install oracle-java8-installer.

Java will be installed in the lib or lib64 directory. To verify that it is installed you can run java -version to see what version is being used.

To install JMeter, it is recommended to download the latest release. Unzip the zip/tar file into the directory where you want JMeter to be installed. If you have a JRE/JDK correctly installed and the JAVA_HOME environment variable set, there is nothing more to do.

Here is the basic directory structure. Along with I have added the tests, results, and reports directories to help with organization:

The bin directory will be where you run JMeter from. The lib directory is where you can add additional jar files, for example, JDBC drivers for database testing.

Store your test scripts (JMX files) in the tests directory. Direct output results to the results directory. CSV is recommended, but JTL files are also an option. HTML Dashboard Reports can be generated to the reports directory.

Building a Test Plan Overview

A test plan describes the steps that JMeter will execute when run. It will consist of one or more Thread Groups, logic controllers, sample generating controllers, listeners, timers, assertions, and configuration elements.

Adding elements to a test plan can be done by right-clicking on an element in the tree and choosing a new element from the add list. Changes to the Test Plan are automatically saved when you move between tree elements, but you should save to a file before running it. To save the Test Plan, select "Save" or "Save Test Plan As ..." from the File menu.

The workbench is not automatically saved with the test plan, but it can be saved by checking "Save Workbench" option on Workbench element.

To run your test plan, choose Start from the Run menu. Stop stops the threads immediately if possible. Many samplers can be terminated early. Shutdown requests the threads to stop at the end of any current work. Will not interrupt any active samples.

Elements of a Test Plan The Test Plan object is the top element of the tree.

Configuration Elements

• HTTP Request Defaults - set defaults that are used for all HTTP requests. For example, server name or IP, port number, etc.

• HTTP Cookie Manager - will manage cookies during the tests • User Defined Variables - used to store data that you don't want to hardcode in the test. For example,

username and password.

Thread Group Thread Group elements are the beginning points of any test plan. All controllers and samplers must be under a thread group. The thread group element controls the number of threads (users) JMeter will use to execute your test. The controls for a thread group allow you to:

• Set the number of threads (users) • Set the ramp-up period (in seconds) • Set the number of times to execute the test

Each thread will execute the test plan in its entirety and completely independently of other test threads.

Multiple threads are used to simulate concurrent connections to your server application.

The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.

Ramp-up needs to be long enough to avoid too large a workload at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen). Start with Ramp-up = number of threads and adjust up or down as needed.

Controllers JMeter has two types of Controllers: Samplers and Logical Controllers. These drive the processing of a test. Samplers tell JMeter to send requests to a server and wait for a response. They are processed in the order they appear in the tree. JMeter samplers included in our tests are:

Each sampler has several properties you can set. Logical Controllers let you customize the logic that JMeter uses to decide when to send requests. For example, you can add a Recording Controller to capture HTTP requests as you record them and use for your testing script.

Listeners Listeners provide access to the information JMeter gathers about the test cases while JMeter runs.

• The Graph Results listener plots the response times on a graph. • The View Results Tree Listener shows details of sampler requests and responses, and can display

basic HTML and XML representations of the response. • The Summary Report creates a table row for each differently named request in your test. • The Response Time Graph draws a line chart showing the evolution of response time during the test,

for each labeled request.

Additionally, listeners can direct the data to a file for later use. Every listener in JMeter provides a field to indicate the file to store data to. There is also a Configuration button which can be used to choose which fields to save, and whether to use CSV or XML format.

Timers By default, a JMeter thread executes samplers in sequence without pausing. We recommend that you specify a delay by adding one of the available Timers to your Thread Group.

Post-Processors A Post-Processor executes some action after a Sampler Request has been made. If a Post-Processor is attached to a Sampler element, then it will execute just after that sampler element runs. We will user a Regular Expression Extractor to get the CSRF Token needed to maintain the login.

Building a Web Test Plan Official Documentation - Building a Web Test Plan

Add a Thread Group (Users) by: Add > Thread Group. Key fields are Number of Threads (users), Ramp-Up Period (seconds), and Loop Count.

Add a Thread Group (Users) by: Add > Thread Group. Key fields are Number of Threads (users), Ramp-Up Period (seconds), and Loop Count.

Add User Defined Variables by: Add > Config Element > User Defined Variables. This is a good place to put Username, Password, and any other variables that may need to reused throughout the test.

Add HTTP Request Defaults by: Add > Config Element > HTTP Request Defaults. The key field is Server Name (IP).

Add Cookie Support by: Add > Config Element > HTTP Cookie Manager.

Add a Timer by: Add > Timer > if you want a specific delay versus the default (that does not pause).

Add Tests Manually by: Add > Sampler > HTTP Request (See Recording a Test Script below to automate this). Leave Server Name blank to use from HTTP Request Defaults. Set Path to pages or to an API call, for example: /login, /stores, /terminals, etc. Set the Method: GET or POST.

Add Send Parameters as needed, including hidden required fields in some cases. Here is how to use the variables defined in User Defined Variables:

Add an Extractor by: Add > Post Processor > Regular Expression Extractor to get the CSRF (Cross Site Request Forgery) Token to be used with login. Select where the field is: Body, Headers, Response. Set a Reference Name that can be used later as a variable. Set the Regular Expression and Template.

Add various Graphs and Reports by: Add > Listener > Some good options are: Graph Results, View Results Tree, Summary Report, Response Time Graph.

Recording a Test Script To record and build your test script using a web browser, there are some additional steps to what is listed above. Add a recording controller: Add > Logic Controller > Recording Controller and give it a name.

Select "Workbench." Right-click on WorkBench and add the recorder: Add > Non-Test Elements > HTTP(S) Test Script Recorder. Set the Global port to the port number you will record on, for example 8888. Set the Target Controller to the recorder added above.

-On HTTP(S) Test Script Recorder, click the "Add" button in "URL Patterns to Include". This will create a blank entry; enter .*.html, or whatever you want to include. Same with exclude if you want to ignore images, CSS, etc. or you can Add suggested Excludes. When you are ready, click the "Start" button at the bottom.

Next, you will configure your Firefox Browser to use the JMeter proxy, in this case, 8888. See the "Configure your browser to use the JMeter Proxy" section in the pdf for detailed instructions.

Record your navigation, which saves everything to the Recording Controller. Now you can review the saved requests, add any extractors for variables, and modify as needed.

When done, you will need to set your Browser proxy back to "Use system proxy settings," or whatever it was before.

Recorders and changes to the Workbench do not get saved with the Test Plan. You may want to save a separate workbench JMX file that can be merged with your test plan when needed by: right-clicking the "Script Recorder" and select "Save Selection As..."

How to Run JMeter in GUI Mode on Windows Official Documentation - Running JMeter

To run JMeter for initial setup, testing your plan, and debugging, run the jmeter.bat (for Windows) or jmeter (for Unix) file. These files are found in the bin directory. Here are the options:

GUI Mode (for generating tests, debugging, and simple load testing)

• jmeter.bat - run JMeter (in GUI mode by default) • jmeterw.cmd - run JMeter without the windows shell console (in GUI mode by default) • jmeter-t.cmd - drop a JMX file on this to load it in GUI mode

Non-GUI mode (for Load Testing)

• jmeter -n.cmd - drop a JMX file on this to run a non-GUI test • jmeter -n -r.cmd - drop a JMX file on this to run a non-GUI test remotely • jmeter-server.bat - start JMeter in server mode • mirror-server.cmd - runs the JMeter Mirror Server in non-GUI mode

• shutdown.cmd - Run the Shutdown client to stop a non-GUI instance gracefully • stoptest.cmd - Run the Shutdown client to stop a non-GUI instance abruptly

Examples:

jmeter -n -t -l jmeter -n -t ..testsgrokola-com-basic.jmx -l ..resultsgrokola-com-basic-results.csv jmeter -n -t ..testsgrokola-com-basic.jmx -l ..resultsgrokola-com-basic-results-20171201.csv You can also add a date to the filename on the command line. To do this, add: %date:~-4,4%%date:~-7,2%%date:~-10,2%.

This will add the date in YYYYMMDD format. For example: grokola-com-basic-results-%date:~-4,4%%date:~-7,2%%date:~-10,2%.csv would turn into grokola-com-basic-results-20171201.csv. This may vary depending on the OS that you are using.

How to Run JMeter in Non-GUI Mode on Linux A JRE or JDK is required to run JMeter. You can check to see what version of Java is installed by running java -version on the command line.

cd </path/to/dir>/apache-jmeter/bin/ ./jmeter -n -t ../tests/grokola-com-basic.jmx -l ../results/grokola-com-basic-results.csv

Command Line Options Official Documentation - Non-GUI Mode

• -n This specifies JMeter is to run in non-GUI mode. • -t [name of JMX file that contains the Test Plan]. • -l [name of CSV or JTL file to log sample results to] (CSV is preferred). • -j [name of JMeter run log file]. • -r Run the test in the servers specified by the JMeter property "remote_hosts." • -R [list of remote servers] Run the test in the specified remote servers. • -g [path to CSV file] generate report dashboard only. • -e generate report dashboard after load test. • -o output folder where to generate the report dashboard after a load test. The folder must not exist or

be empty.

JMX File Variables A JMX file is an XML file where the test is stored. Here are some important variables within a JMX that can be changed to vary tests:

• < stringProp name="ThreadGroup.num_threads">5< /stringProp > - Number of Users simulated in the test.

• < stringProp name="ThreadGroup.ramp_time">60< /stringProp>- Number of seconds to start all the users. For example, if you 60 users and the ramp time is 60 seconds, it will add 1 user per minute to the test.

• < stringProp name="LoopController.loops">10 stringProp> - Number of iterations each user will run in the test

The section below contains User Defined Variables that can be changed as needed:

<Arguments guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables - beta.grokola.com" enabled="true"> <collectionProp name="Arguments.arguments"> <elementProp name="USERNAME" elementType="Argument"> <stringProp name="Argument.name">USERNAME</stringProp> <stringProp name="Argument.value">[email protected]</stringProp> <stringProp name="Argument.metadata">=</stringProp>

</elementProp> <elementProp name="PASSWORD" elementType="Argument"> <stringProp name="Argument.name">PASSWORD</stringProp> <stringProp name="Argument.value">mYp@$w0rd12#</stringProp> <stringProp name="Argument.metadata">=</stringProp> </elementProp> </collectionProp> </Arguments> < stringProp name="ConstantTimer.delay">5000 stringProp> - Number milliseconds between each user request (5000 would be 5 seconds).

Generating an HTML Reporting Dashboard JMeter supports dashboard report generation to get graphs and statistics from a test plan. Go to http://jmeter.apache.org/usermanual/generating-dashboard.html for a detailed overview and configuration settings.

NOTE: the folder that you create the dashboard report in must be empty. You will need to delete the contents of this folder.

To create an HTML dashboard report from an existing CSV output file, run the following on command line:

jmeter -g <path to log results(csv)> -o <Path to output folder> jmeter -g ..\results\grokola-com-basic-results.csv -o ..\reports\grokola-com-basic-20171201 To create a dashboard report at the end of a load test, add the -e and -o options on the command line:

jmeter -n -t <path to testplan(jmx)> -l <path to log results(csv)> -e -o <Path to output folder> jmeter -n -t ..\tests\grokola-com-basic.jmx -o ..\reports\grokola-com-basic-20171201

Final Thoughts I hope that you have found this JMeter introduction helpful! Please let me know if you have any questions.

Experiment 9 Creating a test report using BugZilla.

Bugzilla is a ―Bug Tracking Systemǁthat can efficiently keep track of outstandingbugs in a product. Multiple users can access this database and query, add and manage these bugs. Bugzilla essentially comes to the rescue of a group of people working together on a product as it enables them to view current bugs and make contributions to resolve issues. Its basic repository nature works out better than the mailing list concept and an organized database is always easier to workwith.

Advantage of Using Bugzilla:

3. Bugzilla is very adaptable to various situations. Known uses currently include IT support queues, Systems Administration deployment management, chip design and development problem tracking (both pre-and-post fabrication), and software and hardware bug tracking for luminaries such as Redhat, NASA, Linux-Mandrake, and VA Systems. Combined with systems such as CVS, Bugzilla provides a powerful, easy-to-use solution to configuration management and replicationproblems.

4. Bugzilla can dramatically increase the productivity and accountability of individual employees by providing a documented workflow and positive feedback for good performance. Ultimately, Bugzilla puts the power in user‘s hands to improve value to business while providing a usable framework for natural attention to detail and knowledge store toflourish.

The bugzilla utility basically allows to do the following: Add a bug into the database Review existing bug reports Manage the content

Bugzilla is organised in the form of bug reports that give all the information

needed about a particular bug. A bug report would consist of the following fields. Product–>Component Assigned toStatus (New, Assigned, Fixed etc) Summary Bugpriority Bug severity (blocker, trivialetc) Bugreporter

Using Bugzilla: Bugzilla usage involves the following activities Setting Parameters and Default Preferences

• Creating a NewUser • Impersonating aUser • AddingProducts • Adding Product Components Modifying Default FieldValues Creating a NewBug

Viewing Bug Reports

Setting Parameters and Default Preferences: When we start using Bugzilla, we‘ll need to set a small number of parameters and preferences.

At a minimum, we should change the following items, to suit our particular need: ▪ Set themaintainer ▪ Set themail_delivery_method ▪ Set bug changepolicies ▪ Set the display order of bugreports To set parameters and default preferences:

10. Click Parameters at the bottom of thepage. 11. Under Required Settings, add an email address in the maintainerfield. 12. Click SaveChanges. 13. In the left side Index list, clickEmail.

14. Select from the list of mail transports to match the transport we‘re using. If evaluating a click2try application, select Test. If using SMTP, set any of the other SMTP options for your environment. Click SaveChanges.

15. In the left side Index list, click Bug ChangePolicies. 16. Select On for commentoncreate, which will force anyone who enters a new bug to enter a

comment, to describe the bug. Click SaveChanges. 17. Click Default Preferences at the bottom of thepage. 18. Select the display order from the drop-down list next to the When viewing a bug, show

comments in this order field. Click SubmitChanges. Creating a New User

Before entering bugs, make sure we add some new users. We can enter users very easily, with a minimum of information. Bugzilla uses the email address as the user ID, because users are frequently notified when a bug is entered, either because they entered the bug, because the bug is assigned to them, or because they‘ve chosen to track bugs in a certain project.

To create a new user:

7. ClickUsers. 8. Click add a newuser. 9. Enter the Login name, in the form of an emailaddress. 10. Enter the Real name, a password, and then clickAdd. 11. Select the Group access options. we‘ll probably want to enable the following

options in the row titled User is a member of thesegroups: canconfirmeditbugseditcomponents

12. Click Update when done with settingoptions. Impersonating a User

Impersonating a user is possible, though rare, that we may need to file or manage a bug in an area that is the responsibility of another user when that user is not available. Perhaps the user is on vacation, or is temporarily assigned to another project. We can impersonate the user to create or manage bugs that belong to that user.

Adding Products

We‘ll add a product in Bugzilla for every product we are developing. To start with, when we first login to Bugzilla, we‘ll find a test product called TestProduct. We should delete this and create a newproduct.

To add a product:

8. At the bottom of the page, clickProducts. 9. In the TestProductlisting, clickDelete. 10. Click Yes,Delete. 11. Now click Add aproduct. 12. Enter a product name, such as ―Widget Design Kit.ǁ 13. Enter adescription.

14. Click Add. A message appears that you‘ll need to add at least onecomponent.

Adding Product Components

Products are comprised of components. Software products, in particular, are typically made up of many functional components, which in turn are made up of program elements, like classes and functions. It‘s not unusual in a software development team environment for different

individuals to be responsible for the bugs that are reported against a given component. Even if there are other programmers working on that component, it‘s not uncommon for one person, either a project lead or manager, to be the gatekeeper for bugs. Often, they will review the bugs as they are reported, in order to redirect them to the appropriate developer or even another team, to review the priority and severity supplied by the reporter, and sometimes to reject bugs as duplicates or enhancement requests, for example.

To add a component:

7. Click the link add at least one component in the message that appears after creating a newproduct.

8. Enter the Componentname. 9. Enter aDescription. 10. Enter a default assignee. Use one of the users we‘ve created. Remember to

enter the assignee in the form of an emailaddress. 11. ClickAdd. 12. To add more components, click the name of product in the message that reads

edit other components of product <productname>.

Modifying Default Field Values

Once we begin to enter new bugs, we‘ll see a number of drop-down lists containing default values. Some of these may work just fine for our product. Others may not. We can modify the values of these fields, adding new values and deleting old ones. Let‘s take a look at the OS category.

To modify default field values:

9. At the bottom of the page, in the Edit section, click FieldValues. 10. Click the link, in this case OS, for the field we want to edit. The OS field contains a list of

operating system names. We are going to add browsers to this list. In reality, we might create a custom field instead, but for the sake of this example, just add them to the OS list.

11. Click Add a value. In the Value field, enter ―IE7.ǁClickAdd. 12. Click Add a valueagain. 13. In the Value field, enter ―Firefox3.ǁ 14. ClickAdd. 15. Where it reads Add other values for the op_sys field, clickop_sys. 16. This redisplays the table. We should now see the two new entries at the top of the table.

These values will also appear in the OS drop-down list when we create a newbug.

Creating a New Bug Creating bugs is a big part of what Bugzilla does best.

To create a new bug:

8. In the top menu, click New. 9. If we‘ve defined more than one component, choose the component from the component

list. 10. Select a Severity and a Priority. Severity is self-explanatory, but Priority is generally

assumed to be the lower the number, the higher the priority. So, a P1 is the highest priority bug, ashowstopper.

11. Click the OS drop-down list to see the options, including the new browser names we entered.

12. Select one of theoptions.

13. Enter a summary and a description. We can add any other information of choice, but it is not required by the system, although we may determine that our bug reporting policy requires certaininformation.

14. Click Commit. Bugzilla adds our bug report to the database and displays the detail page for thatbug.

Viewing Bug Reports

Eventually, we‘ll end up with thousands of bugs listed in the system. There are several ways to view the bugs. The easiest is to click the My Bugs link at the bottom of the page. Because we‘ve only got one bug reported, we‘ll use the standard Search function.

To find a bug:

8. ClickReports. 9. Click the Search link on the page, not the one in the top menu. This opens a pagetitled ―Find a Specific Bug.ǁ

10. Select theStatus. 11. Select the Product. 12. Enter a word that might be in the title of thebug. 13. Click Search. If any bugs meet the criteria that we have entered, Bugzilla displays them in

a listsummary. 14. Click the ID number link to view the full bugreport.

Modifying Bug Reports

Suppose we want to change the status of the bug. We‘ve reviewed it and have determined

that it belongs to one of the users we have created earlier

To modify a bug report:

3. ScrolldownthefullbugdescriptionandenteracommentintheAdditionalComments field.

4. Select ―Reassign bug toǁand replace the default user ID with one of the other user IDs you created. It must be in the format of an emailaddress

Experiment 10

Design and Develope test cases for Mobile application.

A test case is a set of test inputs, their implementation conditions and expected results that are developed keeping a particular outcome in focus. In simple words, a test case is a set of conditions under which a tester checks in a particular system to determine if it meets the specific test requirements and functions properly. Developing test cases is also helpful in determining the issues, requirements and design of a particular application being tested Test cases are categorized into two, which include formal and informal test cases. A formal test case includes a well-defined input and an expected output that are written before the execution of a test. The aim behind writing an input beforehand is to test a precondition and that of an output is to test a post condition. To test an application for all the requirements, there are at least one positive and one negative test case that are created for each requirement. In case any of these requirements has a sub-requirement, then each sub-requirement will also have at least two test cases.

Informal test cases are used when there are no formal requirements for a test. These are written on the basis of the accepted normal operation of the programs of a similar class. To conduct these tests, imaginary situations are used to enable a tester to think about different probabilities in a complex situation. However, these are not written in detail, these test cases can be as simple as a diagram or a description written in prose.

How to Write a typical Test Case? Generally, there are different types of test management tools that are used by the companies to determine the elements that are to be included in a test case. This, in turn, leads to an inclusion of a different set of elements in each test. But, there are certain elements that are common in almost every test case as mentioned below: • Test suite ID • Test case ID • Test case summary • Related requirement • Prerequisites of conducting the test • Procedure to conduct the test • Test data or links to the same • Expected result • Actual result • Status of the test • Comments, if any • Creator and date of creation of the test case • Name of the executor • Date of execution • Test environment Android Testing Android is the most popular mobile operating system in the world with its number of varied versions available in the market. Like any other software, it is important to test an Android application rigorously to avoid any sort of flaws in its functioning such as, installation failure, crash during execution, scaling issues, layout problems, hang issue and issue with its landscape/portrait mode. Levels of Writing Test Cases for Android Testing Writing test cases is important to ensure the optimum functioning of any application. The test cases that are written by a team are typically categorized as per different levels. This is done to ensure that there are no duplicate efforts of a team being invested in a single function. The levels of writing test cases are:

• Level 1: This level includes the writing of test cases that are based on the available information about the product’s specification and user documentation

• Level 2: Considered to be a practical stage, this level includes writing of test cases on the basis of actual functional and system flow of the application

• Level 3: At this level, some test cases are grouped together to write a test procedure. Test procedure refers to a group of small test cases and can include a maximum of 10 test cases

• Level 4: The process is automated at this level. This helps in minimizing the human interaction with the system, which enables the QA to focus only on currently updated functionalities to test

Tips to Write Test Cases for Android Application Writing a good test case is easy. However, it just requires an individual’s hard work, determination and clear focus. Some of the simple tips to write an effective test case for Android application include:

• Test cases should be written in such a way that they allow a person to test only one feature at a time

• One should not overlap or complicate test cases • Cover all the positive and negative probabilities of the test outcomes • Write in simple language with exact and accurate names of forms, fields, etc. • Android developers should make sure that they continue to create test cases when the

application code is still in the process of writing • Test cases should be stores in version control along with source code • The focus should also be on continuous integration of the new test cases • Tests should be run every time the code is changed • Avoid using emulators and rooted devices Apart from these, it is also important that the test cases are accurate and meet the exact purpose of conducting a test. These should also be free from any sort of unnecessary information and be capable of being reused.

Conducting a test on an Android application is essential as this is one crucial step that can decide the fate of the entire application. If conducted properly, one can fix all the bugs and launch a superb quality product in the market. Therefore, make sure that launch of your next product is preceded by its thorough testing so as to ensure a superb quality.

stqa manual 2018-19 · laboratory mannual contents this manual is intended for the third year...

Documents