Тестирование ПО. Тестирование. Реферат актуальность. Основной всплеск интереса к теме тестирования пришёлся на 90е годы и начался в сша. Бурное развитие систем автоматизированной разработки
 Скачать 2.21 Mb.
|
|
Необходимая часть любого теста — описание ожидаемых выходных данных или результатов. Одна из самых распространенных ошибок при тестировании состоит в том, что результаты каждого теста не прогнозируются до его выполнения. Ожидаемые результаты нужно определять заранее, чтобы не возникла ситуация, когда глаз видит то, что хочет увидеть. Чтобы совсем исключить такую возможность, лучше разрабатывать самопроверяющиеся тесты, либо пользоваться инструментами тестирования, способными автоматически сверять ожидаемые и фак- тические результаты. Иногда, например, при тестировании математического программного обеспечения, при- ходится допускать исключения. Математическое программное обеспечение обладает тем свойством, что выходные данные являются только приближением правильного результата. Это происходит из-за использования конечных вычислительных процессов вместо бесконечных математических процессов, из-за ошибок округления, связанных с конечной точностью машинной арифметики и неточностью представления чисел, а также ошибок из-за конечной точности представления входных данных и констант. Поэтому во многих случаях оказывается важной не абсолютная точность, а корреляция ошибок. Например, когда математическая программа 29 возвращает массив чисел, может оказаться важным, чтобы вычисленное решение было точным решением для набора входных данных, аппроксимирующего реальные выходные данные. Поэтому при тестировании математического программного обеспечения прогнозирование точных выходных данных затруднительно. Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных. При тестировании программ имеется естественная тенденция концентрировать внимание на правильных и предусмотренных входных условиях, а неправильным и непредусмотренным входным данным не придавать значения. Например, при тестировании задачи о треугольниках, лишь немногие смогут привести в качестве теста длины сторон 1, 2 и 5, чтобы убедиться в том, что треугольник не будет ошибочно интерпретирован как неравносторонний. Многие ошибки, которые потом неожиданно обнаружи- ваются в работающих программах, проявляются вследствие никак не предусмотренных действий пользователя программы. Тесты, представляющие неожиданные или неправильные входные данные, часто лучше обнаруживают ошибки, чем правильные тесты. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать. Это логически вытекает из предыдущего принципа. Необходимо проверить программу на нежелательные побочные эффекты. Например, программа расчета зарплаты, которая производит правильные платежные чеки, окажется неверной, если она произведет лишние чеки для работающих или дважды запишет первую запись в список личного состава. Детально изучать результаты каждого теста. Самые изощренные тесты ничего не стоят, если их результаты удостаиваются лишь беглого взгляда. Тестирование программы означает большее, нежели выполнение достаточного количества тестов; оно также предполагает изучение результатов каждого теста. Не следует выбрасывать тесты, даже если программа уже не нужна. Эта проблема наиболее часто возникает при использовании интерактивных систем отладки. После внесения изменений или исправления ошибок необходимо повторять тестирование, тогда приходится заново изобретать тесты. Как правило, этого стараются избегать, поскольку повторное создание тестов требует значительной работы. В результате повторное тестирование бывает менее тщательным, чем первоначальное, т. е. если модификация затронула функциональную часть программы и при этом была допущена ошибка, то она зачастую может остаться необнаруженной. Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены. Такую ошибку обычно допускают руководители проекта, использующие неверное определение тестирования как процесса демонстрации отсутствия ошибок в программе, корректного функционирования программы. 30 По мере того как число ошибок, обнаруженных в некотором компоненте программного обеспечения, увеличивается, растет относительная вероятность существования в нем необнаруженных ошибок. Ошибки образуют кластеры, т. е. встречаются группами. С ростом числа ошибок, обнаруженных в компоненте программы (например, в модуле, подсистеме, функции пользователя), увеличивается также вероятность существования в этом компоненте еще не обнаруженных ошибок. Если при тестировании двух модулей в них обнаружены одна и восемь ошибок соответственно, кривая показывает, что для модуля с восьмью ошибками вероятность того, что в нем еще есть ошибки, выше. Тестирование, как почти всякая другая деятельность, должно начинаться с постановки целей. Цикл тестирования подобен полному циклу разработки программного обеспечения. Тесты должны быть спроектированы, реализованы, проверены и, наконец, выполнены. Поэтому задачи тестирования должны быть сформулированы на каждом его этапе, например, для каждого конкретного типа тестирования должны быть определены ориентиры (число пройденных путей, проверенных условных переходов и т. п.) и доля ошибок, которые должны быть обнаружены на этом этапе. Тестирование — процесс творческий. Для тестирования большой программы требуется больший творческий потенциал, чем для ее проектирования [10]. 7.3 Планирование тестирования 7.3.1 Вопросы, определяющие процесс планирования Процесс тестирования находится в прямой зависимости от процесса разработки программного обеспечения, но при этом сильно отличается от него, поскольку преследует другие цели. Разработка ориентирована на построение программного продукта, тогда как тестирование отвечает на вопрос, соответствует ли разрабатываемый программный продукт требованиям, в которых зафиксирован первоначальный замысел изделия (т.е. то, что заказал заказчик). Вместе оба процесса охватывают виды деятельности, необходимые для получения качественного продукта. Ошибки могут быть привнесены на каждой стадии разработки. Следовательно, каждому этапу разработки должен соответствовать этап тестирования. Отношения между этими процессами таковы, что если что-то разрабатывается, то оно подвергается тестированию, а результаты тестирования используются для определения, соответствует ли это "что-то" набору предъявляемых требований. Процесс тестирования возвращает выявленные им ошибки в процесс разработки. Процесс разработки передает процессу тестирования новые и исправленные проектные версии. Как было отмечено выше, процесс тестирования тесно связан с процессом разработки. Соответственно планирование тестирования тоже зависит от выбранной модели разработки. 31 Однако вне зависимости от модели разработки при планировании тестирования необходимо ответить на пять вопросов, определяющих этот процесс: кто будет тестировать и на каких этапах? Разработчики продукта, независимая группа тестировщиков или совместно; какие компоненты надо тестировать? Будут ли подвергнуты тестированию все компоненты программного продукта или только компоненты, которые угрожают наибольшими потерями для всего проекта; когда надо тестировать? Будет ли это непрерывный процесс, вид деятельности, выполняемый в специальных контрольных точках, или вид деятельности, выполняемый на завершающей стадии разработки; как надо тестировать? Будет ли тестирование сосредоточено только на проверке того, что данный продукт должен выполнять, или также на том, как это реализовано; в каком объеме тестировать? Как определить, в достаточном ли объеме выполнено тестирование, или как распределить ограниченные ресурсы, выделенные под тестирование. Все ответы на поставленные вопросы и многое другое фиксируется в документе – Тест план. 7.3.2 Тест план Тест план (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Тест план содержит: 1) перечень тестовых ресурсов; 2) перечень функций и подсистем, подлежащих тестированию; 3) тестовую стратегию: анализ функций и подсистем с целью определения слабых мест, требующих исчерпывающего тестирования, то есть участков функциональности, где появление дефектов наиболее вероятно; определение стратегии выбора входных данных для тестирования. Поскольку в реальных применениях множество входных данных программного продукта практически бесконечно, выбор конечного подмножества для проведения тестирования является сложной задачей. Для ее решения могут быть применены методы покрытия классов входных и выходных данных, анализ крайних значений, 32 покрытие случаев использования и т.п. Выбранная стратегия должна быть обоснована и задокументирована; определение потребности автоматизации процесса тестирования. При этом решение об использовании существующей, либо о создании новой автоматизированной системы тестирования должно быть обосновано, а также продемонстрирована оценка затрат на создание новой системы или на внедрение уже существующей. 4) график (расписание) тестовых циклов; 5) указание конкретных параметров аппаратуры и программного окружения; 6) определение тестовых метрик, которые необходимо собирать и анализировать, таких как покрытие набора требований, покрытие кода, количество и уровень серьезности дефектов, объем тестового кода и т.п. Тест план должен как минимум отвечать на следующие вопросы: 1) что надо тестировать? Описание объекта тестирования: системы, приложения, оборудование; 2) что будете тестировать? Список функций и описание тестируемой системы и её компонент в отдельности; 3) как будете тестировать? стратегия тестирования, а именно: методологии, виды тестирования и их применение по отношению к тестируемому объекту, приоритеты, автоматизация и пр.; 4) когда будете тестировать? Последовательность проведения работ: фазы, циклы тестирования, процедура тестирования - подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки; 5) где будете тестировать? окружение тестируемой системы – описание; необходимое для тестирования оборудование и программные средства. 6) кто будет тестировать? роли и обязанности; имена и фамилии. 7) критерии начала тестирования: готовность окружения; готовность тест кейсов; законченность разработки требуемого функционала; выполнение юнит-тестов; 33 билд построен и удовлетворяет определенным критериям. 8) критерии окончания тестирования: результаты тестирования удовлетворяют определенным критериям; требования к количеству открытых багов выполнены (определяются заранее). 9) критерии передачи системы для приемочного тестирования: приемочные тесты – где хранятся и когда выполняются; процедура приемки. 10) какие риски существую и как мы ими будет управлять? Риски и их разрешение 11) метрики и отчеты: продуктовые метрики – кто собирает, с какой периодичностью; отчеты - кто создает, кому отправляет, и т.п. 12) расписание билдов. Ответив в тест плане на вышеперечисленные вопросы, можно считать, что у на руках есть хороший черновик документа по планированию тестирования. Далее, чтобы документ приобрел более менее серьезный вид, предлагается дополнить его следующими пунктами: окружение тестируемой системы (описание программно-аппаратных средств); необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.); риски и пути их разрешения. 7.3.3 Виды тест планов Чаще всего на практике приходится сталкиваться со следующими видами тест планов: 1) мастер тест план (Master Plan or Master Test Plan); 2) тест план (Test Plan); 3) план приемочных испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием: стратегия, дата проведения, ответственные и т.д.; 4) план автоматизации (Test Automation Plan) - документ, описывающий набор действий, связанных с автоматизацией тестированием: стратегия, правила, ответственные и т.д. Явное отличие Master Test Plan от просто Test Plan в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам 34 тестировании, расписанию выполнения работ, является "живым"документом, который постоянно претерпевает изменения, отражающие реальное положение вещей на проекте. В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения [11]. 7.4 Тестовый случай (Test case). Виды. Структура. Тестовый случай (Test Case) – это – минимальный элемент тестирования (всего одна верификация\проверка); – совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части; – описание определенных действий и условий, которые необходимы для того, чтобы выявить тот или иной баг. Под тест кейсом понимается структура вида: Action > Expected Result > Test Result. В таблице 7.1 показан пример test case. Таблица 7.1 - Пример тестового случая Action Expecred Result Test Result (passed/failed/blocked) Open page "Login" Login page is opened Passed 7.4.1 Виды Тестовых Случаев Тест кейсы разделяются по ожидаемому результату на позитивные и негативные: позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию; негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора. 7.4.2 Структура Тестовых Случаев (Test Case Structure) Каждый тест кейс должен состоять из трех частей. В таблице 7.2 показаны эти части. 35 Таблица 7.2 - Структура Test case Pre conditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния. Test case description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям Post conditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state) Примечание: Post Conditions не является обязательной частью. Эта часть актуальна при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов. Пример тест кейса do A1, verify B1 do A2, verify B2 do A3, verify B3 В приведенном примере конечная проверка - В3. Это значит, что именно она является ключевой. Значит, A1 и А2 - это действия приводящие систему в тестопригодное состояние. А В1 и В2 - условия того, что система находится в состоянии пригодном для тестирования. Таким образом в таблице 7.3 показано условие тест кейса. Таблица 7.3 - Условие тест кейса Action Expected Result Test Result (passed/failed/blocked) Preconditions do A1 verify B1 do A2 verify B2 Test Case Description do A3 verify B3 Postconditions PostConditions в данном примере не были описаны, но по логике вещей надо выполнить шаги, которые бы вернули систему в первоначальное состояние. (например, удалили созданную запись, или отменили бы изменения сделанные в документе) Нужно ответить на вопрос: "Почему данное разбиение удобно использовать?" 36 Ответ в таблице 7.4: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает. Таблица 7.4 - Один из вариантов результата Action Expected Result Test Result (passed/failed/blocked) Preconditions do A1 verify B1 passed do A2 verify B2 failed Test Case Description do A3 verify B3 blocked Postconditions 7.4.3 Детализация описания тест кейсов Уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кейсов. В таблице 7.5 можно увидеть пример детализации тест кейса: Таблица 7.5 - Пример тест кейса 1 Проверка отображения страницы Действие |