Эффективная подготовка к государственным междисциплинарным экзаменам для студентов технических специальностей (стр. 14 )

Не используйте ООП, если :

1. вы создаете приложение, от которого требуется максимальная эффективность (при ограничении на объем памяти и/или скорость исполнения);

2. задача по своему характеру не расчленяется на логически обособленные объекты со схожими свойствами (численные методы и т. д.);

3. имеется средство, более подходящее для решения поставленной задачи (так, например, не стоит писать обработку. dbf файлов на объектном расширении Pascal, если имеется специально на это ориентированный FoxPro).

5. Принципы тестирования. Отладка

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

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

В соответствие с RUP Тестирование — одна из дисциплин RUP. Она ориентирована в первую очередь на оценку качества с помощью следующих методов:

поиск и документирование дефектов качества;

общие рекомендации относительно качества;

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

проверка, что продукт функционирует так, как было запроектировано;

проверка, что требования выполнены соответствующим образом.

В соответствие с IEEE Std 829-1983 Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств ПО.

По ГОСТ Р ИСО МЭК 12207-99 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора.

В сумме эти процессы и составляют то, что обычно называют тестированием.

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

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

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

Другое определение тестирования (у Г. Майерса) тестирование - это процесс выполнения программы с целью обнаружения в ней ошибок. Такое определение цели стимулирует поиск ошибок в программах.

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

У Майерса сформулированы также основные принципы организации тестирования:

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

2.  следует по возможности избегать тестирования программы ее автором, т. к. кроме уже указанной объективной сложности тестирования для программистов здесь присутствует и тот фактор, что обнаружение недостатков в своей деятельности противоречит человеческой психологии (однако отладка программы эффективнее всего выполняется именно автором программы ) ;

3.  по тем же соображениям организация - разработчик программного обеспечения не должна “единолично” его тестировать (должны существовать организации, специализирующиеся на тестировании программных средств);

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

5.  необходимо тщательно подбирать тест не только для правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных);

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

7.  следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика);

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

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

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

Существует два основных вида тестирования: функциональное и структурное.

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

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

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

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

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

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

Таким образом, ни структурное, ни функциональное тестирование не может быть исчерпывающим.

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

Процесс отладки начинается при обнаружении ошибки и проводится в два этапа:

1) определяется природа и местонахождение ошибки в программе,

2) фиксируется и исправляется ошибка.

Методы:

Методы "грубой силы"

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

Методы грубой силы можно разделить по крайней мере на три категории: 1) отладка с использованием дампа памяти; 2) отладка в соответствии с общим предложением «расставить операторы печати по всей программе»; 3) отладка с использованием автоматических средств.

Метод индукции

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

Метод дедукции

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

Метод "Прослеживание логики в обратном порядке"

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

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