Введение
Знание о тестировании программного обеспечения критически важно не только для разработчиков программного обеспечения, программистов и профессиональных тестеров, но также и для покупателей, и пользователей. В последнюю категорию попадаем мы все.
Почему программное обеспечение нужно тестировать?
Цели тестирования программного обеспечения, независимо от того, кто совершает тестирование или где это сделано, состоят в том, чтобы обеспечить необходимое качество программного обеспечения и снизить риск ошибок в программе - "багов". Баг - код программы, который приводит к искажению или вовсе несовпадению фактического результата и того, который мы ожидаем. Баги могут быть относительно малозначимыми (типографическая ошибка на экране), средней значимости (определенная комбинация нажатий клавиш приводит к ошибке в работе программы), или очень серьезными (процедура вычисления среднего арифметического числа из нескольких заданных является дефектной). Тестирование и отладка ПО – совсем не одно и то же. Тестирование фокусируется на предотвращении багов и нахождении их в готовом коде. Отладка может быть логическим следствием тестирования. Цель отладки состоит в том, чтобы найти код, который привел к отказу программы и исправить его. Тестирование программного обеспечения может показать некоторые, но не все дефекты в коде программы. Оно также демонстрирует, что функция программы и ее производительность могут быть корректными или неправильными, или обнаружить логический отказ - это означает, что программа делает то, что ей сказали сделать, но чье-то обоснование (разработчика или программиста) было в некотором роде дефектным.
Кто участвует в процессе тестирования программного обеспечения?
Покупатель и/или пользователь ПО должны играть главную роль в процессе его тестирования. Заказчик должен работать с разработчиком во время процесса планирования и проектирования так, чтобы все стороны достигли договоренностей о том, из чего будет состоять заключительный продукт и как он должен выглядеть и работать. Джоэл Джилмен в колонке «Law Report» журнала «Systems Integration» в феврале 1991 предложил, чтобы документ тестовых критериев был составлен и включен в исходные требования к продукту или контракт. Программисты должны быть ответственны за основное тестирование программного обеспечения. Хороший программист никогда не должен передавать программу к тестеру или отделу тестирования без первой обработки тестовых сценариев, которая определяет, отвечает ли программа определенным требованиям. Нужно отметить, однако, что у тестировщиков и программистов есть различные цели, когда они тестируют программное обеспечение. Борис Бейзер в «Software Testing Techniques »- превосходной книге по основам тестирования - сказал, что тестировщик - это "тот, кто пишет и/или выполняет тестирование программного обеспечения с намерением продемонстрировать, что программа не работает, в то время, как программист – это тот, чьи тестирования (если таковые имеются) предназначены, чтобы показать, что программа действительно работает".
Что являет собой тестирование ПО?
Тестирование программного обеспечения - процесс, цель которого состоит в том, чтобы предотвратить и раскрыть "баги" в ПО и определить, соответствует ли оно определенным требованиям. Считается, что половина работы по созданию программного обеспечения - это тестирование. Есть четыре общие категории, часто называемые этапами тестирования программного обеспечения. О них дальше и пойдет речь.
Юнит-тестирование тестирует самые маленькие части программного обеспечения - юниты . Цели такого тестирования состоят в том, чтобы оценить, удовлетворяет ли юнит требования спецификации и/или соответствует ли его структура оговоренной структуре проекта. Юнит-тестирование должно быть реализовано программистом. Есть множество инструментов, которые могут быть использованы, чтобы оценить, были ли протестированы все пути, которыми ПО может реализоваться.
Цель интеграционного тестирования состоит в том, чтобы протестировать то, что происходит, когда все части ПО объединены (интегрированы) в одно целое . Обычно, если проблема найдена, она имеет отношение к информации, упущенной при интеграции таких юнитов.
Відео курси за схожою тематикою:
Системное тестирование, исходя из своего названия, нацелено на тестирование всей системы. Оно направлено на нахождение проблем, кроме тех, которые могут быть приписаны юнитам и/или их взаимодействиям. В системном тестировании можно проверить систему на производительность, вопросы безопасности и другие проблемы этих типов.
Приемочные испытания - широкая категория, которая обеспечивает заключительную сертификацию и гласит, что система готова к реальному использованию. Они могут включать очень интенсивные тесты, которые проверяют положительные и отрицательные аспекты системы и ее функциональность. Причинами багов, найденных на этапе приемочных испытаний, обычно является неполное понимание своего задания разработчиком или отсутствием коммуникации между покупателем и разработчиками. Есть другие этапы тестирования, которые могут быть реализованы совместно с вышеперечисленными этапами. Это регрессивное тестирование, тестирование на надежность и удобство пользования, соответствие стандартам, тестирование функциональной совместимости.
Когда должен начинаться процесс тестирования?
Тестирование, конечно, не может начаться, пока тестируемый программный код не будет написан. Однако процесс тестирования должен зарождаться, когда начинается процесс разработки ПО. Время, потраченное на устранение ошибок, намного короче, когда тестирование запланировано в начале фазы проектирования, чем в ее конце. Системные требования должны быть записаны и согласованы всеми сторонами, и эти спецификации требований должны использоваться в качестве основного плана тестирования.
Когда разработчик должен прекратить тестировать и поставить продукт?
Решение может основываться на измерении коэффициентов ошибок. Однако ключевое решение будет всегда основываться на доступных ресурсах. Если до релиза продукта имеется определенный объем времени, можно было бы расширить тестирование на каждом этапе. Однако, если бы программное обеспечение было обещано 6 месяцев назад, тестировщик мог бы рискнуть и сказать о том, что программа работает без серьезных багов, даже если он или она знает о некоторых незначительных ошибках. Все это сводится к оценке степени риска и способности определить, когда более или менее безопасно отослать продукт заказчику. Если дефектный продукт отослан, новая версия его все же может быть выпущена, однако это подразумевает совершенно новый набор оценок степени риска.
Как должен быть записан и выполнен план тестирования?
Планы тестирования на каждом этапе должны основываться на структурированных требованиях. Эти требования должны быть записаны и согласованы всеми сторонами еще до того, как будет написан программный код. Тестовое планирование должно включать в себя шаги по проверке требований спецификации, проектировать тесты, и, наконец, определять процедуры (тестовые сценарии) и/или получать тест-кейсы. Тест-кейсы – это отдельная наука . Цель их состоит в том, чтобы идентифицировать все типы случаев, которые могли бы произойти согласно каждому сценарию. После того, как код, который будет протестирован, записан, тестер выполняет запланированные тесты, оценивает результаты и обеспечивает обратную связь. Эта обратная связь становится документально подтвержденным фактом для системы.
Безкоштовні вебінари за схожою тематикою:
Источник: "Software Testing" Judith S. Douglass
Статті за схожою тематикою
