Цели И Задачи Тестирования По
Цели и задачи тестирования ПО в разрезе задач обеспечения качества ПО и некоторые мысли по автоматизации тестирования ПО.
У тестировщика три основных задачи:
1. выявить как можно больше существующих дефектов и
2. проверить, что они устранены и
3. при устранении известных дефектов не были внесены новые баги (проверка целостности).
Не согласен с приоритетами в целом, но соглашусь с некоторыми выводами в разрезе задач автоматизации тестирования ПО.
Постараюсь кратко, но не обещаю:
1. Выявление ошибок не есть цель тестирования ПО.
2. Основной задачей тестирования ПО является получение информации о статусе готовности заявленной функциональности системы или приложения.
3. Задача получения статуса готовности обычно реализуется как проверка сценариев использования системы в валидных и невалидных условиях использования, которые формируются наборами входных данных и состояний, операций или пеолучаемых тестируемым функционалом данных и набором выходных данных и состояний системы.
Словарь тестировщика: что такое #тестирование ПО и какие цели тестирования
4. Выявленные ошибки это побочный результат отработки задачи тестирования ПО, так как напрямую не являются нужной и полезной Заказчику тестирования информацией.
5. Количество найденных в процессе тестирования ошибок никак не характеризует уровень качества конечного продукта, а может выступать метрикой качества или зрелости самого процесса разработки ПО.
6. Количество найденных в процессе тестирования ошибок никак не характеризует целесообразность затрат ресурсов на проведение тестирования, так как напрямую зависит в основном от состояния продукта на момент начала тестирования и в меньшей степени от степени подготовленности/спланированности тестирования.
Теперь посмотрим на задачи автоматизации тестирования ПО с точки зрения приведённых выше задач тестирования ПО ибо автоматизация не есть вещью в себе, а является просто подходом к выполнению задач тестирования, эффективность которого по сравнению с ручным тестированием зависит от конкретных переменных проектного окружения: длительность проекта, готовность проекта к автоматизации на разных структурынх уровнях и т.д..
Автоматизировать можно и нужно только то, что автоматизации требует, а не те функциональные модули, где автоматизацию можно применить.
Что значит требует?
Занимает много времени при ручном тестировании (повторяется циклически многократно и/или требует множества автоматизируемых операций перед проверкой ключевой функциональности, как например проверка операции закрытия переода в биллинге, тестирование которой требует введения данных о потреблении услуг) и может в перспективе с учётом затрат на приобретение и внедрение инструмента автоматизации окупиться в бюджете проекта. Финансовая окупаемость — это единственный фактор, который определяет целесообразность внедрения автоматизации тестирования ПО в проекте. Зачастую на финансовую окупаемость может положительно влиять внедрение практик и инструментов автоматизированного тестирования на уровне компании, а не отдельно взятого проекта.
Тестировщик (QA) — кто это? Какие бывают типы тестирования?
Что значит целесообразность внедрения на практике.
Модульное тестирование
Прогон всех модульных тестов на интеграционном окружении во время сборки версии системы является первым этапом автоматизации. Имеет ли смысл вкладывать ресурсы в модульное тестирование?
Если вопрос возник, культура разработки в проекте находится на достаточно низком уровне. Продукт приходит в тестирование стабильно сырым, исправление ошибок вызывает циклическое появление новых ошибок в связанном функционале. Скорее всего поможет внедрение практик модульного тестирования, что приводит к более целосному коду, который выходит из группы разработки. При этом модульные тесты являются первыми же приёмочными тестами и невыполнение полного набора модульных тестов автоматически заворачивает сборку версии/билда. При этом модульное тестирование не есть самоцель, а только инструмент предварительного контроля качества кода на модульном уровне.
Если на этом уровне проблемы не хронические, версии выходят готовые к тестированию, значит группа разработки своими ресурсами обеспечивает целосность кода (обычно в таких проектах за целосность выкатки отвечает тим лид, который строит версию на своей машине и сам проводит начальное тестирование – до тех пор, пока ему это не надоедает и он сам начинает гонять разработчиков на предмет покрытия юнитами). Требовать группой тестирования от разработки вложений ресурсов в модульное тестирование, не имея веских оснований уровня многократых перевыкаток версии после дымового тестирования или возникновения связанных ошибок я бы не стал.
Автоматизация набора регрессионных тестов
Я не совсем понимаю этузадачу как вид тестирования и для себя не выделяю, но формулировки в форумах встречаются именно такие. Для меня структура тестов любого функционала примерно следующая:
1. Полный или основной тестовый набор, покрывающий всю функциональность тестовой области. Ревьювится перед каждым прогоном полного цикла тестирования на предмет изменений в спецификациях и критических исправлений/доработках. Обновляется/актуализируется по результатам ревью.
2. Короткий список (обычно только позитивные тесты основанные на наиболее приоритетных сценариях использования). Включается в цикл дымового тестирования или другими словами в набор тестов приёмочной фазы тестирования. Составляется в процессе создания тестового набора.
Ревьювится перед каждым прогоном набора приёмочных тестов, по сути перед каждым раундом тестирования при выкатке новой версии. Обновляется/актуализируется в момент актуализации основного тестового набора. Удобно вести в том же артефакте что и основной тестовый набор с возможностью автоматизированного включения в тестовый набор дымового/приёмочного тестирования.
Регрессионным тестовым набором системы , в моём понимании, является сумма всех наборов тестов всех тестовых областей. Регрессионное тестирование, по сути, является функциональным тестированием с той разницей, что целью такого тестирования проверка отсуствия регрессии системы. Вкладывать ресурсы в регрессионное тестирование как выделенный этап работ как я бы не стал, так как результатаы регресии системы станут очевидны после прогона полного тестового набора функциональных тестов и тестов производительности (система может регрессировать по любому из аспектов качества ПО включая производительность, функциональность и надёжность). Если проведение полного цикла тестирования удобнее или нагляднее выносить в отдельный этап работ и называть его как-то надо 🙂 то можно называть его и регрессионными тестами. Только не надо потом думать над задачами автоматизации в разрезе этой привнесённой выделенности регрессионного тестирования.
Иногда в планы автоматизации может вмешиваться задача автоматизации тестирования какого-то выделенного компонента, например от стороннего разработчика, функционал которого как бы оборачивается прослойкой автоматизированных тестов, для снижения рисков связянных с неполным контролем качества поставляемого этим разработчиком модулей или компонентов. Если таким компонентом является что-то, что используется в системе несколькими модулями системы, скорее всего прийдётся идти по принципу точечной автоматизации именно в разрезе автоматизации тестирования этого выделенного списка функций. Например, уровень работы с базой данных может стать таким узким местом, если кому-то пришлось отказываться от поставляемых в составе СУБД драйверами.
Что попадает в набор тестов для автоматизации определяется всё тем же основным принципом экономической рациональности и в каждом конкретном тестовом наборе.
Источник: software-testing.ru
ЦЕЛИ , ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ .
Программный комплекс — это совокупность программных модулей, предназначенных для решения одной задачи и составляющих одно целое.
Основными разновидностями контроля программного обеспечения являются визуальный, статический и динамический.
Визуальный контроль — это проверка программ “ за столом “ , без использования компьютера. На первом этапе визуального контроля осуществляется чтение программы, причем особое внимание уделяется следующим ее элементам:
1. комментариям и их соответствию тексту программы ;
2. условиям в операторах условного выбора ( IF, CASE ) и цикла;
3. сложным логическим выражениям;
4. возможности незавершения итерационных циклов ( WHILE, REPEAT, LOOP ).
Второй этап визуального контроля — сквозной контроль программы
( ее ручная прокрутка на нескольких заранее подобранных простых тестах). Распространенное мнение , что более выгодным является перекладывание большей части работы по контролю программных средств на компьютере, ошибочно. Основной довод в пользу этого таков : при работе на компьютере главным образом совершенствуются навыки в использовании клавиатуры, в то время как программистская квалификация приобретается прежде всего за столом.
Статический контроль- это проверка программы по ее тексту (без выполнения) с помощью инструментальных средств. Наиболее известной формой статического контроля является синтаксический контроль программы с помощью компилятора , при котором проверяется соответствие текста программы синтаксическим правилам языка программирования.
Сообщения компилятора обычно делятся на несколько групп в зависимости от уровня тяжести нарушения синтаксиса языка программирования :
1. информационные сообщения и предупреждения , при обнаружении которых компилятор, как правило, строит корректный объектный код и дальнейшая работа с программой (компоновка, выполнение) возможна (тем не менее сообщения этой группы также должны тщательно анализироваться, так как их появление также может свидетельствовать об ошибке в программе — например, из-за неверного понимания синтаксиса языка);
2. сообщения об ошибках, при обнаружении которых компилятор пытается их исправить и строит объектный код, но его корректность маловероятна и дальнейшая работа с ним скорее всего не возможна;
3. сообщения о серьезных ошибках , при наличии которых построенный компилятором объектный код заведомо некорректен и его дальнейшее использование невозможно;
4. сообщения об ошибках , обнаружение которых привело к прекращению синтаксического контроля и построения объектного кода .
Однако, практически любой компилятор пропускает некоторые виды синтаксических ошибок. Место обнаружения ошибки может находиться далеко по тексту программы от места истинной ошибки, а текст сообщения компилятора может не указывать на истинную причину ошибки. Одна синтаксическая ошибка может повлечь за собой генерацию компилятором нескольких сообщений об ошибках (например, ошибка в описании переменной приводит к появлению сообщения об ошибке в каждом операторе программы, использующем эту переменную).
Второй формой синтаксического контроля может быть контроль структурированности программ, то есть проверка выполнения соглашений и ограничений структурного программирования. Примером подобной проверки может быть выявление в тексте программы ситуаций, когда цикл образуется с помощью оператора безусловного перехода (использования оператора GOTO для перехода вверх по тексту программы ). Для проведения контроля структурированности могут быть созданы специальные инструментальные средства, а при их отсутствии эта форма статического контроля может совмещаться с визуальным контролем .
Третья форма статического контроля — контроль правдоподобия программы, то есть выявление в ее тексте конструкций, которые хотя и синтаксически корректны, но скорее всего содержат ошибку или свидетельствуют о ней. Основные неправдоподобные ситуации :
1. использование в программе неинициализированных переменных (то есть переменных, не получивших начального значения) ;
2. наличие в программе описаний элементов, переменных, процедур, меток, файлов, в дальнейшем не используемых в ее тексте;
3. наличие в тексте программы фрагментов, никогда не выполняющихся;
4. наличие в тексте программы переменных, ни разу не используемых для чтения после присваивая им значений;
5. наличие в тексте программы заведомо бесконечных циклов ;
Даже если присутствие в тексте программы неправдоподобных конструкций не приводит к ее неправильной работе, исправление этого фрагмента повысит ясность и эффективность программы, т. е. благотворно скажется на ее качестве.
Для возможности проведения контроля правдоподобия в полном объеме также должны быть созданы специальные инструментальные средства, хотя ряд возможностей по контролю правдоподобия имеется в существующих отладочных и обычных компиляторах.
Следует отметить, что создание инструментальных средств контроля структурированности и правдоподобия программ может быть существенно
упрощено при применении следующих принципов:
1) проведение этих дополнительных форм статического контроля после завершения компиляции и только для синтаксически корректных программ ;
2) максимальное использование результатов компиляции программы и, в частности, информации, включаемой в листинг компилятора;
3) вместо полного синтаксического разбора текста проверяемой программы построение для нее списка идентификаторов и списка операторов с указанием всех их необходимых признаков.
При отсутствии инструментальных средств контроля правдоподобия эта фаза статического контроля также может объединяться с визуальным контролем.
Четвертой формой статического контроля программ является их верификация, то есть аналитическое доказательство их корректности.
В интуитивном смысле под корректностью понимают свойства программы, свидетельствующие об отсутствии в ней ошибок, допущенных разработчиком на различных этапах проектирования ( спецификации, проектирование алгоритма и структур данных, кодирование ). Корректность самой программы по отношению к целям, поставленным перед ее разработкой ( то есть это относительное свойство ). Отличие понятия корректности и надежности программ в следующем :
— надежность характеризует как программу, так и ее “окружение” ( качество аппаратуры, квалификацию пользователя и т.п. );
— говоря о надежности программы, обычно допускают определенную, хотя и малую, долю ошибок в ней и оценивают вероятность их появления.
Надежность можно представить совокупностью следующих характеристик :
1) целостность программного средства (способность его к защите от отказов);
2) живучесть (способность к входному контролю данных и их проверки в ходе работы) ;
3) завершенность (бездеффектность готового программного средства, характеристика качества его тестирования);
4) работоспособность (способность программного средства к восстановлению своих возможностей поле сбоев).
Очевидно, что не всякая синтаксически правильная программа является корректной в указанном выше смысле, т. е. корректность характеризует семантические свойства программ.
С учетом специфики появления ошибок в программах можно выделить две стороны понятия корректности :
— корректность как точное соответствие целям разработки программы (которые отражены в спецификации) при условии ее завершения или частичная корректность ;
— завершение программы , то есть достижение программой в процессе ее выполнения своей конечной точки.
В зависимости от выполнения или невыполнения каждого из двух названных свойств программы различают шесть задач анализа корректности :
1) доказательство частичной корректности ;
2) доказательство частичной некорректности ;
3) доказательство завершения программы ;
4) доказательство незавершения программы ;
5) доказательство тотальной (полной ) корректности (то есть одновременное решение первой и третьей задач);
6) доказательство некорректности (решение второй или четвертой задачи).
Методы доказательства частичной корректности программ как правило опираются на аксиоматический подход к формализации семантики языков программирования. В настоящее время известны аксиоматические семантики Паскаля, подмножества ПЛ/1 и некоторых других языков.
Аксиоматическая семантика языка программирования представляет собой совокупность аксиом и правил вывода. С помощью аксиом задается семантика простых операторов языка (присваивания, ввода — вывода, вызова процедур). С помощью правил вывода описывается семантика составных операторов или управляющих структур (последовательности, условного выбора, циклов). Среди этих правил вывода надо отметить правило вывода для операторов цикла так как оно требует знания инварианта цикла (формулы, истинности которой не изменяется при любом прохождении цикла).
Построение инварианта для оператора цикла по его тексту является алгоритмически не разрешимой задачи, поэтому для описания семантики циклов требуется своего рода ”подсказка” от разработчика программы.
Наиболее известным из методов доказательства частичной корректности программ является метод индуктивных утверждений предложенный Флойдом и усовершенствованный Хоаром. Метод состоит из трех этапов.
Первый этап — получение аннотированной программы. На этом этапе для синтаксически правильной программы должны быть заданы утверждения на языке логики предикатов первого порядка :
— по одному утверждению для каждого цикла (эти утверждения задаются для входной точки цикла и должны характеризовать семантику вычислений в цикле).
Доказательство неистинности условий корректности свидетельствует о неправильности программы, или ее спецификации, или программы и спецификации.
Несмотря на достаточную сложность процесса верификации программы и на то, что даже успешно завершенная верификация не дает гарантий качества программы ( т.к. ошибка может содержаться и в верификации ), применение методов аналитического доказательства правильности очень полезно для уточнения смысла разрабатываемой программы, а знание этих методов благотворно сказывается на квалификации программиста.
Наконец, динамический контроль программы — это проверка правильности программы при ее выполнении на компьютере, т.е. тестирование.
ЦЕЛИ , ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ .
Каждому программисту известно, сколько времени и сил уходит на отладку и тестирование программ. На этот этап приходится около 50% общей стоимости разработки программного обеспечения.
Но не каждый из разработчиков программных средств может верно определить цель тестирования. Нередко можно услышать, что тестирование — это процесс выполнения программы с целью обнаружения в ней ошибок. Но эта цель недостижима : ни какое самое тщательное тестирование не дает гарантии, что программа не содержит ошибок.
Другое определение тестирования ( у Г. Майерса ) тестирование — это процесс выполнения программы с целью обнаружения в ней ошибок. Такое определение цели стимулирует поиск ошибок в программах. Отсюда также ясно, что “удачным” тестом является такой, на котором выполнение программы завершилось с ошибкой. Напротив, “неудачным можно назвать тест, не позволивший выявить ошибку в программе.
Определение Г. Майерса указывает на объективную трудность тестирования : это деструктивный ( т.е. обратный созидательному ) процесс. Поскольку программирование — процесс конструктивный, ясно, что большинству разработчиков программных средств сложно “переключиться” при тестировании созданной ими продукции.
У Майерса сформулированы также основные принципы организации тестирования :
1) необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы, чтобы можно было быстро выяснить наличие или отсутствие ошибки в ней ;
2) следует по возможности избегать тестирования программы ее автором, т.к. кроме уже указанной объективной сложности тестирования для программистов здесь присутствует и тот фактор, что обнаружение недостатков в своей деятельности противоречит человеческой психологии ( однако отладка программы эффективнее всего выполняется именно автором программы ) ;
3) по тем же соображениям организация — разработчик программного обеспечения не должна “единолично ” его тестировать ( должны существовать организации, специализирующиеся на тестировании программных средств ) ;
4) должны являться правилом доскональное изучение результатов каждого теста, чтобы не пропустить малозаметную на поверхностный взгляд ошибку в программе ;
5) необходимо тщательно подбирать тест не только для правильных ( предусмотренных ) входных данных, но и для неправильных (непредусмотренных) ;
6) при анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать ;
7) следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика) ;
8) тестирования не должно планироваться исходя из предположения, что в программе не будут обнаружены ошибки (в частности, следует выделять для тестирования достаточные временные и материальные ресурсы) ;
9) следует учитывать так называемый “принцип скопления ошибок” : вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части ;
10) следует всегда помнить , что тестирование — творческий процесс, а не относиться к нему как к рутинному занятию.
Существует два основных вида тестирования : функциональное и структурное. При функциональном тестировании программа рассматривается как “черный ящик” (то есть ее текст не используется). Происходит проверка соответствия поведения программы ее внешней спецификации. Возможно ли при этом полное тестирование программы ? Очевидно , что критерием полноты тестирования в этом случае являлся бы перебор всех возможных значений входных данных, что невыполнимо .
Поскольку исчерпывающее функциональное тестирование невозможно, речь может идти о разработки методов, позволяющих подбирать тесты не “вслепую”, а с большой вероятностью обнаружения ошибок в программе.
При структурном тестировании программа рассматривается как “белый ящик” (т.е. ее текст открыт для пользования ). Происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей на графе передач управления программы (ее управляющем графе). Даже для средних по сложности программ числом таких путей может достигать десятков тысяч. Если ограничиться перебором только линейных не зависимых путей, то и в этом случае исчерпывающее структурное тестирование практически невозможно, т. к. неясно, как подбирать тесты , чтобы обеспечить “покрытие” всех таких путей. Поэтому при структурном тестировании необходимо использовать другие критерии его полноты, позволяющие достаточно просто контролировать их выполнение, но не дающие гарантии полной проверки логики программы.
Но даже если предположить, что удалось достичь полного структурного тестирования некоторой программы, в ней тем не менее могут содержаться ошибки, т.к.
1) программа может не соответствовать своей внешней спецификации, что в частности, может привести к тому, что в ее управляющем графе окажутся пропущенными некоторые необходимые пути ;
2) не будут обнаружены ошибки, появление которых зависит от обрабатываемых данных (т.е. на одних исходных данных программа работает правильно, а на других — с ошибкой).
Таким образом, ни структурное, ни функциональное тестирование не может быть исчерпывающим. Рассмотрим подробнее основные этапы тестирования программных комплексов.
В тестирование многомодульных программных комплексов можно выделить четыре этапа :
· тестирование отдельных модулей ;
· совместное тестирование модулей ;
· тестирование функций программного комплекса (т.е. поиск различий между разработанной программой и ее внешней спецификацией ) ;
· тестирование всего комплекса в целом (т.е. поиск несоответствия созданного программного продукта сформулированным ранее целям проектирования, отраженным обычно в техническом задании).
На первых двух этапах используются прежде всего методы структурного тестирования, т.к.
на последующих этапах тестирования эти методы использовать сложнее из-за больших размеров проверяемого программного обеспечения ;
последующие этапы тестирования ориентированы на обнаружение ошибок различного типа, которые не обязательно связаны с логикой программы.
При тестировании как отдельных модулей, так и их комплексов должны быть решены две задачи :
1) построение эффективного множества тестов ;
2) выбор способа комбинирования (сборки) модулей при создании трестируемого варианта программы .
Источник: megaobuchalka.ru