Средства и способы программирования

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

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

Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования. Ясно лишь, что далеко не каждый примитив качества ПС может быть испытан тестированием Завершенность ПС проверяется уже при тестировании внешних функций. На данном этапе тестирование этого примитива качества может быть продолжено, если требуется получить какую-либо вероятностную оценку степени надежности ПС. Однако, методика такого тестирования еще требует своей разработки. Могут тестироваться такие примитивы качества, как точность, устойчивость, защищенность, временная эффективность, в какой-то мере - эффективность по памяти, эффективность по устройствам, расширяемость и, частично, независимость от устройств. Каждый из этих видов тестирования имеет свою специфику и заслуживает отдельного рассмотрения. Мы здесь ограничимся лишь их перечислением. Легкость применения ПС (критерий качества, включающий несколько примитивов качества, см. лекцию 4) оценивается при тестировании документации по применению ПС.

Тестирование документации по применению ПС. Целью тестирования является поиск несогласованности документации по применению и совокупностью программ ПС, а также выявление неудобств, возникающих при применении ПС. Этот этап непосредственно предшествует подключению пользователя к завершению разработки ПС (тестированию определения требований к ПС и аттестации ПС), поэтому весьма важно разработчикам сначала самим воспользоваться ПС так, как это будет делать пользователь [1.1]. Все тесты на этом этапе готовятся исключительно на основании только документации по применению ПС. Прежде всего, должны тестироваться возможности ПС как это делалось при тестировании внешних функций, но только на основании документации по применению. Должны быть протестированы все неясные места в документации, а также все примеры, использованные в документации. Далее тестируются наиболее трудные случаи применения ПС с целью обнаружить нарушение требований относительности легкости применения ПС.

Тестирование определения требований к ПС. Целью тестирования является выяснение, в какой мере ПС не соответствует предъявленному определению требований к нему. Особенность этого вида тестирования заключается в том, что его осуществляет организация-покупатель или организация-пользователь ПС [1.1] как один из путей преодоления барьера между разработчиком и пользователем. Обычно это тестирование производится с помощью контрольных задач - типовых задач, для которых известен результат решения. В тех случаях, когда разрабатываемое ПС должно придти на смену другой версии ПС, которая решает хотя бы часть задач разрабатываемого ПС, тестирование производится путем решения общих задач с помощью как старого, так и нового ПС (с последующим сопоставлением полученных результатов). Иногда в качестве формы такого тестирования используют опытную эксплуатацию ПС - ограниченное применение нового ПС с анализом использования результатов в практической деятельности. По существу, этот вид тестирования во многом перекликается с испытанием ПС при его аттестации, но выполняется до аттестации, а иногда и вместо аттестации.

28. Что такое шапка модуля?

Модуль “Шапка сайта с логотипом, телефоном, слоганом и меню”

Внешний вид на сайте:

В модуле шапка сайта пользователь может настраивать по своему усмотрению:

* фоновое изображение (картинку в шапке),

* логотип компании (можно загрузить картинкой или написать текстом),

* телефон/телефоны,

* слоган или приветственный текст,

* главное меню сайта и делать его вертикальным или горизонтальным,

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

Чтобы перейти в редактор шапки сайта нужно войти в систему управления сайтом и нажать кнопку Изменить логотип в горизонтальном меню.

29. Производительность труда программиста и объём программного продукта

1) Уровень сложности

2) 2) Предполагаемый объем

3) 3) Язык на котором пишем (скорее всего это относится к уровню сложности)

Объём программного продукта

Количество строк кода (англ. Source Lines of Code -- SLOC) -- это метрика программного обеспечения, используемая для измерения его объёма с помощью подсчёта количествастрок в тексте исходного кода. Как правило, этот показатель используется для прогноза трудозатрат на разработку конкретной программы, либо для оценки производительности труда уже после того, как она написана.

Подсчёт количества строк кода

Традиционно считается, что имеет смысл сравнивать размеры проектов лишь с точностью до порядка. Среди всего разнообразия методик вычисления данной метрики, большинство источников выделяют два основных: подсчёт физических и логических строк.

Физическими строками считаются все непустые строки текстового файла. Пустые строки учитываются в том случае, если в некоторой секции их количество не превышает 25 %. В противном случае, пустые строки, превышающие порог в 25 % не считаются.

Измеряя логические строки кода, предпринимается попытка посчитать количество собственно операторов в программе, но, разумеется, их определение зависит от конкретного языка программирования. Например, простейший способ посчитать количество логических строк кода в Cи-подобных языках состоит в подсчёте числа точек с запятой, заканчивающих операторы.

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

Рассмотрим следующий пример на Си:

for (i=0; i<100; ++i) printf("привет"); // Сколько здесь строк кода?

В данном случае у нас:

§ 1 физическая строка кода

§ 2 логические строки кода (Оператор цикла for и оператор вызова функции printf)

§ 1 строка комментария

У другого программиста этот же участок кода, скорее всего, будет оформлен в несколько строк:

for (i=0; i<100; ++i)

{

printf("привет");

}

// Сколько здесь строк кода?

В данном примере у нас будет:

§ 5 физических строк кода

§ 2 логических строки кода

§ 1 строка комментария

Также учитывается объём готового программного продукта. Его необходимый объемный минимум занимаемой памяти на жестком диске. Как для хранения количество Мб/Гб, так и в установленном виде, готовым для работы. Также учитываются минимальные системные требования - Частота процессора, ОЗУ, видео и аудио.

Размещено на Allbest.ru