150 въпроса и отговора за интервю за ръчно тестване за 2024 г
Обхванахме почти 150+ важни въпроса за тестване на софтуер viva за нови кандидати, както и ръчно тестване на опитни въпроси за интервю за QA инженери, за да ви помогнем да се подготвите за предстоящото интервю. Това подробно ръководство за въпроси за интервю за тестване на софтуер за опитни кандидати ще ви помогне да разбиете вашето интервю за работа за тестване на софтуер.
Въпроси и отговори за интервю за ръчно тестване за опитни и новаци
1. Какво е проучвателно тестване?
Проучвателното тестване е практически подход, при който тестерите участват в минимално планиране и максимално изпълнение на теста. Планирането включва създаването на тестова харта, кратка декларация за обхвата на кратко (1 до 2 часа) ограничено време тестово усилие, целите и възможните подходи, които да се използват. Дейностите по проектиране и изпълнение на теста обикновено се изпълняват паралелно без официално документиране на условията на теста, тестовите случаи или тестовите скриптове. Това не означава, че няма да се използват други, по-формални техники за тестване. Например, тестерът може да реши да използва анализ на гранични стойности, но ще обмисли и тества най-важните гранични стойности, без непременно да ги записва. Някои бележки ще бъдат написани по време на сесията за проучвателно тестване, така че след това да може да бъде изготвен доклад.
👉 Безплатно изтегляне на PDF: Въпроси и отговори за интервю за ръчно тестване
2. Какво е „тестване на случаи на използване“?
За да се идентифицира и изпълни функционалното изискване на дадено приложение от началото до края, се използва „случай на употреба“, а техниките, използвани за това, са известни като „тестване на случаи на употреба“.
3. Каква е разликата между STLC (жизнен цикъл на тестване на софтуер) и SDLC (жизнен цикъл на разработка на софтуер)?
SDLC се занимава с разработване/кодиране на софтуера, докато STLC се занимава с валидиране и проверка на софтуера
4. Какво е матрица за проследимост?
Връзката между тестовите случаи и изискванията се показва с помощта на документ. Този документ е известен като матрица за проследяване.
5. Какво представлява тестването на еквивалентното разделяне?
Тестването за разделяне на еквивалентност е техника за софтуерно тестване, която разделя входните тестови данни на приложението във всеки дял поне веднъж от еквивалентни данни, от които могат да бъдат извлечени тестови случаи. Чрез този метод на тестване се намалява времето, необходимо за тестване на софтуера.
6. Какво е тестване с бяла кутия и избройте видовете тестване с бяла кутия?
Техниката за тестване на бяла кутия включва избор на тестови случаи въз основа на анализ на вътрешната структура (покритие на код, покритие на клонове, покритие на пътища, покритие на условия и т.н.) на компонент или система. Известно е още като базирано на код тестване или структурно тестване. Различни видове тестване на бяла кутия са
- Покритие на изявлението
- Покритие на решението
7. Какво проверявате при тестване с бяла кутия?
При тестване на бяла кутия се проверяват следните стъпки.
- Проверете дупките в сигурността в кода
- Проверете непълните или счупени пътища в кода
- Проверете потока на структурата според спецификацията на документа
- Проверете очакваните резултати
- Проверете всички условни цикли в кода, за да проверите пълната функционалност на приложението
- Проверете кодирането ред по ред и покрийте 100% тестване
8. Какво е тестване на черна кутия? Какви са различните техники за тестване на черна кутия?
Тестването на черна кутия е методът за тестване на софтуера, който се използва за тестване на софтуера, без да се знае вътрешната структура на кода или програмата. Това тестване обикновено се прави, за да се провери функционалността на дадено приложение. Различните техники за тестване на черна кутия са
- Разделяне на еквивалентност
- Анализ на граничните стойности
- Графика причина-следствие
9. Каква е разликата между статичното и динамичното тестване?
Статично тестване: По време на метода за статично тестване кодът не се изпълнява, а се извършва с помощта на софтуерната документация.
Динамично тестване: За извършване на това тестване се изисква кодът да бъде в изпълнима форма.
10. Какво представляват проверката и валидирането?
Верификацията е процес на оценка на софтуера във фазата на разработка. Помага ви да решите дали продуктът на дадено приложение отговаря на определените изисквания. Валидирането е процес на оценка на софтуера след процеса на разработка и за проверка дали той отговаря на изискванията на клиента.
11. Какви са различните нива на теста?
Има четири тестови нива
- Тестване на модул/компонент/програма/модул
- Интеграционно тестване
- Тестване на системата
- Изпитване за приемане
12. Какво е интеграционно тестване?
Интеграционно тестване е ниво на процес на тестване на софтуер, при което отделни единици от приложение се комбинират и тестват. Обикновено се извършва след единично и функционално тестване.
13. От какво се състоят тестовите планове?
Дизайн на теста, обхват, стратегии за тестване, подход са различни детайли, от които се състои документът на тестовия план.
- Идентификатор на тестов случай
- Обхват
- Функции за тестване
- Характеристики, които не се тестват
- Тестова стратегия и тестов подход
- Резултати от теста
- Отговорности
- Подбор на персонал и обучение
- Риск и непредвидени обстоятелства
14. Каква е разликата между UAT (User Acceptance Testing) и системното тестване?
Тестване на системата: Тестването на системата е откриване на дефекти, когато системата се подлага на тестване като цяло; известно е още като тестване от край до край. При такъв тип тестване приложението страда от началото до края.
UAT: Тестване за приемане от потребителя (UAT) включва провеждане на продукт чрез поредица от специфични тестове, които определят дали продуктът ще отговори на нуждите на своите потребители.
15. Споменете разликата между тестване, управлявано от данни, и повторно тестване?
Повторно тестване: Това е процес на проверка на грешки, които се предприемат от екипа за разработка, за да се провери дали са коригирани.
Тестване, управлявано от данни (DDT): В процеса на тестване, управляван от данни, приложението се тества с множество тестови данни. Приложението е тествано с различен набор от стойности.
Въпроси за интервю за напреднали ръчно тестване на софтуер за 3/5/10 години опит
16. Кои са ценните стъпки за разрешаване на проблеми по време на тестване?
- Запис: Регистрирайте и управлявайте всички възникнали проблеми
- Доклад: Докладвайте проблемите на мениджър от по-високо ниво
- Контрол: Определете процеса на управление на проблема
17. Каква е разликата между тестови сценарии, тестови случаи и тестов скрипт?
Разликата между тестовите сценарии и тестовите случаи е тази
Тестови сценарии: Тестовият сценарий е всяка функционалност, която може да бъде тествана. Нарича се още тестово условие или тестова възможност.
Тестови случаи: Това е документ, който съдържа стъпките, които трябва да бъдат изпълнени; планирано е по-рано.
Тестови скрипт: Написан е на език за програмиране и е кратка програма, използвана за тестване на част от функционалността на софтуерната система. С други думи, писмен набор от стъпки, които трябва да се изпълняват ръчно.
18. Какво е латентен дефект?
Латентен дефект: Този дефект е съществуващ дефект в системата, който не причинява повреда, тъй като точният набор от условия никога не е бил изпълнен
19. Кои са двата параметъра, които могат да бъдат полезни за познаване на качеството на изпълнение на теста?
За да знаем качеството на изпълнение на теста, можем да използваме два параметъра
- Коефициент на отхвърляне на дефекти
- Коефициент на изтичане на дефект
20. Каква е функцията на инструмента за тестване на софтуер „фантом“?
Phantom е безплатен софтуер и се използва за скриптов език за автоматизиране на GUI на Windows. Позволява ни да контролираме прозорците и функциите автоматично. Може да симулира всяка комбинация от натискания на клавиши и щраквания на мишката, както и менюта, списъци и други.
21. Обяснете какво представляват тестовите резултати?
Резултатите от теста са набор от документи, инструменти и други компоненти, които трябва да бъдат разработени и поддържани в подкрепа на тестването.
Има различни тестови резултати на всяка фаза от жизнения цикъл на разработката на софтуер
- Преди тестване
- По време на тестване
- След Тестването
22. Какво е мутационен тест?
Тестването на мутации е техника за идентифициране дали набор от тестови данни или тестов случай е полезен чрез умишлено въвеждане на различни промени в кода (бъгове) и повторно тестване с оригинални тестови данни/случаи, за да се определи дали бъговете са открити.
23. Какви неща трябва да имате предвид, преди да изберете инструменти за автоматизация за AUT?
- Техническа осъществимост
- Ниво на сложност
- Стабилност на приложението
- Данни за теста
- Размер на приложението
- Повторна употреба на автоматизирани скриптове
- Изпълнение в цялата среда
24. Как ще извършите анализ на риска?
За анализа на риска трябва да се приложат следните стъпки
- Намиране на оценката на риска
- Изготвяне на профил на риска
- Промяна на свойствата на риска
- Разгърнете ресурсите на този тестов риск
- Създаване на база данни за риска
25. Какви са категориите за отстраняване на грешки?
Категории за отстраняване на грешки
- Отстраняване на грешки с груба сила
- връщане назад
- Елиминиране на причината
- Програмно нарязване
- Анализ на дървото на грешките
26. Какво е маскиране на грешки, обяснете с пример?
Когато наличието на един дефект скрива наличието на друг дефект в системата, това е известно като маскиране на грешка.
Пример: Ако „Отрицателната стойност“ причини задействане на необработено системно изключение, разработчикът ще предотврати въвеждането на отрицателни стойности. Това ще разреши проблема и ще скрие дефекта на необработено задействане на изключение.
27. Обяснете какво е тестов план? Каква е информацията, която трябва да бъде покрита в плана за тестване?
Планът за тестване може да се дефинира като документ, описващ обхвата, подхода, ресурсите и графика на дейностите по тестване, а планът за тестване трябва да обхваща следните подробности.
- Тестова стратегия
- Цел на теста
- Критерии за изход/спиране
- Планиране на ресурси
- Резултати от теста
28. Как можете да елиминирате продуктовия риск във вашия проект?
Помага ви да елиминирате продуктовия риск във вашия проект и има проста, но важна стъпка, която може да намали продуктовия риск във вашия проект.
- Проучете спецификационните документи
- Обсъдете проекта с всички заинтересовани страни, включително разработчика
- Като истински потребител се разходете из уебсайта
29. Какъв е общият риск, който води до провал на проекта?
Общият риск, който води до провал на проекта, е
- Няма достатъчно човешки ресурс
- Средата за тестване може да не е настроена правилно
- Ограничен бюджет
- Ограничения във времето
30. На каква база можете да стигнете до оценка за вашия проект?
За да оцените проекта си, трябва да имате предвид следните точки
- Разделете целия проект на най-малките задачи
- Разпределете всяка задача на членовете на екипа
- Оценете усилията, необходими за изпълнение на всяка задача
- Потвърдете оценката
31. Обяснете как бихте разпределили задача на членовете на екипа?
Task | Член |
---|---|
Анализирайте спецификацията на софтуерните изисквания | Всички членове |
Създайте спецификацията на теста | Тестер/тестов анализатор |
Изградете тестовата среда | Тестов администратор |
Изпълнете тестовите случаи | Тестер, тестов администратор |
Докладвайте дефекти | тестер |
32. Обяснете какво е тип тестване и какви са често използваните типове тестване?
За да се получи очакван резултат от теста, се следва стандартна процедура, която се нарича тип тестване.
Често използваните видове тестове са
- Тестване на единици: Тествайте най-малкия код на приложение
- API тестване: API за тестване, създаден за приложението
- Интеграционно тестване: Индивидуалните софтуерни модули се комбинират и тестват
- Тестване на системата: Пълно тестване на системата
- Тестване при инсталиране/деинсталиране: Тестване, извършено от гледна точка на клиент/клиент
- Agile тестване: Тестване чрез Agile техника
33. Докато наблюдавате проекта си, какви неща трябва да имате предвид?
Нещата, които трябва да се вземат предвид са
- Вашият проект в график ли е
- Над бюджета ли сте
- Работите ли за една и съща кариерна цел
- Имате ли достатъчно ресурси
- Има ли предупредителни признаци за предстоящи проблеми
- Има ли натиск от ръководството за по-бързо завършване на проекта
34. Кои са често срещаните грешки, които създават проблеми?
- Съпоставяне на ресурси с грешни проекти
- Липса на умения на мениджъра на тестовете
- Не слушане на другите
- Лошо планиране
- подценяване
- Игнориране на дребните проблеми
- Не следване на процеса
35. Какво съдържа типичният протокол от изпитване? Какви са предимствата на докладите от тестовете?
Докладът от теста съдържа следните неща:
- Информация за проекта
- Цел на теста
- Резюме на теста
- дефект
Ползите от докладите от тестовете са:
- Текущото състояние на проекта и качеството на продукта са информирани
- Ако е необходимо, заинтересованите страни и клиентите могат да предприемат коригиращи действия
- Окончателният документ помага да се реши дали продуктът е готов за пускане
36. Какво представлява прегледът на управлението на тестовете и защо е важен?
Прегледът на ръководството също се нарича Осигуряване на качеството на софтуера или SQA. SQA се фокусира повече върху софтуерния процес, отколкото върху софтуерните работни продукти. Това е набор от дейности, предназначени да гарантират, че ръководителят на проекта следва стандартния процес. SQA помага на мениджъра на теста да сравни проекта спрямо зададените стандарти.
37. Какви са най-добрите практики за осигуряване на качеството на софтуера?
Най-добрите практики за ефективно прилагане на SQA са
- Непрекъснато Усъвършенстване
- документация
- Използване на инструмента
- Метрика
- Отговорност на членовете на екипа
- Опитни SQA одитори
38. Кога се изготвя RTM (Матрица за проследяване на изискванията)?
RTM се подготвя преди проектирането на тестов случай. Изискванията трябва да могат да бъдат проследени от дейностите по преглед.
39. Каква е разликата между тестовата матрица и матрицата за проследяване?
Тестова матрица: Тестовата матрица се използва за улавяне на действителното качество, усилията, плана, ресурсите и времето, необходими за улавяне на всички фази на тестването на софтуера
Матрица за проследимост: Съпоставянето между тестовите случаи и изискванията на клиента е известно като матрица за проследяване
40. При ръчното тестване какво са мъничета и драйвери?
Както пъновете, така и драйверите са част от поетапното тестване. При постепенното тестване има два подхода, а именно подход отдолу нагоре и подход отгоре надолу. Драйверите се използват при тестване отдолу нагоре, а пънът се използва за подход отгоре надолу. За тестване на основния модул се използва мъниче, което е фиктивен код или програма.
41. Каква е стъпката, която бихте следвали, след като откриете дефекта?
След като бъде открит дефект, ще следвате стъпката
а) Пресъздайте дефекта
b) Прикачете екранната снимка
c) Регистрирайте дефекта
42. Обяснете какво е метод на тестване „Въз основа на план за тестване“ или „Въз основа на ключови думи“?
Тази техника използва действителния документ за тестов случай, разработен от тестери с помощта на електронна таблица, съдържаща специални „ключови думи“. Ключовите думи контролират обработката.
43. Какво е DFD (Диаграма на потока от данни)?
Когато „поток от данни“ през информационна система е представен графично, тогава той е известен като диаграма на потока от данни. Използва се и за визуализация на обработката на данни.
44. Обяснете какво е LCSAJ?
LCSAJ означава „линейна кодова последователност и скок“. Състои се от следните три елемента
а) Начало на линейната последователност от изпълними изрази
б) Край на линейната последователност
c) Целевата линия, към която се прехвърля контролният поток в края на линейната последователност
45. Обяснете какво е N+1 тестване?
Вариантът на регресионното тестване е представен като N+1. При тази техника тестването се извършва в множество цикъла, в които грешките, открити в тестов цикъл „N“, се разрешават и се тестват отново в тестов цикъл N+1. Цикълът се повтаря, освен ако не бъдат открити грешки.
46. Какво е Fuzz тестване и кога се използва?
Fuzz тестването се използва за откриване на вратички в сигурността и грешки в кодирането в софтуера. При тази техника произволни данни се добавят към системата в опит да се срине системата. Ако уязвимостта продължава, се използва инструмент, наречен fuzz tester, за определяне на потенциалните причини. Тази техника е по-полезна за по-големи проекти, но открива само голяма грешка.
47. Споменете кои са основните предимства на показателя за покритие на изявленията при тестване на софтуер?
Ползата от показателя за покритие на отчета е следната
а) Не изисква обработка на изходния код и може да се приложи директно към обектния код
б) Грешките се разпределят равномерно в кода, поради което процентът на обхванатите изпълними изрази отразява процента на откритите грешки
48. Как да генерирам тестови случаи за метода „замяна на низ“?
a) Ако знаци в новия низ > знаци в предишния низ. Нито един от знаците не трябва да се съкращава
b) Ако символите в новия низ < символите в предишния низ. Не трябва да се добавят нежелани знаци
c) Интервалите след и преди низа не трябва да се изтриват
d) Низът трябва да бъде заменен само за първото срещане на низа
49. Как ще се справите с конфликт между членовете на вашия екип?
- Ще говоря индивидуално с всеки човек и ще отбележа техните притеснения
- Ще намеря решение на често срещаните проблеми, повдигнати от членовете на екипа
- Ще проведа екипна среща, ще разкрия решението и ще помоля хората да си сътрудничат
50. Споменете какви са категориите дефекти?
Основно има три категории дефекти
- Погрешно: Когато дадено изискване е изпълнено неправилно
- Липсващ: Това е отклонение от спецификацията, индикация, че спецификацията не е изпълнена или изискване на клиента не е изпълнено
- екстра: Изискване, включено в продукта, което не е дадено от крайния клиент. Счита се за дефект, защото е отклонение от съществуващите изисквания
51. Обяснете как работи инструментът за тестово покритие?
Инструментът за тестване на покритието на кода работи паралелно, докато извършва тестване на действителния продукт. Инструментът за покритие на кода следи изпълнените оператори на изходния код. Когато финалното тестване е направено, ние получаваме пълен отчет за чакащите отчети и също така получаваме процента на покритие.
52. Споменете каква е разликата между „дефект“ и „провал“ при тестване на софтуер?
С прости думи, когато дефектът достигне до крайния клиент, той се нарича отказ, докато дефектът се идентифицира вътрешно и се разрешава; тогава се говори за дефект.
53. Обяснете как да тествате документи в проект, който обхваща целия жизнен цикъл на разработка на софтуер?
Проектът обхваща целия жизнен цикъл на разработка на софтуер по следния начин
- Централен/план за тестване на проекта: Това е основният план за тестване, който очертава пълната стратегия за тестване на проекта. Този план се използва до края на жизнения цикъл на разработка на софтуер
- План за приемно изпитване: Този документ започва през фаза на изискване и се завършва при окончателната доставка
- План за тестване на системата: Този план започва по време на плана за проектиране и продължава до края на проекта
- План за интеграция и тест на единица: И двата плана за тестване започват по време на фазата на изпълнение и продължават до окончателната доставка
54. Обяснете кои тестови случаи са написани първи черни кутии или бели кутии?
Първо се пишат тестови случаи на черна кутия, за да напишете тестови случаи на черна кутия; изисква план на проекта и документ за изискване, всички тези документи са лесно достъпни в началото на проекта. Докато писането на тестови случаи на бяла кутия изисква повече разбиране на архитектурата и не е налично в началото на проекта.
55. Обяснете каква е разликата между латентни и маскирани дефекти?
- Латентен дефект: Латентен дефект е съществуващ дефект, който не е причинил повреда, тъй като наборите от условия никога не са били изпълнени
- Маскиран дефект: Това е съществуващ дефект, който не е причинил повреда, защото друг дефект е попречил на тази част от кода да бъде изпълнена
56. Споменете какво е тестване отдолу нагоре?
Тестването отдолу нагоре е подход към интеграционното тестване, при което компонентите от най-ниско ниво се тестват първо, след което се използват за улесняване на тестването на компоненти от по-високо ниво. Процесът се повтаря, докато не бъде тестван компонентът на върха на йерархията.
57. Споменете какви са различните видове техники за тестово покритие?
Различни видове техники за тестово покритие включват
- Покритие на изявлението: Той проверява дали всеки ред от изходния код е изпълнен и тестван
- Покритие на решението: Той гарантира, че всяко решение в изходния код се изпълнява и тества
- Покритие на пътя: Той гарантира, че всеки възможен маршрут през дадена част от кода се изпълнява и тества
58. Споменете какво е значението на дихателния тест?
Дихателният тест е пакет от тестове, който упражнява пълната функционалност на даден продукт, но не тества характеристиките в детайли
59. Обяснете какво е значението на Code Walk Through?
Code Walk Through е неформален анализ на изходния код на програмата за намиране на дефекти и проверка на техники за кодиране
60. Споменете кои са основните компоненти на формата за докладване на дефекти?
Основните компоненти на формата на доклада за дефект включват
- Име на проекта
- Име на модула
- Открит дефект на
- Дефектът е открит от
- ID и име на дефекта
- Моментна снимка на дефекта
- Състояние на приоритет и сериозност
- Дефектът е разрешен от
- Дефектът е разрешен на
61. Споменете каква е целта зад извършването на тестване от край до край?
Тестването от край до край се извършва след функционално тестване. Целта зад извършването на тестване от край до край е тази
- За валидиране на софтуерни изисквания и интеграция с външни интерфейси
- Тестване на приложение в сценарий на реална среда
- Тестване на взаимодействие между приложение и база данни
62. Обяснете какво означава тестов сноп?
Тестовият сноп конфигурира набор от инструменти и тестови данни за тестване на приложение при различни условия и включва наблюдение на изхода с очаквания изход за коректност.
63. Обяснете в проект за тестване какви дейности по тестване бихте автоматизирали?
В дейностите по тестване на проекти за тестване бихте автоматизирали
- Тестове, които трябва да се изпълняват за всяка компилация на приложението
- Тестове, които използват множество данни за един и същи набор от действия
- Идентични тестове, които трябва да бъдат изпълнени с помощта на различни браузъри
- Критични за мисията страници
- Транзакция със страници, които не се променят за кратко време
64. Каква е ОСНОВНАТА полза от проектирането на тестове в началото на жизнения цикъл?
Помага да се предотврати въвеждането на дефекти в кода.
65. Какво е базирано на риска тестване?
Въз основа на риска Тестване е терминът, използван за подход за създаване на a Тестова стратегия който се основава на приоритизиране на тестове по риск. Основата на подхода е подробен анализ на риска и приоритизиране на рисковете по ниво на риск. След това се определят тестове за справяне с всеки риск, като първо се започне с най-високия риск.
66. Каква е КЛЮЧОВАТА разлика между превантивните и реактивните подходи към тестването?
Превантивните тестове са предназначени рано; реактивните тестове се проектират след като софтуерът е произведен.
67. Каква е целта на критериите за изход?
Целта на критериите за изход е да се определи кога дадено тестово ниво е завършено.
68. Какво определя нивото на риск?
Вероятността от нежелано събитие и въздействието на събитието определят нивото на риск.
69. Кога се използва тестване на таблицата с решения?
Тестването на таблицата с решения се използва за тестване на системи, за които спецификацията е под формата на правила или комбинации причина-следствие. В таблица с решения входовете са изброени в колона, като изходите са в същата колона, но под входовете. Останалата част от таблицата разглежда комбинации от входове, за да се определят произведените резултати.
Научете повече за техниката за тестване на таблицата с решения във видео урока тук
70. Защо използваме таблици за решения?
Техниките за разделяне на еквивалентност и анализ на гранични стойности често се прилагат към конкретни ситуации или входове. Въпреки това, ако различни комбинации от входни данни водят до предприемане на различни действия, това може да бъде по-трудно да се покаже чрез разделяне на еквивалентност и анализ на гранични стойности, които обикновено са по-фокусирани върху потребителския интерфейс. Другите две техники, базирани на спецификации, таблици с решения и тестване на прехода на състоянието са по-фокусирани върху бизнес логиката или бизнес правилата. Таблицата с решения е добър начин за справяне с комбинации от неща (напр. входове). Тази техника понякога се нарича също таблица „причина-следствие“. Причината за това е, че има свързана техника за логическа диаграма, наречена „графика на причината и следствието“, която понякога се използва за подпомагане на извличането на таблицата с решения
71. Каква е ОСНОВНАТА цел при преглед на софтуерен продукт?
За идентифициране на дефекти във всеки софтуерен работен продукт.
72. Кое от следните определя очакваните резултати от тест? Спецификация на тестов случай или спецификация на тестов дизайн.
Спецификацията на тестовия случай определя очакваните резултати от теста.
73. Каква е ползата от независимостта на теста?
Той избягва пристрастията на автора при дефинирането на ефективни тестове.
74. Като част от кой тестов процес определяте критериите за изход?
Изходните критерии се определят на базата на „Планиране на теста“.
75. Какво е алфа тестване?
Тестване преди пускане от представители на крайния потребител на сайта на разработчика.
76. Какво е бета тестване?
Тестване, извършено от потенциални клиенти на техните собствени места.
77. Споменете каква е разликата между пилотно и бета тестване?
Разликата между пилотно и бета тестване е, че пилотното тестване всъщност се извършва с помощта на продукта от групата потребители преди окончателното внедряване, а при бета тестването ние не въвеждаме реални данни, но се инсталира на крайния клиент за валидиране ако продуктът може да се използва в производството.
78. Като се има предвид следният фрагмент от код, колко теста са необходими за 100% покритие на решението?
if width > length thenbiggest_dimension = width if height > width thenbiggest_dimension = height end_if elsebiggest_dimension = length if height > length thenbiggest_dimension = height end_if end_if
4
79. Вие сте проектирали тестови случаи, за да осигурите 100% изявление и 100% покритие на решение за следния фрагмент от код. if width > length then large_dimension = width else large_dimension = length end_if Следното е добавено в долната част на кодовия фрагмент по-горе. print “Най-голямото измерение е ” &biggest_dimensionprint “Width: ” & width print “Length: ” & length Колко още тестови случая са необходими?
Няма, могат да се използват съществуващи тестови случаи.
80. Каква е разликата между техниките за тестване и инструментите за тестване?
Техника за тестване: – Това е процес за гарантиране, че някои аспекти на приложната система или модул функционират правилно, може да има малко техники, но много инструменти.
Инструменти за тестване: – е средство за извършване на тестов процес. Инструментът е ресурс за тестера, но сам по себе си е недостатъчен за провеждане на тестване
Научете повече за инструментите за тестване тук
81. Ние използваме резултата от анализа на изискването, спецификацията на изискването като вход за писане на...
Тестови случаи за приемане от потребителя
82. Многократно тестване на вече тествана програма, след модификация, за откриване на дефекти, въведени или разкрити в резултат на промените в тествания софтуер или в друг свързан или несвързан софтуерен компонент:
Тестване на регресия
83. Търговец на едро продава касети за принтери. Минималното количество за поръчка е 5. Има 20% отстъпка за поръчки на 100 или повече касети за принтери. Бяхте помолени да подготвите тестови случаи, като използвате различни стойности за броя на поръчаните касети за принтери. Коя от следните групи съдържа три тестови входа, които биха били генерирани с помощта на анализ на гранични стойности?
4, 5, 99
84. Какво е тестване на компоненти?
Тестването на компоненти, известно също като тестване на единици, модули и програми, търси дефекти в и проверява функционирането на софтуер (напр. модули, програми, обекти, класове и т.н.), които могат да се тестват отделно. Тестването на компонентите може да се извърши изолирано от останалата част от системата в зависимост от контекста на жизнения цикъл на разработката и системата. Най-често мъничетата и драйверите се използват за заместване на липсващия софтуер и просто за симулиране на интерфейса между софтуерните компоненти. Извиква се мъниче от софтуерния компонент, който ще се тества; драйверът извиква компонент за тестване.
Ето едно страхотно видео за Единично тестване
85. Какво е функционално системно тестване?
Тестването на функционалността от край до край на системата като цяло се определя като функционално системно тестване.
86. Какви са ползите от независимото тестване?
Независимите тестери са безпристрастни и идентифицират различни дефекти едновременно.
87. При РЕАКТИВЕН подход към тестването кога бихте очаквали да започне по-голямата част от работата по дизайна на теста?
По-голямата част от работата по дизайна на теста започва след като софтуерът или системата са произведени.
88. Какви са различните методологии в Agile Development Model?
В момента има седем различни гъвкави методологии, за които знам:
- Екстремно програмиране (XP)
- Спорна топка
- Lean Разработка на софтуер
- Разработка, управлявана от функции
- Гъвкав унифициран процес
- кристал
- Модел за развитие на динамични системи (DSDM)
89. Коя дейност в процеса на фундаментално тестване включва оценка на възможността за тестване на изискванията и системата?
„Анализът на теста“ и „Дизайнът“ включват оценка на тестваемостта на изискванията и системата.
90. Коя обикновено е НАЙ-важната причина за използване на риска за стимулиране на усилията за тестване?
Тъй като тестването на всичко не е възможно.
91. Какво е произволно/маймунско тестване? Кога се използва?
Случайното тестване често е известно като маймунско тестване. При такъв тип тестване данните се генерират на случаен принцип, често с помощта на инструмент или автоматизиран механизъм. С този произволно генериран вход системата се тества и резултатите се анализират съответно. Тези тестове са по-малко надеждни; следователно обикновено се използва от начинаещи и за да се види дали системата ще издържи при неблагоприятни въздействия.
92. Кои от следните са валидни цели за доклади за инциденти?
- Осигурете на разработчиците и другите страни обратна връзка относно проблема, за да позволите идентифициране, изолиране и коригиране, ако е необходимо.
- Дайте идеи за подобряване на тестовия процес.
- Осигурете средство за оценка на компетентността на изпитателя.
- Осигурете на тестващите средства за проследяване на качеството на тестваната система.
93. Помислете за следните техники. Кои са статични и кои динамични техники?
- Разделяне на еквивалентност.
- Тестване на случаи на използване.
- Анализ на потока от данни.
- Проучвателно изпитване.
- Тестване на решения.
- Проверки.
Анализът на потоците от данни и инспекциите са статични; Разделянето на еквивалентност, тестването на случаи на употреба, проучвателното тестване и тестването на решения са динамични.
94. Защо статичното изпитване и динамичното изпитване се описват като допълващи се?
Тъй като те споделят целта да идентифицират дефекти, но се различават по видовете дефекти, които откриват.
95. Какви са фазите на официалния преглед?
За разлика от неофициалните прегледи, официалните прегледи следват официален процес. Типичният официален процес на преглед се състои от шест основни стъпки:
- Планиране
- Първоначална
- Подготовка
- Review среща
- Преработи
- Последващи действия.
96. Каква е ролята на модератора в процеса на преглед?
Модераторът (или ръководителят на прегледа) ръководи процеса на преглед. Той или тя определя, в сътрудничество с автора, вида на рецензията, подхода и състава на рецензентския екип. Модераторът извършва проверка на входа и проследяване на преработката, за да контролира качеството на входа и изхода на процеса на преглед. Модераторът също така насрочва срещата, разпространява документи преди срещата, обучава други членове на екипа, определя темпото на срещата, води възможни дискусии и съхранява събраните данни.
Научете повече за Review процес във видео урок тук
97. Какво е дял на еквивалентност (известен също като клас на еквивалентност)?
Входни или изходни диапазони от стойности, така че само една стойност в диапазона става тестов случай.
98. Кога трябва да бъдат внедрени процедурите за управление на конфигурацията?
По време на планирането на теста.
99. Тип функционално тестване, което изследва функциите, свързани с откриването на заплахи, като вируси от злонамерени външни лица?
Тестване на сигурността
100. Тестване, при което подлагаме целта на теста на различни натоварвания, за да измерим и оценим поведението на производителността и способността на целта и теста да продължат да функционират правилно при тези различни натоварвания?
Тестване на товара
101. Тестващата дейност, която се извършва за разкриване на дефекти в интерфейсите и във взаимодействието между интегрираните компоненти, е?
Тестване на нивото на интеграция
102. Какви са техниките за тестване, базирани на структура (бяла кутия)?
Техниките за тестване, базирани на структура (които също са динамични, а не статични) използват вътрешната структура на софтуера за извличане на тестови случаи. Те обикновено се наричат техники на „бяла кутия“ или „стъклена кутия“ (което означава, че можете да виждате в системата), тъй като изискват познания за това как софтуерът е внедрен, т.е. как работи. Например, структурна техника може да се занимава с упражняване на цикли в софтуера. Могат да се изведат различни тестови случаи за упражняване на цикъла веднъж, два пъти и много пъти. Това може да се направи независимо от функционалността на софтуера.
103. Кога трябва да се извърши „Регресионно тестване“?
След промяна на софтуера или промяна на средата Регресионно тестване трябва да се извърши.
104. Какво е отрицателен и положителен тест?
Отрицателен тест е, когато въведете невалиден вход и получите грешки. Докато положителното тестване е, когато въведете валиден вход и очаквате някакво действие да бъде завършено в съответствие със спецификацията.
105. Каква е целта на критерия за завършване на теста?
Целта на критерия за завършване на теста е да се определи кога да се спре тестването
106. Какво НЕ може да открие статичният анализ?
Например изтичане на памет.
107. Каква е разликата между повторното тестване и регресионното тестване?
Повторното тестване гарантира, че първоначалният дефект е отстранен; регресионното тестване търси неочаквани странични ефекти.
108. Какви са техниките за тестване, базирани на опит?
При техниките, базирани на опит, знанията, уменията и подготовката на хората имат основен принос за условията на теста и тестовите случаи. Опитът както на техническите, така и на бизнес хората е важен, тъй като те внасят различни гледни точки в анализа на теста и процеса на проектиране. Поради предишен опит с подобни системи, те може да имат представа какво може да се обърка, което е много полезно за тестване.
109. Какъв тип преглед изисква официални критерии за влизане и излизане, включително показатели?
Инспекция
110. Могат ли прегледите или инспекциите да се считат за част от тестването?
Да, защото и двете помагат за откриване на грешки и подобряват качеството.
111. Едно поле за въвеждане приема годината на раждане между 1900 и 2004 г. Какви са граничните стойности за тестване на това поле?
1899,1900,2004,2005
112. Кой от следните инструменти ще бъде включен в автоматизацията на регресионния тест? а. Тестер за данни b. Граничен тестер c. Заснемане/Възпроизвеждане d. Изходен компаратор.
d. Изходен компаратор
113. За да тествате функция, какво трябва да напише програмист, който извиква функцията за тестване и предава тестови данни.
драйвер
114. Коя е единствената ключова причина, поради която разработчиците изпитват трудности при тестването на собствената си работа?
Липса на обективност
115. „Колко тестване е достатъчно?“
Отговорът зависи от риска за вашата индустрия, договора и специалните изисквания.
116. Кога трябва да се спре тестването?
Зависи от рисковете за системата, която се тества. Има някои критерии, въз основа на които можете да спрете тестването.
- Крайни срокове (тестване, пускане)
- Бюджетът за теста е изчерпан
- Процентът на грешки пада под определено ниво
- Завършени тестови случаи с определен процент преминат
- Алфа или бета периодите за тестване приключват
- Покритието на кода, функционалността или изискванията са изпълнени до определена точка
117. Кое от следните е основната цел на интеграционната стратегия за интеграционно тестване в малкия?
Основната цел на стратегията за интеграция е да уточни кои модули да се комбинират кога и колко наведнъж.
118. Какво представляват полуслучайните тестови случаи?
Полуслучайните тестови случаи не са нищо, но когато изпълняваме случайни тестови случаи и правим еквивалентно разделяне на тези тестови случаи, това премахва излишните тестови случаи, като по този начин ни дава полуслучайни тестови случаи.
119. Като се има предвид следният код, кое твърдение е вярно за минималния брой тестови случаи, необходими за пълен оператор и покритие на разклонения?
Прочетете стр
Прочетете q
АКО p+q> 100
СЛЕД ТОВА Отпечатайте „Голям“
ENDIF
АКО p > 50
СЛЕД ТОВА Отпечатайте „p Large“
ENDIF
1 тест за покритие на отчета, 2 за покритие на клона
120. Кой преглед обикновено се използва за оценка на продукт, за да се определи неговата пригодност за предвидената употреба и за идентифициране на несъответствия?
Технически Review.
121. От кого първоначално трябва да се документират намерените грешки?
От тестери.
122. Кой е настоящият официален световно признат стандарт за документация?
Няма нито един.
123. Кой от следните е участникът в прегледа, който е създал елемента за преглед?
автор
124. Редица критични грешки са коригирани в софтуера. Всички бъгове са в един модул, свързан с отчетите. Мениджърът на теста решава да направи регресионно тестване само на модула за отчети.
Регресионното тестване трябва да се направи и на други модули, тъй като коригирането на един модул може да засегне други модули.
125. Защо анализът на граничните стойности предоставя добри тестови случаи?
Тъй като често се правят грешки по време на програмирането на различните случаи близо до „ръбовете“ на диапазона от стойности.
126. Какво прави проверката различна от другите видове проверка?
Ръководи се от обучен лидер, използва официални критерии за влизане и излизане и контролни списъци.
127. Защо тестерът може да зависи от управлението на конфигурацията?
Тъй като управлението на конфигурацията гарантира, че знаем точната версия на тестовия софтуер и тестовия обект.
128. Какво е V-модел?
Модел за разработка на софтуер, който илюстрира как дейностите по тестване се интегрират с фазите на разработка на софтуер
129. Какво е тест за поддръжка?
Задейства се от модификации, миграция или оттегляне на съществуващ софтуер
130. Какво е тестово покритие?
Тестовото покритие измерва по някакъв специфичен начин количеството тестване, извършено от набор от тестове (извлечени по някакъв друг начин, напр. чрез използване на техники, базирани на спецификация). Навсякъде, където можем да преброим нещата и можем да кажем дали всяко от тези неща е било тествано чрез някакъв тест, тогава можем да измерим покритието.
131. Защо постепенната интеграция е предпочитана пред интеграцията на „големия взрив“?
Тъй като постепенното интегриране има по-добър скрининг на ранни дефекти и способност за изолиране
132. Какво се нарича процес, започващ с терминалните модули?
Интеграция отдолу нагоре
133. По време на коя тестова дейност грешката може да бъде открита най-рентабилно?
По време на планирането на теста
134. Целта на фазата на изискване е
За замразяване на изискванията, за разбиране на нуждите на потребителите, за определяне на обхвата на тестването
135. Защо разделяме тестването на отделни етапи?
Ние разделяме тестването на отделни етапи поради следните причини,
- Всеки тестов етап има различна цел
- По-лесно е да управлявате тестването на етапи
- Можем да проведем различни тестове в различни среди
- Ефективността и качеството на тестването се подобряват чрез поетапно тестване
136. Какво е DRE?
За да се измери ефективността на теста, се използва мощен показател за измерване на ефективността на теста, известен като DRE (ефективност на отстраняване на дефекти). От този показател ще знаем колко грешки сме открили от набора от тестови случаи. Формулата за изчисляване на DRE е
DRE=Брой бъгове по време на тестване/брой бъгове по време на тестване + брой бъгове, открити от потребител
137. Кое от изброеното е вероятно да има най-голяма полза от използването на инструменти за тестване, предоставящи средства за улавяне и възпроизвеждане на тест? a) Регресионно тестване b) Интеграционно тестване c) Системно тестване d) Тестване за приемане от потребителя
Регресионно тестване
138. Как бихте оценили количеството повторни тестове, които вероятно ще бъдат необходими?
Показатели от предишни подобни проекти и дискусии с екипа за разработка
139. Какво изучава анализа на потока от данни?
Използването на данни за пътища през кода.
140. Какво е провал?
Провалът е отклонение от определено поведение.
141. Какво представляват тестовите компаратори?
Наистина ли е тест, ако поставите някои входове в някакъв софтуер, но никога не гледате дали софтуерът дава правилния резултат? Същността на тестването е да проверим дали софтуерът дава правилния резултат и да направим това, като трябва да сравним това, което софтуерът произвежда с това, което трябва да произвежда. Тестовият компаратор помага да се автоматизират аспекти на това сравнение.
142. Кой е отговорен за документирането на всички въпроси, проблеми и открити въпроси, които са идентифицирани по време на срещата за преглед
книжник
143. Каква е основната цел на неформалния преглед
Евтин начин да получите някаква полза
144. Каква е целта на техниката за проектиране на тестове?
Идентифициране на тестови условия и Идентифициране на тестови случаи
145. Когато тества система за изчисляване на оценка, изпитващият определя, че всички резултати от 90 до 100 ще дадат оценка А, но резултати под 90 няма. Този анализ е известен като:
Еквивалентно разделяне
146. Тест мениджър иска да използва наличните ресурси за автоматизирано тестване на уеб приложение. Най-добрият избор е
Тестер, тест автоматизатор, уеб специалист, DBA
147. По време на тестване на модулен тестер, 'X' откри грешка и я възложи на разработчик. Но разработчикът отхвърля същото, като казва, че това не е грешка. Какво трябва да направи "X"?
Изпратете подробна информация за откритата грешка и проверете възпроизводимостта
148. Вид интеграционно тестване, при което софтуерни елементи, хардуерни елементи или и двете се комбинират наведнъж в компонент или цялостна система, а не на етапи.
Тестване на Големия взрив
149. На практика кой модел на жизнения цикъл може да има повече, по-малко или различни нива на разработка и тестване, в зависимост от проекта и софтуерния продукт. Например, може да има тестване за интегриране на компоненти след тестване на компоненти и тестване за системна интеграция след системно тестване.
V-модел
150. Коя техника може да се използва за постигане на входно и изходно покритие? Може да се приложи към човешки вход, въвеждане чрез интерфейси към система или параметри на интерфейса при интеграционно тестване.
Еквивалентно разделяне
151. „Този модел на жизнения цикъл се ръководи от график и бюджетни рискове“ Това твърдение е най-подходящо за.
V-модел
152. В какъв ред трябва да се провеждат тестовете?
Първо трябва да се тества най-важното
153. Колкото по-късно в жизнения цикъл на разработката се открие повреда, толкова по-скъпо е нейното отстраняване. защо
Грешката е вградена в повече документация, код, тестове и т.н
154. Какво е измерване на покритието?
Това е частична мярка за изчерпателност на теста.
155. Какво е тестване на гранични стойности?
Тествайте граничните условия на, под и над ръбовете на входните и изходните класове за еквивалентност. Например, да речем банково приложение, където можете да изтеглите максимум Rs.20,000 100 и минимум Rs.XNUMX, така че при тестване на гранични стойности ние тестваме само точните граници, вместо да удряме в средата. Това означава, че тестваме над максималната граница и под минималната граница.
156. Какво представлява COTS?
Реклама на рафта.
157. Коя цел е да позволи извършването на специфични тестове на система или мрежа, която наподобява възможно най-близко средата, в която тестваният елемент ще бъде използван при пускането му?
Тестова среда
158. Какво може да се смята за базирано на плана на проекта, но с повече подробности?
План за тестване на фази
159. Какво е бърза разработка на приложения?
Бързата разработка на приложения (RAD) формално е паралелна разработка на функции и последваща интеграция. Компонентите/функциите се разработват паралелно, сякаш са мини проекти, разработките се ограничават във времето, доставят се и след това се сглобяват в работещ прототип. Това може много бързо да даде на клиента нещо, което да види и използва и да предостави обратна връзка относно доставката и техните изисквания. Чрез тази методология са възможни бърза промяна и развитие на продукта. Въпреки това продуктовата спецификация ще трябва да бъде разработена за продукта в даден момент и проектът ще трябва да бъде поставен под по-официален контрол, преди да влезе в производство.
👉 Обърнете се към нашите – тест за тестване
👉 Обърнете се към нашите – Въпроси за интервю за тестване на софтуер Youtube видео
Безплатно изтегляне на PDF: Въпроси и отговори за интервю за тестване на софтуер
Въпросите и отговорите за интервю за ръчно тестване по-горе в PDF формат ще помогнат както на новопостъпилите, така и на опитните QA инженери. Моля, споделете страницата с приятели и колеги.