393 Final flashcards

Compose objects into tree structures to represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. Recursive composition "Directories contain entries, each of which could be a directory." 1-to-many "has a" up the "is a" hierarchy

Defines a family of algorithms, encapsulates each one, and makes them interchangeable

Attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

separates an abstract class hierarchy from its implementation so the two can vary independently

Encapsulate a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.

a design pattern that provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation; assumes that the underlying collection is not changed or modified while the traversal is occurring

concrete subclasses of visitor perform specific analyses most appropriate when you want to do a variety of things to objects having a stable class structure

- convert the interface of a class into another interface clients expect - wrap an existing class with a new interface - impedance match an old component to a new system

provides a surrogate or placeholder for another object to control or facilitate access to it - useful for when you need to modify the behavior of a class for some of its clients without changing the interface

developer facing - program should be readable, maintainable, etc. -> human code review, static analysis tools and linters, programming idioms and design patterns, local coding standards

customer facing - program should do the right thing -> behave according to a specification, robustness against maintenance mistakes

there cannot be a program that will determine which computer programs will halt (or exit) and which programs will go on forever (infinite loop) so we approximate using type systems, linters, static analyzers, etc.

the systematic examination of a software artifact to determine its properties

attempting to be comprehensive, as measured by, as examples: test coverage, inspection checklists, exhaustive model checking

automated: regression testing, static analysis, dynamic analysis manual: manual testing, inspection, modeling

code, system, module, execution trace, test case, design or requirements document

direct execution of code on test data in a controlled environment

human evaluation of code, design documents (specs and models), modifications

dynamic: tools extracting data from test runs static: tools reasoning about the program without executing it

runtime deviation from required behavior

a flaw in a program that can cause it to fail

human action that results in a defect or fault

property that program absolutely satisfies functional requirement

numerical measure of extent to which behavior of deployed software conforms to requirements ex: frequency of failures

tester or tools generates test data types: functional testing, structural testing, boundary/special values testing, interaction testing, model-based testing

exercises each specified functional requirement at least once

divide input domain of program into finite number of subdomains -> inputs in each subdomain are treated similarly -> one or a few test cases are selected from each subdomain disjoint subdomains can be viewed as equivalence classes

exercises or covers each program element of a certain type -> percent coverage used as one measure of test-completeness

software tested in field (or with inputs captured in field); prerequisite for measuring reliability

approximation to field testing; used when field testing is infeasible; requires probabilistic simulation model

inspection, program analysis, reliability estimation, program verification (formal verification)

feasible and beneficial, but inspectors overlook many defects

effective for finding violations of implicit programming rules

employs statistical sampling methodology, based on field testing

- intended to produce proof of correctness - manual is impractical for large programs - partial automation options: automatic theorem proving or finite-state model checking

analysis of specification and program, test data creation/generation, program execution, evaluation of program behavior

a source to determine an expected result to compare with the actual result of the system under test can be partially automated (full requires correct implementation of requirements, "gold" program)

a software testing technique that deliberately provides invalid, unexpected, or random data as inputs to a computer program does not provide full expected outputs without an automated oracle, may detect only exceptions, assertion failures, crashes, and hangs

unit testing -> integration & subsystem testing -> system testing -> field testing -> acceptance testing -> regression testing pre alpha -> alpha -> beta -> release candidate (rc) -> release

- routine, module, or class tested - analysis and evaluation are simplest - driver and stubs often needed - supported by frameworks like xUnit

- units integrated into subsystem - interactions between units tested - analysis and evaluation are usually harder

- subsystems integrated - analysis and evaluation are usually hardest

- system used in field by ordinary users - users report problems - one or more deployment sites - extended duration (e.g., months)

- testing by customer - basis for accepting software

- retesting after maintenance - existing tests often reused - "general case" of testing

performed by testers who are internal employees of development organization at the developer's site

performed by customers or end users at location of client or end user of product

input (data), oracle (output), comparator (compared actual output against the oracle), discoverer (finds all test cases), runner (chooses which cases to run) test case: piece of code that establishes preconditions, performs an operation, and asserts postconditions test fixture: code to be run before/after each test case

- tests features in isolation -> when a test fails it is easier to locate the bug - tests are small -> easier to understand - tests are fast -> can be run frequently

test each component as soon as it becomes possible

depicts potential control flow between program statements or instructions statement, branch, condition, function coverage

used in conjunction with functional and structural testing; involves testing with boundary or special values of variables

involves stressing software with high loads

testing interactions between variables, objects, events, statements, components, or features feature interaction = integration of two features can modify the behavior of one or both features

a black box testing technique that samples input parameters and configurations and combines them systematically calls for testing all t-way interactions (for chosen t) uses combinatorial algorithms to construct covering arrays for n-way interactions

find evidence of potential causal interactions between program elements; shown in a program dependence graph

many testing technique call for covering specific pdg sub-structures (chains of dependencies, pdg subgraphs)

exercises object interaction scenarios using mock objects

dummy object that mimics a real object's behavior

• The real object does not yet exist • It has nondeterministic behavior • It is difficult to set up • It has behavior that is hard to trigger • It is slow • It is a user interface • It uses a callback

any type of testing guided by a behavioral model limitation: model omissions

involves selecting test cases to reveal a specific kind of programming fault

small changes are automatically injected into a program creating mutant versions, tests are run, if a mutant produces different output then it is killed

• Instrumenting the target program to gather coverage information • Generating and mutating test cases • Executing the program with these test cases • Analyzing the execution feedback to guide further fuzzing

security oriented testing with goal of reporting found vulnerabilities

• Boundary/special values testing • Independent testing by application expert • Random testing • Operational (field) testing • Mining code base to discover programming rules and rule violations

they don't usually generate incorrect results/crashes so they are difficult to diagnose ex: system load, hardware configuration, network conditions, user-specific workflows, interactions with other systems

a process to analyze and measure the performance of a program or specific parts of its code

record sequential events (function calls) that occur during the execution of a program about understanding the flow of execution and the behavior of a program

verification: is it built correctly/are there incorrect design choices validation: did we do requirements capture correctly

information and communications related to addressing a software issue contains severity and priority information, and have a complex nonlinear lifecycle

a potential change to intended purpose (requirements of software)

the process of prioritizing defect reports based on severity and urgency how expensive it is to fix a bug versus the cost of not fixing it

provides information about a defect, created by testers, users, or tools

the degree of impact that a defect has on the development or operation of a system

the importance or urgency of fixing a defect

developers watch the incoming bug report queue and claim defects for themselves

one or more people in QA watch the incoming bug report queue and assign reports to a pool of developers

memory bugs (severe) and semantic bugs

the task of identifying source code regions implicated in a bug

a software tool that is used to detect the source of program or script errors, by performing step-by-step execution of application code and viewing the content of code variables

uses a dynamic analysis to rank suspicious statements implicated in a fault by comparing the statements covered on failing tests to the statements covered on passing tests++

susp = [ fails/total_fail ] / [ fails/total_fail + passes/total_pass ]

a performance analysis tool that measures the frequency and duration of function calls as a program runs

computes the average call times for functions but does not break times down based on context

computes call times for functions and also the call-chains involved

register a function that will get called whenever the target program calls a method, loads a class, allocates an object, etc. (hooks)

pros: simple/cheap, no big slowdown cons: can miss periodic behavior, high error rate

every static analysis is necessarily incomplete, unsound, undecidable, or a combination thereof

security, memory safety, resource leaks

- analysis must produce zero false positives - analysis needs to be really fast - you can't just turn on one particular check

shallow syntax analysis for enforcing code styles and formatting good for improving maintainability

simple syntax or api-based rules for identifying common programming mistakes

check conformance to user-defined types

deep program analysis to find complex error conditions issue is that they are costly

- can only analyze code that is annotated - only considers the signature and annotations of methods - can't handle dynamically generated code well - can produce false positives

workarounds or sub-optimal implementations that incur long-term costs (performance, maintenance, etc)

a system can have messy internals and low debt (stable legacy code nobody touches), or clean internals and high debt (elegant code built on a fundamentally wrong abstraction that must soon change) technical debt mainly impacts maintainability and evolvability

true

code with tangled control flow and poorly organized logic so it is hard to follow, debug, or modify

ad hoc code written mainly to connect different modules, libraries, or services without clean abstractions

class that does too many things and holds too many responsibility

ml is more data-focused, experimental, and algorithmic, while se is more structured or process-oriented evaluation: sl -> functional correctness, ml -> accuracy

automation and reducing manual efforts, support in problem-solving and decision making writing tests, refactoring code, understanding code

incorrect/non-optimal code, security, overreliance, high latency

ml-enabled software is often under-specified, data-driven (data quality/quantity), uncertain, and opaque

human in the loop, undoable actions, guardrails, mistake detection/recovery, containment and isolation

top down systematic method used to identify and analyze potential causes of system failures (fault tree diagram) used to understand how component failures can lead to system-wide failures

a framework for analyzing ml algorithms: hypothesis is correct with a high probability, approximately correct with an error less than a specified threshold, and correct in that it correctly classifies new samples

1. Does my software respect the humanity of the users? 2. Does my software amplify positive behavior, or negative behavior for users and society at large? 3. Will my software's quality impact the humanity of others?

transparency, crowd-source bug reports/fixes, vulnerabilities found faster, community/adoption

depending on a specific version vs pulling the latest available version with each build

packages depend on other packages

multiple intermediate dependencies have the same transitive dependency

duplicate the packages, use a global list with one version for each, use newest or oldest version