Файл: Основные понятия качества и тестирования программ.pdf

2. Виды тестирования, тестирование надежности, организация процесса тестирования

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

1. Тестирование “белого ящика”, “черного ящика”, “серого ящика”.

В зависимости от того, как глубоки познания тестировщика о продукте,

доступен ли только интерфейс программы или её исходный код. Это классификация тестов по знанию системы тестировщиком и она бывает трех видов: тестирование черного ящика, тестирование белого ящика и тестирование серого ящика. [11]

Наиболее распространённым является тестирование черного ящика. Два других встречаются крайне редко.

Тестирование Черного Ящика – это тестирование только той части программы, которая доступна через её интерфейс. В этом случае считается проверка кода программы не выполняется. К этим тестам можно отнести проверку граничных значений вводимой и выводимой информации, проверку согласно готовым тест кейсам и use-кейсам, проверку перехода программы из одного состояния в другое. Так же сюда можно отнести не функциональные тесты, такие как проверка удобства использования, производительности, технических требований к компьютеру. [10]

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

Выделяют четыре техники проведения тестирования черного ящика[9]:

- проверка классов эквивалентности;

- проверка граничных значений;

- проверка согласно таблице вариантов использования;

- проверка согласно таблице переходов состояний.

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

Рисунок 5 – Виды тестирования

Тестирование Белого Ящика – это тестирование работы программы исходя из знания её программного кода. Здесь важно проверить все условия переходов внутри функций, полноту их покрытия, правильность вычисления формул. При таком тестировании проверка выполняется не запуская программу. Читая программный код тестируется правильность реализации циклов операций, переходов внутри программы. К этой группе тестов от-носится и проверка результатов технических исследований программы, сопоставление реализованных программистами алгоритмов к тем, которые планировались дизайнерами системы.[10]

К белому ящику можно также отнести разведывательное тестирование, когда осуществляется выборочная работа с теми участками программы, в которых ожидаете увидеть ошибку. Анализ тестовой документации и результатов тестов является тестированием белого ящика, и следовательно, вычисление всех тестовых характеристик (процент тестового покрытия, уровень успешности тестов, степень рисков и т.д.) – это тоже тестирование белого ящика.[11]

Тестирование Серого Ящика – это тестирование включает в себя оба предыдущих.

2 По степени автоматизации тестов[9]

По степени автоматизации тестирование может быть ручным, автоматизированным и полу автоматизированным.

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

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

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

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

3 По виду позитивности[10]

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

Позитивные тесты проверяют, что при подаче программе входных параметров, соответствующих требованиям, она работает согласно техническому заданию. [17]

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

4 По времени проведения[10]

Процесс разработки программы делится на несколько фаз. На каждой фазе требуется проверять разные аспекты работы программы и покрывать тестированием разную функциональность. На одном этапе можно провести, что программа вообще запускается, а на другом может понадобиться полная проверка всех компонентов системы. Поэтому по времени проведения выделяют следующие виды тестов: Альфа, Бета, Дымное (Smoke), Регрессионное, Приемочное (User Acceptance Testing, UAT).

Альфа тестирование[7] – это тестирование продукта штатными сотрудниками компании, которая разрабатывает продукт. Альфа тестирование проводится для того, чтобы выявить и исправить ошибки в полностью собранной финальной версии продукта перед тем как отдавать её заказчику

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

Дымное тестирование – это поверхностный осмотр программы на то что она вообще способна работать и выполнять основные функции. Это тестирование проводится для того, чтобы пропустить какой-то модуль или всю программу на более точные этапы проверки.[10]

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

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

5 По степени изолированности компонентов[11]

Можно проверять какую-то одну компоненту из приложения, либо проверить сразу несколько компонент или же всё приложение в целом. В связи с этим виды тестирования разделяют по степени изолированности компонентов.

Модульным тестированием (Unit testing) – называется проверка минимально функциональной автономной единицы программы. Чаще всего это проверка функций и процедур внутри кода программы. Такое тестирование чаще всего автоматизируют. Отчеты об ошибках при таком тестировании создаются редко, потому что всё исправляется “на лету”. Для проверки функций кода пишется программа, которая подаёт на вход предопределенные параметры и сравнивает полученный результат на выходе функции с ожидаемым[10].

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

Системное тестирование – это тестирование полностью собранной системы в том виде, в котором она будет поставляться заказчику[18].

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

6. Основы тестирования web-приложений.[9]

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

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

Тестирование клиента будет называться фронтэндом.[17] Это проверка всего того, что будет доступно пользователю, то есть – клиентская часть приложения. Они должны заниматься проверкой внешнего вида, правильности отображения информации. Это ещё и тесты удобства использования. Фронтэнд часть обычно легче тестируется, чем бэкэнд, поскольку на клиент в основном всегда ложиться только операция отображения информации, а все её преобразования ведутся на сервере. Но тестирование фронтэнда может быть более трудоемкое, в плане количества задач, потому что оно может включать проверку работоспособности на разных браузерах, операционных системах, при различных настройках отображения информации. Это требует выполнения одних и тех же тестов в разной среде. Такая работа довольно монотонная и человек, зачастую, психологически сильно устает. [13]

Чаще всего сервер не имеет графического интерфейса в целях экономии ресурсов, требуемых для его работы. Это будет некоторое консольное приложение, поэтому обязательным будет знание командной строки той операционной системы, на которой оно работает. Одновременно с основной функциональностью web-приложений важную роль играет их безопасность. В последнее время для проверки защищенности системы прибегают к помощи сторонних специалистов, которых называют этическими хакерами (ethic hackers) или пентестерами (penetration tester - тестиров-щик возможности проникновения). По сути – это специалисты, которые пытаются взломать систему, но только не пользуются результатами взлома, а сообщают о них работодателю. Их тоже можно отнести к тестировщикам.[8]

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

2.2. Организация тестирования

Организация тестирования программного обеспечения регулируется следующими стандартами:

• IEEE 829-1998. Описывает виды документов, служащих для подготовки тестов.[6]
• IEEE 1008-1987. Описывает организацию модульного тестирования.
• ISO/IEC 12119:1994. Описывает требования к процедурам тестирования программных систем.