Введение в тестирование ПО (стр. 1 )

Введение в тестирование ПО.

О тестировании программ по-настоящему серьёзно заговорили в США в 90-е годы. Это были сумасшедшие для High Tech индустрии годы. Появившиеся на рынке мощные персональные компьютеры, развитые операционные системы и средства программирования позволяли решать всё новые и новые, существенно более сложные задачи. Массовое внедрение Интернет, широкое использование RAD – технологий, позволяющих быстро проектировать прикладные программы, повлекли за собой создание огромных по прежним меркам программные систем. И сложность этих систем все растет день ото дня. Соответственно, количество потенциальных проблем также растет с неимоверной быстротой.

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

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

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

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

Тестирование ПО

Определения

Тестирование программного обеспечения (software testing) – это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов. Тестирование – это плановая и упорядоченная деятельность.

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

Ожидаемый результат – поведение системы, которое мы ожидаем увидеть в результате каких-либо наших действий с программой. Другими словами, это предполагаемое корректное поведение системы (программного продукта).

Если реальное поведение системы, которое мы наблюдаем, не совпадает с тем, что мы ожидали увидеть, мы можем говорить о том, что имеет место дефект.

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

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

Build (билд) – это промежуточная версия программного продукта, которая поставляется разработчиками для тестирования. После того, как группа тестирования приняла билд, он, как правило, поставляется заказчику для того, чтобы тот ознакомился с ходом работ и посмотрел на то, что и как в данный момент сделано. Иногда, заказчик не требует поставку билдов кроме самого последнего, когда все должно быть готово.

Объекты тестирования

Большинство стандартов определяют программное обеспечение (software) как программу (совокупность программ) плюс программная документация (program documentation). Следовательно, тестировать можно не только программы, но и различные документы. Итак, мы можем тестировать:

·  Программы при их непосредственном запуске и исполнении;

·  Код программ без их запуска и исполнения;

·  Прототип программного продукта (product prototype);

·  Различную проектную документацию (project documentation):

o  Требования к программному продукту (product requirements);

o  Функциональные спецификации к программному продукту (functional specifications);

o  Документы, описывающие архитектуру (product architecture), дизайн (product design);

o  План проекта (project plan) и тестовый план (test plan);

o  Тестовые сценарии (test cases);

·  Сопроводительную документацию (или документацию для конечных пользователей):

o  Интерактивную помощь (on-line help);

o  Руководства по установке (Installation guide) и использованию программного продукта (user manual).

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

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

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

Для тестирования программного кода без его непосредственного запуска применяется метод белого ящика (white box testing method).. Говоря о структурном тестировании (structured testing), мы понимаем, как раз, тестирование данным методом. Его тесты основаны на знании кода приложения и его внутренних механизмов. Соответственно концепция структурного тестирования связана с тестированием внутренней структуры исходного кода программного обеспечения. Метод белого ящика обычно применяется на стадии, когда приложение еще не собрано воедино, но необходимо проверить каждый из его компонентов, модулей, процедур и подпрограмм. Следовательно, структурное тестирование тесно взаимосвязано с компонентным или модульным тестированием (unit testing), которое чаще всего выполняет программист, хорошо понимающий код.

Метод черного ящика (black box testing), тесты которого разработаны исходя из знаний функциональных и бизнес требований к тестируемому продукту, используется для тестирования программы при ее запуске на исполнение. Тестировщик тестирует программу так, как с ней будет работать конечный пользователь, и он ничего не знает о внутренних механизмах и алгоритмах, по которым работает код программы. Другими словами, он запускает приложение на выполнение и тестирует его функциональность, используя пользовательский интерфейс для ввода входных данных и получая выходные. Но как при этом обрабатываются входные данные, он не знает. Цель данного метода – проверить работу всех функций приложения на соответствие функциональным требованиям.

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

Существует также метод серого ящика (gray box testing method), которые сочетает в себе нечто среднее между методами белого и черного ящиков.

Критерии тестирования

Рассмотрим требования к идеальному критерию тестирования

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

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