Пробен пример
Во софтверското инженерство, пробен пример е спецификација на влезовите, условите за извршување, постапката за испробување и очекуваните резултати што дефинираат единствен тест што треба да се изврши за да се постигне одредена цел за испробување на програмска опрема.[1] Пробните примери се темели на испробувањето што е повеќе методско, отколку случајно. Може да се изгради батерија на пробни примери за да се произведе посакуваната покриеност на софтверот што се испробува. Формално дефинираните пробни примери овозможуваат истите тестови да се извршуваат постојано против последователни верзии на софтверот, овозможувајќи делотворно и доследно регресивно испробување.[2]
Формални пробни примери
уредиСо цел целосно да се испробува дали се исполнети сите барања на апликацијата, мора да има најмалку два пробни примери за секое барање: еден позитивен тест и еден негативен тест.[3] Ако некое барање има под-побарувања, секој под-услов мора да има најмалку два случаи на испитување. Следење на врската помеѓу барањето и тестот често се прави со употреба на матрица за следливост. Напишаните пробни примери треба да содржат опис на функционалноста што треба да се испробува и потребната подготовка за да се обезбеди дека тестот може да се спроведе.
Формално напишаните пробни примери се одликуваат со познат влез и со очекуван излез, кој е изработен пред да се изврши тестот.[4] Познатиот влез треба да испробува предуслов, а очекуваниот излез треба да испробува постуслов.
Неформални пробни примери
уредиЗа апликации или системи без формални барања, пробните примери може да се напишат врз основа на прифатената нормална работа на програми од слична класа. Во некои училишта за испробување, пробните примери воопшто не се напишани, но активностите и резултатите се пријавуваат откако ќе бидат извршени тестовите.
Во испробувањето на сценариото, хипотетичките приказни се користат за да му помогнат на тестерот да размисли за сложен проблем или систем. Овие сценарија обично не се запишуваат детално. Тие можат да бидат едноставни како дијаграм за средина за испробување или да бидат опис напишан во проза. Идеален тест за сценарио е приказна која е мотивирачка, веродостојна, комплексна и лесна за проценка. Тие обично се разликуваат од пробните примери по тоа што случаите на испробување се единечни чекори, додека сценаријата опфаќаат голем број чекори на клучот.[5][6]
Типичен формат за пишување на пробен пример
уредиПробниот пример е обично еден чекор, или повремено низа чекори, за да се испробува правилното однесување/функционалност, одликите на апликацијата. Обично се дава очекуван резултат или очекуван исход.[7]
Дополнителни информации што можат да бидат вклучени:[8]
- ID на пробен пример- ова поле уникатно го идентификува пробниот пример.
- Опис/резиме на пробен пример - ова поле ја опишува целта на пробниот пример.
- Чекори за испробување- во ова поле, се споменуваат точните чекори за изведување на пробниот пример.
- Предуслови- ова поле ги специфицира условите или чекорите што мора да се следат пред извршувањето на чекорите на тестот.
- Длабочина
- Тест категорија
- Автор- Име на тестерот.
- Автоматизација - Без разлика дали овој пробен пример е автоматизиран или не.
- поминува/пропаѓа
- Забелешки/коментари
Поголемите тест случаи може да содржат предуслви, состојби и описи.[8]
Пишувањето на пробен пример исто така треба да содржи место за вистинскиот резултат.
Овие чекори можат да бидат зачувани во обработувачки текстуален документ, табеларни пресметки, база на податоци или друго заедничко складиште.
Во системот на основа на податоци, можеби ќе можете да ги видите и резултатите од минатите тестови и кој ги генерирал резултатите и системската конфигурација што се користи за генерирање на тие резултати. Овие минати резултати обично се чуваат во посебна табела.
Тест пакетите често содржат и:[9]
- Резиме на тест
- Конфигурација
Покрај описот на функционалноста што треба да се испробува и подготовката потребна за да се осигура дека тестот може да се спроведе, најмногу време е потребно за да се создаваат тестови и да се модифицираат кога системот ќе се смени.
Под посебни околности, може да има потреба да се изврши тестот, да се дадат резултати, а потоа тим од експерти ќе проценат дали резултатите може да се сметаат како поминати/успешни. Ова се случува често при одредување на бројот на перформанси на новите производи. Првиот тест се зема како основна линија за последователните циклуси на испитување и ослободување на производот.
Тестовите за прифаќање, кои користат варијација на пишан тест случај, најчесто се изведуваат од група крајни корисници или клиенти на системот за да се осигури дека развиениот систем ги исполнува наведените барања или договорот.[10][11] Тестовите за прифаќање на корисниците се разликуваат со вклучување на случаи на среќна патека или позитивни тестови до скоро целосно исклучување на случаи со негативни тестови.[12]
Поврзано
уреди- Classification Tree Method
Наводи
уреди- ↑ Systems and software engineering – Vocabulary. Iso/Iec/IEEE 24765:2010(E). 2010-12-01. стр. 1–418. doi:10.1109/IEEESTD.2010.5733835. ISBN 978-0-7381-6205-8.
- ↑ Kaner, Cem (May 2003). „What Is a Good Test Case?“ (PDF). STAR East: 2. Архивирано од изворникот (PDF) на 2017-07-12. Посетено на 2021-02-20.
- ↑ „Writing Test Rules to Verify Stakeholder Requirements“. StickyMinds.
- ↑ Beizer, Boris (May 22, 1995). Black Box Testing. New York: Wiley. стр. 3. ISBN 9780471120940.
- ↑ „An Introduction to Scenario Testing“ (PDF). Cem Kaner. Архивирано од изворникот (PDF) на 2009-04-07. Посетено на 2009-05-07.
- ↑ Crispin, Lisa; Gregory, Janet (2009). Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley. стр. 192–5. ISBN 978-81-317-3068-3.
- ↑ https://www.softwaretestingstandard.org/part3.php Архивирано на 22 јуни 2020 г. ISO/IEC/IEEE 29119-4:2019, "Part 4: Test techniques"
- ↑ 8,0 8,1 Liu, Juan (2014). „Studies of the Software Test Processes Based on GUI“. 2014 International Conference on Computer, Network: 113–121. doi:10.1109/CSCI.2014.104. ISBN 9781605951676. Посетено на 2019-10-22.
- ↑ Kaner, Cem; Falk, Jack; Nguyen, Hung Q. (1993). Testing Computer Software (2. изд.). Boston: Thomson Computer Press. стр. 123–4. ISBN 1-85032-847-1.
- ↑ Goethem, Brian Hambling, Pauline van (2013). User acceptance testing : a step-by-step guide. BCS Learning & Development Limited. ISBN 9781780171678.
- ↑ Black, Rex (August 2009). Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing. Hoboken, NJ: Wiley. ISBN 978-0-470-40415-7.
- ↑ Cimperman, Rob (2006). UAT Defined: A Guide to Practical User Acceptance Testing. Pearson Education. стр. Chapter 2. ISBN 9780132702621.