PyUseCase

PyUseCase є тестування програмного забезпечення інтерфейс для PyGTK.
<Сильний> підтримуваного тестування графічного інтерфейсу користувача з Use Case Recorder
Запис намір, а не механіки
Найбільш природний спосіб створення тестів за допомогою користувальницького інтерфейсу, щоб просто виконувати дії, які ви хочете виконати, і мати інструмент, який може записувати їх, а потім відтворювати їх пізніше. Це простий і швидкий спосіб для створення тестів GUI і існує багато інструментів, які роблять це.
<Сильний> Більшість інструментів пара тести щільно інтерфейс
Проблеми починаються, коли у вас є кілька тестів і зміни GUI. Запис може бути відмінним способом для створення тестів, але це жахливий спосіб зберегти велику кількість з них. Це помилок, розчарування і забирає дуже багато часу, як тільки у вас є кілька тестів. Перше покоління інструментів записані піксельні позиції і зламав, як тільки ви змінили дозвіл екрана. Сьогоднішня інструменти угода з погляду механіки GUI: знайти таблицю з певним ім'ям і натисніть в третьому стовпці четвертого рядка. Вони можуть вижити зміни екраном і незначні повторні заходи графічного інтерфейсу, але не більше того. Записані скрипти щільні і не передають мета тестування, і закрита книга для всіх нетехнічних людей (а іноді й для всіх, крім автора інструменту).
Проблема полягає головним чином у зв'язку. Випробування і графічний інтерфейс тісно пов'язані один з одним і не можуть зручно варіювати незалежно один від одного. Ця точка зроблений добре Роберта С. Мартін у своєму блозі тут і його висновок, що тестування графічного інтерфейсу спочатку крихкими, і ви повинні робити, як мало про нього, як ви можете піти с.
Це здається досить пораженські хоча. Існує величезне значення в тому, в змозі продемонструвати, що ваші тести зробити, щоб користувач системи. Якщо тести обійти користувальницький інтерфейс, те, що процес вимагає чимало технічної майстерності та багато довіри з боку вашого користувача. І в будь-якому випадку, розробники програмного забезпечення вирішувати проблеми зчеплення весь час. Відповідь, як завжди, ввести ще один рівень непрямої.
<Сильний> Порушення зв'язок з картою інтерфейсу
Ділові люди і користувачі зазвичай працюють у тих випадках, використання. Ці описи на високому рівні послідовності дій в мовою, яку вони розуміють: тобто, що в домені. Ідея "Use Case Recorder" Тому інструмент, який може записувати і відтворювати такі послідовності і, таким чином, захопити намір користувача. Це дозволить потім більш глибоке розуміння, менше залежність від точного виду GUI і полегшення регулювання існуючих тестів, не вдаючись до натиснувши всі кнопки знову.
Основним механізмом є те, що ми підтримуємо відображення між діями, які в даний час можуть бути виконані з нашого GUI та звітності в цій мові домену. Зміни GUI, то маю на увазі, що цей сингл відображення потребує оновлення, але тести можуть залишатися недоторканими, продовжуючи описувати те, що повинно бути зроблено на концептуальному рівні. Це відображення приймає форму зовнішнього файлу в PyUseCase 3.0 і майбутній JUseCase 3.0, в той час як в більш ранніх версіях вона приймає форму приладів в коді програми.
<Сильний> Перевірка поведінку через колоди і TextTest
Таким чином, наша прецедентів може записувати і відтворювати usecases для нас. Але як ми можемо перевірити, що ми бачимо на екрані є правильним? Більшість GUI інструменти роблять це, дозволяючи тестовий скрипт, щоб утримувати "затвердження", які виглядають на деякий віджет і перевірити, що деяка властивість його дорівнює жорстко значення. Це створює ще більше залежність від поточної розкладки GUI і не може бути "записані" в будь-якому природним чином, але можна запрограмувати після факту. Ні "UseCase" не буде, природно, містять наступну інформацію: якщо він зробив це перетвориться в тестовому сценарії.
Ця дискусія не на сайті TextTest даремно. Якщо ми можемо отримати тільки наш додаток, щоб справити журнал, що графічний інтерфейс виглядає, як ми можемо перевірити, що вона робить, контролюючи зміст цього журналу, використовуючи TextTest. PyUseCase 3.0 робить це для вас: він генерує ASCII-арт-типу журнал поточного появи GUI і відстежує зміни до нього. Додаток може доповнити його власної лісозаготівлі, як він хоче. З іншими прецедентів реєстраторів додаток повинен будувати свій власний журнал для цієї мети в даний час.
Синхронізація тести по коду приладів
Майже всі зусилля тестування GUI страждають від проблем з переконавшись, сценарій чекає досить довго, перш ніж продовжити, коли щось відбувається у фоновому режимі. Рішення варіюються від таємних способів чекати деякі віджет, щоб мати певний зовнішній вигляд (ще кілька залежностей на GUI-механіки) для "сну" заяви ліберально розкидані навколо. Який збій при завантаженні системи і викликати тести працювати набагато повільніше, ніж вони могли б. Кожна людина, що не глибоким знанням код погано пристосовані для вирішення таких проблем, але робить так життєво важливою частиною написання тестів.
Використання регістра рекордери ввести поняття «Application Event". Це в основному деякі прилади в коді, який вказує на прецедентів рекордер, який щось трапилося, що повинно бути чекав, що дозволяє рекордер для запису і відтворення чекає, а також кліків. Вони описані тут більш докладно.
макроси записи, а також випробування
Високого рівня, легко маніпулювати "usecases" корисні для інших речей, ніж тестування. Вони також надзвичайно корисні для користувачів системи, які можуть створювати свої власні макроси для послідовностей дій, які вони виконують часто.
Вони відомі як "ярлики" GUI тут. Прецедентів рекордер, як правило, дозволяють додатком запросити "Панель" від нього, який містить елементи управління для запису і відтворення їх, які можуть бути вставлені в додатки GUI, як хотілося б. Крім дозволяючи користувачам створювати макроси, вони також можуть бути використані для створення ще більш високі абстракції рівня для мови "тест", описаної вище, допомагаючи тестерів у виконанні повторних дій для досягнення певної екран для тестування. Вони описані тут більш докладно.
Більш детальну інформацію можна знайти на домашній сторінці проекту

Що нового У цьому випуску :.

• Дуже базова підтримка WxPython був додав.
• Є також ряд удосконалень і виправлень для PyGTK. Примітно, gtk.Dialog.run тепер підтримується, не вимагаючи змін у вихідний код.
• Python 2.6 і PyGTK 2.12 або пізнішої версії тепер потрібно.
• Інтерфейс прилади на основі спадщина був видалений.

Вимоги

• Python
• PyGTK
• TextTest