Loading...
IvoArsov avatar IvoArsov 44 Точки

Няколко въпроса за изпита

Привет, 

имам няколко въпроса, чиито отговор ще бъде полезен на доста хора:

 

1.За еднотипни бъгове в различни секция, отделни issues ли се пускат? Например: в чалгарския форум голяма част от бутоните и надписите не са ясно видими. Това с едно issue ли се минава?

2.Можем ли да "рисуваме" по screenshot-ите, стрелки и т.н.?

3.Ако намерим missconception в SRS-a, къде да го опишем?

4.При автоматизираните тестове, да тестваме ли за XSS атаки и SQL injections?

5.Като стана въпрос за SQL injections, какво е поведението на приложението ако има такава атака? Смисъл, в логин формата пишем 

' OR 1=1;--

и какво се случва, ако не се ескеипне?

 

Благордаря предварително ;)

 

2
QA Fundamentals
RoYaL avatar RoYaL Trainer 6849 Точки
Best Answer

Здравей,

 

1. По принцип би било хубаво да са отделни issue-та. Защото може поетапно да ги оправи програмиста. Поне така би било в реална среда. Ако видиш, че те притиска времето ги пусни в едно issue. Също разцъкай малко в JIRA "More" таба на issue-тата. Там има опция Clone, така че можеш едно issue да го клонираш.

2. Можеш да "цапаш" скрийншотите, ако сметнеш, че така по-добре ще разбере човека, на когото репортваш. Понякога даже е силно препоръчително.

3. Неяснотиите по спецификацията се репортват също в тракера. Изпращай ги до отговорния за спецификацията. В случая на изпита това е Project Manager-a.

4. Колкото по-широк е обхватът на автоматизирания тест, толкова по-добре. И в реална среда и на изпита, също. Ако имаш автоматизация, която тества за различни видове атаки, няма да ти се налага всеки ден да го правиш ръчно. Както може да регресира дадена функционалност, така може да регресира и сигурността на приложението. Аз лично препоръчвам преди да стигнеш до автоматизация на сигурността, да минеш през по-основните функционални тестове, като например дали дадената функционалност въобще работи по спецификация. В случая с коментарите на албумите това беше - дали гост може да коментира (съответния error box); дали регистриран може да коментира; дали админ може да коментира. Дали правилно се появява коментара. Дали е от правилния потребител. Дали е с правилната дата. След като минеш през тези, тогава ако остане време автоматизирай тестването на сигурността.

5. Няма one best scenario в тази случка. При логин форма, ако този скрипт мине, най-вероятно ще се логнеш с някой потребител. Евентуално първият в таблицата с потребители, който вероятно е администраторът. Ако си подкарал изпитите при теб, шансовете са, че имаш MySQL. На http://localhost:8023/phpmyadmin (или без 8023, ако не си оправял порта) имаш административен инструмент за достъп до MySQL. Пробвай през него да навигираш до таблицата с потребители на някой от изпитите. Има опция да филтрираш данните. През туулчето избери да филтрираш до някой потребител с парола и то ще ти генерира заявка. Нещо от рода на "SELECT * FROM users WHERE username = 'pesho' AND password = '!$f4553443ef645g457567';". Вземи тази заявка и я пусни в SQL табчето, само че вместо pesho сложи скрипта, и ще видиш какъв де факто е резултатът. SQL injection атаката прави точно това, каквото пише в името й. Инжектира SQL код в заявка, правейки я различна от очакваната за програмиста и евентуално удобна за съответния атакуващ. Най-честият начин да разбереш дали има такава дупка е кодът, който си дал, но може по някога и по-сложни заявки да трябва да се сложат, за да мине атаката (обикновено такива успяват да бъдат намерени, когато приложението е с отворен код).

 

Надявам се да съм успял да ти отговоря и да е било полезно и за останалите.

 

Поздрави,

Иван

4
Petradj avatar Petradj 4 Точки

Здрасти, 

Относно "административен инструмент". Иска ми username and pass. Пробвах всичко възможно. admin/admin и т.н. Какво всъщност трябва да ползваме за логина?

0
07/05/2016 10:01:03
IvoArsov avatar IvoArsov 44 Точки

Username: root

password: {не пишеш нищо}

1
anamariyat avatar anamariyat 9 Точки

Здравей,

Заинтригува ме 4-тият ти въпрос. Относно SQL injection, има около 10 различни типа атаки и е доста трудно да напишеш сам автоматизиран тест за това, който да ти даде реални резултати. Подобна е и ситуацията с XSS.

За тестване на XSS, CSRF, Path Traversal, SQL-i и тн. има специални тулове които обхващат повече видове атаки, а има и level of penetration, който може да избереш, спрямо това колко време за тестване имаш. Най-хубавото при ползване на такива тулове е, че след края на тестовете ти се генерира report описващ слабостите в системата приоритизирани, както и основни решения на появилите се проблеми. 

Аз лично ползвам OWASP ZAP и смятам тула за много удобен и лесен за този тип тестване. 

1
IvoArsov avatar IvoArsov 44 Точки

Добро утро,

благодаря, ще го имам впредвид.

0

Аз малко се обърквам с тези видове бъгове.

Според мен всеки един бъг, който открия, но не е описан във SRS-a , отива за одобрение от Project Manager-а, с изключение на някой важни security бъгове или дизайнерски, които са очеизвадни. 

Но например ако цветът на бутон е в зелен цвят и той не е описан в SRS-a, не е правилно да репортвам до дизайнера, защото на мен не ми е харесало зеленото. Редно е ПМ-а да попита клиента и след това да предприеме действия за промяна или не.

Отделно имам и такова питане: Може ли бъг, който не е описан в СРС-а да бъде функционален или по-скоро в 90% е user acceptance ???  Ако е възможно да е функционален без да е описан в СРС-а бихте ли ми дали пример 

А и всъщност в Jirata по-какъв начин ще покажем на проверяващите, че бъгът е функционален или cesurity , при положение , че и двата отиват към developer-a ??

Благодаря!

0
IvoArsov avatar IvoArsov 44 Точки

Здравей,

според мен, някои неща си имат поведение по подразбиране и не е нужно да се описва в спецификкацията. Например: във форум би било правилно, ако най-новите коментари са най-отгоре. Аз бих го описал като функционален бъг, ако в СРС-а не е споменато изрично някакво друго подреждане. Същото важи и за регистрационна форма, без потвърждение на паролата, например. Явно доста неща опират до преценка в частният случай. 

Поздрави!

0
05/05/2016 21:59:09
Можем ли да използваме бисквитки?
Ние използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Можете да се съгласите с всички или част от тях.
Назад
Функционални
Използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Използваме „сесийни“ бисквитки, за да Ви идентифицираме временно. Те се пазят само по време на активната употреба на услугите ни. След излизане от приложението, затваряне на браузъра или мобилното устройство, данните се трият. Използваме бисквитки, за да предоставим опцията „Запомни Ме“, която Ви позволява да използвате нашите услуги без да предоставяте потребителско име и парола. Допълнително е възможно да използваме бисквитки за да съхраняваме различни малки настройки, като избор на езика, позиции на менюта и персонализирано съдържание. Използваме бисквитки и за измерване на маркетинговите ни усилия.
Рекламни
Използваме бисквитки, за да измерваме маркетинг ефективността ни, броене на посещения, както и за проследяването дали дадено електронно писмо е било отворено.