Web Front End Test

[D.D.D]

Sveiki.

 

Jūsu prāt labākais(ie) Web Front End Test instruments.

 

Vislabākais variants būtu, ka rezultāti glabātos datu bāzē, lai varētu redzēt "trendline".

Budžets no 500 līdz 1500 EUR.

 

 

Labots Februāris 26, 2015 - D.D.D

[usver]

Funkcionālie (akcepttesti)? Slodzes testi? Penetration testi?

 

 

Funkcionālajiem - selenium. bezmaksas rīks. maksāt vajadzēs tikai par cilvēcīgo saprātu, kas definēs, kas tam īsti jādara.

 

ja gribi formāli un uzņēmumā un lai kaut kur no vienas vietas centralizēti tie testi laižas (robots pilda bezpersoniski tad, kad viņu uzrīdi noteiktai lapai noteiktos laikos), tad Jenkins jāpieskrūvē. Vienkāršākā valodā tas būtu - uzraksti testus, liec tāsku šedulerim (Jenkins) tos pildīt un savākt apkopojumu, cik bija veiksmīgi un cik ne. Teiksim - findViewById() konkrētā solī neatrada gaidītom jan bija jābūt - tātad tests feilo.

 

http://www.dailymotion.com/video/xgvbi2_jenkins-and-selenium-end-to-end-example_creation

 

Rezultātus vari automātiski iebāzt Jira vai tamlīdzīgā vietā, ja ļoti gribas zināt, cik no testiem izgāja un cik neizgāja un ja ļoti gribas formalitāti. Jenkins ir vesela kaudze visādu integrāciju - vari Skype vai Slack čatā likt postēt rezultātus, pašam sēžot maldivās un sūcot kokteili un tik skatoties, cik testi izgāja, cik ilgi un vai visi veiksmīgi.

 

Lielākā lieta visā būs testu rakstīšana/veidošana - testētājs vai programmētājs to darīs, bet kādam būs jādara. Vari to automatizēt un point'n'click, bet tāpat cilvēcīgam saprātam būs jābūt klāt, kad definēsi, ko tu gribi no "front end test" - kādus elementus klikosi un kādam jābūt rezultātam.

Labots Februāris 26, 2015 - usver

[D.D.D]

Tavs piedāvājums der maziem projektiem, līdz 1 000 000 objektiem.

turklāt tos vēl aprakstīt vajag un diezin vai gribēsi lasīt n-skaitu -e-pastus. 

Man, gribētos redzēt, instrumentu kurš ar salīdzināšanas metodi norāda uz izmaiņām.

 

Difference test.

 

šodien <> vakar <> aizvakar.

Labots Februāris 26, 2015 - D.D.D

[usver]

0__o

 

nesapratu, no kurienes miljons un kādā sakarā mazi objekti - nosauktie ir produkcijas instrumenti, ko lieto uzņēmumos vebu testēšanai. Nevis šaraškina kantoros, bet lielos, paralēli junittestiem. kad gribēsies cilvēk-lasāmus testus, tad vajadzēs uzrakstīt savu biznesa-valodas leijeri.

 

http://www.ibm.com/developerworks/library/a-automating-ria/

 

 

 

Difference test.

 

 

Ja sāc runāt par "difference test", tad nekāda funkcionālā testēšana tev nafig nav vajadzīga, un tam nav nekāda sakara ar testēšanu vispār. 

To sauc par "website change detection", un Latvijā to lieto iepirkumu uzraudzībai un tamlīdzīgiem sviestiem. Klāsts ir gana plašs - gan desktop, gan server-puses rīki, gan vispār portāli, kas dara to tavā vietā. Skaties tik lai izvēlētais rīks prastu ignorēt noteiktus gabalus (piemēram, pulksteni, kurš katru minūti veblapā mainīsies).

[D.D.D]

Neesmu programmētājs, bet problēma ir jāatrisina.

 

Problēma ir tajā, ka nevaram izvairīties no tā ka ik pa laikam izskan sekojošas replikas.  "No kurienes un kad šitas ir parādījies?" un "Kur tas pazudis un kad?", parasti tas tiek izteikts sulīgākos vārdos, bet pie personāla atlases neņemam vērā ģimenes audzināšanas faktoru.

 

Šitā gadās arī pēc dubultās kvalitātes pārbaudes.

 

Neredzu jēgu pieņemt darbā papildus acis, ja to var panākt softiski. 

Labots Februāris 26, 2015 - D.D.D

[Eric]

Drīkst jautāt ar ko jūs tur nodarbojaties?

 

Testēšana = pārbaude vai softs atbilst iepriekš definētām prasībām.

Tas vai iepriekš definētās prasības atbilst tam, ko sagaida lietotājs ir cita opera un to nevar atrisināt automatizēti.

 

Varbūt runa ir par izmaiņu ieviešanu, kas feilo, jo jūzeriem netiek skaidrots, kas un kādēļ mainās?

[usver]

autors varētu beigt spēlēt aklās vistiņas un aprakstīt situāciju detaļās.

 

Kas taisījis web sistēmu, kurš uztur, vai programmētājs pašu cilvēks un kods ir pieejams. Vai arī galva sāp par to, ka citu taisītā sistēmā bagi.

Un vai vispār kāds izmanto versiju kontroles sistēmu (Git vai SVN) un vai jēdzienu "testēšana" un "rakstīt testus" kāds ir dzirdējis un zina, ar ko to ēd.

Un likšana produkcijā notiek "a kujviņuzin, kad un ko mūsu datoriķis tur pamainīja" vai arī civilizēti, ar versijām un piegādēm.

 

 

Balto cilvēku variants ir tāds (neatkarīgi no tā, taisam weblapu, web uzskaites sistēm vai ko citu, kas jebkad būs jāuztur): 

  1) Lietojam rīku, kas ļauj jebkurā momentā redzēt VISU, kas kad kuros failos, kurās rindiņās ir mainīts. Lai izpaliktu haoss.

      Saucas Git. Vai SVN vismaz. 

      https://www.braintreepayments.com/braintrust/our-git-workflow

      Tas viss ir bezmaksas, atliek kustināt programmētāju/izstrādes vadītāju/CTO/firmas vadītāju vai kurš nu tur jums krutais tehniskais džeks jūtas, lai viņš iemācās ābeci un sāk no rīta tīrīt zobus/lietot kādu no šīm sistēmām.

 

  2) Kad esam iemācījušies kā baltie cilvēki tīrīt zobus (lietot versiju kontroles sistēmu), tad sākam lietot brančus, lai skaidrs, kas ir kas.

    Tev klients pasūtījis dīvānu. Tu nevis ej pie klienta katru rītu un taisi dīvānu pie viņa, mētā pa kājām skaidas, audumu atgriezumus un biedē suni ar savu urbi, bet taisi pie sevis dīvānu, un kad ir foršs, smuks, pārbaudīts un gatavs, tikai tad ved pie klienta.

 

   Tas pats ar jaunām fīčām - tev ir jāuztaisa kaut kas jauns, teiksim, jauna sadaļa. Tu taisi savu branču, tajā čubinies, taisi komitus (koda izmaiņu mailstounus, ja tā saprotamāk), un tikai tad, kad tev ir viss gatavs, tu sauc testētāju, kopīgi testējat un kad visi laimīgi, tikai tad taisi mērdžrekvestu ("merge request" - iekļaušanas pieprasījums), kāds izlasa tavas mainītās rindiņas, saprot jēgu un palūdz sastrukturēt/pamainīt tur kaut ko. Un tikai tad kolēģi dabūn tavu kodu. Kontrolējami, atgriežami, pārvaldāmi.

 

  2) Produkcijā liekam nevis "kad programmētājam ir luste, viņš produkcijas vidē palabo kādu rindiņu", bet vispirms iegrāmatojam, ko tieši mēs liekam produkcijā un tikai pēc tam liekam visu sistēmu vienkopus.

   

    Process: Front-enda kodā redzamā vietā nomainam versiju uz nākamo (v4.3.5), nokomitojam, GIT'ā šim komitam uztaisam jaunu tagu (RELEASE_4.3.5) un taisam jaunu versiju konkrēti no šī komita. Visi redzēs, ka jaunā versija ir šeit, un tieši tas būs produkcijā.  Versiju taisam no konkrētiem komitiem (lai pēc tam var viennozīmīgi noskaidrot, kādas lietas produkcijā ir un kādu tur nav). Jebkurā momentā mēs varam tad ielūrēt produkcijā un redzēt, no kura komita šitais ir uztaisīts un vai tajā ir iekļauti konkrēti labojumi vai nav. Izpaliks "uzkopējām daļu, bet otra daļa aizmirsās". Kaut ko palabojām (klients piezvanīja un pateica, ka viss slikti) - salabojam, notestējam, taisam jaunu versiju v4.3.5.1 un atkārtojam piegādes procesu.

 

3) kad ir balto cilvēku kārtība ar kodu un piegādēm, sākam rakstīt testus. ja ir hieroglifi, dati ar specsimboliem vai citi robežgadījumi - uztaisam testus, kas notestē, kāds būs rezultāts, ja firmas nosaukums būs ar 500 simboliem un 3 rindās.

Ir absolūti stulbi testēt miljonu kartiņu (pat ja ir miljons) tikai tāpēc, lai "kaut ko testētu" no frontenda - tas prasīs stundu, un to neviens nelietos. Testiem pārdesmit sekundes..pāris minūtes max jāiet lai viņus lietotu ikdienā. Ir robežgadījumi/specgadījumi - atrodam tos, kas var gļukot un uzrakstam testus speciāli tai funkcionalitātei, kas ģenerē HTML. Un tad starp versijām salīdzinam rezultātu - pie tam web testiem ir stulbi tas, ka čeksummas, ka "nekas nav mainījies" - okei, tās var pārbaudīt, bet reāli nobīdes/gļuki ir jāskatās specgadījumiem uz aci/jālieto getElementById() lai noskaidrotu, vai izskatās OK. JO mašīnai pilnīgi vienalga - sabraucis labajā pusē viss saturs vai smuki nocentrēts pa vidu. Tā ka būs programmētājs jāiesaista, lai viņš nodefinē, kas tur var gļukot un uzraksta elementārus testus konkrētiem gadījumiem, kas var noiet greizi.

 

 

 

Parādi šo tekstu savam IT lietas nosakošajam džekam uzņēmumā un arī programmētājam, kas fiziski grābstās gar kodu. Ja neviens neko no šī teksta nesaprot - ejiet mācīties tīrīt zobus (lietot Git) pie kāda, kas saprot, par ko ir runa. Nu nevar paņemt jebkuru programmētāju (kam tā varbūt otrā sistēma mūžā tik) vai nopirkt kādu internetā sagrābstītu softu un cerēt, ka tā būs panaceja pret visām problēmām. Iepazīsties, kā baltie cilvēki (izstrādes uzņēmumi) to dara, mācieties visi bariņā, ievies kārtību, un būs viss stipri kontolējamāk un izpaliks daudzas problēmas. Tas man sakāms, ja tēmē nevis uz iepirkumu konkursu lapu izmaiņu uzķeršanu, bet uz iekšējo izstrādi.

[Eric]

Git/svn atrisinās izmaiņu atsekojamību. Vēl izmaiņas ir jānokomunicē lietotājiem.

 

Kā jau usver rakstīja, izklausās pēc miskastes iekšējos procesos..