Software Engineering
Dr Kingsley Sage
Copyright By PowCoder代写 加微信 powcoder
• Development testing
– Test-driven development
• Release testing • User testing
• Testing is intended to show that a program does what it is intended to do and to discover program defects before it is put into use.
• When you test software, you execute a program using artificial data.
• You check the results of the test run for errors, anomalies or information about the program’s non-functional attributes.
• Can reveal the presence of errors NOT their absence.
• Testing is part of a more general verification and validation process, which also includes static validation techniques.
Verification vs validation
• Verification:
– “Are we building the product right”.
– The software should conform to its specification.
• Validation:
– “Are we building the right product”.
– The software should do what the user really requires.
V and V confidence
• Aim of V & V is to establish confidence that the system is ‘fit for purpose’.
• Depends on system’s purpose, user expectations and marketing environment
• Software purpose
– The level of confidence depends on how critical the software is to an organisation.
• User expectations
– Users may have low expectations of certain kinds of software.
– Marketing environment
– Getting a product to market early
Stages of testing
• Development testing:
– System is tested during development to discover bugs and defects.
• Release testing:
– Separate testing team tests a complete version of the system before it is released to users.
• User testing:
– Where users or potential users of a system test the system in their own environment.
Development testing
• Unit testing:
– Individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.
• Component testing:
– Several individual units are integrated to create composite components. Component testing should focus on testing component interfaces.
• Development system testing:
– The system is tested as a whole.
– System testing should focus on testing component interactions.
Unit testing
• We already looked at this.
• Testing individual components in isolation.
• Defect testing process.
• Units may be:
– Individual functions or methods within an object
– Object classes with several attributes and methods
– Composite components with defined interfaces used to access their functionality.
• Can generally be automated (e.g. using Junit test classes)
Automated testing
• A setup part:
– You initialize the system with the test case.
• A call part:
– you call the object or method to be tested.
• An assertion part:
– You compare the result of the call with the expected result. If the assertion evaluates to true, the test has been successful if false, then it has failed.
Automated testing using JUnit test class
Unit test effectiveness
• If there are defects in the component, these should be revealed by test cases.
• This leads to 2 types of unit test case:
– The first of these should reflect normal operation of a program and should show that the component works as expected.
– The other kind of test case should be based on testing experience of where common problems arise. It should use abnormal inputs to check that that these are properly processed and do not crash the component.
Testing strategies
• Partition testing, where you identify groups of inputs that have common characteristics and should be processed in the same way.
– You should choose tests from within each of these groups.
• Guideline-based testing, where you use testing guidelines to choose test cases.
– These guidelines reflect previous experience of the kinds of errors that programmers often make when developing components.
Partitions
Testing guidelines
• Testing software with sequences which have only a single value (i.e. an array of numbers – each element of the array holds a single number)
– Use sequences of different sizes in different tests.
– Derive tests so that the first, middle and last elements of the sequence are accessed.
– Test with sequences of zero length.
General testing guidelines
• Choose inputs that force the system to generate all error messages
• Design inputs that cause input buffers to overflow
• Repeat the same input or series of inputs numerous times
• Force invalid outputs to be generated
• Force computation results to be too large or too small.
Test driven development
• Test-driven development (TDD) is an approach to program development in which you inter-leave testing and code development.
• Tests are written before code and ‘passing’ the tests is the critical driver of development.
• You develop code incrementally, along with a test for that increment. You don’t move on to the next increment until the code that you have developed passes its test.
• TDD was introduced as part of agile methods such as Extreme Programming. However, it can also be used in plan-driven development processes.
Test driven development
Benefits of TDD
• Code coverage
– Every code segment that you write has at least one associated test so all code written has at least one test.
• Regression testing
– A regression test suite is developed incrementally as a program is developed.
• Simplified debugging
– When a test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified.
• System documentation
– The tests themselves are a form of documentation that describe what the code should be doing.
Regression testing
• Regression testing is testing the system to check that changes have not ‘broken’ previously working code.
• In a manual testing process, regression testing is expensive but, with automated testing, it is simple and straightforward. All tests are rerun every time a change is made to the program.
• Tests must run ‘successfully’ before the change is committed.
System level testing
• Release testing is a form of system testing:
– A separate team that has not been involved in the system development, should be responsible for release testing.
– System testing by the development team should focus on discovering bugs in the system (defect testing). The objective of release testing is to check that the system meets its requirements and is good enough for external use (validation testing).
System level testing
• Effectively a form of documentation that the system does what it was supposed to do.
• Not interested in code level, just the system as a whole.
• Need an appropriate form of documentation …
System level testing
Description
Expected Outputs
Actual Outputs
User enters a name and password into login form
Username (String) and password (String) where both are valid
Progress to login screen
Progressed to login screen
User enters a name and password into login form
Username only and password is blank
Error message and return to login screen
Progressed to login screen
System level testing
• Should also record:
– Time and day tests were made.
– Who performed them.
– System build/version.
– Where FAIL’s happen, could provide commentary on suggested caused of failure for the development team to investigate.
• Need to be able to attain “clean run” of system level tests.
• If one fails, repair, and run them all again.
User testing
• User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing.
• User testing is essential, even when comprehensive system testing has been carried out.
• The reason for this is that influences from the user’s working environment have a major effect on the reliability, performance, usability and robustness of a system. These cannot be replicated in a testing environment.
Types of user testing
• Alpha testing
– Users of the software work with the development team to test the software at the developer’s site.
• Beta testing
– A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.
• Acceptance testing
– Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed
• When testing software, you should try to ‘break’ the software by using experience and guidelines to choose types of test case that have been effective in discovering defects in other systems.
• Wherever possible, you should write automated tests. The tests are embedded in a program that can be run every time a change is made to a system.
• Also test the software at a system level.
• And there may be user testing as well.
• We are trying to make reliable software.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com