문제

저는 소프트웨어 테스트 자동화에 관한 논문을 쓰려고 합니다.테스트 스크립트 기록 및 프로그래밍의 두 가지 접근 방식을 비교하고 Abbot, Selenium, Yemmy, FEST 등과 같은 여러 자동화 프레임워크에 대해 논의할 계획입니다.또한 내 논문에는 소프트웨어 테스팅 기술에 대한 간략한 개요와 자동화된 테스팅과 소프트웨어 테스팅의 비교가 포함될 것입니다.

편집하다:GUI를 통해 응용 프로그램을 테스트하는 측면을 계획하고 있습니다.따라서 내 테스트는 대부분 테스트 세계의 블랙박스 측에 있을 것입니다.나는 단위 테스트에 관해 글을 쓸 계획이 없었습니다.

현재 저는 다양한 자동화 프레임워크에 대해 꽤 많이 읽었지만 모두 검토할 시간이 없을 수도 있습니다.그래서 나는 그들에 대해 읽고 논문을 더욱 문학에 기반을 두는 것으로 만들 계획입니다.

  • 이 주제가 성공할 수 있다고 생각하시나요?
  • 이 주제와 관련된 다른 아이디어가 있습니까?
  • 문학을 추천해주실 수 있나요?
  • 이 주제에 대한 귀하의 의견은 무엇입니까?
도움이 되었습니까?

해결책

문헌 조사는 MS 논문에 대한 훌륭한 초점이어야합니다. 합리적으로 작은 틈새 시장 인 Black-Box Gui-Driving 고객 대면 도구에 대해 이야기하고 싶은 것 같습니다.

위에서 언급 한 누군가와 같이 단위 테스트, 보안,로드 등의 전 세계에서 전체 세계에 한 페이지 또는 2 페이지를 갖고 싶을 수도 있습니다. 그러나 나는 당신이 당신의 틈새 시장을 꽤 잘 목표로했다고 생각합니다.

6 학점 논문을 사용하면 더 큰 상업 및 오픈 소스 도구를 탐색하고 시험해 볼 시간이 충분해야한다고 생각합니다. 예를 들어 상업 도구 (빠른 테스트 프로, 테스트 완료)와 키워드 중심 자동화 -Selenium RC를 모두 조사하는 것이 좋습니다. 다른 사람이 "GUI 뒤에"예를 들어 FIT/FITNESSE 테스트를 언급했는데, 논의하고 평가할 가치가있을 수 있습니다.

2008 년 12 월 소프트웨어 테스트 및 성능 잡지에서 월간 열에서 블랙 박스, 기능 테스트 자동화를 다룹니다.

http://www.stpmag.com/issues/stp-2008-12.pdf (7)

그것이 한 페이지 스크래치-표면 소개입니다. 다섯 문장 소개는 화면 레코드/재생 도구가 모든 것을 비교한다는 것입니다. GUI가 전혀 변경되면 (화면 해상도를 변경하더라도) 허위 오류로 돌아올 수 있습니다. 키워드 중심 도구 만 확인하라고 명시 한 내용 만 확인하십시오. 버튼이 갑자기 비활성화 된 이유가 없거나 아이콘이 투명하지 않은 경우 누락됩니다.

만 인간만이 모든 시험 사례가 끝날 때 숨겨진 주장을 확인하는 데 능숙합니다.

따라서 컴퓨터 기반 테스트 실행 및 평가는 약간의 가치를 가질 수 있지만 균형 잡힌 아침 식사의 일부 여야합니다.

조사 할 다른 것들 :

  • James Bach의 "소프트웨어 테스트 자동화 뱀 오일"
  • Kaner, Bach 및 Pettichord의 저서 "소프트웨어 테스트에서 배운 교훈"
  • 테스트 프레임 워크에 대한 내 블로그 게시물 -http://xndev.blogspot.com/2007/09/whats-test-framework.html ( "테스트 프레임 워크 가란 무엇인가"에 대한 Number 4 Google 결과이므로 권장하는 것이 좋습니다).
  • 지뢰밭 비유 ( http://www.testingperspection.com/tpwiki/doku.php?id=minefield )
  • 테스트 자동화에 대한 Doug Hoffman의 논문 :http://www.softwarequalitymethods.com/h-papers.html
  • 테스트 자동화의 고전적인 "Shelfware"문제
  • Blackbox Test Automation 커뮤니티의 일부 지지자들이 강요 한 반 지적 주의자
  • Kaner의 블랙 박스 소프트웨어 테스트 과정
  • James Bach의 작업 /인지 / 테스트
  • 컨텍스트 중심 소프트웨어 테스트
  • Jon Kohl의 "Man and Machine"또는 Cyborg 접근 방식 (컴퓨터가 아닌 테스트 실행 및 평가 대신)

도움이되기를 바랍니다.

다른 팁

소프트웨어 테스트 자동화는 큰 주제이며, 프레임 워크, 재생/레코드, 기술 개요, 자동화 된 대 비공식을 다루지 않고 초점을 좁히기를 원할 수 있습니다.

소프트웨어 테스트 자동화에 관한 전체 책이 작성되었습니다.

  • 일반적인 주제로
  • 기능/기능 테스트에 중점을 둡니다 (적합)
  • 단위 테스트에 중점을 둡니다
  • 하나의 특정 언어 및 프레임 워크를 사용하여 단위 테스트에 중점을 둡니다.

프레임 워크는 다양한 유형의 테스트를 목표로합니다.

  • 단위 테스트
    • 시험 중심 개발
    • 행동 중심의 개발
  • 기능/기능 테스트
  • GUI 테스트 (Windows, Java Guis, X Windows 등)
  • 웹 테스트
  • 성능 시험
  • 보안 테스트

나는 프레임 워크 (또는 기술 또는 기법 또는 그 밖의 모든 것에 초점을 맞추는 것을 고려할 것입니다. 또는이 영역 몇 개를 골라 대조하십시오.

재생/레코드 vs. 필기 테스트의 문제는 나에게 오래된 것 같습니다. 1980 년대 공급 업체는 Windows GUI Automation의 재생/레코드를 푸시하는 것을 좋아했습니다. 그것은 훌륭한 데모와 높은 희망을 위해 만들어졌습니다. 그러나 부서지기 쉬운 테스트와 선반을 위해 만들어졌습니다. 재생/레코드는 도구로 시작하는 것이 좋지만 유지 관리하기 위해서는 일반적으로 더 높은 수준으로 작성된 스크립트가 필요합니다. 그것은 새로운 스프레드 시트와 키워드 기반 접근 방식의 새로운 시대를 안내했으며 결국 적합/피트니스.

나는 문학에 대해 잘 모르겠지만 학교 도서관의 ACM 간행물이 아마도 결과를 낳을 것이라고 생각합니다. 특히 시그* 뉴스 레터. (아마도 시그 소프트?)

그것은 나에게 좋은 주인의 논문처럼 들립니다. 물론 당신의 논문 고문은 그것에 대한 마지막 단어입니다. 당신은 그들과 이야기해야합니다.

문헌 기반 리뷰로서 이는 훌륭한 주제가 됩니다.거기에는 많은 자료가 있습니다.분명히 나는 ​​그것에 대한 모든 세부 사항을 다루기 시작하지는 않을 것입니다. 왜냐하면 그것은 저자로서 여러분의 일이기 때문입니다.:-)

그러나 석사 논문의 원래 연구 요구 사항에 대해 잘 알지 못하더라도 박사 논문에는 이것만으로는 충분하지 않습니다.여기에 추가할 수 있는 원본 작품을 찾아보겠습니다.한 가지 아이디어는 테스트 방법과 시스템을 분류하는 것입니다.공식 검증과 비교하여 테스트의 역할을 검토할 수도 있습니다.

온라인으로 제공되는 경우 논문을 읽는 데 관심이 있습니다. 웹 및 응용 프로그램 모두 GUI에 대한 프로그래밍 방식 액세스를 고려할 가치가 있습니다. 그런 다음 Selenium 또는 Watir와 같은 레코드 및 재생 도구가 있습니다. 물론 자동화의 장단점 - 도구의 제한 (예를 들어 대부분의 자바 애플릿 또는 웹 페이지에서 플래시로 볼 수 없습니다)과 일부 사람들이 자동화 할 때 잊어 버리는 가장 중요한 것은 모든 것이 아닙니다. ~해야 한다 자동화하십시오!

그러나 만약 당신이 이것에 대해 언급 할 수 있다면, 그것이 끝났을 때 우리에게 알리기 위해, 나는 진정으로 읽는 것을 좋아할 것입니다.

올해 테스트 자동화에 관한 훌륭한 책이 방금 출판되었습니다 :“자동 테스트 구현”, Elfriede Dustin, Thom Garrett & Bernie Gauf, Addison Wesley.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top