Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Para trabajar con Analytics y crear informes, se deben cumplir varios requisitos previos como se resume en este artículo.
De forma predeterminada, a todos los miembros del proyecto se les proporciona acceso a los datos de Analytics para los proyectos de los que son miembros, incluidos los miembros agregados al grupo Lectores del proyecto. Los usuarios con acceso a partes interesadas no tienen acceso para ver ni editar vistas de Análisis.
Habilitación de servicios y características
En general, Analytics siempre está activado y disponible para los miembros de una organización o colección para consultar datos y crear informes.
Servicio de análisis
Para Azure DevOps Services, Analytics siempre está activado. No se puede deshabilitar ni pausar.
En el caso de Azure DevOps Server 2020 y versiones posteriores locales, Analytics se instala automáticamente con cada colección de proyectos que cree.
Puede pausar y reiniciar el servicio. Cuando se pausa, no se agregan nuevos datos a Analytics.
Para obtener más información, consulte Instalación o habilitación del servicio Analytics.
Servicios de Azure DevOps
Para ejercer cualquier servicio de Azure DevOps, debe estar habilitado. No se puede capturar ningún dato para un servicio que se haya deshabilitado. Los servicios se pueden habilitar o deshabilitar en un proyecto por proyecto.
Para comprobar que todos los servicios están habilitados, consulte Activar o desactivar un servicio.
Vistas de análisis
Vistas de Analytics, un centro en el portal web, proporcionan una manera simplificada de especificar los criterios de filtro para un informe de Power BI basado en los datos de Analytics. Para obtener más información, consulte ¿Qué es el Servicio de análisis?
Para acceder a las vistas de Analytics, debe estar habilitado. El propietario de la organización o miembro del grupo Administradores de colecciones de proyectos puede habilitarlo para todos los miembros de la organización. O bien, cada miembro del proyecto puede habilitarlo para sí mismo.
Para obtener información sobre cómo hacerlo, consulte Administración o habilitación de características.
Permisos
Establezca permisos para el servicio en el nivel de proyecto y para las vistas de Análisis compartidas en el nivel de objeto.
En la tabla siguiente se resumen los permisos disponibles para establecerse y las asignaciones predeterminadas realizadas a los grupos de seguridad del proyecto.
| Permiso | Lectores | Colaboradores | Administradores de proyectos |
|---|---|---|---|
| Ver analíticas | ✔️ | ✔️ | ✔️ |
| Visualización de una vista de Análisis compartido | ✔️ | ✔️ | |
| Adición de una vista de análisis privada o compartida | ✔️ | ✔️ | |
| Edición y eliminación de vistas de Análisis compartidos | ✔️ |
Requisitos previos de seguimiento de datos
Para capturar datos significativos, los equipos de software deben realizar acciones significativas. En las secciones siguientes se proporcionan recomendaciones generales basadas en el tipo de datos en los que desea informar.
Nota:
Los conjuntos de entidades branch, Pipeline y Test son compatibles con Analytics v3.0-preview y versiones posteriores. Los conjuntos de entidades de instantáneas para admitir trabajos de canalización, solicitudes de agente de tareas y tamaño del grupo de agentes de tareas se agregaron con la versión preliminar de Analytics v4.0. Asegúrese de especificar la versión de Analytics que admite el conjunto de entidades de interés.
Para comprender qué propiedades y valores de lista enumerados puede filtrar o agrupar datos, explore los metadatos de Analytics para el tipo de entidad correspondiente.
Azure Boards y seguimiento del trabajo
Para obtener una revisión de los conjuntos de entidades disponibles que puede consultar, consulte Referencia de metadatos para Azure Boards Analytics.
Para informar sobre el seguimiento del trabajo, los equipos deben realizar varias tareas para asegurarse de que hay datos significativos disponibles. Revise las siguientes tareas antes de definir las consultas e informes de Analytics.
- Para informar sobre errores activos o tendencias de errores, defina errores y actualice el estado del error tal como se ha corregido, comprobado y cerrado.
- Para informar sobre el trabajo pendiente u otros tipos de elementos de trabajo, asegúrese de definir esos elementos de trabajo y actualizar su estado a medida que pasa desde nuevo a cerrado. Tenga en cuenta los campos o etiquetas que usará para filtrar o agrupar datos en un informe y asegurarse de que está bien definido y coherente.
- Para admitir informes acumulativos, asegúrese de que existen vínculos de padre e hijo entre los elementos del backlog de producto y tareas o defectos, o existen vínculos de padre e hijo entre las funcionalidades o los elementos del backlog de cartera y sus elementos secundarios. Para obtener más información, vea Organizar el trabajo pendiente y asignar elementos de trabajo secundarios a los elementos primarios.
- Para crear informes de gráficos de quemado o gráficos de progreso, como gráfico de quemado de sprint o gráfico de quemado de versión, asegúrese de haber pensado en cómo desea filtrar y agrupar los datos en su informe. Los informes de burndown o burnup hacen referencia al
WorkItemsSnapshotconjunto de entidades. Los conjuntos de entidades de instantáneas se modelan como instantáneas diarias. Los datos se agregan en función de las asignaciones realizadas a partir de la fecha en que se asignan. Esto significa que para filtrar un informe de burndown o burnup basado en las asignaciones de campos o etiquetas, debe asignar los campos o etiquetas antes del período sobre el que desea generar el informe. De lo contrario, el informe no registra los campos o etiquetas hasta la fecha en que se aplican. - Para admitir el seguimiento de requisitos, defina casos de prueba y cree un vínculo Probado por desde cada caso de prueba a un caso de usuario, un elemento de trabajo pendiente de producto o un requisito. Defina casos de prueba y vincule los casos de prueba a sus PBIs primarios mediante el vínculo Probado por. Consulte Creación de pruebas.
- (Recomendado) Para admitir el filtrado y la agrupación dentro de un informe, asigne ruta de acceso de área e ruta de acceso de iteración a todos los elementos de trabajo. Para obtener información sobre cómo definir rutas de acceso de iteración y área, consulte Definir rutas de acceso de área y asignarlas a un equipo o Definir rutas de iteración (sprints) y configurar iteraciones de equipo.
Nota:
Todos los campos personalizados agregados a un tipo de elemento de trabajo están disponibles para su uso en los informes. Los campos personalizados se etiquetan con Custom_DisplayNameOfField, donde se han quitado todos los espacios del nombre para mostrar.
Planes de pruebas
Para revisar el progreso del plan de prueba y la preparación de los casos de prueba, los equipos deben realizar las siguientes actividades.
- Defina casos de prueba, planes de prueba y conjuntos de pruebas y especifique su estado actual. Para obtener más información, consulte Creación de planes de prueba y conjuntos de pruebas y Creación de casos de prueba.
- Actualice el estado de los objetos de prueba a medida que avanzan de Diseño a Listo para cerrar.
- Para las pruebas manuales, marque los resultados de cada paso de validación en el caso de prueba como superado o erróneo.
Sugerencia
Los evaluadores deben marcar un paso de prueba con un estado si es un paso de prueba de validación. El resultado general de una prueba refleja el estado de todos los pasos de prueba marcados. Por lo tanto, la prueba tendrá un estado de error si algún paso de prueba está marcado como erróneo o no marcado.
- En el caso de las pruebas automatizadas, cada prueba se marca automáticamente como superada o con errores.
- (Recomendado) Para admitir el filtrado y la agrupación dentro de un informe, asigne Ruta de área y Ruta de iteración a casos de prueba, conjuntos de pruebas y planes de prueba.
Canalizaciones
Para informar sobre las canalizaciones, los equipos deben definir canalizaciones mediante YAML y ejecutar canalizaciones periódicamente. Para más información, consulte Conceptos clave para los nuevos usuarios de Azure Pipelines.
Además, tenga en cuenta las siguientes acciones:
- Tenga en cuenta los datos en los que desea informar y elija el conjunto de entidades correcto. Para obtener una revisión de los conjuntos de entidades disponibles que se van a consultar, consulte Referencia de metadatos para Azure Pipelines Analytics.
- Tenga en cuenta las canalizaciones en las que desea informar y el intervalo de fechas del informe. Querrá filtrar los datos para cumplir los procedimientos recomendados de consulta y minimizar los problemas de rendimiento.
Canalizaciones y pruebas
Para informar sobre canalizaciones y resultados de pruebas, asegúrese de agregar tareas de prueba a la definición de canalización. Para obtener más información, consulte Tareas de construcción y lanzamiento-Prueba.
Si estás empezando, considera consultar este módulo de Learn, Ejecuta pruebas de calidad en la canalización de compilación mediante Azure Pipelines.