PyUseCase

PyUseCase е GUI тестване на софтуер за PyGTK.
<Силен> тестване Maintainable GUI с ползване Case Recorder
Записване на намерението, а не механиката
Най-естественият начин за създаване на тестове чрез потребителски интерфейс е просто да извършват действията, които желаят да извършват и да има инструмент, който може да ги запишете и след това да ги възпроизвеждат по-късно. Това е един лесен и бърз начин за създаване на GUI тестове и съществуват много инструменти, които правят това.
<Силен> Най инструменти двойка тестовете здраво за GUI
Проблемите започват, когато имате няколко тестове и вашите GUI промени. Записването може да бъде един чудесен начин да създадете тестове, но това е ужасен начин да се поддържа голям брой от тях. Той е склонен към грешки, разочароващо и отнема много време, след като имате няколко теста. Първото поколение инструменти записват пиксел позиции и проби, веднага след като сте променили разделителната способност на екрана. Днешният инструменти сделка от гледна точка на графичния интерфейс механиката: намерите таблица с определено име и кликнете в третата колона на четвъртия ред. Те могат да оцелеят промени екран и незначителни повторни аранжименти на графичния интерфейс, но не и много други неща. Записаните скриптове са плътни и не се предават целите на теста, и са затворена книга за всички нетехнически хора (а понякога и на всички, с изключение на автора на инструмента).
Проблемът е по същество един от свързване. Тестовете и GUI са плътно свързани помежду си и не може удобно да варират независимо един от друг. Тази точка е направен добре от Robert C. Martin в своя блог тук и неговото заключение е, че GUI тестване в своята същност е чуплива и вие трябва да направите, като малка част от нея, както можете да се размине с.
Това изглежда доста пораженчески все пак. Има огромна стойност е в състояние да докаже, какви изследвания ви правят на потребител на системата. Ако тестовете заобикалят потребителския интерфейс след това този процес изисква справедлива стойност на технически умения и много доверие от страна на вашия потребител. И все пак, разработчици на софтуер решаване прикачни проблеми през цялото време. Отговорът е, както обикновено, да се въведе още едно ниво на околен.
<Силен> Разрушаване на съединителя с карта UI
Бизнес хора и потребителите обикновено работят в случаите на използване. Това са описания на високо ниво на последователност от действия, на език, който те разбират: т.е., че на домейна. Следователно идеята за "Use Case Recorder" е инструмент, който може да записва и преиграване такива последователности и по този начин да улови намерението на потребителя. Това ще позволи по-добро разбиране, по-малка зависимост от точната форма на GUI и по-лесно адаптиране на съществуващите тестове, без да се прибягва до кликане всички бутони отново.
Основният механизъм е, че ние поддържаме картографиране между действията, които в момента могат да се извършват с нашата GUI и изявления на този език домейн. GUI промени след това да означава, че този единен картографиране трябва да се актуализира, но изпитванията могат да останат недокоснати, продължава да се опише това, което трябва да се направи на концептуално ниво. Това картографиране е под формата на външен файл в PyUseCase 3.0 и предстоящото JUseCase 3.0, а в по-старите версии тя е под формата на апаратура в кода на приложението.
<Силен> Проверка на поведението чрез дневници и TextTest
Така че нашата ползване случай рекордер можете да записвате и преиграване usecases за нас. Но как можем да се провери, че това, което виждаме на екрана е правилно? Повечето графични средства да направят това, като позволява на скрипта за тест, за да съдържат "твърдения", които изглеждат някои джаджа и да проверят, че някои имот от него е равна на един кодиран стойност. Това създава още повече зависимост от текущото оформление GUI и не могат да бъдат "записани" в която и естествен начин, но трябва да се програмира в постфактум. No "usecase" естествено ще съдържа тази информация: ако го е направил, че ще се превърне в един тест скрипт.
Тази дискусия не е на сайта TextTest за нищо. Ако можем да вземем само нашето заявление за получаване на дневник на това, което GUI изглежда като можем да се провери какво прави чрез мониторинг на съдържанието на дневника, който се използва TextTest. PyUseCase 3.0 прави това за вас: тя генерира вид на дневника на текущата GUI появата на ASCII-арт и следи промените в него. Заявлението може да го допълнят със собствен сеч, които желае. С други употреби, дело записващи заявлението трябва да изгради свой собствен дневник за тази цел в момента.
<Силни> Синхронизиране тестове по код апаратура
Почти всички усилия GUI тестване страдат от проблеми с като се уверите сценария чака достатъчно дълго, преди да продължите, когато нещо се случва във фонов режим. Решенията варират от тайнствени начини да се изчака известно джаджа да има определено външен вид (още повече зависимости на GUI-механика) към "сън" изявления щедро разпръснати наоколо. Кой провали, когато системата е заредена и да причини тестовете да се движат много по-бавно, отколкото би било иначе. Всеки, който не дълбоко познаване на кода е зле подготвени за решаване на такива проблеми, но все пак това е много важна част от писане на тестове.
Използвайте обвивка рекордери въвеждат концепцията за "Искане за събитието". Това е в основата на някои измервателни уреди в кода, който показва до записващото устройство за използване случай, че нещо се е случило, че трябва да се изчака, като по този начин позволява на рекордера да записва и преиграване чака както и кликвания. Те са описани по-подробно тук.
<Силни> Запис на макроси, както и тестове
Високо равнище, лесно манипулирани "usecases" са полезни и за други неща от изпитване. Те също са изключително полезни за потребителите на системата, които могат да създават свои собствени макроси за последователности от действия, които те изпълняват често.
Те са известни като "GUI преки пътища" Тук. A Използване случай рекордер обикновено ще позволи на приложението да направите заявка за "лентата" от него, което съдържа контроли за записване и ги преиграе, които могат да бъдат вкарани в графичния интерфейс на приложението, по желание. Освен позволява на потребителите да създават макроси, те също могат да бъдат използвани за създаване на още по-високи абстракции ниво за "езиков тест", описан по-горе, помагачество тестери при изпълнение на повтарящи се действия за достигане на определена екран за тестване. Те са описани по-подробно тук.
Повече информация можете да намерите на началната страница на проекта

Какво ново в тази версия:.

• много основни подкрепа за wxPython беше добавена.
• Има и редица подобрения и поправки за PyGTK. За отбелязване е, gtk.Dialog.run вече се поддържа, без да изисква промени изходния код.
• Python 2.6 и PyGTK 2.12 или по-късно, сега е необходимо.
• измервателна апаратура базиран интерфейс наследството е била отстранена.

<силни> Изисквания

• Python
• PyGTK
• TextTest