Тестирование играет жизненно важную роль в разработке качественного программного обеспечения. Тем не менее, во многих компаниях, занимающихся разработкой ПО, процессы тестирования недостаточно организованы, поэтому исполнители вынуждены идти трудным путем, пытаясь добиться желаемых результатов.
Тестирование программногообеспечения — процесс исследования, испытания программного продукта, имеющий две различные цели:
– продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;
– выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации.
Эта статья написана для того, чтобы помочь опытным специалистам по тестированию сделать разумный выбор и повысить эффективность тестирования даже в тех случаях, когда им приходится сталкиваться с неполными или противоречивыми требованиями, а также для начинающих разработчиков, которые хотели быть более компетентными в очередной IT сфере которая является неотъемлемой частью жизненного цикла разработки программного обеспечения, ибо без тестирования никогда не получится реально надежный проект.
Если взять современного разработчика, то спросив у него работает ли он над проектом в плане тестирования, большая часть ответит, «Нет!» или «Когда-то начинал но забросил потому что нет времени» или того хуже — «Нет! Потому что считаю это скучным и не интересным занятием», а на самом деле программист, более-менее участвовавший в проектах, которые динамично развиваются, а не те, которые пишутся один раз, отдаются заказчику и все о них благополучно забывают. Так вот, эти программисты как минимум умеют писать юнит тесты, ибо они ценят себя и свое драгоценное время. Разработчики говорят: «Да эти тесты писать, как минимум в два раза дольше чем код!» за то потом ты сэкономишь в десятки раз больше времени. Так как тебе не придется заново тестировать свой код когда ты поменяешь реализацию какого-то метода или сервиса который затрагивает другой код в десяти местах, ты просто прогонишь написанные тесты и будешь уверен, что всё работает или работает частично. При этом тест подскажет конкретное место сломанного кода. Тебе останется только пойти и исправить. Всё это хорошо, но какие же существуют виды тестирования?
Виды тестирования программного обеспечения
Всевиды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы:
- Функциональные
- Нефункциональные
- Связанные с изменениями
Далее, я постараюсь более подробно рассказать о каждом отдельном виде тестирования, его назначении и использовании при тестировании программного обеспечения.
Функциональные виды тестирования
Функциональные тесты основаны на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всехуровнях тестирования:
- Компонентном или модульном;
- Интеграционном;
- Системномиприемочном.
Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов:
1. Функциональное тестирование;
2. Тестированиебезопасности;
3. Тестирование взаимодействия.
Основное преимущество компонентных или модульных тестов то, что они пишутся для самых маленьких нетривиальных функций. Это позволяет в дальнейшем не только видеть места, где после некоторого рефакторинга могло что-то сломаться, но и принцип работы методов, покрытых тестами, т. к. данные генерируются отдельно, можно четко прослеживать какие данные вошли в метод, и какие мы получили на выходе. В идеале даже тот, кто только начал погружаться в код, должен понимать методы, читая тесты, написанные на него.
Недостатки компонентных или модульных тестов — это те случаи, когда нам требуется протестировать модули в связке. Т. е. по отдельности модули могут работать идеально, но как они работают в связке модульные тесты не гарантируют. Тут то нас и выручают интеграционные тесты.
Интеграционное тестирование предназначено для проверки связи между компонентами, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).
Уровни интеграционного тестирования:
1. Компонентный интеграционный уровень — проверяется взаимодействие между компонентами системы после проведения компонентного тестирования;
2. Системный интеграционный уровень — проверяется взаимодействие между разными системами после проведения системного тестирования.
Также можно выделить еще один уровень — системный.
Основной задачей системного тестирования являетсяпроверкав системе в целом. При этом выявляютсядефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т. д. Для минимизации рисков, связанных с особенностями поведения в системы в той или иной среде,во время тестирования рекомендуется использовать окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи.
Можно выделить два подхода к системному тестированию:
- На базе требований
Для каждого требования пишутсятестовые случаи (test cases), проверяющие выполнение данного требования.
- На базе случаев использования
На основе представления о способах использования продукта создаются случаи использования системы. По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутсятест кейсы, которые должны быть протестированы.
Как правило, функциональные тесты пишутся тестерами. У которых стоит задача найти ошибку (по крайней мере своим тестерам мы всегда ставим такую задачу). А значит будет больше проверок на нестандартные данные — что согласитесь, просто великолепно! К тому же, мы можем разделить правами доступов код продукта и тестов, что позволит избежать изменений тестов «чтоб он был зелёный, потому что надо релизиться»
К тому же, функциональными тестами гораздо проще покрывать готовый продукт, чем модульными — т. к. гораздо проще понять, что конкретно должна и не должна делать определённая часть пользовательского интерфейса, чем определить, чтодолжнаделать данная функция. И самая большая прелесть — вы можете начать покрывать функциональными тестами только самые важные части продукта — и они будут исправно гарантировать их работоспособность.
Вывод:
Функциональное тестированиерассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.
Функциональные тестыосновываются на функциях, выполняемых системой, и могут проводиться на всехуровнях тестирования(компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases) [2].
Преимущества функционального тестирования:
- Имитирует фактическое использование системы;
Недостатки функционального тестирования:
- Возможность упущения логических ошибок в программном обеспечении;
- Вероятность избыточного тестирования.
Нефункциональные виды тестирования
Нефункциональное тестирование — написание тестов, необходимых для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, «Как» система работает. Далее перечислены основные виды нефункциональных тестов [2]:
Все виды тестирования производительности:
1. Нагрузочное тестирование;
2. Стрессовое тестирование;
3. Тестирование стабильности или надежности;
4. Объемное тестирование;
5. Тестирование установки;
6. Тестирование удобства пользования;
7. Тестирование на отказ и восстановление;
8. Конфигурационное тестирование.
Вывод:
Основными преимуществами нефункционального тестирования являются числовые показатели, если это тестирование производительности, т. е. вы уже имеете представление о технических показателях, на которые можно опираться, чтобы делать какие-либо дальнейшие улучшения [1].
Либо если это тестирование установки, удобства пользователя, на отказ и восстановление или конфигурационное тестирование, то такие тесты всегда необходимы для более-менее приличного проекта. Скорее всего эти показатели будут затребованы заказчиком [1].
Минусом можно назвать дополнительное время на разработку, либо привлечение дополнительных ресурсов для выполнения этих работ.
Связанные с изменениями виды тестирования
После проведения необходимых изменений, таких как исправление бага либо дефекта, программное обеспечение должно быть пере тестировано для подтверждения того факта, что проблема была действительно решена. Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта:
- Дымовое тестирование;
- Регрессионное тестирование;
- Тестирование сборки;
- Санитарное тестирование или проверка согласованности, исправности [1].
В заключение можно сказать что даже в этой методологии можно найти пункты, не соответствующие каким-либо нормам или предпочтениям какого-нибудь менеджера, но рассмотрев основные достоинства и недостатки можно с уверенностью сказать, что эта методология не просто так держится в топе одних из самых популярных методологий и используется современными менеджерами программных проектов.
Литература:
- http://www.protesting.ru/testing/testtypes.html
- http://www.quizful.net/test/software_testing_basics
