Explore chapters and articles related to this topic
Quality and Testing
Published in Nikhilesh Krishnamurthy, Amitabh Saran, Building Software, 2007
Nikhilesh Krishnamurthy, Amitabh Saran
Black-box testing is based on the knowledge gathered from the requirements and functionality documentation. It is behavioral in nature. Black-box testing is concerned with only testing the specification; it cannot guarantee that all parts of the source code have been tested for faults. White-box testing, on the other hand, is based on the knowledge of an application’s internals — the source code — and is thus structural in nature. Because white-box testing is concerned only with testing the software product, it cannot guarantee that the nonfunctional specification has been implemented.
Foundation and Application of Expert System Verification and Validation
Published in Jay Liebowitz, The Handbook of Applied Expert Systems, 2019
These methods are in general “black-box validation techniques.” As the name suggests, these techniques are used to determine the correctness of the system viewed as a “black box.” Given some statements of user requirements, tests are applied to the system to establish whether or not it meets its requirements. The test cases are designed so as to exercise the system in a broad range of situations. Black-box tests are difficult to perform when there are many special-case situations that require special testing.
Static Testing and Dynamic Testing the Code
Published in William E. Lewis, David Dobbs, Gunasekaran Veerapillai, Software Testing and Continuous Quality Improvement, 2017
William E. Lewis, David Dobbs, Gunasekaran Veerapillai
Black-box testing is a technique that focuses on testing a program’s functionality against its specifications. White-box testing is a testing technique in which paths of logic are tested to determine how well they produce predictable results. Gray-box testing is a combination of these two approaches and is usually applied during system testing. It is a compromise between the two and is a well-balanced testing approach that is widely used during system testing.
User acceptance test for software development in the agricultural domain using natural language processing
Published in Journal of Decision Systems, 2023
Leandro Antonelli, Guy Camilleri, Diego Torres, Pascale Zaraté
Traditional techniques to design test cases can be grouped into two main categories. White box tests and black box tests. The first one needs a detailed specification of execution workflows of the software application to analyse all possible flows to test all of them. The second type of category needs all the data that a software application needs to provide all the possible combinations concerning the data to perform a decision table that considers every possible combination. Thus, in order to test a software application, generally source code is used as input, although it is beneficial to use an artefact of early stages as requirements so the validation of the software application is tied closely to clients’ products. This type of test is called system test and user acceptance test, both types of tests have the same goal, to ensure that the whole system satisfies clients’ needs. The difference between both types relies on that the person who performs the tests: user acceptance tests are performed by some representative of the client, while system tests are performed by some member of the development team (ISO/IEC/IEEE, 2010). Generally, system and user acceptance tests, are more related to white-box tests, where a flow of actions is tested. In this paper, two expressions are used ‘User Acceptance Tests’ and ‘Test cases’. It is important to mention that ‘User Acceptance Test’ is a specific type of test as for example, others specifics types of tests ‘System Usability Tests’, and ‘Integration Tests’. Meanwhile, ‘Test case’ is a generic expression that refers to a set of actions or instructions that validates a specific aspect of a product.
Software security evaluation using multilevel vulnerability discovery modeling
Published in Quality Engineering, 2023
Ruchi Sharma, Avinash K. Shrivastava, Hoang Pham
The majority of efforts in software security assessment are steered toward developing and testing systems for robustness and security. The security of a software system is its capability to shield itself from accidental or deliberate attacks. Software designers and developers ensure that solid design principles and defensive techniques are followed to develop secure systems. Code auditing is performed to analyze application code to uncover bugs that might be the cause of future software failure. Black box testing, also known as functional testing, evaluates software by executing different types of test cases. In this process of testing, specific inputs are given to the system under which the application can show unexpected behavior. This could be as crucial as a crash or unwanted exposure of sensitive data. Any software security assessment system is however incomplete without proper addressal of vulnerabilities Software. Figure 1 shows the difference between error, defect, vulnerability and failure and their relation. Error occurs due to the problem in the code. Usually developers use the term error. Error in the software leads to defect or fault. Vulnerabilities are the faults in software that are capable of causing a security breach (Rescorla 2005). Here, it is important to note that a software fault is an implementation defect that can lead to a vulnerability and vulnerability is an exploitable condition within the code that allows an attacker to attack. So, just because a defect is not a vulnerability at present does not mean that it cannot become a vulnerability in the future as the environment and architecture change or get updated. To put it simply, once someone has figured out a way to attack, a fault becomes a vulnerability. In other words, we can say that all vulnerabilities are faults but all faults are not vulnerabilities. Further, vulnerabilities are encountered during the operational phase while faults are detected during the testing phase.