Gray-box testing

Last updated

Black box systems
Black box diagram.svg
System
Black box, Oracle machine
Methods and techniques
Black-box testing, Blackboxing
Related techniques
Feed forward, Obfuscation, Pattern recognition, White box, White-box testing, Gray-box testing, System identification
Fundamentals
A priori information, Control systems, Open systems, Operations research, Thermodynamic systems

Gray-box testing (International English spelling: grey-box testing) is a combination of white-box testing and black-box testing. The aim of this testing is to search for the defects, if any, due to improper structure or improper usage of applications. [1] [2]

Contents

Overview

A black-box tester is unaware of the internal structure of the application to be tested, while a white-box tester has access to the internal structure of the application. A gray-box tester partially knows the internal structure, which includes access to the documentation of internal data structures as well as the algorithms used. [3]

Gray-box testers require both high-level and detailed documents describing the application, which they collect in order to define test cases. [4]

Need for gray-box testing

Gray-box testing is beneficial because it takes the straightforward technique of black-box testing and combines it with the code-targeted systems in white-box testing.

Gray-box testing is based on requirement test case generation because it presents all the conditions before the program is tested by using the assertion method. A requirement specification language is used to make it easy to understand the requirements and verify its correctness. [5]

Gray-box testing assumptions for object-oriented software

Object-oriented software consists primarily of objects; where objects are single indivisible units having executable code and/or data. Some assumptions are stated below which are needed for the application of use gray-box testing.

Examples

Techniques

Cem Kaner defines "gray-box testing as involving inputs and outputs, but test design is educated by information about the code or the program operation of a kind that would normally be out of view of the tester". [9] Gray-box testing techniques are:

Effects

Positive Effects

Negative Effects

Applications

Future scope

The distributed nature of Web services allows gray-box testing to detect defects within a service-oriented architecture (SOA). As we know, white-box testing is not suitable for Web services as it deals directly with the internal structures. White-box testing can be used for state art methods; for example, message mutation which generates the automatic tests for large arrays to help exception handling states, flow without source code or binaries. Such a strategy is useful to push gray-box testing nearer to the outcomes of white-box testing.

See also

Related Research Articles

<span class="mw-page-title-main">Acceptance testing</span> Test to determine if the requirements of a specification or contract are met

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

<span class="mw-page-title-main">Software testing</span> Checking software against a standard

Software testing is the act of checking whether software satisfies expectations.

<span class="mw-page-title-main">Software release life cycle</span> Sum of the phases of development and maturity for computer software

The software release life cycle is the process of developing, testing, and distributing a software product. It typically consists of several stages, such as pre-alpha, alpha, beta, and release candidate, before the final version, or "gold", is released to the public.

Black-box testing, sometimes referred to as specification-based testing, is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance. Black-box testing is also used as a method in penetration testing, where an ethical hacker simulates an external hacking or cyber warfare attack with no knowledge of the system being attacked.

In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. SOA is a good choice for system integration. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

In software project management, software testing, and software engineering, verification and validation is the process of checking that a software engineer system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

White-box testing is a method of software testing that tests internal structures or workings of an application, as opposed to its functionality. In white-box testing, an internal perspective of the system is used to design test cases. The tester chooses inputs to exercise paths through the code and determine the expected outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT). White-box testing can be applied at the unit, integration and system levels of the software testing process. Although traditional testers tended to think of white-box testing as being done at the unit level, it is used for integration and system testing more frequently today. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it has the potential to miss unimplemented parts of the specification or missing requirements. Where white-box testing is design-driven, that is, driven exclusively by agreed specifications of how each component of software is required to behave, white-box test techniques can accomplish assessment for unimplemented or missing requirements.

In software testing, test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes. Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or perform additional testing that would be difficult to do manually. Test automation is critical for continuous delivery and continuous testing.

In the context of software engineering, software quality refers to two related but distinct notions:

Game testing, also called quality assurance (QA) testing within the video game industry, is a software testing process for quality control of video games. The primary function of game testing is the discovery and documentation of software defects. Interactive entertainment software testing is a highly technical field requiring computing expertise, analytic competence, critical evaluation skills, and endurance. In recent years the field of game testing has come under fire for being extremely strenuous and unrewarding, both financially and emotionally.

In software development, functional testing is a form of software system testing that verifies whether software matches its design.

In computer science, fault injection is a testing technique for understanding how computing systems behave when stressed in unusual ways. This can be achieved using physical- or software-based means, or using a hybrid approach. Widely studied physical fault injections include the application of high voltages, extreme temperatures and electromagnetic pulses on electronic components, such as computer memory and central processing units. By exposing components to conditions beyond their intended operating limits, computing systems can be coerced into mis-executing instructions and corrupting critical data.

Manual testing is the process of manually testing software for defects. It requires a tester to play the role of an end user where by they use most of the application's features to ensure correct behaviour. To guarantee completeness of testing, the tester often follows a written test plan that leads them through a set of important test cases.

<span class="mw-page-title-main">V-model (software development)</span> Software development methodology

In software development, the V-model represents a development process that may be considered an extension of the waterfall model and is an example of the more general V-model. Instead of moving down linearly, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction, respectively.

<span class="mw-page-title-main">UFT One</span> Software testing automation tool

OpenText UFT One, formerly known as Micro Focus Unified Functional Testing and QuickTest Professional (QTP), is software that provides functional and regression test automation for software applications and environments.

There is considerable variety among software testing writers and consultants about what constitutes responsible software testing. Proponents of a context-driven approach consider much of the writing about software testing to be doctrine, while others believe this contradicts the IEEE 829 documentation standard.

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. Since APIs lack a GUI, API testing is performed at the message layer. API testing is now considered critical for automating testing because APIs serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps.

<span class="mw-page-title-main">Parasoft C/C++test</span> Integrated set of tools

Parasoft C/C++test is an integrated set of tools for testing C and C++ source code that software developers use to analyze, test, find defects, and measure the quality and security of their applications. It supports software development practices that are part of development testing, including static code analysis, dynamic code analysis, unit test case generation and execution, code coverage analysis, regression testing, runtime error detection, requirements traceability, and code review. It's a commercial tool that supports operation on Linux, Windows, and Solaris platforms as well as support for on-target embedded testing and cross compilers.

Helix ALM, formerly called TestTrack, is application lifecycle management (ALM) software developed by Perforce. The software allows developers to manage requirements, defects, issues and testing during software development.

This article discusses a set of tactics useful in software testing. It is intended as a comprehensive list of tactical approaches to software quality assurance and general application of the test method.

References

  1. ↑ "Microsoft Research – Emerging Technology, Computer, and Software Research" (PDF).
  2. ↑ "Archived copy" (PDF). Archived from the original (PDF) on 29 March 2012. Retrieved 17 October 2011.{{cite web}}: CS1 maint: archived copy as title (link)
  3. ↑ "Gray Box Testing". Software Testing Fundamentals. 4 November 2011. Archived from the original on 16 November 2021. Retrieved 19 January 2012.
  4. ↑ "Example of grey box testing with definition". Geekinterview.com. Retrieved 19 January 2012.
  5. 1 2 Jake Rogers (8 August 2016). "Common Questions Regarding Grey-Box Testing". cgsec.co.uk. Retrieved 8 August 2016.[ permanent dead link ]
  6. ↑ "Object-Oriented Extensions to Pascal". Pascal-central.com. Archived from the original on 5 June 2021. Retrieved 19 January 2012.
  7. ↑ Patton, Ron (26 July 2005). Software Testing . Sams. p.  2. ISBN   978-0-672-32798-8.
  8. ↑ "Archived copy" (PDF). Archived from the original (PDF) on 3 April 2012. Retrieved 17 October 2011.{{cite web}}: CS1 maint: archived copy as title (link)
  9. ↑ Nguyen, Hung Q (2001). Testing Applications on the Web: Test Planning for Internet-Based Systems. John Wiley & Sons. ISBN   9780471437642.
  10. ↑ "Explore the World of Gray Box Testing". Extremesoftwaretesting.com. Retrieved 19 January 2012.
  11. 1 2 "SOA Testing Tools for Black, White and Gray Box SOA Testing Techniques". Crosschecknet.com. Archived from the original on 1 October 2018. Retrieved 19 January 2012.
  12. ↑ "E33 Gray Box Testing.PDF" (PDF).
  13. ↑ Ramdeo, Anand (5 May 2011). "Gray Box Testing - Software". Testing Geek. Retrieved 19 January 2012.
  14. ↑ Bach, James (31 December 2001). Lessons Learned in Software Testing. Wiley Computer Publishing. ISBN   978-0-471-08112-8.
  15. ↑ Falk, Jack (12 April 1999). Testing Computer Software, 2nd Edition. Wiley Computer Publishing. ISBN   978-0-471-35846-6.
  16. ↑ http://legacy.cleanscape.net/docs_lib/paper_graybox.pdf [ bare URL PDF ]
  17. ↑ Li, Z. J.; Tan, H. F.; Liu, H. H.; Zhu, J.; Mitsumori, N. M. (6 April 2010). "Business-process-driven gray-box SOA testing". IBM Systems Journal. 47 (3): 457–472. doi:10.1147/sj.473.0457.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.