четвъртък, 14 юли 2011 г.

Автоматични тестове на GUI ??

Замислих се тия дни, за сериозните усилия, които се полагат в ИТ света по отношение на автоматизация на тестове на GUI сценарии. Съществуват доста изтънчени продукти за целта, като например QTP, или Selenium, сигурно има още кой знае колко яки tool-ове, с които автоматично могат да се запишат и съответно проиграят сложни сценарии на взаимодействие между имитиран потребител и приложението. Не ми се мисли колко нетривиална задача е да се разработят такива продукти. Или пък универсализирането им срещу различни GUI технологии и/или browser-и. Много сериозно се инвестира, от почти всяка компания, в писането на такива автоматични тестове. Това, което ме притеснява, е съответното количество - много често става дума за хиляди тестове, които се пускат всяка нощ. За мениджърите е много важно да знаят, че всяка нощ идват поредните няколко хиляди зелени теста. Важно е и за програмистите: вярно е, че ако такъв тест не мине успешно, с голяма вероятност той засича проблем в продукта (ако е написан качествено). Но до колко е реалистичен този проблем ? Дали би могъл клиентът да попадне на него ? Изпълнението на такова голямо количество тестове означава, че на един единствен сценарий обикновено се пада изключително кратък интервал от време, който е в порядъци по-малък от усета и възможностите на истинския човек, т.е. на реалния потребител на GUI продукта. Т.е. въпросният имитатор на потребител цъка с мишката, въвежда данни с клавиатурата, и проиграва сценария със светкавична скорост. Това на практика няма нищо общо с реален сценарий, при истински клиент на приложението. Т.е. със сценарий, заради който е създаден тоя продукт, заради който е платен от реални хора и реални клиенти. Аз смятам, че такъв тест е безсмислен, и далеч не оправдава усилията по създаването и поддръжката си. Поддръжката. Дааа, поддръжката. Гърми такъв един тест, и ходи да прекарваш тежки часове и дни в дебъгване, за да разбереш накрая, че например става дума за синхронизационен проблем, причинен от твърде бързото изпълнение. Супер, сега изчакай малко, преди да цъкнеш "next". Автоматичните туулове предлагат за целта т.нар. think time. Пълно безумие. Няма по-смислен начин да се тества един такъв сценарий, освен някой човек да седне и да го проиграе. Няма и начин, който поне да се доближава по смисъл до този. Все едно да тествате футболна топка с роботи, които я ритат с над 900 км/ч например. Или да тествате, че един шкаф е читав, като го хвърлите от 40-тия етаж върху асфалт. Или автомобил, като симулирате катастрофа от тип челен удар, със 700 км/ч. Доста безсмислено, нали ?! "Сценарият работи" означава, че работи по начина, по който истинската му употреба би го ползвала, т.е. човек с мишка. Другото е фира. И освен, че е фира, води до много загубено време за дебъгване на проблеми, дължащи се на обстоятелства, които най-често няма да се проявят, когато един истински човек цъка. И още по-лошо: проблеми и бъгове, които реално се проявяват при истинския цъкащ човек, е напълно възможно да не могат да се засекат от автоматичните тестове, и да не могат да се репродуцират. Двата свята понякога са много различни и е нелепо да се подготвиш за истинския (човешкия) чрез тестване на съвсем друг, напълно откъснат от него по отношение на действащите в него физични закони (този на CPU-то).


Да тестваш значи да проиграеш use case-а във възможно най-близка среда до истинската продуктивната среда при клиента. Кое му е близкото на това да изпълниш хиляди GUI сценарии за няколко часа ??

1 коментар:

  1. За да е реалистичен теста - той трябва да се изпълнява с човешка скорост. Ако изпълнието на тестовете се паралелизира, забавянето до човешка скорост не би трябвало да е фатално.

    Нещата, които не могат да се автоматизират е засичането на визуални гличове по време на транзишъни, анимации и т.н.

    В такива ситуации съм правил неща, като полуавтоматични тестове - теста не е headless, въпреки, че се изпълнява автоматично без намесата на тестер. Но тестера трябва да наблюдава изпълнението на теста.

    ОтговорИзтриване