Hi!
The open source development method have a very different
approach to tests from the commercial development method:
Testing is a largely uncoordinated effort, driven by the
individual needs of users. That means that zero to none
evidence is gathered on tests actually ran, and no structured
approach can be claimed on it. Not if testing would not be
made, just the depth and coverage of them cannot be
establised.
Of course there are examples on the contrary, like some
packages which run elaborate tests on 'make test' or
www.linuxtestproject.org, but they are still enough only
to EAL2, which is close to nothing.
My favourite example is happydoc: the author first writes
test cases, and the code _after_ that. It might even enough
for ATE_DPT.3, which requires tests against the implementation
representation (code).
ATE_COV.2 Analysis of coverage (EAL3-EAL5)
ATE_COV.2.1D The developer shall provide an analysis of the test
coverage.
(www.linuxtestproject.org)
ATE_COV.2.1C The analysis of the test coverage shall demonstrate the
correspondence between the tests identified in the test
documentation and the TSF as described in the functional
specification.
(See ADV_FSP to realize that this is the second step to take)
ATE_COV.2.2C The analysis of the test coverage shall demonstrate that
the correspondence between the TSF as described in the
functional specification and the tests identified in the test
documentation is complete.
(Writing tests is boring, eh?)
ATE_DPT.1 Testing: high-level design (EAL3, EAL4)
ATE_DPT.1.1D The developer shall provide the analysis of the depth of
testing.
(the lack of this may be the root cause that SLES got only
EAL2)
ATE_DPT.1.1C The depth analysis shall demonstrate that the tests
identified in the test documentation are sufficient to
demonstrate that the TSF operates in accordance with its
high-level design.
(Writing tests is still boring.)
ATE_FUN.1 Functional testing (EAL2-EAL5)
ATE_FUN.1.1D The developer shall test the TSF and document the results.
(If one is writing tests, it is relatively easy to comment
them.)
ATE_FUN.1.2D The developer shall provide test documentation.
(...and write some pages about their structure.)
ATE_FUN.1.1C The test documentation shall consist of test plans, test
procedure descriptions, expected test results and actual test
results.
(The test script with comments, plus an overview doc is the test
plan, and the proc. description, the expected test results are
some files with the expected output, and actual test results
can be gained by running the test suite.)
ATE_FUN.1.2C The test plans shall identify the security functions to be
tested and describe the goal of the tests to be performed.
(Nice objective for the comments of the test scripts.)
ATE_FUN.1.3C The test procedure descriptions shall identify the tests to
be performed and describe the scenarios for testing each
security function. These scenarios shall include any ordering
dependencies on the results of other tests.
(The code does that, the scenario is "run make;make tests":)
ATE_FUN.1.4C The expected test results shall show the anticipated
outputs from a successful execution of the tests.
(Easy, if we talk about test scripts.)
ATE_FUN.1.5C The test results from the developer execution of the tests
shall demonstrate that each tested security function behaved as
specified.
(the diff command helps a lot:)
ATE_IND.3 Independent testing - complete (EAL7)
ATE_IND.3.1D The developer shall provide the TOE for testing.
(apt source)
ATE_IND.3.1C The TOE shall be suitable for testing.
(seems easy, if the other requirements are fulfilled)
ATE_IND.3.2C The developer shall provide an equivalent set of resources
to those that were used in the developer's functional testing of
the TSF.
(an account on the designated devel machine)
--
GNU GPL: csak tiszta forrásból
