Info domain analysis complete, consistent, accurate? Problem partitioning complete? External/internal interfaces defined? Data model reflects objects, attributes, relationships? Requirements traceable to system level? Prototypes exist? Performance achievable within the system constraints? Requirements consistent w/schedule, resources, budget? Validation criteria complete?
SW requirements reflected in architecture? Modularity (cohesion, independence) Program architecture factored? Interfaces - modules, external systems - defined? Data structures consistent with information domain? Data structures consistent with software requirements? Maintainability considered (design-for-maintainability) Quality factors explicitly assessed?
Algorithms accomplish desired functions? Algorithms logically correct? Interfaces consistent with architectural design? Logical complexity reasonable? Error-handling specified? Local data structures properly defined? Structured programming constructs enforced? Design detail ammenable to implementation language? OS or language-dependent features used? Compound or inverse logic used? Maintainability considered?
Operability—it operates cleanly Observability—the results of each test case are readily observed Controllability—the degree to which testing can be automated and optimized Decomposability—testing can be targeted Simplicity—reduce complex architecture and logic to simplify tests Stability—few changes are requested during testing Understandability—of the design
First, we compute the cyclomatic complexity: number of simple decisions + 1 or number of enclosed areas + 1 In this case, V(G) = 4
3 cases: E 1<E 2, E 1=E 2, E 1>E 2 Will discover errors in rel-op (if E 1, E 2 - correct) Make E 1 close to E 2 to detect errors in E 1, E 2 For n Boolean variables, 2 n cases Feasible only for small n For Boolean singular expressions (each variable occurs only once in the expr. ) it is possible to devise tests < 2 n, and still guarantee detection of errors (including operator errors)
DEF(X)={S | S contains definition of X} USE(X)={S | S contains a use of X} S - statement (number) Definition of X at S is “live” in S’ if there is a path from S to S’ that does not contain another definition of X Then IX, S, S’J is a DU-chain (definition-use chain) DU testing strategy = cover all DU-chains Does not guarantee branch covering (e. g. , empty “else” part, and “then” does not define any variable) Not-covered branches trivial Good for error catching Difficult to generate test plans
Generate one set of data to exercise each major feature of the program (classes in the output space or in the input space) Devise unusual cases in the solution space (boundary lines, extremes of solutions, etc. ) Unusual or bad cases in the input-space (e. g. , zero, negative values, illegal ranges, end-points of illegal ranges) Compute the gradient of the solution and choose points where the gradient is maximized Add points which have not been covered yet If the resources for the testing are not used up, then generate additional tests either judiciously or randomly
Scope of testing (characteristics to be tested, scope/effort bounds, completion criteria, schedule constr. ) Test plan (phases/builds collections of modules), schedule, tools, software (stubs/drivers), environment, resources, test criteria (interface integrity, functional validity, information content, performance) Test procedure: order of integration (purpose, modules to be tested), unit tests for modules in build, test environment, test case data, expected results, actual test results, references, more
Скачать презентацию Info domain analysis complete consistent accurate Problem partitioning
3d5f7db3ddb6a324910aab6920636da6.ppt