1 подтверждает ли тестирование правильность программы

После окончания тестирования интеграции программная система собрана в единый корпус, интерфейсные ошибки обнаружены и откорректированы. Теперь начинается последний шаг программного тестирования — тестирование правильности. Цель — подтвердить, что функции, описанные в спецификации требований к ПС, соответствуют ожиданиям заказчика [64], [69].

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

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

1) системную спецификация;

2) план программного проекта;

Нагрузочное тестирование. Часть 1

3) спецификацию требований к ПС; работающий или бумажный макет;

4) предварительное руководство пользователя;

5) спецификация проектирования;

6) листинги исходных текстов программ;

7) план и методику тестирования; тестовые варианты и полученные результаты;

8) руководства по работе и инсталляции;

9) ехе-код выполняемой программы;

10) описание базы данных;

11) руководство пользователя по настройке;

12) документы сопровождения; отчеты о проблемах ПС; запросы сопровождения; отчеты о конструкторских изменениях;

13) стандарты и методики конструирования ПС.

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

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

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

Бета-тестирование проводится конечным пользователем в организации заказчика. Разработчик в этом процессе участия не принимает. Фактически, бета-тестирование — это реальное применение ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику.

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

22) Системное тестирование

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

Тестирование Программного Обеспечения — урок №1 — Введение

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

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

23) Отладка ПО (аналитические, экспериментальные методы отладки)

Отла́дка — этап разработки компьютерной программы, на котором обнаруживают, локализуют и устраняют ошибки. Чтобы понять, где возникла ошибка, приходится:

• узнавать текущие значения переменных;
• выяснять, по какому пути выполнялась программа.

Существуют две взаимодополняющие технологии отладки.

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

Различают две группы методов отладки:

1 Аналитические
2 Экспериментальные

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

Общая стратегия отладки — обратное прохождение от замеченного симптома ошибки к исходной аномалии (месту в программе, где ошибка совершена).

В простейшем случае место проявления симптома и ошибочный фрагмент совпадают. Но чаще всего они далеко отстоят друг от друга.

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

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

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

В экспериментальных методах для прослеживания выполняется:

1. Выдача значений переменных в указанных точках.

2. Трассировка переменных (выдача их значений при каждом изменении).

3. Трассировка потоков управления (имен вызываемых процедур, меток, на которые передается управление, номеров операторов перехода).

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

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

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

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

Сопровождаемость программного обеспечения — характеристики программного продукта, позволяющие минимизировать усилия по внесению в него изменений:

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

25) Принципы объектно-ориентированного программирования

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

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

Инкапсуляция — это свойство системы, позволяющее объединить данные и методы, работающие с ними в классе, и скрыть детали реализации от пользователя

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

Полиморфизм — это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

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

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

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

Основной упор этой модели в Delphi делается на максимальном повторном использовании кода. Это позволяет разработчикам строить приложения весьма быстро из заранее подготовленных объектов, а также дает им возможность создавать свои собственные объекты для среды Delphi. Никаких ограничений по типам объектов, которые могут создавать разработчики, не существует. Действительно, все в Delphi написано на нем же, поэтому разработчики имеют доступ к тем же объектам и инструментам, которые использовались для создания среды разработки. В результате нет никакой разницы между объектами, поставляемыми Borland или третьими фирмами, и объектами, которые можно создать самостоятельно.
В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. На Delphi можно одинаково хорошо писать как приложения к корпоративным базам данных, так и, к примеру, игровые программы. Во многом это объясняется тем, что традиционно в среде Windows было достаточно сложно реализовывать пользовательский интерфейс. Событийная модель в Windows всегда была сложна для понимания и отладки. Но именно разработка интерфейса в Delphi является самой простой задачей для программиста.
Благодаря такой возможности приложения, изготовленные при помощи Delphi, работают надежно и устойчиво. Delphi поддерживает использование уже существующих объектов, включая DLL, написанные на С и С++, OLE сервера, VBX, объекты, созданные при помощи Delphi. Из готовых компонент работающие приложения собираются очень быстро. Кроме того, поскольку Delphi имеет полностью объектную ориентацию, разработчики могут создавать свои повторно используемые объекты для того, чтобы уменьшить затараты на разработку.
Delphi предлагает разработчикам — как в составе команды, так и индивидуальным — открытую архитектуру, позволяющую добавлять компоненты, где бы они ни были изготовлены, и оперировать этими вновь введенными компонентами в визуальном построителе. Разработчики могут добавлять CASE-инструменты, кодовые генераторы, а также авторские help’ы, доступные через меню Delphi

26) правила оформления пп гост 19 еспд

Единая система документации программной продукции – ЕСПД – относится к ГОСТ класса 19 и подразделяется на 10 групп:
1. Основополагающие стандарты.
2. Правила выполнения документации разработки.
3. Правила выполнения документации изготовления.
4. Правила выполнения документации сопровождения.
5. Правила выполнения эксплуатационной документации.
6. Правила обращения программной документации.

Стандарт с номером 0 содержит общие положения, стандарты 7 и 8 являются зарезервированными и к номеру 9 относятся прочие стандарты, не вошедшие в первые 6.

Это краткие описания ГОСТов класса 19, для более подробного ознакомления с ними необходимо обратиться к справочникам.

• ГОСТ 19.001-77 – единая система программной документации.
• ГОСТ 19.101-77 – виды программ и программных документов.
• ГОСТ 19.102-77 – стадии разработки программ и программной документации.
• ГОСТ 19.105-78 – требования к оформлению программных документов, комплексов и систем независимо от их назначения и области применения. ГОСТ 19.105-78 содержит полный перечень документации, которая должна сопровождать законченный программный продукт.

Перечень документации, декларируемой ГОСТ 19.105-78:

1. Документы, содержащие сведения, необходимые для разработки программного продукта, его изготовления.
1.1. Спецификация – состав программы и документации на нее.
1.2. Ведомость держателей подлинников – перечень предприятий, на которых хранятся подлинники программной документации.
1.3. Текст программы – запись текста программы с необходимыми комментариями.
1.4. Описание программы – сведения о логической и функциональной структуре программы.
1.5. Программа и методика испытаний – требования, подлежащие проверке при испытании программы, порядок и методы их контроля.
1.6. Техническое задание – назначение и область применения программы, технические и специальные требования, необходимые стадии и сроки разработки, виды испытаний.
1.7. Пояснительная записка – схема алгоритма, общее описания алгоритма, выполняемая программой функция. Объяснение принятых технических решений.

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

Другие ГОСТы класса 19:

Источник: studopedia.org

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

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

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

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

1. Системная спецификация;
2. План программного проекта;
3. Спецификация требований к программной системе и работающий или бумажный макет;
4. Предварительное руководство пользователя;
5. Спецификация проектирования;
6. Листинги исходных текстов программ;
7. Плановая методика тестирования;
8. Руководство по работе;
9. Исполняемый код программы;
10. Описание базы данных;
11. Руководство пользователя по настройке;
12. Документы сопровождения;
13. Отчеты о проблемах программной системы;
14. Отчеты о конструкторских изменениях;

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

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

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

1. Предусмотреть средства обработки ошибок, которые тестируют все виды информации из других элементов системы;
2. Провести тесты, моделирующие неудачные данные или другие потенциальные ошибки интерфейса программной системы;
3. Записать результаты тестов, чтобы использовать их в качестве доказательства невиновности;
4. Надо принять участие в планировании и проектировании системных тестов, чтобы гарантировать адекватное тестирование программной системы;

1. Тестирование установления.

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

1. Стрессовые тесты.

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

1. Перечислите шаги тестирования программных систем
2. Перечислите шаги методики тестирования восходящей интеграции
3. Охарактеризуйте назначение тестирования правильности
4. Перечислите и охарактеризуйте основные типы системных тестов.

Источник: studfile.net

ЧТО ТАКОЕ ПОДТВЕРЖДАЮЩЕЕ ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ?

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

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

Подтверждающее тестирование также называется повторным тестированием.

Ознакомьтесь с нашим подробным руководством по повторному тестированию

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

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

Подтверждающее тестирование или повторное тестирование — это одно и то же?

Да, подтверждающее тестирование также называется повторным тестированием.

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

Это выполняется неоднократно в каждом новом Agile-спринте.

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

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

Подтверждающее тестирование и регрессионное тестирование — это одно и то же?

Нет, подтверждающее и регрессионное тестирование — это не одно и то же.

Ознакомьтесь с нашим подробным руководством по Регрессионное тестирование.

Как подтверждающее, так и регрессионное тестирование выполняются во время SDLC жизненного цикла разработки программного обеспечения, но эти два метода совершенно разные.

Не путайте повторное тестирование с регрессионным тестированием.

Регрессионное тестирование и повторное тестирование — разные вещи. Ознакомьтесь с нашим подробным руководством о разнице между подтверждающим и регрессионным тестированием здесь.

Когда мы проводим подтверждающее тестирование?

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

1. Каждый раз, когда команда разработчиков выпускает сборку, содержащую исправления ошибок.
2. Перед выполнением регрессионного тестирования для проверки исправления ошибки.
3. Каждый раз, когда команда разработчиков отклоняла ошибку, о которой сообщил тестировщик. Тестировщики проводят подтверждающее тестирование, чтобы воспроизвести ошибку.

Каковы функции подтверждающего тестирования программного обеспечения? >

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

Источник: atesting.ru