Шаги к воспроизведению / Результат / Ожидаемый результат

Билет №1

1. Основные понятия «Тестирования»

Тестирование программного обеспечения- проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ (TestManagement), проектированию тестов (TestDesign), выполнению тестирования (TestExecution) и анализу полученных результатов (TestAnalysis).

Верификация (Verification) - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

Валидация (Validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].

План Тестирования (TestPlan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Тест дизайн (TestDesign) - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Баг/Дефект Репорт (BugReport) - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Тестовое Покрытие (TestCoverage) - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.

Детализация Тест Кейсов (Test Case Specification) - это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию

Время Прохождения Тест Кейса (Test Case PassTime) - это время от начала прохождения шагов тест кейса до получения результата теста.

2. Условия для проведения тестирования

Необходимые условия:

Наличие объекта тестирования, доступного для проведения испытаний
Наличие исполнителя(ей) (в зависимости от вида проводимых испытаний им может быть как человек, так и машина или комбинация человек+машина)

Достаточные условия:

Наличие объекта тестирования, доступного для проведения испытаний
Наличие исполнителя(ей) (в зависимости от вида деятельности на разных фазах им может быть как человек, так и машина или комбинация человек+машина)
Наличие плана тестирования
Наличие тест кейсов / тестов
Наличие отчета, подтверждающего выполнение задач и достижение целей, по тестированию объекта

3. Требования к количеству открытых багов

4. Серьезность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.

5. Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.

Билет №2

1. Дайте определение «Тестирование»

Тестирование программного обеспечения (SoftwareTesting) - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to SoftwareEngineeringBody of Knowledge, SWEBOK, 2004] В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ (TestManagement), проектированию тестов (TestDesign), выполнению тестирования (TestExecution) и анализу полученных результатов (TestAnalysis).

2. Опешите, процесс тестирования от начала до его окончания

3. Градация приоритете дефекта

4. P1Высокий(High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.

5. P2Средний(Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

6. P3Низкий(Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

7. Порядок исправления ошибок по их приоритетам:

8. High ->Medium ->Low

Билет №3

1. Дайте определения «Верификации» и «Валидации»

2. Верификация (Verification) - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

3. Валидация (Validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].

3. Перечислите необходимые условия для проведения

Тестирования

Необходимые условия:

Наличие объекта тестирования, доступного для проведения испытаний
Наличие исполнителя(ей) (в зависимости от вида проводимых испытаний им может быть как человек, так и машина или комбинация человек+машина)

3. Требования к обязательным полям баг репорта

Короткое описание

Название говорит само за себя. В одном предложение вам надо уместить смысл всего баг репорта, а именно: коротко и ясно, используя правильную терминологию сказать что и где не работает. Например:

Приложение зависает, при попытке сохранения текстового файла размером больше 50Мб.
Данные на форме "Профайл" не сохраняются после нажатия кнопки "Сохранить".

В дополнение предлагаем вам изучить Принцип "Где? Что? Когда?", описанный на страницах блога "QA Nest":

"В чем этот принцип состоит?
Составьте предложение, в котором факты дефекта изложены в следующей последовательности:

Где?: В каком месте интерфейса пользователя или архитектуры программного продукта находится проблема. Причем, начинайте предложение с существительного, а не предлога.
Что?: Что происходит или не происходит согласно спецификации или вашему представлению о нормальной работе программного продукта. При этом указывайте на наличие или отсутствие объекта проблемы, а не на его содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты указываются в описании.
Когда?: В какой момент работы программного продукта, по наступлению какого события или при каких условиях проблема проявляется.

Почему последовательность должна быть именно такой?
В таком виде незнакомые дефекты удобнее сортировать по summary как показывает практика (ведь, скорее всего, именно среди дефектов других инженеров будет производиться поиск дубликатов). Если вы другого мнения - придумайте свою последовательность, но она должна стать единой для всех без исключения членов проекта, иначе вы не добьетесь необходимого результата."

Серьезность

В двух словах можно отметить, что если проблема найдена в ключевой функциональности приложения и после ее возникновения приложение становится полностью недоступно, и дальнейшая работа с ним невозможна, то она блокирующая. Обычно все блокирующие проблемы находятся во время первичной проверки новой версии продукта (BuildVerificationTest, SmokeTest), т.к. их наличие не позволяет полноценно проводить тестирование. Если же тестирование может быть продолжено, то серьезность данного дефекта будет критическая. На счет значительных, незначительных и тривиальных ошибок вопрос достаточно прозрачный и на наш взгляд не требует лишних объяснений.

Шаги к воспроизведению / Результат / Ожидаемый результат

Очень важно четко описать все шаги, с упоминаем всех вводимых данных (имени пользователя, данных для заполнения формы) и промежуточных результатов.

Например:

Шаги к воспроизведению
1. Войдите в системы: Пользователь Тестер1, пароль xxxXXX
--> Вход в систему осуществлен
2. Кликните линкПрофайл
--> Страница Профайл открылась
3. Введите Новое имя пользователя: Тестер2
4. Нажмите кнопку Сохранить
Результат
На экране появилась ошибка. Новое имя пользователя не было сохранено
Ожидаемый результат
Страница профайл перегрузилась. Новое значение имени пользователя сохранено.

Билет №4

1. Дайте определение «Тест дизайн» и «Тестслучай»

2. Тест дизайн (TestDesign) - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

3. Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

3. Перечислите достаточные условия для проведения тестирования

Достаточные условия:

Наличие объекта тестирования, доступного для проведения испытаний
Наличие исполнителя(ей) (в зависимости от вида деятельности на разных фазах им может быть как человек, так и машина или комбинация человек+машина)
Наличие плана тестирования
Наличие тест кейсов / тестов
Наличие отчета, подтверждающего выполнение задач и достижение целей, по тестированию объекта

4. Шаги к воспроизведению, результат, ожидаемый результат

Билет №5

1. Дайте определение «Плановое тестирование» и «Тест покрытие»

2. Преимущества и недостатки функционального тестирования

Преимущества функционального тестирования:

имитирует фактическое использование системы;

Недостатки функционального тестирования:

возможность упущения логических ошибок в программном обеспечении;
вероятность избыточного тестирования.

3. Основные ошибки при написании багов репорта

4. Недостаточность предоставленных данных
Не всегда одна и таже проблема проявляется при всех вводимых значениях и под любым вошедшим в систему пользователем, поэтому настоятельно рекомендуется вносить все необходимые данные в баг репорт

5. Определение серьезности
Очень часто происходит либо завышение, либо занижение серьезности дефекта, что может привести к неправильной очередности при решении проблемы.

6. Язык описания
Часто при описании проблемы используются неправильная терминология или сложные речевые обороты, которые могут ввести в заблуждение человека, ответственного за решение проблемы.

7. Отсутствие ожидаемого результата
В случаях, если вы не указали, что же должно быть требуемым поведением системы, вы тратите время разработчика, на поиск данной информации, тем самым замедляете исправления дефекта. Вы должны указать пункт в требованиях, написанный тест кейс или же ваше личное мнение, если эта ситуация не была документирована.

Билет №6

1. Назовите виды тестирования

Функциональное тестированиеТестированиебезопасностиТестированиевзаимодействияНагрузочноетестированиеДымовоетестированиеТестированиесборкиСанитарноетестированиеРегрессионноетестированиеТестированиеустановкиТестирование удобства использованияТестирование на отказ и восстановлениеКонфигурационное тестирование

2. Назовите и поясните принципы безопасности программного тестирования

Конфиденциальность

Конфиденциальность - это сокрытие определенных ресурсов или информации. Под конфиденциальностью можно понимать ограничение доступа к ресурсу некоторой категории пользователей, или другими словами, при каких условиях пользователь авторизован получить доступ к данному ресурсу.

Целостность

Существует два основных критерия при определении понятия целостности:

Доверие. Ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей.
Повреждение и восстановление. В случае когда данные повреждаются или неправильно меняются авторизованным или не авторизованным пользователем, вы должны определить на сколько важной является процедура восстановления данных.

Доступность

Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс тем выше уровень доступности должен быть.

3. Таблица заполнения полей бага репорта

Заполнение полей баг репорта

В описанной ниже таблице представлены основные поля баг репорта и роль работника, ответственного за заполнение данного поля. Красным цветом выделены обязательные для заполнения поля:

Поле	Ответственный за заполнение поля
Короткое описание (Summary)	Автор баг репорта (обычно это Тестировщик)
Проект (Project)	Автор баг репорта (обычно это Тестировщик)
Компонент приложения (Component)	Автор баг репорта (обычно это Тестировщик)
Номер версии (Version)	Автор баг репорта (обычно это Тестировщик)
Серьезность (Severity)	Автор баг репорта (обычно это Тестировщик), однако данный атрибут может быть изменен вышестоящим менеджером
Приоритет (Priority)	Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт
Статус (Status)	Автор баг репорта (обычно это Тестировщик), но многие системы баг трекинга выставляют статус по умолчанию
Автор (Author)	Устанавливается по умолчанию, если нет, то указывается имя автора баг репорта
Назначен на (Assigned To)	Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт
ОС / Сервис Пак и т.д. / Браузера + версия / ...	Автор баг репорта (обычно это Тестировщик)
Шаги воспроизведения (Steps to Reproduce)	Автор баг репорта (обычно это Тестировщик)
Фактический Результат (Result)	Автор баг репорта (обычно это Тестировщик)
Ожидаемый результат (ExpectedResult)	Автор баг репорта (обычно это Тестировщик)
Прикрепленный файл (Attachment)	Автор баг репорта (обычно это Тестировщик), а также любой член командной группы, считающий, что прикрепленные данные помогут в исправлении бага

Билет №7

1. Функциональное тестирование это

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

2. Назовите и поясните виды уязвимости программного тестирования

XSS (Cross-SiteScripting) - это вид уязвимости программного обеспечения (Web приложений), при которой, на генерированной сервером странице, выполняются вредоносные скрипты, с целью атаки клиента.
XSRF / CSRF (RequestForgery) - это вид уязвимости, позволяющий использовать недостатки HTTP протокола, при этом злоумышленники работают по следующей схеме: ссылка на вредоносный сайт установливается на странице, пользующейся доверием у пользователя, при переходе по вредоносной ссылке выполняется скрипт, сохраняющий личные данные пользователя (пароли, платежные данные и т.д.), либо отправляющий СПАМ сообщения от лица пользователя, либо изменяет доступ к учетной записи пользователя, для получения полного контроля над ней.
Code injections (SQL, PHP, ASP и т.д.) - это вид уязвимости, при котором становится возможно осуществить запуск исполняемого кода с целью получения доступа к системным ресурсам, несанкционированного доступа к данным либо выведения системы из строя.
Server-SideIncludes (SSI) Injection - это вид уязвимости, использующий вставку серверных команд в HTML код или запуск их напрямую с сервера.
AuthorizationBypass - это вид уязвимости, при котором возможно получить несанкционированный доступ к учетной записи или документам другого пользователя

3. Жизненный цикл бага

Билет №8

1. Тестирование безопасности это

Тестирование безопасности - это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.

2. Основные виды производительности

нагрузочноетестирование (Performance and Load Testing)
стрессовое тестирование (StressTesting)
тестирование стабильности или надежности (Stability / ReliabilityTesting)
объемное тестирование (VolumeTesting)

4. Тестовое покрытие, покрытие кода, различия

Тестовое Покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.

Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения.

Различия:
Метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту, в то время как анализ покрытия кода - на полноте проверки тестами, разработанной части продукта (исходного кода), а анализ потока управления - на прохождении путей в графе или модели выполнения тестируемых функций (ControlFlowGraph).

Билет №9

1. Тестирование взаимодействия это

Тестирование взаимодействия (InteroperabilityTesting) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibilitytesting) и интеграционное тестирование (integrationtesting).

2. Отличия санитарного тестирования от дымового

· В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование - это одно и тоже. Мы же полагаем, что эти виды тестирования имеют "вектора движения", направления в разные стороны. В отличии от дымового (Smoketesting), санитарное тестирование (Sanitytesting) направлено вглубь проверяемой функции, в то время как дымовое направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.

2. Уровни тестового покрытия

Уровень	Название	Краткое описание
Уровень 0	--	“Тестируй все что протестируешь, пользователи протестируют остальное” На английском языке это звучит намного элегантнее: “Testwhateveryoutest, userswilltesttherest”
Уровень 1	Покрытие операторов	Каждый оператор должен быть выполнен как минимум один раз.
Уровень 2	Покрытие альтернатив [2] / Покрытие ветвей	Каждый узел с ветвлением (альтернатива) выполнен как минимум один раз.
Уровень 3	Покрытие условий	Каждое условие, имеющее TRUE и FALSE на выходе, выполнено как минимум один раз.
Уровень 4	Покрытие условий альтернатив	Тестовые случаи создаются для каждого условия и альтернативы
Уровень 5	Покрытие множественных условий	Достигается покрытие альтернатив, условий и условий альтернатив (Уровни 2, 3 и 4)
Уровень 6	“Покрытие бесконечного числа путей”	Если, в случае зацикливания, количество путей становится бесконечным, допускается существенное их сокращение, ограничивая количество циклов выполнения, для уменьшения числа тестовых случаев.
Уровень 7	Покрытие путей	Все пути должны быть проверены

Билет №10

1. Нефункциональные виды тестирования

Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. Далее перечислены основные виды нефункциональных тестов:

Все виды тестирования производительности:

нагрузочноетестирование (Performance and Load Testing)
стрессовое тестирование (StressTesting)
тестирование стабильности или надежности (Stability / ReliabilityTesting)
объемное тестирование (VolumeTesting)

Тестирование установки (Installationtesting)
Тестирование удобства пользования (UsabilityTesting)
Тестирование на отказ и восстановление (FailoverandRecoveryTesting)
Конфигурационное тестирование (ConfigurationTesting)

2. Основные типы регрессивного тестирования

Регрессия багов (Bugregression) - попытка доказать, что исправленная ошибка на самом деле не исправлена
Регрессия старых багов (Oldbugsregression) - попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.
Регрессия побочного эффекта (Sideeffectregression) - попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения

3. Техники тест дизайна

ЭквивалентноеРазделение (Equivalence Partitioning - EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.
Анализ Граничных Значений (BoundaryValueAnalysis - BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона" а затем, нажать кнопку "Добавить" - эта "Причина". После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие".
Предугадывание ошибки (ErrorGuessing - EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.
Исчерпывающее тестирование (ExhaustiveTesting - ET) - это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Билет №11

1. Тестирование установки это

Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

2. Особенности тестирования инсталляторов

риск потери пользовательских данных
риск вывода операционной системы из строя
риск неработоспособности приложения
риск не корректной работы приложения

3. План разработки тест кейсов

Билет №12

1. Тестирование удобства пользования это

2. Что тестировать в инсталляционныхпрограммах?

3. Пример функциональности формы приема заявок элемент combobox

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Тестирование на отказ от восстановления это

2. Как тестить инсталляции

3. Пример функциональности формы приема заявок элемента editbox

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Вопрос из пройденной учебной программы предмета

2. Кросс-платформенное тестирование инсталляторов

3. Пример функциональности формы приема заявки элемента textarea

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Конфигурационное тестирование это

2. Уровни проведения тестирования

3. Пример функциональности формы приема заявки элемента button

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Дымовое тестирование это

2. Разница между компонентным и модульным тестированием

3. План работы над дизайном

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Регрессивное тестирование это

2. Уровни интеграционного тестирования

3. Дайте расшифровку элементам формулы Tcov = (Lcov/Ltotal) * 100%

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Тестирование сборки

2. Подходы к интеграционному тестированию

3. Дайте расшифровку элементам Tcov = (Ltc/Lcode) * 100%

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Назовите уровни тестирования

2. Подходы системного тестирования

3. Определение набора тестовых данныхпри разработке тест кейсов

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Модульное тестирование это

2. Рекомендации по написанию тест плана

3. Подход к интеграционному тестированиюСверху вниз (TopDownIntegration)

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Интеграционное тестирование это

2. Виды тест планов

3. Подход к интеграционному тестированиюБольшойвзрыв ("Big Bang" Integration)

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Системное тестирование это

2. Рецензия, утверждение, вывод

3. Подход к интеграционному тестированиюСнизу вверх (BottomUpIntegration)

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Приемочное тестирование это

2. Тестовый случай и его виды

3. Цели нагрузочного тестирования

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Тестовые артефакты

2. Структура баг репорта

3. Разработка модели нагрузкинагрузочного тестирования

Преподаватель: ________________

Бурабай ауданы, Щучинск қаласы, Жоғарыколледж

Высший колледж, город Щучинск, Бурабайский район

Экзаменационный билет № _____

по дисциплине «________________________________________»

1. Наиболее распространенные тестовые артефакты

2. Градация серьезности дефекта

3. Baseline нагрузочная точка

Преподаватель: ________________

Дата добавления: 2018-04-04; просмотров: 1716; Мы поможем в написании вашей работы!

Поделиться с друзьями:

Мы поможем в написании ваших работ!