Методологические основы

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

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

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

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

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

Рис. 13.2

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

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

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

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

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

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