Transcript Document

Intro. To Quality Software
- Fight the Complexity of SW
Moonzoo Kim
CS Dept. KAIST
1
Role of S/W: Increased in Everywhere
F-35 (8 Mloc)
Percent of functionality provided by
software
90
F-22
80
70
60
50
40
30
20
10
F-4
0
1960년
1970년
1982년
2000년
2012년
Year of introduction
자료출처: Watts Humphrey 2002
2
Hardware v.s. Software

Flexibility leads to low development cost



Growing popularity leads to complex software systems



Minimal costs for HW board manufacturing > 20K$
Minimal costs for SW development = 0$
Pentium IV (Willamette): 42 million transistors
Windows XP: hundreds million instructions
Much harder to validate/verify (V&V) software

HW design exploits symmetry, structure, and components

Formal design and V&V tools (e.g. Verilog, VHDL, etc) are popular


Standard property spec. language: OVL, PSL, SVA, etc
SW design allows maximal degree of freedom in programs

Formal principles and techniques have been rarely applied to SW due to




Failure to manage (entire) SW complexity
Lack of commercial tools and supports
(relatively) High learning curve
Products of all engineering fields provide warranty except SW


Ex> Intel CPU provides 3 years warranty
Ex> Microsoft Windows® provides no warranty - Use it at your own risk!!!
3
Analogy of SE with Civil Engineering
There are various kinds of
construction from a house
to a building complex
4
Analogy with Civil Engineering(Cont.)
When building a small house,...
With simple tools
From just a blueprint
By small group of
novice workers
Some failures
are endurable
5
Analogy with Civil Engineering(Cont.)
When constructing a building complex,...
we must re-think everything
6
Analogy with Civil Engineering(Cont.)
With scalable tools
as well as simple ones
Use different
materials
7
Analogy with Civil Engineering(Cont.)
By a big group of various technicians
With collaborations and guides
Set of blueprints As well as careful plans
8
Software Development Cycle
• A practical end-to-end formal framework for software
development
A SW Development Framework for SW with High Assurance
Requirement
analysis
Formal
requirement
Spec.
System
design
Design
analysis
Formal
system
modeling
Model
analysis/
verification
Implementation
Modelassisted
code
generation
9
Testing
Monitoring
Modelbased
testing
Runtime
monitoring
and
checking
.
CS Dept. KAIST
Related Disciplines to SW Development
• Undergraduate CS classes contributing to SW development
•Discrete math
•Algorithm
•PL
•Automata
Embedded
Systems
System
Engineering
System
modeling
Requirement
properties
•OS
•System programming
SW
Development •Cyber physical system
•Intro. to SE
Programming
Languages
Algorithms
OK
System
spec.
Req.
spec.
Automated
Testing &
Debugging
Logic
(F
W)
Counter
example(s)
or
Current Practice for SW Development
• SW developers have to follow systematic disciplines for
building and analyzing software with high quality
– This class focuses on the analysis activities
11
.
CS Dept. KAIST
Safety Problems due to Poor Quality of SW
12
/58
Tragic Accidents I

The Therac-25 Story

Between June 1985 and Jan
1987, a computer-controlled
radiation therapy machine,
called the Therac-25,
massively overdosed six
people

software coding error
• http://sunnyday.mit.edu/papers/therac.pdf
13
/58
Tragic Accidents II

Ariane 5

“On 4 June 1996, the maiden flight of
the Ariane 5 launcher ended in a
failure…The failure of the Ariane 501
was caused by the complete loss of
guidance and attitude information
…This loss of information was due to
specification and design errors in the
software of the inertial reference
system.”


14
Floating number conversion problem
http://www.ima.umn.edu/~arnold/disasters/ar
iane5rep.html
/58
Tragic Accidents III

NASA Mars Pathfinder (1997)


15
Priority inversion problem led to a system reset
and a one-day delay in retransmission of data
which wasted valuable mission time.
http://www.cis.ksu.edu/~hatcliff/842/Docs/CourseOverview/pathfinder-robotmag.pdf
/58
Software Crisis
Quoted from ``1. Information Technology: Transforming our Society'‘
President's Information Technology Advisory Committee 1999
“…Furthermore, the Nation needs software that is far more usable,
reliable, and powerful than what is being produced today. We have
become dangerously dependent on large software systems whose
behavior is not well understood and which often fail in unpredicted
ways ... We need scientifically sound approaches to software
development … ”
Quoted from “Science for Global Ubiquitous Computing (GUC)“
A 15 year Grand Challenges for Computing Research
Supported by UK Computing Research Committee 2004
“…unless we offer a mathematically sound methodology to
supplant the practice of opportunist software creation there will
be consequences of the kind we have illustrated, and a further
mass of inscrutable legacy software. These consequences will be
greatly more damaging than previously, because the GUC is
pervasive, self-modifying and complex in the extreme…“
16
/58
Static analysis falls short of detecting  Systematic and dynamic analysis
such complex bugs accurately
(i.e. automated sw testing) is
- High false negatives
MUST for high quality SW
Moonzoo
Kim positives
- High false
17 /58
The Essence of Software
- Operational Semantics of SW
• A software has its
semantics as a set of
system executions ’s
– A software execution 
is a sequence of states
s0.s1.s2…
• A state s has an environment
s:Var-> Val
s0
s1
s2
s3
s4
x:0,y:0
x:0,y:1
x:1,y:2
s11
x:1,y:3
s12
x:2,y:4
s13
s14
x:5,y:1
x:5,y:2
x:5,y:3
s21
x:5,y:4
s22
x:7,y:3
x:7,y:4
active type A() {
byte x;
again:
x++;
goto again;
}
Example
x:0
x:1
x:2
x:255
active type A() {
byte x;
again:
x++;
goto again;
}
active type B() {
byte y;
again:
y++;
goto again;
}
x:0,y:0
x:0,y:1
x:0,y:255
x:1,y:0
x:1,y:1
x:1,y:255
x:2,y:0
x:2,y:1
x:2,y:255
x:255,y:0
x:255,y:255
19
Testing is a Very Complex
and Challenging task!!!
Remarks by Bill Gates
17th Annual ACM Conference on Object-Oriented
Programming, Systems Languages, and Applications, 2002
• “… When you look at a big commercial software company like
Microsoft, there's actually as much testing that goes in as
development. We have as many testers as we have developers.
Testers basically test all the time, and developers basically are
involved in the testing process about half the time…”
• “… We've probably changed the industry we're in. We're not in
the software industry; we're in the testing industry, and writing
the software is the thing that keeps us busy doing all that testing.”
• “…The test cases are unbelievably expensive; in fact, there's
more lines of code in the test harness than there is in the
program itself. Often that's a ratio of about three to one.”
20
Significance of Automated SW Analysis
• Software has become more ubiquitous and more
complex at the same time
• Human resources are becoming less reliable and more
expensive for highly complex software systems
• Computing resources are becoming ubiquitous and
free
– Tencent @ China provides 10TB storage free
– Amazon EC2 price: you can use thousands of CPUs @
0.057$/hr for 3.2Ghz Quad-core CPU
• Remaining task?
– To develop automated and scientific software analysis tools
to utilize computing resource effectively and efficiently
21/58
21
SW Development and Testing Model
(a.k.a. V model)
Manual
Labor
Abstraction
22/42
Moonzoo Kim
Provable SW Lab
Ex. Testing a Triangle Decision Program
Input : Read three integer values from the command line.
The three values represent the length of the sides of a
triangle.
Output : Tell whether the triangle is
• 부등변삼각형 (Scalene) : no two sides are equal
• 이등변삼각형(Isosceles) : exactly two sides are equal
• 정삼각형 (Equilateral) : all sides are equal
Create a Set of Test Cases for this program
(3,4,5), (2,2,1), (1,1,1) ?
23/21
Moonzoo Kim
Precondition (Input Validity) Check
• Condition 1: a > 0, b > 0, c > 0
• Condition 2: a < b + c
– Ex. (4, 2, 1) is an invalid triangle
– Permutation of the above condition
• a < b +c
• b<a+c
• c<a+b
• What if b + c exceeds 232 (i.e. overflow)?
– long v.s. int v.s. short. v.s. char
• Developers often fail to consider implicit
preconditions
– Cause of many hard-to-find bugs
24/21
Moonzoo Kim
• # of test cases
required?
① 4
② 10
③ 50
④ 100
• # of feasible unique
execution paths?
• 11 paths
• guess what test
cases needed
25/21
“Software Testing
a craftsman’s
approach” 2nd ed
by P.C.Jorgensen
(no check for
positive inputs)
Moonzoo Kim
More Complex Testing Situations (1/3)
• Software is constantly changing
– What if “integer value” is relaxed to “floating value” ?
• Round-off errors should be handled explicitly
– What if new statements S1 … Sn are added to check
whether the given triangle is 직각삼각형 (a right
angle triangle)?
• Will you test all previous tests again?
• How to create minimal test cases to check the changed
parts of the target program
26/21
Moonzoo Kim
More Complex Testing Situations (2/3)
• Regression testing is essential
– How to select statements/conditions affected by the
revision of the program?
– How to create test cases to cover those
statements/conditions?
– How to create efficient test cases?
• How to create a minimal set of test cases (i.e. # of test
cases is small)?
• How to create a minimal test case (i.e. causing minimal
execution time)?
– How to reuse pre-existing test cases?
27/21
Moonzoo Kim
More Complex Testing Situations (3/3)
• However, conventional coverage is not complete
– Ex. Int adder(int x, int y) { return 3;}
• Test case (x=1,y=2) covers all statements/branches of the
target program and detects no error
• In other words, all variable values must be explored for
complete results
• Formal verification aims to guarantee
completeness
– Model checking analyzes all possible x, y values
through 264 (=232 x 232) cases
– However, model checking is more popular for
debugging, not verification
28/21
Moonzoo Kim
Concurrency
• Concurrent programs have very high complexity
p()
due to non-deterministic scheduling x=y+1
y=z+1 z=x+1
q() y=z+1
• Ex. int x=0, y=0, z =0;
void p() {x=y+1; y=z+1; z= x+1;}
void q() {y=z+1; z=x+1; x=y+1;}
– Total 20 interleaving scenarios
z=x+1
x=y+1
= (3+3)!/(3!x3!)
– However, only 11 unique outcomes
29/21
Trail1:
Trail2:
Trail3:
Trail4:
Trail5:
Trail6:
2,2,3
3,2,4
3,2,3
2,4,3
5,4,6
5,4,3
Trail7: 2,1,3
Trail8: 2,3,3
Trail9: 4,3,5
Trail10: 4,3,2
Trail11: 2,1,2
An Example of Mutual Exclusion Protocol
char cnt=0,x=0,y=0,z=0;
void process() {
char me=_pid +1; /* me is 1 or 2*/
again:
x = me;
Software
If (y ==0 || y== me) ;
locks
else goto again;
z =me;
If (x == me) ;
else goto again;
y=me;
If(z==me);
else goto again;
}
/* enter critical section */ Critical
cnt++;
section
assert( cnt ==1);
cnt --;
goto again;
Mutual
Exclusion
Algorithm
30
Process 0
x=1
If(y==0 || y == 1)
z=1
If(x == 1)
y=1
If(z == 1)
cnt++
Process 1
x=2
If(y==0 || y ==2)
z=2
If(x==2)
y=2
If (z==2)
cnt++
Violation detected !!!
Counter
Example
More Concurrency Bugs
• Data race bugs
• Atomicity bugs
class Account_DR {
double balance;
// INV:balance should be always non-negative
class Account_BR {
Lock m;
double balance;
// INV: balance should be non-negative
void withdraw(double x) {
1: if (balance >= x) {
2: balance = balance–x;}
...
}}
double getBalance() {
double tmp;
1: lock(m);
2: tmp = balance ;
3: unlock(m);
4: return tmp; }
(a) Buggy program code
[Initially, balance:10]
-th1: withdraw(10)-
-th2: withdraw(10)1: if(balance >= 10)
1: if(balance >= 10)
2: balance = 10-10;
2: balance = 0 – 10;
The invariant is violated as
balance becomes -10.
(b) Erroneous execution
31
void withdraw(double x){
/*@atomic region begins*/
11: if (getBalance() >= x){
12: lock(m);
13: balance = balance – x;
14: unlock(m); }
/*@atomic region ends*/
... }
(a) Buggy program code
[Initially, balance:10 ]
-th1: withdraw(10)operation block bi
11:if(getBalance()>=10)
getBalance()
1:lock(m);
2:tmp = balance;
3:unlock(m);
4:return tmp;
12: lock(m);
13: balance=0 – 10;
14: unlock(m);
-th2 : withdraw(10)...
12: lock(m);
13: balance=10–10;
14: unlock(m);
The invariant is violated as
balance becomes -10.
(b) Erroneous execution
Software v.s. Magic Circle (마법진)
• Written by a software
developers line by line
• Written by a human
magician line by line
• Requires programming
expertise
• Requires magic spell
knowledge
• SW executes complicated • Summoned monsters
are far more powerful
tasks which are far more
than the magic spell
complex than the code
itself
itself
• The software often
behaves in unpredicted
ways and crash occurs
• The summoned demon
is often uncontrollable
and disaster occurs
네이버 웹툰 “그 판타지 세계에서 사는법“ by 촌장
32/58
/4
Research Trends toward Quality Systems
• Academic research on developing embedded systems has reached stable stage
– just adding a new function to a target system is not considered as an academic
contribution anymore
• Research focus has moved on to the quality of the systems from the mere
functionalities of the systems
– Energy efficient design, ez-maintenance, dynamic configuration, etc
• Software reliability is one of the highly pursued qualities
– ASPLOS 2011 Best paper
• “S2E: a platform for in-vivo multi-path analysis for software systems” @ EPFL
– OSDI 2008 Best paper
• “Klee: Unassisted and Automatic Generation of High-Coverage Tests for Complex
Systems Programs” @ Stanford
– NSDI 2007 Best paper
• “Life, Death, and the Critical Transition: Finding Liveness Bugs in Systems Code” @
U.C. San Diego
33
Formal Analysis of Software as a Foundational and
Promising CS Research
• 2007 ACM Turing Awardees
– Prof. Edmund Clarke, Dr. Joseph
Sipfakis, Prof. E. Allen Emerson
– For the contribution of migrating
from pure model checking research
to industrial reality
• 2013 ACM Turing Awardee
– Dr. Leslie Lamport
– For fundamental contributions to the theory
and practice of distributed and concurrent
systems
• Happens-before relation, sequential consistency,
Bakery algorithm, TLA+, and LaTeX
34
Companies Working on Software Testing/Verification Tools
35/14
Summary
1. Software = a large set of unique executions
2. SW testing = to find an execution that violates
a given requirement among the large set
– A human brain is poor at enumerating all
executions of a target SW, but computer is good at
the task
3. Automated SW testing
= to enumerate and analyze the executions of
SW systematically (and exhaustively if possible)
36
37
소프트웨어 구성요소와 테스팅
Spec
Program
• 소프트웨어의 기능을 구현한 코드의
집합으로 구성
3. 실행
• 요구사항 spec, 시스템 model로 구성됨
• 소프트웨어에 기대하는 기능을
추상적으로 기술한 것
Test case
• 프로그램 입력 값과 그에 해당하는
기대 출력 값의 쌍(pair)으로 구성됨
소프트웨어 테스팅 품질
1. 요구사항 spec이 test case로 모두 올바르게 표현됐는가?
 시나리오 기반 테스팅
2. 시스템 model이 Program 요소로 모두 올바르게 구현됐는가?
 모델 기반 테스팅
3. Program의 코드가 test case로 모두 올바르게 실행되는가?
 코드 기반 테스팅 (white-box testing)
2015-07-17
38
Limitations of the Conventional Quality
Assurance Techniques
• Most QA techniques in industry practice target easy-todetect bugs at low cost (i.e., light-weight approaches)
– Secure coding rule checkers:
• MISRA C, CERT C Coding standard, CERT Oracle secure coding standard
– Static analyzer:
• Coverity, Sparrow, Code sonar, Findbugs
– Various random + heuristic test case generation techniques
• Suresoft codescroll
• Such techniques often fail to detect hard-to-detect
corner case bugs because
– These techniques focus to analyze the syntax (i.e.,
form/appearance) of a target program
– However, the difficulty/complexity is caused by the
semantics (i.e., meaning) of a target program.
39/58
Moonzoo Kim