Add notes on implementation of tests (ARMmbed#101)

* Add notes on implementation of tests
* add comment about active header location
* Add component diagram and more detail on testapp flow

Author: LiyouZhou

docs/test-plan.md

@@ -36,7 +36,7 @@
 11. Given corrupted active firmware, does not boot into firmware.
 12. Given corrupted active firmware, valid firmware candidate of older version, always perform update.
 
-### Overall size (< 32K)
+### Overall size
 
 13. Test that the compiled binary does not exeed 32K limit
 
@@ -71,3 +71,76 @@
 
 - SOTP
 - Insecure Example RoT
+
+### Firmware Header Location options
+
+- Contiguous with active application region
+- In a separate erase sector
+
+### Design of Testing Infrastructure
+
+Write mbed-bootloader-cliapp which abstracts ARM_UC_PAAL layer into python API. Using [mbed-clitest](https://github.com/ARMmbed/mbed-clitest) we will have the following capability:
+- inject firmware candidate onto the device regardless of the storage type
+- Specify the slot, version, hash of each candidate
+- Pass any firmware blob from the host side
+- Get current active firmware version and hash
+
+In addition, the following custom functionality should also be implemented:
+- Reboot device
+
+The mbed-bootloader-cliapp should track the dependencies and build options in mbed-cloud-client as close as possible.
+
+This will cover the following testcases:
+- [Firmware update](#firmware-update)
+- [Rollback protection](#rollback-protection)
+- [Multiple candidates](#multiple-candidates)
+- [Integrity check of firmware candidates](#integrity-check-of-firmware-candidates)
+- [Integrity check of active firmware](#integrity-check-of-active-firmware)
+- [Successful update](#successful-update)
+- [Forward to Application](#forward-to-application)
+
+Component Diagram
+```
+             +------------------------+
+             | host side: clitest     |
+             +------------------------+
+                         | serial link
++----------+ +------------------------+
+|bootloader| | mbed-bootloader-cliapp |
++----------+ +------------------------+
++-------------------------------------+
+|Update Client PAAL API               |
++-------------------------------------+
++-------------------------------------+
+|Physical Storage                     |
++-------------------------------------+
+```
+
+mbed-bootloader-cliapp Flow
+
+1. Build mbed-bootloader
+1. Build mbed-bootloader-cliapp with the same RoT and PAAL options
+1. Combine bootloader with mbed-bootloader-cliapp with approperate headers
+1. Run Clitest on host side, it will detect mbed-bootloader-cliapp booting up successfully
+1. Run python clittest test case which sets up a number of firmware candidates
+1. python test case calls reboot, bootloader performs update
+1. host side keeps monitoring the serial output to confirm the bootloader is behaving as expected
+
+For the following test cases, the flow need to be adapted:
+- [Rollback protection](#rollback-protection)
+  - Inject firmware using a old time stamp in testapp
+- [Integrity check of firmware candidates](#integrity-check-of-firmware-candidates)
+  - Inject firmware blob that is tampered and does not match with hash
+- [Integrity check of active firmware](#integrity-check-of-active-firmware)
+  - Tamper with the combined binary before flashing to device
+
+[Power Cut](#power-cut) can continue to be performed using the current mbedgt infrastructure.
+
+[Overall size](#overall-size) Can be checked as a Jenkins step
+
+[Integrity check of active firmware](#integrity-check-of-active-firmware) Need to tamper with combined firmware using custom script before flashing to device. Need custom script to monitor serial output to determine the bootloader have done the right thing. Or instrument the bootloader source code with mbedgt and make sure the bootloader goes into the right state.
+
+Notes:
+- Bootloader binaries can be built as a first step in Jenkins for all possible configurations
+- Cli testapp can live in https://github.com/ARMmbed/mbed-bootloader-tests. Using the mbed-os TEST folder structure, multiple binaries can be built with one repo. Hence there should be at least the bootlaoder-cliapp and a dummy firmware candidate. The dummy firmware candidate may implement functions to get active hash.
+- Tests can be run in parallel on raas so as to not impact the testing time.