Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

345 > QA in Construction > Flashcards

QA in Construction Flashcards

1
Q

3 things that programmers must accomplish

A

1) Syntactically correct (grammar)
2) Software must be consistant with standards sanctioned by the project and organization
3) Software must implement algorithms and data structures in accord with design specs

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Code Analysis

A

Verification and validation that is automated

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Code Review

A

Verification and Validation that is not automated

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Dynamic analysis

A

analysis techniques while programs are running

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Static analysis

A

Examine software when it is not running

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Formal Reviews

A

Code inspections because each participant has a well-defined role ,the activity follows a well-defined process, and the activity is guided by a checklist.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Rate of code review should be about how many lines of code per hour?

A

200 lines for preparation and team inspection should not exceed 150 per hour

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What should code inspection checklist have on it?

A

Specific defects that inspectors should look for during preparation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Ex of things on code checklist

A
  • naming conventions
  • are variable names confusing?
  • is every variable and attribute correctly typed
  • method returns correct value
  • appropriate access modifiers
  • nested if statements should be converted into switch statement
  • all exceptions handled
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Simplest type of static analysis

A

Syntax Checking

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Syntax Checking

A

ensures that the software obeys grammatical rules of language it is written in. Most frequently performed by a language-sensitive editor.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Something to be aware of Syntax Checkers

A

Editors do not always correctly identify the root cause of the problem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Style Checking

A

Standards related to typography based on a style guide. (upper and lower case, naming, spaces, tabs, brackets)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

First style checker was called?

A

Lint

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Usage checkers

A

look for 3 things:

  • suspicious or error prone constructs (uninitialized variables, use of division operator)
  • non-portable constructs (may have range problem)
  • memory allocation inconsistencies.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Difference between usage and idiom checkers

A

Idiom checkers are more varied

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Formal Methods

A

refer to the class of static analysis tools that rely on mathematical models

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Types of Formal Methods (3)

A

Model checking
Data Flow analysis
Symbolic evaluation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Model Checking

A

the process of automatically determining if a program or sub program satisfies certain requirements. The inputs to a model checker are the program or sub-program and formal specs of requirements. Requirements specified using logical expressions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Data Flow Analysis

A

Process of enumerating the set of possible values calculated at various points in a program or sub-program using ideas from graph theory

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Symbolic evaluation

A

Process of automatically tracing the execution of a program or sub-program using symbolic values rather than numeric values. Used to identify the values that will cause different statements to be executed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Unit Testing

A

The testing of individual units or sub-programs in isolation. One value for each sub-program argument and one corresponded expected output. To determine faults in sub-program

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

False negative

A

the conclusion that there are no faults due to an incomplete test suit

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

False Positive

A

Incorrect expected value (conclusion that there is a fault when there isn’t)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Black Box Testing
testing the processing details of the component, system or product are presumed to be unknown. The person developing the tests only knows what can go into the tested unit and what should come out
26
Clear/White/open box
Person developing the tests knows exactly how the componenet, sub-system or product is built and how it should operate. Combo of two is generally required for effective testing
27
What does clear box testing focus on?
Coverage of tests.
28
How to measure coverage?
Control Flow Graph (CFG)
29
Describe control flow graph:
action node - represents a piece of code with one entry point and one exit point (statement represented as an action) decision node - represents the start of a piece of code with one entry point and multiple exit points
30
Statement Coverage
The percentage of statements exercised when a set of tests cases is executed.
31
Branch Coverage
Percentage of branch directions taken when a set of tests cases is executed. Identifies the outbound edges from decision nodes that have and have not been traversed.
32
Path Coverage
The percentage of all execution paths taken when a set of test cases executes.
33
Is 100% path coverage achievable for large programs
NO
34
Test Driven Development
TTD A process in which tests are developed as the code is and for very small increments in functionality.
35
Are all tests supposed to be created before the program is written?
No, You want to have some written before (black box) and then others for (TTD) written after the code that focus on coverage (clear box).
36
Complete enumeration/exhaustive testing
Creates a test suite that contains all possible inputs. Usually a huge number b/c has to do every value 2^32 for integer and 2^64
37
Oracle
Another sub-program that is known to output the correct answers
38
Randomization
"brute force" approach which can be done in either a structured or unstructured fashion. Stat with the completely enumerated test suit and then select tests from that suite in some probabilistic fashion ( looking for possible error triggers).
39
Boundary Value Analysis
Idea that failure triggers tend to be found at the "boundaries" of the sets of inputs and outputs.
40
Other popular value-based heuristics for individual parameters
- number 0 for dividing by zero - very large and very small numbers (underflow and overflow) - characters or string version of digits and numbers - equal value params - different relative value params - small and large arrays - arrays w/ 1 or 0 elements - unsorted arrays - arrays with duplicates and no duplicates
41
Equivalence class
Partitioning test cases into sets in which each test case in the set is expected to trigger the same failure. Helps so don't have to create more than one test case from each equivalence class.
42
Ideal test should do what?
Correct the fault and NOT introduce a new fault
43
Regression Testing
Running all tests over again after making any software change (even just editing comments)
44
Assertion
relates actual output to expected output
45
What unit testing tool do we use?
JUnit
46
Advantages of Unit Testing
- easy to isolate different tests - easy to construct isolate tests - reports generated are easy to read and highlight the failed tests - can be supplemented with code coverage tools
47
Symptom
A characteristic of a failure that can be observed
48
Error
Something that a person does that gives rise to a fault
49
Trigger Condition
Condition that causes a product to fail
50
Symptom and Error in a program that divides by 0
Symptom = the program crashes Fault- the omission of statements that checks the user-supplied value and display an error message Trigger Condition - dividing by zero
51
Debugging process (5) steps
``` Stabilize Localize Correct Verify Globalize ```
52
Stabilize
Understand the symptom and trigger condition of test so failure can be reproduced
53
Localize
Locate the fault (form hypothesis and then tests if your hypothesis for the error was correct)
54
Correct
Fix Fault
55
Verify
Test fix, make sure not introduce new fault
56
Globalize
Look for and fix similar defects in other parts of the system
57
Debug Code
Includes both temporary output statements that can be used to monitor state information and temporary input statements that can be used to pause the execution of a component
58
Biggest disadvantages of debug code:
- chunkiness - can obscure the code it is meant to debug - can take a significant amount of time to add - it can be difficult to know what is output - can print a lot of stuff
59
Debugger
A tool that can be used to trace the execution of a code without having to modify it in any way
60
Breakpoint
Pauses the execution of a program. Can start executing a program but pause execution when particular statement is reached
61
Step into
If statement is a call to a sub0program, enter the sub-program and execute each of its statements one at a time
62
Step over
Ignores internal details
63
Step out
Get out of a sub-program, continuing execution of its code until it returns then pausing again after the return
64
Watches
monitor state information. Can monitor values contained in different variables to see how they change.
65
Profiling
The process of measuring the amount of time (or space) used by sub-programs and statements during a particular execution of a program.
66
What kind of analysis is Profiling?
Dynamic b/c occurs while the program is executing
67
Refactoring
changing code without altering its behavior. To improve structure
68
When should refactoring be done (3)?
- duplication of code - lack of clarity (code hard to understand) - code smell
69
Code smell
Comments that duplicate code, classes that do nothing but hold data, failure to hide info, tight coupling, low cohesion, bloated classes, lazy classes, long methods, reliance on switch statements instead of classes
70
Introduce explain variable
refactoring technique that adds temp variable to make code easier to understand
71
Inline temporary variable
refactoring technique get rid of temp variables that make code harder to understand
72
Extract sub-program
refactoring technique that splits a sub-program into two or more sub-programs
73
Inline sub-program
refactoring technique when sub-program is too short to warrant being a separate identity get rid of it
74
What kind of testing should unit and integration testing be (black or clear)?
Clear
75
Test-driven development (TDD)
A style of coding in which writing tests is integral to the coding process itself. Has many tests that check behavior in ways that do not depend on code (because they are written before the code) -> high quality tests
76
Essential factors of TDD
``` testing framework is assumed tests are written before code tests and code are written incrementally code is only written to pass tests Refactoring is expected ```

345 (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions