Post on 21-Dec-2015
2
Administrivia
There will be group reorganization Got a problem? Let us know ASAP Samples coming soon…
4
Integration?
Not really separate from Implementation, but traditionally thought of as such
Schach calls it the “Implementation and Integration phase”
Why? (2 reasons)
5
Implementation needs integration (I)
Here, a calls b, c, and d
You can’t test a until you attempt to integrate with b, c, and d
Code stubs of b, c, and d
For b: need driver for a, stub for e
6
Stubs and drivers
Essentially empty modules Usually prints debugging info Stubs
– Get called upon– Might return a canned answer
Drivers– Call others– Also prints some debugging
7
Implementation needs integration (II)
Consider a really complex set of modules Each time you integrate, fault isolation becomes
harder Additionally, possibility for faults increase Can’t work completely independently until the last
day Even with OO Need to combine module and integration testing
8
Top-down I&I
Implement and integrate starting from the top Create stubs for subsidiary components Fill in the stubs later Good: major fundamental flaws shown early:
better to test logic first
9
Problems with top-down
Difficult to test actual low-level functions (reusable components)– The top-level gets tested n times– Bottom-level gets tested once– Defensive programming a liability?
if (x >= 0) computeSquareRoot
10
Bottom-up I&I
Build drivers, fill them in later Design flaws not shown early, but low-level
components very well tested– Huge cost to redesign
Conclusion: need to combine both
11
Sandwich I&I
Simple idea: work from both ends
Tests logic, as well as reusable components
Schach claims infinite upside from this model
– Reality: a bit more complex to organize
– Need both stubs and drivers
12
OO I&I
Needed to include in a “Object Oriented Software Engineering” book
Basically, works the same as classical I&I
13
Management issues during I&I
What if the pieces don’t fit together? What do Phil and I do if server and client don’t
talk?– Happens more often than you think…
Have integration run by SQA– One well-contained group to integrate
14
Testing I&I
Incremental testing: as each new module is integrated, must already be tested separately, then continue testing
GUI: can’t use simple test cases– Special CASE tools actually record mouse clicks,
etc. Product testing when integration is complete,
followed by acceptance testing
15
Product testing
SQA has to do extra testing, especially with COTS software
– Alpha and beta phases With custom software, make sure acceptance test
won’t fail: would be bad– Black-box tests for whole product– Robustness (crash?)– Constraints met (such as time bounds)– Documentation review
Use “scenarios”
16
Acceptance testing
Does product satisfy client requirements/developer specifications?
Supervised/independent SQA or client does this
Must be performed on actual data Often, new product run in parallel with old for a
while
17
CASE tools
Versioning and configuration management Build tools Environments: UI integration, tool integration,
process integration: these support/automate the manual process– CMM levels needed
Others
18
Metrics
Complexity metrics Total number of test cases and failures Number of faults/types of faults
19
Key Security Concepts
Privacy Authentication Authorization Non-repudiability Symmetric vs. Asymmetric keys Key management One-way hashes
20
Privacy
Social issues Carnivore, Echelon Linking of databases Surveillance Control over computer records
21
Encryption
What we usually associate with crypto Scrambling plaintext so that it’s unreadable Should be resistant to attacks
– Even if attacker has unlimited access to plaintext/encrypted text pairs
– Even if (especially if) encryption algorithm is known Do not try to invent one on your own
– Rot-13
22
One-way Hashes
Also called Message Digests Like hash function, but less predictable Given a message and its digest,
computationally infeasible to alter the message without changing the digest
Encrypt digest with private key = electronic signature
23
Public key crypto challenges
Asymmetric encryption is very slow– Need large keys (128-bit or more) so that guessing private key
is difficult– Solution: use a symmetric key to encode message, and then
encrypt the symmetric key using asymmetric keys– Attach said symmetric key to rest of message
Keys need to be trusted– Public key: man-in-the-middle attack– Private key: local machine compromise– Solutions exist for both
24
Implications of public key Internet-scale cryptography possible Allowed for creation of tools like SSL, PGP
– Encryption more powerful than government can decrypt
– Significant social implications now
Still, some problems– Government wants backdoors– Key trust: people do, blindly (including me!)
25
One-way hashes
Also called “message digests” Like a hash function, but less predictable Take a message and generate this “garbage”
out of it If message changes, garbage will as well Difficult (impossible?) to reverse engineer
garbage to original message Simpler and faster than encryption
26
Applications of one-way hashes As long as you don’t need to know the original
message… or already know it Signatures: create a digest of stuff to be encrypted,
and encrypt it with private key– http://www.youdzone.com/signature.html
Crypt-ing passwords– You don’t care what the password is– If someone grabs the crypt, they can use it, but much more
limited– Not at all foolproof, just limits damage