1
4.9

Оценить

Статьи 4.9 11 голосов 1599

Тестирование производительности приложений. Часть 1

Тестирование. Качество

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

Тестирование — это оценка поведения системы с целью определения отличий между реальным и ожидаемым поведением системы.

Целей тестирования несколько: находить баги во время процесса подтверждения того, что ПО соответствует заявленным требованиям и во время проведения негативных сценариев, цель которых проверить нештатное поведение системы.

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

Если с определением требований дело обстоит чуть проще: есть прямые и косвенные требования, есть различные пути выработки требований, то вопрос качества достаточно сложен и неоднозначен.

Цитируя Уильям Деминга, специалиста в области менеджмента качества; консультанта крупных американских и японских компаний в области управления качеством: «Проблема, присущая попыткам определить качество продукта, практически любого продукта, была изложена мастером Уолтером Шухартом (всемирно известный американский ученый и консультант по теории управления качеством (прим. ред.)). Сложность в определении качества заключается в том, чтобы преобразовать будущие потребности пользователя в измеримые характеристики, чтобы продукт мог быть спроектирован и получен таким образом, чтобы удовлетворять по цене, которую заплатит пользователь. Это непросто, и как только человек чувствует себя довольно успешным в этом начинании, он обнаруживает, что потребности потребителя изменились, появились конкуренты и т. д.»

Исходя из слов ученых, которые посвятили вопросу качества не один десяток лет, можем дать определение качеству. Качество — это набор характеристик, которыми должен обладать продукт, чтобы удовлетворять потребностям конечного потребителя.

Существуют организации, разрабатывающие стандарты в разных сферах деятельности, в том числе и в вопросах качества. Одними из таких являются: ISO (Международная организация по стандартизации) и IEC (Международная электротехническая комиссия).

В далеком 1991 году, 19 декабря появился стандарт ISO/IEC 9126, который называется: «Разработка программного обеспечения. Качество продукции». Целью данного стандарта была попытка определить измеримые характеристики качества, для управления ими.

Было выделено 6 верхнеуровневых характеристик качества с подхарактеристиками на каждом уровне. Характеристики верхнего уровня по стандарту ISO/IEC 9126:

  • функциональность;
  • надежность;
  • эффективность;
  • удобство использования;
  • удобство сопровождения;
  • портативность.

Спустя годы, стандарт ISO/IEC 9126 был обновлен в 2011 году и теперь имеет название ISO/IEC 25010: «Разработка систем и программного обеспечения. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения».

В обновленной версии стандарта были выделены и дополнены характеристики качества, теперь их 8:

  • функциональность;
  • надежность;
  • производительность;
  • защищенность;
  • переносимость;
  • сопровождаемость;
  • совместимость;
  • удобство использования.

Производительность

Из всех характеристик нас интересует только одна характеристика качества верхнего уровня — это производительность. Производительность включает в себя еще несколько подхарактеристик:

  • Временные характеристики (время выполнения операций)
  • Характеристики использования ресурсов (физический софт)
  • Характеристики потенциальных возможностей систем (запас мощности).

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

С другой стороны у нас есть физический сервер и база данных, с процессором, оперативной памятью, жестким диском. И они подключены к интернет-сети, к локальной или глобальной, которая имеет свою пропускную способность для передачи данных — это характеристики использования ресурсов.

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

Современные веб-приложения могут состоять из трех частей: базы данных, сервера приложения и веб-сервера. Сервер приложения хранит в себе непосредственно логику приложения. А веб-сервер занимается функциями управления статическим контентом — css, js, изображения и другими файлами. Эти три компонента могут находиться на разных компьютерах или даже на разных дата-центрах, располагающихся в разных регионах.

В данном случае со стороны разработки мы можем управлять структурой системы и компонентами, из которых она состоит, а вот внешние системы усложняют процесс тестирования. Во внешних системах конечные пользователи могут использовать различные типы устройств, как показано на картинке выше. Эти устройства подключены к сервис-провайдерам. Здесь могут быть разные типы интернет-соединений: оптоволокно, телефония и мобильный интернет. Локальные провайдеры пользуются услугами более крупных провайдеров, которые обеспечивают доступ к нашему приложению.

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

Решения для такой ситуации два: либо выполнять тест с точки зрения конечного пользователя, либо обеспечить запас мощности на производительность нашему приложению для компенсации на промежуточные звенья. Главный вопрос — будет ли данная сложная система работать быстро с точки зрения конечного пользователя?

Продолжение статьи можно прочитать в нашем блоге.

Похожие материалы

Подпишитесь на рассылку
Компьютерной школы Hillel

Вы получите:

  • Информацию о полезных отраслевых мероприятиях
  • Интересные статьи IT-сферы
  • Новости Компьютерной школы Hillel