QA вопросы : Вопрос 1 : 26

Понятие матрица соответствия требований (Requirements Traceability Matrix).

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Матрица соответствия требований - это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк - тестовые сценарии. На пересечении - отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.

Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

Понятие матрица соответствия требований (Requirements Traceability Matrix).

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Матрица соответствия требований - это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк - тестовые сценарии. На пересечении - отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.

Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

Что такое приемочное (acceptance) тестирование?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

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

Синонимы: release acceptance, final testing, validation testing

Что такое приемочное (acceptance) тестирование?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

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

Синонимы: release acceptance, final testing, validation testing

Для чего применяют граничное (boundary) тестирование?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

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

Для чего применяют граничное (boundary) тестирование?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

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

Какими 8 критериями должны обладать требования (набор требований)?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Требования должны быть:

1) завершенными

2) непротиворечивыми

3) корректными

4) недвусмысленными

5) проверяемыми

6) модифицируемыми

7) прослеживаемыми

8) проранжированными

P.S. Последние 3 критерия - для набора требований.

Какими 8 критериями должны обладать требования (набор требований)?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Требования должны быть:

1) завершенными

2) непротиворечивыми

3) корректными

4) недвусмысленными

5) проверяемыми

6) модифицируемыми

7) прослеживаемыми

8) проранжированными

P.S. Последние 3 критерия - для набора требований.

Какой функционал на веб-странице подлежит полной автоматизации?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Полной автоматизации подлежит проверка ссылок (перехода по ссылкам), работоспособность всех кликабельных элементов.

Какой функционал на веб-странице подлежит полной автоматизации?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Полной автоматизации подлежит проверка ссылок (перехода по ссылкам), работоспособность всех кликабельных элементов.

Опишите различия между верификацией (verification) и валидацией (validation).

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Верификация проверяет соответствие одних создаваемых в ходе разработки и сопровождения ПО артефактов другим, ранее созданным или используемым в качестве исходных данных, а также соответствие этих артефактов и процессов их разработки правилам и стандартам. Другими словами, при верификации проверяем все, что написано в ТЗ. Система работает так, как написано в ТЗ? — Успех. Система работает не так? — Провал.

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

Опишите различия между верификацией (verification) и валидацией (validation).

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Верификация проверяет соответствие одних создаваемых в ходе разработки и сопровождения ПО артефактов другим, ранее созданным или используемым в качестве исходных данных, а также соответствие этих артефактов и процессов их разработки правилам и стандартам. Другими словами, при верификации проверяем все, что написано в ТЗ. Система работает так, как написано в ТЗ? — Успех. Система работает не так? — Провал.

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

Какие можно выделить основные задачи АТ?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

1) Решение "рутинных" задач
2) Ускорение тестирования
3) Освобождение человеческих ресурсов
4) Увеличение тестового покрытия
5) Улучшение кода
6) Выполнение тестов, неподсильных человеку

Какие можно выделить основные задачи АТ?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

1) Решение "рутинных" задач
2) Ускорение тестирования
3) Освобождение человеческих ресурсов
4) Увеличение тестового покрытия
5) Улучшение кода
6) Выполнение тестов, неподсильных человеку

Опишите какие бывают требования к продукту?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Опишите какие бывают требования к продукту?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Дайте определение термина CMM.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

CMM (Capability Maturity Model) переводится как "модель зрелости возможностей". Подразумевает модель зрелости процессов в компании. Изначально CMM была разработана для измерения эффективности работы подрядчиков, выполняющих заказы правительства США на разработку и поставку ПО. Позже модель была обобщена для любых компаний-разработчиков программного обеспечения. Различают следующие уровни CMM:

Уровень 1 - начальный (initial). Хаотический процесс, который характеризуется, как правило, полным отсутствием документации и быстрыми изменениями продукта. Считается, что результат такого процесса непредсказуем;

Уровень 2 - воспроизводимый (repeatable). Характеристика процесса, который частично воспроизводим и дает предсказуемый результат. Процессы, как правило не сильно формализованы, но достаточны для тех продуктов, которые разрабатывает компания;

Уровень 3 - определенный (defined). Процесс характеризуется формализацией и планом улучшения процесса с течением времени;

Уровень 4 - управляемый (managed). Процесс формализован и контролируется с помощью набора метрик, позволяющих измерить эффективность процесса. На основании статистики по этим метрикам можно прогнозировать результаты будущих разработок;

Уровень 5 - улучшеный (optimized). Процесс постоянно улучшается путем применения технических и административных инноваций;

Дайте определение термина CMM.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

CMM (Capability Maturity Model) переводится как "модель зрелости возможностей". Подразумевает модель зрелости процессов в компании. Изначально CMM была разработана для измерения эффективности работы подрядчиков, выполняющих заказы правительства США на разработку и поставку ПО. Позже модель была обобщена для любых компаний-разработчиков программного обеспечения. Различают следующие уровни CMM:

Уровень 1 - начальный (initial). Хаотический процесс, который характеризуется, как правило, полным отсутствием документации и быстрыми изменениями продукта. Считается, что результат такого процесса непредсказуем;

Уровень 2 - воспроизводимый (repeatable). Характеристика процесса, который частично воспроизводим и дает предсказуемый результат. Процессы, как правило не сильно формализованы, но достаточны для тех продуктов, которые разрабатывает компания;

Уровень 3 - определенный (defined). Процесс характеризуется формализацией и планом улучшения процесса с течением времени;

Уровень 4 - управляемый (managed). Процесс формализован и контролируется с помощью набора метрик, позволяющих измерить эффективность процесса. На основании статистики по этим метрикам можно прогнозировать результаты будущих разработок;

Уровень 5 - улучшеный (optimized). Процесс постоянно улучшается путем применения технических и административных инноваций;

Тестовый случай: определение, виды тестовых случаев.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Под тест кейсом понимается структура вида:
Действие -> Ожидаемый результат -> Результат прохождения (Action -> Expected Result -> Test Result ).
Тест-кейс может писаться как самим тестировщиком, так и руководителями проекта, например.
Для более успешной работы в компании применяется единый стиль написания тест-кейсов, утвержденный на уровне руководства.
Тест-кейсы разделяются в заависимости от ожидаемого результата на позитивные и негативные:

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

Тестовый случай: определение, виды тестовых случаев.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Под тест кейсом понимается структура вида:
Действие -> Ожидаемый результат -> Результат прохождения (Action -> Expected Result -> Test Result ).
Тест-кейс может писаться как самим тестировщиком, так и руководителями проекта, например.
Для более успешной работы в компании применяется единый стиль написания тест-кейсов, утвержденный на уровне руководства.
Тест-кейсы разделяются в заависимости от ожидаемого результата на позитивные и негативные:

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

В чем отличие Бага от Дефекта?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Баг - это несоответствие поведения тестируемой области ожидаемому результату, которое проявляется в каждой версии продукта начиная с первой релизной версии до тех пор, пока не будет устранена.

Дефект - это ошибка приложения/функции которая возникла в следствие ПЕРЕРАБОТКИ И ДОПОЛНЕНИЯ ПРОГРАММНОГО КОДА в одной из последующих после первой релизной версии.

В чем отличие Бага от Дефекта?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Баг - это несоответствие поведения тестируемой области ожидаемому результату, которое проявляется в каждой версии продукта начиная с первой релизной версии до тех пор, пока не будет устранена.

Дефект - это ошибка приложения/функции которая возникла в следствие ПЕРЕРАБОТКИ И ДОПОЛНЕНИЯ ПРОГРАММНОГО КОДА в одной из последующих после первой релизной версии.

Опишите структуру тест-кейса, детализацию описания.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Каждый тест кейс обычно состоит из трёх частей:
PreConditions - Список действий, которые приводят систему к состоянию, пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description - Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям PostConditions - Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)

Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.

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

Пример тест-кейса:
-1-
Название: Проверка отображения главного меню программы
Действие: Запустить программу -> ввести учетные данные -> нажать кнопку "Войти"
Проверка: Проверить, что меню программы отображается согласно спецификации (стр. 23)

-2-
Действие: запустить программу -> ввести имя пользователя и пароль 
Ожидаемый результат:
- Окно "Вход в систему" открыто
- Название окна - Вход в систему
- Название программы отображается в правом верхнем углу
- На форме 2 поля - Имя и Пароль
- Кнопка Вход доступна
Тестовый результат: .......

В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным.

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

Опишите структуру тест-кейса, детализацию описания.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Каждый тест кейс обычно состоит из трёх частей:
PreConditions - Список действий, которые приводят систему к состоянию, пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description - Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям PostConditions - Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)

Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.

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

Пример тест-кейса:
-1-
Название: Проверка отображения главного меню программы
Действие: Запустить программу -> ввести учетные данные -> нажать кнопку "Войти"
Проверка: Проверить, что меню программы отображается согласно спецификации (стр. 23)

-2-
Действие: запустить программу -> ввести имя пользователя и пароль 
Ожидаемый результат:
- Окно "Вход в систему" открыто
- Название окна - Вход в систему
- Название программы отображается в правом верхнем углу
- На форме 2 поля - Имя и Пароль
- Кнопка Вход доступна
Тестовый результат: .......

В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным.

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

Дайте определение термина программный дефект (bug).

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Программным дефектом называется ошибка в программном продукте, вследствие которой продукт ведет себя непредвиденно (неверно). Большинство дефектов возникают из-за допущенной ошибки в программном коде или логической ошибки, допущенной во время проектирования. Гораздо меньшее количество - вследствие ошибок работы инструментальных средств (компилятора, генератора кода).

Дефекты делят на следующие категории

Арифметические ошибки (деление на 0, переполнение)

Логические ошибки (бесконечные циклы, бесконечная рекурсия)

Ошибки работы с ресурсами (null pointer, access violation, переполнение буфера)

Ошибки синхронизации многопоточности (дедлок, race condition)

Поскольку количество дефектов в большинстве программных продуктом достаточно велико, для учета дефектов применяют специальный класс систем - систему учета запросов (Issue Tracking System). Данная система кроме учета дефектов ведет еще учет требований продукта, релизов и т.д.

Дайте определение термина программный дефект (bug).

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Программным дефектом называется ошибка в программном продукте, вследствие которой продукт ведет себя непредвиденно (неверно). Большинство дефектов возникают из-за допущенной ошибки в программном коде или логической ошибки, допущенной во время проектирования. Гораздо меньшее количество - вследствие ошибок работы инструментальных средств (компилятора, генератора кода).

Дефекты делят на следующие категории

Арифметические ошибки (деление на 0, переполнение)

Логические ошибки (бесконечные циклы, бесконечная рекурсия)

Ошибки работы с ресурсами (null pointer, access violation, переполнение буфера)

Ошибки синхронизации многопоточности (дедлок, race condition)

Поскольку количество дефектов в большинстве программных продуктом достаточно велико, для учета дефектов применяют специальный класс систем - систему учета запросов (Issue Tracking System). Данная система кроме учета дефектов ведет еще учет требований продукта, релизов и т.д.

Назовите основные атрибуты дефекта.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

К основным атрибутам дефекта относятся: 
1. Имя дефекта/ Name (которое должно содержать краткое описание, ключевые слова, по которым можно понять суть дефекта и легко его найти).
2. Описание дефекта/ Description (развернутое описание дефекта).
3. Шаги для воспроизведения/ Steps to reproduce (пошаговое описание для воспроизведения дефекта)
4. Приоритет/ Priority (показывает насколько дефект важен и в какую очередь его стоить фиксить).
5. Степень серьезности/Severity (показывает насколько критичны последствия дефекта для приложения).
6. Статус/Status (показывает на какой стадии в данный момент находится дефект (новый, в процессе починки,проверен и т.д.))
7. Компонент/ Components (к какой части относится дефект (фронт энд, бэк энд, какая-то часть приложения и т.д.))
8. Окружение/ Environment (используемые браузер, операционная система и т.д.)
9. Билд/ Build (в какой версии был найден дефект)
10. Кто занес дефект
11. На кого занесен дефект (может быть продукт менеджер, разработчик, все зависит от проекта).
12. Дополнения /Attachments (прикрепленные скрин шоты, файлы, куски кода...)

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

Назовите основные атрибуты дефекта.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

К основным атрибутам дефекта относятся: 
1. Имя дефекта/ Name (которое должно содержать краткое описание, ключевые слова, по которым можно понять суть дефекта и легко его найти).
2. Описание дефекта/ Description (развернутое описание дефекта).
3. Шаги для воспроизведения/ Steps to reproduce (пошаговое описание для воспроизведения дефекта)
4. Приоритет/ Priority (показывает насколько дефект важен и в какую очередь его стоить фиксить).
5. Степень серьезности/Severity (показывает насколько критичны последствия дефекта для приложения).
6. Статус/Status (показывает на какой стадии в данный момент находится дефект (новый, в процессе починки,проверен и т.д.))
7. Компонент/ Components (к какой части относится дефект (фронт энд, бэк энд, какая-то часть приложения и т.д.))
8. Окружение/ Environment (используемые браузер, операционная система и т.д.)
9. Билд/ Build (в какой версии был найден дефект)
10. Кто занес дефект
11. На кого занесен дефект (может быть продукт менеджер, разработчик, все зависит от проекта).
12. Дополнения /Attachments (прикрепленные скрин шоты, файлы, куски кода...)

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

Что такое тестирование "черного ящика" (black box testing)?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Существует еще и тестирование "белого ящика". В этом случае тестировщик должен обладать знаниями о внутренних механизмах работы продукта и иметь доступ к исходному коду приложения. Юнит-тестирование, проводимое, как правило, разработчиками продукта, является примером white box тестирования.

Что такое тестирование "черного ящика" (black box testing)?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Существует еще и тестирование "белого ящика". В этом случае тестировщик должен обладать знаниями о внутренних механизмах работы продукта и иметь доступ к исходному коду приложения. Юнит-тестирование, проводимое, как правило, разработчиками продукта, является примером white box тестирования.

Какие бывают методы планирования без документации?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Ad-hoc Testing, или тестирование без требований и спецификаций (интеллектуальное тестирование):
1. Импровизированное тестирование без предварительной подготовки
2. Преимущество: важные дефекты находятся на ранних стадиях
3. Метод для обзора функциональности продукта

Exploratory Testing, или исследовательское тестирование:
1. Переплетение дизайна тестов и выполнения
2. Тестировщик узнает продукт в процессе его тестирования
3. Особое внимание уделяется творчеству и спонтанности

Какие бывают методы планирования без документации?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Ad-hoc Testing, или тестирование без требований и спецификаций (интеллектуальное тестирование):
1. Импровизированное тестирование без предварительной подготовки
2. Преимущество: важные дефекты находятся на ранних стадиях
3. Метод для обзора функциональности продукта

Exploratory Testing, или исследовательское тестирование:
1. Переплетение дизайна тестов и выполнения
2. Тестировщик узнает продукт в процессе его тестирования
3. Особое внимание уделяется творчеству и спонтанности

Перечислите основные виды тестирования:

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Процесс тестирования можно классифицировать по:

а) возможности доступа к исходному коду:

тестирование "белого ящика"

тестирование "черного ящика"

б) по тому, нужно ли выполнять исходный код:

динамическое тестирование

статическое тестирование (анализ исходного кода)

в) по охвату тестируемого приложения

модульное тестирование (unit-тесты)

интеграционное тестирование

системное тестирование

альфа и бета тестирование

приемо-сдаточные испытания

пилотное тестирование

г) по тестируемым областям работы приложения:

"дымовое" тестирование (может содержать тесты любого из следующих видов)

функциональное тестирование

нагрузочное тестирование

тестирование безопасности

тестирование удобства использования (usability тестирование)

Перечислите основные виды тестирования:

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Процесс тестирования можно классифицировать по:

а) возможности доступа к исходному коду:

тестирование "белого ящика"

тестирование "черного ящика"

б) по тому, нужно ли выполнять исходный код:

динамическое тестирование

статическое тестирование (анализ исходного кода)

в) по охвату тестируемого приложения

модульное тестирование (unit-тесты)

интеграционное тестирование

системное тестирование

альфа и бета тестирование

приемо-сдаточные испытания

пилотное тестирование

г) по тестируемым областям работы приложения:

"дымовое" тестирование (может содержать тесты любого из следующих видов)

функциональное тестирование

нагрузочное тестирование

тестирование безопасности

тестирование удобства использования (usability тестирование)

Что такое тест-план.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Тест-план - главный документ, которым руководствуется QA инженер. В идеале тест-план должен описывать

объект тестирования (тестируемый продукт)

цели тестирования и скоупы работ

стратегию тестирования (как будет производится тестирование, какие инструменты будут применяться)

приоритеты проекта и роль тестирования в процессе

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

тестовую среду

собственно тестовые сценарии (test cases)

Составление и формальное следование подробному тест-плану в реальности часто бывает нецелесообразным. Часто причиной отказа от жесткой формализации процесса является недостаток времени или ресурсов. В подобных случаях обычно тест-план ограничивается минимальным описанием тестовой среды и набором тест-кейсов, описанных высокоуровнево (без формальной детализации).

Что такое тест-план.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Тест-план - главный документ, которым руководствуется QA инженер. В идеале тест-план должен описывать

объект тестирования (тестируемый продукт)

цели тестирования и скоупы работ

стратегию тестирования (как будет производится тестирование, какие инструменты будут применяться)

приоритеты проекта и роль тестирования в процессе

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

тестовую среду

собственно тестовые сценарии (test cases)

Составление и формальное следование подробному тест-плану в реальности часто бывает нецелесообразным. Часто причиной отказа от жесткой формализации процесса является недостаток времени или ресурсов. В подобных случаях обычно тест-план ограничивается минимальным описанием тестовой среды и набором тест-кейсов, описанных высокоуровнево (без формальной детализации).

Опишите основные различия между Quality Assurance и Quality Control.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Quality Assurance включает в себя Quality Control наряду с другими процессами по улучшению качества работы компании.

Quality Assurance (обеспечение качества) - это превентивный процесс, задачей которого является обеспечение качества продукта в будущем. В этом смысле Quality Assurance более ориентирован на процесс.


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

Говоря другими словами, Quality Assurance гарантирует, что процесс поставлен правильно и дает предсказуемый результат, в то время как Quality Control гарантирует, что продукт удовлетворяет указанному набору требований.

Опишите основные различия между Quality Assurance и Quality Control.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Quality Assurance включает в себя Quality Control наряду с другими процессами по улучшению качества работы компании.

Quality Assurance (обеспечение качества) - это превентивный процесс, задачей которого является обеспечение качества продукта в будущем. В этом смысле Quality Assurance более ориентирован на процесс.


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

Говоря другими словами, Quality Assurance гарантирует, что процесс поставлен правильно и дает предсказуемый результат, в то время как Quality Control гарантирует, что продукт удовлетворяет указанному набору требований.

Дайте определение классов эквивалентности в тестировании.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Класс эквивалентности - множество тестов со сходными параметрами, протестировав один из них, можно поставить галочку, что протестировал и все остальные (остальные параметры множества будут иметь тот же результат). 
Эквивалентные тесты — это тесты, которые приводят к одному и тому же результату.
То есть, если мы выполним два любых теста из одного класса эквивалентности — то получим один и тот же результат.

Дайте определение классов эквивалентности в тестировании.

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Класс эквивалентности - множество тестов со сходными параметрами, протестировав один из них, можно поставить галочку, что протестировал и все остальные (остальные параметры множества будут иметь тот же результат). 
Эквивалентные тесты — это тесты, которые приводят к одному и тому же результату.
То есть, если мы выполним два любых теста из одного класса эквивалентности — то получим один и тот же результат.

Назовите цели нагрузочного тестирования?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Основными целями нагрузочного тестирования являются:

Оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию;

Оценка производительности и работоспособности приложения на этапе выпуска новых релизов, патч-сетов;

Оптимизация производительности приложения, включая настройки серверов и оптимизацию кода;

Подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера.

Назовите цели нагрузочного тестирования?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Основными целями нагрузочного тестирования являются:

Оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию;

Оценка производительности и работоспособности приложения на этапе выпуска новых релизов, патч-сетов;

Оптимизация производительности приложения, включая настройки серверов и оптимизацию кода;

Подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера.

Какая основная задача стресс-тестирования?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Основной задачей стресс-тестирования является проверка стабильности работы продукта при граничных нагрузках. Стресс-тестирование включает тесты, создающие нагрузку значительно выше операционной (повседневной) нагрузки на продукт.

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

С помощью стресс-тестов потенциально можно обнаружить:

узкие места (bottlenecks) приложения (интенсивно используемые участки кода, требующие оптимизации)

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

ошибки синхронизации кода (например, отсутствие синхронизации и как следствие некорректная работа или разрушение данных)

ошибки балансировки нагрузки (например, неправильная конфигурация балансировщика)

Какая основная задача стресс-тестирования?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Основной задачей стресс-тестирования является проверка стабильности работы продукта при граничных нагрузках. Стресс-тестирование включает тесты, создающие нагрузку значительно выше операционной (повседневной) нагрузки на продукт.

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

С помощью стресс-тестов потенциально можно обнаружить:

узкие места (bottlenecks) приложения (интенсивно используемые участки кода, требующие оптимизации)

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

ошибки синхронизации кода (например, отсутствие синхронизации и как следствие некорректная работа или разрушение данных)

ошибки балансировки нагрузки (например, неправильная конфигурация балансировщика)

Что такое тестирование совместимости (compatibility testing)?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Окружение может состоять из следующих элементов:

- аппаратное обеспечение;
- сетевые компоненты;
- периферические устройства (принтеры, сканеры и т.д.);
- операционные системы;
- системы управления базами данных (СУБД);
- браузеры (Chrome, Firefox, Opera и т.д.)
- антивирусные программы;
- файрволы.

Что такое тестирование совместимости (compatibility testing)?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Окружение может состоять из следующих элементов:

- аппаратное обеспечение;
- сетевые компоненты;
- периферические устройства (принтеры, сканеры и т.д.);
- операционные системы;
- системы управления базами данных (СУБД);
- браузеры (Chrome, Firefox, Opera и т.д.)
- антивирусные программы;
- файрволы.

Допустим, что у программы три входных значения, каждое из которых имеет определенный диапазон значений. Сколько тест-кейсов вам понадобится, чтобы протестировать все граничные значения?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Если эти диапазоны не известны, то умножаем 3 (кол-во входных значений) на 4 (значение на границах диапазона, в диапазоне, и в не диапазоне) = 12.

А если известны, то допустим эти значения: [0, 1]; [2, 3]; [0,3].
Определим число классов эквивалентности.


Первый: <0;
Второй: [0,1);
Третий: [1, 2);
Четвёртый: [2, 3];
Пятый: >3.


Определим кол-во границ: 4 

Итого тестов: 5+4 = 9

Допустим, что у программы три входных значения, каждое из которых имеет определенный диапазон значений. Сколько тест-кейсов вам понадобится, чтобы протестировать все граничные значения?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

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

Если эти диапазоны не известны, то умножаем 3 (кол-во входных значений) на 4 (значение на границах диапазона, в диапазоне, и в не диапазоне) = 12.

А если известны, то допустим эти значения: [0, 1]; [2, 3]; [0,3].
Определим число классов эквивалентности.


Первый: <0;
Второй: [0,1);
Третий: [1, 2);
Четвёртый: [2, 3];
Пятый: >3.


Определим кол-во границ: 4 

Итого тестов: 5+4 = 9

Что такое Fuzz Testing?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Fuzz-тестирование – своего рода стресс-тест для программного обеспечения, суть которого заключается в обработке программным обеспечением большого объёма информации, содержащей заведомо неверные параметры.
Еще Фаззинг – методика тестирвоания, при которой на вход программы подается невалидные, непредусмотренные или случайные данные.

Что можно фазить? 
- Файлы
- Драйверы
- Приложения
- Веб-приложения
- Протоколы
- АРІ

Как можно фазить?
1. Генерация: случайные дынные(dumb); входные данные, сформированные по моделям (smart)
2. Мутация: изменение существующих входных данных

Фаззинг файлов:
1. Выбираем входные данные
2. Фаззер искажает эти данные
3. Фаззер запускает приложение с передачей ему искаженных данных
4. Фаззер перебирает входные данные
5. В случае возникновения ошибки, записываем данные и анализируем результат

Фаззинг протоколов:
1. Выбираем фаззер (свой или сторонний)
2. Создаем модели данных
3. Описываем параметры модели в входном файле
4. Запускаем фаззер
5. В случае возникновения ошибки, записывае данные и анализируем результат

Какие баги можно найти при помощи фаззинга:
1. Утечка памяти
2. Переполнение буфера
3. Неверные коды ошибок
4. Ошибки обработки входных данных
5. Отказ в обслуживании

Фаззинг в процессе тестирования:
1. Часть процесса тестирования безопасности
2. Стоит попробовать с другими видами тестирования
3. Необходимо знание протоколов и форматов данных
4. Документирование

Что такое Fuzz Testing?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Fuzz-тестирование – своего рода стресс-тест для программного обеспечения, суть которого заключается в обработке программным обеспечением большого объёма информации, содержащей заведомо неверные параметры.
Еще Фаззинг – методика тестирвоания, при которой на вход программы подается невалидные, непредусмотренные или случайные данные.

Что можно фазить? 
- Файлы
- Драйверы
- Приложения
- Веб-приложения
- Протоколы
- АРІ

Как можно фазить?
1. Генерация: случайные дынные(dumb); входные данные, сформированные по моделям (smart)
2. Мутация: изменение существующих входных данных

Фаззинг файлов:
1. Выбираем входные данные
2. Фаззер искажает эти данные
3. Фаззер запускает приложение с передачей ему искаженных данных
4. Фаззер перебирает входные данные
5. В случае возникновения ошибки, записываем данные и анализируем результат

Фаззинг протоколов:
1. Выбираем фаззер (свой или сторонний)
2. Создаем модели данных
3. Описываем параметры модели в входном файле
4. Запускаем фаззер
5. В случае возникновения ошибки, записывае данные и анализируем результат

Какие баги можно найти при помощи фаззинга:
1. Утечка памяти
2. Переполнение буфера
3. Неверные коды ошибок
4. Ошибки обработки входных данных
5. Отказ в обслуживании

Фаззинг в процессе тестирования:
1. Часть процесса тестирования безопасности
2. Стоит попробовать с другими видами тестирования
3. Необходимо знание протоколов и форматов данных
4. Документирование

В чем разница между понятиями статическое и динамическое тестирование?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Статическое тестирование производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте.

С помощью code review на раннем этапе могут быть выявлены ошибки в коде продукта. Как правило code review производится самими разработчиками.


Примерами ошибок, которые потенциально можно выявить с помощью автоматического статического тестирования, могут быть:

утечки ресурсов (утечки памяти, неосвобождаемые файловые дескрипторы и т.д.)

возможность переполнения буфера (buffer overflows)

ситуации частичной (неполной) обработки ошибок

Как правило, результатом автоматического анализа кода является список рекомендаций для ручного review некоторых участков кода, потенциально содержащих ошибки.

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

модульное тестирование (unit testing)

интеграционное тестирование (integrated testing)

приемочное тестирование (acceptance testing)

В чем разница между понятиями статическое и динамическое тестирование?

Уважаемые учащиеся ниже Вы сможете увидеть ответ, перед тем, как ответить, пожалуйста, постарайтесь написать для себя ответ на черновике, и только потом сравните наш ответ с Вашим: 

Верно ли наше решение?

Ответ:

Статическое тестирование производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте.

С помощью code review на раннем этапе могут быть выявлены ошибки в коде продукта. Как правило code review производится самими разработчиками.


Примерами ошибок, которые потенциально можно выявить с помощью автоматического статического тестирования, могут быть:

утечки ресурсов (утечки памяти, неосвобождаемые файловые дескрипторы и т.д.)

возможность переполнения буфера (buffer overflows)

ситуации частичной (неполной) обработки ошибок

Как правило, результатом автоматического анализа кода является список рекомендаций для ручного review некоторых участков кода, потенциально содержащих ошибки.

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

модульное тестирование (unit testing)

интеграционное тестирование (integrated testing)

приемочное тестирование (acceptance testing)