Тестирование. Качество
Прежде, чем начать говорить о тестировании производительности, необходимо определиться с тем, что такое тестирование в целом.
Тестирование — это оценка поведения системы с целью определения отличий между реальным и ожидаемым поведением системы.
Целей тестирования несколько: находить баги во время процесса подтверждения того, что ПО соответствует заявленным требованиям и во время проведения негативных сценариев, цель которых проверить нештатное поведение системы.
Это все необходимо для того, чтобы в конечном итоге предоставить фактическую информацию о состоянии ПО, его качестве всем заинтересованным лицам — заказчикам тестирования.
Если с определением требований дело обстоит чуть проще: есть прямые и косвенные требования, есть различные пути выработки требований, то вопрос качества достаточно сложен и неоднозначен.
Цитируя Уильям Деминга, специалиста в области менеджмента качества; консультанта крупных американских и японских компаний в области управления качеством: «Проблема, присущая попыткам определить качество продукта, практически любого продукта, была изложена мастером Уолтером Шухартом (всемирно известный американский ученый и консультант по теории управления качеством (прим. ред.)). Сложность в определении качества заключается в том, чтобы преобразовать будущие потребности пользователя в измеримые характеристики, чтобы продукт мог быть спроектирован и получен таким образом, чтобы удовлетворять по цене, которую заплатит пользователь. Это непросто, и как только человек чувствует себя довольно успешным в этом начинании, он обнаруживает, что потребности потребителя изменились, появились конкуренты и т. д.»
Исходя из слов ученых, которые посвятили вопросу качества не один десяток лет, можем дать определение качеству. Качество — это набор характеристик, которыми должен обладать продукт, чтобы удовлетворять потребностям конечного потребителя.
Существуют организации, разрабатывающие стандарты в разных сферах деятельности, в том числе и в вопросах качества. Одними из таких являются: ISO (Международная организация по стандартизации) и IEC (Международная электротехническая комиссия).
В далеком 1991 году, 19 декабря появился стандарт ISO/IEC 9126, который называется: «Разработка программного обеспечения. Качество продукции». Целью данного стандарта была попытка определить измеримые характеристики качества, для управления ими.
Было выделено 6 верхнеуровневых характеристик качества с подхарактеристиками на каждом уровне. Характеристики верхнего уровня по стандарту ISO/IEC 9126:
- функциональность;
- надежность;
- эффективность;
- удобство использования;
- удобство сопровождения;
- портативность.
Спустя годы, стандарт ISO/IEC 9126 был обновлен в 2011 году и теперь имеет название ISO/IEC 25010: «Разработка систем и программного обеспечения. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения».
В обновленной версии стандарта были выделены и дополнены характеристики качества, теперь их 8:
- функциональность;
- надежность;
- производительность;
- защищенность;
- переносимость;
- сопровождаемость;
- совместимость;
- удобство использования.
Рекомендуем курс по теме
Производительность
Из всех характеристик нас интересует только одна характеристика качества верхнего уровня — это производительность. Производительность включает в себя еще несколько подхарактеристик:
- Временные характеристики (время выполнения операций)
- Характеристики использования ресурсов (физический софт)
- Характеристики потенциальных возможностей систем (запас мощности).
Если взять во внимание контекст типичного веб-приложения, мы рассматриваем работу клиент-серверной архитектуры ПО, где с одной стороны у нас тонкий клиент, на котором нет логики ПО, и он только отправляет запросы на сервер. Это могут быть браузеры, которые используют пользователи, и в этом случае пользователи заинтересованы в быстром отклике на их запросы. Быстрота отклика и будет нашей временной характеристикой.
С другой стороны у нас есть физический сервер и база данных, с процессором, оперативной памятью, жестким диском. И они подключены к интернет-сети, к локальной или глобальной, которая имеет свою пропускную способность для передачи данных — это характеристики использования ресурсов.
Третья характеристика потенциальных возможностей описывает ситуацию с изменением количества пользователей, используемых веб-приложение. Количество пользователей сложно прогнозируемая величина особенно, когда мы говорим про акции, распродажи на ресурсах в какие-то праздничные и предпраздничные дни. Нам необходимо понять, справится ли наше приложение в эти дни активных продаж и посещений. Для этого нам необходимо оценить запас наших возможностей для бесперебойной и корректной работы.
Современные веб-приложения могут состоять из трех частей: базы данных, сервера приложения и веб-сервера. Сервер приложения хранит в себе непосредственно логику приложения. А веб-сервер занимается функциями управления статическим контентом — css, js, изображения и другими файлами. Эти три компонента могут находиться на разных компьютерах или даже на разных дата-центрах, располагающихся в разных регионах.
В данном случае со стороны разработки мы можем управлять структурой системы и компонентами, из которых она состоит, а вот внешние системы усложняют процесс тестирования. Во внешних системах конечные пользователи могут использовать различные типы устройств, как показано на картинке выше. Эти устройства подключены к сервис-провайдерам. Здесь могут быть разные типы интернет-соединений: оптоволокно, телефония и мобильный интернет. Локальные провайдеры пользуются услугами более крупных провайдеров, которые обеспечивают доступ к нашему приложению.
И запрос, который клиент отправляет из своего браузера, проходит всю эту длинную цепочку. Аналогичным образом возвращается ответ к конечному пользователю. Поэтому время отклика, непосредственно напрямую, используя наше приложение, и время отклика конечного пользователя могут очень сильно отличаться.
Решения для такой ситуации два: либо выполнять тест с точки зрения конечного пользователя, либо обеспечить запас мощности на производительность нашему приложению для компенсации на промежуточные звенья. Главный вопрос — будет ли данная сложная система работать быстро с точки зрения конечного пользователя?
Продолжение статьи можно прочитать в нашем блоге.
