Тестирование ( testing ) —процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки.
Комплексное тестирование ( system testing ) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля , если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.
Отладка ( debugging ) не является разновидностью тестирования. Хотя слова » отладка » и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность , направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.
Нельзя сказать, что комплексное тестирование является независимым этапом реализации IT проекта. Скорее, комплексное тестирование – ряд распределенных во времени мер, направленных на выявление соответствия реализуемого решения исходным требованиям и ограничениям.
Введение в Тестирование Программного обеспечения
В данной лабораторной работе мы рассмотрим три основных, с нашей точки зрения, элемента комплексного тестирования.
Комплексное тестирование в VSTS 2008.
По сути, реальное комплексное тестирование можно провести лишь в реальной производственной среде, для которой создается приложение. Однако, если подойти к комплексному тестированию как к процессу контроля (см. определение выше), то можно реализовать его часть средствами VSTS 2008 .
Основным инструментом комплексного тестирования будет конструктор развертывания. Он позволяет выполнить, так называемый, тест на развертывание, в ходе которого проверяется возможность эксплуатации спроектированного продукта в конкретном логическом центре данных. Этот тест завершается успехом или неудачей (если параметры и ограничения приложений и центра данных оказываются несовместимыми), в последнем случае выводится информация, необходимая в устранении проблем.
Часть 1. Тест на развертывание (3 часа)
Тест на развертывание должен выполняться в составе «Инсталляция рабочего места архитектора проекта, основные функции и возможности, создание архитектуры проекта согласно техническому заданию на проект» (освоение рабочего места архитектора). Цель теста – выявить возможность реализации проекта с уже определенной архитектурой в заданном логическом центре данных.
увеличить изображение
Рис. 19.1.
Большая часть проверок на возможность развертывания будет проводиться по мере формирования схемы. Например, если вы попытаетесь разместить приложение, для которого требуется обеспечить взаимодействие по протоколу HTTP , на хосте, не имеющем такой конечной точке, конструктор не позволит это сделать.
Тестирование Программного Обеспечения — урок №1 — Введение
Более сложные нарушения ограничений могут быть неочевидными, пока конструктор не выполнит анализ схемы развертывания.
Для того, чтобы выполнит такой анализ, щелкните правой кнопкой мыши диаграмму развертывания и выберите команду Validate Diagram .
Рис. 19.2.
В процессе анализа просматриваются все документы, связанные с процедурой развертывания, и выводятся сообщения об ошибках и предупреждениях. Их отсутствие означает, что тест пройден успешно.
Задание:
В ходе выполнения «Инсталляция рабочего места архитектора проекта, основные функции и возможности, создание архитектуры проекта согласно техническому заданию на проект» провести тест на развертывание, составить отчет о его результатах и сделать вывод о соответствии логического цента данных (среды разработки) требованиям архитектуры реализуемого проекта. В случае выявления ошибок в процессе выполнения теста – исправить ошибки в проектировании архитектуры проекта.
Часть 2. Отладка проекта (1,5 часа)
Отладка проекта является процессом, длящимся на протяжении всего времени работы над проектом. Ошибки будет выявляться всегда, а соответственно и отладка должна проводиться регулярно
Поскольку отладка подразумевает исправление ранее выявленных ошибок, то средствами VSTS этот процесс может быть налажен следующим образом:
- В процессе выполнения какого-либо теста (предполагается, что чаще всего ошибки находит тестировщик) выявляется ошибка.
- Создается рабочий элемент «Ошибка» ( Bug )
- Создается рабочий элемент «Задача» (Task), в котором разработчику указывается информация об ошибке и указание исправить ее.
При выявлении ошибок в ходе выполнения «Инсталляция рабочего места разработчика проекта, разработка фрагментов проекта» часть из них должна оформляться в идее рабочего элемента «Ошибка», где должно присутствовать подробное описание действий приведших к сбою, также, как правило, ошибке присваивается определенный номер, в соответствии с принятыми стандартами разработки. Затем должен создаваться рабочий элемент «Задача» с указанием исправить ошибку № ****, задача назначается одному – двум исполнителям, которые должны исправить ошибку. По исправлении, исполнители документируют причину ошибки и внесенные изменения и «закрывают» соответствующие рабочие элементы «ошибка» и «задача».
Процесс создания рабочего элемента «Ошибка».
Рис. 19.3.
В окне создания рабочего элемента указывается его название, приоритет, итерация, на которой выявлена ошибка и подробное описание действий, приведших к возникновению ошибки.
увеличить изображение
Рис. 19.4.
Создание рабочего элемента «Задача».
Рис. 19.5.
Процесс создания рабочего элемента «Задача» мало отличается от создания рабочего элемента «Ошибка». Разница в том, что указывается не последовательность действий, а задачи, требующие решения.
В сущности, после создания элемента «Задача», отладкой начинает заниматься разработчик, а именно исправлением какой-то конкретной ошибки, после чего вновь проводится тестирование.
Задание:
Провести отладку выявленных ошибок, процесс отладки см. выше.
Часть 3. Сборка проекта (1,5 часа)
Также к комплексному тестированию можно отнести сборку проекта, поскольку при сборке в соответствии со сценарием компилируется весь имеющийся код, и выполняются определенные тесты.
Задание
Создать сценарий сборки и выполнить ее. Обязательно назначить 1 — 2 теста к выполнению в процессе сборки, исключая нагрузочные тесты (см. «Инсталляция рабочего места разработчика проекта, разработка фрагментов проекта» )
Источник: intuit.ru
Комплексное тестирование
1. Структура программного изделия и правила оформления описания каждого модуля должны быть унифицированы.
2. Каждый модуль должен характеризоваться функциональной законченностью и независимостью в оформлении от модулей, которые его используют и которые его вызывают.
3. Структура программного изделия должна быть представлена в виде совокупности небольших программных модулей, связанных иерархическим образов, что дает возможность полностью и относительно просто уяснить функцию правила работы отдельных частей программного изделия.
4. Созданные на этапе внутреннего проектирования проект проверяется автором внешних спецификаций и разработчиком модулей с целью обеспечения работоспособности, понятности, соответствие инструменту разработки, совместимости с принципами организации модулей, полноты декомпозиции и минимизации доступа к данным.
6 основных характеристик:
Функциональность, надежность, практичность, эффективность, сопровождаемость, мобильность.
Эффективность – способность программных средств обеспечивать необходимую производительность в зависимости от количества используемых ресурсов. Эффективность включает 3 подхарактеристики:
1) Поведение во времени.
2) Использование ресурсов.
Открытая система – это система, состоящая из компонентов, взаимодействующих друг с другом через стандартные интерфейсы.
Комплексное тестирование – это процесс поиска несоответствия системы ее исходным целям. Элементами, участвующими в комплексном тестировании, являются: сама система, описание цели продукта и вся документация, которая будет поставляться вместе с системой.
Если не сформулированы цели продукта или если эти цели не измеримы, тогда комплексное тестирование выполнять невозможно. Комплексное тестирование может быть процессом, как контроля, так и испытания. Процессом испытания оно является тогда, когда выполняется в реальной среде пользователя или в обстановке, которая реально создана, чтобы максимально эмулировать среду пользователя. Когда невозможно рассмотреть выполнение системы в реальной среде пользователя, то комплексное тестирование является процессом контроля.
Виды тестов при выполнении комплексного тестирования.
1. Тестирование стрессов или тестирование с нагрузкой.
При тестировании стрессов делается попытка подвергнуть систему …
2. Тестирование объема.
Представляет собой попытку предъявить система большие объемы данных в течение длительного времени. Цель этого тестирования – показать, что программа не может обрабатывать данные в количестве, указанном в спецификации.
3. Тестирование конфигурации.
Следует тестировать, по крайней мере, минимальную или максимальную конфигурацию. Система должна быть проверена со всяким аппаратным устройством, которое она должна обслуживать или со всякой программой, с которой она должна взаимодействовать. Желательно тестировать каждую конфигурацию, которую допускает программная система.
4. Тестирование совместимости.
Прежде всего, касается версии программных продуктов. Если система представляется собой улучшение прежних версий, то на систему накладывается дополнительное требование, в соответствии с которым взаимодействие пользователей с прежней версией должно полностью сохраниться… Цель тестирования совместимости – показать наличие несовместимостей.
5. Тестирование защиты.
Цель тестирования защиты – нарушить секретность в системе. Для тестирования защиты важно построить такие тесты, которые нарушают программные способы защиты.
6. Тестирование требований к памяти.
С помощью специальных тестов нужно попытаться показать, что система не достигает тех целей в памяти, которые прописаны в сопровождающей документации.
7. Тестирование производительности.
При разработке многих программ ставится задача обеспечения производительности или эффективности. Определяются такие характеристика как: время отклика, уровень пропускной способности при определенной нагрузке. Проверка системы в этом случаи сводится к демонстрации того, что данная программа не соответствует заявленным характеристикам.
8. Тестирование процессов настройки системы очень важно, поскольку одна из наиболее частых ситуаций, с которой сталкивается покупатель, заключается в том, что он оказывает в не состоянии разобраться в системе.
9. Тестирование надежности/готовности.
Надежность – базовая характеристика качества. Ключевой момент заключается в попытке доказать, что система не удовлетворяет к исходным требованиям надежности (среднее время между отказами, количество ошибок, способность к обнаружению, исправлению ошибок и устойчивость к ошибкам).
10. Тестирования средств восстановления.
Важная составная часть к операционным системам, к СУБД, к системам передачи данных – это обеспечение способности к восстановлению. И следует попытаться показать, что эти средства работают неправильно.
11. Тестирование удобства обслуживания.
Требования к продукту, либо в требованиях к проекту должны быть перечислены задачи, определяющие удобства обслуживания (сопровождение системы).
Все документы, описывающие внутреннюю логику, следует проанализировать глазами обслуживающего персонала, чтобы понять как быстро и точно указать причину ошибки, если известны только некоторые ее симптомы. Все средства, обеспечивающие сопровождение и поставляемые вместе с системой должны быть проверенны.
12. Тестирование публикаций.
Проверка точности все документации для пользователя является важной частью комплексного тестирования. Все комплексные тесты стоить строить на основе документации. Пользовательская документация должны быть проверена на точность. Любые примеры, приведенные в документации, следует оформить как тест и проверить при выполнении программ.
13. Тестирование психологических факторов.
На этапе комплексного тестирования могут быть устранены мелкие недостатки, неудобство использования.
14. Тестирования удобства установки.
Процедуры установки некоторых типов систем являются сложными и их следует тестировать на этапе комплексного тестирования.
15. Тестирование удобства эксплуатации.
В этом случаи следует попытаться выявить психологические пользовательские проблемы при эксплуатации программ.
Большинство систем обработки данных являются компонентами более крупных систем, предполагающих деятельность человека, либо сами регламентируют такую деятельность во время своей работы. На этапе комплексного тестирования нужно проверить, что вся эта деятельность удовлетворяет комплексным…
При написании тестов следует проверять все функциональные границы системы, так же следует писать тесты представляющего ошибки пользователя, разрушительные тесты. Тестирования следует осуществлять с точки зрения пользователя или покупателя, что предполагает доскональное понимание того, для чего система будет применяться. Группа тестирования системы должна быть независимая организация и должна включать:
· Профессиональных специалистов по комплексному тестированию систем;
· Пользователей, для которых система разрабатывалась;
· Основных аналитиков и проектировщиков системы;
· И желательно одного или двух психологов.
Все комплексные тесты должны быть подготовлены на основе документации для пользователя. К внешним спецификациям следует обращаться только тогда, когда следует разобраться в противоречиях между системой и публикацией о ней. По своей природе комплексные тесты никогда не сводятся к проверке отдельных функций системы.
Как правило, они пишутся в форме сценариев, представляющих ряд последовательных действий пользователям. Вследствие особых сложностей комплексных тестов, они состоят из трех компонентов: сценария, входных данных и ожидаемых выходных данных. При этом в сценарии точно указываются действия, которые должны быть совершенны во время выполнения теста.
Один из методов, позволяющий привлечь к тестированию пользователей – это опытная эксплуатация. При ее проведении заключаются контракты на установку у них созданной системы. Причем, это выгодно обеим сторонам. Организация разработчик оповещается об ошибках в программном обеспечении, которые она не заметила.
А организация-пользователь позволяет использовать возможность изучить систему до того, как она пойдет в эксплуатацию. Второй метод привлечения пользователей – использовать систему в организации изготовителя для внутренних нужд.
Источник: studopedia.ru
Промежуточное тестирование
Когда несколько компонент связаны между собой данными сложного формата, то изолированное тестирование будет провести достаточно тяжело. Тогда тест строится для некоторого множество компонент и проверяется результат работы всего комплекса.
Комплексное тестирование
Комплексное тестирование проводится уже почти полностью написанной программы. Цель такого тестирование — проверить выполняет ли программа требуемые от нее функции. Обычно на этой стадии определяются дефекты алгоритмов, сложные ошибки, возникшие в результате неверного использования компонент или взаимодействия между ними, и недостатки функциональных возможностей. Если не проводить предварительно изолированное и промежуточное тестирование, то на этой стадии будет слишком много ошибок, чтобы их можно было легко исправить, поэтому придется долго выпускать тестовые версии.
Комплексное тестирование, выполненное разработчиками, называется альфа-тестированием. В результате исправления ошибок появляется так называемая альфа-версия программы.
Обычно альфа-версию поставляют ограниченному кругу конечных пользователей для более жесткого тестирования. Хорошо известно, что пользователи иногда используют программное обеспечение не совсем для тех целей, для которых оно предназначалось. Поэтомy могут обнаружиться неожиданные ошибки в тех местах пpогpаммы, которые разработчики считают абсолютно правильными. Комплексное тестирование программного продукта пользователями называется бетта-тестированием. В результате исправления найденных ошибок появляется бетта-версия программы.
Как правило, бетта-версия проходит еще одно комплексное тестирование у разработчиков (приемочный тест). Чтобы удостовериться, что все ошибки исправлены и не возникло никаких новых проблем. Приемочный тест особенно важен, если программное обеспечение будет разослано большому количеству пользователей.
Стратегии тестирования
Практика работы позволяет выделить две стратегии тестирования:
- Черного ящика (функциональное тестирование)
- Белого ящика (структурное тестирование)
III. Разработка программного продукта и сопровождающей его документации
Постановка задачи
Составить программу и оттестировать ее по методу эквивалентных разбиений (указать возможные ошибки). Тесты составить только для неправильных классов эквивалентности. Пусть имеется несколько функций одного аргумента Х. Для каждой из них требуется распечатать таблицу значений на некотором отрезке. Отрезок [a,b] для каждой функции свой, также для каждой задан шаг изменения аргументаdX. Функции: F1(X) = X*sin(X) a=0.0 b=1.0 dX=0.1 F2(X) = X*cos(X) a=0.5 b=2.1 dX=0.2 F3(X) = a=2.0 b=4.75 dX=0.25
Источник: studfile.net