A Review On Software Testing In SDlC And Testing Tools

Transcription

1 International Journal Of Engineering And Computer Science ISSN: Volume - 3 Iue -9 September, 2014 Page No A Review On Software Teting In SDlC And Teting Tool T.Amruthavalli*, S.MahaLAkhmi*, K.HariKrihnan* Ait Prof, SKR Engineering college. amrutha1201@gmail.com Ait Prof, SKR Engineering college. maha3088@yahoo.com UG Scholar,SKR Engineering Abtract- The paper review the oftware teting and the different tool ued for teting the oftware.the teting i baed on the method of it attribute,ecurity and it uability.teting i an important part in oftware engineering where the coding get deployed baed on the teting.the teting can be done with different parameter of different type.i do not mean to give here a complete urvey of oftware teting.rather I intend to how how unwieldy mix of theoretical and technical challenge faced by the teter between the tate of art and practice. Keyword-Software teting,teting and debugging,teting method,teting level. 1.Introduction: Software teting i an invetigation conducted to provide takeholder with information about the quality of the product or ervice under tet. Software teting can alo provide an objective, independent view of the oftware to allow the buine to appreciate and undertand the rik of oftware implementation. Tet technique include, but are not limited to the proce of executing a program or application with the intent of finding oftware bug (error or other defect)[1].it involve the execution of a oftware component or ytem to evaluate one or more propertie of interet. In general, thee propertie indicate the extent to which the component or ytem under tet. A the number of poible tet for even imple oftware component i practically infinite, all oftware teting ue ome trategy to elect tet that are feaible for available time and reource. A a reult, oftware teting typically (but not excluively) attempt to execute a program or application with the intent of finding oftware bug (error or other defect).software teting can provide objective, independent information about the quality of oftware and rik of it failure to uer and/or ponor. 2.Software Teting Level: Software teting i the proce of evaluation a oftware item to detect difference between given input and expected output. Alo to ae the feature of A oftware item. Teting aee the quality of the product. Software teting i a proce that hould be done during the development proce. In other word oftware teting i a verification and validation proce[2]. Verification Verification i the proce to make ure the product atifie the condition impoed at the tart of the development phae. In other word, to make ure the product behave the way we want it to. Validation Validation i the proce to make ure the product atifie the pecified requirement at the end of the development phae. In other word, to make ure the product i built a per cutomer requirement. T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8188

2 Black box teting Internal ytem deign i not conidered in thi type of teting. Tet are baed on requirement and functionality. White box teting Thi teting i baed on knowledge of the internal logic of an application code. Alo known a Gla box Teting. Internal oftware and code working hould be known for thi type of teting. Tet are baed on coverage of code tatement, branche, path, condition. Unit teting Teting of individual oftware component or module. Typically done by the programmer and not by teter, a it require detailed knowledge of the internal program deign and code. may require developing tet driver module or tet harnee. Incremental integration teting Bottom up approach for teting i.e continuou teting of an application a new functionality i added; Application functionality and module hould be independent enough to tet eparately. done by programmer or by teter. Integration teting Teting of integrated module to verify combined functionality after integration. Module are typically code module, individual application, client and erver application on a network, etc. Thi type of teting i epecially relevant to client/erver and ditributed ytem. Functional teting Thi type of teting ignore the internal part and focu on the output i a per requirement or not. Black-box type teting geared to functional requirement of an application. Sytem teting Entire ytem i teted a per the requirement. Black-box type teting that i baed on overall requirement pecification, cover all combined part of a ytem. End-to-end teting Similar to ytem teting, involve teting of a complete application environment in a ituation that mimic real-world ue, uch a interacting with a databae, uing network communication, or interacting with other hardware, application, or ytem if appropriate. Sanity teting - Teting to determine if a new oftware verion i performing well enough to accept it for a major teting effort. If application i crahing for initial ue then ytem i not table enough for further teting and build or application i aigned to fix. Regreion teting Teting the application a a whole for the modification in any module or functionality. Difficult to cover all the ytem in regreion teting o typically automation tool are ued for thee teting type. Acceptance teting -Normally thi type of teting i done to verify if ytem meet the cutomer pecified requirement. Uer or cutomer do thi teting to determine whether to accept application. Load teting It a performance teting to check ytem behavior under load. Teting an application under heavy load, uch a teting of a web ite under a range of load to determine at what point the ytem repone time degrade or fail. Stre teting Sytem i treed beyond it pecification to check how and when it fail. Performed under heavy load like putting large number beyond torage capacity, complex databae querie, continuou input to ytem or databae load. Performance teting Term often ued interchangeably with tre and load teting. To check whether ytem meet performance requirement. Ued different performance and load tool to do thi. Uability teting Uer-friendline check. Application flow i teted, Can new uer undertand the application eaily, Proper help documented whenever uer tuck at any point. Baically ytem navigation i checked in thi teting. Intall/unintall teting - Teted for full, partial, or upgrade intall/unintall procee on different operating ytem under different hardware, oftware environment. Recovery teting Teting how well a ytem recover from crahe, hardware failure, or other catatrophic problem. Security teting Can ytem be penetrated by any hacking way. Teting how well the ytem protect againt unauthorized internal or external acce. Checked if ytem, databae i afe from external attack. Compatibility teting Teting how well oftware perform in a particular hardware/oftware/operating ytem/network environment and different combination of above. Comparion teting Comparion of product trength and weaknee with previou verion or other imilar product. Alpha teting In houe virtual uer environment can be created for thi type of teting. Teting i done at the end of development. Still minor deign change may be made a a reult of uch teting. Beta teting Teting typically done by end-uer or other. Final teting before releaing application for commercial purpoe. T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8189

3 Tet Deigning You deign/detail your tet on the bai of detailed requirement /deign of the oftware (ometime, on the bai of your imagination). Cae/ Tet Script /Tet Data Requir ement Tracea bility Matrix Creativit y teting fundamental 3.Phae of Teting : Fig:1 oftware Tet Environmen t Setup You etup the tet environment (erver/client /network, etc) with the goal of replicating the enduer environment. Enviro nment Rich compan y Phae Activity Deliverable Requiremen t/deign Review Tet Planning You review the oftware requirement /deign (Well, if they exit.) Once you have gathered a general idea of what need to be teted, you plan for the tet. Revie w Defect Report Plan Etima tion Sched ule Neceit y Curioit y Faright edne Tet Execution Tet Reporting You execute your Tet Cae/Script in the Tet Environment to ee whether they pa. You prepare variou report for variou takeholder. Reult (Incre mental ) Defect Report Reult (Final) /D efect Metric Clour e Patience Diploma cy T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8190

4 Report Who Worke d Till Late & on Weeke nd Report analyi and verification of requirement are alo conidered teting. Reviewing the deign in the deign phae with intent to improve the deign i alo conidered a teting. Teting performed by a developer on completion of the code i alo categorized a Unit type of teting. Unlike when to tart teting it i difficult to determine when to top teting, a teting i a never ending proce and no one can ay that any oftware i 100% teted. Following are the apect which hould be conidered to top the teting: teting Deadline. 4.Teting Role: Completion of tet cae execution. It depend on the proce and the aociated takeholder of the project(). In the IT indutry, large companie have a team with reponibilitie to evaluate the developed oftware in the context of the given requirement. Moreover, developer alo conduct teting which i called Unit Teting[3]. In mot cae, following profeional are involved in teting of a ytem within their repective capacitie: Software Teter Completion of Functional and code coverage to a certain point. Bug rate fall below a certain level and no high priority bug are identified. Management deciion. 5.Teting, Quality Aurance and Quality Control: Software Developer Project Lead/Manager End Uer Different companie have difference deignation for people who tet the oftware on the bai of their experience and knowledge uch a Software Teter, Software Quality Aurance Engineer, and QA Analyt etc. It i not poible to tet the oftware at any time during it cycle. The next two ection tate when teting hould be tarted and when to end it during the SDLC. 4.1 Teting time: An early tart to teting reduce the cot, time to rework and error free oftware that i delivered to the client. However in Software Development Life Cycle (SDLC) teting can be tarted from the Requirement Gathering phae and lat till the deployment of the oftware. However it alo depend on the development model that i being ued. For example in Water fall model formal teting i conducted in the Teting phae, but in incremental model, teting i performed at the end of every increment/iteration and at the end the whole application i teted. Mot people are confued with the concept and difference between Quality Aurance, Quality Control and Teting. Although they are interrelated and at ome level they can be conidered a the ame activitie, but there i indeed a difference between them. Mentioned below are the definition and difference between them: S.N. Quality Aurance 1 Activitie which enure the implementation of procee, procedure and tandard in context to verification of developed oftware and intended requirement. Quality Control Activitie which enure the verification of developed oftware with repect to documented (or not in ome cae) requirement. Teting Activitie which enure the identification of bug/error/defect in the Software. Teting i done in different form at every phae of SDLC like during Requirement gathering phae, the T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8191

5 2 3 Focue on procee and procedure rather then conducting actual teting on the ytem. Proce oriented activitie. Focue on actual teting by executing Software with intend to identify bug/defect through implementation of procedure and proce. Product oriented activitie. Focue on actual teting. Product oriented activitie. and tet the Software to identify any un-expected behavior or bug[5]. There are different tage for manual teting like unit teting, Integration teting, Sytem teting and Uer Acceptance teting. Teter ue tet plan, tet cae or tet cenario to tet the Software to enure the completene of teting. Manual teting alo include exploratory teting a teter explore the oftware to identify error in it. Automation teting Automation teting which i alo known a Tet Automation, i when the teter write cript and ue another oftware to tet the oftware. Thi proce involve automation of a manual proce. Automation Teting i ued to re-run the tet cenario that were performed manually, quickly and repeatedly. 4 Preventive activitie. It i a corrective proce. It i a corrective proce. 5 It i a ubet of Software Tet Life Cycle (STLC). QC can be conidered a the ubet of Quality Aurance. Teting i the ubet of Quality Control. 6.Teting and Debugging : TESTING: It involve the identification of bug/error/defect in the oftware without correcting it. Normally profeional with a Quality Aurance background are involved in the identification of bug[4]. Teting i performed in the teting phae. DEBUGGING: It involve identifying, iolating and fixing the problem/bug. Developer who code the oftware conduct debugging upon encountering an error in the code. Debugging i the part of White box or Unit Teting. Debugging can be performed in the development phae while conducting Unit Teting or in phae while fixing the reported bug. 6.1Teting Type : Manual teting Thi type include the teting of the Software manually i.e. without uing any automated tool or any cript. In thi type the teter take over the role of an end uer Apart from regreion teting, Automation teting i alo ued to tet the application from load, performance and tre point of view. It increae the tet coverage; improve accuracy, ave time and money in comparion to manual teting. 7.Teting Method: Black Box Teting The technique of teting without having any knowledge of the interior working of the application i Black Box teting. The teter i obliviou to the ytem architecture and doe not have acce to the ource code. Typically, when performing a black box tet, a teter will interact with the ytem' uer interface by providing input and examining output without knowing how and where the input are worked upon. White Box Teting. In order to perform white box teting on an application, the teter need to poe White box teting i the detailed invetigation of internal logic T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8192

6 and tructure of the code. White box teting i alo knowledge of the internal working of the code[6]. The teter need to have a look inide the ource code and find out which unit/chunk of the code i behaving inappropriately. Grey Box Teting Grey Box teting i a technique to tet the application with limited knowledge of the internal working of an application. In oftware teting, the term the more you know the better carrie a lot of weight when teting an application. Matering the domain of a ytem alway give the teter an edge over omeone with limited domain knowledge. Unlike black box teting, where the teter only tet the application' uer interface, in grey box teting, the teter ha acce to deign document and the databae. Having thi knowledge, the teter i able to better prepare tet data and tet cenario when making the tet plan. Functional Teting Thi i a type of black box teting that i baed on the pecification of the oftware that i to be teted. The application i teted by providing input and then the reult are examined that need to conform to the functionality it wa intended for. Functional Teting of the oftware i conducted on a complete, integrated ytem to evaluate the ytem' compliance with it pecified requirement[7]. There are five tep that are involved when teting an application for functionality. An effective teting practice will ee the above tep applied to the teting policie of every organization and hence it will make ure that the organization maintain the trictet of tandard when it come to oftware quality. Unit Teting Thi type of teting i performed by the developer before the etup i handed over to the teting team to formally execute the tet cae. Unit teting i performed by the repective developer on the individual unit of ource code aigned area. The developer ue tet data that i eparate from the tet data of the quality aurance team. The goal of unit teting i to iolate each part of the program and how that individual part are correct in term of requirement and functionality. Integration Teting The teting of combined part of an application to determine if they function correctly together i Integration teting. There are two method of doing Integration Teting Bottom-up Integration teting and Top Down Integration teting. S.N. Integration Teting Method 1 Bottom-up integration Thi teting begin with unit teting, followed by tet of progreively higher-level combination of unit called module or build. Step I Decription The determination of the functionality that the intended application i meant to perform. 2 Top-Down integration Thi teting, the highet-level module are teted firt and progreively lower-level module are teted after that. II III IV V The creation of tet data baed on the pecification of the application. The output baed on the tet data and the pecification of the application. The writing of Tet Scenario and the execution of tet cae. The comparion of actual and expected reult baed on the executed tet cae. In a comprehenive oftware development environment, bottom-up teting i uually done firt, followed by top-down teting. The proce conclude with multiple tet of the complete application, preferably in cenario deigned to mimic thoe it will encounter in cutomer' computer, ytem and network. Sytem Teting Thi i the next level in the teting and tet the ytem a a whole. Once all the component are integrated, the application a a whole i teted rigorouly to ee that it meet Quality Standard. Thi type of teting i performed by a pecialized teting team. T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8193

7 Sytem teting i o important becaue of the following reaon: Sytem Teting i the firt tep in the Software Development Life Cycle, where the application i teted a a whole. The application i teted thoroughly to verify that it meet the functional and technical pecification. imple pelling mitake, cometic error or Interface gap, but alo to point out any bug in the application that will reult in ytem craher or major error in the application. By performing acceptance tet on an application the teting team will deduce how the application will perform in production. There are alo legal and contractual requirement for acceptance of the ytem. The application i teted in an environment which i very cloe to the production environment where the application will be deployed. Sytem Teting enable u to tet, verify and validate both the buine requirement a well a the Application Architecture. Regreion Teting Whenever a change in a oftware application i made it i quite poible that other area within the application have been affected by thi change. To verify that a fixed bug han't reulted in another functionality or buine rule violation i Regreion teting. The intent of Regreion teting i to enure that a change, uch a a bug fix did not reult in another fault being uncovered in the application. ALPHA TESTING Thi tet i the firt tage of teting and will be performed amongt the team (developer and QA team). Unit teting, integration teting and ytem teting when combined are known a alpha teting. During thi phae, the following will be teted in the application: Spelling Mitake Broken Link Cloudy Direction The Application will be teted on machine with the lowet pecification to tet loading time and any latency problem. Regreion teting i o important becaue of the following reaon: BETA TESTING Minimize the gap in teting when an application with change made ha to be teted. Teting the new change to verify that the change made did not affect any other area of the application. Mitigate Rik when regreion teting i performed on the application. Thi tet i performed after Alpha teting ha been uccefully performed. In beta teting a ample of the intended audience tet the application. Beta teting i alo known a pre-releae teting. Beta tet verion of oftware are ideally ditributed to a wide audience on the Web, partly to give the program a "real-world" tet and partly to provide a preview of the next releae. In thi phae the audience will be teting the following: Tet coverage i increaed without compromiing timeline. Uer will intall, run the application and end their feedback to the project team. Increae peed to market the product. Acceptance Teting Thi i arguably the mot importance type of teting a it i conducted by the Quality Aurance Team who will gauge whether the application meet the intended pecification and atifie the client. requirement. The QA team will have a et of pre written cenario and Tet Cae that will be ued to tet the application. More idea will be hared about the application and more tet can be performed on it to gauge it accuracy and the reaon why the project wa initiated. Acceptance tet are not only intended to point out Typographical error, confuing application flow, and even crahe. Getting the feedback, the project team can fix the problem before releaing the oftware to the actual uer. The more iue you fix that olve real uer problem, the higher the quality of your application will be. Having a higher-quality application when you releae to the general public will increae cutomer atifaction. T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8194

8 On the other hand Uability teting enure that a good and uer friendly GUI i deigned and i eay to ue for the end uer. UI teting can be conidered a a ub part of Uability teting. Security Teting Security teting involve the teting of Software in order to identify any flaw ad gap from ecurity and vulnerability point of view. Following are the main apect which Security teting hould enure: overall teting of Software with repect to it uage over different environment. Computer Hardware, Operating Sytem and Brower are the major focu of Portability teting. Following are ome precondition for Portability teting: Software hould be deigned and coded, keeping in mind Portability Requirement. Unit teting ha been performed on the aociated component. Confidentiality. Integration teting ha been performed. Integrity. Tet environment ha been etablihed. Authentication. 8.Software Teting Documentation: Availability. Authorization. Teting documentation involve the documentation of artifact which hould be developed before or during the teting of Software. Non-repudiation. Software i ecure againt known and unknown vulnerabilitie. Software data i ecure. Software i according to all ecurity regulation. Input checking and validation. SQL inertion attack. Injection flaw. Seion management iue. Cro-ite cripting attack. Buffer overflow vulnerabilitie. Directory traveral attack. Documentation for Software teting help in etimating the teting effort required, tet coverage, requirement tracking/tracing etc. Thi ection include the decription of ome commonly ued documented artifact related to Software teting uch a: Tet Plan Tet Scenario Tet Cae Traceability Matrix Tet Plan A tet plan outline the trategy that will be ued to tet an application, the reource that will be ued, the tet environment in which teting will be performed, the limitation of the teting and the chedule of teting activitie. Typically the Quality Aurance Team Lead will be reponible for writing a Tet Plan. Portability Teting A tet plan will include the following. Portability teting include the teting of Software with intend that it hould be re-ueable and can be moved from another Software a well[8]. Following are the trategie that can be ued for Portability teting. Tranferred intalled Software from one computer to another. Introduction to the Tet Plan document Aumption when teting the application Lit of tet cae included in Teting the application Lit of feature to be teted Building executable (.exe) to run the Software on different platform. What ort of Approach to ue when teting the oftware Portability teting can be conidered a one of the ub part of Sytem teting, a thi teting type include the Lit of Deliverable that need to be teted T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8195

9 The reource allocated for teting the application Product verion. Any Rik involved during the teting proce Reviion hitory. A Schedule of tak and miletone a teting i tarted Purpoe Tet Scenario Aumption A one line tatement that tell what area in the application will be teted. Tet Scenario are ued to enure that all proce flow are teted from end to end. A particular area of an application can have a little a one tet cenario to a few hundred cenario depending on the magnitude and complexity of the application[9]. Pre-Condition. Step. Expected Outcome. Actual Outcome. The term tet cenario and tet cae are ued interchangeably however the main difference being that tet cenario ha everal tep however tet cae have a ingle tep. When viewed from thi perpective tet cenario are tet cae, but they include everal tet cae and the equence that they hould be executed. Apart from thi, each tet i dependent on the output from the previou tet. Pot Condition. Many Tet cae can be derived from a ingle tet cenario. In addition to thi, ome time it happened that multiple tet cae are written for ingle Software which i collectively known a tet uite. 9.concluion Thu the paper review the teting of different level and different method of teting were been dicued.each and every teting ha ome uniquene in their own way.thu teting which make the module with goodne and atify the requirement of the cutomer. Reference: 1. Exploratory Teting, Cem Kaner, Florida Intitute of Technology, Quality Aurance Intitute Worldwide Annual Software Teting Conference, Orlando, FL, November Tet Cae Tet cae involve the et of tep, condition and input which can be ued while performing the teting tak. The main intent of thi activity i to enure whether the Software Pae or Fail in term of it functionality and other apect. There are many type of tet cae like: functional, negative, error, logical tet cae, phyical tet cae, UI tet cae etc. Furthermore tet cae are written to keep track of teting coverage of Software. Generally, there i no formal template which i ued during the tet cae writing[10]. However, following are the main component which are alway available and included in every tet cae: Tet cae ID. Product Module. 2. Software Teting by Jiantao Pan, Carnegie Mellon Univerity 3.Leitner, A., Ciupa, I., Oriol, M., Meyer, B., Fiva, A., "Contract Driven Development = Tet Drive Development Writing Tet Cae", Proceeding of ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Sympoium on the Foundation of Software Engineering 2007, (Dubrovnik, Croatia), September Kaner, Cem; Falk, Jack and Nguyen, Hung Quoc (1999). Teting Computer Software, 2nd Ed. New York, et al: John Wiley and Son, Inc. pp. 480 page. ISBN Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Bet Practice in T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8196

10 Software Management. Wiley-IEEE Computer Society Pre. pp ISBN Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Bet Practice in Software Management. Wiley-IEEE Computer Society Pre. p ISBN Section 1.1.2, Certified Teter Foundation Level Syllabu, International Software Teting Qualification Board 8. Principle 2, Section 1.3, Certified Teter Foundation Level Syllabu, International Software Teting Qualification Board 9. "Proceeding from the 5th International Conference on Software Teting and Validation (ICST) Software Competence Center Hagenberg. "Tet Deign: Leon Learned and Practical Implication.". 10. Software error cot U.S. economy $59.5 billion annually, NIST report T.Amruthavalli, IJECS Volume-3 Iue-9 September 2014 Page No Page 8197