Рабочее определение

В практике компьютерной инженерии бытует другой, более узкий контекст использования данного понятия: под системными требованиями в узком смысле понимают требования, выдвигаемые прикладной программной системой (в частности – информационной) к среде своего функционирования (системной, аппаратной). Пример таких требований – тактовая частота процессора, объём памяти, требования к выбору операционной системы.

Функциональные и нефункциональные требования

- Функциональные требования

- Нефункциональные требования

- Характеристики продукта

Функциональные требования

Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос «что должна делать система» в тех или иных ситуациях. Функциональные требования определяют основной «фронт работ» Разработчика, и устанавливают цели, задачи и сервисы, представляемые системой Заказчику.

Нефункциональные требования

- Внешние интерфейсы (External Interfaces)

- Атрибуты качества (Quality Attributes)

- Ограничения (Constraints).

Нефункциональные требования. Внешние интерфейсы

Среди внешних интерфейсов в большинстве современных АИС наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и передачи информации (коммуникационные интерфейсы).

Нефункциональные требования. Атрибуты качества

• Применимость

• Надежность

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

• Эксплуатационная пригодность

Ограничения

Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. Выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных…), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.

Характеристики продукта

Вигерс формулирует характеристику, «фичу» (feature), как набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели.

Классификация RUP

- Модель FURPS

- Модель FURPS+

- Дополнения

Классификация RUP. Модель FURPS

- Functionality (Функциональность)

- Usability (Применимость)

- Reliability (Надежность)

- Performance (Производительность)

- Supportability (эксплуатационная пригодность)

Классификация RUP. Модель FURPS+

- ограничения проекта

- требования выполнения

- требования к интерфейсу

- физические требования

Классификация RUP. Дополнения

- требования, указывающие на необходимость согласованности с некоторыми юридическими и нормативными актами

- требования к лицензированию

- требования к документированию

Методология и стандарты, регламентирующие работу с требованиями

- Разработка IEEE

- Отечественные стандарты

Разработка IEEE

- IEEE 1362 «Concept of Operations Document».

- IEEE 1233 «Guide for Developing System Requirements Specifications».

- IEEE Standard 830-1998 , «IEEE Recommended Practice for Software Requirements Specifications»

- IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990

- IEEE Guide to the Software Engineering Body of Knowledge (1) – SWEEBOK, 2004

Отечественные стандарты

• ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.

• ГОСТ 34.602-89. Информационная технология. Технические задания на создание автоматизированной системы.

• ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

1. Основные определения

Тестирование ПО - это процесс выполнения ПО в контролируемых условиях с целью получения ответа на вопрос "Ведет ли ПО себя так, как специфицировано?".

Термин ошибка (bug) часто используется в отношении проблем и сбоев в компьютере. Различают программные и аппаратные ошибки. При тестировании программного обеспечения речь идет о программных ошибках.

Международный стандарт ANSI/IEEE–729–83 разделяет все ошибки в разработке программ на следующие:

• Ошибка (error) – состояние программы, при котором выдается неправильные результаты, причиной которых являются изъяны (flaw) в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, а следовательно и к неверному решению.

• Дефект (fault) в программе является следствием ошибок разработчика на любом из этапов разработки и может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. Дефект обнаруживается в процессе выполнения программы.

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

Тестовый случай (test-case) – пара (входные данные-ожидаемый результат), в которой входные данные - это описание данных, подаваемых на вход системы, а ожидаемый результат - описание выходных данных, которая система должна предъявить в ответ на соответствующий ввод.

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

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

Из тестовых случаев формируются тестовые наборы (test suits). Тестовые наборы организуются в определенном порядке, отражающем свойства тестовых случаев. Если система успешно справилась со всеми тестовыми случаями из набора, то она успешно прошла испытания на тестовом наборе.

1.1 Уровни тестирования

Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция

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

Системное тестирование — тестируется интегрированная система на её соответствие исходным требованиям

• Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на стороне разработчика. Часто альфа-тестирование применяется для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

1.1.1 Модульное тестирование

Модульное или юнит-тестирование (unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

Преимущества

Цель юнит-тестирования — изолировать отдельные части программы и показать, что по отдельности эти части — работоспособны. Этот тип тестирования обычно выполняется программистами. Достоинствами юнит-тестирования является

-Поощрение изменений

Юнит-тестирование позволяет программистам проводить реорганизацию кода программы, будучи уверенными, что модуль по-прежнему работает корректно. Это поощряет программистов к изменениям кода, поскольку достаточно легко проверить, что код работает и после изменений.

-Упрощение интеграции

Юнит-тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируются отдельные части программы, затем программа в целом.

-Документирование кода

Юнит-тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит- тест в качестве примера.

-Отделение интерфейса от реализации

Поскольку некоторые классы могут использовать другие классы, тестирование отдельного класса часто распространяется на связанные с ним. Например, класс пользуется базой данных; в ходе написания теста программист обнаруживает, что тесту приходится взаимодействовать с базой. Это ошибка, поскольку тест не должен выходить за границу класса. В результате разработчик абстрагируется от соединения с базой данных и реализует этот интерфейс, используя свой собственный mock-объект.

В объектно-ориентированном программировании mock-объектом называют специальный объект, создаваемый для организации тестирования программного модуля. Такой объект имитирует поведение реального объекта, с которым будет взаимодействовать тестируемый модуль. Это приводит к менее связанному коду, минимизируя зависимости в системе.

Ограничения

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

Кроме того, довольно трудно предугадать все варианты исходных данных, которые могут быть переданы модулю в реальной работе.

Юнит-тестирование будет эффективным только при использовании совместно с другими способами тестирования.

Инструментарий

Для большинства популярных языков программирования высокого уровня существуют инструменты и библиотеки юнит-тестирования. Некоторые из них:

• Для Java

  • JUnit JUnit.org

  • TestNGtestNG.org

  • JavaTESK UniTESK.ru

• NUnit [1]—для языков платформы.NET:C#, Visual Basic .NETи др.

• Для C

  • CTESK UniTESK.ru

• Для C++

  • CPPUnit[2]

  • Boost Test [3]

  • googletest[4]

  • Symbian[5]—фреймворк для Symbian OS всех версий.

• DUnit [6]—дляDelphi

• Для Perl

  • Test[7]

  • Test::Simple [8]

  • Test::Unit [9]

  • Test::Unit::Lite [10]

• Для PHP

  • SimpleTest [11]

  • PHPUnit[12]

• Для Python

  • PyUnit[13]

  • PyTest[14]

  • Nose[15]

• vbUnit[16]—Visual Basic

• utPLSQL[17]—PL/SQL

• Для ActionScript 2.0—язык_сценариев,используемый_виртуальной_машиной_Adobe Flash Playerверсии 7и 8

  • AsUnit[18]

  • AS2Unit[19]

• Для ActionScript 3.0—скриптовый язык,используемый_виртуальной_машинойAdobe Flash Player_версии9

  • FlexUnit[20]

  • AsUnit[21]

• Test::Unit [22] — для Ruby

• JsUnit[23]—для JavaScript

1.1.2 Интеграционное тестирование

Интеграционное тестирование (Integration testing, Integration and Testing, I&T) — одна из фаз тестирования программного обеспечения, при котором отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.

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

Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приемным и требованиям надежности. Тестирование этих проектируемых единиц — объединения, множества или группа модулей —выполняются через их интерфейс, используя тестирование «черного ящика».

1.1.3 Системное тестирование

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

Системное тестирование относится к методам тестирования чёрного ящика, и, тем самым, не требует знаний о внутреннем устройстве системы.

Функциональное тестирование

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

Функциональные требования включают:

• Функциональная пригодность (англ. suitability).

• Точность (англ. accuracy).

• Способность к взаимодействию (англ. interoperability).

• Соответствие стандартам и правилам (англ. compliance).

• Защищенность (англ. security).

Юзабилити-тестирование

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

Юзабилити-тестирование — метод оценки удобства использования продукта, основанный на привлечении пользователей в качестве тестирующих.

Процесс

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

Процесс тестирования фиксируется на аудио- и видеоустройства с целью последующего анализа.

Если юзабилити-тестирование выявляет трудности, такие как сложности в понимании инструкций, выполнении действий или интерпретации ответов системы, то разработчики должны улучшить объект и повторить тестирование.

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

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

• Речь модератора и респондента;

• Выражение лица респондента(снимается на видеокамеру);

• Изображение экрана компьютера, с которым работает респондент;

• Различные события, происходящие на компьютере, связанные с действиями пользователя:

• Перемещение курсора и нажатия на клавиши мыши;

• Использование клавиатуры;

• Переходы между экранами(браузера или другой программы).

Все эти потоки данных должны быть синхронизированы, чтобы при анализе их можно было бы соотносить между собой.

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

Тестирование на основе модели

Тестирование на основе модели (англ. Model-based testing) - это тестирование программного обеспечения, в котором тестовые случаи (test cases) частично или целиком получаются из модели описывающей некоторые аспекты(чаще функциональные)тестируемой системы (system under test).

Тестирование безопасности

Тестирование безопасности — оценка уязвимости программного обеспечения к различным атакам.

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

• попытки узнать пароль с помощью внешних средств;

• атака системы с помощью специальных утилит, анализирующих защиты;

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

• целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;

• просмотр несекретных данных в надежде найти ключ для входа в систему.

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

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

Тестирование производительности— оценка функции производительности.

• программного обеспечения

• оборудования(например, персонального компьютера)

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

Автоматическое тестирование

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

В наши дни создаётся большое количество инструментов с графическим интерфейсом(GUI), использование которых помогает облегчить работу программистов и повышает их производительность. Эти процессы увеличили требования к тестировщикам. Сейчас они должны обрабатывать большое количество информации за короткий срок. Потому использование автоматических тестов является необходимым условием для экономии средств и времени тестировщиков.

Современные средства разработки создают довольно сложные приложения, и их ручное тестирование является очень трудоёмким процессом. Недостаток ручного тестирования также в том, что результаты выполнения тестов не сохраняются и их трудно повторить заново. Автоматические тесты позволяют упростить процесс ручного тестирования, сделать его наиболее удобным и точным.

Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них по итогам 2008года:

• HP LoadRunner, HP QuickTest Professional , HP Quality Center

• Segue SilkPerformer

• IBM Rational FunctionalTester, IBM Rational PerformaneTester, IBM Rational TestStudio

• AutomatedQA TestComplete

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

• установка продукта

• создание тестовых данных

• GUIвзаимодействие

• определение проблемы

Однако автоматические тесты не могут полностью заменить ручное тестирование. Автоматизация всех испытаний — очень дорогой процесс, и потому автоматическое тестирование является лишь дополнением ручного тестирования. Наилучший вариант использования автоматических тестов —регрессионное тестирование.

1.2 Тестирование "белого" и "черного" ящика

При тестированиибелого ящика ( white-box testing), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования(unit testing), при котором тестируются только отдельные части системы.

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

Покрытие кода - это запуск тестируемоего ПО со специальными настройками или библиотеками и/или в особом окружении.

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

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

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

При тестировании чёрного ящика (black-box testing), тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования.

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

В данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).

1.3 Статическое и динамическое тестирование

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

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

1.4 Регрессионное тестирование

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

Регрессионное тестирование может выполняться как вручную, так и программой, автоматизирующей этот процесс.