Тестирование. Книга первая. Юнит-тестирование, виды тестирования

Начало: пост.

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

Рекомендации:

• Юнит-тесты должны планироваться в письменной форме ДО написания кода. На самом деле это, возможно, было бы полезнее делать и нам, или просто несколько корректировать сценарии использования.
• Требования к юнит-тестам должны быть формализованыв стандартах о юнит-тестировании

Кстати, перед началом тестирования нужно убедиться, что

• код заморожен (обычно релиз-инженеры посылают соответствующий е-мейл);

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

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

Цикл тестирования ПО

Цикл тестирования ПО состоит из трех этапов:

1. Изучение и анализ предмета тестирования. Тестирование интерфейсов, скорости работы, документации.

2. Планирование тестирования. Тест-документация с тест-кейсами.

3. Исполнение тестирования. Суть исполнения тестирования — это практическийпоиск багов в написанном коде с использованием тест-кейсов, созданных ранее. Сначала идет тестирование новых функциональностей (new featuretesting), а позднее – регрессивное тестирование (regression testing) или тестирование старой функциональности. Мы исполняем тест-кейсы, рассчитывая найти баги.Давайте еще

Есть ещё проверка работы функциональностей называется функциональным тестированием (functional testing). Им часто занимаются аналитики.

Для полноты картины приведу все виды тестирования:

1. По знанию внутренностей системы:

• черный ящик (black box testing);

• серый ящик (grey box testing);

•белый ящик (white box testing).

2. По объекту тестирования:

• функциональное тестирование (functional testing);

• тестирование интерфейса пользователя (UI testing);

• тестирование локализации (localization testing);

• тестирование скорости и надежности (load/stress/performancetesting);

•тестирование безопасности (security testing);

• тестирование опыта пользователя (usability testing);

• тестирование совместимости (compatibility testing).

3. По субъекту тестирования:

• альфа-тестировщик (alpha tester);

• бета-тестировщик (beta tester).

4. По времени проведения тестирования:

• до передачи пользователю — альфа-тестирование (alphatesting);

– тест приемки (smoke test, sanity test или confidence test);

– тестирование новых функциональностей (new featuretesting);

– тест сдачи (acceptance or certification test);

• после передачи пользователю — бета-тестирование (betatesting).

5. По критерию “позитивности” сценариев:

• позитивное тестирование (positive testing);

• негативное тестирование (negative testing).

6. По степени изолированности тестируемых компонентов:

• компонентное тестирование (component testing), тестирование одного компонента;

• интеграционное тестирование (integration testing), тестирование взаимодействия пары компонентов системы;

• системное (или энд-ту-энд) тестирование (system or end to-end testing), полное тестирование системы.

7. По степени автоматизированности тестирования:

• ручное тестирование (manual testing);

• автоматизированное тестирование (automated testing);

• смешанное/полуавтоматизированное тестирование (semiautomated testing).

8. По степени подготовки к тестированию:

• тестирование по документации (formal/documented testing);

• эд хок-тестирование (ad hoc testing).

Покрытие возможных сценариев — это одна из частей архиважнейшейконцепции, называемой тестировочное покрытие.

Тестирование с разными браузерами называется кросс-браузер-тестированием (cross-browser testing). Тестирование с разными ОС называется кросс-платформ-тестированием (cross-platform testing).

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

В отношении методов генерирования тестов:

• при использовании метода Черновик-чистовик: Черновик —это полет мысли и вдохновения, “мозговой штурм”, не ограниченный суетными приличиями бренного света. Чистовик —это подчищенный, причесанный и классифицированный Черновик;

• матричная раскладка может быть лишь простой классификацией элементов на табл. 1, а может и бесконечно углублятьсяв дебри комбинаций и комбинаций. Главное помнить, что матричная раскладка создается для тестирования, а не тестирование было придумано для матричной раскладки;

• блок-схемы — это дочери добродетели под именем “Наглядность”.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Правильный формат заведения бага.

Правильный формат заведенного бага в системе типа JIRA или Redmine и т.п.:

Если есть номер спека, то можно давать краткое описание в таком формате:

<номер спека> : <само краткое описание>, например:

7422: неверное значение баланса Switch после покупки.

Description:Полезная информация о баге: описание, комментарии, нюансы и т.д.

Steps to reproduce:Конкретные шаги для воспроизведения проблемы.

Bug: Фактический результат.

Expected: Ожидаемый результат.

Пример:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ещё очень полезно выписать типы объектов страницы и как они должна работать и включать их в описание.

В книге есть ещё продолжение и рекомендации по прохождению собеседования. Я же приведу фрагмент тест-кейса: