Документация обычно содержится в тестпланах

• Название: Документация обычно содержится в тестпланах
• Дата: 12.10.2021
• Размер: 270.2 Kb.
• Имя файла: Otchyot_po_praktike-1.docx
• Тип: Документация; #246360
• страница: 9 из 10

Предоставление доступа к пакетам из тестового пакета всем пользователям

Если вы решили, что один или несколько пакетов, входящих в опубликованный тестовый пакет, необходимо сделать доступным для пользователей, не входящих в тестовые группы, вы можете добавить эти пакеты в обычную отправку, не загружая их заново.

При создании новой отправки на странице Пакеты вы увидите раскрывающееся меню, в котором можно копировать пакеты из одного из ваших тестовых пакетов. Выберите тестовый пакет, содержащий пакеты, которые вы хотите включить. Вы можете выбрать лишь некоторые или все пакеты для включения в обычную отправку.

Обратите внимание, что к пакетам будут применяться одинаковые правила проверки, даже при использовании пакетов из ранее опубликованной отправки.

Удаление тестового пакета

Для удаления тестового пакета, поддержка которого больше не требуется, щелкните на его имя на странице обзора приложения. На обзорной странице тестового пакета щелкните Изменить и ссылку Удалить, чтобы удалить тестовый пакет. (При наличии незавершенной отправки тестового пакета необходимо сначала ее удалить.) Это может занять до 30 минут.

При удалении тестового пакета все использовавшие его пользователи получат обновление приложения, если существует пакет более новой версии, чем полученный ими в тестовом пакете (или как только такой пакет станет доступен). Если пользователи удалят приложение и установят его заново позже, это будет считаться новым приобретением, и пользователи получат самую новую из доступных версий.

Дата выполнения - 03.06.2021; количество часов - 6 часов.

Оценка программных средств с помощью метрик
Инспекция программного кода на предмет соответствия стандартам кодирования.

Оценка качества программного обеспечения. Метрики качества

Контроль качества программного продукта должен осуществляться на самых различных уровнях. Однако любой контроль предполагает наличие измерений, которые позволяют оценить уровень качества программного проекта. Измерения в процессе разработки программного обеспечения проводятся для того, чтобы лучше оценить процесс разработки, ход выполнения проекта и качество программного продукта. В результате выполнения измерений определяется количественная характеристика какого-либо свойства объекта измерения. Система измерения включает метрики и модели измерений, которые используются для количественной оценки качества программного обеспечения.

Под метриками понимают количественную оценку программного продукта, процесса или проекта, которая используется непосредственно либо на основе которой производятся другие измерения или выполняется прогноз. Можно сказать, что метрика — это мера степени обладания свойством, имеющая числовое значение. Важность метрик определяется тем, в какой мере они способствуют принятию решений. Если руководитель программного проекта будет помнить об этом, то он сможет оперировать полезными и важными метриками, а не собирать их случайным образом, накапливая большие объемы информации, использование которой затруднительно.

Путем непосредственных измерений могут определяться только опорные свойства объекта — опорные метрики. Все остальные метрики оцениваются в результате вычисления тех или иных функций от значений опорных метрик. Эти вычисления проводятся по соответствующим формулам.

Все метрики можно разделить на три основные группы: метрики процесса, метрики проекта, метрики продукта.

Внутри каждой группы существуют следующие типы метрик: непосредственно наблюдаемые (измеряемые), прогнозируемые, вычисляемые.

Непосредственное наблюдение атрибута какого-либо объекта не требует использования в процессе измерения других атрибутов или объектов и применяется при оценивании существующего объекта.

При прогнозировании используется математическая модель выбранного атрибута наравне с набором процедур прогнозирования, применяемых для определения неизвестных параметров и интерпретации результатов.

Вычисление, или косвенное измерение, означает вовлечение в процесс измерения с помощью определенной математической модели других атрибутов и объектов (всегда включает в себя вычисления с использованием, по крайней мере, двух других метрик).

Метрики классифицируются по следующим типам:

• 
  • метрики программного продукта, которые используются при измерении его характеристик — свойств;
  
• 
  • метрики процесса (измерение свойства процесса жизненного
  

цикла создания продукта);

• метрики использования.

Метрики программного продукта включают:

• 
  • внешние метрики, обозначающие свойства продукта, видимые пользователю;
  
• 
  • внутренние метрики, обозначающие свойства, видимые только команде разработчиков.
  

Внешние метрики (атрибуты) оцениваются с учетом связи объекта с внешней средой. Внешние метрики продукта — это метрики:

• 
  • надежности продукта, которые служат для определения числа дефектов;
  
• 
  • функциональности, с помощью которых устанавливаются наличие и правильность реализации функций в продукте;
  
• 
  • сопровождения, с помощью которых измеряются ресурсы продукта (скорость, память, среда);
  
• 
  • применимости продукта, которые способствуют определению степени доступности для изучения и использования;
  
• 
  • стоимости, которыми определяется стоимость созданного продукта. Внутренние метрики (атрибуты) могут измеряться в терминах самого объекта, отдельно от его поведения. Примерами внутренних метрик являются показатель числа строк кода в программном продукте, продолжительность выполнения действия, величина трудозатрат, число неудачных тестовых испытаний, объем денежных затрат, уровень сложности и степень модульности. Внутренние метрики продукта включают:
  
• 
  • метрики размера, необходимые для измерения продукта с помощью его внутренних характеристик;
  
• 
  • метрики сложности, необходимые для определения сложности продукта;
  
• 
  • метрики стиля, необходимые для определения методов и технологий создания отдельных компонентов программного продукта и его документов.
  

Внешние и внутренние метрики задаются на этапе формирования требований к программному обеспечению.

Стандарт ИСО/МЭК 9126 определяет следующие типы мер:

• 
  • мера размера программного обеспечения в разных единицах измерения (число функций, строк в программе, размер дисковой памяти и др.);
  
• 
  • мера времени (функционирования системы, выполнения компонента и др.);
  
• 
  • мера усилий (производительность труда, трудоемкость и др.);
  
• 
  • мера учета (количество ошибок, число отказов, ответов системы идр.).
  

Специальной мерой может служить уровень использования повторных компонентов, который измеряется как отношение размера продукта, изготовленного из готовых компонентов, к размеру системы в целом. Данная мера используется также при определении стоимости и качества программного обеспечения. В качестве примеров метрик можно привести:

• 
  • общее число объектов и число повторно используемых;
  
• 
  • общее число операций, повторно используемых и новых операций;
  
• 
  • число классов, наследующих специфические операции;
  
• 
  • число классов, от которых зависит данный класс;
  
• 
  • число пользователей класса или операций и др.
  

При оценке общего количества некоторых величин часто используются среднестатистические метрики (среднее число операций в классе, наследников класса или операций класса и др.).

Примером широко используемых внешних метрик программ являются метрики Холстеда — это характеристики программ, выявляемые на основе статической структуры программы на конкретном языке программирования: число вхождений наиболее часто встречающихся операндов и операторов; длина описания программы как сумма числа вхождений всех операндов и операторов и др. В качестве внешних метрик можно рассматривать также время выполнения (требуются программа и компьютер), полезность и удобство представления (требуются приложение и пользователь), надежность, эффективность, тестируемость, повторную применимость, переносимость и взаимодействие между операциями.

В качестве метрик процесса могут быть время разработки, число ошибок, найденных на этапе тестирования, и др. Практически используются следующие метрики процесса:

• 
  • общее время разработки и отдельно время для каждой стадии;
  
• 
  • время модификации моделей;
  
• 
  • время выполнения работ на процессе;
  
• 
  • число найденных ошибок при инспектировании;
  
• 
  • стоимость проверки качества;
  
• 
  • стоимость процесса разработки.
  

Метрики использования служат для измерения степени удовлетворения потребностей пользователя при решении его задач. Они помогают оценить не свойства самой программы, а результаты ее эксплуатации — эксплуатационное качество. Примером могут служить точность и полнота реализации задач пользователя, а также затраченные ресурсы (трудозатраты, производительность и др.) на эффективное решение задач пользователя. Оценка требований пользователя проводится с помощью внешних метрик.

Метрики бывают объективными и субъективными. Субъективные измерения предполагают наличие личностного, субъективного подхода, например применение какого-либо весового коэффициента.

Определения характеристик и соответствующая модель процесса оценки качества, приведенные стандарте ГОСТ Р ИСО/МЭК 9126

Оценка программной продукции. Характеристики качества и руководства по их применению, применимы тогда, когда определены требования для программной продукции и оценивается ее качество в процессе жизненного цикла. Эти характеристики могут применяться к любому виду программного обеспечения.

Стандарт ГОСТ Р ИСО/МЭК 9126 применяется для установления требований к качеству программного обеспечения и оценивания (измерения, ранжирования и оценки) программных продуктов, включая:

• 
  • определение требований к качеству программной продукции;
  
• 
  • оценивание технических требований к программному обеспечению при контроле за тем, чтобы требования качества были удовлетворены в процессе разработки;
  
• 
  • описание признаков и свойств (атрибутов) внедренного программного обеспечения (например, в руководствах пользователя);
  
• 
  • оценивание разработанного программного обеспечения перед его поставкой;
  
• 
  • оценивание программного обеспечения перед приемкой. Существует только несколько общепринятых метрик для характеристик, описанных в этом стандарте. Организации и группы по стандартизации могут устанавливать свои собственные модели процесса оценивания. Также могут применять свои методы формирования и проверки метрик, связанных с этими характеристиками, для охвата различных областей применения и стадий жизненного цикла программного обеспечения. В тех случаях, когда соответствующие метрики отсутствуют и не могут быть разработаны, иногда пользуются словесными описаниями или «приблизительными методами».
  

При использовании перечисленных характеристик качества также необходимо установить критерии конкретно для данной организации или для данного применения, или для того и другого.

Должны быть установлены метрики и критерии применительно к оценке качества, когда обмениваются результатами оценивания.

Хотя отсутствует общепринятая система классификации программного обеспечения, имеется несколько общепринятых классов программного обеспечения, в зависимости от которых меняется важность каждой характеристики качества. Например, надежность наиболее важна для программного обеспечения критичных систем, эффективность — для программного обеспечения систем реального времени, а практичность — для программного обеспечения диалога конечного пользователя.

Важность каждой характеристики качества также меняется в зависимости от принятых точек зрения. Имеется несколько представлений о качестве: представление пользователя, разработчика и руководителя.

С точки зрения пользователя, качество — это совокупность характеристик объекта, относящихся к его способности удовлетворить установленные и предполагаемые потребности.

Процесс создания требует от пользователя и разработчика использования одних и тех же характеристик качества программного обеспечения, так как они применяются для установления требований и приемки. Когда разрабатывается программное обеспечение для продажи, в требованиях качества должны быть отражены предполагаемые потребности. Так как разработчики отвечают за создание программного обеспечения, которое должно удовлетворять требованиям качества, они заинтересованы в качестве промежуточной продукции также, как и в качестве конечной продукции. Для того чтобы оценить качество промежуточной продукции на каждой фазе цикла разработки, разработчики должны использовать различные метрики для одних и тех же характеристик, потому что одни и те же метрики неприменимы для всех фаз жизненного цикла. Например, пользователь понимает эффективность в терминах времени реакции, тогда как разработчик использует в проектной спецификации термины длины маршрута и времени ожидания и доступа. Метрики, применяемые для внешнего интерфейса продукции, заменимы метриками, применяемыми для ее структуры.

Представление пользователя должно также включать представление о характеристиках качества, требуемое тем, кто сопровождает программное обеспечение.

Руководитель может быть более заинтересован в общем качестве, чем в конкретной характеристике качества, и по этой причине будет нуждаться в определении важности значений, отражающих коммерческие требования для индивидуальных характеристик. Руководителю может также потребоваться сопоставление повышения качества с критериями управляемости, такими как плановая задержка или перерасход стоимости, потому что он желает оптимизировать качество в пределах ограниченной стоимости, трудовых ресурсов и установленного времени.

Инспекция программного кода на предмет соответствия стандартам кодирования.

Инспекция кода — это хорошо. Мы используем эту технику в своих проектах не так давно — около трех месяцев, — однако положительные результаты налицо. Мы уже рассказывали на Хабре о внедрении инспекций в процесс разработки, о документообороте при инспекциях, рассказывали о том, как можно оптимизировать процесс инспектирования с помощью инструмента Code Collaborator. Сегодня мы хотим подвести итоги и представить результаты, которых нам удалось достичь за время инспектирования. Поехали!..

На самом деле, плюсов много, поэтому в этом топике мы коснемся лишь нескольких основных.

Утвердился общий стиль написания кода. Конечно, и до внедрения инспектирования в нашей команде существовало некое представление о том, что такое хорошо и что такое плохо, которого все старались придерживаться. Однако благодаря инспекциям общий стиль был окончательно отточен и фактически «закрепился в голове» у каждого разработчика.

Парк велосипедов пополняется медленней. Все реже возникают ситуации «я придумал гениальное решение», и все чаще мы используем проверенные решения из сторонних библиотек. Возник интересный эффект «коллективного знания», когда один член команды знает об отдельной библиотеке что-то, чего не знают другие, и предлагает оптимально использовать ее лучшие качества.

Улучшилось общее владение кодом. Стало больше живого общения по различным аспектам проекта: почему это сделали так, а не по-другому? может быть, следовало бы поступить вот так? В результате понимание того, как работают различные части системы, стало равномерно распределяться среди разработчиков, а не концентрироваться у кого-то одного.

Активизировался обмен опытом и знаниями. Теперь мы чаще используем в разработке успешные методики и практики коллег, реализованные в других частях системы. Подобный опыт, на наш взгляд, может передаваться только через чтение чужого кода: другого пути просто не существует. Любой метод нужно «пережить» самому, лишь тогда его может сделать «своим», освоить. Для такого «погружения» нет ничего лучше, чем хороший пример чужого кода из знакомой предметной области: это куда эффективнее абстрактных геометрических примеров типа shape, circle и box.

Кодовая база стала более «сопровождаемой». Здесь целый список улучшений:

• 
  магические константы блокируются проверяющими;
  
• 
  уменьшилось дублирование кода (DRY);
  
• 
  алгоритмы стали проще (KISS);
  
• 
  документация классов и публичных методов улучшилась значительно (практически на каждый публичный класс и метод инспекторы требуют добавить документацию);
  

Единственный недостаток внедрения инспекций кода — увеличение времени разработки. На начальном этапе внедрения время увеличилось на 50—100% (иногда бывало и больше), но в результате в общем репозитории стало гораздо меньше некачественного кода, меньше «шлака».

В данный момент, после первоначальной отладки всех процессов, дополнительные временные затраты сократились до примерно 20—50%. Основной всплеск связан с притиркой команды к общему стилю кодирования; много времени ушло на принятие общих практик и методик. Для опытных команд, на наш взгляд, нормальное среднее увеличение времени разработки — 10%.

Checklist

Данный термин часто встречается в англоязычной литературе и обозначает, по сути, памятку инспектора — список контрольных вопросов для облегчения процесса инспектирования.

Контрольный список лучше создавать для каждого проекта и для каждой команды, поскольку он может сильно различаться в зависимости от используемых платформ, библиотек, архитектурных решений. При этом со временем список эволюционирует и начинает более полно отвечать текущим задачам проекта.

Суммируя накопленный опыт инспектирования, мы начали понимать, как нужно составлять контрольный список. Вот как выглядит наш список на данный момент.

Контрольный список — памятка инспектора Positive Technologies

1. Корректность реализации предметной области.

• 
  Функциональность реализована в полном объеме.
  
• 
  Соответствие спецификациям.
  
• 
  Верность заданных констант.
  
• 
  Обоснованность принятых допущений и соглашений.
  
• 
  Верная последовательность обработки.
  

2. «Читабельность» кода.
Тут главный контрольный вопрос нужно задать самому себе: «Смогу ли я в случае необходимости добавить новую фичу или пофиксить баг в инспектируемом коде?». Ответ должен быть положительным, в противном случае автору следует изменить код.

3. Наличие и полнота тестового покрытия.

• 
  Все публичные классы и методы тестируются.
  
• 
  Тестируются граничные условия.
  
• 
  Достаточность тестирования «положительных веток» выполнения.
  
• 
  Достаточность тестирования «отрицательных веток» выполнения.
  

4. Стоит добавить в свою копилку хорошие практики из чужого кода.

5. Корректность многопоточного кода.

• 
  Доступ к общим данным синхронизирован.
  
• 
  Отсутствуют deadlocks.
  
• 
  Для синхронизации используется идиома RAII.
  
• 
  Корректно обрабатывается возврат ресурсов в обработчиках ошибок.
  
• 
  Нет утечки ресурсов.
  

6. Код обрабатывает возможные ошибки корректно.

7. Отсутствие видимых нежелательных побочных эффектов в других частях системы.

8. Корректность языковых конструкций.

• 
  Применяются верные идиомы используемого языка и фреймворка.
  
• 
  Использование корректных библиотек.
  
• 
  Отсутствие вновь изобретенных «велосипедов».
  
• 
  Отсутствие дублирования кода.
  

9. Все переменные проинициализированы правильными значениями.

Возможно, наш контрольный список поможет составить подходящий для вашего проекта.
Нужно отметить также еще один очень важный момент. Для проектов, в которых нет модульных тестов, инспекция — это, по большому счету, единственная эффективная методика предотвращения дефектов в коде. По крайней мере ничего другого на ум не приходит. Поэтому если в вашем проекте нет модульных тестов, в первую очередь следует внедрять инспекции и только потом — практику написания модульных тестов.

Итак, почему же инспекции настолько эффективны? Часто бывает, что при проектировании или работе с кодом у разработчика в какой-то момент «замыливается глаз», ум накрепко привязывается к определенному проектному решению или конкретному фрагменту кода. Инспекция является простым способом обратиться к коллективному разуму, который обладает большей гибкостью и свободой, — по принципу «две головы лучше».

Дата выполнения - 04.06.2021; количество часов - 6 часов.

Использование выбранной системы контроля версии.
Использование методов для получения кода с заданной функциональностью и степенью качества.