Уважаемые коллеги! 
Максимально можно заказать – 1000 штук. Анализ граничных значений очень интересуют границы интервалов значений, на то он и «анализ граничных». Используя метод эквивалентного разбиения, были выделены следующие классы:
Самое время взяться за граничные значения этих самых классов. Нужно брать не только само граничное значение, но и отступать на шаг вверх/вниз (на самый, самый малюсенький из возможных шажков). Для выше написанных классов получаем:
Итак, получаем по 3 значения для границ, а также берем по одному значению из «тел» классов эквивалентности, итого: 33 + 12 = берем для проверки 45 значений. М-м-м-м-м, это больше 12, но гораздо меньше 1000. Да еще и проверяем не только валидные значения, но и невалидные! Но это только две техники из… продолжение следует…
Автоматизация тестирования, применяемая по месту, по времени и по теме весьма и весьма полезна. А если инструмент автоматизации бесплатный, мммм… «ни в сказке сказать, ни пером описать».
Selenium – набор инструментов для автоматизации тестирования веб-приложений на различных платформах. Официальный сайт тут. Там же можно посмотреть описание всего этого добра и, да-да, скачать.
Используя надстройку над Firefox Selenium IDE, записываем и воспроизводим тесты. IDE позволяет экспортировать тесты во множество различных языков (включая Ruby, PHP, java, perl, C# и Python). Меня интересует связка Firefox-Selenium-JAVA. Почему? А не скажу, корыстные цели у меня :). Если будут появляться интересные моменты, буду описывать.
Самое главное, как это все добро запускать! А очень просто. Мне помогла вот эта инструкция. Однако переменные среды я менять совсем не хотела, и один разработчик подсказал мне простой обходной путь (сама я в JAVA полный чайник, вот и мучаю знакомых ассов :)). Ниже мой вариант инструкции:
package com.example.tests;
import
com.thoughtworks.selenium.*;
import java.util.regex.Pattern;
public
class TrySelenium extends SeleneseTestCase {
public void setUp() throws
Exception {
setUp("http://wikipedia.org/", "*chrome");
}
public void
testTrySelenium() throws Exception {
selenium.open("/");
selenium.select("language", "label=English");
selenium.type("searchInput", "testing");
selenium.click("go");
selenium.waitForPageToLoad("30000");
selenium.click("link=Software
testing");
selenium.waitForPageToLoad("30000");
}
}
Имеем-с класс (название должно совпадать с именем файла!), содержащий последовательность вызовов селениум-методов, реализующих последовательность наших действий. Красота! Однако, хочется все это добро запустить через Selenium RC, а почему? Да потому, что Selenium RC позволяет преобразить записанный тест в оружие автоматизированного тестирования, используя мощь языка программирования и селениумовский библиотечных классов (громко сказано, а? а вдруг и правду может!). Для начала так далеко заходить не будем, а просто немного преобразуем java-код, дабы запускалось через RC.
import com.thoughtworks.selenium.*;
import junit.framework.*;
import java.util.regex.Pattern;
public class TrySelenium extends SeleneseTestCase {
public void setUp() throws Exception {
setUp("http://wikipedia.org", "*chrome");
}
public void testTrySelenium() throws Exception {
selenium.open("/");
selenium.select("language", "label=English");
selenium.type("searchInput", "testing");
selenium.click("go");
selenium.waitForPageToLoad("30000");
selenium.click("link=Software testing");
selenium.waitForPageToLoad("30000");
}
public static Test suite(){
return new TestSuite(TrySelenium.class);
}
public static void main(String args[]){
junit.textui.TestRunner.run(suite());
}
}
Конечно же, приведенный пример очень и очень прост, ничего особенно стоящего он не делает. Но он поможет начать. На сайте Selenium «вагон и маленькая тележка» документации, а на просторах-то «нашего всего» интернета. Дерзайте!
Снова хочу процитировать Канера и Ко, а именно их «Lessons Learned in Software Testing».
Programmers are like tornadoes. Think of them as forces of nature.
Мой вольный перевод: «Программисты как торнадо. Воспринимайте их как силы природы».
Силы природы, силами природы, конечно. Но не все программисты такие :). Они все разные, как и тестировщики!
Работая в компании, выпускающей коробочный продукт, я себя чувствовала по другую сторону баррикад от разработчиков. Отдел разработки и отдел тестирования имели свои цели. И разработчики воспринимали нас как «врагов» их творчества :) Что-то от сил природы в них было!
А вот в проектной команде разработчики оказались надежными соратниками, «опора» в тестировании так сказать. Правда и я уже была более опытным работником :)
Я сторонник того, что программист - не враг, а отличный коллега. Если разработчик для вас враг, может быть дело в ВАС!
Все мы совершаем ошибки, порой очень глупые. Что тут поделаешь? Мы люди, а людям свойственно ошибаться. 9-го июня прошел бесплатный вебинар, на котором небезызвестный Рекс Блэк рассказывал о 10 худших вещах для тестирования (о 10 не очень умных вещах, которые он делал тестируя). Мистер Блэк обещался выложить презентацию в библиотеке сайта своей компании http://www.rbcs-us.com/.
Я же хочу вольно пересказать эти 10 вещей на русском. Приступим.
1. «Тестировать только то, что может инструмент автоматизации». Честно признаюсь, такого я не встречала, но оказывается, бывает.
2. «Не увольнять человека, которого нужно уволить». Часто бывает, что «сантименты» затмевают «бизнес».
3. «Писать «плохие» отчеты об ошибках». А ведь отчет об ошибке – это своего рода «лицо» тестировщика.
4. «Забыть, что тестирование – это услуга». Такого пока тоже не встречала.
5. «Игнорировать ключевых заинтересованных лиц». Это как минимум глупо, ведь эти самые ключевые заинтересованные лица просто кладезь «полезной» для тестировщиков информации.
6. «Сообщать плохие новости «плохо»». Опустить руки и сказать, что все «плохо» - проще всего, а вот предложить варианты выхода из «кризиса» - это уже очень интересно.
7. «Не определить цель тестирования». Вопросы задавать очень полезно, тут не поспоришь.
8. «Брать ответственность за качество только на себя». Качественным продукт может стать только благодаря усилиям всех членов команды, только тестировщики «воз не вытянут».
9. «Изменять процесс без полномочий». «Затычек в каждой бочке» особо никогда не жалуют.
10. «Игнорировать неверные ожидания». Очень часто люди ждут от вас того, что вы сделать не можете. Может, стоит этих людей просветить?
Не скажу, что эти 10 «худших вещей» является открытием или откровением. Каждый из нас встречался с частью, а может и со всеми. Давайте же учиться на чужих ошибках!
А вы совершали ошибки, которые никогда не повторите?
P.S. Ожидаются еще бесплатные вебинары:
Six Surprises from Test Assessments July 1, 2009
ISTQB Advanced Certification August 5, 2009
Five Testing Best Practices September 3, 2009
Дополнительную информацию ищите на сайте компании Рекса Блэка.
P.S.S: картинка взята отсюда.
James Bach: "Requirements are the result of ongoing struggles between what we want and what we can have".
Мой вольный перевод: "Требования - это результат непрерывной борьбы между тем, что нам хочется, и тем, что можем получить".
В самом деле, требования редко когда стоят на месте. Как только будующий пользователь увидит демо-версию, сразу захочет что-нибудь изменить или добавить :) Да и без демо-версий чего-то все время хочется изменить или добавить :)
Если тестировать «в лоб», то, чтобы проверить все возможные варианты обработки заказанного количества карандашей, нужно написать очень много тестов (вспоминаем, что можно заказать аж 1000 штук), а потом еще все это и протестировать. Попробуем применить разбиение на классы эквивалентности. Очевидно, что наши входные данные мы можем разделить на следующие классы эквивалентности:
На основании этих классов мы и составим тестовые сценарии. Итак, если взять по одному представителю из каждого класса, то получаем 12 тестов. 12 – не очень много, но достаточно ли этого? Даст ли гарантию качества такой набор тестов? Давайте рассмотрим следующую технику: анализ граничных значений, и попробуем ответить на эти вопросы. Но об этом в следующий раз.
Приложение.
В качестве дополнения хочу привести парочку определений Equivalence partitioning.
Сем Канер, Джеймс Бах и Брет Петтихорд в Lessons Learned on Software Testing называют эту технику – Анализ классов эквивалентности (Equivalence class analysis) и определяют ее следующим образом:
«Класс эквивалентности – это набор значений переменной, который считается эквивалентным. Тестовые сценарии эквиваленты, если a) они тестируют одно и тоже; b) Если один из них выявляет ошибку, то и остальные выявят ее; c) Если одни из них не выявляет ошибку, то и остальные не выявят. Если определен класс эквивалентности, протестируйте только одно-два значения из него».
«Эквивалентное разбиение: Разработка тестов методом черного ящика, в которой тестовые сценарии создаются для проверки элементов эквивалентной области. Как правило, тестовые сценарии разрабатываются для покрытия каждой области как минимум один раз».
И напоследок, любая поисковая система (я предпочитаю, google) выдаст вам кучу определений, пояснений и примеров.
.png){kind=link}
