Black Box Testing and White Box Testing - Coursework Example

?Discussions Black Box testing and White Box Testing Black-box test design treats the system as ‘inaccessible’, so it doesn't explicitly use knowledge of the internal structure of the system. There are many advantages to black-box testing like: 1. Ease of use: We simply work through the application, as an end user like will it work on windows platform or not. Will the Start, Exit and Minimize functions work among other functionalities; we came to know that Decimal Point overwriting and Last Function Buffer does not work. 2. Simplicity: We focus on invalid and valid inputs and ensure the correct outputs are received like testing functionalities like Addition, Subtraction and division for larger values and fractional values; we came to know that the Percentage and Subtraction functionality were not working correctly for a lot of values. White-box test design allows one to peek inside the "box", and it focuses specifically on using internal knowledge of the software to guide the selection of test data. There are distinct advantages to white-box testing like: 1. Thoroughness: As such, white-box testing is much more thorough in terms of what percentage of the application we can test. This helped us in finding out that it will overwrite the point character if you first enter it and then enter a number. 2. Stability: Delivers greater stability and reusability of test cases if the objects that comprise an application never change like the calculator whose multiplication is constant but whose exception was not correct. But there’s the flip side of the coin as well and each of these come with a few disadvantages as well. The Black-Box Testing Techniques lack accuracy and despite the ease of use lack thoroughness and it doesn’t look very stable to me. Other disadvantages include the fragility of scripts and lack of introspection that comes with no knowledge of the internal structure. White-Box Testing Techniques also aren’t full proof as they are highly complex and because these are very thorough scripts, integrating them into the system to test is cumbersome as well as error prone in many cases. The test scripts are meant to be tightly tied into the underlying code and any change to the code often causes these scripts to break thus making them very fragile. GUI testing JUnit testing Success of any GUI application depends on how it interacts through its user interface with different users. An application with invalid behavior or incorrect user interaction can lead to large problems. GUI testing is a process to test the application's user interface and to detect if the application is working fine functionally. GUI Testing includes how the application deals with keyboard and mouse events, how different GUI components like menu-bars, tool-bars, dialog-boxes, buttons, entry fields, list navigations, images etc. respond to user input and to ensure that the tasks are performed as desired. The GUI testing can be implemented either manually or through automated methods. Manual testing is often error prone as well as far from exhaustive thus automated approach is preferred. Automated GUI Testing is use of a software program to check if the application is working fine functionally. This includes automating manual testing tasks which are mostly time consuming and error prone. To test a GUI, we needed a good method of finding the components of value, selecting cells in a table, dragging things about, clicking buttons, etc. The events we test are similar to assembly language only these are applicable for GUI testing. What the ideal approach is in describing the expected behavior is that we clarify the developer's goals before penning the code can; this avoids overbuilding useless feature and the correlated feature sets. Below is the required refactoring of the Java calculator program using Test-Driven Development (TDD). There is no possibility of exception in multiplication function so exception part of code can be considered as a dead code and can be removed. Public DivideByZeroExeption(String s), this function can also be considered in dead code. Informal methods and Formal methods After following a systematic procedure for generating consistent and complete collections of test methods for a JUnit test class, I gained some insights about the Formal and Informal methods. Writing informal specifications was easy and yielded sufficiently consistent results. Results show that test classes find more errors in the target class than the simple method we compared it with (writing one test class method for each method in the target class). The JUnit classes were not strictly written according to the simple one-test-method-per-target-method approach; rather, they were supplemented in an ad-hoc fashion with test methods not corresponding directly to any target method. But this approach does not work well for all the classes and we find that some classes lend themselves better to the other approach, that is, the Informal approach. Classes with major algorithmic content, this means that they have a lot of code content and almost negligible GUI interaction with the user. Since the project was Postfix Stack Calculator Program writing Formal methods was quite time-consuming and strenuous for me and seemed to lack responsiveness and flexibility; however, thorough testing is essential for all processes be it the modern approaches such as Xtreme programming techniques or agile development as well as traditional software building techniques. Another issue we have not considered is the impact these support testing methods would have on refactoring. More test methods shall obviously mean more code to alter or to shuffle as I refactored the target classes. It is not clear how difficult refactoring will be at this stage for these tests. Automation can be of help, as such refactored code might be easier to move than full tests; the tests then can be remade after the specs have been replaced correctly in the refactored code. And then we could do an analysis on how to further the efficiency of our tests. The Informal methods and Formal methods are given below: new: int --> BST push: BST x E --> BST pop: BST --> BST top: BST --> E isStackEmpty: BST --> bool isStackFull: BST --> bool maximumSize: BST --> int getSize: BST --> int datatype BST =New of int | push of BST * int ; calc isEmpty (New(n)) = true | isEmpty (push(B,e)) = false ; calc maxSize (New(n)) = n | maximumSize (push(B,e)) = maxSize(B) ; calc getSize (New(n)) = 0 | getSize (push(B,e)) = if getSize(B)=maxSize(B) then maximumSize(B) else getSize(B)+1 ; calc isFull (New(n)) = n=0 | isFull (push(B,e)) = if getSize(B)>=maxSize(B)-1 then true else false ; exception topEmptyStack; calc top (New(n)) = raise topEmptyStack | top (push(S,e)) = if isFull(S) then top(S) else e ; calc pop (New(n)) = New(n) | pop (push(S,e)) = if isFull(S) then pop(S) else S ; In summary, the steps for building a JUnit test class are: 1) Figure out the default method for the target class of the Java class. 2) Figure out which methods follow the canonical notation, and thus subdivide all the methods into 2 categories. 3) Solve the left-hand side of the axioms. This is done by taking the non-canonical methods and cross them on the canonical ones. 4) Write an equals calcaction method that take two elements from the target class and compare them. (This is done to compare two BSTs in our example) 5) Write a test method for each axiom from the left-hand side in the test class, making use of the abstract equals wherever it is befitting in the JUnit assert calls. Sources 1- Black-box vs. White-box Testing: Choosing the Right Approach to Deliver Quality Applications, by Redstone Software. 2- An Informal Formal Method for Systematic JUnit Test Case Generation, by David Stotts, Mark Lindsey, and Angus Antley. Read More