Design Article.

The basics of embedded software testing

Arnold Berger
07/02/2011 5:31 PM EST
Test is the last step in traditional software development. We gather requirements, do high level design,
detailed design, create code, do some unit testing, then integrate and start—finally— final test.
Since most projects run late, what do you think gets cut? Test, of course. The implication is that we
deliver bug-ridden products that infuriate our customers and drive them to competitive products.
Best practice development includes code inspections. Yet inspections typically find only 70% of a
system’s bugs, so a fabulous test regime is absolutely essential. Test is like a double-entry bookkeeping
system that insures mistakes don’t leak into the deployed product.
In every other kind of engineering testing is considered fundamental. In the USA, every Federally funded
bridge must undergo extensive wind tunnel tests, for instance.
Mechanical engineers subject spacecraft to an almost bizarre series of evaluations. It’s quite a sight to see
a 15-foothigh prototype being nearly torn to pieces on a shaker, which vibrates at a rate that puts a
thousand-Hertz tone into the air. The bridge prototype, as well as that of the shaken spacecraft, are
discarded at great expense, but in both cases that cost is recognized as a key ingredient of proper
engineering practices.

Yet in the software world test is the ugly stepchild. No one likes to do it. Time spent writing tests feels
wasted, despite the fact that test is a critical part of all engineering disciplines. Many segments of the
embedded systems design community have thankfully embraced test as a core part of their processes, and
advocate creating tests synchronously with writing the code, realizing that leaving such a critical step till
the end of the project is folly.
Application versus embedded testing. Embedded systems software testing shares much in common with
application software testing. Thus, much of this two part article is a summary of basic testing concepts
and terminology. However, some important differences exist between application testing and embedded
systems testing. Embedded developers often have access to hardware-based test tools that are generally
not used in application development.
Also, embedded systems often have unique characteristics that should be reflected in the test plan. These
differences tend to give embedded systems testing its own distinctive flavor. This article covers the basics
of testing and test case development and points out details unique to embedded systems work along the
way.
Why Test?
Before you begin designing tests, it’s important to have a clear understanding of why you are testing. This
understanding influences which tests you stress and (more importantly) how early you begin testing. In
general, you test for four reasons:
• To find bugs in software (testing is the only way to do this)
• To reduce risk to both users and the company
• To reduce development and maintenance costs
• To improve performance
To Find the Bugs. One of the earliest important results from theoretical computer science is a proof
(known as the Halting Theorem) that it’s impossible to prove that an arbitrary program is correct.
To Reduce Costs.The classic argument for testing comes from Quality Wars by Jeremy Main. In 1990,
HP sampled the cost of errors in software development during the year. The answer, $400 million,
shocked HP into a completely new effort to eliminate mistakes in writing software.
The $400M waste, half of it spent in the labs on rework and half in the field to fix the mistakes that
escaped from the labs, amounted to one-third of the company’s total R&D budget and could have
increased earnings by almost 67%.[5]
The earlier a bug is found, the less expensive it is to fix. The cost of finding errors and bugs in a released
product is significantly higher than during unit testing, for example (Figure 2-1 below).

 
Figure 2-1: The Cost to Fix a Problem. Simplified graph showing the cost to fix a problem as a function
of the time in the product life cycle when the defect is found. The costs associated with finding and fixing
the Y2K problem in embedded systems is a close approximation to an infinite cost model.
To Improve Performance. Testing maximizes the performance of the system. Finding and eliminating
dead code and inefficient code can help ensure that the software uses the full potential of the hardware
and thus avoids the dreaded “hardware re-spin.”
Diseño artículo. Los fundamentos de las pruebas de software prueba: Parte 1

Arnold Berger
07/02/2011 05:31 PM EST
La prueba es el último paso en el desarrollo de software tradicional. Nos reunimos los requisitos, hacer el
diseño de alto nivel, diseño detallado, crear el código, hacer algunas pruebas de unidades, a continuación,
integrar y-finalmente-última prueba de arranque .
Como la mayoría de proyectos llevados a cabo tarde, ¿qué crees que se corta? Prueba, por supuesto. La
implicación es que nosotros entregamos montado productos-bug que enfurecen a los clientes y los llevan
a productos de la competencia .
El mejor desarrollo de la práctica incluye inspecciones de código. Sin embargo, las inspecciones suelen
encontrar sólo el 70% del sistema de errores sea, por lo que un régimen de prueba fabulosa es
absolutamente esencial. Prueba es como un sistema de contabilidad de entrada doble que asegura errores
no tengan fugas en el producto desplegado .
En cualquier otro tipo de pruebas de ingeniería se considera fundamental. En los EE.UU., todos los
puentes con financiación federal deben someterse a extensas pruebas de túnel de viento, por ejemplo.

Ingenieros mecánicos nave objeto de una extraña serie casi de las evaluaciones. Es todo un espectáculo
ver a un prototipo foothigh-15 que es casi hecho pedazos en un agitador, que vibra a una velocidad que
pone de mil tonos de Hertz en el aire. El prototipo de puente, así como la de la nave sacudida, se
descartan a un gran costo, pero en ambos casos que el costo es reconocido como un ingrediente clave de
las prácticas de la ingeniería adecuada .
Sin embargo, en la prueba mundo del software es el hijastro feo. A nadie le gusta hacerlo. El tiempo
dedicado a escribir las pruebas se siente perdido, a pesar de que la prueba es una parte fundamental de
todas las disciplinas de ingeniería. Muchos segmentos de la comunidad de diseño de sistemas embebidos
afortunadamente han aceptado la prueba como una parte fundamental de sus procesos, y promover la
creación de pruebas de forma sincrónica con la escritura del código, al darse cuenta de que dejar como un
paso crítico hasta el final del proyecto es una locura .
Aplicación frente a las pruebas incrustado. incorporado sistemas de cuotas de las pruebas de software
mucho en común con el software de prueba de aplicaciones. Por lo tanto, gran parte de este artículo la
segunda parte es un resumen de los conceptos básicos y terminología de las pruebas. Sin embargo,
algunas diferencias importantes entre las pruebas de aplicaciones y sistemas de evaluación integrados.
desarrolladores de sistemas integrados suelen tener acceso a la prueba de herramientas basadas en
hardware que no se utilizan generalmente en el desarrollo de aplicaciones.
Además, los sistemas integrados a menudo tienen características únicas que deben reflejarse en el plan de
pruebas. Estas diferencias tienden a dar pruebas de sistemas embebidos su propio sabor distintivo. Este
artículo cubre los conceptos básicos de las pruebas y desarrollo de casos de prueba y señala detalles
únicos para trabajar los sistemas incorporados en el camino.
¿Por qué prueba?
Antes de comenzar el diseño de pruebas, es importante tener una comprensión clara de por qué se está
probando. Esto influye en la comprensión que las pruebas de tensión y (más importante) cómo a
principios de comenzar la prueba. En general, se prueba por cuatro razones:
• Para encontrar los fallos en el software (la prueba es la única manera de hacer esto)
• Para reducir el riesgo tanto para los usuarios y la empresa
• Para reducir los costes de desarrollo y mantenimiento
• Para mejorar el rendimiento
Para encontrar los errores. Uno de los primeros resultados importantes de ciencias de la computación
teórica es una prueba (conocido como el Teorema de Detención) que es imposible probar que un
programa arbitrario es la correcta.
Para reducir los costos. El argumento clásico para la prueba viene de Guerras de Calidad de Jeremy Main.
En 1990, HP muestra el costo de los errores en el desarrollo de software durante el año. La respuesta, $
400 millones, sorprendió HP en un nuevo esfuerzo para eliminar por completo los errores en la escritura
de software.
Los residuos 400 millones de dólares, la mitad de lo gastado en los laboratorios de la reanudación y la
mitad en el campo para arreglar los errores que se escapó de los laboratorios, asciende a un tercio de la I
total de la compañía y el desarrollo del presupuesto y podría haber aumentado los ingresos en casi un
67%. [5]
Cuanto antes se encuentra un error, el más barato es de arreglar. El costo de encontrar errores y fallos en
un producto liberado es significativamente mayor que durante las pruebas de unidad, por ejemplo ( Figura
2.1 a continuación ).

 
Figura 2-1: El costo para solucionar un problema. Simplificado gráfico que muestra el costo para
solucionar un problema en función del tiempo en el ciclo de vida del producto cuando el defecto se
encuentra. Los costos asociados con la búsqueda y solución del problema Y2K en los sistemas integrados
es una aproximación a un modelo de costo infinito.
Para mejorar el rendimiento. Prueba maximiza el rendimiento del sistema. Búsqueda y eliminación de
código muerto y el código ineficiente puede ayudar a asegurar que el software utiliza todo el potencial del
hardware y por lo tanto evita el temido "hardware nuevo giro."