CS代考 SENG201

Software Engineering I SENG201

Lecture 13 – Software testing (part 1) March 21, 2022

Copyright By PowCoder代写 加微信 powcoder

Previous lecture
1. Substitutability and conversion
2. Inheritance and interfaces
3. Abstract classes

1. Overview
2. Types of testing
3. Black box testing and white box testing

1. Overview
2. Types of testing
3. Black box testing and white box testing

Why should we test?
Does my software work?
Functionality
Quality attributes1
See also: verification = checking that program matches specification; “you built it right”
1 Quality attributes (“non-functional” requirements): performance, security, safety, etc. experienced by customers; maintainability, portability, etc. relevant for developers
(see previous lectures). Also, does software not only work for one user/request, but also for two, ten, hundreds and thousands of users (potentially at the same time)?

Why should we test?
Does my software meet its requirements?
How system was planned based on user needs
How system was implemented
*See also: validation = making sure program meets requirements; “you built the right thing”

Why should we test?
I’ve changed something – does my software still work?
Carriage Battleship
Improve maintainability and reusability
<> Flyable
<> Powered
CivilianVehicle
MilitaryVehicle
Basic types of changes
1. Adding functionality 2. Fixing bugs
3. Refactoring

Battleship

Many flavours
… and many more

Software fault
• Weakness in design or implementation
– Static defect in software – root cause of error
• E.g., mistake in coding, incorrect step, process, or data definition
– “As ‘developers’ see it”
– May cause error when exact scenario is met
int countSpaces(String s) {
int count = 0;
for(int i = 1; i < s.length(); i++) return count; if(s.charAt(i) == ‘ ’) count++; i should be 0 Software error • Incorrect internal state that is manifestation of some fault – Computed, observed, measured vs true, specified, theoretically correct – Likely not visible to end user (variable values, memory, etc.) – “As ‘testers’ see it” – May lead to failure when exact scenario is met int countSpaces(String s) { int count = 0; for(int i = 1; i < s.length(); i++) return count; if(s.charAt(i) == ‘ ’) count++; Point in the program where we have incorrect number of spaces Software failure • “User-visible” manifestation of error – Incorrect behaviour with respect to expected behaviour – “As‘testers’,‘users’,seeit” int countSpaces(String s) { int count = 0; for(int i = 1; i < s.length(); i++) return count; if(s.charAt(i) == ‘ ’) count++; • countSpaces(“H H H”); no failure • countSpaces(“ H”); failure 1. Overview 2. Types of testing 3. Black box testing and white box testing Unit testing • Test specific functionality of a unit – Small unit of code: function, method, class (not larger than a class) – Target: low-level design and actual code structure – Module testing: larger scale package Integration testing • How things fit together, interfaces between components – Multiple classes, modules, interactions – Target: low-level and high-level design – At the end (“big bang”): when all units / modules are ready – Incremental: as each component is integrated (“continuous integration”) Unit / module 1 Unit / module 2 System testing • Test entire program (including hardware) – Whole product in representative environment – Target: ensure requirements Acceptance testing • Aka “functional testing” – Whole product in customer (or “real”) environment • Customer approval – May be agreed with user story and acceptance criteria – May be based on use cases, scenarios How it fits together Catch bugs early and minimize debugging Unit testing Module testing Integration testing System testing Requirements Acceptance testing Client needs Other types – regression testing • Evolving system must – Pass old tests (or they need to be revised) – Passnewtests • Goal: automated test suites to regularly check for regressions Requirements/features Version 1 Version 2 Version 3 Version 4 Other types – mutation testing • “Test the test” (rather than the program) – Test the test data to evaluate quality of tests • If program is modified, does test still detect defective code? – “Mutate”: change statement in test or test code – Do tests still catch problems? 1. Overview 2. Types of testing 3. Black box testing and white box testing Black box testing Black box – SUT* (executable program, component, etc.) *SUT = “System under test” No knowledge of internal implementation (only interface) No access to source code (Minimalistic) structure of a test case Test description Expected results Actual results • Preparations + preconditions for test • Input for particular condition to test • Steps for particular condition to test • Expected outcome based on input • Recorded after run • Pass or fail • Reason for result • Example: board game Test description Expected results Actual results • Precondition: test mode • Board game is loaded, game begins • Number of players: 2 • Money for player 1: $1 • Money for player 2: $1 • Player 1 dice roll: 3 • Player 1 is located on field Blue 3 Example – bad Test description Expected results Actual results Player 1 rolls dice and moves Player 1 moves on board Player 2 rolls dice and moves Player 2 moves on board What is the state of the program that makes test pass or fail? Define precisely when test passes/fails (condition, situation, context, etc.) White box testing White box – SUT* (executable program, component, etc.) Know program implementation structure Access to source code Types of tests and opacity Testing type Who does it? • White box Programmer who wrote code Integration • White box • Black box Programmer(s) who wrote code Other programmers, independent testers • Black box “Customer” Acceptance • Black box “Customer” Regression • White box • Black box Programmer(s) or independent testers What are test cases based on? • Requirements • Specified behavior • Unit (or module) interfaces • Internal structure • Algorithms, control paths • Goal when defining test cases Ensure proper use of SUT, e.g., • Incorrect, missing functionality • Interface, initialization, termination • Quality problems Successfully follow possible branches, e.g., • true/false in if-else • zero, 1, n in for/while 1. Overview 2. Types of testing 3. Black box testing and white box testing Cartoon of the day Key lesson: Different types of testing complement each other. Testing with end users may identify unexpected user behaviour that was not anticipated at design time. https://me.me/i/unittests-passing-nointegrationitests-unit-tests-passing-no-integration-tests-53c8003af57f45e4be46960b62cf6627 程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com