Достоинства тестирования «БЯ»

Принцип «белого ящика» позволяет учесть особенности программных ошибок:

1. Количество ошибок минимально в «центре» и максимально на «периферии» программы.

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

3. При записи алгоритма ПО в виде текста на языке программирования возможно внесение типовых ошибок трансляции (синтаксических и семантических).

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

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

Способы тестирования «БЯ»:

• тестирование базового пути;

• тестирование условий;

• тестирование ветвей и операторов отношений;

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

• тестирование циклов

– простые циклы,

– вложенные циклы,

– объединенные циклы,

– неструктурированные циклы.

Функциональное тестирование ПО
(тестирование «черного ящика»)

Особенности функционального тестирования:

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

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

Функциональное тестирование ПО
(тестирование «черного ящика»)

При таком подходе желательно иметь:

• набор, образуемый такими входными данными, которые приводят к аномалиям поведения программы (назовем его IT );

• набор, образуемый такими выходными данными, которые демонстрируют дефекты программы (назовем его ОТ ).

 

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

Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:

1) некорректных или отсутствующих функций;

2) ошибок интерфейса;

3) ошибок во внешних структурах данных или в доступе к внешней базе данных;

4) ошибок характеристик (необходимая емкость памяти и т. д.);

5) ошибок инициализации и завершения.

Подобные категории ошибок способами «белого ящика» не выявляются.

 

В отличие от тестирования «белого ящика», которое выполняется на ранней стадии процесса тестирования, тестирование «черного ящика» применяют на поздних стадиях тестирования.

При тестировании «черного ящика» пренебрегают управляющей структурой программы. Здесь внимание концентрируется на информационной области определения программной системы.

Техника «черного ящика» ориентирована на решение следующих задач:

– сокращение необходимого количества тестовых вариантов (из-за проверки не статических, а динамических аспектов системы);

– выявление классов ошибок, а не отдельных ошибок.

 

Способы тестирования «ЧЯ»

• Способ разбиения по эквивалентности [этом способе входная область данных программы делится на классы эквивалентности, для каждого из которых разрабатывается один тестовый вариант (класс эквивалентности — набор данных с общими свойствами)].

• Способ анализа граничных значений (как правило, большая часть ошибок происходит на границах области ввода, а не в центре. Анализ граничных значений заключается в получении тестовых вариантов, которые анализируют граничные значения).

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

 

 

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

1. Необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы;

2. Программе не должна тестироваться её автором;

3. Организация - разработчик программного обеспечения не должна "единолично " его тестировать;

4. Необходимо подбирать тесты не только для правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных);

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

6. "Принцип скопления ошибок" - вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части;

 

Процесс тестирования состоит из трёх этапов:

1. Проектирование тестов.

2. Исполнение тестов.

3. Анализ полученных результатов.

 

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

 

- "Чёрный ящик" - тестирование функционального поведения программы с точки зрения внешнего мира (текст программы не используется).

- "Белый ящик" - тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка на котором она писалась.

 

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

 

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

 

- Compuware Corporation (DevPartner`s)

- Rational Software from IBM

- Gcov (open source program for TrueCoverage)

- Различные редакторы и средства облегчающие редактирование текста(EditPlus 2, WinEdit и т.д.)

 

Автоматизированные средства разрабатываются в основном для следующих этапов процесса тестирования:

- Тестирование функциональных требований

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

- Тестирование отдельных модулей

- Комплексное тестирование

- Анализ сложности программных модулей

- Тестирование покрытия программного кода

- Тестирование скорости загрузки системы

- Тестирование граничных условий

- Тестирование утечки памяти

Существует два основных вида тестирования: функциональное и структурное.

 

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

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

1) программа может не соответствовать своей внешней спецификации, что в частности, может привести к тому, что в ее управляющем графе окажутся пропущенными некоторые необходимые пути;

2) не будут обнаружены ошибки, появление которых зависит от обрабатываемых данных (т.е. на одних исходных данных программа работает правильно, а на других - с ошибкой).

 

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

наверх.

 

2.Организация тестирования программ.

Тестирование программного продукта одновременно проводится в 3-ёх направлениях:

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

2.Тестирование высокого уровня: Здесь главная цель тестирования - выяснить, удовлетворяет ли разработка всем требованиям заказчика. Для программного продукта пишутся эмуляторы, с помощью которых тестер может наблюдать за работой системы в роли оператора. Он видит, как система осуществляет диалог с пользователем, какие сообщения она выдаёт, как реагирует на различные события, сохраняет информацию и т.д.. Большинство обнаруживаемых ошибок на этом этапе связанно с ошибками взаимодействия программного продукта с пользователем - вывод ошибочных сообщений, не правильная реакция на запрос от оператора и т.п.

 

3.Тестирование низкого уровня: Тестер проверяет, на сколько логически полно исходный код покрывает всё возможные варианты работы системы, для которой он разрабатывается.

 

Структурное моделирование, анализ и проектирование ПО.

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

 

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

 

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

 

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

 

Особенности современных проектов ПО:

структурная, функциональная и информационная сложность объекта внедрения;

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

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

наличие унаследованного ПО и необходимость его интеграции с разрабатываемым ПО;

территориально распределенная и неоднородная среда функционирования;

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

значительная длительность жизненного цикла ПО.

 

С конца 60-х годов прошлого века до сегодняшних дней продолжается так называемый «кризис ПО». Выражается он в том, что большие проекты выполняются с превышением сметы расходов и/или сроков отведенных на разработку, а разработанное ПО не обладает требуемыми функциональными возможностями, имеет низкую производительность и качество. По результатам исследований американской индустрии разработки ПО, выполненных в 1995 году, только 16% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности. 53% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме. 31% проектов были аннулированы до завершения. Для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения – на 122%. В последние годы процентное соотношение трех перечисленных категорий проектов незначительно изменяется в лучшую сторону.

 

Причины неудач:

- нечеткая и неполная формулировка требований;

- недостаточное вовлечение пользователей в работу над проектом;

- отсутствие необходимых ресурсов;

- неудовлетворительное планирование и отсутствие грамотного управления проектом;

- частое изменение требований и спецификаций;

- новизна и несовершенство используемой технологии;

- недостаточная поддержка со стороны высшего руководства;

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

 

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

 

 

В структурном анализе и проектировании используются различные модели, описывающие:

- Функциональную структуру системы;

- Последовательность выполняемых действий;

- Передачу информации между функциональными процессами;

- Отношения между данными.

 

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

- функциональная модель SADT (Structured Analysis and Design Technique);

- модель IDEF3;

- DFD (Data Flow Diagrams) - диаграммы потоков данных.

 

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном стандартов этого семейства - IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г.

 

Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового. Достоинствами применения моделей SADT для описания бизнес-процессов являются:

- полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);

- жесткие требования метода, обеспечивающих получение моделей стандартного вида;

соответствие подхода к описанию процессов стандартам ISO 9000.

 

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

 

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции). Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.

Диаграммы потоков данных (Data Flow Diagrams - DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

 

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

 

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

 

Наиболее распространенным средством моделирования данных (предметной области) является модель "сущность-связь" (Entity-Relationship Model - ERМ). Она была впервые введена Питером Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Одна из разновидностей модели "сущность-связь" используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE-средств (в частности, AllFusion ERwin Data Modeler).

 

Объектное моделирование, анализ и проектирование ПО.

 

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

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

1) абстрагирование;

2) инкапсуляция;

3) модульность;

4) иерархия.

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

Инкапсуляция – локализация свойств и поведения в рамках единственной абстракции (рассматриваемой как «черный ящик»), скрывающей реализацию за общедоступным интерфейсом. Инкапсуляция – это отделение внутреннего устройства объекта от его внешнего поведения. Объектный подход предполагает, что внутренние ресурсы объекта, скрыты от внешней среды. Абстрагирование и инкапсуляция являются взаимодополняющими принципами.

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

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

К основным понятиям объектно-ориентированного подхода (элементам объектной модели) относятся: объект; класс; атрибут; операция; полиморфизм; наследование; компонент; связь.

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

Структура и поведение схожих объектов определяют общий для них класс. Класс – это множество объектов, связанных общностью свойств, поведения, связей и семантики. Любой объект является экземпляром класса. Определение классов и объектов – одна из самых сложных задач объектно-ориентированного проектирования.

Атрибут – поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Атрибуты могут быть скрыты от других классов, это определяет видимость атрибута: рublic (общий, открытый); private (закрытый, секретный); protected (защищенный).

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

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

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

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

Между элементами объектной модели существуют различные виды связей:

1) ассоциация – это семантическая связь между классами;

2) агрегация – более сильный тип связи между целым и его частями;

3) зависимость – связь между двумя элементами модели, при которой изменения в спецификации одного элемента могут повлечь за собой изменения в другом элементе;

4) обобщение – связь «тип – подтип».

Связи характеризуются: направлением; именем и ролевыми именами участников связи; мощностью.

Управление проектами разработки ПО.

 

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

 

Управление проектом — применение знаний, навыков, инструментов и методов для планирования и реализации действий, направленных на достижение поставленной цели в рамках проектных требований.

 

Управление проектами включает такие этапы, как:

· Планирование работ

· Оценка рисков

· Оценка необходимых ресурсов

· Организация работ

· Привлечение людских и материальных ресурсов

· Назначение задач

· Руководство

· Контроль над ходом выполнения (для измерения и контроля эффективности выполнения проектов используется метод освоенного объема)

· Отчет о ходе выполнения

· Анализ результатов на основе полученных фактов.

 

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

 

В Плане управления проектом должно быть отражено:

- Содержание и границы проекта

- Ключевые вехи проекта

- Плановый бюджет проекта

- Предположения и ограничения

- Требования и стандарты