«В.В. Липаев ТЕСТИРОВАНИЕ КОМПОНЕНТОВ И КОМПЛЕКСОВ ПРОГРАММ УЧЕБНИК СИНТЕГ® Москва - 2010 УДК 004.41(075.8) ББК 32.973.26-018я73 Л61 Липаев В.В. Тестирование компонентов и комплексов программ. Учебник. – М.: СИНТЕГ, ...»

Тестирование корректности определения и использования данных на маршрутах исполнения программы (см. рис. 2.9). Если маршруты исполнения программы соответствуют допустимым областям изменения входных данных, то целесообразно проверить корректность основных операций обработки данных на выделенных маршрутах. Эти проверки могут производиться путем символического анализа текста программы или накопления результатов обработки реальных данных при исполнении программы. Каждая величина на маршруте исполнения программы считывается из памяти и после использования для вычислений записывается в память ЭВМ для хранения и последующей обработки. Чередование операций чтения и записи переменных может быть нарушено в результате ошибок в программе. Для выявления таких ошибок проводится тестирование корректности записи и считывание реальных значений данных или статический анализ этих операций по тексту программы.

Лекция 2.2. Тестирование потоков данных программных модулей… При тестировании потока данных выявляются все определения переменных, которые могут достигать каждой вершины графа программы по управлению. При этом под определением данных подразумеваются действия в программе, которые изменяют соответствующую величину данных. Использование данных – это операция в выражении, которая обращается к переменной, не изменяя ее. В результате для каждой точки программы устанавливается, какие переменные действуют в этой точке, т.е. какие данные, сформированные до прихода в эту точку, используются после выхода из нее. Анализ потока данных позволяет обнаруживать ошибки, обусловленные нарушением корректной последовательности операций определение – использование данных и выявлять переменные, которые целесообразно сохранять на регистрах.

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

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

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

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

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

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

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

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

Группируя и упорядочивая тестовые значения разных переменных, их общее количество можно сократить до 5 – 10 тестовых наборов.

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

структуру и размер массива, а также наличие в структуре массива особых точек или подструктур;

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

В простейшем случае (отсутствие особых точек в одномерной структуре массива и в значениях переменной) при тестировании неЛекция 2.2. Тестирование потоков данных программных модулей… обходимо минимум 3 значения переменной (краевые и промежуточные) при ее расположении в 3 точках массива, т.е. 9 тестов. При увеличении размерности массива и появлении особых точек в его структуре или значениях переменной соответственно возрастает число тестов, необходимых для проверки программы. Если область определения переменной включает значение нуль, то целесообразно тестирование программы при всех значениях переменной в массиве, равных нулю. Кроме того, следует задавать значения переменных в массиве равными между собой, а также изменяющимися случайно или в соответствии с наиболее характерной закономерностью. В ряде массивов можно выделить определенные столбцы, строки или иные подструктуры, имеющие самостоятельное назначение. Такой массив может быть использован для реализации иерархии подструктур. В этом случае каждая структура делится на подструктуры более низкого уровня, пока не получатся подструктуры, состоящие из отдельных элементов массива.

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

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

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

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

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

выражения с одними и теми же переменными, но с разными их значениями, определяющими непересекающиеся области условий ветвления;

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

Для выявления нереализуемых маршрутов в формально построенном графе программы, каждый из них должен быть проанализирован на наличие подобных пар несовместимых условий. Такой анализ относительно просто выполнить для условий первого вида, которые, однако не так часто встречаются. Наиболее важный вид неЛекция 2.2. Тестирование потоков данных программных модулей… явных несовместимых условий формально проанализировать невозможно без привлечения описаний всех корреляционных связей между переменными и предикатами. Построение таких описаний громоздко и трудоемко, что затрудняет их применение для селекции нереализуемых маршрутов. Выделение непересекающихся областей значений переменных при формировании условий образования маршрутов трудно реализовать из-за часто встречающихся областей со сложной конфигурацией. Дополнительные трудности может представлять селекция условий с точными и неточными неравенствами на границах областей, когда граничные значения по-разному используются в анализируемых условиях маршрута (см. рис. 2.9).

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

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

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

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

Документы при тестировании программных модулей Регламентировать тестирование программных модулей должны следующие базовые документы:

исходные данные для тестирования модулей;

организация, подготовка тестирования и обеспечение качества модулей;

сценарии тестирования и спецификации тестов для каждого модуля;

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

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

Исходные данные для тестирования модулей должны включать следующую документацию:

техническое задание и/или спецификация требований на разработку программного модуля;

исходный текст программы в виде печатного документа и файла;

выбранные методы тестирования модулей;

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

Лекция 2.2. Тестирование потоков данных программных модулей… тестовые сценарии исходных и результирующих данных, являющиеся достаточно представительной выборкой из полной совокупности значений и распределений эталонных данных, ограниченной доступными ресурсами на тестирование модуля;

доступные ресурсы для тестирования модуля: финансовые, трудовые и временные затраты на тестирование; оснащенность процесса тестирования модуля программными и аппаратными средствами автоматизации; состав и квалификация специалистов;

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

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

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

методы и средства объективного измерения требуемого покрытия тестами и достигнутого качества результатов тестирования каждого модуля;

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

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

Сценарии тестирования и спецификации тестов для каждого модуля должны отражаться в документе:

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ результаты функционирования модуля при подготовленных тестах и заданиях;

сравнения результатов тестирования с эталонами и обнаруженные отклонения (дефекты или ошибки) для проведения дополнительного тестирования с целью диагностики и локализации дефектов;

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

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

оценка характеристик качества модуля, исходных и выходных данных: годен - не годен;

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

Отчет о результатах верификации и тестирования модулей:

справка о передаче модуля на тестирование, когда в разработке участвуют независимые группы программистов и тестировщиков;

журнал выполнения плана тестирования, используемый коллективом тестировщиков модулей для регистрации: сценариев и операций, которые имели место во время выполнения тестирования;

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

результаты верификации и тестирования: результат выполнения (прошел/не прошел) для каждого анализа и выполненного теста и заключительный результат верификации и тестирования модуля; результаты оценивания покрытия и анализа трассируемости для выполнения тестов, и анализов в процессе верификации и тестирования;

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

Лекция 2.2. Тестирование потоков данных программных модулей… модули и компоненты комплекса программ выполняют все (частично) декларируемые в документации функции;

полученные выходные данные находятся в допустимых пределах отклонений от эталонных, заданных в требованиях на разработку комплекса программ или спецификациях на модули;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Затраты на обеспечение корректности функциональных компонентов и модулей комплекса программ зависят от полноты прослеживания реализации требований к ним сверху вниз. Эти затраты входят непосредственно в процесс разработки и зависят от объема и детальности процессов верификации и тестирования требований к компонентам и модулям. Для сложных программных комплексов при требовании их высокой корректности они могут составлять до 25 30% от затрат труда и 15 20% времени на обеспечение первичной, функциональной пригодности. Эти затраты приходятся на верификацию и тестирование программных компонентов и модулей, что должно обеспечивать корректность, безопасность и надежность комплекса в целом.

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

Затраты на совершенствование и модернизацию комплексов программ близки по содержанию (но не по величине) к затратам на их первичную разработку. Модернизация обычно производится поэтапно. Для каждой новой версии изменяется (разрабатывается) только некоторая часть от всего объема программного комплекса. Экспериментально установлено, что эта часть при вводе очередной версии обычно составляет 10 20% от объема всего комплекса. Сложность связей компонентов приводит к тому, что удельные затраты на изменяемые программы при модернизации каждой версии могут быть в В.В. Липаев. Тестирование компонентов и комплексов программ 2 3 раза больше, чем затраты на создание модулей программ такого же объема при разработке первой версии. Эта величина зависит от того, насколько путем стандартизации архитектуры и интерфейсов, предусматривались перспективы совершенствования комплекса программ.

Лекция 2.3. Планирование тестирования модулей и компонентов…

ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ

МОДУЛЕЙ И КОМПОНЕНТОВ ДЛЯ

КОМПЛЕКСА ПРОГРАММ

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ Лекция 2.3. Планирование тестирования модулей и компонентов… Планирование тестирования модулей и компонентов для комплекса программ должно включать:

- выбор метода «нисходящей – восходящей» сборки и тестирования модулей и программных компонентов:

планирование порядка разработки программ модулей и компонентов и их тестирования для комплекса программ;

формирование требований и эталонов к тестам в базе данных и/или матрице для отслеживания процессов реализации требований;

тестирование интерфейсов модулей и программных компонентов;

- планирование тестирования модулей и компонентов для комплекса формирование предварительного плана разработки и порядка выполнения тестов для модулей и компонентов комплекса программ;

документирование квалификации сотрудников, необходимых для тестирования модулей и компонентов;

формирование и контроль матрицы отслеживания требований к тестам модулей и компонентов;

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

анализ и контроль покрытия тестами требований и эталонов при тестировании модулей и компонентов;

- подготовка графиков разработки и выполнения тестов для модулей и компонентов комплекса программ;

освоение методов формирования графиков производства модулей и компонентов для программных комплексов;

стандартизация планирования производства комплекса программ и подготовки детализированных планов для модулей и компонентов;

отслеживание изменений требований и тестов и соответствующее обновление графиков тестирования;

тестирование качества технологической документации на модули и компоненты комплекса программ;

- применения графиков для планирования производства компонентов и комплексов программ:

освоение методики и средств планирования производства и тестирования компонентов сложных комплексов программ с использованием графиков Ганта;

принципы построения и применения сетевых графиков для планирования производства компонентов и комплексов программ.

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

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

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

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

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

Вначале оценивают состав и качество имеющихся готовых ПИК, из них планируют собрать версию, выбирают направления и объекты Лекция 2.3. Планирование тестирования модулей и компонентов… для последовательных доработок. Доработки, как правило, касаются изменения и совершенствования функциональных возможностей, интерфейсов разных видов при смене оборудования или операционной системы, изменений эргономических требований или модификации дисциплины обмена с абонентами сети или вычислительной системы. Доработки не всегда удается сделать так, чтобы полностью удовлетворить требованиям комплекса программ. Поэтому по завершении доработок в какой-то части комплекса осуществляется повторная его сборка и оценка полноты реализации требований технического задания. Этот цикл работ может повторяться в зависимости от соотношения потребных и завершенных доработок компонентов и модулей, особенно в условиях сжатых сроков разработки. Итерации, завершающиеся сборкой, осуществляют для распараллеливания работ по доработке компонентов и по комплексному тестированию предварительного варианта группы компонентов и модулей. Восходящий технологический процесс применяют обычно в коллективах, в течение ряда лет разрабатывающих однотипные комплексы программ для разных заказчиков.

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

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

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

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

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

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

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

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

Наблюдение за ходом тестирования – при нисходящем и восходящем тестировании могут возникать проблемы, связанные с контролем за состоянием тестирования. В большинстве комплексов, разрабатываемых сверху вниз, более верхние уровни системы, которые реализованы первыми, не генерируют выходные данные, однако для проверки этих уровней нужны какие-либо имитированные выходные Лекция 2.3. Планирование тестирования модулей и компонентов… результаты. Испытатель должен создать искусственную среду для генерации результатов теста. При восходящем тестировании также может возникнуть необходимость в создании искусственной среды (тестовых драйверов) для исследования функционирования компонентов и модулей нижних уровней.

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

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

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

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

Тестирование и обнаружение дефектов интерфейсов сложно, поскольку некоторые ошибки могут проявиться только изредка при необычных условиях. Такую ситуацию можно обнаружить только во время выполнения специальных тестов: например, специально вызывается переполнение очереди, которое приводит к непредсказуемому поведению объекта. Другая проблема может возникнуть из-за взаимодействий между ошибками в разных программных модулях или компонентах. Ошибки в компоненте иногда можно выявить, когда поведение другого взаимодействующего компонента становится непредсказуемым. Если объект неправильно понимает вычисленные значения, возвращаемое значение может быть достоверным, но неправильным во времени.

Накопленный опыт, анализ дефектов и ошибок взаимодействия компонентов сложных комплексов программ позволил представить некоторые полезные рекомендации при тестировании интерфейсов:

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

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

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

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

Лекция 2.3. Планирование тестирования модулей и компонентов… Планирование тестирования модулей и компонентов Тестирование компонентов и сложного комплекса программ составляет около половины затрат на полное проектирование и производство программного комплекса. Составление графика производства одна из ответственных работ, выполняемых менеджером, необходимая для определения и контроля интегральных характеристик производства программных комплексов. Менеджер должен оценивать длительность этапов создания компонентов и всего проекта, определять виды и размер ресурсов, необходимых для реализации отдельных этапов и типов работ, и представлять их в виде согласованной последовательности. Если данный проект подобен ранее реализованному, то график производства нового продукта можно взять за основу. Если проект является инновационным, первоначальные оценки длительности и требуемых ресурсов для компонентов почти наверняка будут слишком оптимистичными, даже если менеджер попытается предусмотреть все возможные неожиданности. С этой точки зрения производство программных комплексов не отличаются от больших инновационных технических проектов, в которых также неожиданно возникают проблемы и трудности. Именно поэтому графики работ являются динамичными и их необходимо постоянно обновлять по мере поступления новой информации о ходе выполнения проекта.

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

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

Некоторые из этих факторов могут увеличить, или сократить сроки тестирования, тогда как другие всегда только увеличивают затраты.

Следующие факторы определяются качеством организации процесса производства и выполнения работ:

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

четко определенные точки передачи управления между тестированием и остальными процессами производства модулей и компонентов;

качество управления изменениями графиков разработки и тестирования, требований, архитектуры и тестирования модулей и компонентов;

реалистичные и действующие графики и бюджеты производства и тестирования компонентов;

своевременное и надежное устранение обнаруженных дефектов, при нарушении критериев качества тестирования компонентов.

Некоторые важные факторы вытекают из особенностей состава и квалификации коллектива тестирования:

навыки, опыт и отношение к работе в группе тестировщиков, особенно у тест-менеджеров и ключевых специалистов;

взаимоотношения специалистов в группе тестирования компонентов;

корпоративная культура и традиции коллектива специалистов;

вдохновляемые и вдохновляющие менеджеры и технические лидеры, подготовленная группа управления, являющаяся организатором и контролером высокого уровни качества тестирования программных компонентов;

понимание всеми участниками производства необходимости тщательного тестирования компонентов, подготовки версий, системЛекция 2.3. Планирование тестирования модулей и компонентов… ного администрирования и документирования работ;

стабильность производственного коллектива, отсутствие текучести специалистов;

компетентная и своевременная поддержка тестовой среды;

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

Несколько усложняющих производственных факторов, которые всегда увеличивают сроки и затраты:

большая сложность проекта, технологии производства, структуры предприятия или тестовой среды;

большое число лиц, заинтересованных в тестировании, качестве компонентов и программном комплексе;

большое количество малых групп, особенно если они разделены географически;

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

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

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

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

Также ошибка не должна превышать 10 - 20%, и ни в коем случае оценка не должна отличаться от фактического результата в несколько раз. К сожалению, многие официальные графики и бюджеты проектов превышаются, часто на значительные величины. Это происходит по следующим основным причинам:

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

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

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

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

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

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

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

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

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

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

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

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

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

Должны быть документированы квалификация и навыки сотрудников, необходимых для проведения тестирования определенных компонентов. Состав группы тестирования, с требуемым качеством и навыками, может быть обозначен в требованиях к квалификации тестировщиков. Тест-менеджер должен оценить разницу между требуемой квалификацией и реальной подготовкой персонала, чтобы определить необходимые направления и объем обучения. Планируемое обучение следует отразить в графике, чтобы соответствующие работы по тестированию компонента не предшествовали обучению. Также необходимо определить и документировать в плане роли Лекция 2.3. Планирование тестирования модулей и компонентов… и ответственность сотрудников тестирования за качество определенного компонента с учетом особенности проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

тестовые процедуры могут быть объединены в группы в соответствии с функциями компонентов и программного комплекса;

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

в структуре тестовых процедур следует учитывать и документировать их приоритеты и риски;

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

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

Менеджер тестирования должен отслеживать изменения требований и тестов и соответственно обновлять график тестирования.

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

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

Стандартами ISO 16326 и ISO 90003 рекомендуется в процессе планирования производства комплекса программ подготовить и утвердить содержание следующих крупных детализированных планов:

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

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

обеспечения качества модулей и компонентов программного комплекса, определяющего методы и средства, при помощи которых будет гарантировано их требуемое качество;

В.В. Липаев. Тестирование компонентов и комплексов программ реализации процессов интеграции модулей и компонентов в версии программного комплекса;

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

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

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

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

Особый вид ресурсов это команда специалистов, привлеченная к выполнению проекта. Существует эмпирическое правило планирования: оценивать временные затраты на этапы и компоненты так, как будто ничего непредвиденного не может случиться, а затем значительно (на 30 50%) увеличивать эти оценки для учета и компенсации Лекция 2.3. Планирование тестирования модулей и компонентов… возможных проблем. Прогнозируемые проблемы существенно зависят от типа и размера проекта, а также от квалификации и опыта членов команды разработчиков. График работ по проекту обычно представляется в виде набора диаграмм, отражающих разбиение производственных работ на этапы и компоненты, зависимости между работами и распределение специалистов и затрат по этапам, работам и компонентам.

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

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

График представляет собой гистограмму, где каждая горизонтальная линейка обозначает отдельный вид или компонент производственной деятельности (рис. 2.14).

В.В. Липаев. Тестирование компонентов и комплексов программ Линейки изображаются относительно временной шкалы. Длина каждой линейки пропорциональна продолжительности времени, запланированного на выполнение определенной работы. Слева должны быть перечислены производственные действия, идентификаторы компонентов (например, 71 и 92) и модулей (7.1.1 … 9.2.6 и т.д.), а справа указаны горизонтальные полоски, длина которых соответствует длительности выполнения каждого этапа производства и тестирования компонента в соответствии с временной шкалой. Визуально диаграмма Ганта представляет собой последовательность определенных действий, выполняемых в пределах жизненного цикла комплекса программ. Трудоемкость процессов и число необходимых специалистов может указываться числами над линейкой для каждого модуля или компонента (рис. 2.14 в числителе число специалистов, в знаменателе трудоемкость тестирования). Пунктирные линии отражают связи и зависимости начала некоторых работ только после завершения предшествующей работы, например, начало работы 9.2. только после завершения процесса 7.1.3.

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

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

Независимо от того, как выявляются отклонения от плана, руководитель – менеджер должен принимать решение об их устранении, Там, где производство ограничивается чисто человеческим трудом, обычно коррекция производится добавлением сотрудников или увеличением времени сверхурочной работы соответствующих специалистов. Однако в программировании недостаток чаще всего ощущается не в рабочей силе как таковой, а в интеллектуальных ресурсах специалистов, поэтому с отклонениями от календарного плана здесь бороться сложнее. Формальное увеличение числа программистов не поможет «уложиться» в поставленные сроки, настолько же важно признать, что помочь в этом могут интеллектуальные способности только некоторых специалистов. Таким образом, приемлемым вариантом может стать временный перевод подходящих специалистов В.В. Липаев. Тестирование компонентов и комплексов программ на работу над проблемной частью проекта, либо наем специалистов – консультантов для устранения недостатков ресурсов.

Другой способ обеспечения уложиться в заданные сроки подробное, критичное изучение требований к программному комплексу и исключение из них не самых актуальных. Иногда, требования оказываются чересчур высокими, так как делаются попытки придать программному продукту дополнительные «украшения», не влияющий на него по существу. Избавление от ненужных требований состоит в «чистке» эталонов – требований. Важнейшим принципом планирования производства комплексов программ является упорядочивание приоритетов в порядке возрастания важности требований для заказчика и/или пользователей. Зачастую можно согласовать с заказчиком и принять решение об исключении определенных требований для того, чтобы уложиться в сроки. Следовательно, необходимо придерживаться принципа последовательного приращения функций и качества, не только на этапе анализа требований, но и во время планирования производства (в том числе календарного), реализации компонентов и комплекса программ.

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

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

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

Для планирования и мониторинга планов производства, создано несколько универсальных технологических программных продуктов. Они обеспечивают представление планов в различной графической форме – графиков Ганта, сетевых и других графиков. Большинство из них не имеют проблемного ориентирования, и требуют перед применением подготовки состава, содержания и характеристик этапов, компонентов или работ, значений времени и трудоемкости, необходимых ресурсов и состава конкретных специалистов для наполнения графиков. В качестве примера, достаточно простым и удобным может рассматриваться программный продукт Microsoft Project для представления, изменения и управления сложными планами производства в виде графиков Ганта. Основные функции пакета отражены четырьмя группами процедур: задачи проекта; ресурсы проекта; отслеживание реализации и изменений проекта и отчеты.

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

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

Ресурсы проекта: выбор состава и квалификации специалистов;

определение рабочих часов использования определенных ресурсов;

назначение специалистов и оборудования на решение задач; публикация сводных данных о доступных ресурсах производства.

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

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

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

этапов, производственных процессов и ресурсов всего жизненного цикла комплекса программ;

каждой крупной функциональной задачи и взаимодействия ее модулей и компонентов в комплексе программ;

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

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

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

Тестирование ряда определенных компонентов не может начаться, пока не выполнены все компоненты на всех путях, ведущих от начала тестирования компонентов комплекса к данному компоненту.

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

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

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

Лекция 2.4. Подготовка средств тестирования комплексов программ…

ПОДГОТОВКА СРЕДСТВ ТЕСТИРОВАНИЯ

КОМПЛЕКСОВ ПРОГРАММ НА

СООТВЕТСТВИЕ ТРЕБОВАНИЯМ

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