CMPE 131 FINAL SJSU
Development testing includes all testing activities
Unit testing, component testing, and system testing
Dynamic models
describe the interactions between objects
Structural models
describe the static structure of the system in terms of object classes and relationships.
Program testing
Testing is intended to show that a program does what it is intended to do and to discover program defects before it is put into use.
Design patterns
a way of reusing abstract knowledge about a problem and its solution
Interface types:
Parameter interfaces, shared memory interfaces, procedural interfaces, and message passing interfaces
Testing Strategies:
Partition testing and guideline-based testing
Security
The security of a system is a system property that reflects the system's ability to protect itself from accidental or deliberate external attack.
Experience-based testing
The system is reviewed and analyzed against the types of attack that are known to the validation team
Formal verification
The system is verified against a formal security specification
The output of the architectural design process is
an architectural model that describes how the system is organized as a set of communicating components.
Agile methods
are based on incremental development so the transition from development to evolution is a seamless one.
Inspections and testing
are complementary and not opposing verification techniques
Legacy systems
are older systems that rely on languages and technology that are no longer used for new systems development.
Component testing
where several individual units are integrated to create composite components. Component testing should focus on testing component interfaces.
System testing
where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on testing component interactions
Development testing
where the system is tested during development to discover bugs and defects.
User testing
where users or potential users of a system test the system in their own environment
call part
where you call the object or method to be tested
setup part
where you initialize the system with the test case, namely the inputs and expected outputs
Guideline-based testing
where you use testing guidelines to choose test cases.
Operational security
which is concerned with the secure operation and use of the organization's systems
development view
which shows how the software is decomposed for development. (Partition work)
Beta testing
· A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.
physical view
· shows the system hardware and how software components are distributed across the processors in the system. (SW/HW mapping)
State machine models
· that show how individual objects change their state in response to events.
Release testing
· where a separate testing team test a complete version of the system before it is released to users.
Unit testing
· where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.
Problem tracking
· where support is provided to allow users to report bugs and other problems, and to allow all developers to see who is working on these problems and when they are fixed.
Regression testing
is the process of testing a particular release of a system that is intended for use outside of the development team.
Sequence models
· that show the sequence of object interactions.
How to write a secure code?:
1.Limit the visibility of information in a program 2.Check all inputs for validity 3.Provide a handler for all exceptions 4.Minimize the use of error-prone constructs 5.Provide restart capabilities 6.Check array bounds 7.Include timeouts when calling external components 8.Name all constants that represent real-world values
Penetration testing
A team is established whose goal is to breach the security of the system by simulating attacks on the system
Types of user testing:
Alpha testing, beta testing, and acceptance testing
Use of architectural models
As a way of documenting an architecture that has been designed (most updated common understanding) The aim here is to produce a complete system model that shows the different components in a system, their interfaces and their connections.
Shared memory interfaces
Block of memory is shared between procedures or functions
Security dimensions:
Confidentiality, integrity, and availability
Parameter interfaces
Data passed from one method or procedure to another
Stages of testing:
Development testing, release testing, and user testing
Security validation:
Experience-based testing, Penetration testing, Tool-based analysis, and Formal verification
Fundamental security
If a system is a networked system and is insecure then statements about its reliability and its safety are unreliable.
Security levels:
Infrastructure security, application security, and operational security
Architecture and system characteristics
Performance · Localize critical operations and minimize communications. Use large rather than fine-grain components. Security · Use a layered architecture with critical assets in the inner layers. Safety · Localize safety-critical features in a small number of sub-systems. Availability · Include redundant components and mechanisms for fault tolerance. Maintainability · Use fine-grain, replaceable components architectural views
Implementation issues:
Reuse, configuration management, and host-target development
Security requirements classification:
Risk avoidance, risk detection, and risk mitigation
Model view controller
Separates presentation and interaction from the system data. The system is structured into three logical components that interact with each other. The Model component manages the system data and associated operations on that data. The View component defines and manages how the data is presented to the user. The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model.
Architectural representations
Simple, informal block diagrams showing entities and relationships are the most frequently used method for documenting software architectures.
Advantages of explicit architecture
Stakeholder communication · Architecture may be used as a focus of discussion by system stakeholders. System analysis · Means that analysis of whether the system can meet its functional and non-functional requirements. Large-scale reuse · The architecture may be reusable across a range of systems · Product-line architectures may be developed.
two kinds of design model
Structural model and dynamics models
Procedural interfaces
Sub-system encapsulates a set of procedures to be called by other sub-systems
Message passing interfaces
Sub-systems request services from other sub-systems
Legacy system components:
System hardware, Support software, Application software, Application data, and business process
Object class testing:
Testing all operations associated with an object Setting and interrogating all object attributes Exercising the object in all possible states.
Business processes
These are processes that are used in the business to achieve some business objective
Security engineering
Tools, techniques and methods to support the development and maintenance of systems that can resist malicious attacks that are intended to damage a computer-based system or its data.
User testing
User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing.
Tool-based analysis
Various security tools such as password checkers are used to analyze the system in operation
Configuration management activities:
Version management, system integration, and problem tracking
Security specification
has something in common with safety requirements specification - in both cases, your concern is to avoid something bad happening.
Interaction model
is a dynamic model that shows how the system interacts with its environment as it is used.
Stress testing
is a form of performance testing where the system is deliberately overloaded to test its failure behavior.
Application security
is a software engineering problem where the system is designed to resist attacks.
Context model
is a structural model that demonstrates the other systems in the environment of the system being developed.
Infrastructure security
is a systems management problem where the infrastructure is configured to resist attacks
Test-driven development (TDD)
is an approach to program development in which you inter-leave testing and code development.
Architectural design
is concerned with understanding how a software system should be organized and designing the overall structure of that system. the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them.
Risk mitigation
requirements set out how the system should be designed so that it can recover from and restore system assets after some loss has occurred
Automated test components:
setup part, call part, and assertion part
Design models
show the objects and object classes and relationships between these entities.
Subsystem models
that show logical groupings of objects into coherent subsystems.
Release testing and System testing differences
· A separate team that has not been involved in the system development, should be responsible for release testing. · System testing by the development team should focus on discovering bugs in the system (defect testing). The objective of release testing is to check that the system meets its requirements and is good enough for external use (validation testing).
Availability
· Access to a system or its data that is normally available may not be possible.
Servicing (mature, no more new function)
· At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and changes to reflect changes in the software's environment. No new functionality is added.
MVC controller objects
· Coordinate the model and view objects. o Often have no physical counterpart in the real world. o Closely related to a use case. o Collect information from view objects for dispatch to model objects. o This is how user-entered data can update the model.
Acceptance testing
· Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems.
Stages in the acceptance testing process:
· Define acceptance criteria · Plan acceptance testing · Derive acceptance tests · Run acceptance tests · Negotiate test results · Reject/accept system
Configuration management
· During the development process, you have to keep track of the many different versions of each software component in a configuration management system.
Types of security requirement:
· Identification requirements. · Authentication requirements. · Authorization requirements. · Immunity requirements. · Integrity requirements. · Intrusion detection requirements. · Non-repudiation requirements. · Privacy requirements. · Security auditing requirements. · System maintenance security requirements.
Integrity
· Information in a system may be damaged or corrupted making it unusual or unreliable.
Confidentiality
· Information in a system may be disclosed or made accessible to people or programs that are not authorized to have access to that information.
System hardware
· Legacy systems may have been written for hardware that is no longer available.
Reuse
· Most modern software is constructed by reusing existing components or systems. When you are developing software, you should make as much use as possible of existing code.
Host-target development
· Production software does not usually execute on the same computer as the software development environment. Rather, you develop it on one computer (the host system) and execute it on a separate computer (the target system).
Design and Implementation
· Software design and implementation is the stage in the software engineering process at which an executable software system is developed. · Software design and implementation activities are invariably inter-leaved. · Software design is a creative activity in which you identify software components and their relationships, based on a customer's requirements.
Examples of Design models
· Subsystem models · Sequence models · State machine models
Application software
· The application system that provides the business services is usually made up of a number of application programs.
Support software
· The legacy system may rely on a range of support software, which may be obsolete or unsupported. [language, compiler, library]
Phase-out (stable, no more change -> legacy)
· The software may still be used but no further changes are made to it.
Evolution (growing)
· The stage in a software system's life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system.
Application data
· These are data that are processed by the application system. They may be inconsistent, duplicated or held in different databases.
Validation testing
· To demonstrate to the developer and the system customer that the software meets its requirements · A successful test shows that the system operates as intended.
Defect testing
· To discover faults or defects in the software where its behavior is incorrect or not in conformance with its specification · A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system.
Alpha testing
· Users of the software work with the development team to test the software at the developer's site.
MVC view objects
· View objects represent user interface components. · In each use case, actors interact with at least one view object. · A view object collects information from actors in a form that the model and controller objects can use.
Program testing:
· When you test software, you execute a program using artificial data. · You check the results of the test run for errors, anomalies or information about the program's non-functional attributes. · Can reveal the presence of errors NOT their absence. · Testing is part of a more general verification and validation process, which also includes static validation techniques.
Risk detection
· requirements define mechanisms that identify the risk if it arises and neutralise the risk before losses occur.
Risk avoidance
· requirements set out the risks that should be avoided by designing the system so that these risks simply cannot arise.
process view
· shows how, at run-time, the system is composed of interacting processes. (runtime/dynamic view)
logical view
· shows the key abstractions in the system as objects or object classes. (static view)
System integration
· where support is provided to help developers define what versions of components are used to create each version of a system. This description is then used to build a system automatically by compiling and linking the required components.
Version management
· where support is provided to keep track of the different versions of software components. Version management systems include facilities to coordinate development by several programmers.
assertion part
· where you compare the result of the call with the expected result. If the assertion evaluates to true, the test has been successful if false, then it has failed.
Partition testing
· where you identify groups of inputs that have common characteristics and should be processed in the same way.
Infrastructure security
· which is concerned with maintaining the security of all systems and networks that provide an infrastructure and a set of shared services to the organization.