preguntas de la entrevista automatizados tres (41 a 60)

41, lo que las pruebas unitarias, pruebas de integración, pruebas del sistema de enfoque es?

Unidad de prueba: Para la unidad más pequeña de diseño de software - un módulo de programa (para el proceso es una función del proceso; es orientado a objetos), para probar la exactitud de la prueba, cada error se encuentra que pueden existir los módulos de programa en el interior. Hay dos pasos generales: la comprobación estática artificial \ tracing ejecución dinámica

agujas de prueba de integración: justo por las componentes de los módulos individuales integran la unidad de prueba se examinaron , y sus contenidos principales son la interfaz entre los módulos respectivos de la unidad , los módulos y las diversas funciones realizadas por la integración

prueba del sistema: se dirige a un buen sistema de software integrado , como un elemento de todo el sistema informático, en combinación con otros elementos del sistema de hardware del equipo \ \ Ordenadores Cierto software de soporte \ data y personal, para estar en el entorno de funcionamiento real , una serie de pruebas de sistema de integración y pruebas de validación

42, un ingeniero de pruebas debe tener esas cualidades?

　　1, 2 responsabilidad, habilidades de comunicación 3, 4 de trabajo en equipo, la paciencia, la atención, la confianza 5, siempre actitud escéptica, y conscientemente 6 prevención de defectos, y que tienen alguna experiencia en programación

43, usted sabe cuáles son los tipos de pruebas de software, una breve introducción.

estrategia de prueba por categoría:

1, estática y pruebas dinámicas
2, caja de negro y la caja blanca
3, la prueba manual y automatizado
4, prueba de humo
5, las pruebas de regresión;

Presione la Categoría fase de prueba:

Prueba de la unidad,
Las pruebas de integración,
Las pruebas del sistema;

Otros métodos comunes de ensayo:

1, pruebas funcionales
2, pruebas de rendimiento
3, prueba de esfuerzo
4, la prueba de carga
5, las pruebas de usabilidad
6, instalación y pruebas
7, las pruebas de interfaz
8, pruebas de configuración
9, prueba de documento
10, prueba de compatibilidad
11, las pruebas de seguridad
12, las pruebas de recuperación

44, ¿qué te parece la clave está en hacer el trabajo de plan de pruebas?

　　pruebas específicas, plan de pruebas mayor facilidad de uso

La elaboración de planes de pruebas de software han propósito importante es hacer que el proceso de pruebas puede encontrar más defectos de software, y por lo tanto el valor de los planes de pruebas de software dependen de él para ayudar a manejar los elementos de prueba, y encontrar posibles defectos de software. En consecuencia, el alcance de la prueba del plan de pruebas de software debe cubrir la altura de los requerimientos funcionales, el método de ensayo debe ser, herramientas de prueba practicables y tiene un alto práctico, fácil de usar, intuitiva generar resultados de las pruebas, precisa

Se adhieren a la regla "5W", contenido claro y el proceso de

"5W" regla se refiere al "Lo que (hacer)", "¿Por qué (qué hacer)", "Cuando (cuándo hacerlo)", "¿Dónde (en)", "¿Cómo (cómo hacerlo)." El uso de la regla de "5W" para crear un plan de prueba de software, puede ayudar a equipo de pruebas para entender el propósito de la prueba (por qué), el alcance y contenido de la prueba específica (Lo), determinar las fechas de inicio y final de la prueba (Al), señaló que los métodos y herramientas probadas ( cómo), da la ubicación de almacenamiento de la documentación de las pruebas y el software (Dónde).

Revisión y actualización del mecanismo adoptado para asegurar que el plan de pruebas para cumplir con la demanda real

Después de escribir el plan de prueba es completa, si no están sujetos a evaluaciones envía directamente al equipo de pruebas, el contenido de un plan de pruebas de la prueba puede ser contenido inexacto o falta, o requisitos de software cambio causado por cambios en el rango de prueba, y el contenido del programa de prueba no se actualiza, engañosa prueba Ejecutivo

Respectivamente, para crear un plan de prueba y probar las especificaciones detalladas, casos de prueba

Debe contener las especificaciones detalladas de la prueba a prueba creada independientemente especificaciones detalladas documento, el equipo de pruebas para guiar el proceso de la aplicación de casos de prueba en un documento separado caso de prueba o base de datos de gestión de casos de prueba creado. planes de prueba detallados y especificaciones de pruebas, casos de prueba es la relación entre la estrategia y la táctica, las actividades principales del plan de prueba de rangos de los métodos de prueba de macro y la asignación de recursos, y las especificaciones detalladas de las pruebas previstas, los casos de prueba es para completar las tareas de prueba tácticas específicas.

45. ¿Qué opinas de la clave es hacer el caso de prueba el trabajo de diseño?

Caja blanca con la realización clave está diseñado para utilizar menos casos cubrir la mayor parte de la lógica interna de los resultados del programa

método clave Ejemplo utilizando cuadro negro también está diseñado para utilizar menos casos cubierta de salida del módulo y una interfaz de entrada. no pueden ser probados por completo, con un uso mínimo de los casos encontraron que la mayoría de los problemas dentro de un plazo razonable

46. ¿Cuál es su meta profesional es a prueba?

Personalmente, creo que el más largo es el trabajo de prueba, cuanto más se encuentran propias deficiencias, por lo que la prueba no es necesario que acumulan experiencia y mejorar las capacidades de prueba, por lo que mi primera carrera toma tiempo para acumular resumen, mi segundo objetivo es el desarrollo de pruebas; y este año para probar el rendimiento y análisis automatizado determinaron que los programas de tiempo libre para el desempeño dirección optimización de aprendizaje; ver horario de la prueba durante el desarrollo del conocimiento y el aprendizaje, y mejorar constantemente las tareas de auto-corregirse a sí mismos y hacer las pruebas

47, ¿cuál es el final de los criterios de la prueba?

, Se define desde el micro está en el plan de prueba, tal como el sistema funcionando sin problemas durante 72 horas en un cierto rendimiento, Sistema de seguimiento de fallos de corriente, la presente versión no es generalmente un grave error, el número de ERROR ordinaria de 3 o menos, la tasa de reparación ERROR de 90% los parámetros anteriores, etc., y luego co-firmada por un gerente de desarrollo de lanzamiento de la versión reconocido, director de pruebas, director del proyecto.

Si la macro, es cuando el software desaparecer por completo después de la prueba ha terminado.

48, un conjunto completo de pruebas debe consistir en qué etapa?

Análisis de viabilidad, análisis de necesidades, diseño de contorno, diseño detallado, codificación, pruebas unitarias, pruebas de integración, pruebas del sistema, pruebas de aceptación

49 ¿Entiendes el pasado, el trabajo del proceso de desarrollo de software de la empresa? Si usted sabe, por favor Shishu un proceso de desarrollo completo de lo que hay que hacer? ¿Cuáles son los diferentes roles para completar estas tareas? todo lo que han trabajado específicamente qué tipo de trabajo en el trabajo previo de pruebas? ¿Qué parte de la obra el mejor?

--- necesidades de investigación proceso de desarrollo (personal de la demanda), análisis de necesidades (personal de la demanda), el esquema de diseño (diseño), el diseño detallado (el diseñador), codificación (desarrollador)

--- necesita prueba de evaluación, diseño de prueba del sistema, revisión del diseño preliminar, pruebas de integración, diseño, revisión detallada de diseño, diseño de prueba de unidad, la ejecución de pruebas

Todo el proceso de las pruebas se realizaron, bueno en la prueba de diseño

Proceso determina la calidad de la mejora de procesos de software, precisamente, con el fin de mejorar la calidad del software, las diversas lecciones del pasado acumulado.

50, lo que es la prueba de los principios de diseño caso? En la actualidad los principales métodos de diseño de casos de prueba hay?

Representación: representar y cubrir toda la frontera razonable y no razonable, legal e ilegal, y transfronteriza, así como datos de entrada, operación y límites de ajuste del medio ambiente y así sucesivamente.

Decidibilidad: es decir, la exactitud de los resultados de la prueba se determinan para cada caso de prueba debe tener un resultado deseado correspondiente.

Reproducibilidad: los resultados de la misma prueba realizada, el sistema debe ser la misma.

Métodos de equivalencia clases, de valor límite, diagramas causales, diagramas de estado, método de cuadratura, un proceso de inferencia error

51, hay varias formas de diseño orientado a objetos de prueba? ¿Cómo lograr?

Cada constructor de la clase para diseñar un conjunto de casos de prueba
Combinación de variables de clase, clase de variables de instancia
Varias combinaciones de métodos de clase
Las condiciones previas y post-condiciones casos de prueba
De acuerdo con los casos de prueba de diseño de código

52, en el que prueba el mayor interés? ¿Por qué?

el interés más grande se está poniendo a prueba difícil y desafiante! Haga la prueba se pone mejor capaz de sentir lo difícil que hacer la prueba. Había visto un artículo en una prueba en línea sin preocupaciones es acerca de cómo hacer un ingeniero de pruebas. Enumera un total de 11 puntos, y algunos están relacionados con la personalidad, algunos esfuerzos se deben adquirir. Pero además del punto sobre el carácter no estoy seguro de 1,2, otros puntos Tengo mucha confianza para hacerlo.

Acaba de empezar a entrar en la industria de las pruebas, el conocimiento de la prueba es entender parte de la información de la prueba sin problemas a Internet, la prueba fue dirigida a hacer requiere de mucha habilidad para hacerlo bien, aunque la entrada es fácil, pero es difícil hacer algo más que el desarrollo difícil, aunque en ese momento que quería hacer el desarrollo (cursos de la escuela que, básicamente, no se pierda, porque me gusta mi profesión), pero más difícil de ver el examen más difícil de desarrollar, probar va a querer hacer aún más fortalecido.

Siento que todo el proceso de prueba me hace pensar que hay dos (para mí, las cosas difíciles Me interesó mucho) muy difíciles

El primero es un diseño de casos de prueba, la prueba debido a que la esencia de la misma, y para salir en la versión anterior, los casos de uso escritas en el diseño de casos de prueba, métodos de escritura lo pruebas? (Es decir, planes de prueba o estrategia de prueba), si sólo probó una nueva tarea, usted tiene que pasar algún tiempo para digerir los requerimientos del negocio y la infraestructura técnica, las necesidades del negocio están bien entendida (y gestores de múltiples productos y desarrolladores serán capaces de lograr una comunicación propósito), y la base de la tecnología no puede ser tan simple, y esta capacidad que usted necesita aprender auto-consciente, tales como el sitio de la misma, los conocimientos técnicos básicos que necesita saber cómo funciona el interior del sitio, y el fondo es cómo responder a las peticiones de los usuarios? Cómo configurar un entorno de prueba? Estos necesidad de aprender en primer lugar. Puede hacer por lo menos las preparaciones básicas antes de iniciar la prueba, puede encontrarse con algún problema? Determinar los detalles de la demanda no es nada bueno? Estos problemas se pueden encontrar en el diseño de casos de uso.
El segundo es el tiempo para encontrar ERROR, esto debería ser las tareas más básicas de los probadores, de acuerdo con la prueba general para iniciar el proceso de prueba se puede encontrar en el caso de la mayor parte del insecto, todavía hay algunos errores que ser probado en una mejor comprensión de la versión medido para obtener más información, los casos de prueba complementarios, prueba a cabo el fallo. Y cómo encontrar error? Esto requiere eficaz en el caso de prueba, a través de cuidado y paciencia para encontrar un error, y cada caso de uso es probable que encuentre un error, cada lugar puede salir mal, por lo que el proceso de prueba que se pensaba con claridad (el proceso de prueba y los datos fluyen los resultados tenían que mirar en el interior con cuidado, insecto se encuentran). ¿Cómo describir también muy particular insecto, insecto bajo qué circunstancias producirían, si las condiciones cambian un poco, no tienen este error, al menos los pasos que va a ser capaz de reproducir este insecto, insecto produce lo que la ley es? Si usted es lo suficientemente alto, puede ayudar a los desarrolladores a localizar el problema inicial.

53, que está familiarizado con los tipos de pruebas de software ¿Cuáles son? Debemos tratar de comparar estos diferentes tipos de pruebas y su conexión (por ejemplo, pruebas funcionales, pruebas de rendimiento ......)

Tipos de pruebas: pruebas funcionales, pruebas de rendimiento, pruebas de la interfaz.

Las pruebas funcionales representaron la proporción más grande de las pruebas, las pruebas funcionales, también conocida como la prueba de caja negro. Es para probar el objeto como un cuadro negro. Cuando el negro-box método la prueba utilizando el ensayo dinámico, es necesario para probar la función de productos de software, sin la prueba de la estructura interna de los productos y procesos de software. casos de prueba negro de la caja utilizando la tecnología de los métodos de diseño son: la partición de equivalencia, análisis de valores límite, error de adivinanzas, diagramas de causa y efecto y la estrategia global.

Las pruebas de rendimiento es probar la variedad analógica rendimiento del sistema de las condiciones normales, anormales y pico de carga a través de las herramientas de prueba automatizados. Cargar y pruebas de estrés pertenecen prueba de rendimiento, los dos se pueden combinar. Por las pruebas de carga para determinar el rendimiento del sistema en una variedad de cargas de trabajo, el objetivo es aumentar gradualmente cuando la prueba de carga, el cambio de los indicadores de rendimiento del sistema. La prueba de presión es un sistema mediante la identificación de los cuellos de botella o no puede recibir puntos de rendimiento, para obtener el sistema de prueba máxima de nivel de servicio puede proporcionar.

pruebas de la interfaz, el software de capa de interfaz es la interacción más directa y fácil, buena interfaz de usuario o mala decisión la primera impresión del software. interfaces de usuario adicionales bien diseñados pueden ser guiados para completar sus respectivas operaciones, funciones asistente. Si bien la interfaz como la cara de un hombre, con una ventaja directa para atraer clientes. interfaz bien diseñada para dar a los usuarios una sensación de relajación y la sensación de éxito, por el contrario, debido a la falla de diseño de la interfaz, lo que permite a los usuarios tener la frustración, a continuación, práctico puede poderosa en el usuario ha desperdiciado en el miedo y darse por vencido.

La diferencia es que, en todas las características de las pruebas funcionales del producto de que se trate, teniendo en cuenta cada detalle funciones de cada uno de los posibles problemas. prueba de rendimiento se centró en la estabilidad y robustez del producto en su conjunto bajo la concurrencia multi-usuario. Interfaz de prueba más centrado en la experiencia del usuario, el usuario al utilizar el producto o no de usar, fácil de entender si, si la especificación (atajos similares), es hermoso (la capacidad de atraer la atención del usuario), si es seguro (por lo que datos no válidos evitar la recepción de entrada del usuario no intencional, por supuesto, tienen en cuenta la experiencia, no pueden ser emergente de advertencia demasiado grosero)? Hacer una prueba de rendimiento al principio puede ser un puntos de función, hay que asegurarse primero de su función no es ningún problema, y luego considerar la prueba de rendimiento de los puntos de la entidad

Las pruebas de usabilidad - interfaz de uso, facilidad de operación y así sucesivamente.
Prueba funcional - sistema para cumplir con los requisitos funcionales
Las pruebas de seguridad - si el sistema es un riesgo para la seguridad y la vulnerabilidad
Pruebas de Rendimiento - respuesta del sistema y robustez en gran concurrente

54, tratan de comparar las diferencias y relaciones entre las pruebas de negro caja, pruebas de caja blanca, las pruebas unitarias, pruebas de integración, pruebas del sistema, pruebas de aceptación.

Pruebas de Caja Negro: especificaciones de diseño funcionales conocidos productos pueden ser probados cada implementación de las funciones cumple con los requisitos.
pruebas de caja blanca: el funcionamiento interno de los productos del procedimiento conocido, se puede probar si cada uno de la operación se encuentran interna las especificaciones de diseño, si todos los componentes internos a fin de pasar la inspección.

　　cuadro de prueba negro de medios de software que la prueba se realice en la interfaz del software. Este método es para ser visto como un objeto de prueba de la caja negro, el probador no tiene en cuenta la estructura lógica y características internas dentro del programa, sólo las instrucciones de programa de acuerdo con la especificación de los requisitos, la función comprueba si el programa es su descripción funcional. Llamado cuadro de prueba negro de la prueba funcional o de datos basado en pruebas.

pruebas de caja negro es principalmente para descubrir los tipos de errores:

1, si hay funciones incorrectas o que faltan?
2, en la interfaz, la entrada se acepta correctamente? puede hacer salir el resultado correcto?
3, si hay un error o una información externa estructura de datos (como archivos de datos) Error de acceso?
4, es capaz de satisfacer los requisitos de rendimiento? 5. ¿Hay un error de inicialización o terminación?

　　software de pruebas de caja blanca es hacer un examen detallado de los detalles de procedimiento de software. Este método es considerado como un objeto de prueba para abrir la caja, que permite que el probador de usar la estructura lógica interna de los programas e información, diseñados o seleccionados casos de prueba para las pruebas de los procedimientos de todas las rutas lógicas. Al marcar los procedimientos en diferentes puntos del estado, para determinar si el estado real de la frontera del estado con las expectativas. Por lo tanto la prueba de caja blanca también se conoce como prueba de la unidad estructural o lógica.

los módulos del programa de pruebas de caja blanca quieren sobre todo de comprobar lo siguiente:

　　1, todos ruta de ejecución independiente de los módulos de programa probados al menos una vez.

　　2, toda la lógica de decisiones tomadas "verdadera" toma y daca "falsa", tanto si se mide al menos una vez.

　　3, el bucle de realizar dentro de medidas y límites del ciclo de funcionamiento.

　　4, las pruebas de la eficacia de las estructuras de datos internos, y así sucesivamente.

Prueba de la unidad (módulo de prueba) es una pequeña pieza de desarrolladores de código para escribir un pequeño código de prueba en prueba, es clara la función correctamente. Típicamente, una unidad de prueba para juzgar una condición específica (o escena) actúa en una función particular.
Prueba de la unidad se realiza por los programadores a sí mismos, los beneficiarios finales son también el programador. Se puede decir que el programador tiene la responsabilidad de escribir código funcional, mientras que tiene la responsabilidad de escribir pruebas unitarias para su código. Prueba de la unidad, sólo para demostrar que este código de conducta y consistentes con nuestras expectativas.

Las pruebas de integración (también llamada la prueba de montaje, prueba conjunta) es una prueba de la unidad lógica extensión. Es la forma más simple: dos han probado combinado en una unidad de montaje, y la interfaz entre ellas prueba. De un sentido, se refiere a un sistema integrado de conjunto de una pluralidad de unidades polimerizadas. En el escenario realidad, muchas unidades en componentes, estos componentes se convierten en una parte mayor del proceso de polimerización. Método de ensayo es una combinación de fragmentos, y, finalmente, ampliar el proceso de probar sus módulos con otros grupos de módulos. Por último, todos los módulos de prueba en conjunto conforman el proceso.

Las pruebas del sistema se prueba subsistema montado en un sistema completo de prueba. Comprueba si el sistema de hecho puede proporcionar un eficiente soluciones de sistema de especificación de método funciones especificadas. (Prueba común del FBI)
El objetivo es poner a prueba el sistema a fondo probar el sistema de software final, asegurar que los productos finales satisfacen las necesidades de software del sistema y el diseño del sistema a seguir.

Las pruebas de aceptación es la prueba final antes de la operación de despliegue de software. El propósito es asegurar que la prueba de aceptación del software está listo, y permite que el usuario final que se utilizará para el software de ejecución de la función y la tarea prevista.
Las pruebas de aceptación son los futuros usuarios que el sistema puede funcionar como requisitos programados. Por las pruebas de integración, ha sido diseñado de acuerdo con todos los módulos montados en un sistema de software completo, error de interfaz básicamente ha descartado, entonces deben estar más verificada la validez del software, que es la tarea de las pruebas de aceptación, es decir, el rendimiento funcional del software ya que el usuario pueda esperarse razonablemente.

55, cuando los desarrolladores dicen que no es ERROR, ¿cómo hacer frente?

　　Los desarrolladores dicen que no es error, hay dos casos,

En primer lugar, la demanda no está determinada, por lo que puedo hacer eso, esta vez consiguió el gerente de producto puede confirmar o necesidad de cambio, y después de 3 vías discusión para determinar un aspecto bueno en si o no al cambio.
En segundo lugar, esto es poco probable que suceda, por lo que no tenga que modificar este tiempo, puedo decir tanto como sea posible antes de que el error se basa en qué? Si se comprueba que el usuario o un problema, lo que los resultados adversos? Los programadores pueden darle una gran cantidad de razones, se puede refutar su interpretación. Si eso no funciona, entonces puedo hacer a esta pregunta, confirman con los gerentes de desarrollo y los administradores de prueba, si desea modificar en el cambio, si no se modifica no va a cambiar. De hecho, algunos realmente no fallo, acabo de recomendar formas escritos TD, si el desarrollador no modifica el gran problema. Si se determina que el error no olvide que atenerse a su posición, dejar que el problema de obtener la confirmación final.

56, ¿por qué debería llevar a cabo las pruebas de software de trabajo en equipo?

Porque no hay software probado es difícil saber la calidad del software antes de la liberación, al igual que la misma certificación de calidad ISO, poniendo a prueba también requiere la garantía de calidad, esta vez en la necesidad de trabajar en un equipo de pruebas de software.
En el proceso de pruebas de software encontrado problemas en el momento oportuno y que permite a los desarrolladores para modificar el problema, en la próxima versión, los resultados del informe de la prueba en el caso de software de calidad.

57, un plan de pruebas que debe incluir?

Fondo, perfiles de proyectos, con el propósito de la gama de prueba, estrategia de prueba, la división de personal, necesidades de recursos, programación, documentos de referencia, los términos comúnmente utilizados, para presentar los documentos, análisis de riesgos.

58, para el fondo de la industria de software, a entender cómo el negocio del software?

Lea el manual del propietario para las funciones de software y procesos operativos; vistazo a algunos de los negocios de los conocimientos libros profesionales servicios suplementarios, y si no es usuario de datos real, se puede obtener la referencia de datos reales, los casos anteriores de uso de referencia e informes de errores, el uso de productos de software más pensar, más intercambios y gerente de producto.

59, cómo colocar el papel de casos de prueba?

Organizacional: la preparación, organización, cobertura funcional, repetibilidad, seguimiento, prueba confirmó

60, ¿cuál es la prueba de compatibilidad? Dé un ejemplo de cómo utilizar la lista de pruebas de compatibilidad para el ensayo.

La compatibilidad del producto principal software de validación entre las diferentes versiones. Incluyendo tambaleó hacia atrás compatible y compatible, compatible con la nueva versión del caso de prueba de software es retener su función de versiones anteriores, es compatible escalonada para verificar la compatibilidad entre los dos productos idénticos coexistentes relacionados pero no son.

******* Por favor, respecto del original, en cuanto a la reimpresión, por favor indique la fuente: Tomado de: https://www.cnblogs.com/shouhu/ , gracias! ! *******