5.8 KiB
| title | chunk | source | category | tags | date_saved | instance |
|---|---|---|---|---|---|---|
| Software testing tactics | 2/5 | https://en.wikipedia.org/wiki/Software_testing_tactics | reference | science, encyclopedia | 2026-05-05T08:04:31.188122+00:00 | kb-cron |
==== Visual testing ==== The aim of visual testing is to provide developers with the ability to examine what was happening at the point of software failure by presenting the data in such a way that developers can easily find the required information, and the information is expressed clearly. At the core of visual testing is the idea that showing someone a problem (or a test failure), rather than just describing it, greatly increases clarity and understanding. Visual testing therefore requires the recording of the entire test process – capturing everything that occurs on the test system in video format. Output videos are supplemented by real-time tester input via picture-in-a-picture webcam and audio commentary from microphones. Visual testing provides a number of advantages. The quality of communication is increased drastically because testers can show the problem (and the events leading up to it) to the developer as opposed to just describing it, eliminating the need to replicate test failures in many cases. Developers obtain all necessary evidence of a test failure and can instead focus on identifying and fixing its root cause. Visual testing is particularly well-suited for environments that deploy agile methods in their development of software, since agile methods require closer cooperation between testers and developers, as well as collaboration within small teams. Ad hoc testing and exploratory testing are important methodologies for checking software integrity, because they require less preparation time to implement, while the important bugs can be found quickly. In ad hoc testing, where testing takes place in an improvised, impromptu way, the ability of a test tool to visually record everything that occurs on a system becomes very important in order to document the steps taken to uncover the bug. Visual testing is gathering recognition in customer acceptance and usability testing, because the test can be used by many individuals involved in the development process. For the customer, it becomes easy to provide detailed bug reports and feedback, and for program users, visual testing can record user actions on screen, as well as their voice and image, to provide a complete picture at the time of software failure for the developers.
=== Grey-box testing ===
Grey-box testing (American spelling: gray-box testing) involves having knowledge of internal data structures and algorithms for purposes of designing tests, while executing those tests at the user, or black-box level. The tester is not required to have full access to the software's source code. Manipulating input data and formatting output do not qualify as grey-box, because the input and output are clearly outside of the "black box" that we are calling the system under test. This distinction is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. However, tests that require modifying a back-end data repository such as a database or a log file does qualify as grey-box, as the user would not normally be able to change the data repository in normal production operations. Grey-box testing may also include reverse engineering to determine, for instance, boundary values or error messages. By knowing the underlying concepts of how the software works, the tester makes better-informed testing choices while testing the software from outside. Typically, a grey-box tester will be permitted to set up an isolated testing environment with activities such as seeding a database. The tester can observe the state of the product being tested after performing certain actions such as executing SQL statements against the database and then executing queries to ensure that the expected changes have been reflected. Grey-box testing implements intelligent test scenarios, based on limited information. This will particularly apply to data type handling, exception handling, and so on.
== Automated testing ==
Many programming groups are relying more and more on automated testing, especially groups that use test-driven development. There are many frameworks to write tests in, and continuous integration software will run tests automatically every time code is checked into a version control system. While automation cannot reproduce everything that a human can do (and all the ways they think of doing it), it can be very useful for regression testing. However, it does require a well-developed test suite of testing scripts in order to be truly useful.
=== Automated testing tools === Program testing and fault detection can be aided significantly by testing tools and debuggers. Testing/debug tools include features such as:
Program monitors, permitting full or partial monitoring of program code including: Instruction set simulator, permitting complete instruction level monitoring and trace facilities Hypervisor, permitting complete control of the execution of program code including:- Program animation, permitting step-by-step execution and conditional breakpoint at source level or in machine code Code coverage reports Formatted dump or symbolic debugging, tools allowing inspection of program variables on error or at chosen points Automated functional GUI (graphical user interface) testing tools are used to repeat system-level tests through the GUI Benchmarks, allowing run-time performance comparisons to be made Performance analysis (or profiling tools) that can help to highlight hot spots and resource usage Some of these features may be incorporated into a single composite tool or an Integrated Development Environment (IDE).