Software Coding and Testing SE Unit-6 PDF
Document Details
Uploaded by ManageableMinimalism645
V.V.P. Engineering College
Tags
Related
- Module8-Software Testing.pdf
- Unit-1 Introduction to Software Testing and Quality (E-next.in).pdf
- Unit-1 Introduction to Software Testing and Quality (E-next.in).pdf
- Unit-1 Introduction to Software Testing and Quality (E-next.in).pdf
- Unit-1 Introduction to Software Testing and Quality (E-next.in).pdf
- CT501-N Software Engineering PDF
Summary
This document covers software coding and testing, including topics like coding standards, coding guidelines, and code review. It also discusses different testing methodologies such as unit, integration, and validation testing, and how to test object-oriented and web/mobile applications.
Full Transcript
In the coding phase, the design documents are translated into codes. The main goal of coding phase is to transform the design produced after requirements are collected and analyzed, into code by using some languages. Each software organizations have their own standards a...
In the coding phase, the design documents are translated into codes. The main goal of coding phase is to transform the design produced after requirements are collected and analyzed, into code by using some languages. Each software organizations have their own standards and formatting styles for writing codes. All the software developers strictly follow the standards laid by the organizations in order to produce uniform code patterns. Most software development organizations formulate their own coding standards. Following are some important advantages for using specific coding style: It produces uniform code. It is very easy for the developers to understand the code. Newly joined numbers in the development team can easily cope up with progress of the development process. It is actually very good programming practice. Following are some coding standards generally followed by most of the software organizations: Rules for naming different variables. Rules for exceptions handling. Rules for using global. Standard headers for each of the modules. Following are some coding guidelines generally followed by most of the software organizations: Use simple coding styles that can be easily understood by other programmers. Avoid using complex conventions. The codes should be well documented. The functions and procedures should be short, it should not be too lengthy. Avoid using Go to statements. In the coding phase, the design documents are translated into codes. Each software organizations have their own standards and formatting style for writing codes. All the software developers strictly follow the standard organizations of uniform code pattern. Code review is necessary after completion of each of the modules of a software under construction. In this phase, as many errors are possible are uncovered and resolved. The code review is very economical, since errors are detected and corrected early in the development stages. Code review consists of following three activities: 1. Testing 2. Debugging, and 3. Correcting the errors Following are some of review techniques generally used: →Code walkthrough is used to detect algorithmic and logical errors. →Code inspection is used to detect common programming errors. →Cleanroom testing. 1. Code Walkthrough : A walkthrough is a term describing the review process at an abstract level. It is an informal code analysis technique. The term is often used in software industry to describe the process of inspecting algorithms and source code to find out logical error by paths through the algorithms or code as determined by input conditions. Code Walkthrough is a form of peer review in which a programmer leads the review process and the other team members ask questions and spot possible errors against development standards and other issues. Before the walkthrough meeting, the preparation by reviewers and then a review report with a list of findings. 2. Code Inspection : Code Inspection is the most formal type of review, which is a kind of avoid the defect multiplication at a later stage. The main purpose of code inspection is to find defects and it can also spot any process improvement if any. Once the code is written for a module; it is first verified before it is used by other. Inspection was started for detecting faults in code, and was later applied for design, requirement etc. Preparation before the meeting is essential, which includes reading of any source documents to ensure consistency. The inspection process is the most formal type of review based on rules and checklists and makes use of entry and exit criteria. After the meeting, a formal follow-up process is used to ensure that corrective action is completed in a timely manner. 3.Cleanroom Testing : The strategy and tactics of classroom testing are basically different from traditional testing strategies and tactics. Traditional methods generate a set of test cases to find the design and coding errors. The primary goal of cleanroom testing is to validate software requirements by showing the statistical samples of use-cases that have been executed successfully. The technical documentation is important and it is easily accessible. It is well organized. Also it is specific, details and an accurate. Software engineer develops a software configuration i.e., programs, data and documents. All these attributes are amenable to testing. Verification evaluates all the documentation, planning, coding, requirements and specifications. The complete test plan for integration testing is documented in a test specification. The performance requirements must be attained and documentation must be correct. The documentation section describes each of the work produced as part of the software process. These includes: →Project documents (e.g., project plan) →Models (e.g., ER diagrams, class diagrams) →Technical documents (e.g., specifications, test plans) →User documents (e.g., help files) Documentation testing is conducted in following two phases: 1.Review and inspection 2.Actual test of application is accordance with documentation. Following are the list of questions that must be answered while conducting documentation testing: →Are all modes of use are described accurately? →Is description of the sequence of each interaction accurate? →Are all the terminologies, menu descriptions and system responses are in advance with the actual program? →Is the table of contents and index accurate and complete? →Are hyperlinks correct and accurate? →Is design navigation is appropriate? All these questionnaires must be checked and answered by the independent third party. Testing is an important activity in software development process. Before the start of the development, testing is planned and is conducted very systematically. In order to implement the testing, there are various testing strategies defined in the software engineering literature. All these strategies provided a testing template to the developers. Following are the characteristic that process the testing templates: The developer should conduct the successful technical reviews to perform the testing successful. Testing starts with the component level and work from outside toward the integration of the whole computer based system. Different testing techniques are suitable at different point in time. Testing is organized by the developer of the software and by an independent test group. Debugging and testing are different activities, then also the debugging should be accommodated in any strategy of testing. Testing focuses on finding errors whereas debugging starts after a bug has been identified in the software. 1.Unit testing : It focuses each of the components individually and ensures that it should work properly as per requirements. 2.Integration testing : An integration testing focuses on the construction and design of the software. The test cases also focus on inputs and outputs during integration. 3.Validation testing : Check all the requirements like functional, behavioral and performance requirement are validate against the construction software. 4.System testing : System testing confirms all system elements and performance are tested entirely. Verification Validation Verification is the process to find The validation process is checked whether the software meets the whether the software meets specified requirements for particular requirements and expectation of the phase. customer. It estimates an intermediate product. It estimates the final product. The objectives of verification is to check The objectives of the validation is to whether software is constructed check whether the specifications are according to requirement and design correct and satisfy the business need. specification. It describes whether the outputs are as It explains whether they are accepted per the inputs or not. by the user or not. Verification is done before the It is done after the verification. validation. Plans, requirement, specification, code Actual product or software is tested are evaluated during the verifications. under validation. It is a computer software or developed It manually checks the files and program based checking of files and document. document. Once the software is developed it should be tested in a proper manner before the system is delivered to the user. For this, two techniques that provide systematic guidance for designing tests are used. These techniques are discussed here. Once the internal working of software is known, tests are performed to ensure that all internal operations of the software are performed according to specifications. This is referred to as white box testing. Once the specified function for which the software has been designed is known, tests are performed to ensure that each function is working properly. This is referred to as black box testing. 1. White Box Testing White box testing (also called structural testing or glass box testing) is performed to test the program internal structure. The goal of White Box testing is to verify all the decision branches, loops, statements in the code. To perform white box testing, the tester should have a through knowledge of the program internals along with the purpose of developing the software. During this testing, the entire software implementation is also included with the specification. This helps in detecting errors even with unclear or incomplete software specification. Figure : White box testing The goal of white box testing is to ensure that the test cases (developed by software testers by using white box testing) exercise each path through a program. The test cases also ensure the following. 1.All independent paths within the program have been exercised at least once. 2.All internal data structures have been exercised. 3.All loops (simple loops and nested loops) have been executed at and within their specified boundaries. 4.All segments present between the control structures (like 'switch' statement) have been executed at least once. 5.Each branch (like 'case' statement) has been exercised at least once. 6.All the logical conditions as well as their combinations have been executed at least once for both true and false paths. White box testing involves the testing of the software code for the following: Internal security process Broken or poorly structured paths in the coding processes The flow of specific inputs through the code Expected output The functionality of conditional loops Testing of each statement, object, and function on an individual basis 2.Black Box Testing Black box (or functional) testing checks the functional requirements and examines the input and output data of these requirements. When black box testing is performed, only the sets of 'legal' input and corresponding outputs should be known to the tester and not the internal logic of the program to produce that output. Hence to determine the functionality, the outputs produced for the given sets of input are observed. Figure : Black box Testing This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see. This method attempts to find errors in the following categories: →Incorrect or missing functions →Interface errors →Errors in data structures or external database access →Behavior or performance errors The black box testing is used to find the errors listed below. 1.Interface errors such as functions, which are unable to send or receive data to/from software. 2.Incorrect functions that lead to undesired output when executed. 3.Missing functions and erroneous data structures. 4.Erroneous databases, which lead to incorrect outputs when the software uses the data present in these databases for processing. 5.Incorrect conditions due to which the functions produce incorrect outputs when they are executed. 6.Termination errors such as certain conditions due to which a function enters a loop that forces it to execute indefinitely. Here are the generic steps followed to carry out any type of Black Box Testing. Initially, the requirements and specifications of the system are examined. Tester chooses valid inputs (positive test scenario) to check whether SUT (System Under Test) processes them correctly. Also some invalid inputs (negative test scenario) are chosen to verify that the SUT is able to detect them. Tester determines expected outputs for all those inputs. Software tester constructs test cases with the selected inputs. Software tester compares the actual outputs with the expected outputs. Test suite is a container that has a set of tests which helps testers in executing and reporting the test execution status. It can take any of the three states namely Active, In progress and completed. The test suite is created to describe following parameters: →What is to be tested? →Define the preconditions. →Define the post conditions. →Assign various test steps that are to be followed. →Also record the result of ongoing test case. A test suite is a set of machines that is usually considered as a platform to test the web apps. These machines are designed in such a way that they behave like a client-side environment for testing the Web Apps. On the other hand the labs are specially equipped and designed for usability testing. The test labs allow the monitoring of various users testing the applications. Following are some goals that of designing a test suite: →Always provide a very clear environment for testing. →For enhancing the productivity, provide rapid test and review prototypes. →For testing the connectivity and network performance, provide proper environment over the production servers. →Also provide clean environment for usability testing. A well designed test suite should address the following points: Provide compatibility with the browsers that are commonly used by the majority of the users. The platform used must be compatible for the sites used by the majority of the users. Consider the budget parameters while designing the test suite. For the conventional software, there are various test strategies available for use. In first one, the team waits for a product development to be completed and then start conducting tests. In another approach, the developer conducts the test on a daily basis as the development proceeds and one part of the program is completed. These strategies are chosen by the development team based on the product and convenience of the team. The choice may among two approaches discussed above. The team starts with an incremental view of testing and test individual program units. Then moving ahead with integration of the units, and finalizing the tests of overall system. Different types of tests are mentioned below: 1.Unit Testing 2.Integration Testing 3.Regression Testing 4.Smoke Testing 1.Unit Testing is a level of software testing where individual units/ components of a software are tested. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output. In procedural programming, a unit may be an individual program, function, procedure, etc. 2.Integration Testing also known as integration and testing (I&T), is a software development process which program units are combined and tested as groups in multiple ways. In this context, a unit is defined as the smallest testable part of an application. 3.Regression Testing is defined as a type of software testing to confirm that a recent program or code change has not adversely affected existing features. Regression Testing is nothing but a full or partial selection of already executed test cases which are re-executed to ensure existing functionalities work fine. 4.Smoke Testing Smoke testing is defined as a type of software testing that determines whether the deployed build is stable or not. Smoke testing is a process where the software build is deployed to QA environment and is verified to ensure the stability of the application. It is also called as "Build verification Testing" or “Confidence Testing.” In object-oriented environment programming consists of procedures operating on data, while the object-oriented paradigm focuses on objects that are instances of classes. In object-oriented (OO) paradigm, software engineers identify and specify the objects and services provided by each object. In addition, interaction of any two objects and constraints on each identified object are also determined. The main advantages of OO paradigm include increased reusability, reliability, interoperability, and extendibility. OO program should be tested at different levels to uncover all the errors. At the algorithmic level, each module (or method) of every class in the program should be tested in isolation. For this, white-box testing can be applied easily. As classes form the main unit of object-oriented program, testing of classes is the main concern while testing an OO program. At the class level, every class should be tested as an individual entity. At this level, programmers who are involved in the development of class conduct the testing. To adequately test OO systems, three things must be done: 1)The definition of testing must be broadened to inclu de error discovery techniques applied to object- oriented analysis and design models. 2)The strategy for unit and integration testing must change significantly, and 3)The design of test cases must account for the unique characteristics of OO software. Developing Test Cases in Object-oriented Testing The methods used to design test cases in OO testing are based on the conventional methods. However, these test cases should encompass special features so that they can be used in the object-oriented environment. The points that should be noted while developing test cases in an object-oriented environment are listed below. 1.It should be explicitly specified with each test case which class it should test. 2.Purpose of each test case should be mentioned. 3.External conditions that should exist while conducting a test should be clearly stated with each test case. 4.All the states of object that is to be tested should be specified. 5.Instructions to understand and conduct the test cases should be provided with each test case. As many organizations are currently using or targeting to switch to the OO paradigm, the importance of OO software testing is increasing. The methods used for performing object-oriented testing are discussed in this section. 1.State-based Testing State-based testing is used to verify whether the methods (a procedure that is executed by an object) of a class are interacting properly with each other. This testing seeks to exercise the transitions among the states of objects based upon the identified inputs. 2.Fault-based Testing Fault-based testing is used to determine or uncover a set of possible faults. In other words, the focus of tester in this testing is to detect the presence of possible faults. Fault-based testing starts by examining the analysis and design models of OO software as these models may provide an idea of problems in the implementation of software. 3.Scenario-based Testing Scenario-based testing is used to detect errors that are caused due to incorrect specifications and improper interactions among various segments of the software. The use of scenarios in testing is a common way of describing how a user might accomplish a task or achieve a goal within a specific context or environment. Note that these scenarios are more context- and user specific instead of being product-specific. The testing strategy for web and mobile applications use the basic principles for all software testing and also applies the strategies and tactics of object- oriented testing. Following steps summarizes the approach: The content model for Web and Mobile Applications are reviewed to uncover errors. The interface model is reviewed to ensure that all use cases can be accommodated. The design model for web and Mobile Applications are reviewed to uncover navigation errors. The user interface is tested to uncover errors in presentation or navigation mechanics. Each functional component is unit tested. Navigation throughout the architecture is tested. The Web and Mobile Applications are implemented in a variety of different environment of configurations. Security testes are conducted. Performance tests are conducted. The Web and Mobile Applications are tested by a controlled and monitored population of end users. We know that testing a software application is how tedious and painful. It consumes lot of time and man hours. Eventually heavy investment is required. Also there are possibilities of mistakes using manual testing. Sometimes it is quite impossible to test all feature of software thoroughly before the final delivery of the product to the client. In order to control testing in a proper way, some automated tools are used to uncover the errors and correct then accordingly. The examples of these automated tools are as follows: 1. WinRunner 2. LoadRunner Win Runner is the most used Automated Software Testing Tool. Main Features of Win Runner are : →Developed by Mercury Interactive →Functionality testing tool →Supports C/s and web technologies such as (VB, VC++, Java, HTML, Power Builder, Cibell (ERP)) →To Support.net, xml, SAP, Peoplesoft, Oracle applications, Multimedia we can use QTP (Quick Test Professional). →WinRunner run on Windows only. →XRunner run only UNIX and linux. →Tool developed in C on VC++ environment. →To automate our manual test win runner used TSL (Test Script language like c) LoadRunner is a software testing tool from Micro Focus. It is used to test applications, measuring system behavior and performance under load. LoadRunner can simulate thousands of users concurrently using application software, recording and later analyzing the performance of key components of the application. LoadRunner simulates user activity by generating messages between application components or by simulating interactions with the user interface such as key presses or mouse movements. The messages and interactions to be generated are stored in scripts. LoadRunner can generate the scripts by recording them, such as logging HTTP requests between a client web browser and an application's web server. Load testing is to test that if the application works fine with the loads that result from large number of simultaneous users, transactions and to determine weather it can handle peak usage periods. Thank You