1. ¿Cómo probar una transferencia bancaria en línea?Diseñe un caso de prueba.
Ideas de respuesta:
Desde una perspectiva macro, podemos considerarlo desde el modelo de calidad (fórmula universal), centrándonos en probar la función, rendimiento y seguridad de las transferencias. Al diseñar casos de prueba, puede utilizar principalmente el método de escenario: primero, enumere el flujo básico y el flujo alternativo de transferencia. Luego diseñe el escenario y finalmente diseñe los datos según el escenario. Será necesario dar ejemplos específicos durante la entrevista real.
Primero verifique la interfaz.
Funciones de nueva prueba:
verificar transferencias entre pares y transferencias interbancarias.
Verifique los límites de transferencia.
Verificar transferencias desde cuentas ilegales (cuentas perdidas, congeladas o bloqueadas).
Pruebe el rendimiento nuevamente.
2. ¿Cuál es el proceso de trabajo de prueba? ¿Cuáles son los estados de los defectos? ¿Cuántos métodos existen para diseñar casos de prueba?
El flujo de trabajo real del ingeniero de pruebas (tomando como ejemplo la versión mediana de P2P, una versión por mes): el
gerente de producto o SR envía el documento de requisitos al desarrollo y las pruebas,
el evaluador lo lee primero y realiza el análisis de requisitos. El líder del equipo de prueba escribe el plan de prueba y asigna tareas de prueba a los probadores (2 días) (el desarrollo también está realizando un análisis de demanda en este momento). Después de
2 días, el gerente de producto reúne las pruebas y el desarrollo para explicar los requisitos (o hablar sobre revisión de requisitos), si tiene alguna pregunta, puede preguntarla directamente, si encuentra problemas con los requisitos, también puede plantearlos y el SR los modificará cuando regresen. (El tiempo de explicación de los requisitos es de 0,5 días)
Después de explicar los requisitos, los compañeros de prueba deben ordenar los escenarios de prueba y escribir los casos (se utilizarán xmind y Excel), lo que lleva un total de 5 días hábiles. (El desarrollo está escribiendo el código en este momento)
Después de eso, se llevará a cabo la revisión del caso. Durante la revisión, habrá SR, colegas de prueba y colegas de desarrollo. Durante la revisión, el SR, el líder del equipo de prueba y los colegas de desarrollo de el módulo correspondiente generalmente presentará algunas opiniones, después de la revisión, regrese, revise y agregue al caso. (0,5 días para revisión del caso)
Después de la modificación, hay dos situaciones:
para proyectos grandes, a veces se requiere una segunda revisión del caso.
Para proyectos pequeños, cuando el tiempo es escaso, generalmente no habrá una segunda revisión, pero los casos modificados o agregados deben enviarse por correo electrónico, mostrarse al líder y copiarse a otros colegas. (0,5 días para la revisión del caso, 0,5 días para la modificación del caso y 0,5 días para la segunda revisión del caso)
Después de la revisión del caso, comenzarán las pruebas. Generalmente, el entorno de prueba ha sido desarrollado y configurado (si tiene que decir que puede constrúyalo usted mismo, memorice el proceso de construcción resumido por el profesor):
versión de tamaño mediano Las pruebas generalmente se dividen en 2 rondas: la primera ronda: 5 días; la segunda ronda: 3 días; prueba de regresión durante 2 días; (un total de 10 días hábiles).
Una vez que se completa la prueba de regresión y se cumple el estándar de puesta en funcionamiento, se pondrá en línea según lo programado, generalmente a las 12 en punto de esa tarde.
Estado del defecto: diagrama de flujo de gestión de defectos
3. ¿Cuáles son los ERRORES clásicos que se encuentran en el proyecto?
Hay un problema de compatibilidad. En el navegador IE, se puede hacer clic en el botón enviar pedido, pero en Google Firefox no.
En la página de orden de consulta, los resultados filtrados según las condiciones no son los resultados deseados y los valores de algunos campos no se muestran o se muestran incorrectamente. (Debido a que el desarrollo obtuvo el valor de la tabla de la base de datos incorrectamente)
Una vez que el pago se realiza correctamente, el estado del pedido nunca cambia a transacción exitosa. (Debido a que el código no obtuvo correctamente el código de estado del registro de pago exitoso en la tabla de la base de datos) La
contraseña de pago fue modificada. La nueva contraseña era consistente con la contraseña original y fue aprobada. El sistema no verificó las contraseñas antiguas y nuevas.
El código de verificación del teléfono móvil al realizar el pago se puede utilizar para siempre y el período de validez se controla si no se realiza correctamente.
Después de desconectar la aplicación móvil de la red, cuando vuelve a hacer clic en ella, no aparece ninguna página de error descriptiva que indique que la red está desconectada y solo se devuelve indefinido.
4. ¿Cómo probar la transferencia automática de depósitos a plazo al vencimiento?
Idea de respuesta: Definitivamente habrá un límite cuando expire, por lo que el método del valor límite se puede considerar en el diseño. Transferencia automática (En primer lugar, debemos entender qué es la transferencia automática). ¿
Cómo probar el depósito y qué método de prueba se debe utilizar?
Ideas de preparación: el ahorro de dinero debe clasificarse en: depósitos a la vista, depósitos impares, etc. (consulte Baidu para conocer las reglas específicas) y luego elegir el método de diseño de casos de uso apropiado de acuerdo con las reglas comerciales de cada tipo. Por ejemplo, ¿cuál es el monto mínimo de depósito a la vez? La cantidad máxima que se puede depositar a la vez, etc.
5. ¿Qué debes hacer después de encontrar un error?
Primero, pregúntele al desarrollador si se trata de un error y déjele hacer un juicio preliminar.
Si no es un error, el desarrollador te dará una razón suficiente y es cierto que cometió un error, así que olvídalo.
Si el desarrollo también cree que se trata de un error, infórmelo directamente.
Si dudo de la respuesta del desarrollo y creo que es un error, pero el desarrollo insiste en que no es un error, consultaré a nuestro líder de equipo o al líder del equipo de desarrollo y les dejaré emitir un juicio.
6. Si se descubre un ERROR, no tiene nada que ver con el desarrollo en sí, involucra conceptos y requisitos, ¿cómo solucionarlo?
Exponga el problema al líder del equipo de prueba y al líder del equipo de desarrollo y solicite sus opiniones. Luego, los líderes del equipo informarán al gerente del grupo de desarrollo y al gerente del proyecto, y luego todos discutirán y resolverán el problema con el gerente de producto. Cualquier requisito que hay que cambiar hay que cambiar.
Durante el proceso de prueba muy urgente, se encontró un problema de bloqueo y el desarrollo correspondiente no tuvo tiempo de solucionarlo ¿Cómo promueven la solución del problema?
Primero determine la gravedad del problema y averigüe la causa del problema con el desarrollador correspondiente.
Luego infórmelo al líder del equipo de prueba y al líder del equipo de desarrollo, infórmeselo al líder del equipo, consulte sus opiniones y luego informe el problema al gerente del grupo de desarrollo para que lo coordinen y lo manejen. Contrate a otros desarrolladores senior con experiencia para que ayuden en este desarrollo a resolver problemas y luego trabaje horas extras para completar la resolución de problemas y las pruebas.
7. ¿Cómo se clasifican los niveles de ERROR de las pruebas funcionales?
Gravedad del error: generalmente se mencionan L4 y L3, y rara vez se menciona L2 a menos que afecte el proceso. L1 es un error muy fatal y básicamente no se mencionará.
8. Al ejecutar el caso de uso de otra persona, ¿qué debe hacer si encuentra un error en el caso de uso?
Primero, consulte al autor del caso o al líder del equipo de prueba para confirmar y, si efectivamente hay un error, corrija el caso de uso.
9. ¿Has hecho el lado del humo? ¿Qué son las pruebas de humo (teoría)?
Las pruebas de humo también se denominan pruebas previas, que son un tipo de prueba antes de las pruebas formales para garantizar que el proceso principal pueda ejecutarse sin problemas.
Puede responder que no hay una prueba de humo, solo diga que antes de la prueba, generalmente se requiere una autoprueba de desarrollo. Después de la autoprueba de desarrollo (la autoprueba dura aproximadamente un día), asegúrese de que no haya problemas importantes. y luego notifique al evaluador para que inicie la prueba.
10. ¿Cuánto tiempo llevas trabajando en tu proyecto y cuántos casos de uso has escrito en total? ¿Cuántas personas están involucradas en el proyecto?
Cuánto tiempo lleva el proyecto en marcha: (Dos respuestas, se recomienda elegir la primera)
El proyecto ya estaba en línea cuando entré, y siempre ha existido, y luego habrá actualizaciones menores a la versión. modificaciones, habrá una versión cada medio mes, y para modificaciones medianas, aproximadamente una versión al mes. Cada vez que se actualiza la versión, se escriben alrededor de 60 casos para nuevos puntos funcionales o puntos de modificación (un ejemplo de una versión por mes).
Cuando me uní, participé en este proyecto desde el principio (es decir, el comienzo del análisis de necesidades). El proyecto tomó aproximadamente medio año desde cero. En seis meses, todo el equipo del proyecto escribió alrededor de 900 casos. Yo mismo escribí unos 200 elementos (5 pruebas en total, incluido el líder del equipo).
PD: Si dices que estás involucrado en el proyecto desde cero, entonces 6 meses comienzan con el análisis de la demanda. Antes de redactar el documento de requisitos, el gerente de producto debe realizar una gran cantidad de trabajo de preparación preliminar, que puede llevar alrededor de 3 meses.
Entonces, el tiempo de trabajo real para las pruebas fue de 6 meses:
2 meses en la etapa inicial: al principio, había muchas lagunas en el documento de requisitos y hubo muchas revisiones de requisitos, básicamente una vez por semana. Tanto el desarrollo como las pruebas están involucrados. En este momento, el desarrollo es diseñar código y las pruebas son analizar los requisitos, leer documentos de referencia, usar xmind para clasificar escenarios de prueba y extraer puntos de prueba. El desarrollo a menudo discute los requisitos con los gerentes de producto y las pruebas con frecuencia. hace preguntas sobre gerentes de desarrollo y productos, preguntas sobre necesidades. Todos siguieron chocando y paso a paso se les ocurrió una lógica más perfecta.
Los 2 meses intermedios: una vez completados el desarrollo y el diseño, se lleva a cabo la codificación y nuestras pruebas se basarán en los escenarios de prueba previamente ordenados para escribir casos para una mayor optimización. Durante este período, el documento de demanda es básicamente estable y no volverá a modificarse. Cambiarlo significa refinar los requisitos y describir las áreas generales con más detalle y hacerlo más fácil de entender para las personas. La dirección general de los puntos de función no cambiará. Si tiene alguna pregunta durante el desarrollo y las pruebas, se comunicará con el gerente de producto por correo electrónico o por teléfono. Los evaluadores también suelen hacer preguntas de lógica de desarrollo sobre puntos de función.
Los próximos dos meses: comienza el trabajo de caso de implementación, que generalmente se divide en dos rondas de pruebas st, la primera ronda es de un mes, la segunda ronda es de medio mes y la prueba de regresión es de medio mes. El grupo de prueba de la Uat comenzó en paralelo durante la segunda ronda de la primera prueba. El equipo de prueba UAT tiene una persona dedicada a cargo. Generalmente, el equipo de prueba ST necesita enviar aproximadamente una persona para apoyar. La prueba UAT también tiene una primera ronda (medio mes) y una segunda ronda (medio mes).
Cuántas personas están involucradas en el proyecto: Una empresa suele tener muchos proyectos y yo solo soy parte de uno de los equipos del proyecto. Mi equipo de proyecto P2P tiene alrededor de 20 personas, 15 para desarrollo y 5 para pruebas. (Todos se consideran personal subcontratado, que trabaja para el Partido A, también llamado trabajo en el sitio)
11. Si le piden que pruebe un producto de préstamo p2p de 6 meses, ¿cómo debe diseñar el caso y establecer los puntos de prueba?
(Ideas de respuesta: 1. Pruebe desde la perspectiva del usuario. Puede probar cómo lo usa el usuario. 2. Pruebe por una persona que desempeña múltiples roles. 3. Piense en algunos escenarios anormales). En T+7 en la fecha de finalización de la
licitación del producto de préstamo, todas las Oferta y condiciones insatisfechas.
Antes de T+7, la fecha de finalización de la oferta de productos crediticios, el producto se ofertará completamente por adelantado.
Una vez establecido el producto, antes de la fecha de pago cada mes, verifique si el sistema ha enviado correos electrónicos, mensajes de texto o mensajes de texto. Cartas del sitio para notificar a los prestatarios que recarguen a la cuenta de la plataforma.
El día del pago mensual, cuando el prestatario recarga dinero para el pago, verifique cómo maneja el sistema la situación si los fondos de recarga son suficientes, insuficientes o no se recargan. Cuando los fondos de recarga son insuficientes o no hay recarga, el sistema debe tener intereses de penalización.
En el caso de que el prestatario cancele el saldo por adelantado, algunos productos no admiten el reembolso anticipado y algunos productos requieren el reembolso anticipado después de un cierto período de tiempo (hay una determinada tarifa de gestión por el reembolso anticipado). Todos estos son puntos de prueba en los que centrarse. (Debe actuar como prestatario para liquidar el saldo por adelantado, luego actuar como administrador backend para revisar y luego actuar como inversionista para verificar la llegada de fondos a la cuenta virtual) Cuando el prestatario liquida los fondos en el último período, vaya al
backend. Verifique el estado del producto de préstamo en la página y debería haber finalizado normalmente. Vaya a la página principal y busque nuevamente, no debería encontrar el producto de préstamo. (O agregue: Vaya a la base de datos para verificar el estado de este producto de préstamo)
12. ¿Está su P2P en línea? ¿Puedo comprobarlo? ¿Cuánto tiempo duró el proyecto y en cuánto tiempo se espera que esté terminado?
Respuesta: Hay dos opciones:
aún no está en línea y no se puede verificar. Este es un proyecto nuevo y está previsto que se complete en medio año. Sin embargo, debido a que algunos problemas no se han resuelto durante el proceso, no se ha completado dentro del tiempo estimado.
El nombre del proyecto que todos escribieron se puede encontrar en línea, por lo que se dice que está en línea y se puede encontrar. (De hecho, es posible que el entrevistador no lo verifique)
13. ¿Cómo se mide la autenticación del nombre real? ¿De qué plataforma desea recuperar datos?
Interfaz de autenticación de nombre real:
Autenticación del nombre real de la tarjeta bancaria (llame a la interfaz del banco para verificar el número de la tarjeta, el nombre, el número de identificación y el número de teléfono móvil. Debe utilizar el código de verificación recibido por el teléfono móvil)
Verificación de identidad y autenticación de nombre (Centro de Servicio de Consulta de Número de Identificación Nacional de Ciudadano, o directamente la interfaz de seguridad pública)
14. ¿El registro requiere autenticación de nombre real?
El registro no requiere autenticación de nombre real: se requiere autenticación de nombre real al comprar.
15. ¿También prueban la gestión backend para P2P? ¿Dónde recupero la información de mis puntos personales de Sesame Credit?
Gestión de antecedentes de prueba:
El backend también se prueba, pero yo pruebo principalmente el frontend. Mi atención se centra en el frontend. El backend es solo para uso, siempre que pueda cooperar con el frontend para completar el proceso normalmente.
El backend gestiona principalmente el frontend, incluida la gestión de préstamos y la gestión de fondos.
Gestión de préstamos: puede verificar el estado de inversión de los inversores, también puede verificar los productos de endeudamiento de los prestatarios y administrar los productos de endeudamiento. Por ejemplo, aprobación, recordatorios de pago para cada período, alertas tempranas, etc.
Gestión de fondos: administre y vea las recargas de los usuarios y apruebe los procesos de retiro de los usuarios.
Sesame Credit Points: llama a la interfaz de Alipay Sesame Credit: llama a la interfaz de Alipay (Alipay proporciona dicho servicio de Sesame Credit y cobra alrededor de 0,1 yuanes por cada cheque).
Finalmente me gustaría agradecer a todos los que leyeron atentamente mi artículo, la reciprocidad siempre es necesaria, aunque no es algo muy valioso, si puedes usarlo, puedes tomarlo directamente:
Estos materiales deberían ser el almacén de preparación más completo y completo para los amigos [de pruebas de software]. Este almacén también ha acompañado a decenas de miles de ingenieros de pruebas a través del viaje más difícil. ¡Espero que también pueda ayudarlos! Cualquiera que lo necesite Los socios pueden seguir el cuenta pública "Programador Tiger Balm"