1 / 17

Developing a Test Plan and Debugging

Developing a Test Plan and Debugging. MIS3502: Application Integration and Evaluation Paul Weinberg weinberg@temple.edu Presentation by David Schuff. The role of testing. What should happen…. Development. Testing. Rollout. What often does happen…. Development. Rollout. Chaos.

jovita
Download Presentation

Developing a Test Plan and Debugging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Developing a Test Plan and Debugging MIS3502: Application Integration and Evaluation Paul Weinberg weinberg@temple.edu Presentation by David Schuff

  2. The role of testing What should happen… Development Testing Rollout What often does happen… Development Rollout Chaos

  3. Types of testing • Unit Test • Does each piece work individually? • System Test (Integration Test) • Do all the pieces work together? • Acceptance Test • What do the users think of it? • We’ll focus on the system test

  4. Constructing a system test • Go back to the use cases • Deposit transaction use case • Balance inquiry transaction use case • Invalid PIN extension use case • Create scenarios for each use case • Test scripts • “Play out” those scenarios • Verify that each one is successful

  5. Try it… • For example, to test the deposit transaction • Enter “checking” for account type, $500 for amount • Verify it works • Is this enough to test the deposit transaction? • How would you test the withdrawal use case?

  6. Building a complete test plan • This obviously isn’t a complete test plan • But how many scenarios should you test • Where do you stop?

  7. Test plans in this course • Two goals • “Deliverable mentality” • Get major functions working completely, one at a time • Instead of having everything “half-working” • The application must compile or you can’t test anything! • Practice constructing and executing test plans • Start with the grading guidelines • The major functions the application should perform • Construct scenarios for each function • Try out each scenario • Create a chart like the one earlier in this presentation

  8. Create your own test plan • Create a test plan for the Movie application • Think about the use cases • How would you test each one?

  9. Debugging What a lame, obvious visual pun! • Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware thus making it behave as expected. (http://en.wikipedia.org/wiki/Debugging) • A debugger is a tool to help you do this, but you can manually debug a program

  10. Types of errors • Compile-time • Syntax errors in the application which prevent it from compiling • Runtime • Logic errors in the application which cause the application to unintentionally terminate while running

  11. The Visual Studio Debugger:StupidCalc example namespace StupidCalculator { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click(object sender, EventArgs e) { double num1 = Convert.ToDouble(textBox1.Text); double num2 = Convert.ToDouble(textBox2.Text); double ans = num1 * num2; textBox3.Text = ans.ToString(); } }

  12. Compile-time error example • Changedouble num1 = Convert.ToDouble(textBox1.Text);todouble num1 = Cnvt.ToDouble(textBox1.Text); • And you’ll get this error when you compile it:

  13. Runtime error example When you enter these values… …you get this error

  14. With the VS 2008 debugger Now when you enter these values… …you get this…

  15. The Visual Studio 2008 debugger • Helps you troubleshoot during runtime • Indicate exactly where an error has occurred • Shows you what values the program variables hold at the time of the error

  16. Using breakpoints • Allows you to troubleshoot your program before an exception occurs • View the state of the program at a point in its execution Click here to set a breakpoint. The program will pause before this line executes. We put the breakpoint here because this is the line that generated the exception.

  17. When you reach the breakpoint… • The program pauses its execution before the line executes and enters the debugger • It hasn’t thrown the exception yet • But you can seesomething bad isabout to happen!

More Related