Организация тестирования в команде разработчиков. Лек15ТИС. 3. 1 Организация тестирования в команде разработчиков
 Скачать 24.85 Kb.
|
|
Для повышения качества тестирования рекомендуется соблюдать следующие основные принципы: предполагаемые результаты должны быть известны до тестирования; следует избегать тестирования программы автором; досконально изучать результаты каждого теста; необходимо проверять работу программы на неверных данных; вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части. Формирование набора тестов имеет большое значение, поскольку тестирование является одним из наиболее трудоемких этапов (от 30 до 60 % общей трудоемкости) создания программного продукта. Существуют два принципиально разных подхода к формированию тестовых наборов – структурный и функциональный. Структурный подход базируется на том, что известны алгоритмы работы программы. В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы. Функциональный подход основывается на том, что алгоритм работы программного обеспечения не известен. Тесты строят, опираясь на функциональные спецификации. Программа рассматривается как «черный ящик», и целью тестирования является выяснение обстоятельств, в которых поведение программы не соответствует требованиям. Опытные отладчики обнаруживают ошибки путём сравнения шаблонов тестовых выходных данных с выходными данными тестируемых систем. Чтобы определить местоположение ошибки, необходимы знания о типах ошибок, шаблонах выходных данных, языке и процессе программирования. Очень важны знания о процессе разработке программного обеспечения. Тема 3.1 Организация тестирования в команде разработчиков Цели и область тестирования Качество программного продукта характеризуется набором свойств, определяющих, насколько продукт «хорош» с точки зрения заинтересованных сторон, таких как заказчик продукта, спонсор, конечный пользователь, разработчики и тестировщики продукта, инженеры поддержки, сотрудники отделов маркетинга, обучения и продаж. Каждый из участников может иметь различное представление о продукте и том, насколько он хорош или плох, то есть о том, насколько высоко качество продукта. Таким образом, постановка задачи обеспечения качества продукта выливается в задачу определения заинтересованных лиц, их критериев качества и затем нахождения оптимального решения, удовлетворяющего этим критериям. Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения и входит в набор эффективных средств современной системы обеспечения качества программного продукта. С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных м сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. Отладка(debug, debugging) - процесс поиска, локализации и исправления ошибок в программе. Термин «отладка» в отечественной литературе используется двояко: для обозначения активности по поиску ошибок (собственно тестирование), по нахождению причин их появления и исправлению, или активности по локализации и исправлению ошибок. Тестирование - это процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта. Тестирование - это процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований. Тестирование - это контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок. Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости. Тестирование обеспечивает: Обнаружение ошибок. Демонстрацию соответствия функций программы ее назначению. Демонстрацию реализации требований к характеристикам программы. Отображение надежности как индикатора качества программы. Тестирование не может показать отсутствие дефектов (оно может показывать только присутствие дефектов). Важно помнить это утверждение при проведении тестирования. Тестирование - важная часть любой программы контроля качества, а зачастую и единственная. Это печально, так как разнообразные методики совместной разработки позволяют находить больше ошибок, чем тестирование, и в то же время обходятся более чем вдвое дешевле в расчете на одну обнаруженную ошибку. Каждый из отдельных этапов тестирования (блочное тестирование, тестирование компонентов и интеграционное тестирование) обычно позволяют найти менее 50% ошибок. Комбинация этапов тестирования часто приводит к обнаружению менее 60% ошибок. Коммуникация и взаимодействие в процессе тестирования В зависимости от потребностей проекта команда может включать участников с различными ролями. При этом на практике часто бывает, что один человек одновременно выполняет несколько ролей, если имеет необходимые навыки и знания для исполнения обязанностей. Аккаунт-менеджер - менеджер по работе с клиентами, специалист, который работает с клиентами компании и обеспечивает их лояльность. Аккаунт-менеджер обеспечивает выполнение всех необходимых клиенту задач, находит к каждому заказчику индивидуальный подход, поддерживает с ним хорошие отношения (даже после того, как все заказы уже выполнены), предлагает ему новые услуги и продукты. Иными словами, профессия аккаунт-менеджера обязывает ее представителя сделать все возможное, чтобы клиент был счастлив, работал с компанией всегда и всем ее рекомендовал. Менеджер проекта (Project manager, руководитель проекта, проект-менеджер; сокращенно - PM, ПМ, РП) - лицо, ответственное за управление проектом. Менеджер проекта несет ответственность за достижение целей проекта в рамках бюджета, в срок и с заданным уровнем качества. Системный аналитик (аналитик) является “мостиком” между заказчиком и членами команды. Переводит пожелания заказчика в формат точно описанных технических заданий. Системный архитектор (архитектор) проектирует разрабатываемую систему на самом верхнем уровне и принимает ключевые решения по поводу технологий и методологий разработки. Активно занимается исследованиями и экспериментами, рисует многочисленные диаграммы и документирует архитектурные решения. Программист (разработчик) пишет код на языках программирования, т.е. непосредственно кодирует логику работы программы. Также является ее первым пользователем и тестировщиком. Непосредственно отвечает за то, что программа работает и работает правильно (в соответствии с техническим заданием). Ведущий программист (технический лидер, техлид) - программист, который с технической точки зрения принимает решения о формате реализации функционала и координирует работу команды разработчиков. QA-специалист - специалист, который обеспечивает качество продукта (тестирует, контролирует и управляет качеством продукта). SDET-специалист (контроль качества, автоматизация тестирования) - специалист, который проверяет и отвечает за качество продукта. Пишет код для автоматизации процесса тестирования на разных языках программирования. Помогает команде разработки с точки зрения технических вопросов, вопросов архитектуры и построения приложения QA lead (ведущий специалист по управлению и контролю качества) - QA-специалист, который руководит командой тестирования. Тимлид — лидер команды, обеспечивающий достижение проектных целей посредством организации работы команды, состоящей из сотрудников различных направлений компании, а также отвечающий за развитие участников команды, построение коммуникаций (как внутри, так и извне), дисциплину и управление составом команды. Методология тестирования Тестирование - самая популярная методика повышения качества, подкрепленная многими исследованиями и богатым опытом разработки коммерческих приложений. Существует множество видов тестирования: одни обычно выполняют сами разработчики, а другие - специализированные группы. Виды тестирования перечислены ниже: · Блочным тестированием называют тестирование полного класса, метода или небольшого приложения, написанного одним программистом или группой, выполняемое отдельно от прочих частей системы. · Тестирование компонента - это тестирование класса, пакета, небольшого приложения или другого элемента системы, разработанного несколькими программистами или группами, выполняемое в изоляции от остальных частей системы. · Интеграционное тестирование - это совместное выполнение двух или более классов, пакетов, компонентов или подсистем, созданных несколькими программистами или группами. · Регрессивным тестированием называют повторное выполнение тестов, направленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов. · Тестирование системы - это выполнение ПО в его окончательной конфигурации, интегрированного с другими программными и аппаратными системами. Фазы тестирования. Реализация тестирования делится на три этапа: 1. Создание тестового набора (test suite) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testing environment). 2. Прогон программы на тестах, управляемый тестовым монитором (test monitor, test driver) с получением протокола тестирования (test log). 3. Оценка результатов выполнения программы на наборе тестов с целью принятия решения о продолжении или остановке тестирования. Тестовые среды Среда тестирования — это настройка программного и аппаратного обеспечения для групп тестирования для выполнения тестовых случаев. Другими словами, он поддерживает выполнение теста с настроенным оборудованием, программным обеспечением и сетью. Испытательный стенд или тестовая среда настраиваются в соответствии с требованиями тестируемого приложения. В некоторыхслучаях испытательный стенд может представлять собой комбинацию тестовой среды и тестовых данных, которые он использует. Важно понимать, что процесс тестирования требует системного подхода и использовать для этого лучшие практики недостаточно. Чтобы получить положительные результаты, необходимо с самого начала организовать процесс правильно. Для начала необходимо определиться с целями, областью, методологией тестирования и позаботиться о подготовке тестовой среды. Сегодня многие организации, в том числе команды разработки, уходят от традиционных подходов к организации тестовых сред. Если раньше под эти задачи разворачивали собственную инфраструктуру, которая требовала отдельной поддержки и дополнительных финансовых вливаний, теперь чаще отдается предпочтение более экономичным вариантам. Одним из них является виртуальный хостинг, представляющий собой один из удобных вариантов организации процесса тестирования, который отличается целым рядом конкурентных преимуществ. Примечательно, что тестовые среды, развернутые на базе виртуального хостинга, избавляют от простоев собственных серверов, поскольку отпадает необходимость в их использовании. Вместо этого вы получаете необходимые виртуальные ресурсы без потери качества. В последнее время большинство приложений создаются с возможностью доступа через стандартный интернет-браузер, и они также нуждаются в проверке работоспособности на уровне кода. Очень важно, чтобы приложение точно повторяло взаимодействие с пользователем. Кроме того, важно получить обратную связь относительно производительности и надежности работы сервиса. Используя для этих задач виртуальный хостинг, можно получить практически мгновенный ответ и обратную связь относительно функциональности и согласованности работы конкретного решения. Документированность процесса тестирования Тестовый план - это документ, или набор документов, который содержит тестовые ресурсы, перечень функций и подсистем, подлежащих тестированию, тестовую стратегию, расписание тестовых циклов, фиксацию тестовой конфигурации (состава и конкретных параметров аппаратуры и программного окружения), определение списка тестовых метрик, которые на тестовом цикле необходимо собрать и проанализировать (например метрик, оценивающих степень покрытия тестами набора требований). Тесты разрабатывают на основе спецификаций как вручную, так и с помощью автоматизирующих средств. Помимо собственно кода, в понятие "тест" включается его общее описание и подробное описание шагов, выполняемых в данном тесте. Для оценки качества тестов используют различные метрики, связанные с количеством найденных дефектов, покрытием кода, функциональных требований, множества сценариев. Вся информация об обнаруженных в процессе тестирования дефектах (тип, условия обнаружения, причина, условия исправления, время, затраченное на исправление) заносятся в базу дефектов. Информация о тестовом плане, тестах и дефектах используется в конце каждого цикла тестирования для генерации тестового отчета и корректирования системы тестов для следующей итерации. В тестовом плане определяются и документируются различные типы тестов. Типы тестирования по виду подсистемы или продукта таковы: Тестирование основной функциональности, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом. Тестирование инсталляции включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т. п. Тестирование пользовательской документации включает проверку полноты и понятности описания правил и особенностей использования продукта, наличие описания всех сценариев и функциональности, синтаксис и грамматику языка, работоспособность примеров и т. п. Методология тестирования сложных систем Тестирование сложных программных решений и комплексных систем. Сложная система — система, состоящая из множества взаимодействующих составляющих, вследствие чего сложная система приобретает новые свойства, которые отсутствуют на подсистемном уровне и не могут быть сведены к свойствам подсистемного уровня. Эффективно начинать тестирование комплексных (и других) систем на ранних стадиях разработки ПО. Методы тестирования в основном отличаются подходами к выбору множества тестовых данных из входного пространства. Основная цель тестирования — обнаружить дефекты в ПС и установить ее функциональную пригодность, удобство применения, производительность и др. Тестирование на протяжении процесса разработки сложной структуры из модулей выполняется на нескольких уровнях. Для каждого определяются категория объектов тестирования (ПС, компоненты, отдельные модули) и набор проверяемых тестируемых характеристик. На каждом уровне тестирование повторяется многократно, образуя циклы: тестирование — исправление — повторное тестирование. В современной практике тестирования все виды действий, начиная с планирования до оценки результатов тестирования, должны интегрироваться в четко определенный, документируемый и контролируемый процесс тестирования. Это облегчает взаимодействие между разработчиками, группой тестирования и руководством проекта, а также позволяет сделать процесс видимым, повторяемым и измеряемым. Тестирование имеет много общего с процессами верификации и валидации (V& V). Общность процесса тестирования с процессами V& V заключается в единстве состава и структуры планов, рекомендуемых стандартом IEEE Std. 829, а также объектов и применяемых методов. Отличие этих процессов состоит в условиях их применения. Тестирование выполняется всегда, для всех объектов ПО системы независимо от ее критичности. Процессы V&.V в современной трактовке стандартов IEEE Std. 1012 и ISO/IEC 12207 — поддерживающие процессы, которые могут применяться к выбранным объектам тестирования для проверки планов тестирования и подтверждения того, что выполненное тестирование адекватно уровню критичности ПС. По отношению к процессу тестирования V&V выполняет контрольную функцию и подтверждает соответствие объектов установленным требованиям. Тестирование ПС тесно связано с отладкой и собственно программированием, но охватывает гораздо более широкий круг проблем и участников — программистов, тестировщиков, аналитиков и инженеров по качеству. Традиционно выделяются три уровня тестирования ПО: автономное или модульное (unit testing), интеграционное (integrating testing) и системное (system testing). В стандарте ISO/IEC 12207 прослеживаются четыре уровня тестирования: • модульное (в процессе «Построение ПО»); • интеграционное (в процессе «Сборка ПО»); • тестирование ПС (как процесс); • системное (в процессе «Испытания ПС») |