Файл: Отладка и тестирование программ: основные подходы и ограничения (Этапы, цели и задачи тестирования программного обеспечения).pdf

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

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

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

3.2 Выбор и обоснование методик тестирования

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

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

Для создания ПО приемлемого качества и для значительной экономии времени на создании пользовательского интерфейса было решено использовать библиотеку классов Microsoft Foundation Class.

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

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

Таким образом, был составлен следующий приоритет тестирования в порядке убывания важности:

1. Тестирование функций добавления, редактирования и сохранения информации об услугах

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

3. Тестирование скорости работы

Были выбраны следующие методы ООП тестирования:

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

Тестирование моделированием конечными автоматами было выбрано, т.к. данный метод зарекомендовал себя для проверки взаимодействия объектов ООП.

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

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

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

3.3 Планирование процесса тестирования

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

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

3.4 Разработка тестовых сценариев Use Case

При составлении тестовых сценариев были включены следующие пункты:

1. Состояние программы до начала теста (систему приводит в начальное состояние тестировщик)

2. Последовательность действий

3. Конечное состояние программы / ожидаемый результат

Далее приводятся тестовые сценарии для некоторых функций программы:

Use Case №1: добавление новой услуги

Use Case №2: редактирование информации об услуге

Use Case №3: просмотр информации об услуге

Use Case №4: ввод неверной информации

Use Case №5: выход из программы во время редактирования услуги

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Ехлаков Ю.П. Введение в программную инженерию: учебное пособие. – Томск: Эль Контент, 2011. – 148 с.
2. Липаев В.В. Программная инженерия сложных заказных программных продуктов: Учебное пособие. – М.: МАКС Пресс, 2014. – 312 с.
3. Липаев В.В. Тестирование компонентов и комплексов программ. Учебник. – М.: СИНТЕГ, 2010. – 400 с.
4. Мейер Б. Почувствуй класс.—М.: Национальный Открытый Университет «ИНТУИТ»: БИНОМ. Лаборатория знаний, 2011. —775 с.
5. Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. – СПб.: Питер, 2012. – 608 с.
6. Панюкова Т.А. Документирование программного обеспечения: в помощь техническому писателю: Учебное пособие. – М.: Книжный дом «Либроком», 2012. – 264 с.
7. Перемитина Т.О. Тестирование программного обеспечения: учебное пособие. – Томск: факультет дистанционного обучения ТУСУРа, 2015. - 116 с.
8. Поппендик М., Поппендик Т. Бережливое производство программного обеспечения: от идеи до прибыли. - М. : ООО ‘‘И.Д. Вильямс’’, 2010. - 256 с.
9. Тюгашев А.А., Ильин И.А. Ермаков И.Е. Пути повышения надежности и качества программного обеспечения в космической отрасли // Управление большими системами: сборник трудов Выпуск 39 2012 С. 288-299
10. Уиттакер Дж., Арбон Дж., Каролло Дж. Как тестируют в Google. - СПб. : Питер, 2014. — 320 с.
11. Фролов Е.М., Солдатова М.А. Методика оценки качества прикладного программного обеспечения технического назначения // Известия Волгоградского государственного технического университета. - Выпуск № 8 (135) / том 11 / 2014
12. Testing the limits беседует с Бобом Биндером. // QATesting.ru. [Электронный ресурс]. URL: http://qatesting.ru/blog/interviews/2012/0916utest-bob-binder (дата обращения 16.05.2015)
13. Вудкок Д. Первые шаги к решению проблемы верификации программ. / Открытые системы. – http://www.osp.ru/os/2006/08/3584577/ (дата обращения 5.05.2015)
14. Гуров В.С., Мазин М.А., Шалыто А.А. UniMod – программный пакет для разработки объектно-ориентированных приложений на основе автоматного подхода [Электронный ресурс]. / Информационно-коммуникационные технологии в образовании. – URL: http://www.ict.edu.ru/vconf/index.php?a= vconf&c=getForm&r=thesisDesc&id_sec=143&id_vconf=25&id_thesis=5645&d=light (дата обращения 22.05.2015)
15. Дэвис Ч. Передовой опыт управления тестированием. // IBM.com [Электронный ресурс]. URL: http://www.ibm.com/developerworks/ru/library/1107_davis /index.html (дата обращения 19.05.2015)
16. Зизин М. Концепция создания системного и прикладного программного обеспечения задач математического моделирования. // AtomInfo.ru. [Электронный ресурс]. URL: http://www.atominfo.ru/news4/d0185.htm (дата обращения: 15.04.2015).
17. Карпов Ю. Синдром «146%»: некомпетентность или злой умысел? // Открытые системы [Электронный ресурс]. URL: http://www.osp.ru/os/2014/05/ 13041826/ (дата обращения 10.05.2015)
18. Количественное управление процессом тестирования. // Тестирование и качество ПО [Электронный ресурс]. URL: http://www.software-testing.ru/library/around-testing/processes/309-quantitative-process-management (дата обращения 18.05.2015)
19. Михайлов А. Тестирование объектно-ориентированных программных систем. // Объектно-ориентированный анализ и проектирование [Электронный ресурс]. URL: http://ooad.asf.ru/standarts/Library/OORP/List10.aspx (дата обращения 19.05.2015)
20. https://ru.wikipedia