TESTNI NAČRT - TESTIRANJE PROGRAMSKE OPREME

Testni načrt je podroben dokument, ki opisuje področja in dejavnosti testiranja programske opreme. Opisuje testno strategijo, cilje, testni razpored, potrebne vire (človeški viri, programska in strojna oprema), testno oceno in testne rezultate.

Testni načrt je osnova testiranja vsake programske opreme. Je najpomembnejša aktivnost, ki zagotavlja razpoložljivost vseh seznamov načrtovanih aktivnosti v ustreznem zaporedju.

Testni načrt je predloga za izvajanje dejavnosti testiranja programske opreme kot definiran proces, ki ga v celoti spremlja in nadzoruje vodja testiranja. Testni načrt pripravijo vodja testa (60 %), vodja testa (20 %) in testni inženir (20 %).

Vrste testnega načrta

Obstajajo tri vrste testnega načrta

Glavni testni načrt
Fazni testni načrt
Načrti testiranja, specifični za vrsto

Glavni testni načrt

Glavni testni načrt je vrsta testnega načrta, ki ima več ravni testiranja. Vključuje celotno testno strategijo.

Fazni testni načrt

Načrt faznega testiranja je vrsta načrta testiranja, ki obravnava katero koli fazo strategije testiranja. Na primer seznam orodij, seznam testnih primerov itd.

Posebni preskusni načrti

Poseben načrt testiranja, zasnovan za glavne vrste testiranja, kot so varnostno testiranje, testiranje obremenitve, testiranje delovanja itd. Z drugimi besedami, poseben načrt testiranja, zasnovan za nefunkcionalno testiranje.

Kako napisati testni načrt

Izdelava testnega načrta je najbolj ključna naloga procesa vodenja testiranja. V skladu z IEEE 829 sledite naslednjim sedmim korakom za pripravo preskusnega načrta.

Najprej analizirajte strukturo in arhitekturo izdelka.
Zdaj oblikujte testno strategijo.
Določite vse testne cilje.
Določite območje testiranja.
Določite vse uporabne vire.
Vse aktivnosti razporedite na primeren način.
Določite vse rezultate testa.

Komponente ali atributi preskusnega načrta

Načrt testiranja je sestavljen iz različnih delov, ki nam pomagajo izpeljati celotno aktivnost testiranja.

Cilji: Sestavljen je iz informacij o modulih, funkcijah, testnih podatkih itd., ki označujejo cilj aplikacije, pomeni vedenje aplikacije, cilj itd.

Obseg: Vsebuje informacije, ki jih je treba preizkusiti glede na aplikacijo. Obseg lahko nadalje razdelimo na dva dela:

V obsegu
Izven obsega

V obsegu: To so moduli, ki jih je treba strogo (podrobno) testirati.

Zunanji obseg: To so moduli, ki jih ni treba rigorozno testirati.

Na primer , Recimo, da imamo aplikacijo Gmail za testiranje, kjer funkcije, ki jih je treba preizkusiti kot naprimer Nova pošta, Poslani predmeti, Prejeto, Osnutki in funkcije, ki jih ni mogoče preizkusiti kot naprimer pomoč in tako naprej, kar pomeni, da se bomo v fazi načrtovanja odločili, katero funkcionalnost je treba preveriti ali ne, glede na časovno omejitev, navedeno v izdelku.

zdaj kako se odločimo, katere lastnosti ne bomo testirali?

Imamo naslednje vidike, pri katerih se lahko odločimo, katere funkcije ne bomo preizkusili:

Kot vidimo zgoraj pomoč lastnosti ne bodo testirane, saj jih je napisal in razvil tehnični pisec, pregledal pa jih je drug poklicni pisec.
Predpostavimo, da imamo eno aplikacijo, ki ima P, Q, R in S funkcije, ki jih je treba razviti na podlagi zahtev. Tukaj pa je funkcijo S že oblikovalo in uporabljalo neko drugo podjetje. Tako bo razvojna ekipa od tega podjetja kupila S in ga integrirala z dodatnimi funkcijami, kot so P, Q in R.

Zdaj ne bomo izvajali funkcionalnega testiranja funkcije S, ker je bila že uporabljena v realnem času. Izvedli pa bomo testiranje integracije in sistemsko testiranje med funkcijami P, Q, R in S, ker nove funkcije morda ne bodo delovale pravilno s funkcijo S, kot lahko vidimo na spodnji sliki:

Recimo, da so v prvi izdaji izdelka razviti elementi, kot npr P, Q, R, S, T, U, V, W…..X, Y, Z . Zdaj bo stranka podala zahteve za nove funkcije, ki izboljšujejo izdelek v drugi izdaji, in nove funkcije so A1, B2, C3, D4 in E5.

Po tem bomo med testnim načrtom zapisali obseg kot

Obseg

java je naslednja

Funkcije, ki jih je treba preizkusiti

A1, B2, C3, D4, E5 (nove funkcije)

P, Q, R, S, T

Lastnosti, ki se ne testirajo

W…..X, Y, Z

Zato bomo najprej preverili nove funkcije in nato nadaljevali s starimi funkcijami, ker bi to lahko vplivalo po dodajanju novih funkcij, kar pomeni, da bo vplivalo tudi na področja vpliva, zato bomo izvedli en krog regresivnih testiranj za P, Q , R…, T funkcije.

Metodologija testiranja:

Vsebuje informacije o izvajanju različnih vrst testiranja, kot so funkcionalno testiranje, integracijsko testiranje in sistemsko testiranje itd. v aplikaciji. Pri tem se bomo odločili, kakšno vrsto testiranja; izvedli bomo različne funkcije glede na zahteve aplikacije. In tukaj bi morali tudi opredeliti, kakšno testiranje bomo uporabili v metodologijah testiranja, da bi lahko vsi, kot so vodstvo, razvojna ekipa in ekipa za testiranje, zlahka razumeli, ker pogoji testiranja niso standardni.

na primer za samostojno uporabo, kot npr Adobe Photoshop , bomo izvajali naslednje vrste testiranj:

Testiranje dima → Funkcionalno testiranje → Testiranje integracije → Testiranje sistema → Testiranje adhoc → Testiranje združljivosti → Regresijsko testiranje → Testiranje globalizacije → Testiranje dostopnosti → Testiranje uporabnosti → Testiranje zanesljivosti → Testiranje obnovitve → Testiranje namestitve ali odstranitve

In recimo, da moramo preizkusiti https://www.jeevansathi.com/ aplikacije, zato bomo izvajali naslednje vrste testiranj:

Testiranje dima	Funkcionalno testiranje	Integracijsko testiranje
Testiranje sistema	Adhoc testiranje	Testiranje združljivosti
Regresijsko testiranje	Globalizacijsko testiranje	Testiranje dostopnosti
Testiranje uporabnosti	Testiranje delovanja

Pristop

Ta atribut se uporablja za opis poteka aplikacije med izvajanjem testiranja in za prihodnjo referenco.

sneg proti ledu

Potek aplikacije lahko razumemo s pomočjo spodnjih vidikov:

S pisanjem scenarijev na visoki ravni S pisanjem grafa toka

S pisanjem scenarijev na visoki ravni

Na primer , recimo, da preizkušamo Gmail aplikacija:

Prijavite se v Gmail – pošlje e-pošto in preveri, ali je na strani Poslano
Prijavite se v …….
……
…....

To pišemo, da bi opisali pristope, ki jih je treba uporabiti za testiranje izdelka in samo za kritične funkcije, kjer bomo napisali scenarije na visoki ravni. Tukaj se ne bomo osredotočali na pokrivanje vseh scenarijev, ker se lahko posamezen testni inženir odloči, katere funkcije je treba preizkusiti ali ne.

S pisanjem grafa toka

Graf poteka je napisan, ker je pisanje scenarijev na visoki ravni dolgotrajen proces, kot lahko vidimo na spodnji sliki:

Ustvarjamo diagrame poteka, da zagotovimo naslednje prednosti, kot so:

Pokritost je enostavna
Združevanje je enostavno

Pristop je mogoče razvrstiti v dva dela, ki sta naslednja:

Pristop od zgoraj navzdol
Pristop od spodaj navzgor

Vnebovzetje

Vsebuje informacije o težavi ali vprašanju, ki se je morda pojavilo med postopkom testiranja in ko pišemo testne načrte, bi bile narejene zagotovljene predpostavke, kot so viri in tehnologije itd.

Tveganje

To so izzivi, s katerimi se moramo soočiti, da preizkusimo aplikacijo v trenutni izdaji, in če predpostavke ne bodo uspele, potem so vključena tveganja.

na primer učinek za aplikacijo, datum izdaje postane odložen.

Načrt ublažitve ali načrt ukrepov ob nepredvidljivih dogodkih

Je rezervni načrt, ki je pripravljen za premagovanje tveganj ali težav.

Oglejmo si en primer za predpostavko, tveganje in načrt ukrepov ob nepredvidljivih dogodkih skupaj, ker so medsebojno povezani.

V katerem koli izdelku, predpostavka naredili bomo, da bodo vsi 3 testni inženirji prisotni do dokončanja izdelka in vsakemu od njih bodo dodeljeni različni moduli, kot so P, Q in R. V tem posebnem scenariju je tveganje to bi se lahko zgodilo, če bi inženir zapustil projekt sredi projekta.

Zato je krizni načrt bo vsakemu elementu dodeljen primarni in podrejeni lastnik. Torej, če en testni inženir odide, podrejeni lastnik prevzame to posebno funkcijo in tudi pomaga novemu testnemu inženirju, da lahko razume njihove dodeljene module.

Predpostavke, tveganje in načrt za ublažitev ali izredne razmere so vedno natančni na samem izdelku. Različne vrste tveganj so naslednje:

Pogled kupca
Pristop k virom
Tehnično mnenje

Vloga in odgovornost

Določa celotno nalogo, ki jo mora opraviti celotna ekipa za testiranje. Ko pride velik projekt, potem Vodja testov je oseba, ki piše testni načrt. Če obstajajo 3-4 majhni projekti, bo vodja testiranja vsak projekt dodelil vsakemu vodji testiranja. Nato vodja testa napiše testni načrt za projekt, ki mu je dodeljen.

Oglejmo si en primer, kjer bomo razumeli vloge in odgovornost vodje testiranja, vodje testiranja in inženirjev za testiranje.

Vloga: Vodja testiranja

Ime: Ryan

Odgovornost:

Pripravite (napišite in pregledajte) testni načrt
Izvedite sestanek z razvojno ekipo
Izvedite sestanek z ekipo za testiranje
Izvedite sestanek s stranko
Izvedite en mesečni stand up sestanek
Podpišite obvestilo o izdaji
Obravnavanje eskalacij in težav

Vloga: Vodja testiranja

Ime: Harvey

Odgovornost:

Pripravite (napišite in pregledajte) testni načrt
Vodite vsakodnevno stand up srečanje
Preglejte in potrdite testni primer
Pripravite RTM in poročila
Dodelite module
Urnik ravnanja

Vloga: Testni inženir 1, Testni inženir 2 in Testni inženir 3

Ime: Louis, Jessica, Donna

Dodelite module: M1, M2 in M3

Odgovornost:

Napišite, pregledajte in izvedite testne dokumente, ki so sestavljeni iz testnega primera in testnih scenarijev
Preberite, preglejte, razumejte in analizirajte zahtevo
Napišite potek aplikacije
Izvedite testni primer
RTM za posamezne module
Sledenje napakam
Pripravite poročilo o izvedbi testa in ga posredujte vodji testa.

Urnik

Uporablja se za razlago časovnega razporeda za delo, kar je treba storiti, ali ta atribut zajema, kdaj točno naj se vsaka dejavnost testiranja začne in konča? Natančni podatki so navedeni tudi za vsako aktivnost testiranja za določen datum.

Torej, kot lahko vidimo na spodnji sliki, bosta za določeno dejavnost obstajala začetni in končni datum; za vsako testiranje določene zgradbe bo naveden datum.

Na primer

Pisanje testnih primerov
Postopek izvedbe

Sledenje napakam

Običajno se izvaja s pomočjo orodij, ker ne moremo ročno slediti statusu vsake napake. Prav tako komentiramo, kako sporočamo napake, ki so bile ugotovljene med postopkom testiranja, in jih pošiljamo nazaj razvojni skupini ter kako bo razvojna ekipa odgovorila. Tukaj omenimo tudi prioriteto hroščev, kot so visoka, srednja in nizka.

Sledijo različni vidiki sledenja napakam:

Blokater ali showstopper

Na primer

Kritično

Major

Minor

Visoko-P1

Srednje-P2

Nizek P3

Zato ga bomo na podlagi prioritete hroščev, kot so visoka, srednja in nizka, kategorizirali kot P1, P2, P3 in P4.

Testna okolja

To so okolja, v katerih bomo testirali aplikacijo, in tukaj imamo dve vrsti okolij, ki sta programsko opremo in strojna oprema konfiguracijo.

The konfiguracijo programske opreme pomeni podrobnosti o različnih Operacijski sistemi kot naprimer Windows, Linux, UNIX in Mac in različne Brskalniki kot Google Chrome, Firefox, Opera, Internet Explorer , in tako naprej.

In konfiguracijo strojne opreme pomeni informacije o različnih velikostih RAM, ROM in procesorji .

Na primer

The Programska oprema vključuje naslednje:

Strežnik

Operacijski sistem	Linux
spletni strežnik	Apache Tomcat
Aplikacijski strežnik	Websphere
Strežnik baze podatkov	Oracle ali MS-SQL Server

Opomba: Zgornji strežniki so strežniki, ki jih ekipa za testiranje uporablja za testiranje aplikacije.

Stranka

Operacijski sistem	Windows XP, Vista 7
Brskalniki	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 in Internet Explorer 8

Opomba: Zgornje podrobnosti navajajo različne operacijske sisteme in brskalnike, v katerih bo skupina za preizkušanje testirala aplikacijo.

The Strojna oprema vključuje naslednje:

Strežnik : Sun StarCat 1500

Ta poseben strežnik lahko skupina za testiranje uporabi za testiranje svoje aplikacije.

Naročnik:

sql concat

Ima naslednjo konfiguracijo, ki je naslednja:

Procesor	Intal 2GHz
Oven	2 GB
….	….

Opomba: zagotovil bo konfiguracijo sistemov testnih inženirjev, ki so ekipa za testiranje.

Razvojna skupina bo zagotovila konfiguracijo za namestitev programske opreme. Če razvojna ekipa še ne bo zagotovila procesa, ga bomo v testnem načrtu zapisali kot Task-Based Development (TBD).

Kriteriji vstopa in izstopa

Je nujen pogoj, ki mora biti izpolnjen pred začetkom in ustavitvijo postopka testiranja.

Vstopna merila

Vstopna merila vsebujejo naslednje pogoje:

Testiranje bele škatle bi moralo biti končano.
Razumeti in analizirati zahtevo ter pripraviti testne dokumente ali ko bodo testni dokumenti pripravljeni.
Testni podatki morajo biti pripravljeni.
Pripraviti je treba gradnjo ali aplikacijo
Module ali funkcije je treba dodeliti različnim testnim inženirjem.
Potreben vir mora biti pripravljen.

Izhodna merila

Izstopna merila vsebujejo naslednje pogoje:

Ko so vsi testni primeri izvedeni.
Večina testnih primerov mora biti opravili .
Odvisno od resnosti napak, kar pomeni, da ne sme biti nobenih blokatorjev ali večjih napak, nekaj manjših napak pa obstaja.

Preden začnemo izvajati funkcionalno testiranje, vse zgoraj našteto Vstopna merila je treba upoštevati. Ko smo izvedli funkcionalno testiranje in preden bomo izvedli integracijsko testiranje, potem Izhodna merila slediti je treba funkcionalnemu testiranju, ker se % izhodnih meril določi na sestanku z vodjo razvoja in testiranja, ker lahko njuno sodelovanje doseže odstotek. Toda če izhodni kriteriji funkcionalnega testiranja niso upoštevani, potem ne moremo nadaljevati s testiranjem integracije.

Tukaj glede na resnost hrošča pomeni, da bi se ekipa za testiranje odločila, da bo nadaljevala v naslednjih fazah.

Avtomatizacija testiranja

Pri tem se bomo odločili o naslednjem:

Katera funkcija mora biti avtomatizirana in katera ne?
Katero orodje za avtomatizacijo testiranja bomo uporabili na katerem ogrodju za avtomatizacijo?

Testni primer avtomatiziramo šele po prvi izdaji.

polna oblika i d e

Tu se postavlja vprašanje, na podlagi česa mi volja odločite, katere funkcije je treba preizkusiti?

Kot lahko vidimo na zgornji sliki, je treba najpogosteje uporabljene funkcije znova in znova testirati. Recimo, da moramo preveriti aplikacijo Gmail, kjer so bistvene funkcije Nova pošta, Poslani predmeti in Prejeto . Zato bomo testirali te funkcije, saj ročno testiranje vzame več časa in postane tudi monotono delo.

zdaj, kako se odločimo, katere funkcije ne bodo testirane?

Recimo Pomoč funkcije aplikacije Gmail ne preizkušamo znova in znova, ker se te funkcije ne uporabljajo redno, zato nam je ni treba pogosto preverjati.

Ampak če so nekatere funkcije nestabilne in imajo veliko napak , kar pomeni, da teh funkcij ne bomo testirali, ker jih je treba med ročnim testiranjem vedno znova testirati.

če obstaja funkcija, ki jo je treba pogosto testirati , vendar pričakujemo spremembo zahteve za to funkcijo, zato je ne preverjamo, ker je spreminjanje ročnih testnih primerov udobnejše v primerjavi s spremembo v skriptu za avtomatizacijo.

Ocena napora

Pri tem bomo načrtovali napor, ki ga mora vložiti vsak član ekipe.

Dobavljivi test

To so dokumenti, ki so rezultat ekipe za testiranje, ki smo jih skupaj z izdelkom predali stranki. Vključuje naslednje:

Testni načrt Testni primeri Testni skripti RTM (Matrika sledljivosti zahtev) Poročilo o napaki Poročilo o izvedbi testa Grafi in metrike Opombe ob izdaji

Grafi in metrike

Graf

V tem članku bomo govorili o vrstah grafi bomo poslali, posredovali pa bomo tudi vzorec vsakega grafa.

Kot lahko vidimo, imamo pet različnih grafov, ki prikazujejo različne vidike postopka testiranja.

Graf1: V tem bomo pokazali, koliko napak je bilo ugotovljenih in koliko napak je bilo odpravljenih v vsakem modulu.

Graf 2: Slika ena prikazuje, koliko kritičnih, večjih in manjših napak je bilo ugotovljenih za vsak modul in koliko jih je bilo odpravljenih za posamezne module.

Graf3: V tem posebnem grafu predstavljamo zgraditi pameten graf , kar pomeni, da je bilo v vsaki zgradbi koliko napak ugotovljenih in odpravljenih za vsak modul. Na podlagi modula smo določili napake. Dodali bomo R za prikaz števila napak v P in Q, dodamo pa tudi S za prikaz napak v P, Q in R.

Graf4: Preskusni vodja bo oblikoval Analiza trendov napak graf, ki nastaja vsak mesec, in ga pošljete tudi upravi. In to je kot napoved, ki se naredi na koncu izdelka. In tukaj lahko tudi mi ocenite popravke napak kot lahko opazimo, da lok ima težnja navzgor na spodnji sliki.

Graf5: The Vodja testov je oblikoval to vrsto grafa. Ta graf je namenjen razumevanju vrzeli v oceni hroščev in dejanskih hroščev, ki so se pojavili, poleg tega ta graf pomaga izboljšati ocenjevanje hroščev v prihodnosti.

Metrike

Kot zgoraj, ustvarimo graf porazdelitve hroščev, ki je na sliki 1, in s pomočjo zgoraj omenjenih podatkov bomo oblikovali tudi meritve.

Na primer

Na zgornji sliki hranimo zapise o vseh inženirjih za testiranje v določenem projektu in o tem, koliko napak je bilo ugotovljenih in odpravljenih. Te podatke lahko uporabimo tudi za prihodnje analize. Ko pride nova zahteva, se lahko odločimo, komu bomo zagotovili zahtevno funkcijo za testiranje na podlagi števila napak, ki so jih prej odkrili v skladu z zgornjimi meritvami. In bolje bomo vedeli, kdo lahko zelo dobro obravnava problematične funkcije in najde največje število napak.

Opomba ob izdaji: To je dokument, ki se pripravi ob izdaji izdelka in ga podpiše vodja testiranja.

Na spodnji sliki lahko vidimo, da je končni izdelek razvit in uveden stranki, ime zadnje izdaje pa je Beta .

The Opomba ob izdaji sestoji iz naslednjega:

Navodila za uporabo.
Seznam čakajočih in odprtih napak.
Seznam dodanih, spremenjenih in izbrisanih funkcij.
Seznam platforme (operacijski sistem, strojna oprema, brskalniki), na kateri je izdelek testiran.
Platforma, v kateri izdelek ni testiran.
Seznam hroščev, odpravljenih v trenutni izdaji, in seznam odpravljenih hroščev v prejšnji izdaji.
Postopek namestitve
Različice programske opreme

Na primer

Recimo, da Beta je druga izdaja aplikacije po prvi izdaji Alfa je sproščen. Nekatere napake, ugotovljene v prvi izdaji, ki so bile odpravljene v kasnejši izdaji. In tukaj bomo izpostavili tudi seznam na novo dodanih, spremenjenih in izbrisanih funkcij od izdaje alfa do izdaje beta.

Predloga

Ta del vsebuje vse predloge za dokumente, ki bodo uporabljeni v izdelku, in vsi testni inženirji bodo v projektu uporabljali samo te predloge, da ohranijo konsistentnost izdelka. Tukaj imamo različne vrste predlog, ki se uporabljajo med celotnim postopkom testiranja, kot so:

Predloga testnega primera
Predloga za pregled testnega primera
Predloga RTM
Predloga poročila o napakah
Poročilo o izvedbi testa

Oglejmo si en vzorec dokumenta testnega načrta

Stran-1

Stran3-stran18

Stran-20

Na strani 1 primarno izpolnimo samo Različice, avtor, komentarji in recenzent polja, po odobritvi upravitelja pa bomo podrobnosti zapisali v Odobreno do in datum odobritve polja.

Testni načrt večinoma odobri vodja testov, testni inženirji pa ga le pregledajo. In ko bodo prišle nove funkcije, bomo spremenili testni načrt in izvedli potrebne spremembe Različica polje, nato pa bo ponovno poslano v nadaljnji pregled, posodobitev in odobritev upravitelju. Testni načrt je treba posodobiti vsakič, ko pride do kakršnih koli sprememb. Na strani 20 je Reference navedite podrobnosti o vseh dokumentih, ki jih bomo uporabili za pisanje dokumenta testnega načrta.

Opomba:

Kdo piše testni načrt?

Testni vod → 60 %
Vodja testov→20%
Testni inženir→20 %

Torej, kot lahko vidimo od zgoraj, je v 60% izdelka testni načrt napisal vodja testa.

Kdo pregleda testni načrt?

Testni vodnik
Vodja testov
Testni inženir
Stranka
Razvojna ekipa

Inženir testiranja pregleda načrt testiranja glede na svoj modul, vodja testiranja pa pregleda načrt testiranja na podlagi mnenja stranke.

Kdo odobri načrt testiranja?

Stranka
Vodja testov

Kdo piše testni primer?

Testni vodnik
Testni inženir

Kdo pregleda testni primer?

natisni zvezdasti vzorec

Testni inženir
Testni vodnik
Stranka
Razvojna ekipa

Kdo odobri testne primere?

Vodja testov
Testni vodnik
Stranka

Smernice za načrt testiranja

Strni svoj testni načrt.
Izogibajte se prekrivanju in odvečnosti.
Če menite, da razdelka, ki je že omenjen zgoraj, ne potrebujete, ga izbrišite in nadaljujte.
Bodite natančni. Na primer, ko določite programski sistem kot del testnega okolja, navedite različico programske opreme namesto samo imena.
Izogibajte se dolgim odstavkom.
Uporabite sezname in tabele, kjer koli je to mogoče.
Po potrebi posodobite načrt.
Ne uporabljajte zastarelega in neuporabljenega dokumenta.

Pomen testnega načrta

Testni načrt usmerja naše razmišljanje. To je kot knjiga pravil, ki se jih je treba držati.
Testni načrt pomaga pri določanju potrebnih naporov za potrditev kakovosti programske aplikacije v testu.
Testni načrt tem ljudem pomaga razumeti podrobnosti testa, ki so povezane z zunanjostjo, kot so razvijalci, vodje podjetij, stranke itd.
Pomembni vidiki, kot so urnik testiranja, strategija testiranja, obseg testiranja itd., so dokumentirani v načrtu testiranja, tako da jih lahko vodstvena ekipa pregleda in ponovno uporabi za druge podobne projekte.