В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 22
Текст из файла (страница 22)
Интеграционное тестирование также используется приотладке, но на более позднем этапе разработки.• Системное тестирование (system testing) предназначено для проверки правильностиработы системы в целом, ее способности правильно решать поставленные пользователямизадачи в различных ситуациях.Системное тестирование выполняется через внешние интерфейсы ПО и тесно связано стестированием пользовательского интерфейса (или через пользовательский интерфейс),проводимым при помощи имитации действий пользователей над элементами этогоинтерфейса.
Частными случаями этого вида тестирования являются тестирование69графического пользовательского интерфейса (Graphical User Interface, GUI) ипользовательского интерфейса Web-приложений (WebUI).Если интеграционное и модульное тестирование чаще всего проводят, воздействуя накомпоненты системы при помощи операций предоставляемого ими программногоинтерфейса (Application Programming Interface, API), то на системном уровне безиспользования пользовательского интерфейса не обойтись, хотя тестирование через API вэтом случае также вполне возможно.Основной недостаток тестирования состоит в том, что проводить его можно, только когдапроверяемый элемент программы уже разработан. Снизить влияние этого ограничения можно,подготавливая тесты (а это — наиболее трудоемкая часть тестирования) на основе требованийзаранее, когда исходного кода еще нет. Подход опережающей разработки тестов с успехомиспользуется, например, в рамках XP.Проверка на моделяхПроверка свойств на моделях (model checking) [10] — проверка соответствия ПОтребованиям при помощи формализации проверяемых свойств, построения формальных моделейпроверяемого ПО (чаще всего в виде автоматов различных видов) и автоматической проверкивыполнения этих свойств на построенных моделях.
Проверка свойств на моделях позволяетпроверять достаточно сложные свойства автоматически, при минимальном участии человека.Однако она оставляет открытым вопрос о том, насколько выявленные свойства модели можнопереносить на само ПО.ПроверяемыетребованияФормализацияпроверяемыхсвойствФормальныесвойстваАвтоматическаяпроверка свойствЭвристикипостроениямоделиПостроениемодели ПОМодель ПОАнализрезультатовРезультатыпроверки —отчетыРисунок 26. Схема процесса проверки свойств ПО на моделях.Обычно при помощи проверки свойств на моделях анализируют два вида свойств алгоритмов,использованных при построении ПО.
Свойства безопасности (safety properties) утверждают, чтонечто нежелательное никогда не случится в ходе работы ПО. Свойства живучести (livenessproperties) утверждают, наоборот, что нечто желательное при любом развитии событийпроизойдет в ходе его работы.Примером свойства первого типа служит отсутствие взаимных блокировок (deadlocks).Взаимная блокировка возникает, если каждый из группы параллельно работающих в проверяемомПО процессов или потоков ожидает прибытия данных или снятия блокировки ресурса от одногоиз других, а тот не может продолжить выполнение, ожидая того же от первого или от третьегопроцесса, и т.д.Примером свойства живучести служит гарантированная доставка сообщения, обеспечиваемаянекоторыми протоколами — как бы ни развивались события, если сетевое соединение междумашинами будет работать, посланное с одной стороны (процессом на первой машине) сообщениебудет доставлено другой стороне (процессу на второй машине).В классическом подходе к проверке на моделях проверяемые свойства формализуются в видеформул так называемых временных логик.
Их общей чертой является наличие операторов «всегда70в будущем» и «когда-то в будущем». Заметим, что второй оператор может быть выражен спомощью первого и отрицания — то, что некоторое свойство когда-то будет выполнено,эквивалентно тому, что отрицание этого свойства не будет выполнено всегда.
Свойствабезопасности легко записываются в виде «всегда будет выполнено отрицание нежелательногосвойства», а свойства живости — в виде «когда-то обязательно будет выполнено желаемое».Проверяемая программа в классическом подходе моделируется при помощи конечногоавтомата. Проверка, выполняемая автоматически, состоит в том, что для всех достижимых приработе системы состояний этого автомата проверяется нужное свойство.
Если оно оказываетсявыполненным, выдается сообщение об успешности проверки, если нет — выдается трасса,последовательность выполнения отдельных шагов программы, моделируемых переходамиавтомата, приводящая из начального состояния в такое, в котором нужное свойство нарушается.Эта трасса используется для анализа происходящего и исправления либо программы, либо модели,если ошибка находится в ней.Основная проблема этого подхода — огромное, а часто и бесконечное, количество состояний вмоделях, достаточно хорошо отражающих поведение реальных программ.
Для борьбы скомбинаторным взрывом состояний применяются различные методы оптимизации представленияавтомата, выделения и поиска состояний, существенных для выполнения проверяемого свойства.Ошибки в программахОшибками в ПО, вообще говоря, являются все возможные несоответствия междудемонстрируемыми характеристиками его качества и сформулированными или подразумеваемымитребованиями и ожиданиями пользователей.В англоязычной литературе используется несколько терминов, часто одинаково переводящихсякак «ошибка» на русский язык.• defect — самое общее нарушение каких-либо требований или ожиданий, не обязательнопроявляющееся вовне (к дефектам относятся нарушения стандартов кодирования,недостаточная гибкость системы и пр.).• failure — наблюдаемое нарушение требований, проявляющееся при каком-то реальномсценарии работы ПО.
Это можно назвать проявлением ошибки.• fault — ошибка в коде программы, вызывающая нарушения требований при работе(failures), то место, которое надо исправить. Хотя это понятие используется довольно часто,оно, вообще говоря, не вполне четкое, поскольку для устранения нарушения можноисправить программу в нескольких местах. Что именно надо исправлять, зависит отдополнительных условий, выполнение которых мы хотим при этом обеспечить, хотя внекоторых ситуациях наложение дополнительных ограничений не устраняетнеоднозначность.• error — используется в двух смыслах.Первый — это ошибка в ментальной модели программиста, ошибка в его рассуждениях опрограмме, которая заставляет его делать ошибки в коде (faults).
Это, собственно, ошибка,которую сделал человек в своем понимании свойств программы.Второй смысл — это некорректные значения данных (выходных или внутренних), которыевозникают при ошибках в работе программы.Эти понятия некоторым образом связаны с основными источниками ошибок. Поскольку приразработке программ необходимо сначала понять задачу, затем придумать ее решение изакодировать его в виде программы, то, соответственно, основных источников ошибок три.• Неправильное понимание задач.Очень часто люди не понимают, что им пытаются сказать другие.
Так же и разработчикиПО не всегда понимают, что именно нужно сделать. Другим источником непониманияслужит отсутствие его у самих пользователей и заказчиков — достаточно часто они могутпросить сделать несколько не то, что им действительно нужно.71Для предотвращения неправильного понимания задач программной системы служит анализпредметной области.• Неправильное решение задач.Зачастую, даже правильно поняв, что именно нужно сделать, разработчики выбираютнеправильный подход к тому, как это делать. Выбираемые решения могут обеспечиватьлишь некоторые из требуемых свойств, они могут хорошо подходить для данной задачи втеории, но плохо работать на практике, в конкретных обстоятельствах, в которых должнобудет работать ПО.Помочь в выборе правильного решения может сопоставление альтернативных решений итщательный анализ их на предмет соответствия всем требованиям, поддержаниепостоянной связи с пользователями и заказчиками, предоставление им необходимойинформации о выбранных решениях, демонстрация прототипов, анализ пригодностивыбираемых решений для работы в том контексте, в котором они будут использоваться.• Неправильный перенос решений в код.Имея правильное решение правильно понятой задачи, люди, тем не менее, способнысделать достаточно много ошибок при воплощении этих решений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
