Just had a question on my C++ homework, and working with a Black-Box From my understanding, you read and understand the code and then work to discover bugs and fill in the charts. Here is the notes on black box. Here is the solution table

Assignment 3 Solution Template

Fill in the information for each test that you develop for the 4 tables below. Add more rows as required to list all possible tests for each type. Do not repeat tests which have already been used to test a particular description. Use as many rows as needed to capture all of your tests. Each of the four tables may span more than one page if necessary.

Special Values Tests
Test #	Test Description	Test Data	Expected Result	Actual Result	Pass/Fail
1	Handling of empty spaces	first word: second word:	Low similarity, F grade	60% similarity, D grade	Fail

Black-Box Testing 1 Testing In this lesson, we explore how to do a thorough job of testing your programs. If you've ever submitted a programming assignment that you thought was Ok and then been surprised to receive a poor grade for it, then it's a pretty good bet that the instructor had done a more rigorous job of testing your code than you had. In the professional world, testing and debugging typically take far more time than actually writing the code. They may amount to as much as half the total development time with the requirements analysis, design, and coding taking up the remainder. As a professional, it will be a mark of your professionalism and a factor in your company's reputation to catch bugs before the software is released. As a student, it's a matter of self-interest to do a good job of testing your code if you hope to get good grades. Why do we test? To detect flaws in the software (but what if we don't find any?) To gain confidence as to whether or not the system is usable . 1.1 Defintitions Testing and Debugging Testing is the act of executing a program with selected data to uncover bugs. As opposed to debugging, which is the process of finding the faulty code responsible for failed tests. In practical terms, we don't start debugging until we know that something is wrong. How do we find out that something is wrong? Hopefully, we failed one of our own tests. If that's not how we found out, it's probably because someone using our software reported a bug. That, of course, makes us look bad. And if someone else reported the bug, then before we can start debugging we have to figure out how to reproduce the bug, which means we are right back to testing, trying to find test data that reveal the bug so that we can figure out what's causing it. Failures, Faults, and Errors A failure is an execution of a program on which incorrect output was obtained. A fault is a defect in the code that could lead to failures. An error refers to either A defect in the output produced by a program A mistake made by the software developer that resulted in a fault. Test Cases and Suites A test case is a description of a set of test inputs developed for a particular objective. Could be so detailed as to give the actual input data, but often simply describes the desired input data. A test suite is a collection of test cases. 1.2 Choosing Test Data Strategies for Choosing Tests Testing traditionally can be conducted in three styles Black-Box testing Try to choose "smart" tests based on the requirements, without looking at the code. White Box testing Try to choose "smart" tests based on the structure of the code, with minimal reference to the requirements. Random testing Try to use directed random selection to choose tests that are "representative of how the program will be used. We'll discuss the black-box testing of these today and white-box later this semester. Random testing is not used as often. It sometimes is useful as a way check against unwarranted assumptions by the developers and testers ("Oh, I never thought of even trying that!"). But its primary use is in large projects where statistics collected during random testing are plugged into models that are used to predict how reliable the software will be if released in its current state or how much longer we will need to test before we reach a desired level of reliability. 2 Black Box Testing Black-Box Techniques There are a number of well-known BB strategies. Representative Inputs Functional Coverage Boundary-Values Testing Special-Values Testing A good test BB suite will include all of these. In fact, these should become second nature to most programmers. 2.1 Representative Inputs Representative Inputs Choose at least one test that is a "typical" input to the system when in real use. This may require some study of how people will use the system. If you are replacing an existing system, or automating a task that people have been doing manually, you may be able to collect "real" inputs. Example: the Auction Program What would we use as "typical" or "representative" inputs to our auction program? Well, the auction program description contains some sample input, and that's certainly worth using, but it's really not clear how representative that's intended to be. But there's also mention of existing auction systems, so we might try to collect some sample sessions from some of those. Test Specifications Software development projects manage testing via a couple of standard documents: . A test plan is a document describing what will be tested, who will do it, and the procedures they will follow. A test case specification or test specification describes the test cases for an item to be tested. These are often confused with one another. O Test plans are for management. o Test specs are for the software developers. We'll demonstrate the development of a test specification document, following (roughly) the format of the IEEE 829 Standard for Software and System Test Documentation. Starting the Auction Program Test Spec 1. Module Overview The auction program resolves bids received at an online auction site. 1.1 Inputs Three files, one describing the items up for bid on a single day, another describing the registered bidders, a third describing bids received 1.2 Outputs List of auction winners, written to standard output. 2. Test Data Representative Input 1. At least one typical input as described in the requirements document. That last item is our first test case. 2.2 Functional Coverage This is a bit of a misnomer. the "function" in "Functional Coverage" has nothing to do with the idea of a C++ function. Instead it really pertains more to "functionality". If you look though most program requirements, you'll see that the program is probably supposed to carry out a variety of different behaviors under various circumstances. Sometimes these behaviors are described in terms of input conditions: For any input x, if x = 0, return x but if x 0 and x 0 behavior O An extremely large negative number and x = -1: the boundaries of the x Similarity: 77% Score: C Continue (Y/N): N As: Bs: Cs: C Ds: Fs: You must design a complete Black-Box testing plan for the program described. Your task is to apply what you have learned about black-box testing techniques to develop a full suite of test data for this program. Use the template file provided in the Instructions and supporting files on BlackBoard to organize your tests and test data. Fill in the information for each test that you develop for the 4 tables You must design a complete Black-Box testing plan for the program described. Your task is to apply what you have learned about black-box testing techniques to develop a full suite of test data for this program. Use the template file provided in the Instructions and supporting files on BlackBoard to organize your tests and test data. Fill in the information for each test that you develop for the 4 tables (representative input, functional coverage, boundary values, and special values). Please note that you will need to add more rows as you might need to list all possible test cases for each type. Do not repeat tests which have already been used to test a particular description. Use as many rows as needed to capture all of your tests. Each of the four tables may span more than one page if necessary. #include #include using namespace std; /* * Responsible for calculating the similarity between two strings using the Levenshtein distance metric *// info: https://en.wikipedia.org/wiki/Levenshtein distance * // credit to: http://rosettacode.org/wiki/Levenshtein_distance * @param 51: first candidate string for similarity test * @param 52: second candidate string for similarity test * @param return: numeric measure of distance size_t uiLevenshteindistance(const string &si, const string &s2) const size_t m(s1.size(); const size_t n(s2.size(); if( M==0) return n; if(n==0) return m; size_t *costs = new size_t[n + 1]; for( size_t k=e; k= 90 ) return 'A'; else if( score >= 30 ) return 'B'; else if( score >= 70 ) return 'c'; else if( score >= 60 ) return 'D'; return 'F'; * Responsible for printing ad chart of letter grades */ void printchart(string chart[]) for(int i = e; i maxWordLength ) maxwordLength = secondword.length(); levenshteinscore = uiLevenshteindistance(firstword, secondword); cout " " > firstword; cin.ignore(); }while(firstWord!="Y" && firstword!="N"); if( firstword == "N") cout > firstword; cin.ignore(); }while(firstword!="Y" && firstword !="N"); if( firstWord == "N") cout 0 and x 0 behavior O An extremely large negative number and x = -1: the boundaries of the x Similarity: 77% Score: C Continue (Y/N): N As: Bs: Cs: C Ds: Fs: You must design a complete Black-Box testing plan for the program described. Your task is to apply what you have learned about black-box testing techniques to develop a full suite of test data for this program. Use the template file provided in the Instructions and supporting files on BlackBoard to organize your tests and test data. Fill in the information for each test that you develop for the 4 tables You must design a complete Black-Box testing plan for the program described. Your task is to apply what you have learned about black-box testing techniques to develop a full suite of test data for this program. Use the template file provided in the Instructions and supporting files on BlackBoard to organize your tests and test data. Fill in the information for each test that you develop for the 4 tables (representative input, functional coverage, boundary values, and special values). Please note that you will need to add more rows as you might need to list all possible test cases for each type. Do not repeat tests which have already been used to test a particular description. Use as many rows as needed to capture all of your tests. Each of the four tables may span more than one page if necessary. #include #include using namespace std; /* * Responsible for calculating the similarity between two strings using the Levenshtein distance metric *// info: https://en.wikipedia.org/wiki/Levenshtein distance * // credit to: http://rosettacode.org/wiki/Levenshtein_distance * @param 51: first candidate string for similarity test * @param 52: second candidate string for similarity test * @param return: numeric measure of distance size_t uiLevenshteindistance(const string &si, const string &s2) const size_t m(s1.size(); const size_t n(s2.size(); if( M==0) return n; if(n==0) return m; size_t *costs = new size_t[n + 1]; for( size_t k=e; k= 90 ) return 'A'; else if( score >= 30 ) return 'B'; else if( score >= 70 ) return 'c'; else if( score >= 60 ) return 'D'; return 'F'; * Responsible for printing ad chart of letter grades */ void printchart(string chart[]) for(int i = e; i maxWordLength ) maxwordLength = secondword.length(); levenshteinscore = uiLevenshteindistance(firstword, secondword); cout " " > firstword; cin.ignore(); }while(firstWord!="Y" && firstword!="N"); if( firstword == "N") cout > firstword; cin.ignore(); }while(firstword!="Y" && firstword !="N"); if( firstWord == "N") cout