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

    [Ответить]



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

Пожалуйста, исправьте результат: дважды два равно



КРАТКОЕ СОДЕРЖАНИЕ

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


ПУТЕВОДИТЕЛЬ

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

ПОДПИСКА

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

ИЩЕЙКА