• 제목/요약/키워드: JUnit

검색결과 7건 처리시간 0.024초

JUnit과 JTestCase 프레임워크에 기반한 데스트 데이터 및 코드 생성 도구 (Test Data and Code Generation Tool based on JUnit and JTestCase Framework)

  • 이유정;최승훈
    • 한국정보과학회:학술대회논문집
    • /
    • 한국정보과학회 2002년도 가을 학술발표논문집 Vol.29 No.2 (2)
    • /
    • pp.106-108
    • /
    • 2002
  • 신뢰성있는 소프트웨어의 개발을 위해 테스트의 중요성은 매우 크다. 특히, 최근에 점진적이고 반복적인 소프트웨어 개발 방법론이 각광을 받으면서 소프트웨어의 잦은 변경에 따른 회귀 테스트의 중요성이 점점 커지고 있다. 이에 따라 단위 데스트의 자동화에 대한 연구가 활발히 진행되고 있다. JUnit은 자바 클래스의 단위 레벨 테스팅을 도와 주는 테스트 지원 프레임워크이다. 또한, JTestCase는 테스트 데이터와 테스트 코드를 분리함으로써, 데이터 중심 테스팅(data-driven testing)을 지원하기 위해 개발된 JUnit 확장 프레임워크이다. 본 논문에서는, 이 두 개의 테스트 프레임워크와 자바 리플렉션 API를 이용하여, 하나의 클래스 파일을 읽어 들여 XML 형태의 테스트 데이터 파일과 테스트 드라이버 코드를 자동생성하는 도구를 제안한다. 그리고, 구체적인 예를 통해 본 논문에서 제안하는 도구의 유용성을 보여준다. 본 논문의 데스트 도구는 회귀 단위 테스트에 필요한 노력을 줄여주고, 자바 클래스 단위 테스트를 지원하는 도구 개발의 기반 기술을 제공하며, 궁극적으로 소프트웨어 개발의 생산성을 향상시켜 준다.

  • PDF

JUnit 텍스트 UI 테스트 러너를 활용한 자바 프로그램 단위 테스트 고찰 (Unit Testing of Java Program using JUnit Text UI Test Runner)

  • 이채영;윤회진;박영철
    • 한국정보과학회:학술대회논문집
    • /
    • 한국정보과학회 2012년도 한국컴퓨터종합학술대회논문집 Vol.39 No.1(B)
    • /
    • pp.258-260
    • /
    • 2012
  • 본 논문은 오픈소스 자바 어플리케이션인 JTopas를 대상으로 단위 메소드 테스트를 수행하고, 기존의 IDE 중심의 JUnit 테스트 환경이 아닌 텍스트 UI 테스트 러너 기반으로 테스트를 수행함으로써 얻는 효과를 기술한다. 또한 리눅스 환경을 활용하여 쉘 프로그램으로 테스트 실행 프로그램을 작성하였으며, 이를 통하여 테스트 실행 결과 분석을 용이하게 할 수 있다. 동시에 테스트 코드와 테스트 대상 소스 코드를 관리하는 패키지 구성 방법을 보임으로써, TDD등에서 요구하는 테스트 코드 작성과 소스 코드 작성을 동시에 수행하는 환경을 지원하는 효과가 있다.

안드로이드 소프트웨어를 위한 테스트케이스 자동 생성 방안 (Methodology of Automatic Test-Case Generation for Android Software)

  • 신원;박정민;김태완;장천현
    • 한국정보과학회:학술대회논문집
    • /
    • 한국정보과학회 2011년도 한국컴퓨터종합학술대회논문집 Vol.38 No.1(A)
    • /
    • pp.198-201
    • /
    • 2011
  • 현재 안드로이드 시장에는 다양한 플랫폼을 기반으로 한 디바이스들이 혼재하고 있고, 안드로이드의 성장세로 봤을 때 앞으로 더욱더 많은 플랫폼 및 디바이스가 출시될 것이다. 따라서 여러 플랫폼 및 디바이스에 대한 상호 호환성을 만족시키기 위해 안드로이드 소프트웨어 개발 단계부터 테스트의 중요도가 높아지고 있고, 테스팅 시간을 줄이기 위한 테스트 자동화 문제가 대두되고 있다. 이러한 환경에서 상호 호환성을 만족시키기 위해서는 소프트웨어적인 요소뿐만 아니라 프로그램의 전반적인 요소까지 고려해야 하지만 기존의 테스트 자동화 도구인 JUnit은 안드로이드 소프트웨어의 특정 상태에 대한 정보만을 도출하기 때문에 전반적인 요소에 대한 통합관리가 불가능하다. 따라서 본 논문에서는 안드로이드 소프트웨어의 전반적인 요소들에 대한 정보를 도출하여 테스트 케이스를 자동으로 생성하는 방안을 제안한다. 사용자가 도출하고자 하는 정보를 선택함으로써 테스트 케이스 생성에 대한 유연성이 증가하고, 이를 자동화함으로써 테스팅 시간 감소를 통해 생산성 향상 및 높은 품질의 안드로이드 소프트웨어를 기대할 수 있다.

A Practical Intent Fuzzing Tool for Robustness of Inter-Component Communication in Android Apps

  • Choi, Kwanghoon;Ko, Myungpil;Chang, Byeong-Mo
    • KSII Transactions on Internet and Information Systems (TIIS)
    • /
    • 제12권9호
    • /
    • pp.4248-4270
    • /
    • 2018
  • This research aims at a new practical Intent fuzzing tool for detecting Intent vulnerabilities of Android apps causing the robustness problem. We proposed two new ideas. First, we designed an Intent specification language to describe the structure of Intent, which makes our Intent fuzz testing tool flexible. Second, we proposed an automatic tally method classifying unique failures. With the two ideas, we implemented an Intent fuzz testing tool called Hwacha, and evaluated it with 50 commercial Android apps. Our tool offers an arbitrary combination of automatic and manual Intent generators with executors such as ADB and JUnit due to the use of the Intent specification language. The automatic tally method excluded almost 80% of duplicate failures in our experiment, reducing efforts of testers very much in review of failures. The tool uncovered more than 400 unique failures including what is unknown so far. We also measured execution time for Intent fuzz testing, which has been rarely reported before. Our tool is practical because the whole procedure of fuzz testing is fully automatic and the tool is applicable to the large number of Android apps with no human intervention.

프레임워크기반 웹 어플리케이션을 위한 BizUnit 테스트 코드 생성 (A BizUnit Test Code Generation for Framework-based Web Application)

  • 이은영;최병주;송화정;황상철
    • 한국정보과학회논문지:컴퓨팅의 실제 및 레터
    • /
    • 제15권12호
    • /
    • pp.899-912
    • /
    • 2009
  • 웹 어플리케이션의 활용과 그 시장이 압도적으로 성장하면서 그 기능이 확대 심화되고 있다. 오늘날 나날이 높아지는 소프트웨어의 고품질 요구와 맞물려 웹 어플리케이션의 테스트에 대한 관심도 급증하고 있다. 웹 어플리케이션은 개발환경적인 면에서 프레임워크 기반으로 개발되고 있는 추세로 그 프레임워크의 영역이 확장될수록 전체 웹 어플리케이션의 각 모듈은 이질적인 파일들의 조합으로 구성되고 있다. 반제품의 형태로 제공되는 프레임워크가 전체 개발 대상의 구조를 제어한다는 점에서 웹 어플리케이션만의 특성을 갖게 된다. 본 논문에서는 웹 어플리케이션의 실행 단위로써 의미를 가지는 최소 단위로 웹비즈니스 로직을 정의하고, 이에 대한 BizUnit 테스트 코드를 자동생성하는 방안을 제안하며, BizUnit을 통해 효과적으로 웹 어플리케이션을 테스트하는 것을 분석한다.

원개발자 부재에 따른 원시코드 기반의 단위테스트 노력 분석 (Effort Analysis of Unit Testing Conducted by Non-Developer of Source Code)

  • 윤회진
    • 한국IT서비스학회지
    • /
    • 제11권4호
    • /
    • pp.251-262
    • /
    • 2012
  • Unit testing is one of the test levels, which tests an individual unit or a group of related units. Recently, in Agile Development or Safety-critical System Development, the unit testing plays an important role for the qualities. According to the definition of unit testing, it is supposed to be done by the developers of units. That is because test models for the unit testing refers to the structure of units, and others but its original developers hardly can understand the structures. However, in practice, unit testing is often asked to be done without the original developers. For example, it is when faults are revealed in customer sites and the development team does not exit any more. In this case, instead of original developers, other developers or test engineers take a product and test it. The unit testing done by a non-developer, who is not the original developer, would cause some difficulties or cause more cost. In this paper, we tests an open source, JTopas, as a non-developer, with building test models, implementing test codes, and executing test cases. To fit this experiment to practical testing situations, we designed it based on the practices of unit testing, which were surveyed through SPIN(Software Process Improvement Network). This paper analyzes which part of unit testing done by non-developers needs more effort compared to the unit testing done by original developers. And it concludes that Agile Development contributes on reducing the extra effort caused by non-developers, since it implements test codes first before developing source code. That means all the units have already included their own tests code when they are released.