B

A B C D E F G 


Backus-Naur Form (BNF): A metasyntax used to express context-free grammars: that is, a formal way to describe formal languages.
BNF is widely used as a notation for the grammars of computer programming languages, instruction sets and communication protocols, as well as a notation for representing parts of natural language grammars. Many textbooks for programming language theory and/or semantics document the programming language in BNF.

Basic Block: A sequence of one or more consecutive, executable statements containing no branches.

Basis Path Testing: A White Box Test case design technique that fulfills the requirements of branch testing and also tests all of the independent paths that could be used to construct any arbitrary path through the computer program.

Basis Test Set: A set of test cases derived from Basis Path Testing.

Baseline: The point at which some deliverable produced during the software engineering process is put under formal change control.

Bebugging: A popular software engineering technique used to measure test coverage. Known bugs are randomly added to a program source code and the programmer is tasked to find them. The percentage of the known bugs not found gives an indication of the real bugs that remain.

Behavior: The combination of input values and preconditions along with the required response for a function of a system. The full specification of a function would normally comprise one or more behaviors.

Benchmarck Testing: Benchmark testing is a normal part of the application development life cycle. It is a team effort that involves both application developers and database administrators (DBAs), and should be performed against your application in order to determine current performance and improve it. If the application code has been written as efficiently as possible, additional performance gains might be realized from tuning the database and database manager configuration parameters. You can even tune application parameters to meet the requirements of the application better.

You run different types of benchmark tests to discover specific kinds of information:

• A transaction per second benchmark determines the throughput capabilities of the database manager under certain limited laboratory conditions.
• An application benchmark tests the same throughput capabilities under conditions that are closer production conditions.

Benchmarking is helpful in understanding how the database manager responds under varying conditions. You can create scenarios that test deadlock handling, utility performance, different methods of loading data, transaction rate characteristics as more users are added, and even the effect on the application of using a new release of the product.

Benchmark Testing Methods: Benchmark tests are based on a repeatable environment so that the same test run under the same conditions will yield results that you can legitimately compare.

You might begin benchmarking by running the test application in a normal environment. As you narrow down a performance problem, you can develop specialized test cases that limit the scope of the function that you are testing. The specialized test cases need not emulate an entire application to obtain valuable information. Start with simple measurements, and increase the complexity only when necessary.

Characteristics of good benchmarks or measurements include:

• Tests are repeatable.
• Each iteration of a test starts in the same system state.
• No other functions or applications are active in the system unless the scenario includes some amount of other activity going on in the system.
• The hardware and software used for benchmarking match your production environment.

For benchmarking, you create a scenario and then applications in this scenario, capturing key information during each run. Capturing key information after each run is of primary importance in determining the changes that might improve performance of both the application and the database.

Beta Testing: Comes after Alpha Testing. Versions of the software, known as beta versions, are released to a limited audience outside of the company. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.

Big-Bang Testing: An inappropriate approach to integration testing in which you take the entire integrated system and test it as a unit. Can work well on small systems but is not favorable for larger systems because it may be difficult to pinpoint the exact location of the defect when a failure occurs.

Binary Portability Testing: Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.

Black Box Testing: Testing without knowledge of the internal working of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs. It is because of this that black box testing can be considered testing with respect to the specifications, no other knowledge of the program is necessary. For this reason, the tester and the programmer can be independent of one another, avoiding programmer bias toward his own work. For this testing, test groups are often used.

Advantages of Black Box Testing

• More effective on larger units of code than Glass Box Testing.
• Tester needs no knowledge of implementation,
• Tester and programmer are independent of each other.
• Tests are done from a user's point of view.
• Will help to expose any ambiguities or inconsistencies in the specifications.
• Test cases can be designed as soon as the specifications are complete.

Disadvantages of Black Box Testing

• Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever,
• Without clear and concise specifications, test cases are hard to design.
• There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried.
• May leave many program paths untested.
• Cannot be directed toward specific segments of code which may be very complex (and therefore more error prone).
• Most testing related research has been directed toward glass box testing.

Block Matching: Automated matching login applied to data and transaction driven websites to automatically detect block s of related data. This enables repeating elements to be treated correctly in relation to other elements in the block without the need for special coding. See TestDrive-Gold.

Bottom Up Testing: An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components.

Boundary Testing: Tests focusing on the boundary or limits of the software being tested.

Boundary Value: An input value or output value which is on the boundary between equivalence classes, or an incremental distance either side of the boundary.

Boundary Value Analysis: In boundary value analysis, test cases are generated using the extremes of the input domain, e.g. maximum, minimum, just inside/outside boundaries, typical values, and error values.

Boundary Value Coverage: The percentage of boundary values which have been exercised by a test case suite.

Branch: A conditional transfer of control from any statement to any other statement in a component, or an unconditional transfer to control from any statement to any other statement in the component except the next statement, or when a component has more than one entry point, a transfer of control to an entry point of the component.

Branch Condition Coverage: The percentage of branch condition outcomes in every decision that has been tested.

Branch Condition Combination Coverage: The percentage of combinations of all branch conditions outcomes in every decision that has been tested.

Branch Condition Combination Testing: A test case design technique in which test cases are designed to execute combinations of branch condition outcomes.

Branch Condition Testing: A technique in which test cases are designed to execute branch condition outcome.

Branch Testing: A test case design technique for a component in which test cases are designed to execute branch outcomes.

Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail.

Bug: A fault in a program which causes the program to perform in an unintended. See Fault.