1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 /* Author: ud17 Project Title: Compute Average Grade Description: A students enters 10 grades and the application thereafter the application calculates the average grade. In case the student average grade is less than 70 points then the program prints a message You need extra help from the Professor" otherwise if the average is more than 70 points but less than 80 points, then the program prints "The You are doing a good job". If the student's average is more than 80 points but less than 90, then the program will print "You are doing a great job". For averages more than 90 points, the program will print "You are donig an excellent job, keep it up!" */ import javax.swing.JOptionPane; public class computerAverageGradesFinal { //Begin the main method. public static void main(String[] args) { //Set the averageGrade_NoMaxMin and the feedbackMsg. double averageGrade_NoMaxMin = fillGradesArray(); String feedbackMsg = ""; feedbackMsg = printGradeMsg(averageGrade_NoMaxMin); } //Begin the submethod called, printGradeMs with a parameter of averageGrade_NoMaxMin. public static String printGradeMsg(double averageGrade_NoMaxMin) { //Set the strGrade and the feedbackMsg. String strGrade= ""; String feedbackMsg=""; //Validate the feedbackMsg based on the averageGrade_NoMaxMin. if (averageGrade_NoMaxMin < 70) { feedbackMsg = "You needs extra help from your Professor"; } else if (averageGrade_NoMaxMin > 70 || averageGrade_NoMaxMin 80 || averageGrade_NoMaxMin 90 && averageGrade_NoMaxMin < 100) { feedbackMsg = "You are doing an excellent job, keep it up!!!"; 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 } //Return the feedbackMsg to the main method. return feedbackMsg; } //Begin the second submethod, fillGradesArray. public static double fillGradesArray() { //Set maxArrayLength, index, grade, strGrade, averageGrade_NoMaxMin, and initialize allGradesArray. final int maxArrayLength = 10; int[] allGradesArray = new int[maxArrayLength]; int index = 0; int grade = -1; String strGrade=""; double averageGrade_NoMaxMin = 0.00; //Use try and catch within a do loop and do loop within a for loop to prompt and validate the grade user inputs. for (index = 0; index 100); strGrade = grade+", "+strGrade; allGradesArray[index] = grade; } //Set maxGrade, minGrade, readAllGrades, sumAllGrades, output, strOutput, and feedbackMsg. int maxGrade = allGradesArray[0]; int minGrade = allGradesArray[0]; int readAllGrades; //*** 1 bug missing initialization for variable declaration int sumAllGrades = 0; String feedbackMsg =""; int output = 0; String strOutput =""; 101 102 //Begin a for loop to find the maximum and the minimum values. 103 for (index = 1; index maxGrade) 107 { 108 maxGrade = allGradesArray[index]; 109 110 } 111 else if (allGradesArray[index] < minGrade) 112 { 113 minGrade = allGradesArray[index] 114 } 115 116 //Calculate the sum of all grades. 117 sumAllGrades += grade; 118 119 //Calculate the average grade of all grades with no maximum or minimum values. 120 averageGrade_NoMaxMin = (float) (sumAllGrades - maxGrade - minGrade)/(maxArrayLength - 2); 121 122 } 123 feedbackMsg = printGradeMsg(averageGrade_NoMaxMin); 124 125 //Print the report: strGrade, averageGrade_NoMaxMin, and the feedbackMsg. 126 JOptionPane.showMessageDialog(null,"\nThe grades you entered are: " + strGrade + "\nThe student's average grade wit hout the maximum and the minimum grade is: " + String.format("%.2f", averageGrade_NoMaxMin)+ "\nThe feedback is: "+feedbackMsg); 127 128 //Return the averageGrade_NoMaxMin to the main method. 129 return averageGrade_NoMaxMin 130 131 } 132 } 133 Software Testing, Documentation and Quality Assurance (IT355-A) Week 5 – Examining Code Spring 2018 1 Agenda • Static white-box testing and its benefits • Misconceptions about static white-box testing • Formal Review • Coding standards and guidelines • Generic code review checklist 2 Introduction • Software testing extends beyond examining specifications as well as the techniques we covered in static testing • There are also techniques for testing software architecture and the code • Such techniques require some or limited programming experience • We shall cover the following topics • Benefits of static white box testing • Coding guidelines and standards • Strategies for generically reviewing code for bugs 3 Static white-box testing • Static testing means examining and reviewing software without executing or running it • White box-testing (also called clear testing) • The software tester has read and review the code • Static white-box testing • The process of reviewing software design, architecture or code for bugs without executing it • This process is also called structural analysis 4 Why static white-box testing • Reasons for performing static white-box testing are: • Finding bugs early during the software life cycle • There also bugs which are difficult to find during dynamic black-box testing • Advantages for static white-box testing • Derive better black-box testing test cases from the underlying software logic or architecture • Obtain great ideas on good test cases for dynamic white-box testing by listening to the review comments • Review comments may also give insight on the potential problem areas for finding bugs 5 Misconceptions about static white-box testing • Software testing teams often do not perform static white box testing due to the following misconceptions • It is time consuming • It is costly • It is unproductive • The source of the problem for these misconceptions has usually been that software engineers/programmers are hired to write software and any other additional tasks simply slows down their roles 6 Formal Review • This is an established process for performing static white-box testing • Involves rigorous inspection of software architecture or its code. • Composition of the formal review may range from a small team of programmers to several individuals 7 Elements of a formal review • Identification of problems • Following rules • Preparation • Report writing 8 Identification of problems • The ultimate goal is to find problems with the software with • All critique should be constructive and directed at the design or code but not the developers • All participants in this session should behave professionally and not take criticisms personally 9 Following rules • A fixed set of rules have to be followed to scope the volume of work • Some of the rules may be: • • • • Amount of code to be reviewed i.e. number of lines Amount of time effort that will be invested in the exercise in hours What should be reviewed Description of the roles that will be performed by the individuals in the team 10 Preparation • Every participant should actively contribute to the review • Participants need to prepare and also know the their duties and responsibilities in the review • Participants need to be committed to the review 11 Report writing • The main deliverable of a formal review is a written report that summarizes the results of the findings • How many problems were found • Where the problems where found • etc. • The report should be availed to the product development team 12 Benefits of formal reviews • Communication • Quality • Team camaraderie • Solutions 13 Communication • The team will get informal feedback which may not be included in the report e.g. • Insight in the source of bugs that were discovered during black box testing • Inexperienced programs learn new techniques from more experienced software developers • Management can tell whether the software project is on schedule 14 Quality • A programmer will be more cautious when writing code because his or her code will be scrutinized in detail (i.e. line by line, module by module) • The programmer invest more time in double checking his or her code of any careless mistakes 15 Team camaraderie • A formal review presents opportunities for testers and developers to bond • Testers and developers can appreciate and rest each other’s skills, jobs and job needs 16 Solutions • During the review, the team may find solutions for difficult problems • The rules defined at the beginning of the review will determine • if solutions can be discussed in the review to resolve difficult problems • If solutions can be discussed outside the review 17 How do you establish a formal review? • There are different approaches for setting up formal reviews • These include: • Peer reviews • Walkthroughs • Inspections 18 Peer reviews • Peer reviews are informal and the best way of putting a team together for a formal review • Programmers present their code to their testers, who act as reviewers to improve the code • Although informal, the peer review is governed by a set of 4 rules to obtain results: • • • • Finding problems and omissions in the software Following rules established at the beginning of the formal review Preparing the for the review Preparing a report with findings 19 Walkthroughs • This the next step in the peer review • There are more participants in a walkthrough compared to a peer review • Programmers formally present their code to a group comprising other programmers (including a senior programmer) and testers • Programmers should send their code in advance before the presentation so that: • The team takes time to study it • Prepare comments and questions 20 Walkthroughs • How programmers present their code? • Programmers will read through the code: • line by line • Module by module (or function by function) • Explaining design decisions of what the code does and how • Reviewers raise question when they seek anything suspicious • The presenter prepares a report on the findings and how the identified problems will be fixed 21 Inspections • These are the most formal type of reviews • Unlike peer reviews and walkthroughs, • the code is presented by someone else but not the programmer who wrote it • All the other participants are inspectors • This forces potential presenters to learn and understand the material to be presented 22 Inspections • Inspectors perform the following tasks • Reviewing the code from different perspectives as users, testers and software support/maintenance engineers • An inspector will be tasked to review the code backwards from end to start • There will be an inspector tasked to moderate the session ensure that rules are adhered to and inspection 23 Inspections • After the inspection meeting • Inspectors can meet again to followup the discussions on problems found • The programmers present progress made on effecting changes and recommendations • The moderator verifies the effected changes • Another inspection may be scheduled depending on criticality of the software 24 Coding standards and guidelines • The code may be working properly but is not written to meet a specific standard or guideline • This is similar to writing words that convey a message but sentences are grammatically wrong • Standards • define rules of do’s and don’ts • Established and fixed • Guidelines • Best practices on the preferred way of doing things 25 Reasons for adhering to standards and guidelines • Reliability • Code is more reliable and secure code • Readability/Maintainability • Code is easier to read, understand and maintain • Portability • Software may be deployed to different platforms i.e. hardware or OS if standards and guidelines are followed 26 Obtaining Standards • When working on a project that must follow standards, there are several sources to obtain them • You can obtain national and international standards from: • • • • American National Standards Institute (ANSI), www.ansi.org International Engineering Consortium (IEC), www.iec.org International Organization for Standardization (ISO), www.iso.ch National Committee for Information Technology Standards (NCITS), www.ncits.org 27 Generic Code Review Checklist • When performing static white-box testing, this is a checklist types of errors to look for • • • • • • • Data reference errors Data declaration errors Computation errors Comparison errors Control flow errors Sub-routine parameter errors Input/Output errors 28 Data reference errors • These are errors arising from using a variable, constant, array, string or record that has not been properly declared • Is the uninitialized variable reference? • Is the variable assigned to value of a different data type? • Are array and string subscript integer values within boundaries of the array or string’s dimensions? • Is garbage collection properly handled to manage memory? 29 Data declaration errors • These bugs are caused by improperly declaring and using variables and constants • Are variables assigned the correct length, type or storage class? • For the variables that declared and initialized, are they assigned the values of the right type? • Are there variables with similar names? 30 Computation errors • These bugs arise from calculation errors • Do calculations that use variables have operands of different data types? • Do calculations that use variables of the same data type have different lengths? • Is it possible for the divisor or modulus to be zero? • For calculations that use multiple operators, is there confusion in operator precedence? Can parentheses be used for clarification? 31 Comparison errors • Comparison operations are susceptible to boundary condition problems • Are the comparisons correct? • Do comparisons between fractional and floating pointing point values exist? • e.g Is 1.0001 equal to 1.0002? • Are Boolean expressions correctly stated and work as expected? • Are operands in the Boolean expression, Boolean? Or are you using integer values like 1 and 0 for Boolean operands? 32 Control flow errors • These arise from loops and other control flow consults in the software which do not behave as expected • Is the do … while looping construct giving the expected results or should other looping constructs be considered? • Will the program module or function containing a loop terminate? • Does the loop terminate prematurely? • Is there possibility that loop never executes? • Are branching constructs executing conditions as expected? 33 Sub-routine parameter errors • These are errors that arise from passing in correct data to and from a module or function in software • Do the data types and sizes of the parameters passed to a module or function math those of the calling code? • Are the parameters passed in the correct order? • If constants are passed as parameters, are they accidentally changed? • If global variables exist, do they have consistent definitions and attributes in all referencing modules or functions? 34 Input and Output Errors • These are errors that arise from reading files or accepting input for devices like keyboards and mice and writing to output devices like printers and screens • If a file being read from is not present, is there an error condition to handle that situation? • Are files being read from try .. catch block to contain exceptions or unforeseen when opening and reading data from them? • Are files and database connections properly closed and memory resources freed after obtaining the data from them • Have all error messages been checked for correctness and appropriateness including grammar and spelling? 35 Other checks • Will software work with other languages other than English? • Does software handle extended ASCII characters? • Will the software need to use Unicode (e.g. UTF8) instead of ASCII? • When compiling the software, are warnings or information messages generated? 36 Conclusion • We have looked at examining code with respect to static white-box testing • This process in software testing requires a great deal of preparation as well as checking the software using standards and guidelines. 37 Q&A 38
Purchase answer to see full attachment