Please enable JavaScript.
Coggle requires JavaScript to display documents.
HTSM Resonance APPunnamed, Customers, Information, Developer Relations,…
HTSM Resonance APP
-
-
-
Customers
-
Se debe considerar a los ingenieros y profesionales que usarán la aplicación para su trabajo, así como a los entusiastas o al público general que podría usarla para curiosidad.
Information
-
La información incluye las especificaciones del producto, la documentación técnica de los algoritmos de FFT y la API de sensores de los sistemas operativos, y los reportes de bugs previos.
Developer Relations
-
Una comunicación fluida permite entender la lógica detrás de los algoritmos y ayuda a los testers a reportar bugs de manera más efectiva.
Test Team
-
El equipo de pruebas puede estar compuesto por testers de software, sería ideal incluir a ingenieros estructurales para validar la precisión de los datos.
Equipment & Tools
-
e necesitan dispositivos móviles con diferentes versiones de Android e iOS, herramientas de depuración para ver los logs y el tráfico de red.
Structure
-
La app incluye la Interfaz de Usuario (UI) para la interacción, los componentes de software que se comunican con el acelerómetro y el giróscopo, el módulo de procesamiento de señales que realiza el análisis de FFT y la base de datos o sistema de archivos para guardar los resultados.
Functions
-
Clave son iniciar y detener una medición, visualizar la vibración en tiempo real, calcular la frecuencia natural y la amplitud, y permitir la exportación de los datos en formatos como CSV o un archivo de reporte.
-
Test Items
Los elementos a probar son las diferentes versiones de la aplicación (beta, release candidates) y los parches.
-
Deliverables
Los resultados de las pruebas, como los reportes de bugs detallados, las matrices de cobertura y los informes de calidad, son los entregables más importantes.
-
Data
-
Los datos de entrada son la aceleración registrada por los sensores en los tres ejes (X, Y, Z).
Platform
-
Se debe probar la aplicación en múltiples plataformas, es decir, en dispositivos con Android y iOS
Operations
-
Las operaciones a probar incluyen el flujo completo del usuario: abrir la app, calibrar el sensor (si aplica), iniciar la medición, ver los resultados y exportarlos.
Time
-
Se debe probar la precisión del tiempo de medición, la capacidad de la aplicación para manejar datos en tiempo real sin latencia significativa
Function Testing
-
Probar cada botón, cada gráfico y cada cálculo para asegurar que funcionan según lo especificado.
Claims Testing
-
Verificar las afirmaciones de la aplicación (por ejemplo, "precisión de 0.1 Hz" o "capacidad para medir hasta 50 Hz") contra datos de referencia.
Domain Testing
-
Probar los rangos de entrada del sensor, desde vibraciones muy pequeñas hasta las más grandes que el hardware puede captar.
User Testing
-
Pedir a ingenieros y a otros usuarios que prueben la aplicación para obtener retroalimentación sobre la usabilidad y la utilidad de las características.
Stress Testing
-
Realizar mediciones continuas durante un largo período (varias horas) para ver si la aplicación falla.
-
Flow Testing
-
Usuario que inicia una medición, la pausa, la reanuda, la detiene y la exporta.
Automatic Testing
-
Usar scripts de automatización para probar flujos repetitivos, como la instalación, el inicio de sesión y la navegación básica.
Scenario Testing
-
Crear escenarios de uso realistas, como la medición de una viga de madera versus una de hormigón, y verificar si los resultados tienen sentido.
Operational Criteria
-
La aplicación debe ser usable (fácil de usar para el público objetivo), fiable (no debe fallar durante la medición), tener un buen rendimiento (procesamiento rápido de los datos) y ser segura (proteger los datos del usuario).
Development Criteria
-
El código debe ser limpio y estar bien documentado, la arquitectura de la aplicación debe ser escalable para futuras características y debe haber un buen sistema de control de versiones.
-