Тестировщик программного обеспечения

Размещено на http://www.allbest.ru/

Министерство образования и науки РФ

ФГБОУ ВПО «Восточно-Сибирский государственный университет технологий и управления»

Электротехнический университет

Кафедра систем информатики

Доклад

По дисциплине: Вопросы философия программной инженерии

На тему: «Тестировщик программного обеспечения»

Выполнили:

Проверила:

Улан-Удэ

2014

Содержание

Введение

1. Специфика профессии

2. История

3. Направления тестирования производительности

4. Определение целей тестирования производительности

Заключение

Введение

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

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

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

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

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

В случае создания программ с различными уровнями защиты и прав доступа для пользователя количество возможных моделей поведения («начальник», «подчинённый») существенно увеличивается.

Тестировщики ПО работают в IT-компаниях, в крупных компаниях, внедряющих свои программы, а также в независимых группах тестирования.

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

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

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

Знания и навыки:

Чтобы работать тестировщиком ПО, желательно иметь высшее техническое образование по специальности "Информационные системы и технологии" или "Автоматизация систем обработки информации и управления". Этот специалист должен быть продвинутым ПК-пользователем. Ему необходимо уметь пользоваться языком SQL, работать с такими базами данных, как MSSQL, Oracle. Если речь идет об автоматизированном тестировании, то специалисту необходимо знать такие программы, как Silk Test или Rational Robot.

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

1. Специфика профессии

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

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

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

2. История

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

В 1960-х много внимания уделялось «исчерпывающему» тестированию, которое должно проводиться с использованием всех путей в коде или всех возможных входных данных. Было отмечено, что в этих условиях полное тестирование программного обеспечения невозможно, потому что, во-первых, количество возможных входных данных очень велико, во-вторых, существует множество путей, в-третьих, сложно найти проблемы в архитектуре и спецификациях. По этим причинам «исчерпывающее» тестирование было отклонено и признано теоретически невозможным.

В начале 1970-х годов тестирование программного обеспечения обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы программного обеспечения». В зарождавшейся программной инженерии верификация ПО, значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности -- неэффективный метод тестирования программного обеспечения. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приёмо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест -- это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой -- выявляет ошибки в программах, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки программного обеспечения.

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

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

В 2000-х появилось ещё более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий». Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки программного обеспечения для достижения необходимого уровня качества, производительности, доступности.

3. Направления тестирования производительности

тестирование производительность программный

В тестировании производительности различают следующие направления:

· нагрузочное (load)

· стресс (stress)

· тестирование стабильности (endurance or soak or stability)

· конфигурационное (configuration)

Возможны два подхода к тестированию производительности программного обеспечения;

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

Нагрузочное тестирование:

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

Стресс-тестирование:

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

Тестирование стабильности:

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

Конфигурационное тестирование:

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

4. Определение целей тестирования производительности

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

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

· С целью определения производительность какой из двух или нескольких систем лучше.

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

Многие тесты на производительность делаются без попытки осмыслить их реальные цели. Перед началом тестирования всегда должен быть задан бизнес-вопрос: «Какую цель мы преследуем, тестируя производительность?». Ответы на этот вопрос являются частью технико-экономического обоснования (или business case) тестирования. Цели могут различаться в зависимости от технологий, используемых приложением, или его назначения, однако, они всегда включают что-то из нижеследующего:

Параллелизм / Пропускная способность:

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

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

Время ответа сервера:

Эта концепция строится вокруг времени ответа одного узла приложения на запрос, посланный другим. Простым примером является HTTP 'GET' запрос из браузера рабочей станции на веб-сервер. Практически все приложения, разработанные для нагрузочного тестирования работают именно по этой схеме измерений. Иногда целесообразно ставить задачи по достижению производительности времени ответа сервера среди всех узлов приложения.

Время отображения:

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

Требования к производительности:

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

Однако тестирование производительности часто не проводится согласно спецификации, так как нет зафиксированного понимания о максимальном времени ответа для заданного числа пользователей. Тестирование производительности часто используется как часть процесса профайлинга производительности. Его идея заключается в том, чтобы найти «слабое звено» -- такую часть системы, соптимизировав время реакции которой, можно улучшить общую производительность системы. Определение конкретной части системы, стоящей на этом критическом пути, иногда очень непростая задача, поэтому некоторые приложения для тестирования включают в себя (или могут быть добавлены с помощью add-on'ов) инструменты, запущенные на сервере (агенты) и наблюдающие за временем выполнения транзакций, временем доступа к базе данных, оверхедами сети и другими показателями серверной части системы, которые могут быть проанализированы вместе с остальной статистикой по производительности.

Тестирование производительности может проводиться с использованием глобальной сети и даже в географически удаленных местах, если учитывать тот факт, что скорость работы сети Интернет зависит от местоположения. Оно также может проводиться и локально, но в этом случае необходимо настроить сетевые маршрутизаторы таким образом, чтобы появилась задержка, присутствующая во всех публичных сетях. Нагрузка, прилагаемая к системе, должна совпадать с реальным положением дел. Так например, если 50 % пользователей системы для доступа к системе используют сетевой канал шириной 56К, а другая половина использует оптический канал, то компьютеры, создающие тестовую нагрузку на систему должны использовать те же соединения (идеальный вариант) или эмулировать задержки вышеуказанных сетевых соединений, следуя заданным профайлам пользователей.

Заключение

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

Обо всём об этом я узнал на первом своём месте в качестве тестировщика с неугасшими амбициями разработчика. В первую очередь, меня очаровала возможность получения доступа к управлению продуктом, власть. Это выше написания очередной функциональности. Во-вторых, тестировщики в силу особенностей профессии имеют большее представление о процессах и целях продукта, отчасти транслируют бизнес цели разработчикам, а результат разработчиков -- руководителям. К сожалению, в мире и, тем более, в России, представление о роли тестировщика весьма сумбурное, и её значение сильно преуменьшается. А те компании, которые всё-таки находятся в тренде, стараются развить направления тестирования и управления качеством, хотя и ставят несколько завышенные цели: «найти все ошибки, снизить до минимума стоимость разработки через тестирование».

Размещено на Allbest.ru