Testing and maintenance · Pruebas y mantenimiento
| English | Español |
|---|---|
| run-time error/rʌn taɪm ˈerə/ | error en tiempo de ejecución |
| syntax error/ˈsɪntæks ˈerə/ | error de sintaxis |
| logic error/ˈlɒdʒɪk ˈerə/ | error lógico |
| dry run/draɪ rʌn/ | ejecución manual |
| walkthrough/ˈwɔːkθruː/ | revisión |
| white-box testing/waɪt bɒks ˈtestɪŋ/ | prueba de caja blanca |
| black-box testing/blæk bɒks ˈtestɪŋ/ | prueba de caja negra |
| integration testing/ˌɪntɪˈɡreɪʃn ˈtestɪŋ/ | prueba de integración |
| stub/stʌb/ | stub |
| alpha testing/ˈælfə ˈtestɪŋ/ | prueba alfa |
| beta testing/ˈbiːtə ˈtestɪŋ/ | prueba beta |
| acceptance testing/əkˈseptəns ˈtestɪŋ/ | prueba de aceptación |
| test strategy/test ˈstrætədʒi/ | estrategia de prueba |
| test plan/test plæn/ | plan de pruebas |
| normal data/ˈnɔːml ˈdeɪtə/ | datos normales |
| abnormal data/əbˈnɔːml ˈdeɪtə/ | datos anómalos |
| extreme data/ekˈstriːm ˈdeɪtə/ | datos extremos |
| boundary data/ˈbaʊndəri ˈdeɪtə/ | datos límite |
| corrective maintenance/kəˈrektɪv ˈmeɪntənəns/ | mantenimiento correctivo |
| adaptive maintenance/əˈdæptɪv ˈmeɪntənəns/ | mantenimiento adaptativo |
| perfective maintenance/pəˈfektɪv ˈmeɪntənəns/ | mantenimiento perfectivo |
| regression testing/rɪˈɡreʃn ˈtestɪŋ/ | prueba de regresión |
Thirty-seven seconds
- On 4 June 1996 the first Ariane 5 rocket lifted off from French Guiana. Thirty-seven seconds later it veered off course and destroyed itself. The payload was four satellites worth $370 million.
- The cause was one line of code, reused from Ariane 4, that converted a 64-bit number into a 16-bit integer. Ariane 5 flew faster, the number was bigger, and the conversion overflowed: a run-time error 运行时错误 in a routine that was not even needed after lift-off.
- The code had never been tested with Ariane 5's flight data. Nobody had chosen test data at the extremes of the new rocket's range.
- This lesson is the three kinds of error, the methods of testing, how to choose test data, and how a program is kept alive after release.
Treinta y siete segundos
- El 4 de junio de 1996, el primer cohete Ariane 5 despegó desde la Guayana Francesa. Treinta y siete segundos después, se desvió de su trayectoria y se destruyó a sí mismo. La carga útil consistía en cuatro satélites valorados en 370 millones de dólares.
- La causa fue una sola línea de código reutilizada del Ariane 4 que convertía un número de 64 bits en un entero de 16 bits. El Ariane 5 volaba más rápido, el número era mayor y la conversión provocó un desbordamiento: un error en tiempo de ejecución error en tiempo de ejecución en una rutina que ni siquiera era necesaria tras el despegue.
- El código nunca había sido probado con los datos de vuelo del Ariane 5. Nadie había elegido datos de prueba en los extremos del nuevo rango del cohete.
- Esta lección trata sobre los tres tipos de error, los métodos de prueba, cómo elegir datos de prueba y cómo mantener vivo un programa después de su lanzamiento.
Three kinds of error
- A syntax error 语法错误 breaks the grammar of the language: a missing bracket, a misspelled keyword. It is found at translation, so the program will not run until it is fixed.
- A run-time error happens while the program runs: division by zero, a file that does not exist, an array index out of range. The program crashes or raises an exception; the fix is a check before the risky operation.
- A logic error 逻辑错误 lets the program run and produce wrong results:
+for-, an off-by-one loop, conditions in the wrong order. Nothing flags it; only testing and tracing reveal it.
Found at translation, found at run time, found only in the output
Tres tipos de error
- Un error de sintaxis error de sintaxis rompe la gramática del lenguaje: un paréntesis faltante, una palabra clave mal escrita. Se detecta durante la traducción, por lo que el programa no ejecutará hasta que se corrija.
- Un error en tiempo de ejecución ocurre mientras el programa se ejecuta: división por cero, un archivo que no existe, un índice de matriz fuera de rango. El programa se detiene inesperadamente o genera una excepción; la solución es realizar una comprobación antes de la operación arriesgada.
- Un error de lógica error de lógica permite que el programa se ejecute y produzca resultados incorrectos:
+en lugar de-, un bucle con un error de uno, condiciones en el orden equivocado. Nada lo marca; solo las pruebas y el rastreo lo revelan.
Encontrado en la traducción, encontrado en tiempo de ejecución, encontrado solo en la salida
Match each kind of error to how it shows up. · Asocia cada tipo de error con cómo se manifiesta.
Syntax = caught at translation; logic = wrong output; run-time = crash while running. · Sintaxis = detectada en la traducción; lógica = salida incorrecta; tiempo de ejecución = fallo al ejecutarse.
Worked example: find and correct the errors
- Syntax: the
IFhas noENDIF. The translator rejects it. Run-time: ifCountis 0 the division fails; guard it withIF Count > 0 THEN. Logic: if a pass is 50 or more,> 50fails a student on exactly 50; it should be>= 50. - Name the type, say why it is that type, and give the correction. Three parts, three marks.
Ejemplo resuelto: encontrar y corregir errores
Total ← 0
FOR i ← 1 TO Count
Total ← Total + Marks[i]
NEXT i
Average ← Total / Count
IF Average > 50 THEN
OUTPUT "Pass"
- Sintaxis: el
IFno tieneENDIF. El traductor lo rechaza. Tiempo de ejecución: siCountes 0, la división falla; proteja conIF Count > 0 THEN. Lógica: si la nota aprobatoria es 50 o más,> 50reprueba a un estudiante que saca exactamente 50; debería ser>= 50. - Nombre el tipo, explique por qué es ese tipo y dé la corrección. Tres partes, tres puntos.
A program divides a total by the number of entries and crashes when the input file is empty. This is a: · Un programa divide un total entre el número de entradas y falla cuando el archivo de entrada está vacío. Esto es un:
Division by zero happens while the program runs and stops it. A guard such as IF Count > 0 fixes it. · La división por cero ocurre mientras el programa se ejecuta y lo detiene. Un control como SI Count > 0 lo soluciona.
Testing methods: reading the code
- A dry run 手工跟踪 traces the code on paper, writing each variable's value in a trace table after each line.
- A walkthrough 走查 is a team review: the programmer explains the code line by line while colleagues look for faults.
- White-box testing 白盒测试 designs tests from the code's internal structure, so that every statement, branch and loop is exercised. Black-box testing 黑盒测试 designs tests from the specification only: feed inputs, compare the outputs with what was expected, without looking at the code.
Outside looking in, or inside looking at every path
Métodos de prueba: lectura del código
- Una prueba en seco prueba en seco sigue el código en papel, escribiendo el valor de cada variable en una tabla de seguimiento después de cada línea.
- Un recorrido recorrido es una revisión en equipo: el programador explica el código línea por línea mientras sus colegas buscan fallos.
- La prueba blanca prueba blanca diseña pruebas a partir de la estructura interna del código, para que se ejerzan todas las sentencias, ramas y bucles. La prueba negra prueba negra diseña pruebas basándose únicamente en la especificación: introduce entradas, compara las salidas con lo esperado, sin mirar el código.
Mirar desde afuera hacia adentro, o desde adentro revisar cada ruta
Designing test cases from the specification only (inputs and expected outputs), ignoring the code inside, is called ______-box testing. · Diseñar casos de prueba basándose únicamente en la especificación (entradas y salidas esperadas), ignorando el código interno, se llama prueba de caja ______.
Black-box tests from the spec; white-box uses the code's internal structure to cover statements and branches. · Las pruebas de caja negra se basan en la especificación; las de caja blanca utilizan la estructura interna del código para cubrir sentencias y ramas.
Testing methods: assembling and releasing
- Integration testing 集成测试 combines modules that were tested separately and tests the interfaces between them. A stub 桩 stands in for a module that is not yet written, returning fixed values so the rest can be tested top-down.
- Alpha testing α测试 is done in-house by the developers before release. Beta testing β测试 gives a limited group of real users the program in their own environment.
- Acceptance testing 验收测试 is done by the customer, against the requirements, to decide whether the product is fit for purpose.
Métodos de prueba: ensamblaje y lanzamiento
- La prueba de integración prueba de integración combina módulos que fueron probados por separado y verifica las interfaces entre ellos. Un stub stub sustituye a un módulo que aún no está escrito, devolviendo valores fijos para que el resto pueda probarse de arriba hacia abajo.
- La prueba alfa prueba alfa se realiza internamente por los desarrolladores antes del lanzamiento. La prueba beta prueba beta entrega el programa a un grupo limitado de usuarios reales en su propio entorno.
- La prueba de aceptación prueba de aceptación la realiza el cliente contra los requisitos, para decidir si el producto es apto para su propósito.
Software process lab · Laboratorio de procesos de software
Classify development examples by the stage or tool they belong to. · Clasificar ejemplos de desarrollo según la etapa o herramienta a la que pertenecen.
Worked example: which method for which situation
- The reporting module is finished but the database module it calls does not exist yet: test it with a stub that returns fixed data.
- Two modules pass their own tests but fail when the output of one feeds the other: integration testing of the interface.
- The software is complete; the company wants faults found in real conditions before general release: beta testing by a limited group of users.
- The customer decides whether to pay: acceptance testing against the agreed requirements. Name the method and what it is for.
Ejemplo resuelto: qué método para qué situación
- El módulo de informes está terminado, pero el módulo de base de datos que llama aún no existe: pruébelo con un stub que devuelva datos fijos.
- Dos módulos pasan sus propias pruebas pero fallan cuando la salida de uno alimenta al otro: prueba de integración de la interfaz.
- El software está completo; la empresa quiere encontrar fallos en condiciones reales antes del lanzamiento general: prueba beta por un grupo limitado de usuarios.
- El cliente decide si paga: prueba de aceptación contra los requisitos acordados. Nombre el método y su propósito.
Match each situation to the testing method it needs. · Asocia cada situación con el método de prueba que requiere.
Stub for a missing part, beta for real users, acceptance for the customer, integration for the joins. · Stub para una parte faltante, beta para usuarios reales, aceptación para el cliente, integración para las uniones.
Test strategy and test plan
- A test strategy 测试策略 is the high-level approach: which kinds of testing will be done, by whom, when, and what must pass before the next stage.
- A test plan 测试计划 is the detailed list of tests. For each: the purpose, the input data, the expected output, and a column for the actual output when the test is run.
- A test without an expected result is not a test. It only shows what the program did, not whether that was right.
Estrategia y plan de prueba
- Una estrategia de prueba estrategia de prueba es el enfoque de alto nivel: qué tipos de prueba se realizarán, por quién, cuándo y qué debe aprobarse antes de la siguiente etapa.
- Un plan de prueba plan de prueba es la lista detallada de pruebas. Para cada una: el propósito, los datos de entrada, la salida esperada y una columna para la salida real cuando se ejecute la prueba.
- Una prueba sin un resultado esperado no es una prueba. Solo muestra lo que hizo el programa, no si eso fue correcto.
A test plan lists, for each test, the input data and the expected output. · Un plan de pruebas enumera, para cada prueba, los datos de entrada y la salida esperada.
Purpose, input, expected output and a column for the actual output. The strategy is the high-level approach; the plan is the detailed list. · Propósito, entrada, salida esperada y una columna para la salida real. La estrategia es el enfoque de alto nivel; el plan es la lista detallada.
Choosing test data
- Normal data 正常数据: typical valid values inside the range, which should be accepted and processed correctly.
- Abnormal data 异常数据: values that should be rejected, out of range or the wrong type.
- Extreme data 极端数据: the largest and smallest values still accepted, at the edges of the range. Boundary data 边界数据: the pairs that straddle each edge, the accepted extreme and the rejected value just outside it, where off-by-one errors hide.
Inside, outside, and right on the line
Elección de datos de prueba
- Datos normales datos normales: valores típicos válidos dentro del rango, que deberían aceptarse y procesarse correctamente.
- Datos anormales datos anormales: valores que deben ser rechazados, fuera de rango o del tipo incorrecto.
- Datos extremos datos extremos: los valores más grandes y más pequeños que aún son aceptados, en los bordes del rango. Datos límite datos límite: los pares que cruzan cada borde, el extremo aceptado y el valor rechazado justo fuera de él, donde se esconden los errores de un número.
Dentro, fuera y justo sobre la línea
For a field that accepts marks 0–100, which are the boundary test values? · Para un campo que acepta calificaciones de 0–100, ¿cuáles son los valores de prueba de límite?
Boundary data sits at the edges of the valid range (and just outside) — where off-by-one errors hide. · Los datos de límite están en los bordes del rango válido (y justo fuera) — donde se ocultan los errores off-by-one.
Worked example: test data for a mark from 0 to 100
| Kind | Data | Expected result |
|---|---|---|
| normal | 50, 75 |
accepted and processed |
| abnormal | -10, 200, "abc" |
rejected: out of range or wrong type |
| extreme | 0, 100 |
accepted: the smallest and largest valid values |
| boundary | -1 and 0, 100 and 101 |
-1 rejected, 0 accepted; 100 accepted, 101 rejected |
- Every row needs the expected result; a table of inputs alone scores half. The extremes are accepted:
-1is boundary, not extreme.
Ejemplo resuelto: datos de prueba para una nota de 0 a 100
| Tipo | Datos | Resultado esperado |
|---|---|---|
| normal | 50, 75 |
aceptado y procesado |
| anormal | -10, 200, "abc" |
rechazado: fuera de rango o tipo incorrecto |
| extremo | 0, 100 |
aceptado: los valores válidos más pequeños y más grandes |
| límite | -1 y 0, 100 y 101 |
-1 rechazado, 0 aceptado; 100 aceptado, 101 rechazado |
- Cada fila necesita el resultado esperado; una tabla solo de entradas obtiene la mitad de los puntos. Los extremos son aceptados:
-1es un dato límite, no extremo.
A field accepts marks from 0 to 100. Which values are extreme test data? Select all · todos that apply. · Un campo acepta calificaciones de 0 a 100. ¿Qué valores son datos de prueba extremos? Selecciona todos los que correspondan.
Extreme values are the smallest and largest still accepted. -1 is rejected, so it is boundary or abnormal; 50 is normal. · Los valores extremos son los más pequeños y más grandes que aún se aceptan. -1 es rechazado, así que es límite o anormal; 50 es normal.
Maintenance
- Most of a program's lifetime cost is spent after release. Corrective maintenance 纠正性维护 fixes faults found in use.
- Adaptive maintenance 适应性维护 keeps the program working in a changing environment: a new operating system, a new API, a change in the law.
- Perfective maintenance 完善性维护 improves a program that already works: faster performance, a new feature users asked for. A program may need all three throughout its life.
Fix it, keep it working, make it better
Mantenimiento
- La mayor parte del costo de vida útil de un programa se gasta después del lanzamiento. El mantenimiento correctivo mantenimiento correctivo corrige fallos encontrados en uso.
- El mantenimiento adaptativo mantenimiento adaptativo mantiene el programa funcionando en un entorno cambiante: un nuevo sistema operativo, una nueva API, un cambio en la ley.
- El mantenimiento perfectivo mantenimiento perfectivo mejora un programa que ya funciona: mejor rendimiento, una nueva función que pidieron los usuarios. Un programa puede necesitar los tres a lo largo de su vida.
Corrígalo, manténgalo funcionando, mejórelo
Corrective maintenance fixes faults, perfective maintenance improves features, and adaptive maintenance keeps the software working in a changed environment. · El mantenimiento correctivo corrige fallos, el mantenimiento perfectivo mejora funciones y el mantenimiento adaptativo mantiene el software funcionando en un entorno cambiado.
Three maintenance types: corrective (fix bugs), perfective (enhance), adaptive (new OS/hardware/rules). · Tres tipos de mantenimiento: correctivo (corregir bugs), perfectivo (mejorar), adaptativo (nuevo SO/hardware/normativas).
A payroll program is changed because the tax law changed. Which kind of maintenance is this? · Se modifica un programa de nómina porque cambió la ley fiscal. ¿Qué tipo de mantenimiento es este?
The program was not faulty and is not being improved; its environment changed. That is adaptive maintenance. · El programa no estaba defectuoso ni se está mejorando; su entorno cambió. Eso es mantenimiento adaptativo.
Amending an existing program
- Read the existing code until you understand the algorithm and the data flow. Find where the change belongs: which subroutine, which lines.
- Make the change as small as possible; do not rewrite working code. Update every related part: each caller of a changed parameter list, each routine that uses a changed data structure.
- Test the new behaviour and the old: regression testing 回归测试 checks that nothing that used to work has broken. Then document the change.
Modificar un programa existente
- Lea el código existente hasta entender el algoritmo y el flujo de datos. Encuentre dónde pertenece el cambio: qué subrutina, qué líneas.
- Realice el cambio lo más pequeño posible; no reescriba código que funcione. Actualice todas las partes relacionadas: cada llamada a una lista de parámetros cambiada, cada rutina que use una estructura de datos cambiada.
- Pruebe el nuevo comportamiento y el antiguo: la prueba de regresión prueba de regresión verifica que nada que solía funcionar se haya roto. Luego documente el cambio.
After changing a program, regression testing checks that: · Después de cambiar un programa, la prueba de regresión verifica que:
Regression testing re-runs old tests to confirm existing behaviour still works after a change. · La prueba de regresión vuelve a ejecutar pruebas antiguas para confirmar que el comportamiento existente sigue funcionando después de un cambio.
Put the steps of amending an existing program in order. · Coloca los pasos para modificar un programa existente en orden.
Understand, locate, change small, propagate, test everything, record. Skipping the regression test is how a fix breaks something else. · Entender, localizar, cambiar poco, propagar, probar todo, registrar. Saltarse la prueba de regresión es cómo una corrección rompe otra cosa.
Marks that slip away
- Extreme is accepted; abnormal is rejected.
0and100are extreme;-1and101are boundary values on the rejected side. - A logic error does not crash the program. If it crashed, it was a run-time error.
- Alpha is in-house; beta is real users outside. A stub replaces a missing module; it is not a test method for finished code.
- A test plan row without an expected output earns nothing. Regression testing follows every change.
Puntos que se pierden fácilmente
- Los extremos se aceptan; lo anormal se rechaza.
0y100son extremos;-1y101son valores límite en el lado rechazado. - Un error de lógica no hace que el programa se detenga inesperadamente. Si se detuvo, fue un error en tiempo de ejecución.
- Alfa es interna; beta es usuarios reales externos. Un stub reemplaza un módulo faltante; no es un método de prueba para código terminado.
- Una fila de plan de prueba sin una salida esperada no obtiene puntos. La prueba de regresión sigue todo cambio.
You've got it
- syntax errors stop translation · run-time errors crash a running program · logic errors run and give wrong output, found only by testing
- methods: dry run, walkthrough, white-box (from the code), black-box (from the specification), integration (interfaces, with stubs for missing modules), alpha (in-house), beta (real users), acceptance (the customer)
- test data: normal accepted, abnormal rejected, extreme the accepted edges, boundary either side of each edge; every test has an expected result
- maintenance: corrective fixes, adaptive keeps up with the environment, perfective improves; amend small, update callers, regression test
Lo has logrado
- los errores de sintaxis detienen la traducción · los errores de tiempo de ejecución hacen que se detenga un programa en ejecución · los errores de lógica se ejecutan y dan salida incorrecta, encontrados solo mediante pruebas
- métodos: prueba en seco, recorrido, prueba blanca (desde el código), prueba negra (desde la especificación), integración (interfaces, con stubs para módulos faltantes), alfa (interna), beta (usuarios reales), aceptación (el cliente)
- datos de prueba: normal aceptado, anormal rechazado, extremo los bordes aceptados, límite ambos lados de cada borde; cada prueba tiene un resultado esperado
- mantenimiento: correctivo correcciones, adaptativo se mantiene actualizado con el entorno, perfectivo mejora; modifique poco, actualice las llamadas, prueba de regresión