8
1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual coding!) Maintenance and bug tracking “Compile-time” testing – warnings, static analysis, build systems Testing, testing, testing

1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual

Embed Size (px)

Citation preview

Page 1: 1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual

1

Welcome to CS 362

Applied Software Engineering• Dr. Alex Groce (KEC 3067)

Testing, debugging, running programs• Design for testability• Implementation (actual coding!)• Maintenance and bug tracking• “Compile-time” testing – warnings, static

analysis, build systems• Testing, testing, testing

Page 2: 1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual

2

Today

We’re just going to talk a bit, and think a bitDifferent perspective on code than in most

of your previous classes

Solicit your opinion: write more code, or test more code?

Page 3: 1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual

3

Before we start

What do I know about testing, anyway?• I’ve written programs and tested them

• So have most of you, I would bet• Split my time at JPL (before I came to OSU)

between model checking & testing research• E.g., testing the file systems that will be used in

the Mars Science Laboratory – JPL’s next big Mars mission

Page 4: 1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual

4

Let’s Talk about Civil Engineering

Page 5: 1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual

5

Let’s Talk about Civil Engineering

Galileo

Page 6: 1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual

6

We’re Engineers. Really.

What is similar to other engineering disciplines?

Page 7: 1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual

7

We’re Engineers. Really.

What is different?

Page 8: 1 Welcome to CS 362 Applied Software Engineering Dr. Alex Groce (KEC 3067) Testing, debugging, running programs Design for testability Implementation (actual

8

You are given a library, container.o and the following .h file:

int put (int n, container* c); /* returns 1 and adds to c if n not in c, otherwise returns 0 */

int get (int n, container* c); /* returns 1 if n is in c, 0 otherwise */int remove (int n, container* c); /* returns 1 if n was in c; after

return n is not in c! */container* newContainer(); /* returns a new container if memory avail */

You don’t have source code, and the file isn’t compiled with debugging information. Attached is a note: “We would like to use this (it’s really fast) in our new system, but it needs to work well – a bug in this could be catastrophic. Can you give me a plan/approach for thorough testing? I don’t want to share our test generation code with the company that wrote this, and they won’t share source, but you can give them test cases. The programmer behind this at Container Code Design, LLC, is pretty busy, so we’d like to make sure to get good turnaround from debugging. Can I get a short white paper on this by this afternoon’s 2:35 project meeting? I know it’s short notice, and you’re not really a test engineer, but we need something.

Think-piece