how find bug application
Много добър и важен момент. Нали? Ако сте софтуерен тестер или QA инженер, трябва да мислите всяка минута да намерите грешка в приложение. И трябва да бъдете!
Мисля, че намирането на Блокираща грешка като всеки Срив в системата е често възнаграждаващо! Не, не мисля така. Трябва да се опитате да откриете грешките, които са най-трудни за намиране и които винаги заблуждават потребителите.
Намирането на такива фини грешки е най-предизвикателната работа и ви доставя удовлетворението от работата ви. Също така, той трябва да бъде възнаграден от възрастните хора. Ще споделя моя опит с една такава фина грешка, която беше не само трудна за улавяне, но беше и трудна за възпроизвеждане.
Тествах един модул от моя проект за търсачка. Повечето дейности по този проект правя ръчно, тъй като е малко сложно да се автоматизира. Този модул се състои от статистически данни за трафика и приходите на различни филиали и рекламодатели. Така че тестването на такива отчети винаги е трудна задача.
Когато тествах този отчет, той показваше данните, обработени точно за известно време, но когато се опита да тества отново след известно време, той показваше подвеждащи резултати. Беше странно и объркващо да видя резултатите.
Имаше Cron (Cron е автоматизиран скрипт, който се изпълнява след определено време или състояние) за обработка на регистрационните файлове и актуализиране на базата данни. Такива множество култури се изпълняват в регистрационни файлове и DB за синхронизиране на общите данни.
На една маса имаше две крони с известни интервали от време.
В таблицата имаше колона, която се презаписваше от друг Cron, което правеше някои несъответствия в данните. Отне ни много време, за да разберем проблема поради огромните DB процеси и различни Crons.
Мисълта ми е да се опитам да открия скритите грешки в системата, които могат да възникнат при специални условия и да окажат силно въздействие върху системата. Можете да намерите такава грешка с някои съвети и трикове.
най-добрият блокер за изскачащи реклами за хром
И така, какви са тези съвети:
# 1) Разберете цялото приложение или модул в дълбочина, преди да започне тестването.
# две) приготви се добри тестови случаи преди да започнете да тествате. Имам предвид да наблегна на функционалните тестови случаи, които включват основния риск от приложението.
# 3) Създайте достатъчно данни от теста преди тестове, този набор от данни включва условията на тестовия случай, както и записите в базата данни, ако ще тествате свързано с DB приложение.
# 4) Извършете многократни тестове с различна тестова среда .
# 5) Опитайте се да разберете получения модел и след това сравнете резултатите си с тези модели.
# 6) Когато смятате, че сте изпълнили повечето от условията на теста и когато смятате, че сте уморени донякъде направи малко тестване на маймуни.
# 7) Използвайте предишната си Образец на тестови данни за анализ на текущия набор от тестове.
# 8) Опитай Стандартни тестови случаи за които сте открили грешките в някакво различно приложение. Като ако тествате текстовото поле за въвеждане, опитайте да вмъкнете някои HTML тагове като входове и вижте изхода на страницата за показване.
# 9) Последният и най-добрият трик е да се опитате много да намерите грешката. Сякаш тествате само за разбиване на приложението!
Ще включа още съвети в някои следващи публикации. Междувременно можете да коментирате още съвети тук.
Препоръчително четене
- Как да напиша добър доклад за грешка? Съвети и трикове
- Топ 20 практични съвета за тестване на софтуер, които трябва да прочетете, преди да тествате приложение
- Какво е тестване на маймуни при тестване на софтуер?
- Разлика между десктоп, тестване на клиентски сървър и уеб тестване
- Примерен доклад за грешка
- Тестване на приложения за здравеопазване - съвети и важни сценарии за тестване (част 2)
- Ръководство за тестване на сигурността на уеб приложения
- 7 основни съвета за тестване на многоезични уебсайтове