We catch your bugs!)

Основные задачи тестирования

Еще несколько терминов, которые связаны с упомянутыми двумя задачами, которыми занимается тестировщик, это стимулы, реакции и оракул.

Стимулы – это данные, которые подаются на вход программе.

Реакции — это то, что получается на выходе.

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

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

• Пользовательский интерфейс (UI)
• Программный интерфейс (API)
• Сетевой протокол
• Файловая система
• Состояние окружения
• События

Наиболее распространенные интерфейсы это

• графический,
• текстовый,
• консольный,
• и речевой.

Через пользовательский интерфейс компьютер взаимодействует с человеком, с пользователем.

Через программный интерфейс программы взаимодействуют друг с другом (человек тут не нужен).

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

Это файловая система, программы могут писать данные на диск и читать данные с диска.

Это состояние окружения, которое могут программы модифицировать и, соответственно, тоже читать.

Это события, в частности, таймер. То есть некоторые механизмы отслеживания времени.

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

Виды тестирования

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

Говоря о качестве компьютерных программ, я придерживаюсь трактовки, которая изложена в стандарте ISO 9126. Этот стандарт выделяет 6 аспектов качества, у каждого из которых еще выделяется некоторое количество подхарактеристик.

Вот эти 6 аспектов качества верхнего уровня:

• функциональность,
• надежность,
• практичность,
• эффективность,
• сопровождаемость
• переносимость.

Функциональность

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

Во-вторых, она должна делать это правильно (accuracy). Она должна вычислять с определенной точностью, она должна правильно конвертировать данные и так далее.

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

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

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

Надежность

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

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

Практичность

Это понятность программы (understandability) то есть пользователь должен понять, как воспользоваться ею для достижения своих целей.

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

Это работоспособность (operability) или управляемость, то есть пользователь должен иметь возможность управлять поведением программы, она должна реагировать на его действия.

И привлекательность (attractiveness), эстетическая привлекательность, что тоже, конечно же, немаловажно.

Эффективность

Она же – производительность, четвертый аспект качества.

Сюда относятся временные характеристики (time behaviour), время отклика, скорость работы программы, скорость обработки определенных данных и так далее.

И использование ресурсов (resource utilisation), использование дисковых ресурсов, использование ресурсов процессора, использование оперативной памяти, использование сетевых ресурсов.

Сопровождаемость

Этот аспект качества в большей степени не внешний, а внутренний.

Он важен не столько конечным пользователям, не столько потребителям программы, сколько самим разработчикам и ее тестировщикам.

Является единственным аспектом качества, который плохо совместим с тестированием, и является сопровождаемость.

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

Подразумевает анализируемость кода (analyzability), изменяемость(changeability), то есть удобство внесения изменений в программный код,риск возникновения неожиданных эффектов после того, как мы эти изменения внесли (stability), а также контролируемость (testability), или же – удобство тестирования программы.

Переносимость (или мобильность)

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

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

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

И получаем разные виды тестирования:

• тестирование функциональности,
• тестирование надежности,
• тестирование эффективности,
• тестирование практичности,
• тестирование сопровождаемости,
• тестирование переносимости.

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

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

Чаще всего используется разбиение на три уровня, это

1. модульное тестирование,
2. интеграционное тестирование,
3. системное тестирование.

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

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

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

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

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

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

Библиотеки состоят из классов, классы состоят из методов, на стороне баз данных тоже есть пакеты, состоящие из хранимых процедур.

Само по себе приложение тоже может являться частью какой-то более крупной информационной системы.

В этой матрешке мы должны понять, где, на каком уровне у нас должно находиться модульное тестирование, а на каком должно находиться системное тестирование. И найти еще место для интеграционного.

Глядя на эту матрешку мы можем понять, что разделение на системное и модульное тестирование является чисто условным.

То есть у нас система состоит из каких-то модулей. Модули в свою очередь состоят из других более мелких модулей. Эти мелкие модули состоят еще из более мелких, и так далее.

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

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

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

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

То есть разделение на системное и модульное тестирование вообще говоря чисто условное, если говорить с технической точки зрения.

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

Комбинируем:

То есть, можно говорить о модульном тестировании функциональности.

Можно говорить о системном тестировании функциональности.

Можно говорить о модульном тестировании, например, эффективности.

Можно говорить о системном тестировании эффективности.

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

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

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

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

И разница эта проявляется тогда, когда мы выполняем не технологическую классификацию, а классификацию по целям тестирования.

Классификацию по целям удобно выполнять с использованием «магического квадрата», который был изначально придуман Брайаном Мариком и потом улучшен Эри Тенненом.

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

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

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

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

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

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