К дипломному проекту icon

К дипломному проекту


Загрузка...
страницы:   1   2   3   4   5   6   7
скачать
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ

(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)


Кафедра «Информационно-коммуникационные технологии»


ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к дипломному проекту


На тему «Средства автоматизированного тестирования как контроль качества программного продукта»


Дипломник Алексашенков Даниил Владиславович

/

Руководитель проекта Акатов Максим Сергеевич


Допущен к защите_________________2010 г.


КОНСУЛЬТАНТЫ ПРОЕКТА:


Специальная часть ______________________ М. С. Акатов


Охрана труда ______________________ А. Ф. Завальнюк


Заведующий кафедрой ______________________ В. Н. Азаров


МОСКВА 2010 г.



Введение 3

Глава 1. Обзор существующих средств автоматизации тестирования 7

1.1 Тестирование на уровне кода 7

1.2 Тестирование приложений через графический интерфейс 11

^ Глава 2. Организация тестирования программного продукта 16

Глава 3. Жизненный цикл программного продукта 22

Глава 4. Качество и надежность программного продукта 33

4.1 Показатели качества ПО в ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126 33

4.2 Модели и метрики оценки качества ПО 42

4.3 Метрики качества тестирования 48

^ Глава 5. Виды тестирования программного продукта 50

5.1 Функциональные виды тестирования 50

5.2 Нефункциональные виды тестирования 52

5.3 Связанные с изменениями виды тестирования 55

^ Глава 6. Оценка эффективности автоматизации тестирования 58

Глава 7. Оценка полноты тестирования 63

7.1 Структурные критерии 64

7.2 Критерии полноты на основе структуры входных данных 70

7.3 Критерии полноты на основе требований 72

7.4 Критерии полноты на основе предположений об ошибках 74

Заключение 76

Приложение 1. Охрана труда 78

Исследование возможных опасных и вредных факторов при эксплуатации ЭВМ и их влияние на пользователей 78

Методы и средства защиты пользователей от воздействия на них опасных и вредных факторов. 82

Используемая литература 90

Введение


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

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

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

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

При автоматизированном тестировании для выполнения тестов и проверки результатов используются программные средства. При использовании методологии гибкого программирования TDD (Test Driven Development, Разработка через тестирование) тесты пишутся до написания кода программы, и программа считается законченной, когда проходит все тесты. В этом подходе автоматизация тестирования заложена в самой методологии. Автоматизация тестирования при правильном применении позволяет значительно снизить время, необходимое на тестирование. Оно не может полностью заменить ручное тестирование, но зато высокоэффективно при модульном, регрессионном, нагрузочном, инсталляционном и некоторых других видах тестирования.

Самая первая "автоматизация" появилась в эпоху операционных систем DOS и CP/M. Тогда она заключалась в отдаче приложению команд через командную строку и анализе результатов. Чуть позже добавились удаленные вызовы через API для работы по сети. Впервые об автоматизированном тестировании упоминается в книге Фредерика Брукса "Мифический человеко-месяц", где говорится о перспективах использования модульного тестирования. Но по-настоящему автоматизация тестирования стала развиваться только в 80-х годах.

Существует два основных подхода к автоматизации тестирования: тестирование на уровне кода и GUI-тестирование. К первому типу относится, в частности, модульное тестирование. Ко второму - имитация действий пользователя с помощью специальных тестовых Фреймворков.

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

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

Также нельзя забывать, что хоть тестирование и является неотъемлемой частью жизненного цикла программы, только оно не может гарантировать высокое качество. Повышенное внимание следует уделять на стадиях подготовки требований и создании архитектуры продукта. Многие авторы склоняются к тому, что чем раньше найден дефект, тем дешевле его устранить. [1]

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

Глава 1.Обзор существующих средств автоматизации тестирования

1.1Тестирование на уровне кода


Этот подход используется в основном при модульном и регрессионном тестировании [6][7].

Модульное тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно компонентное (модульное) тестирование проводится, вызывая код, который необходимо проверить и при поддержке сред разработки, таких как Фреймворки (frameworks - каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило, исправляются в коде без формального их описания в системе менеджмента багов (Bug Tracking System). Преимущества модульного тестирования включают:

  • Поощрение изменений. Модульное тестирование позже позволяет программистам проводить рефакторинг, будучи уверенными, что модуль по-прежнему работает корректно (регрессионное тестирование). Это поощряет программистов к изменениям кода, поскольку достаточно легко проверить, что код работает и после изменений.

  • Упрощение интеграции. Модульное тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируются отдельные части программы, затем программа в целом. Такой подход значительно упрощает интеграционное тестирование. Стоит отметить, что даже тщательно построенная иерархия модульных тестов не тождественна интеграционному тестированию. Оно пока не поддается полной автоматизации и требует участия людей тестировщиков.

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

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

Естственно, у этого вида тестирования есть определенные ограничения и недостатки:

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

  • Большой объем тестового кода. Тестирование программного обеспечения — комбинаторная задача. Например, каждое возможное значение булевской переменной потребует двух тестов: один на вариант TRUE, другой — на вариант FALSE. В результате на каждую строку исходного кода потребуется 3-5 строк тестового кода.

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

Инструментарий для облегчения выполнения модульного тестирования разработан для широкого спектра языков. В языках D и Cobra модульное тестирование интегрировано в саму грамматику языка и доступно без использования дополнительных библиотек. [7]

  • Для Java

JUnit JUnit.org

TestNG testNG.org

JavaTESK UniTESK.ru

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

  • Для C

CUnit cunit

CTESK UniTESK.ru

cfix cfix

API Sanity Autotest — для динамических C/C++ библиотек в Unix-подобных ОС.

  • Для Objective-C

OCUnit

  • Для C++

CPPUnit

Boost Test

Google C++ Testing Framework

Symbian — Фреймворк для Symbian OS всех версий.

API Sanity Autotest — для динамических C/C++ библиотек в Unix-подобных ОС.

  • DUnit — для Delphi

  • Для Perl

Test

Test::Simple

Test::Unit

Test::Unit::Lite

  • Для PHP

SimpleTest

PHPUnit

  • Для Python

PyUnit

PyTest

Nose

  • vbUnit — Visual Basic

  • utPLSQL — PL/SQL

  • Для T-SQL

TSQLUnit

SPUnit

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

AsUnit

AS2Unit

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

FlexUnit

AsUnit

  • Test::Unit — для Ruby

  • JsUnit — для JavaScript
    1. ^

      Тестирование приложений через графический интерфейс


Популярность такого вида тестирования объясняется двумя факторами: во-первых, приложение тестируется тем же способом, которым его будет использовать человек, во-вторых, можно тестировать приложение, не имея при этом доступа к исходному коду.

UI-автоматизация развивалась в течение 4 поколений инструментов и техник:

  • Утилиты записи и воспроизведения (capture/playback tools) записывают действия тестировщика во время ручного тестирования. Они позволяют выполнять тесты без прямого участия человека в течение продолжительного времени, значительно увеличивая продуктивность и устраняя «тупое» повторение однообразных действий во время ручного тестирования. В то же время, любое малое изменение тестируемого ПО требует перезаписи ручных тестов. Поэтому это первое поколение инструментов не эффективно и не масштабируемо.

  • Сценарии (Scripting) — форма программирования на языках, специально разработанных для автоматизации тестирования ПО — смягчает многие проблемы capture/playback tools. Но разработкой занимаются программисты высокого уровня, которые работают отдельно от тестировщиков, непосредственно запускающих тесты. К тому же скрипты более всего подходят для тестирования GUI и не могут быть внедренными, пакетными или вообще каким-либо образом объединены в систему. Наконец, изменения в тестируемом ПО требуют сложных изменений в соответствующих скриптах, и поддержка все возрастающей библиотеки тестирующих скриптов становится в конце-концов непреодолимой задачей.

  • Data-driven testing — методология, которая используется в автоматизации тестирования. Особенностью является то, что тестовые скрипты выполняются и верифицируются на основе данных, которые хранятся в центральном хранилище данных или БД. Роль БД могут выполнять ODBC-ресурсы, csv или xls файлы и т.д. Data-driven testing — это объединение нескольких взаимодействующих тестовых скриптов и их источников данных во Фреймворк, используемый в методологии. В этом Фреймворке переменные используются как для входных значений, так и для выходных проверочных значений: в тестовом скрипте обычно закодированы навигация по приложению, чтение источников данных, ведение логов тестирования. Таким образом, логика, которая будет выполнена в скрипте, также зависит от данных.

  • Keyword-based автоматизация подразумевает разделение процесса создания тесовых случаев на 2 этапа: этап планирования и этап реализации.

Популярные программы для такого вида тестирования включают в себя:

Коммерческие:

  • HP LoadRunner, HP QuickTest Professional, HP Quality Center

  • Segue SilkPerformer

  • IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio

  • AutomatedQA TestComplete



С открытым исходным кодом:

  • Selenium

  • WATIR

Также стоит выделить нагрузочное тестирование, которое тоже поддается автоматизации. Нагрузочное тестирование (Load Testing) или тестирование производительности (Performance Testing) - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком либо общем (разделяемом ими) ресурсе. [12]

Основными целями нагрузочного тестирования являются:

  1. Оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию

  2. Оценка производительности и работоспособности приложения на этапе выпуска новых релизов, патч-сетов

  3. Оптимизация производительности приложения, включая настройки серверов и оптимизацию кода

  4. Подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера

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

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

  2. Если целью является понимание насколько приложение устойчиво в режиме длительного использования (исключение утечек памяти, некорректных конфигурационных настроек и т.д.) то проводится долгий нагрузочный тест – это тестирование стабильности (Stability Testing). При этом анализ времен отклика может иметь место, но не быть первым приоритетом, главное чтобы система "не упала".

  3. Стресс тестирование (Stress Testing) имеет своей целью проверить, возвращается ли система после запредельной нагрузки (и как скоро) к нормальному режиму, также целями стрессового тестирования могут быть проверки поведения системы в случаях когда, один из серверов приложения в пуле перестаёт работать, аварийно изменилась аппаратная конфигурации сервера базы данных и т.д. Отметим также, что при стрессовом тестировании проверяется не производительность системы, а её способность к регенерации после сверх нагрузки.

Коммерческие инструменты для автоматизированного нагрузочного тестирования:

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

^ Hewlett-Packard (Mercury Interactive)

HP Performance Center (включает HP LoadRunner)

IBM Rational

Rational Performance Tester

^ Borland (Segue)

SilkPerformer

AutomatedQA Corp

TestComplete

Microsoft

MS Web Application Stress Tool



Отдельным пунктом выделим бесплатные инструменты для автоматизированного нагрузочного тестирования:

В целом можно составить сводную таблицу наиболее популярных средств автоматизации.

^ Таблица 1 2 Средства для автоматизации тестирования

Разработчик

Функциональное

Нагрузочное

Качество кода

Управление тестами

IBM

+

+

+

+

Borland

+

+

-

+

AutomatedQA

+

+

-

+

HP

+

+

+

+

Open-source

Abbot, Selenium, Watir

Grinder, Jmeter, OpenSTA

GCT, NCover, Cobertura

FitNesse, TestLink


^

Глава 2.Организация тестирования программного продукта


При внедрении автоматизированного тестирования в разработку, во избежание многих частых проблем связанных с этим процессом, рекомендуется использовать методологию жизненного цикла автоматизированного тестирования (The Automated Testing Life-cycle Methodology, ATLM).

При использовании такого структурного подхода организации могут исполнять действия связанные с тестированием с максимальным возможным в пределах ресурсов покрытием. Этот подход используется параллельно жизненному циклу разрабатываемой системы. [3]

Данный подход состоит из шести основных процессов или компонентов. Каждый из них делиться на подпроцессы, как показано ниже.

  1. ^ Решение автоматизировать тестирование. Первая фаза ATLM. Во время этой фазы ответственные за тестирование должны обозначить свои ожидания от автоматизации тестирования. Выделить потенциальную пользу при правильном внедрении. Также необходимо выдвинуть решение об инструментах, которые предполагается использовать.

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

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

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

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

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

  2. ^ Фаза внедрения автоматизированным тестированием.

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

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

  1. ^ Планирование, проектирование и разработка тестирования

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

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

Установка среды тестирования — это часть планирования тестирования. Команда тестировщиков должна планировать, отслеживать и управлять работами по установке среды тестирования, что может занять немало времени. Тестировщики обязаны составить план-график и управлять работой по установке среды; установить аппаратные, программные и сетевые ресурсы среды тестирования; интегрировать и установить ресурсы среды тестирования; получить и обновить тестовые базы данных; разработать скрипты для установки среды и скрипты для тестового стенда.

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

^ Разработка тестирования. Чтобы автоматизированное тестирование можно было повторно использовать, повторять и сопровождать, необходимо определить и соблюдать стандарты разработки тестирования.

  1. ^ Выполнение тестов и управление тестами

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

  1. ^ Обзор и оценка программы тестирования

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

Глава 3.Жизненный цикл программного продукта


При организации автоматизированного тестирования важно понимать, что для получения наибольшего эффекта от его внедрения, подход ATLM должен реализовываться параллельно с жизненным циклом разработки системы. [3] Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла информационной системы, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполнения работ, ожидаемые результаты, роли участников, методы и средства, необходимые для выполнения работ и т.д. Такое формальное описание позволяет управлять данными процессами и организовать процесс коллективной разработки. Жизненный цикл информационной системы можно представить как ряд событий, которые происходят с ней во время создания и использования.

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

На настоящий момент основными моделями жизненного цикла являются:

  • Каскадная модель (рис. 1). Последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем.

Рисунок 1 Каскадная модель



  • Поэтапная модель с промежуточным контролем (рис. 2). Разработка ведется итеративно с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существющие влияния результатов разработки друг на друга на различных этапах. Вследствие этого время жизни каждого из этапов растягивается практически на все время разработки.

^ Рисунок 2 Поэтапная модель с промежуточным контролем



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

^ Рисунок 3 Спиральная модель



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

Каскадный подход имеет следующие преимущества:

  • На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

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

Пример внедрения автоматизированного тестирования в спиральную модель жизненного цикла:

Рисунок 4 Соотношение жизненного цикла разработки системы с ATLM




В нашей стране жизненный цикл разработки ПО установлен стандартом ГОСТ 19.102-77 Стадии разработки программ и программной документации и содержит следующие стадии и этапы [10]:

  1. Техническое задание (ТЗ).

  2. Эскизный проект (ЭП).

  3. Технический проект (ТП).

  4. Рабочий проект (РП).

  5. Внедренние.

В таблице 3-1 показаны стадии разработки и этапы, их составляющие.
Неверно предполагать, что жизненный цикл разработки ПО согласно ГОСТ 19.102-77 есть последовательное выполнение стадий и этапов, определенных в таблице 3-1. В реальном жизненном цикле трудно провести четкую и определенную границу между этапами, а сам процесс создания ПО является итеративным: после завершения некоторого этапа почти всегда есть необходимость в коррекции уже выполненных этапов и стадий с целью внесения уточнений. При разработке принципиально нового ПО иногда бывает необходимо осуществить пробную реализацию с целью получения информации, требующейся для принятия решения на некоторой стадии.

Таблица 3-1

Стадии разработки

Этапы работ

Техническое задание

1. Обоснование необходимости разработки программ.
2. Выполнение научно-исследовательских работ (НИР).
3. Разработка и утверждение технического задания.

Эскизный проект

1. Разработка эскизного проекта.
2. Утверждение эскизного проекта.

Технический проект

1. Разработка технического проекта.
2. Утверждение технического проекта.

Рабочий проект

1. Разработка программы.
2. Разработка программной документации.
3. Испытание программы.

Внедрение

1. Подготовка и передача программы.

Техническое задание. На стадии Техническое задание выполняются следующие работы, входящие в состав соответствующих этапов.

  1. ^ Обоснование необходимости разработки программ:

постановка задачи;

сбор исходных материалов;

выбор и обоснование критериев эффективности и качества;

обоснование необходимости проведения НИР.

  1. ^ Выполнение научно-исследовательских работ:

определение структуры входных и выходных данных;

предварительный выбор методов решения задач;

обоснование целесообразности применения ранее разработанных программ;

определение требований к техническим средствам;

обоснование принципиальной возможности решения поставленных задач.

  1. ^ Разработка и утверждение технического задания:

определение требований к программе;

разработка технико-экономического обоснования разработки программы;

определение стадий, этапов и сроков разработки программы и документации на нее;

выбор языков программирования;

определение необходимости проведения НИР на последующих стадиях;
согласование и утверждение ТЗ.

Результатом выполнения данной стадии является техническое задание, оформленное в соответствии с ГОСТ 19.105-78 (изм. 09.1981.) Общие требования к программным документам и ГОСТ 19.106-78 Общие требования к программным документам, выполненным печатным способом на листах формата 11 и 12 (по ГОСТ 2.301-68).

Эскизный проект. Основные этапы и содержание работ на стадии Эскизный проект приведены в таблице 3 - 2.


Таблица 3 - 2

Этапы работ

Содержание

Разработка ЭП

1. Предварительная разработка структуры входных и выходных данных.
2. Уточнение методов решения задач.
3. Разработка общего описания алгоритма решения задачи.
4. Разработка технико-экономического обоснования.

Утверждение ЭП

1. Разработка пояснительной записки.
2. Согласование и утверждение эскизного проекта.

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

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

Результаты эскизного проекта отображаются в документе Пояснительная записка к эскизному проекту, оформленному в соответствии с ГОСТ 19.105-78 и ГОСТ 19.404-79.

После утверждения пояснительной записки она становится программным документам, правила дублирования, учета, хранения которого определяется ГОСТ 19.601-78 Общие правила дублирования, обращения, учета и хранения и ГОСТ 19.602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом. Последующие стадии и этапы разработки ПО могут выявить необходимость внесения изменений в ЭП. Эти изменения должны быть отражены в пояснительной записке в соответствии с ГОСТ 19.603-78 Общие правила внесения изменений в программные документы и ГОСТ 19.602-78 Правила внесения изменений в программные документы, выполненные печатным способом.

В качестве примера, ниже приводится фрагмент расширенного описания работ стадии эскизного проекта.

^ Разработка эскизного проекта ПО.

разработка плана совместных работ на разработку ПО;

разработка и обоснование математической модели системы на ЭВМ и описание результатов моделирования;

разработка и обоснование алгоритмов и временных графиков функционирования ПО по всем режимам работы;

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

разработка перечня документов на ПО;

разработка и обоснование структуры БД, внешних входных и выходных данных;

разработка и обоснование алгоритмов информационного обеспечения;

определение взаимосвязей между видами программ;

разработка и обоснование набора тестов для проверки ПО;

разработка и обоснование организации наращивания и развития ПО;

оформление пояснительной записки и ведомости эскизного проекта ПО (в соответствии с ГОСТ 19.105-78, ГОСТ 19.404-79 и ГОСТ 2.106-68 ЕСКД. Текстовые документы);

согласование и утверждение ЭП.


Технический проект. Основные этапы и содержание работ на стадии Технический проект приведены в таблице 3 - 3.

Содержанием работ на этой стадии является проектирование структуры ПО. Результатом - реализующий заданный и утвержденный в техническом задании комплекс программ как иерархическая структура программных модулей, заданных своими функциональными спецификациями. Форма представления результата - Пояснительная записка к техническому проекту согласно ГОСТ 19.105-78, ГОСТ 19.404-79.

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

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


^ Таблица 3 3 Стадия технический проект

Этапы работ

Содержание

Разработка ТП

  1. Уточнение структуры входных и выходных данных.

  2. Разработка алгоритмов решения задач.

  3. Определение формы представления входных и выходных данных.

  4. Определение синтаксиса и семантики языка.

  5. Разработка структуры программы.

  6. Окончательное определение конфигурации технических средств.

Утверждение ТП

  1. Разработка плана мероприятий по разработке и внедрению программ.

  2. Разработка пояснительной записки.

  3. Согласование и утверждение ТП.

Рабочий проект. Основные этапы и содержание работ на стадии Рабочий проект приведены в таблице 3 - 4.

^ Таблица 3 4 Стадия рабочий проект

Этапы работ

Содержание

Разработка ПО

Программирование и отладка программ.

Разработка программной документации

  1. Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.

Испытание ПО

  1. Разработка, согласование и утверждение программ и методики испытаний

  2. Проведение предварительных государственных, межведомственных приемо-сдаточных и других видов испытаний.

  3. Корректировка ПО и программной документации по результатам испытаний.

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

На стадии Внедрения осуществляется подготовка и передача ПО и программной документации для сопровождения и/или изготовления, оформление и утверждение акта о передаче ПО на сопровождение или изготовление, передача ПО в фонд алгоритмов и программ.
^

Глава 4.Качество и надежность программного продукта


Перечисленные метрики и показатели качества помогают формализовать и оценить требования к тестированию. Как писал Том ДеМарко: “Невозможно управлять тем, что нельзя измерить”. Но следует учитывать, что многие из этих метрик могут давать ложное представление о состоянии продукта при неверной интерпретации, и приносить скорее вред, чем пользу.
^

4.1Показатели качества ПО в ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126


ГОСТ Р ИСО/МЭК 9126 устанавливает шесть характеристик качества ПО. Под характеристикой качества ПО, согласно этому стандарту, понимается набор свойств (атрибутов) программной продукции, по которым ее качество оценивается или описывается. Определение качества и определенные в этом стандарте характеристики отражают представление пользователя о качестве ПО. [11] Ниже приводится существенное для оценки качества ПО обсуждение этих характеристик. [8]

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

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

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

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

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

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

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

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

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

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

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

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

Все приведенные характеристики являются наборами атрибутов и, следовательно, должны уточняться на множестве соответствующих подхарактеристик. ГОСТ Р ИСО/МЭК 9126 не устанавливает соответствующих показателей, но в рекомендуемом приложении А к этому стандарту дается пример (качественная модель) таких подхарактеристик, называемых комплексными показателями.

В качестве примера приведем комплексные показатели для некоторых характеристик.

^ Характеристика Функциональные возможности:

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

2. Правильность - атрибуты ПО, относящиеся к обеспечению правильности или соответствия результатов или эффектов.

3. Способность к взаимодействию - атрибуты ПО, относящиеся к способности его взаимодействовать с конкретными системами.

4. Согласованность - атрибуты ПО, которые заставляют программу придерживаться соответствующих стандартов или соглашений, или положений законов, или подобных рекомендаций.

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

Характеристика Эффективность:

1. Характер изменения во времени - атрибуты ПО, относящиеся к временам отклика и обработки и к скорости выполнения его функций.

2. Характер изменения ресурсов - атрибуты ПО, относящиеся к объему используемых ресурсов и продолжительности такого использования при выполнении функций.

Приведенные комплексные показатели в свою очередь формируются на основе показателей нижележащего уровня. ГОСТ Р ИСО/МЭК 9126 не устанавливает этих показателей, так как современное состояние соответствующих моделей, терминов, определений не позволяет включить их в рассматриваемый международный стандарт.

В СССР действовал и продолжает действовать в РФ ГОСТ 28195-89. Этот стандарт устанавливает четырехуровневую модель оценки качества ПС. Характеристики верхних двух уровней (называемые фактор и критерий) устанавливаются в основном тексте документа. В таблице 4-1 показаны факторы и критерии качества ПО согласно ГОСТ 28195.


Таблица 4 - 1

Наименование факторов и критериев качества ПО и их обозначение

Характеризуемое свойство

1. Надежность ПО (Н)

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

1.1. ^ Устойчивость функционирования (Н1)

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

1.2. Работоспособность (Н2)

Способность ПО функционировать в заданных режимах и объемах обрабатываемой информации в соответствии с программными документами при отсутствии сбоев технических средств.

2. Сопровождаемость (С)

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

2.1. Структурность (С1)

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

2.2. Простота конструкции (С2)

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

2.3. Наглядность (С3)

Наличие и представление в наиболее легко воспринимаемом виде исходных модулей ПО, полное их описание в соответствующих программных документах.

2.4. Повторяемость (С4)

Степень использования типовых проектных решений или компонентов, входящих в ПО.

3. Удобство применения (У)

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

3.1. Легкость освоения (У1)

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

3.2. Доступность эксплуатационных программных документов (У2)

Понятность, наглядность и полнота описания взаимодействия пользователя с ПО в эксплуатационных программных документах.

3.3. Удобство эксплуатации и обслуживания (У3)

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

4. Эффективность (Э)

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

4.1. ^ Уровень автоматизации (Э1)

Уровень автоматизации функций процесса обработки данных с учетом рациональности функциональной структуры ПО с точки зрения взаимодействия с ней пользователя и использования вычислительных ресурсов.

4.2. Временная эффективность (Э2)

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

4.3. Ресурсоемкость (Э3)

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

5. Универсальность (Г)

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

5.1. Гибкость (Г1)

Возможность использования ПО в различных областях применения.

5.2. Мобильность (Г2)

Возможность применения ПО без существенных дополнительных трудозатрат на ЭВМ аналогичного класса.

5.3. Модифицируемость (Г3)

Обеспечение простоты внесения необходимых изменений и доработок в ПО в процессе эксплуатации.

6. Корректность (К)

Характеризует степень соответствия ПО требованиям, установленным в техническом задании, требованиям к обработке данных и общесистемным требованиям.

6.1. Полнота реализации (К1)

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

6.2. Согласованность (К2)

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

6.3. Логическая корректность (К3)

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

6.4. Проверенность (К4)

Полнота проверки возможных маршрутов выполнения программы в процессе тестирования.




оставить комментарий
страница1/7
Дата18.11.2011
Размер0,85 Mb.
ТипДиплом, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы:   1   2   3   4   5   6   7
Ваша оценка этого документа будет первой.
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Загрузка...
Документы

наверх