DOC PREVIEW
PSU CSE 420W - System Testing

This preview shows page 1-2-20-21 out of 21 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

System TestingCauses of Software FaultsSystem Testing ProcessSlide 4Build & Integration PlanBuild & Integration Plan Cont’dConfiguration ManagementRegression TestingSource & Version ControlTest TeamFunction TestingPerformance TestingReliability,Availability,MaintainabilityAcceptance TestingDeployment TestingSafety-Critical SystemsSafety-Critical System IssuesHazard and Operability StudiesCleanroomCleanroom ProcessReadSystem TestingSystem TestingUnit & Integration Testing Objective: to make sure that the program code implements the design correctly.System Testing Objective: to ensure that the software does what the customer wants it to do.Causes of Software FaultsCauses of Software FaultsSystem Testing ProcessSystem Testing ProcessFunction Testing: the system must perform functions specified in the requirements.Performance Testing: the system must satisfy security, precision, load and speed constrains specified in the requirements.Acceptance Testing: customers try the system (in the lab) to make sure that the system built is the system they requested.Deployment Testing: the software is deployed and tested in the production environment.System Testing ProcessSystem Testing ProcessBuild & Integration PlanBuild & Integration Plan- Large complex system is very hard to test.+ We can devise a build & integration plan defining subsystems to be built and tested such that we are managing a less complex entity. Such subsystems usually correspond to increments in system scope & functionality and are called spins.Example: Microsoft’s Synch & Stabilize approach.Build & Integration Plan Cont’dBuild & Integration Plan Cont’dEach spin is identified including its functionality and testing schedule.If the test of spin n succeeds but the problem arises during the testing of spin n+1 we know that the fault comes from components / functionality introduced in spin n+1.Accounting System Example: spin 0 – basic accounting operations are tested; spin 1 – accounting with data auditing tested; spin 2 – access user control is tested, etc.Configuration ManagementConfiguration ManagementModule-based systems can be shipped in various configurations of components defining the system’s functionality and performance.Different configurations are referred to as product versions or product editions.Sequential modifications of a configuration corresponding to product releases are identified as major versions.Sequential modifications of the same major release configuration are identified by minor versions.During development & testing current pre-release version is identified by the build number.Product Edition V Major . Minor . Build NumberE.g. Sonar Producer v 5.1.1012Keeping track of version is a must for phased development!Regression TestingRegression TestingRegression testing ensures that no new faults are introduced when the system is modified, expanded or enhanced as well as when the previously uncovered faults are corrected.Procedure:1. Insert / modify code2. Test the directly affected functions3. Execute all available tests to make sure that nothing else got brokenInvaluable for phased development!Unit testing coupled with nightly builds serves as a regression testing tool for agile methodology.Source & Version ControlSource & Version ControlOpen Source: CVS flavorsMicrosoft: Visual Source Safe, TFS•Each version is stored separately•Delta changes•Modification comments•Revision history including usersDo not use conditional compilation for tasks other than debugging, tracing or checked builds.Test TeamTest TeamTesters: devise test plans, design, organize and run testsAnalysts: assist testers, provide guidance for the process verification as well as on the appearance of the test resultsDesigners: assist testers, provide guidance for testing components and software architectureUsers: provide feedback for the development teamFunction TestingFunction TestingThread Testing: Verifying a narrow set of actions associated with a particular functionTest process requirements•Test plan including the stopping criteria•High probability for detecting a fault•Use of independent testers•The expected actions and the expected output must be specified•Both valid and invalid input must be tested•System must not be modified in the testing process (or to make testing easier)Performance TestingPerformance TestingLoad / Stress Testing: large amount of users / requestsVolume Testing: large quantities of dataSecurity Testing: test access, authentication, data safetyTiming Testing: for control and event-driven systemsQuality / Precision Testing: verify the result accuracy (when applies)Recovery Testing: verify recovery from failure process (when applies)Reliability,Availability,MaintainabilityReliability,Availability,MaintainabilityReliability: the probability of software operating without failure under given conditions for a given time interval T.R = MTTF/(T+MTTF)Availability: the probability of software operating without failure at a given moment in time.MT(Between Failures) = MT(To Failure)+MT(To Repair)A = MTBF/(T+MTTF)Maintainability: the probability of successful software maintenance operation being performed within a stated interval of time.M = T/(T+MTTR)Acceptance TestingAcceptance TestingThe purpose is to enable customers and users to determine if the system built really meets their needs and expectations.Benchmarking: a predetermined set of test cases corresponding to typical usage conditions is executed against the systemPilot Testing: users employ the software as a small-scale experiment or in a controlled environmentAlpha-Testing: pre-release closed / in-house user testingBeta-Testing: pre-release public user testingParallel Testing: old and new software are used together and the old software is gradually phased out.Acceptance testing uncovers requirement discrepancies as well as helps users to find out what they really want (hopefully not at the developer’s expense!)Deployment TestingDeployment TestingThe software is installed on a target system and tested with:•Various hardware configurations•Various supported OS versions and service packs•Various versions of third-party components (e.g. database servers, web servers, etc.)•Various configurations of resident softwareSafety-Critical SystemsSafety-Critical SystemsSafe means free from accident or loss.Hazard: a system state that, together with the right conditions, can lead to an accident.Failure Mode: a situation that can lead to a


View Full Document

PSU CSE 420W - System Testing

Download System Testing
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view System Testing and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view System Testing 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?