New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here


by: Sterling Schmeler


Sterling Schmeler
GPA 3.95


Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Class Notes
25 ?




Popular in Course

Popular in ComputerScienence

This 19 page Class Notes was uploaded by Sterling Schmeler on Monday October 26, 2015. The Class Notes belongs to CS1530 at University of Pittsburgh taught by Staff in Fall. Since its upload, it has received 63 views. For similar materials see /class/229393/cs1530-university-of-pittsburgh in ComputerScienence at University of Pittsburgh.

Similar to CS1530 at Pitt

Popular in ComputerScienence




Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 10/26/15
Software Engineering Testing 3 1530 sofmare Engineering Faii 2004 5 Integration testing I Bottomup I Topdown I Bigbang I Sandwich testing I Modified topdown I Modified sandwich g Example Hierarchy lt3 1530 Software Engneerng Faii 2004 g Bottomup Integration Testing Uses Component Drivers CS 1530 Software Engineerng Fall 2004 Topdown Integration Testing Uses component stubs CS 1530 Software Engineerng Fall 2004 g Modified Topdown CS 1530 Software Engineerng Fall 2004 a Big Bang Integration Testing Not advised need many drivers need many stubs hard to isolate faults CS 1530 Software Engineer ng Fall 2004 g Sandwich Testing CS 1530 Software Engineer ng Fall 2004 a Modified Sandwich Testing CS 1530 Software Engineer ng Fall 2004 Table 87 Comparison of integration strategies Bottomup T opdown Modified Bigbang Sandwich Modified topdown sandwich Integration Early Early Early Late Early Early Time to Late Early Early Late Early Early ic working program Component Yes No Yes Yes Yes Yes drivers needed Stubs No Yes Yes Yes Yes Yes needed Work Medium Low Medium High Medium High parallelism at beginning Ability to asy Hard Easy Easy Medium Easy est particular aths Ability to Easy Hard Hard Easy Hard Hard plan and control sequence Microsoft SynchandStabilize lllllemne l Mosl erltlnl tenures ml shared enmynnenlr Design nude prniniypa uhlllty iuilng rum builds Fulnnz Iniagmt n Ellmlmle severe Fault A Mllulnn 1 remain failures Dulgn Emil pintntvye Urnhlllly mung rm nII 139 Failure Integmlun Mllerlune 3 Lem irltlnl failures l Failure Integrallnn and inmylellnn karma lo manulmurlnq CS 1530 Software Engineer ng Fall 2004 Traditional vs OOTesting Easier Harder Modular v Inheritance Quicker development Polymorphism Encapiuiaiion Small methods Dynamii binding Reuse Complex Interfaces Interfaie Identified early More Integration CS 1530 Software Engineer ng Fall 004 Test planning Establish test objectives Design test cases I Write test cases Test test cases Execute tests Evaluate test results The Test Fjlan Describes how software will be demonstrated to be correct I have to know requirements specifications amp design Plan contents I series of tesB at unit integration functional acceptance amp installation level u how tests will be run and criteria when test is complete and satisfactory a law Software Engineer nq Fall 2mm IAutomated testing tools Code analysis Static analysis code analyzer structure checker Test execution 7 Capture and replay 7 Stubs and drivers 7 Automated testing I data analyzer environmems sequence checker 39 Test case generators Dynamic analySIs program monitor When to stop testing I I Coverage criteria I Fault seeding I Confidence in the software a I my gtN SSNH m4 3N mm seeded faults dztzclzd mnrseedzd faults mm seeded faults mfnl mnrseedzd faults System testing process I I Function testing does the integrated system m as promised by the requiremen specification I Performance testing are the nonfunctional requiremen 5 met I Acceptance tsting is the system what the customer expects I Installation testing does the system run at the customer Site 5 Techniques used in system testin I Build or spin plan for gradual testing I Configuration management I versions and releases I production system vs development system I deltas separate files and conditional compilation I change control I Regression testing Regression Testing I Identify faults after changes to system I because of new functionality added I because of fixes to other faults I Rerun tests after every change I compare output or previous tesB to current test I if there39s a change check if a fault c ism Software Engineer rig Fall 2mm l Configuration Management I Software revision control systems I RCS revision control system I users have loc s I CVS concurrent revision control system can concurrently edit the same file merges happen at updates cmflicts have to resolved manually I Deltas I differences between previous and current version backward delta or current and next version fonN r 39 Save con tw j t E gnq Fall 2mm ITest team I Professional testers organize and run the tests I Analysts who created requirements I System designers understand the proposed solution I Configuration management specialists to help control fixes I Users to evaluate issues that arise 1 Performance tests I Stress tests Environmental tests I I Volume tests I Quality tests I Configuration tests I Recovery tab I Compatibility tab I Maintenance tests I Regression tab I Documentation tests I Security tests I Human factors I Timing tests usabilitY tab 1 Acceptance tests I Pilot test install on experimental basis I Alpha test inhouse test I Beta test customer pilot I Parallel testing new system operates in parallel with old system Test documentation I Test plan describes system and plan for exercising all functions and characteristics I Test specification and evaluation details each test and defines criteria for evaluating each feature I Test description test data and procedures for each test I Test analysis report resulB of each test mm DATA inpuzdamav a n m s m a h w m Ru n pvvid dhym LiSTpvgmm m miyaiisz wa ms faiphanum n is n ngth m Pigmisinv x any n usrmm my uvtszdnvv m LSrBUF m mm COMMANDS m SOWHmn ism dhyusmgm mmand nun soWUNBUF ouTBUF y mam in mm ham 1 rs aw uzpuzispia mm haidamav a szdazas m n us m H hiszszay as nun sowr ownsm ifzw Pawn My us mm s ndiiszispia umouraur om ms itispia din waur sverM MESSAGES Dunngzh 5 mnng ss zh r u wngm ssag isdispiay a s mng pi as W Up H mm H n Sowmspiaysm r u wngm 558 h mng mm x u r m it Mina m man m mm H rim m is dismay aim ssooNTRoch m K yh am a w m quotk y Magnum 5mm Sammy r Mm new it ryve gym xquot a p m Mummy mm a me ie m m it mm it mg 5 mu m m itrmapnssmm ke mm sJunwzsk me mm Yype39mw39 s pm Swami Wmm mum mum in mm mm x umz V was erype my pm in H mm v gem H Wu 2quot mm 25m WW it in 5 5 mm m at aroFaw 5 Mus m nkeya m any a we En quotmenwmwmm M mm r vmmmN m we mmde pussmw k y a w En Mun Whamqu mmqu Mg m mm mm m m m 5 HM pm a p ms Mummy mm mm ie m an it mm it r m M hm m i quotimam men We 5 mm m m itrmapnssmm ke swwu stwzsknm mm Yype39mw39 a mu 5cmwummmmsnm mum in mm mm x umz s Hype m m n v qehi n ms e wmmme i2m 5 c quot5 m mimnmm at aroFaw o M my 2quot w w 25m m use I Problem report forms Location Timing I I Symptom End result Mechanism Cause Testing safetycritical systems I I Design diversity use different kinds of designs designers I Software safety cases make explicit the ways the software addrsses possible problems I failure modes and effecls analysis I hazard and operability studies I Cleanroom certifying software with respect to the specification Table 95 123 de safety analys39s Unknown 217 a Software Engineering Future of SE Dynamic Analysis in SE a ism Saftwave Engineering Fall 2mm Reviewing Wasserman s grecommendations I Abstraction I Analysis and design notations I User interface prototyping I Software architecture I Software process I Reuse I Measurement I Tools and integrated environments How to move Research into Practice Adopter types I Innovators I Early adopters I Early majority I Late majority I Laggards Sold on Ideas types of g evidence I Tangible evidence I Testimonial evidence I Equivocal testimonial evidence I Missing evidence I Accepted facts Speed of tech transfer influenced by I bg ommunication channels used to increase awareness and knowledge of the technology I The nature of the social system in which the potential user operates I The extent of efforts to diffuse the technology throughout an organization I The technology39s attributes I relative advantage I compatibility I complexity I trialability I observability Decision Making Framing Question 1 You have a 50 chance of losing 200 and a 50 chance of losing nothing Would you be Willing to pay 100 to avoid this situation Question 2 You can pay 100 to avoid a situation Where you may lose 200 or nothing Would you pay if there were a 50 chance of losing 39 stframin Program A Exactly 200 lives will be saved Program B 13 chance of saving all 600 and23 chance ofsaving none Alternate framing Program c Exactly 400 lives willbe lost Program D 13 chance that no one will die and 23 chance that 39 1 die 600 W11 39 SE Research Many many directions n One area tools to aid in the design co ing and maintenance of programs tools that are always right vs tools that useful dynamic analysisquot I Work in next slides joint research with D Atkinson C Chambers amp S Eggers 5 law sortwsre E qlneevlnq Pal 2mm Program Slicing Promise look only at the relevant parts of a program Backward slicing what may have influenced ltstatementvariablegt Forward slicing what is affected by a change to ltstatementgt 5 law sortwsre E qlneevlnq Pal 2mm g A Backward Slice sum Pmd prod 1 u l While KN d while 14 10 l sum 1 g Fwd 139 prod K 1 l prlntf d sum puntflh nquot prodl pnntwwmquot PM 5 ram Sahwave Engineering Pal 2mm Another Backward Slice 1 7 u whlle 1ltN do i sump I pmdp pnncf dnquot sump prlnzfisdxnquot prodpi 5 ram Sahwave Engineering Pal 2mm g Identifying Data Dependences Pointer analysis crucial Slice size depends on pointer analysis precusnon Reason why slices of C programs often very large 5 ram Sahwave Engineering Pal 2mm What size are slices with l Optimal Pointer Information I How much could slice size be reduced with perfect pointer information Static pointer analysis results are approximate Compared to runtime behavior very conservative 5 law Sahwave Engineering Pal 2mm g Static Pointer Analysis Computes conservative approximation of actual runtime behavior Eg as pointsto analysis p may point to Xyz Conservative resulB make dependent analyses potentially more imprecise 5 law Sahwave Engineering Pal 2mm Dynamic Pointsto Sets Observe what pointers point to at run time Lower bound on actual true pointsto seB iE DynamicpBp Q staticptsp Lower bound on pointerinduced data dependences Upper bound on slice size improvements from more precise pointer analysis 5 law Sahwave Engineering Pal 2mm Dynamic vs Static Points To Sets a b EE 3gtmqmw X E c N 00 5 ism Sahwave E a eevinq Fdl 00 2mm E I Experimerlts I Sprite slicing tool for C I Corn utes backward slice I Modified to use either Steensgaard39s pointsrto analvsis Dvnamic pommo sets I Slices I All possible criteria from executed statemenls I Varied several parameters 5 ism Sahwave E qineevinq Fdl 2mm 1 27B SPEcmm 1513 1111 sPEcmm 1909 SPECIIEU 9 SPE mm m E i a 5 93 g 59 4E2 15 245 SPECIIEU cs ism Sahwave E qineevinq Fdl 2mm Results Dereference Size lmnmvennnl Fatmr hurlau E s qa n 5 law Sahwave Enqineevinq Pal 2mm g Results FlowSet Size lmnmvennnl Fatmr Results Slice Size lmnmvennnl Fatmr 5 law Sahwave Enqineevinq Pal 2mm Improvement Factors Number of Data Dependences Classi cation of Dependences Classification of Improvements x29 x97 xm ma x25 1mm 7 m w i l 50 60 um 20 I an lunmnll Winks dma dynam vandwl A data 5 g E a 5 law Sahwave Engineering Pal 2mm g Conclusions The Good I More compact call graph a smaller slices The Bad Programs with little function pointer use benefit insignificantly The Ugly Useful slices for C programs may be hard to achieve in practice 5 law Sahwave Engineering Pal 2mm


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."

Kyle Maynard Purdue

"When you're taking detailed notes and trying to help everyone else out in the class, it really helps you learn and understand the I made $280 on my first study guide!"

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.