What is a Black Box Testing Strategy?
Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc. As the name “black box” suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Black box testing is sometimes also called as “Opaque Testing”, “Functional/Behavioral Testing” and “Closed Box Testing”.
The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and testing it against the functional specifications in order to check for normal and abnormal behavior of the system. Now a days, it is becoming common to route the Testing work to a third party as the developer of the system knows too much of the internal logic and coding of the system, which makes it unfit to test the application by the developer.
In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement specifications of the system and as a user, should know, how the system should behave in response to the particular action.
Various testing types that fall under the Black Box Testing strategy are: functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing etc.
These testing types are again divided in two groups: a) Testing in which user plays a role of tester and b) User is not required.
Testing method where user is not required:
Functional Testing:
In this type of testing, the software is tested for the functional requirements. The tests are written in order to check if the application behaves as expected.
Stress Testing:
The application is tested against heavy load such as complex numerical values, large number of inputs, large number of queries etc. which checks for the stress/load the applications can withstand.
Load Testing:
The application is tested against heavy loads or inputs such as testing of web sites in order to find out at what point the web-site/application fails or at what point its performance degrades.
Ad-hoc Testing:
This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing.
Exploratory Testing:
This testing is similar to the ad-hoc testing and is done in order to learn/explore the application.
Usability Testing:
This testing is also called as ‘Testing for User-Friendliness’. This testing is done if User Interface of the application stands an important consideration and needs to be specific for the specific type of user.
Smoke Testing:
This type of testing is also called sanity testing and is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level.
Recovery Testing:
Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc. Type or extent of recovery is specified in the requirement specifications.
Volume Testing:
Volume testing is done against the efficiency of the application. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system.
Testing where user plays a role/user is required:
User Acceptance Testing:
In this type of testing, the software is handed over to the user in order to find out if the software meets the user expectations and works as it is expected to.
Alpha Testing:
In this type of testing, the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user. Any type of abnormal behavior of the system is noted and rectified by the developers.
Beta Testing:
In this type of testing, the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the developers.
Black Box Testing
beSTORM performs a comprehensive analysis, exposing security holes in your products during development and after release.
beSTORM represents a new approach to security auditing. This new approach is sometimes called “fuzzing”, “fuzz testing” or “fuzzer” and can be used for securing in-house developed applications and devices, as well as applications and devices of external vendors.
Most of the security holes found today in products and applications, can be discovered automatically. By using an automated attack tool that tries virtually all different attack combinations, with the ability to detect certain application anomalies and indicate a successful attack, those security holes can be found almost without user intervention.
 |
How it works
- Innovative beSTORM performs an exhaustive analysis to uncover new and unknown vulnerabilities in software products. This is different than older generation tools that use attack signatures or attempt to locate known vulnerabilities in products. beSTORM does not need the source code to analyze and uncover vulnerabilities.
- Broad range Many of the common Internet protocols can be tested by beSTORM – even complex protocols such as SIP (used in Voice over IP products) are supported.
- Attack Prioritization Special attack prioritizing algorithms allow beSTORM to start with the attacks most likely to succeed, depending on the specific protocol that is audited. This saves considerable time during the audit process and highlights the most important problems, first.
- Report accuracy beSTORM checks the application externally by triggering actual attacks. Vulnerabilities are reported only if an actual attack has been successful, for example if a buffer overflow has been triggered. Simply put, beSTORM emulates an attacker. If the attacker cannot carry out the attack, beSTORM will not report it, effectively reducing the number of false positives.
- Protocol compliance beSTORM is able to convert the protocol standard text to automated set of tests by converting the BNF description used in technical RFC documents to attack language. This ensures that the entire functionality of the system is checked, and enables to quickly find bugs that otherwise surface only months or years after the product is released to the market.
- Comprehensive analysis beSTORM detects vulnerabilities by attaching to the audited process and detecting even the slightest anomalies. By doing so, beSTORM can find attacks as subtle as ‘off-by-one’ attacks, as well as buffer overflow attacks that do not crash the application.
- Scaling beSTORM is extremely scalable, with the ability to use multiple processors or multiple machines to parallelize the audit and substantially reduce the testing duration.
- Extensibility beSTORM tests the protocol rather than the product, and therefore can be used to test extremely complicated products with a large code base.
- Flexibility beSTORM’s protocol analysis can be easily extended to support your proprietary protocol.
- Language independent beSTORM tests the binary application, and is therefore completely indifferent to the programming language or system libraries used. beSTORM will report the exact interaction that triggers the vulnerability, and the programmers can now debug the application with whatever development environment they wish to see what causes the fault.
Automated Binary Analysis
| beSTORM includes an automated engine that can parse through binary data, decode ASN.1 structures as well as length value pairs:
|
Automated Textual Analysis
| beSTORM includes an automated engine that can parse through textual data, recognize multiple forms of data encoding, as well as decode XML structures:
|
Custom Protocols
| For those protocols that cannot be automatically analyzed beSTORM includes a graphical interface that can be used to easily support your proprietary protocols:
|
Advanced Debugging and Stack Tracing
| beSTORM includes an advanced debugging and stack tracing engine that can not only discover potential coding issues, but also show what is the stack trace that brought you to the specific coding issue:
|
Advantages
- Integrates with the existing development strategy Search for security vulnerabilities during development or as part of your QA process.
- Source code not necessary No need for source code – perfect for auditing 3rd party applications.
- Reproducable Vulnerabilities are searched for in a methodical way which can be reproduced.
- Powerful substitute beSTORM can be used to substitute existing tools used by security auditors and black-box testers.
