Solved by verified expert:Required:Inspect the code and identify bugs in the software. Give a short description of the bug, its location (i.e. use line
numbers), bug category (Which you can find it in the power point slides I attached)document your findings using power slides.
computeraveragegradesfinal.pdf
lecture_5a.pptx
Unformatted Attachment Preview
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)
{
feedbackMsg = "You are doing a good job.";
}
else if (averageGrade_NoMaxMin > 80 || averageGrade_NoMaxMin <90)
{
feedbackMsg = "You are doing a great job!";
}
else if (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 <= (maxArrayLength); index++)
{
do
{
//Validate user inputs.
try {
grade = JOptionPane.showInputDialog("Please enter grade(0-100), #"+(index+1)+": ");
}
catch (NumberFormatException e)
{
grade = -1;
JOptionPane.showMessageDialog(null, "ERROR! Enter a grade between 0 and 100");
}
}
while(grade < 0 || grade > 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 <= (maxArrayLength); index++)
104
{
105
grade=allGradesArray[index];
106
if (allGradesArray[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
