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

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

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

Опубликовано 18.08.2008 в рубрике "Автоматизация"

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

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

    Автор : Aquarius | Август 18, 2008


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

    Автор : Капитан Аляска | Август 18, 2008


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

    http://www.pairwise.org/

    Автор : Алексей Булат | Февраль 9, 2009


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

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

    Автор : Капитан Аляска | Февраль 9, 2009



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



Краткое содержание

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


Путеводитель

Список всех статей с краткой аннотацией и разбивкой по рубрикам. Открыть карту.

Подписка

Доступ к самым интересным материалам по электропочте и RSS. Подробности.

Ищейка