-
Notifications
You must be signed in to change notification settings - Fork 96
Secure element driver interface test strategy #246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secure element driver interface test strategy #246
Conversation
Just the structure for now, no actual content.
@@ -41,6 +41,7 @@ For each API function that can lead to a driver call (more precisely, for each d | |||
|
|||
* Wherever the specification guarantees parameters that satisfy certain preconditions, check these preconditions whenever practical. | |||
* If the API function can take parameters that are invalid and must not reach the driver, call the API function with such parameters and verify that the driver method is not called. | |||
* Check that the expect inputs reach the driver. This may be implicit in a test that checks the outputs if the only realistic way to obtain the correct outputs is to start from the expected inputs (as is often the case for cryptographic material, but not for metadata). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/expect/expected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I amended the last commit.
LGTM other than one nit |
5b1d027
to
8b193c1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I wrote a test strategy document describing what I think we should test about the secure element driver interface (the Mbed Crypto code — this is not about how to test drivers).