Asdf

estándar IEEE Std 1012-1998 para la verificación y validación de software

Resumen: se describen los procesos de la verificación y validación de software (V & V) que determinan si los productos de desarrollo de software de una determinada actividad se ajustan a los requisitos de dicha actividad, y si el software cumple su uso previsto y las necesidades del usuario. Esta determinaciónpuede incluir el análisis, evaluación, revisión, inspección, evaluación, y pruebas de productos de software y procesos. procesos V & V evaluan el software en el contexto del sistema, incluyendo el sistema operativo, hardware, componentes de interfaz de software, operadores y usuarios.
Palabras clave: la integridad del software, el software de procesos de ciclo de vida, verificación y validaciónIEEE 829-1998, también conocida como la Norma 829 para la documentación de pruebas de software, es un estándar IEEE que especifica la forma de un conjunto de documentos para su uso en ocho etapas definidas de pruebas de software, cada etapa potencialmente produce su propio tipo de documento por separado. La norma especifica el formato de estos documentos, pero no establece si todos ellos debenser producidos, ni incluye algún criterio sobre el contenido adecuado para estos documentos. Se trata de una cuestión de juicio fuera del alcance de la norma. Los documentos son:

* Test Plan: a management planning document that shows:
* How the testing will be done (including SUT (system under test) configurations).
* Who will do it
* What will be tested
* How long it willtake (although this may vary, depending upon resource availability).
* What the test coverage will be, i.e. what quality level is required
* Test Design Specification: detailing test conditions and the expected results as well as test pass criteria.
* Test Case Specification: specifying the test data for use in running the test conditions identified in the Test Design Specification* Test Procedure Specification: detailing how to run each test, including any set-up preconditions and the steps that need to be followed
* Test Item Transmittal Report: reporting on when tested software components have progressed from one stage of testing to the next
* Test Log: recording which tests cases were run, who ran them, in what order, and whether each test passed or failed
*Test Incident Report: detailing, for any test that failed, the actual versus expected result, and other information intended to throw light on why a test has failed. This document is deliberately named as an incident report, and not a fault report. The reason is that a discrepancy between expected and actual results can occur for a number of reasons other than a fault in the system. These includethe expected results being wrong, the test being run wrongly, or inconsistency in the requirements meaning that more than one interpretation could be made. The report consists of all details of the incident such as actual and expected results, when it failed, and any supporting evidence that will help in its resolution. The report will also include, if possible, an assessment of the impact of anincident upon testing.
* Test Summary Report: A management report providing any important information uncovered by the tests accomplished, and including assessments of the quality of the testing effort, the quality of the software system under test, and statistics derived from Incident Reports. The report also records what testing was done and how long it took, in order to improve any futuretest planning. This final document is used to indicate whether the software system under test is fit for purpose according to whether or not it has met acceptance criteria defined by project stakeholders.
* Plan de pruebas: un documento de planificación de la gestión que muestra:
Como la prueba se llevará a cabo (incluyendo SUT (sistema sometido a prueba) las configuraciones).
¿Quién lo...