undefined | unit 5 coding testing

Back to Study material

Unit - 5Coding & Testing Q1) Write the difference between white box testing and black box testing?A1) Difference between White box testing and Black box testing

White box testing	Black box testing
It is mainly performed by developers of applications.	It is often performed by testers of apps.
Implementation expertise is required.	No implementation experience is required.
That is the inner or internal software testing.	This can be referred to as outer or external software testing.
It's a structural software evaluation.	It is a practical device evaluation.
Having awareness of programming is compulsory.	No programming awareness is required.
It is the logic testing of the software.	It is the behavior testing of the software.
In general, it is applicable to the lower software testing stages.	It is applicable to higher stages of software testing.
Sometimes called as clear box testing.	Sometimes called closed testing.
It is a software testing process in which the tester has knowledge of the software's internal structure or code or programme.	It is a software testing approach in which the internal structure or programme or code is secret and nothing about it is known.
Types of White Box Testing Path Testing Loop Testing Condition Testing	Types of Black Box Testing: Functional Testing Non-functional Testing Regression Testing

Q2) What do you mean by coding?A2) Coding Coding is done when the design phase is over and the design documents are successfully reviewed.Coding is the process of transforming the design of & a system to computer language format.Coding is done by the coder or programmers who are independent people then the designers.Coding Standards & GuidelinesGeneral and good coding standards refers to how the developers write codes that suits the organization.The following are some representative coding standards:-Indentation: – Proper and consistent indentation is essential in producing easy to read and maintainable programs.Rules for limiting the use of global: – These rules file what type of data can be declared global & what cannot.Naming conventions for global variables, local variables and constant identifiers :- A possible naming conversion can be that global variable names always start with a capital letter (e.g. Global), local variable are made of small letters (e.g. Global) and constant names are formed using capital letters only (e.g. CONSTANT).Standard headers to precede the code of different modules: - The information contained in the header of different modules should be standard for an organization.Error return convention & exception handling system:- Different function in a program report the way error conditions are handled. It should be standard within an organization. e.g. → different tasks while encountering an error should return either 0 or 1 consistently.Coding guidelines:General coding guidelines providers the programmer with a set of best methods which can makes the programs more comfortable to read & maintain. The following are some guidelines:-Do not use coding style that is too difficult to understand: - Codes should be easy to understand by all. Many inexperienced programmers actually write codes in clever way which hammers the understanding.Avoid ambiguous side effect: An ambiguous side effect is the one that is not obvious from casual examination. It makes the codes difficult to understand.Do not use an identifier for multiple purposes:- Programmer after use same identifier to denote saved temporary entities. Use of variables for multiple purposes usually makes future enhancements difficult.The code should be well documented:- As a rule of thumb, there must be at least one comment line on an average of every three source lines.The length of any function should not exceed Io source lines:- A very length function is generally very difficult to understand as it possibly carries out various function as well us large no. of variables. For the same reason, it might carry a large no. of bugs too.Do not use GOTO statements:- Use of GOTO Statements makes a program unstructured & very difficult to understand.Q3) Define code review?A3) Code Review Code review is a systematic examination of computer source code. It is intended to find and fix mistakes overlooked in initial development phase, thus improving overall quality of the software as well as the developer’s skill.Generally, the following two types of reviews are carried out on the code. They are: WalkthroughsA structured walkthrough is an in-depth, technical review of some aspects of a software system. Walkthroughs can be anytime , during any phase of a software project.A walkthrough team consists of 4 to 6 people. The person whose material is being reviewed is responsible for providing copies of the review materials to the members of the walkthrough group in advance of the walkthrough session and the team members are responsible for understanding the reviewing material before the session.During the walkthrough the reviewed “walks through” the material while the reviewers look for errors, request clarification and explore problem areas in the material under review.High-level managers should not attend walkthrough sessions as the aim of walkthroughs is error detection not corrective action. Its important to note that the material is reviewed not the person whose material is being reviewed. InspectionsDesign inspections are conducted by teams of trained inspectors who have a checklist of items to be examined.Special forms are used to record problems encountered.A typical inspection team consists of a Moderator or Secretary, a Designer, an Implementer and a Tester. The Designer, Implementer and Tester may or may not be the people responsible for the actual design, implementation and testing of the product being inspected.The team members are trained for their specific roles and typically conduct a dual 2-hrs sessions per day.Q4) What do you mean by system testing?A4) System testing Software is the only one element of a larger computer-based system. Ultimately, software is incorporated with other system elements (e.g., hardware, people, information), and a series of system integration and validation tests are conducted. These tests fall outside the scope of the software process and are not conducted solely by software engineers. However, steps taken during software design and testing can greatly improve the probability of successful software integration in the larger system. A classic system testing problem is "finger-pointing." This occurs when an error is uncovered, and each system element developer blames the other for the problem. Rather than indulging in such nonsense, the software engineer should anticipate potential interfacing problems andDesign error-handling paths that test all information coming from other elements of the system,Conduct a series of tests that simulate bad data or other potential errors at the software interface,Record the results of tests to use as "evidence" if finger-pointing does occur, andParticipate in planning and design of system tests to ensure that software is adequately tested.System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. Although each test has a different purpose, all work to verify that system elements have been properly integrated and perform allocated functions. Q5) Explain top down integration?A5) Top-down IntegrationTop-down integration testing is an incremental approach to construction of program structure. Modules are integrated by moving downward through the control hierarchy, beginning with the main control module (main program). Modules subordinate (and ultimately subordinate) to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.

Fig: Top down integration Referring to Figure above, depth-first integration would integrate all components on a major control path of the structure. Selection of a major path is somewhat arbitrary and depends on application-specific characteristics. For example, selecting the left-hand path, components M1, M2, M5 would be integrated first. Next, M8 or (if necessary for proper functioning of M2) M6 would be integrated. Then, the central and right-hand control paths are built. Breadth-first integration incorporates all components directly subordinate at each level, moving across the structure horizontally. From the figure, components M2, M3, and M4 (a replacement for stub S4) would be integrated first. The next control level, M5, M6, and so on, follows. The integration process is performed in a series of five steps:The main control module is used as a test driver and stubs are substituted for all components directly subordinate to the main control module.Depending on the integration approach selected (i.e., depth or breadth first), subordinate stubs are replaced one at a time with actual components.Tests are conducted as each component is integrated.On completion of each set of tests, another stub is replaced with the real component.Regression testing may be conducted to ensure that new errors have not been introduced. The process continues from step 2 until the entire program structure is built.The top-down integration strategy verifies major control or decision points early in the test process. In a well-factored program structure, decision making occurs at upper levels in the hierarchy and is therefore encountered first. If major control problems do exist, early recognition is essential. If depth-first integration is selected, a complete function of the software may be implemented and demonstrated. For example, consider a classic transaction structure in which a complex series of interactive inputs is requested, acquired, and validated via an incoming path. The incoming path may be integrated in a top-down manner. All input processing (for subsequent transaction dispatching) may be demonstrated before other elements of the structure have been integrated. Early demonstration of functional capability is a confidence builder for both the developer and the customer. Top-down strategy sounds relatively uncomplicated, but in practice, logistical problems can arise. The most common of these problems occurs when processing at low levels in the hierarchy is required to adequately test upper levels. Stubs replace low-level modules at the beginning of top-down testing; therefore, no significant data can flow upward in the program structure. The tester is left with three choices:Delay many tests until stubs are replaced with actual modules,Develop stubs that perform limited functions that simulate the actual module, orIntegrate the software from the bottom of the hierarchy upward.The first approach (delay tests until stubs are replaced by actual modules) causes us to loose some control over correspondence between specific tests and incorporation of specific modules. This can lead to difficulty in determining the cause of errors and tends to violate the highly constrained nature of the top-down approach. The second approach is workable but can lead to significant overhead, as stubs become more and more complex. Q6) Define bottom up integration?A6) Bottom-up IntegrationBottom-up integration testing, as its name implies, begins construction and testing with atomic modules (i.e., components at the lowest levels in the program structure). Because components are integrated from the bottom up, processing required for components subordinate to a given level is always available and the need for stubs is eliminated.A bottom-up integration strategy may be implemented with the following steps:Low-level components are combined into clusters (sometimes called builds) that perform a specific software sub-function.A driver (a control program for testing) is written to coordinate test case input and output.The cluster is tested.Drivers are removed and clusters are combined moving upward in the program structure.

Fig: Bottom up integrationIntegration follows the pattern illustrated in Figure above. Components are combined to form clusters 1, 2, and 3. Each of the clusters is tested using a driver (shown as a dashed block). Components in clusters 1 and 2 are subordinate to Ma. Drivers D1 and D2 are removed and the clusters are interfaced directly to Ma. Similarly, driver D3 for cluster 3 is removed prior to integration with module Mb. Both Ma and Mb will ultimately be integrated with component Mc, and so forth. As integration moves upward, the need for separate test drivers lessens. In fact, if the top two levels of program structure are integrated top down, the number of drivers can be reduced substantially and integration of clusters is greatly simplified. Q7) Describe the program analysis tool?A7) Program Analysis ToolsA program analysis tool implies an automatic tool source code or executable codes as input and produces reports with respect to a few significant attributes of the program, such as ,its size, adherence to programming complexity, adequacy of commenting & testing, etc. We can classify various program analysis.Tools into two broad categories:- Static Analysis toolsDynamic Analysis toolsStatic Analysis Tools: - It is program analysis tools which access & compute different attributes of a software product without executing it. The properties that are normally categorized areThe coding standards are met or not ?Certain programming mistakes such as uninitialized variables, unmatched actual & formal parameters, variables that are announced however never utilized are likewise.Code walkthrough and code inspection may be considered as static analysis methods. It is automatic examination tools. In this way a compiler can be viewed as a static program analysis tool.Dynamic Analysis Tools:Dynamic program analysis tool require program to be executed and its genuine conduct are recorded.As soon as the software is tested the conduct is recorded, the dynamic analysis tools carries out a analysis & produces reports which portray the basic prolusion that has been accomplished by the total test suit for the program.Ordinarily the dynamic analysis results are accounted in the form of histogram or a pie chart to describe the structural coverage achievedQ8) Write about unit testing, also write merit and demerit?A8) Unit testingUnit testing focuses verification effort on the smallest unit of software design—the software component or module. Using the component- level design description as a guide, important control paths are tested to uncover errors within the boundary of the module. The relative complexity of tests and uncovered errors is limited by the constrained scope established for unit testing. The unit test is white-box oriented, and the step can be conducted in parallel for multiple components. Unit Test ConsiderationsThe tests that occur as part of unit tests are illustrated schematically in Figure below. The module interface is tested to ensure that information properly flows into and out of the program unit under test. The local data structure is examined to ensure that data stored temporarily maintains its integrity during all steps in an algorithm's execution. Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing. All independent paths (basis paths) through the control structure are exercised to ensure that all statements in a module have been executed at least once. And finally, all error handling paths are tested.

Fig : Unit Test Tests of data flow across a module interface are required before any other test is initiated. If data do not enter and exit properly, all other tests are moot. In addition, local data structures should be exercised and the local impact on global data should be ascertained (if possible) during unit testing.Selective testing of execution paths is an essential task during the unit test. Test cases should be designed to uncover errors due to erroneous computations, incorrect comparisons, or improper control flow. Basis path and loop testing are effective techniques for uncovering a broad array of path errors. Among the more common errors in computation areMisunderstood or incorrect arithmetic precedence,Mixed mode operations,Incorrect initialization,Precision inaccuracy,Incorrect symbolic representation of an expression.Comparison and control flow are closely coupled to one another (i.e., change of flow frequently occurs after a comparison). Test cases should uncover errors such asComparison of different data types,Incorrect logical operators or precedence,Expectation of equality when precision error makes equality unlikely,Incorrect comparison of variables,Improper or nonexistent loop termination,Failure to exit when divergent iteration is encountered, andImproperly modified loop variables.Among the potential errors that should be tested when error handling is evaluated areError description is unintelligible.Error noted does not correspond to error encountered.Error condition causes system intervention prior to error handling.Exception-condition processing is incorrect.Error description does not provide enough information to assist in the location of the cause of the error.Boundary testing is the last (and probably most important) task of the unit test step. Software often fails at its boundaries. That is, errors often occur when the nth element of an n-dimensional array is processed, when the ith repetition of a loop with i passes is invoked, when the maximum or minimum allowable value is encountered. Test cases that exercise data structure, control flow, and data values just below, at, and just above maxima and minima are very likely to uncover errors. Merit of Unit TestingCan be applied directly to object code and does not require processing source code.Performance profilers commonly implement this measure.Demerit of Unit TestingInsensitive to some control structures (number of iterations)Does not report whether loops reach their termination conditionStatement coverage is completely insensitive to the logical operators (|| and &&).Q9) What do you mean by testing?A9) TestingOnce the source code has been developed testing is required to uncover the errors before it is implemented. In order to perform software testing a series of test case is designed. Definition of TestingAccording to IEEE – “Testing means the process of analyzing a software item to detect the differences between existing and required condition (i.e. bugs) and to evaluate the feature of the software item”.According to Myers – “Testing is the process of analyzing a program with the intent of finding an error”.Primary objectives of Software TestingAccording to Glen Myers the primary objectives of testing are:Testing is a process of executing a program with the intent of finding an error.A good test case is one that has a high probability of finding and as yet undiscovered error.A successful test is one that uncovers as yet undiscovered error.Testing cannot show the absence of errors and defects, it can show only error and detects present. Hence, objective of testing is to design tests that systematically uncover different errors and to do so with a minimum amount of time and effort. ERRORS, FAULT AND FAILUREError – The term error is used to refer to the discrepancy between computed, observed or measured value and the specified value. In other terms errors can be defined as the difference between actual output of software and correct output. Fault – It is a condition that causes a system to fail in performing its required function. Failure – A software failure occurs if the behavior of the software is different from specified behavior. It is a stage when a system becomes unable to perform a required function according to the specification mentioned. Q10) Describe black box testing, also write advantages and disadvantages?A10) Black box testing This technique exercises the input and output domain of the program to uncover errors in program, function, behavior and performance.Software requirements are exercised using “black box” test case design technique.It is done in the later stage of the software development.Black box testing technique attempts to find errors related to:Missing functions or incorrect functions.Errors created due to interfaces.Errors in accessing external databases.Performance related errors.Behavior related errors.Initialization and termination errors.In Black box testing the main focus is on the information domain. Test is designed for following questions:How is functionality validation testing?What class of input will make good test cases?Is the system particularly sensitive to certain input values?How are the boundaries of a data class isolated?What data rates and data volume can the system tolerate?What effects will specific combinations of data have on system operation? Advantages:More effective on larger units of code than glass box testing.Tester needs no knowledge of implementation, including specific programming languages.Tester and programmer are independent of each other.Tests are done from a user's point of view.Will help to expose any ambiguities or inconsistencies in the specifications.Test cases can be designed as soon as the specifications are complete.Disadvantages:Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever.Without clear and concise specifications, test cases are hard to design.There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried.May leave many program paths untested.Cannot be directed toward specific segments of code which may be very complex (and therefore more error prone).Most testing related research has been directed toward glass box testing. Q11) Write about white box testing, also write advantages and disadvantages?A11) White box testing In this testing technique the internal logic of software components is tested.It is a test case design method that uses the control structure of the procedural design test cases.It is done in the early stages of the software development.Using this testing technique software engineer can derive test cases that:All independent paths within a module have been exercised at least once.Exercised true and false both the paths of logical checking.Execute all the loops within there boundaries.Exercise internal data structures to ensure their validity. Advantages:As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively.The other advantage of white box testing is that it helps in optimizing the code.It helps in removing the extra lines of code, which can bring in hidden defects.We can test the structural logic of the software.Every statement is tested thoroughly.Forces test developer to reason carefully about implementation.Approximate the partitioning done by execution equivalence.Reveals errors in "hidden" code.Disadvantages:It does not ensure that the user requirements are fulfilled.As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of testing, which increases the cost.It is nearly impossible to look into every bit of code to find out hidden errors, which may create problems, resulting in failure of the application.The tests may not be applicable in real world situation.Cases omitted in the code could be missed out.

Sign Up