White-box testing. White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing).
In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT). While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Unit testing. In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures are tested to determine if they are fit for use.[1] Intuitively, one can view a unit as the smallest testable part of an application.
In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. In object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method.[2] Unit tests are short code fragments[3] created by programmers or occasionally by white box testers during the development process. Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects,[4] fakes, and test harnesses can be used to assist testing a module in isolation.
System testing. System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements.
System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. [1] As a rule, system testing takes, as its input, all of the "integrated" software components that have passed integration testing and also the software system itself integrated with any applicable hardware system(s).
The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together (called assemblages) or between any of the assemblages and the hardware. Stress testing. Stress testing (sometimes called torture testing) is a form of deliberately intense or thorough testing used to determine the stability of a given system or entity.
It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. Reasons can include: to determine breaking points or safe usage limitsto confirm intended specifications are being metto determine modes of failure (how exactly a system fails)to test stable operation of a part or system outside standard usage Reliability engineers often test items under expected stress or even under accelerated stress in order to determine the operating life of the item or to determine modes of failure.[1] Software performance testing. Performance testing is a subset of performance engineering, an emerging computer science practice which strives to build performance into the implementation, design and architecture of a system.
Scenario testing. History[edit] Kaner coined the phrase scenario test by October 2003.[1] He commented that one of the most difficult aspects of testing was maintaining step-by-step test cases along with their expected results.
His paper attempted to find a way to reduce the re-work of complicated written tests and incorporate the ease of use cases.[1] A few months later, Buwalda wrote about a similar approach he had been using that he called "soap opera testing". Like television soap operas these tests were both exaggerated in activity and condensed in time.[2] The key to both approaches was to avoid step-by-step testing instructions with expected results and instead replaced them with a narrative that gave freedom to the tester while confining the scope of the test.[3]
Regression testing. The intent of regression testing is to ensure that a change such as those mentioned above has not introduced new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2] Common methods of regression testing include rerunning previously completed tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged.
Regression testing can be performed to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change. Background[edit] Experience has shown that as software is fixed, emergence of new and/or reemergence of old faults is quite common. Sometimes reemergence occurs because a fix gets lost through poor revision control practices (or simple human error in revision control). Integration testing. Purpose[edit] The purpose of integration testing is to verify functional, performance, and reliability requirements placed on major design items.
These "design items", i.e. assemblages (or groups of units), are exercised through their interfaces using black box testing, success and error cases being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas and inter-process communication is tested and individual subsystems are exercised through their input interface. Black-box testing. Black box diagram Black-box testing is a method of software testing that examines the functionality of an application (e.g. what the software does) without peering into its internal structures or workings (see white-box testing).
This method of test can be applied to virtually every level of software testing: unit, integration, system and acceptance. It typically comprises most if not all higher level testing, but can also dominate unit testing as well. [citation needed] Test procedures[edit] Specific knowledge of the application's code/internal structure and programming knowledge in general is not required. Test cases[edit] Test cases are built around specifications and requirements, i.e., what the application is supposed to do. Functional testing. Functional testing is a quality assurance (QA) process[1] and a type of black box testing that bases its test cases on the specifications of the software component under test.
Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered (not like in white-box testing).[2] Functional Testing usually describes what the system does. Six steps[edit] Functional testing typically involves six steps[citation needed] The identification of functions that the software is expected to performThe creation of input data based on the function's specificationsThe determination of output based on the function's specificationsThe execution of the test caseThe comparison of actual and expected outputsTo check whether the application works as per the customer need. Performance testing. Manual testing. Compare with Test automation.
Manual testing is the process of manually testing software for defects. It requires a tester to play the role of an end user, and use most of all features of the application to ensure correct behavior. To ensure completeness of testing, the tester often follows a written test plan that leads them through a set of important test cases. Overview[edit] A key step in the process is, testing the software for correct behavior prior to release to end users. For small scale engineering efforts (including prototypes), exploratory testing may be sufficient. Large scale engineering projects that rely on manual software testing follow a more rigorous methodology in order to maximize the number of defects that can be found. Graphical user interface testing. GUI Testing Checklist. Click here to view the complete list of archived articles This article was originally published in the Spring 2000 issue of Methods & Tools GUI Testing Checklist Barry Section 1 - Windows Compliance Standards 1.1.
Section 2 - Tester's Screen Validation Checklist 2.1. Section 3 - Validation Testing - Standard Actions 3.1. 1. For Each Application Start the application by double clicking on its icon. No login is necessary. The main window of the application should have the same caption as the caption of the icon in Program Manager. Closing the application should result in an "Are you Sure" message box. Attempt to start application twice. Try to start the application twice as it is loading. On each window, if the application is busy, then the hour glass should be displayed.