Статья 2 Investigation of Methods for Testing AspectOriented Software Исследование методов для аспекта тестирования ориентированное программное обеспечение


Тестирование программного обеспечения



Скачать 65.55 Kb.
страница6/24
Дата23.06.2022
Размер65.55 Kb.
#130952
ТипСтатья
1   2   3   4   5   6   7   8   9   ...   24
Статья 2-Исследование методов аспекта тестирования (9000 слов) (1-4 главы)

Тестирование программного обеспечения


Тестирование программного обеспечения имеет важное значение для обеспечения качества программного обеспечения. На тестирование в большинстве программных проектов уходит не менее 30 процентов проектных усилий. Тестирование программного обеспечения может потреблять от 50 до 80 процентов проектных усилий в критически важных для безопасности приложениях (Коллофелло и Вехатири, 2005). Несмотря на то, что это дорогостоящий и трудоемкий процесс, тестирование программного обеспечения имеет важное значение для производства высококачественного
продукта (Коллофелло и Вехатири, 2005). Существует множество исследователей, которые по-разному определяют тестирование программного обеспечения. Согласно Линдстрему (2000), тестирование — это процесс выполнения системы с целью поиска неисправностей и повышения доверия к системе. Однако это никогда не может доказать правильность системы. Как мы знаем 12100% тестирование невозможно. Исследователи все еще экспериментируют, чтобы найти методы тестирования, которые охватывают большинство возможных неисправностей для конкретной системы, и это способ повысить доверие к системе. Поэтому приведенное выше определение, по-видимому, дает лучшее представление о тестировании программного обеспечения.
Тестирование программного обеспечения должно выявить ошибки. Многие ошибки — это распространяющиеся ошибки проектирования. Вставка неверного ввода оператором также известна как ошибка. Ошибка также является ошибкой статической реализации, допущенной программистом. Если выполнение достигает сбоя, оно может перейти в неправильное внутреннее состояние, которое является ошибкой. Такая ошибка может привести к внешнему неправильному поведению, что называется сбоем. Тестовые примеры должны обеспечивать четкую обратную связь, чтобы выявленные ошибки можно было легко исправить (Ammann & Offutt 2008, Beizer 1990).

public int findMax (int[] y)


// Effects: If y==null throw NullPointerException
// else return the biggest element in y.
{
int x=y[y.length-1];
for (int i=y.length-1; i > 0; i--)
{
if (y[i] > x)
{
x=y[i];
}
}
return x;
}
Figure 4: Example of presence of fault in a small function (from course lecture)
На рисунке 4 мы видим небольшую функцию, которая находит максимальное значение из входного массива. В операторе “для” есть ошибка, которая равна i > 0. Для этого условия он не может проверить первый элемент. Но массив должен быть проверен от последнего элемента до первого элемента. Ошибка заключается в условии i>0. Правильным выражением должно было быть i==0. Было бы исключение, если входной сигнал равен нулю. Выполнение не достигает ошибки, если входные данные равны нулю. Таким образом, ошибка не инициируется входным сигналом. Таким образом, выполнение не достигает состояния ошибки и сбоя не происходит. Если мы дадим входной массив типа [2,4,6,8]. В результате будет 8. В этом случае выполнение достигает ошибки, но это не приведет к сбою. Функция выдаст правильный вывод, поскольку максимальное значение находится не в первой позиции. Когда мы дадим входной массив типа [8,6,4,2], результат будет равен 6. Функция не проверила первый элемент. Мы наблюдаем здесь неправильное поведение. В этом случае выполнение достигает ошибки, также достигается стадия ошибки и наблюдается сбой.
Тестируемость — это аспект качества программного обеспечения, который очень трудно оценить. Хотя это важно для тестировщиков и качества системы, тестировщики редко обладают этими знаниями. Тестируемость показывает вероятность того, что программное обеспечение выйдет из строя при следующем выполнении во время тестирования, если программное обеспечение содержит ошибку. Тестируемость также отражает сценарий того, насколько вероятно, что тестирование выявит ошибку. Поэтому, когда инженер-программист находит программный артефакт с низкой проверяемостью, он/она уже становится известно, что само по себе тестирование вряд ли приведет к удовлетворительной проверке, и требуется альтернативная проверка. Инженер-тестировщик также может попытаться улучшить тестируемость программного артефакта, что является вопросом дизайна (Ammann & Offutt, 2008, стр. 284). Следовательно, в проектировании должен участвовать тестировщик. Проблема тестируемости была сформулирована с точки зрения управляемости и наблюдаемости, которые исходят из тестирования оборудования. Фридман (1991) и Биндер (1994) адаптировали условие тестируемости при тестировании программного обеспечения.
Чтобы отличить правильное поведение программного обеспечения от ошибочного, необходимо наблюдать, почему, когда и что делает программное обеспечение. Наблюдаемость указывает на возможность наблюдения как за внутренним, так и за внешним поведением во время выполнения теста. Поведение программного обеспечения можно оценить, если оно соблюдается должным образом. Однако программное обеспечение должно облегчать такое наблюдение, то есть оно должно быть наблюдаемым (Schütz 1994). Наблюдаемость позволяет узнать об инцидентах, связанных с программным обеспечением, когда оно выполняется. Наблюдаемость указывает на способность наблюдать за тем, что происходит в программном
обеспечении во время выполнения.
Управляемость программным обеспечением показывает, насколько легко обеспечить программу необходимыми входными данными с точки зрения значений, операторов и поведения (Ammann & Offutt, 2008, стр. 14). Другое свойство, известное как воспроизводимость, связано со свойством управляемости. Управляемость — это свойство. Управляемость — это степень, в которой система позволяет тестировщику контролировать выполнение тестов. Управляемость показывает, насколько большое влияние на программное обеспечение оказывает тестировщик при выполнении тестовых случаев. Воспроизводимость указывает на то, что поведение программного обеспечения останется неизменным при выполнении одних и тех же тестовых примеров. В противном случае мы не сможем быть уверены в ошибке, которая является причиной сбоя. Таким образом, воспроизводимость — это часть управляемости.
На рисунке 5 показаны три необходимых условия для наблюдения сбоя. Существуют различные подходы к решению проблемы тестируемости. Мы уже знакомы с моделью тестируемости, построенной на неисправностях, ошибках и сбоях. В качестве ключевых компонентов тестируемости некоторые авторы сосредоточили внимание на наблюдаемости программного обеспечения и управляемости программным обеспечением. RIP-модель была представлена Джеффри Воасом в 1995 году, где он определил тестируемость с точки зрения трех атрибутов: способности к охвату, инфекции и размножению. На рисунке 5 показана модель RIP. Если мы увидим небольшой пример функции на рис.4, мы обнаружим, что reach указывает на то, что выполнение функции должно привести к ошибке. Ошибка отражает неверное утверждение. Таким образом, выполнение заражается, что также приводит к неправильному выводу.
Достаточность тестов для тестируемой программы также является важным фактором при тестировании. Чтобы повысить уверенность при тестировании, тестовые примеры должны тестировать достаточное количество частей программа. Критерии охвата определяют достаточность. Критерии покрытия используются для определения того, какие входные данные теста использовать, потому что мы не можем тестировать со всеми входными данными. Таким образом, эффективное использование критериев охвата делает тестирование также эффективным и обеспечивает неформальную уверенность в том, что программное обеспечение является высококачественным и надежным. Критерии покрытия также показывают, когда следует прекратить тестирование.
Неотъемлемой частью любого жизнеспособного процесса разработки программного обеспечения является регрессионное тестирование. Регрессионное тестирование означает повторное тестирование модифицированного программного обеспечения, что составляет подавляющее большинство усилий по тестированию при разработке коммерческого программного обеспечения. В большинстве случаев любое небольшое изменение в программном обеспечении может повлиять на значительную часть системы. Регрессионное тестирование используется для проверки того, что изменение не приводит к какой-либо новой проблеме (т. Е. Все тесты, прошедшие до изменения, должны пройти после него.) Тестирование программного обеспечения отражает только наличие ошибок, а не отсутствие ошибок (Даль и др., 1972).



Скачать 65.55 Kb.

Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   24




База данных защищена авторским правом ©vossta.ru 2022
обратиться к администрации

    Главная страница