Testing: Chapter 13. "You make it, I’ll break it". Purpose:. Does the product as a whole perform up to specifications? (validation?) Does it perform under normal, upper, and lower limits wrt the environment? Does it meet or exceed all claims (verification)?. Testing defined.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
"You make it, I’ll break it"
For each test and for each device, a failure must be defined. This definition depends on the intended application and the anticipated environment. What is considered a failure for one component or device may not be a failure for another. The test protocol should be as detailed as possible in defining the failure.
We want to test some power supplies to prove a MTBF goal of 50,000 hours of operation. How many units do we test and for how long, assuming one failure and 90% confidence level?
(sample size)(test time) = MTBF goal (7.779)/2
(sample size)(test time) = 50,000 (7.779)/2
= 194,475 unit-hours
Determining Sample Size and Test Length 50,000 hours of operation. How many units do we test and for how long, assuming one failure and 90% confidence level?
MTBF goal = (sample size)(test time) (2)/Χ2 α;2r+2
Confidence level = 1 ‑ α, where α is the risk factor and r = the number of failures
Using the 90% confidence level, α = 0.10 & no failures (r=0)
(Sample size)(test time) = (MTBF goal)( Χ2 α;2 )/2
(sample size)(test time) = MTBF goal (4.61)/2
to prove a MTBF goal of 50,000 hours of operation:
(sample size)(test time) = 50,000 (4.61)/2 = 115,250 unit-hours
Procedures that attempt to determine that the product of each phase of the development process is an implementation of a previous phase, i.e., it satisfies it. Each verification activity is a phase of the testing life cycle…
Black box testing is a data driven testing scheme. The tester views the device or program as a black box, i.e., the tester is not concerned about the internal behavior and structure. The tester is only interested in finding circumstances in which the device or program does not behave according to its specification
White box testing is concerned with the degree to which test cases exercise or cover the structure of the device or program. The ultimate while box test is an exhaustive path test.
This type of testing verifies that given all the expected inputs then all of the expected outputs are produced. This type of testing is termed success oriented testing because the tests are expected to produce successful results.