1 / 7

Testing Project

Testing Project. Course Software Testing & Verification 2013/14 Wishnu Prasetya. Goals : applying these in practice. Unit testing (S1) Testability (S1) Class invariants, ADT-based testing (S1) Black/gray box testing (S2) Model based testing (S2) System testing (S2)

brock-hyde
Download Presentation

Testing Project

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. Testing Project Course Software Testing & Verification 2013/14 WishnuPrasetya

  2. Goals : applying these in practice • Unit testing (S1) • Testability (S1) • Class invariants, ADT-based testing (S1) • Black/gray box testing (S2) • Model based testing (S2) • System testing (S2) • Automating your tests (S2)

  3. Setup • We’ll simulate a small software development project. Selected focus: • implementation, unit testing, and system testing • other stages of SD are ignored • Target to develop, one of these: • Breakout game • GUI-based address book • Work in pairs

  4. Stage 1 • develop a full version of the application, satisfying the requirement set of the Project Document. • Unit testing • refactor to improve testability • testing complex classes  class inv., ADT • prepare for Stage-2 : • logging user events • dealing with non-determinism • 4 weeks time, demonstration at the end.

  5. Breakout • Altered game rules to make it more challenging for testing. See Project Doc. • You can implement in any language that you want. I recommend Java or C#. • Other choices ... risky, because : • JavaScript, Haskell, ...  code coverage support? • you’ll need support for intercepting game events.

  6. Address Book • GUI-based • The application maintains multiple address books. Each is just a set of pairs (name,emailadr). • You have to check that each emailadr is valid, which involves a quite extensive set of rules. Examples:C.A.R.Hoare@logic.com Hoaref1+2=3g@logic.com tony.”tony@home.org”.hoare@logic.com ”wierd: tony@home.org”@logic.comHoare.logic.com C..Hoare@logic.com Hoare@home@logic.com not • As in Breakout, you can implement in any language you want; with the same remark too.

  7. BO vs AB, and Stage 2 • GameTech students are recommended to choose BO. • BO  testability • AB  complicated logic • We may proceed differently in Stage-2. • In Stage-2, in principle we proceed with system testing; but if unit testing is felt to be too inferior, we may decide to also implement a stronger coverage criterion in Stage-2.

More Related