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

Обеспечение качества функционирования компьютерных систем-psihdo. Обеспечение качества функционирования компьютерных систем Опорный конспект лекций


Скачать 478.49 Kb.
НазваниеОбеспечение качества функционирования компьютерных систем Опорный конспект лекций
Дата09.03.2023
Размер478.49 Kb.
Формат файлаdoc
Имя файлаОбеспечение качества функционирования компьютерных систем-psihdo.doc
ТипКонспект
#977765
страница11 из 11
1   2   3   4   5   6   7   8   9   10   11

Тесты производительности

Тесты производительности


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

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

Дымовое тестирование (Smoke testing)

Дымовое тестирование (Smoke testing)


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

Как автоматизировать тесты

Как автоматизировать тесты


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

§  Машина может с легкостью воспроизводить эти же действия и повторять в сотый раз без каких-либо нареканий цикл проверки.

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

§  PHPUnit , Mocha, RSpec – это примеры фреймворков для тестирования, которые можно использовать для PHP, Javascript и Ruby, соответственно. В них есть множество возможностей для каждого языка, поэтому решение принимает тестировщик.

§  Если ваши тесты могут запускаться с помощью скриптов из терминала, вы можете автоматизировать их, использовав сервер непрерывной интеграции по типу Bamboo или облачного сервера Bitbucket Pipelines. Эти инструменты будут мониторить ваши репозитории и исполнять наборы тестов, как только новые изменения будут запушены в основной репозиторий.

Исследовательское тестирование

Исследовательское тестирование


§  Чем больше функций и улучшений добавляется в код программы, тем больше возрастает потребность в тестировании, поскольку на каждом этапе вам необходимо убеждаться, что система работает корректно. Также это понадобится каждый раз, когда исправляете баг, поскольку было бы не лишним убедиться, что он не вернется снова после нескольких релизов.

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

Первичные ошибки, вторичные ошибки и их проявления


§  Рассмотрим классификацию ошибок по месту их возникновения.

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

§  Недостатки программы зависят от субъективной оценки ее качества потенциальным пользователем.

§  Преодоление недостатков программы, особенно на заключительном этапе проектирования, может приводить к снижению надежности.

Проблемы наличия ошибок в спецификациях, субъективного оценивания пользователем качества программы существуют и не могут быть проигнорированы.


§  Проблемы наличия ошибок в спецификациях, субъективного оценивания пользователем качества программы существуют и не могут быть проигнорированы.

§  Для ПО все проблемы, связанные с субъективным оцениванием их качества и наличием ошибок, скорее всего неизбежны.

§  В краткой классификации выделяются следующие ошибки.

§  - Ошибки пользовательского интерфейса.

§  - Ошибки вычислений.

§  - Ошибки управления потоком.

§  - Ошибки передачи или интерпретации данных.

§  - Перегрузки.

§  - Контроль версий.

§  - Ошибка выявлена и забыта.

§  - Ошибки тестирования.

1. Ошибки пользовательского интерфейса.

1. Ошибки пользовательского интерфейса.


§  Многие из них субъективны, т.к. часто они являются скорее неудобствами, чем «чистыми» логическими ошибками. Однако они могут провоцировать ошибки пользователя программы или же замедлять время его работы до неприемлемой величины. В результате чего мы будем иметь ошибки информационной системы (ИС) в целом.

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

2. Ошибки вычислений.

2. Ошибки вычислений.


§  Выделяют следующие причины возникновения таких ошибок:

§  - неверная логика (может быть следствием, как ошибок проектирования, так и кодирования);

§  - неправильно выполняются арифметические операции (как правило - это ошибки кодирования);

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

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

3. Ошибки управления потоком.

3. Ошибки управления потоком.


§  В этот раздел относится все то, что связано с последовательностью и обстоятельствами выполнения операторов программы.

§  Выделяются подпункты:

§  - очевидно неверное поведение программы;

§  - переход по GOTO;

§  - логика, основанная на определении вызывающей подпрограммы;

§  - использование таблиц переходов;

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

4. Ошибки обработки или интерпретации данных.

4. Ошибки обработки или интерпретации данных.


§  Выделяются подпункты:

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

§  - границы расположения данных (сюда включены несколько видов ошибок: не обозначен конец нуль-терминированной строки, неожиданный конец строки, запись/чтение за границами структуры данных или ее элемента, чтение за пределами буфера сообщения, чтение за пределами буфера сообщения, дополнение переменных до полного слова, переполнение и выход за нижнюю границу стека данных, затирание кода или данных другого процесса);

§  - проблемы с обменом сообщений (сюда включены несколько видов ошибок: отправка сообщения не тому процессу или не в тот порт, ошибка распознавания полученного сообщения, недостающие или несинхронизированные сообщения, сообщение передано только N процессам из N+1, порча данных, хранящихся на внешнем устройстве, потеря изменений, не сохранены введенные данные, объем данных слишком велик для процесса-получателя, неудачная попытка отмены записи данных).

5. Повышенные нагрузки.

5. Повышенные нагрузки.


§  При повышенных нагрузках или нехватке ресурсов могут возникнуть дополнительные ошибки.

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

§  В этом разделе хотелось бы обратить внимание на следующее:

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

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

6. Контроль версий и идентификаторов.

6. Контроль версий и идентификаторов.


§  Выделяются подпункты:

§  таинственным образом появляются старые ошибки;

§  обновление не всех копий данных или программных файлов;

§  отсутствие заголовка;

§  отсутствие номера версии;

§  неверный номер версии в заголовке экрана;

§  отсутствующая или неверная информация об авторских правах;

§  программа, скомпилированная из архивной копии, не соответствует проданному варианту;

§  готовые диски содержат неверный код или данные.

7. Ошибки тестирования.

7. Ошибки тестирования.


§  Являются ошибками сотрудников группы тестирования, а не программы.

§  Выделяются подпункты:

§  - пропущенные ошибки в программе;

§  - не замечена проблема (отмечаются следующие причины этого: тестировщик не знает, каким должен быть правильный результат, ошибка затерялась в большом объеме выходных данных, тестировщик не ожидал такого результата теста, тестировщик устал и невнимателен, ему скучно, механизм выполнения теста настолько сложен, что тестировщик уделяет ему больше внимания, чем результатам);

§  - пропуск ошибок на экране;

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

8. Ошибка выявлена и забыта.

8. Ошибка выявлена и забыта.


§  Описываются ошибки использования результатов тестирования. Выделяются подпункты:

§  не составлен итоговый отчет;

§  серьезная проблема не документирована повторно;

§  не проверено исправление;

§  перед выпуском продукта не проанализирован список нерешенных проблем.

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

Основные пути борьбы с ошибками

Основные пути борьбы с ошибками


§  Учитывая рассмотренные особенности действий человека при переводе можно указать следующие пути борьбы с ошибками:

§  сужение пространства перебора (упрощение создаваемых систем),

§  обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),

§  обеспечение однозначности интерпретации представления информации,

§  контроль правильности перевода (включая и контроль однозначности.


http://psihdocs.ru
1   2   3   4   5   6   7   8   9   10   11


написать администратору сайта