OpenQuality.ru

Продукт и среда: перебор вариантов

Добрый день.

Как правило, выпускаемые продукты должны работать в различных конфигурациях среды. Рассмотрим простой пример: разрабатывается сервис мониторинга системных ресурсов. Продукт планируется выпускать в виде исходного кода. Что принять во внимание? Вот далеко не полный список: операционная система, платформа, ядро, средства защиты, компилятор, run level, настройки iptables и многое-многое другое.

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

- операционная система (пример: RHEL AS 4, SLES 9 sp3, Solaris 10, AIX 5.3):  a1…a4
- платформа (пример: i386, x86_64, IA64):  b1…b3
- ядро (пример: SMP, неSMP) :  c1, c2
- средства защиты (пример: SELinux, AppArmor, Tivoli Access Manager, базовые):  d1…d4

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

#!/usr/bin/perl -w
use strict;
 
our @rows;
 
sub get_element {
    my ($array, $variant) = @_;
    my $element;
    if ($array == $#rows) {
        for $element (0 .. $#{ $rows[$array] }) {
            print Result join (" ", @{ $variant });
            print Result " ", $rows[$array][$element], "\n";
        }
    } else {
        for $element (0 .. $#{ $rows[$array] }) {
            my @incomplete_variant = @{ $variant };
            push @incomplete_variant, $rows[$array][$element];
            my $inner_array = $array + 1;
            get_element($inner_array, \@incomplete_variant);    # recursion
        }
    }
}
 
my $i;
 
open (List, "list.txt") or die "Can't read a list $!";
while (<List>) {
    push @rows, [ split ];
}
close(List);
 
open (Result, "> result.txt") or die "Can't write results $!";
 
for $i (0..$#{ $rows[0] }) {
    my @variant;
    push (@variant, $rows[0][$i]);
    get_element(1, \@variant);
    undef @variant;
}
close (Result);

В result.txt получим:

a1 b1 c1 d1
....
a2 b3 c2 d4
....
a4 b3 c2 d4

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

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

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

Отправить в Twitter, Facebook, ВКонтакте | Опубликовано 18.08.2008 в рубрике "Автоматизация"

Комментарии (7)

1. Автор комментария : Aquarius | August 18, 2008

   не все получившиеся сочетания возможны на практике; можно даже сказать, что некоторые невозможны и в теории 8)

   [Ответить]

   
   

2. Автор комментария : Капитан Аляска | August 18, 2008

   Aquarius, спасибо за комментарий!
   Безусловно, “в одну телегу впрясть не можно коня и трепетную лань” :) Это оценочная прикидка и не более того. Помимо всего прочего, она позволит ничего не упустить и прикинуть предстоящий фронт работ и риски. Можно пойти другим путем: перед прикидкой установить возможные зависимости между координатами и учесть их в выдаче вариантов. Но это уже совсем другая история :)

   [Ответить]

   
   

3. Автор комментария : Алексей Булат | February 9, 2009

   Ну мне кажется, что кол-во комбинаций можно уменьшить еще и за счет различных способов генерации тест кейсов (Pairwise Testing):
   Вот здесь про это можно почитать:

   http://www.pairwise.org/

   [Ответить]

   
   

4. Автор комментария : Капитан Аляска | February 9, 2009

   Алексей, спасибо за ссылку и комментарий.

   Не так давно попалась на глаза статья Майкла Болтона (http://www.developsense.com/testing/PairwiseTesting.html). Безусловно, этот подход имеет право на жизнь, особенно в комбинации с другими критериями: приоритеты, классы эквивалентности и пр.

   [Ответить]

   
   

5. Автор комментария : sgh | November 29, 2010

   Спасибо за хороший пример

   [Ответить]

   
   

6. Автор комментария : Капитан | January 30, 2012

   Две русскоязычных статьи по pairwise testing:
   http://qcthoughtsaloud.blogspot.com/2010/06/pairwise-testing.html
   http://www.freality.info/itblog/?p=199

   [Ответить]

   
   

7. Автор комментария : Капитан | March 12, 2013

   Неплохой инструмент: http://engineering.meta-comm.com/allpairs.aspx

   [Ответить]

   
   

Добавить комментарий