Professional Documents
Culture Documents
Notes
Notes
v=dL08kDGylks&list=PLAwxTw4SYaPkWVHeC_8aSIbSxE_NXI76g&index=160
POgledaj ovo opet
Sta je testiranje:
test inputs ----> sw----> test_outputs ----> if ok then great, if not ok then
debug
-clean code
-refactor whenever necessery
-should clearly descibe
-what the module does
-how it interacts with the rest of the system
-no extra threads
Assertions
*Assertions are not for error handling
*Never make assertions with side effects
*No silly assertions
Trust boundry
If you dont trust the users to not cross a boundary,
then we have to test functions so we test the full domain under test and output
range
GUI: domain (set of all possible gui actions clicks, keyboard, events, swipes)
---> GUI application states
Defensive coding
Fuzzing
3. Regression tests, any input that has caused so the software fails on a
bug that we already fixed.
test cases should contain values selected from entire input domain
interfaces that cross a trust boundary need to be tested with represntable value,
not just those
from the ostensible inout domain
when appropriate all three kinds of input should be used as a basis for testing:
apis that are provided by the SUT
apis used by the sut can be tested using fault injections
non functional inputs
____________________________________________________________
Todo:
https://www.youtube.com/watch?v=WARkqLBreoQ&ab_channel=Udacity
https://www.youtube.com/watch?v=pklED4UfODg&ab_channel=Udacity