what is testability
refers to the ease with which software can be made to demonstrate its faults through (typically execution-based) testing
what does it mean for a system to properly testable
it must be possible to control each of the components inputs and then to observe its outputs
general scenario: 5 values for source
with manual or automatic testing tools:
- unit testers
- integration testers
- system testers
- acceptance testers
- end users
general scenario: 4 values of stimulus
- a set of tests executed due to the completion of a coding increment
- completed integration of subsystem
- finished implementation
- deliver system to customer
general scenario: 6 values for environment
- design time
- development time
- compile time
- integration time
- deployment time
- run time
general scenario: 1 value for artifact
the portion of the system being tested
general scenario: 3 values for response
- execution of test suite and capture results
- capture activity that resulted in the fault
- control and monitor the state of the system
general scenario: 4 values for response measure
effort to find fault or class of faults
-effort to achieve a given percentage of state space coverage
probability of fault being revealed by the next test
-time to perform tests
general scenario: 4 more values response measure
- effort to detect faults
- length of longest dependency chain
- length of time to prepare test environment
- reduction in risk exposure
the main goal of testability tactics
to allow for easier testing when an increment of software development has completed
2 categories of testability tactics
- control and observer system state
- limit complexity
6 ways to control and observe the system state
- specialized interfaces
- record/playback
- localize state storage
abstract data sources
-sandbox
executable assertions
meaning of “specialized interfaces”
to control or capture variable values for a component either through a test harness or through normal execution
meaning of “record/playback”
capturing information crossing an interface and using it as input for further testing
meaning of “local state storage”
to start a system, subsystem, or module in an arbitrary state for a test
meaning of “abstract data sources”
abstracting interfaces lets you substitute data more easily
meaning of “sandbox”
isolate the system from the real world to enable experimentation that is unconstrained by the worry about having to undo the consequences of the experiment
meaning of “executable assertions”
assertions are hand coded and placed at desired locations to indicate when and where a program is in a faulty state
2 methods to limit complexity
limit structural complexity
limit non-determinism
meaning of “limit structural complexity (3 things)
- avoiding or resolving cyclic dependencies between components
- isolating and encapsulating dependencies on the external environment
- reducing dependencies between components in general
meaning of “limit non-determinism”
finding all sources of non-determinism, such as unconstrained parallelism, and weeding them out
3 factors for binding time
- ensure the components that are bound later than compile time can be tested in late-bound context
- ensure late bindings can be captured (logged)
- ensure full range of binding possibilities can be tested
-
Chapter 1 - What is SW Architecture45
-
Chapter 2 - Why is Architecture Important22
-
Chapter 3 - Contexts of SW Architecture12
-
Chapter 4 - Understanding Quality Attributes21
-
Chapter 5 - Availability48
-
Chapter 6 - Interoperability22
-
Chapter 7 - Modifiability30
-
Chapter 8 - Performance28
-
Chapter 9 - Security39
-
Chapter 10 - Testability22
-
Chapter 11 - Usability20
-
Chapter 12- Other Quality Attributes18
-
Chapter 13 - Patterns and Tactics70
-
Chapter 14 - Quality Attribute Modeling and Analysis25
-
Chapter 15 - Architectures in Agile Projects12
