Тестирование ПО. Тестирование. Реферат актуальность. Основной всплеск интереса к теме тестирования пришёлся на 90е годы и начался в сша. Бурное развитие систем автоматизированной разработки
 Скачать 2.21 Mb.
|
|
Type Size Format method File system Cluster size Compression Primary 10 Quick FAT 512 On Logical 100 Slow FAT32 102 Off Single 500 NTFS 2048 Span 1000 4096 Stripe 5000 8192 Mirror 10000 16384 RAID-5 40000 32768 65536 Существует больше 4700 комбинаций этих значений. Будет очень сложно протестировать их за разумное время. Исследования показывают, что тестирование всех пар возможных значений обеспечивает очень хорошее покрытие и количество тест кейсов остается в пределах разумного. К примеру, {Primary, FAT} это одна пара и {10, slow} другая; один тест кейс может покрывать много пар. Запускается PICT из командной строки, как показано на рисунке 10.11. Рисунок 10.11 - Запуск PICT На вход программа принимает простой текстовый файл с параметрами и их значениями, называемый Моделью, а на выход выдает сгенерированные тестовые сценарии. Рассмотрим работу программы на примере. Имеем следующие параметры и их значения, таблица 10.7. Таблица 10.7 - Параметры и их значения для PICT Пол Возраст Наличие детей Мужской До 25 Да Женский От 25 до 60 Нет Более 60 Если перебирать все возможные значения, то количество сценариев будет 12. Составим модель и посмотрим какой результат выдаст программа. Для этого создается текстовый файл, в 66 котором указывается параметры и их значения. Содержимое текстового файла выглядит следующим образом: SEX: Male, Female Age: Under 25, 25-60, Older than 60 Children: Yes, No Где: sex, Age, Children - это название параметров; maile, Female, Under 25 и т.п. - это значения параметров, которые указываются через зяпятую. Чтобы PICT получила результат в командной строке нужно написать "pict" и путь к модели. Используя модель и получится 6 тестовых сценариев, вместо 12, изображенные на рисунке 10.12. Рисунок 10.12 - Набор тест кейсов Можно использовать прямой вывод и сохранение тест кейсов в Excel, рисунок 10.13. Рисунок 10.13 - Сохранение результат в Excel-файл В результате будет создан Excel файл со следующим содержанием, рисунок 10.14. Рисунок 10.14 - Результат сформированный в Excel Если рассмотреть решение первого примера в данной главе, то PICT получит 60 тестовых сценариев, против 4700 при полном переборе, изображенный на рисунке 10.15. 67 Рисунок 10.15 - Результат при полном переборе 68 На рисунке 10.16 изображен результат, полученный в программе PICT для DVD. Рисунок 10.16 - Результат для DVD в PICT Итого 15 сценариев против 17 у Allpairs. Это значит, что в данном примере PICT способен сгенерировать меньшее количество сценариев, чем Allpairs, при одинаковом покрытии. Дополнительные возможности PICT: можно указывать порядок группировки значений. По умолчанию используется порядок 2 и создаются комбинации пар значений (что и составляет попарное тестирование). Но можно указать к примеру 3 и тогда будут использоваться триплеты, а не пары. Максимальный порядок для простой модели равен количеству параметров, что создаст набор всевозможных вариантов; можно группировать параметры в подмодели и указывать им отдельный порядок для комбинаций. Это необходимо, если комбинации определенных параметров должны быть протестированы более тщательно или должны быть объединены по отдельности от других параметров; можно создавать условия и ограничения. К примеру, можно указать, что один из параметров будет принимать определенное значение только тогда, когда несколько других параметров примут нужные значения. Это позволяет отсечь создание ненужных проверок; можно обозначать невалидные значения для параметров, для создания комбинации, для негативных тест кейсов; используя весовые коэффициенты можно указать программе отдавать предпочтения определенным значениям при генерации комбинаций; можно использовать опцию минимизации (запускать программу несколько раз с этой опцией), чтобы получить минимальное количество тест кейсов. 69 11 АВТОМАТИЗАЦИЯ. НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ 11.1 Терминология нагрузочного тестирования Чтобы обсуждать подходы к нагрузочному тестированию и проблемы, решаемые с его помощью, нужно начать с основ - терминологии [9]. 1) виртуальный пользователь (Virtual User) - программный процесс, циклически выполняющий моделируемые операции. Пример - простой пользователь, который хочет воспользоваться системой; 2) итерация (Iteration) – это один повтор выполняемой в цикле операции. Пример итерации - вход в систему -> проведение анализа -> получение результата анализа - > выход из системы; 3) интенсивность выполнения операции (Operation Intensity) - частота выполнения операции в единицу времени, в тестовом скрипте задается интервалом времени между итерациями. Пример - 3 пользователя, которые входят в систему через минуту, после того, как зашел предыдущий пользователь; 4) нагрузка (Loading) - совокупное выполнение операций на общем ресурсе. Пример - общее количество выполненных операций в системе тремя пользователями за определенный промежуток времени; 5) производительность (Performance) - количество выполняемых операций за период времени. Если система не может выполнить определенной количество операций за заданный период времени, то она начинает тормозить, что означает нехватку производительности; 6) масштабируемость приложения (Application Scalability) - пропорциональный рост производительности при увеличении нагрузки; 7) профиль нагрузки (Performance Profile) - это набор операций с заданными интенсивностями, полученный на основе сбора статистических данных либо определенный путем анализа требований к тестируемой системе. Также называется сценарием (скриптом); 8) нагрузочной точкой называется рассчитанное (либо заданное Заказчиком) количество виртуальных пользователей в группах, выполняющих операции с определенными интенсивностями. Нужно рассмотреть как эти сущности связаны между собой. Выразив интенсивность через интервал времени между итерациями, можно увидеть, что рост интенсивности выполняемых операций это сокращение интервала времени. Рост нагрузки пропорционален росту интенсивности. Также, что при увеличении интенсивности растет производительность. При этом увеличивается степень использования (загруженности) ресурсов. С какого-то момента рост производительности 70 прекращается (а нагрузка может продолжать расти), происходит насыщение и затем деградация системы. В дополнение можно заметить что при тестировании изменение интенсивности операций может подчиняться какому либо закону (например, Пуассона) либо быть равномерным в течении всего теста. 11.2 Цели нагрузочного тестирования Основными целями нагрузочного тестирования являются: оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию; оценка производительности и работоспособности приложения на этапе выпуска новых релизов, патчей; оптимизация производительности приложения, включая настройки серверов и оптимизацию кода; подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера. Нужно знать, что в рамках одной цели могут использоваться разные виды нагрузочного тестирования, например, для первой, второй и третьей цели нужно производить как тестирование производительности так и тестирование стабильности. Но при планировании нагрузочного тестирования логичнее все же отталкиваться от технических целей (а не коммерческих, перечисленных выше), которые достигаются в результате тестирования и классифицировать тесты по ним: если интересует исследование производительности приложения, а именно время отклика для операций на разных нагрузках в довольно широких диапазонах, включая стрессовые нагрузки, то это тестирование производительности; если целью является понимание насколько приложение устойчиво в режиме длительного использования (исключение утечек памяти, некорректных конфигурационных настроек и т.д.) то проводится долгий нагрузочный тест - это тестирование стабильности. При этом анализ времен отклика может иметь место, но не быть первым приоритетом, главное чтобы система "не упала"; стресс тестирование имеет своей целью проверить возвращается ли система после запредельной нагрузки (и как скоро) к нормальному режиму, также целями стрессового тестирования могут быть проверки поведения системы в случаях, когда один из серверов приложения в пуле перестаёт работать, аварийно изменилась аппаратная конфигурации сервера базы данных и т.д. Нужно отметить также, что при 71 стрессовом тестировании проверяется не производительность системы, а её способность к регенерации после сверх нагрузки. Главное понимать цели того или иного тестирования и постараться их достигнуть. 11.3 Этапы проведения нагрузочного тестирования Рассматривая этапы проведения нагрузочного тестирования, хотелось бы отметить следующие: 1) анализ требований и сбор информации о тестируемой системе; 2) конфигурация тестового стенда для нагрузочного тестирования; 3) разработка модели нагрузки; 4) выбор инструмента для нагрузочного тестирования; 5) создание и отладка тестовых скриптов; 6) проведение тестирования; 7) анализ результатов; 8) подготовка, отправка и публикация отчета по проведенному нагрузочному тестированию. 11.3.1 Анализ требования и сбор информации о тестируемой системе При анализе требований основной упор необходимо сделать на определение основных критериев успешности проведенных тестов. Для этого необходимо будет выделить следующие характеристики: время отклика (время необходимое для открытия страницы или получения ожидаемого результата); интенсивность (число запросов в секунду); используемые ресурсы (загрузка процессора, кол-во используемой памяти, дисковое и сетевой I/O и т.д.); максимальное количество пользователей (определяет число пользователей, способных работать с системой в условиях заданной конфигурации). Заданные в требованиях характеристики, будут являться базовыми нагрузочными точками тестируемого приложения. Все получаемые результаты будут сравниваться с ними для принятия решения о завершении тестирования либо дальнейшем профилировании производительности. Примечение: основной проблемой при анализе требований будет являться их отсутствие. В связи с тем, что не всегда бизнес аналитики или люди ответственные за написание требований по производительности реально представляют как система должна работать под 72 нагрузкой, какие именно требования должны быть предоставлены, очень часто цифры берутся просто «с потолка», поэтому приходится не только выделять имеющиеся требования, но и проводить их глубокий анализ на предмет их корректности; характеристика "Максимальное количество пользователей" на самом деле является малоинформативной, в случае если для тестирования необходимо будет работать с несколькими группами пользователей. Поэтому крайне важно будет знать более менее точное количество пользователей в каждой группе. 11.3.2 Анализ требований в зависимости от типа проекта При анализе требований необходимо учесть разрабатывается ли новое (startup project) или же проект направлен на профилирование нагрузки для уже находящегося в эксплуатации приложения (profiling project). В зависимости от типа проекта разрабатываются требования по производительности. Для startup проектов: анализ общепринятых критериев производительности; анализ производительности конкурирующих приложений; анализ экспертного мнения разработчиков, системных и сетевых администраторов, администраторов баз данных и инженеров по нагрузочному тестированию; анализ ожиданий целевых пользователей (групп пользователей). Для profiling проектов: анализ общепринятых критериев производительности; анализ производительности конкурирующих приложений; анализ производительности эксплуатируемой версии приложения, с целью определения требующих профилирования функций, процессов, операций и т.д; анализ экспертного мнения разработчиков, системных администраторов и администраторов баз данных, инженеров по нагрузочному тестированию; анализ мнения целевых пользователей (групп пользователей). И уже после получения всех данных из всех источников можно получить более менее точные требования по производительности для тестируемого приложения. 11.3.3 Конфигурация тестового стенда для нагрузочного тестирования На результаты нагрузочного тестирования могут влиять разные факторы, такие как конфигурация тестового стенда, загруженность сети, заполненность базы данных и многие другие. Причем влияние их на производительность приложения может быть значительным и иметь нелинейную зависимость, поэтому выразить её формулой будет практически невозможно. 73 Следовательно, чем меньше будут разниться параметры тестовой и реальной инфраструктуры, тем меньше будет погрешность в полученных результатах. Нужно отметить те части конфигурации, которые требуют особого внимания: Hardware: процессор (тип, частота, количество ядер и т.д); оперативная память (тип, объем, тайминг, эффективная частота и т.д.); жесткие диски (тип, скорость и т.д.). Software: операционная система; драйвера. Network: топология сети; пропускная способность; протокол передачи данных. Application: архитектура; база данных (структура + данные); программное обеспечение, необходимое для работы приложения (например, для Java приложений - JVM). В самом идеальном случае тестовый стенд один к одному дублирует конфигурацию реального сервера, на котором работает или же будет работать приложение. Однако, идеальных случаев практически не бывает (то памяти мало, то процессора такой частоты нет в наличии, то операционная система не той версии, то стоимость некоторого серверного ПО не укладывается в бюджете). Перечислим основные причины, по которым не всегда получается продублировать конфигурацию системы на тестовом стенде: 1) сложность дублирования дорогого серверного железа для тестовых нужд; 2) ограничения на использование лицензий требуемого программного обеспечения; 3) закрытость архитектуры приложения со стороны заказчика по соображениям безопасности; 4) трудность воссоздания или транспортировки базы данных приложения; 5) сложность воссоздания требуемой архитектуры сети; 6) и многое другое (всё перечислить крайне сложно из-за большого количества нюансов, влияющих на конфигурацию системы). Целесообразность же воссоздания инфраструктуры необходимо оценить с учетом выделенных ресурсов, времени и усилий, так как не всегда результат будет оправдывать средства. 74 11.3.4 Разработка модели нагрузки Определившись с видами нагрузочного тестирования, целями и терминологией, нужно перейти к основной задаче нагрузочного тестировании - разработке модели нагрузки. Для этого необходимо определить следующее: список тестируемых операций; интенсивность выполнения операций; зависимость изменения интенсивности выполнения операций от времени. В список тестируемых задач должны войти операции, критичные с точки зрения бизнеса, а также с технической точки зрения: критичными с точки зрения бизнеса являются операции, скорость выполнения которых, реально влияет на производительность бизнес процесса. Например, увеличение длительности обслуживания клиентов в банке, невозможность выполнения необходимого количества операций в течение дня и так далее; критичными с технической точки зрения являются ресурсоемкие операции, требующие большое количество памяти, серьезно задействующие процессор, создающие значительный сетевой трафик. Как правило, это операции выполняемые одновременно большим количеством бизнес пользователей или создание сложных отчетов, в которые входят так называемые "тяжелые" запросы к базе данных; Нужно подчеркнуть, что под степенью критичности операции подразумевается её влияние на бизнес процесс и работоспособность системы. Например, создание какого-нибудь отчета, полностью загружающего сервер базы данных в ночное время, не будет носить высокий приоритет для оптимизации, а в рабочие часы будет иметь максимальный приоритет. Модель тестирования производительности Постепенное увеличение нагрузки, добавляя новых пользователей с некоторым интервалом времени, позволяет определить: измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций; количество пользователей, способных одновременно работать с приложением; границы приемлемой производительности при увеличении нагрузки; производительность при разных нагрузках. 75 Модель стрессового тестирования Увеличивая интенсивность операций выше пиковых (максимально разрешенных) значений, либо увеличивая количество пользователей до тех пор, пока нагрузка не станет выше максимально допустимых значений, проверяем, что система работоспособна в условиях стресса. Далее, опустив нагрузку до средних значений, проверяем (способность системы к регенерации), что система вернулась к нормальному состоянию (основные нагрузочные характеристики не превышают базовые). Модель объемного тестирования Можно использовать ту же модель что и для тестирования производительности, однако целью будет проверка работы системы с прогнозом на будущий рост объема данных. Следовательно, одним и самым важным предусловием теста будет увеличение объемов базы данных приложения до требуемых размеров. Таким образом можно проверить и оценить производительность, прогнозируя рост системы на год, два или три вперед. |