From d68be1ed2f3d2b6bc82c952fc886da35957892ff Mon Sep 17 00:00:00 2001 From: anebz Date: Tue, 13 Oct 2020 17:47:39 +0200 Subject: [PATCH] chapter 11 done :heavy_check_mark: --- 11. Testing/11.1. Mistake.md | 13 ++++++++ 11. Testing/11.2. Random crashes.md | 14 ++++++++ 11. Testing/11.3. Chess test.md | 10 ++++++ 11. Testing/11.5. Test a pen.md | 16 +++++++++ 11. Testing/11.6. Test an ATM.md | 20 +++++++++++ 11. Testing/README.md | 51 +++++++++++++++++++++++++++++ 6 files changed, 124 insertions(+) create mode 100644 11. Testing/11.1. Mistake.md create mode 100644 11. Testing/11.2. Random crashes.md create mode 100644 11. Testing/11.3. Chess test.md create mode 100644 11. Testing/11.5. Test a pen.md create mode 100644 11. Testing/11.6. Test an ATM.md create mode 100644 11. Testing/README.md diff --git a/11. Testing/11.1. Mistake.md b/11. Testing/11.1. Mistake.md new file mode 100644 index 0000000..3b20615 --- /dev/null +++ b/11. Testing/11.1. Mistake.md @@ -0,0 +1,13 @@ +# 11.1. Mistake + +> Find the mistake(s) in the following code + +```c++ +unsigned int i; +for (i=100; i>=0; --i) + printf("%d\n", i); +``` + +One mistake is syntax in the for, it lacks {}. The printf is taking a digit but i is unsigned int. + +Unsigned int is always greater than or qual to zero, it will remain in 0 and the loop will run infinitely. diff --git a/11. Testing/11.2. Random crashes.md b/11. Testing/11.2. Random crashes.md new file mode 100644 index 0000000..9dc1770 --- /dev/null +++ b/11. Testing/11.2. Random crashes.md @@ -0,0 +1,14 @@ +# 11.2. Random crashes + +> An app crashes when it is run. After running it 10 times in a debugger, you find it never crashes in the same place. The app is single threaded and only uses the C standard library. What programming errors could be crashing the crash, and how do you test each one? + +Some part of the code overloads the memory or something, and it shows up randomly after some time. + +## Solution + +* The system could use a random variable that is not fixed in every execution. +* Uninitialized variable: in some languages, uninitialized variables take a random value +* Memory leak: the program runs out of memory Heap overflow, or corruption of data on the stack +* External dependencies + +Close all other applications, track resource use very carefully. If there are parts of the program that can be disabled, do it. Run it on a different machine and see if the error persists. diff --git a/11. Testing/11.3. Chess test.md b/11. Testing/11.3. Chess test.md new file mode 100644 index 0000000..2d68bb8 --- /dev/null +++ b/11. Testing/11.3. Chess test.md @@ -0,0 +1,10 @@ +# 11.3. Chess test + +> In a chess game there's the following method: boolean canMoveTo(int x, int y). This is part of the Piece class and returns whether or not the piece can move to position (x,y). Test this method + +1. Test for normal inputs: values of x,y in the range [1,8] +2. Test for extreme cases: values of 0, bigger than 8, float inputs +3. Test for illegal inputs: negative numbers, strings, arrays +4. Test for strange inputs + +Test each piece, all 6 pieces in chess. diff --git a/11. Testing/11.5. Test a pen.md b/11. Testing/11.5. Test a pen.md new file mode 100644 index 0000000..7df2ced --- /dev/null +++ b/11. Testing/11.5. Test a pen.md @@ -0,0 +1,16 @@ +# 11.5. Test a pen + +1. Who would use the pen? Students, painters? +2. Black box or white box? Can I test components of the pen? +3. What are the use cases? +4. What are the bounds of use? +5. In what conditions should it fail, what would that mean? + +Children are going to use the pen, they will be drawing on clothing. The pen is intended to wash off when cleaning the clothing. It will have colors red, green, blue and black. + +1. Fact check: verify that the pen is felt tip and that the ink is one of the allowed colors +2. Intended use: pen writes properly on clothing +3. Intended use: color washes off when clothing is washed. What about cold water washing, hot water? +4. Safety: is the pen non-toxic for children? +5. Unintended uses: what if the children write on other surfaces? The pen should hold up + diff --git a/11. Testing/11.6. Test an ATM.md b/11. Testing/11.6. Test an ATM.md new file mode 100644 index 0000000..100c074 --- /dev/null +++ b/11. Testing/11.6. Test an ATM.md @@ -0,0 +1,20 @@ +# 11.6. Test an ATM + +> in a distributed banking system + +1. Black box or white box? Can I test separate components of the ATM? +2. Users? Clients in the street +3. Use case? check account, retrieve money, insert money, renew transport card +4. Bounds of use? Clients cannot retrieve more than 2k€/day. After 3 PIN attempts, card is blocked +5. In what conditions should it fail? It should never fail... if the machine swallows up the card, it should show instructions on how to proceed now + +Tests: + +1. Fact check: check that the buttons in the ATM all work, the display too +2. Intended use: log in as user, enter PIN, retrieve money, put it back in +3. Safety: try entering wrong PIN, should see the prompt with instructions. If the credit card has a theft alert or something, no operations should be done on it +4. Unintended uses: user shall not retrieve more than 2k€/day, and if there are less than 2k€ in the account, only the max amount of money should be retrieved as maximum. + +## Solution + +Take security into account, reliability, that money does not magically disappear when you withdraw it and put it back in. diff --git a/11. Testing/README.md b/11. Testing/README.md new file mode 100644 index 0000000..728d98c --- /dev/null +++ b/11. Testing/README.md @@ -0,0 +1,51 @@ +# 11. Testing + +Interviewers are looking for: + +* Big picture understanding + * how to prioritize tests, some are more important +* Knowing how the pieces fit together + * not just test the product, test the product that the product interacts with. integrations etc +* Organization + * break down tests into sections +* Practicality + +## Testing a piece of software + +* Manual vs. automated testing + * sometimes manual is necessary, human observation can reveal new issues that haven't been physically examined. +* Black box testing vs. white box testing + * how much access do we have into the software? + +An approach from start to end: + +1. Are we doing black box testing or white box testing? +2. Who will use it and why? +3. What are the use cases? +4. What are the bounds of use? +5. What are the stress/failure conditions? + 1. Is it acceptable that the product fails, what should failure mean? It shouldn't crash the computer +6. What are the test cases? How would you perform the testing? + +## Testing a function + +1. Define test cases + 1. Normal case: generating the correct output for typical inputs + 2. Extreme cases: empty inputs, very small, very large inputs + 3. Nulls and 'illegal' input: if the function expects a number but a string is given + 4. Strange input: passing an already sorted array to a sort function, or a reverse sorted array +2. Define the expected results +3. Write test code + +## Troubleshooting questions + +How to debug or troubleshoot an existing issue. Instead of reinstalling the software, we can try a systematic approach + +1. Understand the scenario + 1. How long has the user been experiencing this issue? + 2. What version of the browser is it? What OS? + 3. Does the issue happen consistently, or how often? When does it happen? + 4. Is there an error report that launches? +2. Break down the problem + 1. Break down the problem into testable units +3. Create specific, manageable tests