Klaidų valdymas: kuri stebėjimo programinė įranga yra geriausia?

Patikrinus šias ataskaitas, visada bus atskleista daugybė klaidų, kurios yra „sulenktos“, nes jos tik dubliuoja esamas, o kai kuriais atvejais net nėra tos konkrečios programinės įrangos klaidų. Svarbi bet kurios pranešimų apie klaidas sistemos dalis yra būdas, kuriuo ji valdo kiekvienos klaidos gyvavimo laiką, o tai bus padaryta paprastai skirstomi į tris fazes: pradinė „atidarymo fazė“, „fiksavimo/žudymo fazė“ ir „uždarymas/palaidojimas“. fazė“.

Klaidų valdymas: kuri stebėjimo programinė įranga yra geriausia?

Pirma fazė

Atidarymo fazė yra tada, kai klaida pirmą kartą įvedama į sistemą, o po to bus atliekamas įvairių tipų skirstymas, kurio metu klaida patikrinama ir priimama.

Įvairios sistemos palaiko klaidų atidarymą skirtingais būdais, tačiau pagrindinis sprendimas yra tai, ar vartotojams leidžiama pranešti apie klaidas tiesiai į klaidų valdymo sistemą, ar ne. Iš pradžių tai yra patraukli mintis, tačiau, kaip jau minėjau, dauguma vartotojų nelabai moka pranešti apie klaidas.

Pasirinkus šį maršrutą, šiuo metu daugelis pranešimų apie klaidas paprastai bus uždaromi, nes jų negali patvirtinti pats asmuo. patikrinti ar net pranešti apie klaidą – kitaip jie negali būti priimti (kaip „Mes nebepalaikome Internet Explorer 4 jokioje platformoje ir niekada nepalaikome Mac“).

Vykdant šį procesą, riktos įrodymai turės būti užfiksuoti ir priskirti riktų ataskaitai, o jam priskirtas sunkumo lygis, kuris kai kuriais atvejais gali būti nulemtas balsavimu („Ar tikrai reikia taisyti tai?").

Atidaryta klaida

Kai klaida bus atidaryta, ji turės būti priskirta asmeniui arba grupei, kuris ketina ją ištaisyti. Taisymo procesas gali labai skirtis, tačiau jis turės veikti su įrankiais, kuriuos jau naudojame: kūrimo aplinkas, šaltinio kodo valdymo sistemas ir bandymų rinkinius.

Nepamirškime, kad testavimas yra esminė taisymo dalis

Nepamirškime, kad testavimas yra esminė taisymo dalis, todėl mums reikės tam tikro būdo, kaip perduoti šią ataskaitą bandytojui, kad įsitikintume, jog ji pašalinta. Tam tikru momentu klaida bus pašalinta, o tada reikės uždaryti, kad pakeitimai būtų konsoliduojami ir prireikus taikomi bet kurioms kitoms susijusioms sistemoms.

Taigi, kokie buvo mūsų kriterijai, rinkdamiesi pranešimų apie klaidas sistemą? Dėl įvairių priežasčių nesame suinteresuoti leisti vartotojams įvesti klaidų tiesiai į mūsų sistemą – naudosime kitą maršrutą.

Be to, mums reikėjo pranešimų apie klaidas sistemos, kad ji veiktų su esama šaltinio kodo valdymo sistema, kuri yra Subversion. Galiausiai būtų gerai, jei pranešimų apie klaidas sistema galėtų tam tikru mastu integruotis su Eclipse IDE (integruota kūrimo aplinka), kurią naudojame dažniausiai.

„Eclipse“ turi modulį, pavadintą „Mylyn“, kuris yra skirtas būtent šiai integracijai, todėl „Mylyn“ palaikymas būtų naudingas. „Mylyn“ jau keletą leidimų yra „Eclipse“ dalis, o dabartiniame leidime (3.6 arba „Helios“) buvo patobulinta, kaip aptarta toliau pateiktame langelyje.

Deja, ne visas mūsų programavimas atliekamas „Eclipse“, o „Apple Xcode“ aplinka nepalaiko jokios klaidų valdymo sistema („Apple“ programinė įranga niekada neturi klaidų, tereikia ją tinkamai laikyti), todėl mums reikėjo geros atskiros vartotojo sąsajos taip pat.