Тестирование. На этапе кодирования должны выполняться следующие рекомендации

Кодирование.

На этапе кодирования должны выполняться следующие рекомендации.

1. Обеспечить читаемость текста программы:

– использовать значащие имена переменных;

– не использовать в качестве идентификаторов ключевые слова языка или идентификаторы используемых библиотек;

– избегать промежуточных переменных там, где без них можно обойтись;

– применение круглых скобок там, где порядок операций не очевиден;

– не изменять счётчик цикла в теле цикла;

– не использовать переход по меткам.

2. Не приносить читаемость в жертву эффективности там, где, возможно, будет требоваться доработка кода.

3. Использовать особенности языка программирования:

– изучайте и используйте прямые возможности языка программирования, библиотечные и встроенные функции;

– не игнорируйте предупреждения транслятора.

4. Не улучшать модуль, пока он не будет проверен.

5. Увеличивать эффективность за счёт правильного выбора алгоритма и структур данных.

6. Желательно, чтобы модуль компелировался без ошибок с первого раза потому что:

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

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

– компилятор может не обнаружить некоторые ошибки (двойное толкование, отключение предупреждений и т.д.);

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

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

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

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

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

Две основных задачи:

– подготовить набор тестов, определяющий наибольшее количество ошибок;

– определение момента окончания тестирования.

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

Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция

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

Системное тестирование — тестируется интегрированная система на её соответствие исходным требованиям

Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на стороне разработчика. Часто альфа-тестирование применяется для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

Тестирование «белого ящика» и «чёрного ящика»

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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

Статическое и динамическое тестирование

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

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

Ручной контроль

При статическом подходе анализируют структуру, управляющие и информационные связи программы, её входные и выходные данные. При динамическом – вручную моделируют процесс выполнения программы для различных входных данных. Исходные данные: техническое задание, внешние спецификации, структурная / функциональная схема, схемы компонент и т.д.

Методы ручного контроля:

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

Сквозные просмотры – анализ текста программы с применением к нему мысленных тестов.

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

Оценка программ – из ряда аналогичных программ группа разработчиков выбирает наилучшие и наихудшие.

Структурное тестирование

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

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определенной степени. При тестировании белого ящика используются метрики покрытия кода.

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

Критерии формирования тестовых наборов:

– покрытие операторов: чтобы каждый оператор выполнился по крайней мере один раз;

– покрытие решений: все возможные результаты каждого условия принимали значение истина / ложь хотя бы один раз;

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

– покрытие решений и условий;

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

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

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

Это тестирование для всех наборов входных данных.

Методы формирования тестовых наборов:

– эквивалентное разбиение: входные данные разбивают на «классы эквивалентности», каждый из которых должен выявить одну ошибку; разбиение является эвристическим процессом, но требуется определить по крайней мере 2 класса: для верных и неверных входных данных;

– анализ граничных значений – выбираются значения строго на границах классов эквивалентности и около них;

– анализ причинно-следственных связей; здесь «причина» – отдельное входное условие или класс эквивалентности, «следствие» – предобразование системы; далее строят по спецификациям таблицы истинности для функций;

– предположения об ошибках.

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

– тесты, разработанные по приведённым выше методикам, перестают выявлять ошибки;

– экспертно оценивают кол-во ошибок и завершают тестирования по выявлению 93-95%;

– если количество выявленных ошибок на единицу времени становится мало.

"Заповеди" тестов

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

Качество теста определяется тем, может ли он обнаружить ошибку.

Тесты должны строиться для несогласованных, неправильных данных.

Тестирование должно документироваться. Не следует использовать тесты, которые затруднительно повторить.

Каждый модуль тестируется и подключается только один раз.

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

Дата добавления: 2014-01-05