4-software_engineering_testing (1133544), страница 5
Текст из файла (страница 5)
Соответствующие метрики позволяют оценить степень охвата характеристиксистемы (например, процент различных тестируемых параметров производительности) и глубину ихдетализации (например, случайное тестирование параметров производительности или с учетомграничных значений и т.п.). Такие метрики помогают прогнозировать вероятностное достижениезаданных параметров качества системы.4.2.2 Введение искусственных дефектов (Fault seeding)“Своими руками?! Никогда! ...” – такова, обычно, первая реакция на идею искусственного внесениядефектов, например, в программный код.
На практике, этот подход помогает классифицироватьвозможные ошибки и следующие за ними сбои, применяя в дальнейшем полученные результаты длямоделирования (пусть, часто, и интуитивного) возможных причин реальных сбоев, обнаруженных впроцессе тестирования.Безусловно, данная техника должна использоваться с максимальной осторожностью опытнымиспециалистами, хорошо представляющими общую архитектуру тестируемой программной системы иразбирающимеся во еѐ внутренних связях.4.2.3 Оценка мутаций (Mutation score)Получаемое в процессе тестирования мутаций (см.
выше 3.4.2) отношение “убитых” к общему числусгенерированных мутантов помогает измерить эффективность выполняемых тестов. В силуспецифики такой техники тестирования, количественные оценки мутаций имеют практическоезначение только для определенных типов систем.4.2.4 Сравнение и относительная эффективность различных техник тестирования (Comparison andrelative effectiveness of different techniques)Различные исследования в области тестирования связаны с попытками сравнения (с точки зрениядостигаемого качества продукта) разных подходов к тестированию. Когда мы говорим обCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru12Основы программной инженерии (по SWEBOK)Программная инженерия. Тестирование программного обеспечения.“эффективности” тестирования надо чѐтко договориться, что именно мы подразумеваем подэффективностью, желательно, в количественном выражении. Возможные варианты интерпретацииэтого понятия – число тестов (данной техники), необходимых для обнаружения первого дефекта;отношение количества всех обнаруженных дефектов к дефектам, найденным с применениемзаданного подхода и т.п.
Только обладая такого рода данными можно говорить о корректностисравнения и оценки эффективности.5. Процесс тестирования (Test Process)Концепции, стратегии, техники и измерения тестирования должны быть объеденены в единыйпроцесс тестирования как деятельности по обеспечению качества. Процесс тестированияподдерживает работы по тестированию и определяет “правила игры” для членов командытестирования – от планирования тестов до оценки их результатов. Хотя, в большинствесовременных методов разработки, в частности, гибких (agile) подходов, тестирование выходит напередний план и является одной из базовых практик, многостороннее тестирование и, тем более,прогнозирование на основе полученных результатов, часто подменяется отдельными работами вэтой области, не позволяющими добиться необходимых параметров качества (что, кстати, яснопоказывают уже упоминавшиеся результаты исследований Standish Group [Chaos, 2004]).
Только втом случае, если тестирование рассматривать как один из важных процессов всей деятельности посозданию и поддержке программного обеспечения, можно добиться оценки стоимостисоответствующих работ и, в конце концов, соблюсти те ограничения, которые определены дляпроекта.5.1 Практические соображения (Practical considerations)5.1.1 Программирование без персоналий (Attitudes/Egoless programming)Очень важным компонентом успешного тестирования является совместное стремлениеучастников проекта обеспечить необходимое качество продукта. Менеджеры играют ключевуюроль в организации этой деятельности и на стадии разработки и в процессе сопровожденияпрограммных систем.5.1.2 Руководства по тестированию (Test guides)Работы по тестированию могут руководствоваться различными соображениями и критериями – отуправления рисками до специфицированных сценариев работы программных систем.
В любомслучае, желательно, исходя из ресурсов, количественных оценок и других характеристик, обеспечитьиспользование различных техник тестирования для многосторонней оценки и улучшения качестваполучаемого продукта.5.1.3 Управление процессом тестирования (Test process management)Работы по тестированию, ведущиеся на разных уровнях (см. выше 2. “Уровни тестирования”),должны быть организованы в единый (однозначно интерпретируемый) процесс, на основе учета 4элементов и связанных с ними факторов: людей (в том числе, в контексте организационнойструктуры и культуры), инструментов, регламентов и количественных оценок (измерений). Стандартжизненного цикла IEEE, ISO/IEC, ГОСТ Р 12207 не выделяет деятельность по тестированию вкачестве самостоятельного процесса, однако, рассматривает соответствующие принципы работ потестированию как неотъемлемую часть процессов жизненного цикла и сопровождения программныхсистем.
В другом распространенном стандарте IEEE 1074 деятельность по тестированию такжеобъединена с другими оценочными работами как интегральная часть полного жизненного цикла.5.1.4 Документирование тестов и рабочего продукта (Test documentation and work products)Документация – составная часть формализации процесса тестирования. Существует стандарт IEEE829-98 “Standard for Software Test Documentation”, предоставляющий прекрасное описание тестовыхдокументов, их связей между собой и с процессом тестирования.
Среди таких документов могутбыть: План тестирования Спецификация процедуры тестированияCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru13Основы программной инженерии (по SWEBOK)Программная инженерия. Тестирование программного обеспечения.Спецификация тестовЛог тестови др.Документирование тестов, в случае его формального ведения, должно быть актуальным. Впротивном случае, как и любые другие документы, документация по тестированию ляжет “мертвымгрузом”.
В то же время, деятельность по тестированию, в случае отсутствия соответствующихрегламентов и результатов (в том числе, исторических, для разных проектов), сложно поддаетсяоценке для прогнозирования и, тем более, улучшению - в общем контексте улучшения процессов.Если компания-разработчик не ведет соответствующей документации по тестированию, говорить осертификации или оценке по тем или иным моделям или стандартам (CMMI, ISO, SixSigma и т.п.) –просто не представляется возможным. А это уже вопрос доверия заказчиков, не имевших опытаработы с конкретной компанией-разработчиком.5.1.5 Внутренние и независимые команды тестирования (Internal vs. independent test team)Формализация процесса тестирования может включать и организационную формализациюкоманд(ы) тестирования.
В нее могу входить как члены проектной команды, в частности,разрабатывающие код, так и внешние лица и группы. В идеале – желательно иметь как внутреннююкоманду тестирования, так и внешнюю группу тестирования (обеспечения качества).Соответствующие организационные решения принимаются на основе стоимостных характеристикпроекта, доступных ресурсов, анализа стоимости тестирования, как такового, организационнойкультуры и т.п.5.1.6 Оценка стоимости и усилий, а также другие измерения процесса (Cost/effort estimation and otherprocess measures)Ряд метрик, связанных с оценкой ресурсов, необходимых для тестирования, как и оценкаэффективности тестирования на разных этапах и уровнях, основывается на точке зрения и практикахменеджмента проекта (подразделения, компании...) и используется для оценки и улучшения(оптимизации) процесса тестирования.
Разные техники, концепции и модели тестирования требуютразных затрат – по времени и необходимым ресурсам. Результат – стоимость тестирования, какзатратная составляющая проекта. Понимание соответствия между стоимостью/усилиями,необходимыми для той или иной формы тестирования является обязательной частью современногоуправления проектами разработки программного обеспечения.5.1.7 Окончание тестирования (Termination)Очень важным аспектом тестирования является решение о том, в каком объеме тестированиедостаточно и когда необходимо завершить процесс тестирования. Тщательные измерения, такие какдостигнутое покрытие кода тестами или охват функциональности, безусловно, очень полезны.Однако, сами по себе они не могут определить критериев достаточности тестирования. Приятиерешения об окончании тестирования также включает рассмотрение стоимости и рисков, связанных спотенциальными сбоями и нарушениями надѐжности функционирования тестируемой программнойсистемы.
В то же время, стоимость самого тестирования также является одним из ограничений, наоснове которых принимается решение о продолжении тех или иных связанных с проектом работ (счастности, тестирования) или об их прекращении. Cм. также 1.2.1 “Критерии отбора тестов/критерииадекватности тестов, правила прекращения тестирования”.5.1.8 Повторное использование и шаблоны тестов (Test reuse and test patterns)Доведение тестов до конца и обеспечение сопровождения программной системы необходимокаждый фрагмент системы тестировать систематическим образом, повторно используянаработанные тесты.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
