¿Cómo probar la confiabilidad de mi propio (pequeño) sistema operativo incorporado?

He escrito un pequeño sistema operativo para el proyecto integrado que se ejecuta en blanco pequeño a mediano.¿Cómo probar la confiabilidad de mi propio (pequeño) sistema operativo incorporado?

Agregué algunas pruebas de unidad automatizadas con una cobertura de código de prueba alta (> 95%), pero el alcance es solo la parte estática.
Obtuve algunas métricas de código como complejidad y legibilidad.
Estoy probando mi código con un verificador de reglas con soporte MiSRA, y por supuesto solucioné todas las advertencias.
Estoy probando el código con un analizador estático y volví a arreglar todas las advertencias.

¿Qué puedo hacer ahora para probar y mejorar la fiabilidad de mi sistema operativo? ¿Qué tal la parte dinámica?

Fuente

2010-05-23 TridenT

Dejar que la gente realmente lo use no es una opción en este momento? –

@Tim Post: Sí, 2 proyectos lo están ejecutando ... ¡pero debo proporcionar información sobre la fiabilidad! He probado solo la parte estática. – TridenT

¿Es este un sistema operativo basado en texto? –

Intente escribir algunas pruebas de unidad para la parte dinámica. Luego ejecute las pruebas en el hardware de destino. Ejecute las pruebas en el hardware con más núcleos Ejecute las pruebas en el hardware con un solo núcleo

Varíe la velocidad del reloj del sistema objetivo y ejecute las pruebas dinámicas.

debería sacudir la mayoría de los problemas de sincronización.

Fuente

2010-05-24 06:05:46

¡Quizás sea la única solución! Pero escribir unidad/prueba de integración con evaluación de tiempo, en el objetivo, con múltiples núcleos ... ¿Escribiré la prueba unitaria durante 10 años?!? – TridenT

Ejecute las pruebas dinámicas en el destino. (1) experimente ejecute las pruebas dinámicas en hardware de desarrollo con más o menos experimentos de núcleos (2). Ejecutar en el objetivo con diferente velocidad de reloj (1) experimento. Un total de 5 experimentos. –

Eche un vistazo a software-testing entry on wikipedia. Es una descripción bastante completa de las diferentes ramas de las pruebas. Puede encontrar una nueva idea o dos allí.

Fuente

2010-05-23 08:16:09 bitc

Es un comienzo interesante, pero no sé cómo manejar el comportamiento dinámico de mi sistema operativo. ¡Seguiré el enlace para la investigación! – TridenT

cosas que faltan en su lista:

Si no lo está haciendo, entonces también ejecutar las pruebas unitarias en el hardware de destino, para comprobar si hay problemas de compilación y hardware.
Las revisiones de código, especialmente para comprobar las condiciones de carrera

También puede revisar el código ensamblador generado, si no es demasiado grande.

Fuente

2010-05-23 10:59:01 starblue

Las revisiones de código son buenas, pero es 'una oportunidad'.La revisión del código de ensamblaje se realizó parcialmente, pero ¿qué resultados debo mostrar? – TridenT

Pruebe Atomic Object's sitio. Pruebe this also..

También James Greening.

Fuente

2010-05-24 00:09:03 Gutzofter

La técnica simulada es bastante difícil en C (el SO está escrito en C + ASM) y pesado en comparación con C++. ¡Pero podría ser la única solución! – TridenT

Creo que usan mucho la generación de código también. – Gutzofter

Parece que ha hecho mucho para probar su sistema. Creo que el próximo paso sería lograr que otros proyectos o personas lo usen. Otros usuarios mostrarían rápidamente que eran problemas de robustez.

Fuente

2010-10-29 12:58:48 Gerhard

sí, y ya solicitan una mejor documentación de usuario :) – TridenT

¿Cómo probar la confiabilidad de mi propio (pequeño) sistema operativo incorporado?

Respuesta

Cuestiones relacionadas