Software coding & testing, software engineering

  • Published on

  • View

  • Download

Embed Size (px)


<ul><li><p>Unit-6Software Coding &amp; Testing</p></li><li><p>Coding PhaseCoding is undertaken once design phase is complete. During coding phase:every module identified in the design document is coded and unit tested. Unit testing :testing of different modules of a system in isolation.</p></li><li><p>Unit TestingWhy test each module in isolation first?then integrate the modules and again test the set of modules?why not just test the integrated set of modules once thoroughly?</p></li><li><p>Unit TestingIt is a good idea to test modules in isolation before they are integrated:it makes debugging easier.</p></li><li><p>If an error is detected when several modules are being tested together, it would be difficult to determine which module has the error.Another reason:the modules with which this module needs to interface may not be ready. Unit Testing</p></li><li><p>Integration TestingAfter all modules of a system have been coded and unit tested:integration of modules is doneaccording to an integration plan.</p></li><li><p>Integration TestingThe full product takes shape: only after all the modules have been integrated.Modules are integrated together according to an integration plan: involves integration of the modules through a number of steps. </p></li><li><p>Integration TestingDuring each integration step, a number of modules are added to the partially integrated system and the system is tested. Once all modules have been integrated and tested, system testing can start. </p></li><li><p>System TestingDuring system testing:the fully integrated system is tested against the requirements recorded in the SRS document. </p></li><li><p>CodingThe input to the coding phase is the design document. During coding phase: modules identified in the design document are coded according to the module specifications. </p></li><li><p>CodingAt the end of the design phase we have:module structure (e.g. structure chart) of the systemmodule specifications: data structures and algorithms for each module. Objective of coding phase:transform design into code unit test the code.</p></li><li><p>Coding StandardsGood software development organizations require their programmers to:adhere to some standard style of coding called coding standards. </p></li><li><p>Coding StandardsMany software development organizations: formulate their own coding standards that suits them most, require their engineers to follow these standards rigorously.</p></li><li><p>Coding StandardsAdvantage of adhering to a standard style of coding:it gives a uniform appearance to the codes written by different engineers, it enhances code understanding, encourages good programming practices.</p></li><li><p>Coding StandardsA coding standard sets out standard ways of doing several things:the way variables are named, code is laid out, maximum number of source lines allowed per function, etc. </p></li><li><p>Coding guidelinesProvide general suggestions regarding coding style to be followed:leave actual implementation of the guidelines: to the discretion of the individual engineers.</p></li><li><p>Code inspection and code walk throughsAfter a module has been coded, code inspection and code walk through are carried out ensures that coding standards are followed helps detect as many errors as possible before testing. </p></li><li><p>Code inspection and code walk throughsDetect as many errors as possible during inspection and walkthrough:detected errors require less effort for correction much higher effort needed if errors were to be detected during integration or system testing. </p></li><li><p>Representative Coding StandardsRules for limiting the use of globals:what types of data can be declared global and what can not. Naming conventions for global variables, local variables, and constant identifiers.</p></li><li><p>Representative Coding StandardsHeader data:Name of the module, date on which the module was created, author's name, modification history,synopsis of the module, different functions supported, along with their input/output parameters, global variables accessed/modified by the module.</p></li><li><p>Representative Coding StandardsError return conventions and exception handling mechanisms.the way error and exception conditions are handled should be standard within an organization. For example, when different functions encounter error conditionsshould either return a 0 or 1 consistently.</p></li><li><p>Representative Coding GuidelinesDo not use too clever and difficult to understand coding style.Code should be easy to understand. Many inexperienced engineers actually take pride:in writing cryptic and incomprehensible code. </p></li><li><p>Representative Coding GuidelinesClever coding can unclear meaning of the code: hampers understanding.makes later maintenance difficult. Avoid obscure side effects.</p></li><li><p>Representative Coding GuidelinesThe side effects of a function call include:modification of parameters passed by reference, modification of global variables, I/O operations. An obscure side effect:one that is not obvious from a casual examination of the code. </p></li><li><p>Representative Coding GuidelinesObscure side effects make it difficult to understand a piece of code. For example, if a global variable is changed obscurely in a called module, it becomes difficult for anybody trying to understand the code.</p></li><li><p>Representative Coding GuidelinesDo not use an identifier (variable name) for multiple purposes.Programmers often use the same identifier for multiple purposes. For example, some programmers use a temporary loop variable also for storing the final result. </p></li><li>Example use of a variable for multiple purposesfor(i=1;i</li><li><p>Use of a variable for multiple purposesThe justification given by programmers for such use: memory efficiency:e.g. three variables use up three memory locations, whereas the same variable used in three different ways uses just one memory location. </p></li><li><p>Use of a variable for multiple purposesThere are several things wrong with this approach:hence should be avoided. Each variable should be given a name indicating its purpose:This is not possible if an identifier is used for multiple purposes. </p></li><li><p>Use of a variable for multiple purposesLeads to confusion and annoyance for anybody trying to understand the code.Also makes future maintenance difficult.</p></li><li><p>Representative Coding GuidelinesCode should be well-documented. Rules of thumb: on the average there must be at least one comment line for every three source lines.The length of any function should not exceed 10 source lines.</p></li><li><p>Representative Coding GuidelinesLengthy functions:usually very difficult to understandprobably do too many different things.</p></li><li><p>Representative Coding GuidelinesDo not use goto statements.Use of goto statements: make a program unstructuredmake it very difficult to understand.</p></li><li><p>Code Walk ThroughAn informal code analysis technique. undertaken after the coding of a module is complete. A few members of the development team select some test cases:simulate execution of the code by hand using these test cases.</p></li><li><p>Code InspectionFor instance, consider:classical error of writing a procedure that modifies a formal parameter while the calling routine calls the procedure with a constant actual parameter. It is more likely that such an error will be discovered: by looking for this kind of mistakes in the code, rather than by simply hand simulating execution of the procedure. </p></li><li><p>Code InspectionGood software development companies: collect statistics of errors committed by their engineers identify the types of errors most frequently committed. A list of common errors:can be used during code inspection to look out for possible errors.</p></li><li><p>Commonly made errorsUse of uninitialized variables.Nonterminating loops. Array indices out of bounds.Incompatible assignments.Improper storage allocation and deallocation.Actual and formal parameter mismatch in procedure calls. Jumps into loops.</p></li><li><p>Code InspectionUse of incorrect logical operators or incorrect precedence among operators.Improper modification of loop variables.Comparison of equality of floating point values, etc.Also during code inspection, adherence to coding standards is checked.</p></li><li><p>Testing Tactics</p></li><li><p>Psychology of TestingTest cases are designed to detect errors but does not guarantee that all possible error get detected.There is no standard method for selecting test cases.Selection of test cases is an art.One of the reason why organization is not selecting developer as a tester is depend upon human psychology.</p></li><li><p>Project Testing FlowUnit TestingIntegration TestingSystem TestingUser Acceptance Testing</p></li><li><p>Levels of Testing</p></li><li><p>Testing ProcessTesting is carried out at the till later stage of s/w development.Testing is also necessary even after release of product.Therefore testing is considered as the COSTLIEST activity in s/w devp. &amp; should be done efficiently.</p></li><li><p>Testing PrinciplesAll tests should be traceable to customer requirements.Tests should be planned long before testing begins.The Pareto principle applies to software testing.Testing should begin in the small and progress toward testing in the large.Complete testing is not possible.To be most effective, testing should be conducted by an independent third party.</p></li><li><p>Software TestabilityS/w testability is simply how easily system or program or product can be tested. Testing must exhibit set of characteristics that achieve the goal of finding errors with a minimum of effort.</p><p>Characteristics of s/w Testability:Operability - The better it works, the more efficiently it can be testedRelatively few bugs will block the execution of tests.Allowing testing progress without fits and starts.</p></li><li><p>Observability - "What you see is what you test. Distinct output is generated for each input.System states and variables are visible or queriable during execution.Incorrect output is easily identified.Internal errors are automatically detected &amp; reported.Source code is accessible.Controllability - "The better we can control the software, the more the testing can be automated and optimized.Software and hardware states and variables can be controlled directly by the test engineer.Tests can be conveniently specified, automated, and reproduced.Decomposability - By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting.Independent modules can be tested independently.</p></li><li><p>Simplicity - The less there is to test, the more quickly we can test it."Functional simplicity (e.g., the feature set is the minimum necessary to meet requirements).Structural simplicity (e.g., architecture is modularized to limit the propagation of faults).Code simplicity (e.g., a coding standard is adopted for ease of inspection and maintenance).Stability - "The fewer the changes, the fewer the disruptions to testing."Changes to the software are infrequent.Changes to the software are controlled.Changes to the software do not invalidate existing tests.Understandability "The more information we have, the smarter we will test."Dependencies between internal, external, and shared components are well understood.Changes to the design are communicated to testers.Technical documentation is instantly accessible, well organized, specific and detailed, and accurate.</p></li><li><p>Test Case DesignSpecifies </p><p>how to carry out testing process?Which unit need to be tested?What are the tools that can used for testing?</p></li><li><p>Test Case Specification</p><p>Test Case IDTest Case NameTest Case DescriptionTest StepsStatus(pass/fail)Test PriorityDefect Severity</p></li><li><p>Taxonomy of TestingThere are two general approaches of testing</p><p>Black Box TestingWhite Box Testing</p></li><li><p>Black-box testingFunctional testing approach focuses on application externals. We can call it as Requirements-based or Specifications-based.Characteristics: </p><p>Functionality Requirements, use, standards Correctness Does system meet business requirements </p></li><li><p>Black-box testingType of Test during Black Box Approach:</p><p>System Testing Acceptance Testing</p></li><li><p>Black box testingAlso called behavioral testing, focuses on the functional requirements of the software.It enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program.Black-box testing is not an alternative to white-box techniques but it is complementary approach.Black-box testing attempts to find errors in the following categories:Incorrect or missing functions,Interface errors,Errors in data structures or external data base access.Behavior or performance errors,Initialization and termination errors.</p></li><li><p>Black-box testing purposely ignored control structure, attention is focused on the information domain. Tests are designed to answer the following questions:How is functional validity tested?How is system behavior and performance tested?What classes of input will make good test cases?By applying black-box techniques, we derive a set of test cases that satisfy the following criteriaTest cases that reduce the number of additional test cases that must be designed to achieve reasonable testing (i.e minimize effort and time)Test cases that tell us something about the presence or absence of classes of errorsBlack box testing methodsGraph-Based Testing MethodsEquivalence partitioningBoundary value analysis (BVA)Orthogonal Array Testing </p></li><li><p>White Box TestingStructural testing approach focuses on application internals. We can call it as Program-basedCharacteristics: </p><p>Implementation Do modules meet functional and design specifications? Do program structures meet functional and design specifications? How does the program work</p></li><li><p>White box testingWhite-box testing of software is predicated on close examination of procedural detail.Logical paths through the software are tested by providing test cases that exercise specific sets of conditions and/or loops.The "status of the program" may be examined at various points.White-box testing, sometimes called glass-box testing, is a test case design method that uses the control structure of the procedural design to derive test cases.</p></li><li><p>White box testingUsing this method, SE can derive test cases that Guarantee that all independent paths within a module have been exercised at least onceExercise all logical decisions on their true and false sides,Execute all loops at their boundaries and within their operational boundsExercise internal data structures to ensure their validity.</p></li><li><p>White Box TestingType of Test during White Box Approach:</p><p>Unit TestingIntegration Testing</p></li><li><p>Validation and Verification V &amp; VValidationAre we building the right product?VerificationAre we building the product right?TestingInspectionStatic analysis</p></li><li><p>Verification and ValidationTesting is one element of a broader topic that is often referred to as verification and validation (V&amp;V).Verification refers to the set of activities that ensure that software correctly implements a specific function.Validation refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.State another way:Verification: "Are we building the product right?"Validation: "Are we building the right product?The definition of V&amp;V encompasses many of the activities that are similar to software quality assurance (SQA).</p></li><li><p>Test CasesKey elements of a test planMay include scripts, data, checklistsMay map to a Requirements Coverage MatrixA traceability tool</p></li><li><p>Testing Strategies</p></li><li><p>S...</p></li></ul>