 |
Особенности тестирования ООПО
|
|
|
|
Объектно-ориентированные возможности в языках программирования оказывают влияние на некоторые аспекты тестирования. Такие особенности, как наследование и интерфейсы, поддерживают полиморфизм, по условиям которого программа манипулирует объектами таким образом, что класс, которому они принадлежат, неизвестен. Специалисты, осуществляющие тестирование, должны сделать так, чтобы программы работали независимо оттого, что представляет собой класс, к которому принадлежат эти объекты. Средства языка, которые поддерживают и вынуждают сокрытие данных, способны усложнить тестирование, поскольку некоторые операции время от времени должны быть включены в интерфейс класса специально для целей тестирования. С другой стороны, наличие таких средств позволяет улучшить качество тестирующих программ и обеспечить их повторное использование.
Различия между старыми и новыми методами разработки и тестирования ПО намного глубже, нежели выбор в качестве базового понятия объекта вместо функции. Основное различие заключается в том, что объектно-ориентированное программное обеспечение (ООПО) разрабатывается в виде набора объектов, которые по сути дела моделируют задачу и взаимодействуют между собой в целях ее решения. В основе такого подхода лежит принцип, согласно которому решение задачи может со временем претерпевать изменения, и в то же время структура и компоненты задачи не меняются столь же часто. Поскольку компоненты были получены в соответствии с потребностями задачи, они могут быть повторно использованы при разработке других программных решений.
Большая польза от такого подхода к проектированию заключается в том, что аналитические модели непосредственно отражаются на проектные модели, а те в свою очередь отображаются на программы. Следовательно, можно начинать тестирование на стадии анализа и доводить его до уровня проектного тестирования. Это означает, что процесс тестирования может переплетаться с процессом разработки.
|
|
|
Можно отметить три существенных применения преимуществ моделей анализа и проектирования с элементами тестирования [4,c.21]:
1. Контрольные тесты могут определяться на ранних стадиях процесса разработки, даже на стадии определения требований. Раннее тестирование позволяет аналитикам и проектировщикам лучше понимать и четко формулировать требования.
2. Программные ошибки могут быть обнаружены на ранних стадиях процесса разработки, тем самым позволяя экономить деньги, время и усилия. Известно, что чем раньше проблема обнаружена, тем проще и дешевле ее исправить.
3. Тесты можно проверить на предмет правильности уже на ранних стадиях проекта. Если тесты разработаны заранее и применены к моделям на ранней стадии проекта, то все случаи неправильного понимания требований со стороны тестировщиков, могут быть исправлены на ранних этапах. Тестирование моделей помогает добиться того, чтобы тестировщики и разработчики имели согласованное понимание системных требований.
Другое различие между традиционными проектами и проектами с использованием объектно-ориентированных технологий, касается целей программного обеспечения. Новой важной целью для многих компаний является производство программных продуктов многократного использования, расширяемых систем и компонент распределенных систем. Тестирование может выявить их неспособность соответствовать этим целям, чего не могут гарантировать традиционные подходы.
Контрольные вопросы:
1) В чем состоит стратегия тестирования модулей?
|
|
|
2) Перечислите способы проверки взаимодействия модулей.
3) Какими свойствами обладает пошаговое тестирование?
4) Как осуществляется тестирование структуры модуля?
5) Какие существуют математические показатели корректности структуры модуля?
Лекция 7. Отладка
Цель: рассмотреть методы отладки программного обеспечения и их особенности.
Определение и особенности процесса отладки
Отладкой можно назвать процесс, осуществляемый после прохождения тестов. Он проводится в два этапа: сначала определяется местонахождение ошибки в программе, а затем эта ошибка исправляется.
Существуют характерные особенности, присущие отладке, как одному из этапов разработки ПО. К ним можно отнести:
- психологическая трудность для разработчиков из-за самого факта наличия ошибки в программе;
- требования максимальных усилий и интеллектуальных затрат разработчиков, поскольку возникает желание как можно быстрее найти и исправить ошибку;
- процесс отладки недостаточно формализован.
Рассмотрим наиболее часто применяющиеся при отладке методы: «грубой силы», индукции, дедукции.
Метод «грубой силы»
Этот метод не требует слишком много внимания и умственных затрат, поэтому применяется довольно часто. При данном методе могут использоваться:
1) отладка с использованием дампа памяти;
2) постановка операторов печати после каждой строки программы;
3) использование автоматических средств.
Если рассматривать отладку с использованием дампа памяти, то она заключается в анализе значений, располагающихся в ОЗУ начиная с некоторого адреса. Если знать содержимое памяти при корректной работе программы, то такой метод принесет положительный эффект. Однако таким способом можно обнаружить неверные данные, а вот установить причину их появления там не всегда возможно. Кроме того, дамп памяти отражает лишь одно состояние программы и не раскрывает динамики ее выполнения.
Наиболее часто для отладки используют операторы вывода, располагая их в контрольных точках программы. После выполнения программы до очередной контрольной точки известны значения переменных, результаты операций и т.п. Эти значения можно вывести на экран, принтер или в файл, так чтобы человек мог с ними ознакомиться. Если выводимые значения содержат неожиданные данные, то текст программы для дальнейшего анализа можно сузить до области, предшествующей данной контрольной точке. Недостатки данного подхода заключаются в следующем:
|
|
|
1) Расстановка операторов вывода заставляет программиста работать в режиме проб и ошибок, отвлекая от размышления над задачей.
2) Число анализируемых данных может оказаться очень большим.
3) Требуется вносить изменения прямо в текст программы и заново собирать исполняемый модуль.
Можно рекомендовать данный подход при относительно небольших размерах программ и программ, написанных на языках высокого уровня. Он неприемлем для очень больших проектов и определенного типа программ (операционных систем, драйверов и т.п.).
Отладка с автоматическими средствами предполагает использование программ-отладчиков, позволяющих не только выполнять программу построчно, но и устанавливать контрольные точки для остановки, просматривать и модифицировать содержимое памяти, регистров процессора. При использовании символьной информации, отладчик работает с оригинальными именами функций и переменных, что ускоряет и улучшает процесс отладки.
Общей проблемой метода «грубой силы» является игнорирование процесса обдумывания, использование перебора вариантов и подозрение на каждую строку программы.
Экспериментально доказано [1,157], что средства отладки не помогают процессу отладки (это справедливо и для начинающих и для опытных программистов) и бесцельные прогоны программы под отладчиком неэффективны по сравнению с вдумчивым подходом.
Индуктивный метод
Индуктивный анализ означает движение от частного к целому. При этом, просматривая симптомы ошибки и взаимосвязи между ними, часто можно придти к ошибке.
Процесс индукции разбивается на следующие шаги:
1) Определение данных, имеющих отношение к ошибке.
2) Организация данных.
3) Выдвижение гипотезы.
4) Доказательство или опровержение гипотезы.
|
|
|
Основная ошибка, встречающаяся в плохо организованной отладке программы, заключается в том, что рассматриваются все имеющиеся данные. Первым шагом индуктивного метода должно быть перечисление всех действий, свидетельствующих о правильном выполнении программы и всех ее неправильных действий.
Второй шаг заключается в структурировании данных, имеющих отношение к ошибке, с целью выявления некоторых закономерностей. Особую важность имеет исследование на противоречивость, то есть когда ошибка проявляется при правильных входных значениях и отсутствует при вводе неправильных.
Для изучения взаимосвязи между признаками ошибки выдвигаются гипотезы о ее причинах. Если гипотезы нельзя выдвинуть, то необходимы дополнительные данные (а для этого могут потребоваться дополнительные тесты).
Гипотеза доказывается путем сравнения ее с первоначальными симптомами ошибки или данными. Она должна полностью объяснить существование этих симптомов. Если такое объяснение получить не удается, то или гипотеза не полна, либо не верна.
Дедуктивный метод
Процесс дедукции позволяет на основании некоторых общих теорий и предпосылок, используя операции исключения и уточнения, придти к определенному заключению, то есть обнаружить место ошибки. Он состоит из следующих этапов:
1) Перечисление возможных причин и гипотез.
2) Использование данных для исключения возможных причин.
3) Уточнение выбранной гипотезы.
4) Доказательство выбранной гипотезы.
Первый шаг заключается в разработке списка всех возможных причин ошибки. Эти причины могут являться только версиями, с помощью которых можно структурировать и анализировать имеющиеся в распоряжении данные. Далее, путем тщательного анализа данных исключаются все возможные причины, кроме одной. Если исключить все причины, то потребуются дополнительные данные (например, за счет дополнительных тестов) для выдвижения новых гипотез. Если же остается более чем одна причина, то первой выбирается наиболее вероятная из них.
Возможная причина может быть определена верно, но она может недостаточно полно отражать специфику ошибки. Поэтому следующим шагом должно быть использование доступных данных для уточнения гипотезы (например, ошибка при обращении к последней записи файла) с учетом некоторой специфики (например, последняя запись в буфере затирает признак конца файла).
Принципы отладки
Подобно основным принципам тестирования, приведенных в лекции 2, перечислим принципы отладки, опираясь на материал Г. Майерса [1,с.167].
Думайте.
Отладка представляет собой процесс решения задач. Наиболее эффективный метод отладки заключается в анализе информации, связанной с симптомами ошибок. Для ее эффективного проведения специалист должен обладать способностью, точно определять большинство ошибок без использования компьютера.
|
|
|
