소프트웨어 테스트 자동화 - 석사 논문 [닫기]
-
22-08-2019 - |
문제
저는 소프트웨어 테스트 자동화에 관한 논문을 쓰려고 합니다.테스트 스크립트 기록 및 프로그래밍의 두 가지 접근 방식을 비교하고 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의 재생/레코드를 푸시하는 것을 좋아했습니다. 그것은 훌륭한 데모와 높은 희망을 위해 만들어졌습니다. 그러나 부서지기 쉬운 테스트와 선반을 위해 만들어졌습니다. 재생/레코드는 도구로 시작하는 것이 좋지만 유지 관리하기 위해서는 일반적으로 더 높은 수준으로 작성된 스크립트가 필요합니다. 그것은 새로운 스프레드 시트와 키워드 기반 접근 방식의 새로운 시대를 안내했으며 결국 적합/피트니스.
문헌 기반 리뷰로서 이는 훌륭한 주제가 됩니다.거기에는 많은 자료가 있습니다.분명히 나는 그것에 대한 모든 세부 사항을 다루기 시작하지는 않을 것입니다. 왜냐하면 그것은 저자로서 여러분의 일이기 때문입니다.:-)
그러나 석사 논문의 원래 연구 요구 사항에 대해 잘 알지 못하더라도 박사 논문에는 이것만으로는 충분하지 않습니다.여기에 추가할 수 있는 원본 작품을 찾아보겠습니다.한 가지 아이디어는 테스트 방법과 시스템을 분류하는 것입니다.공식 검증과 비교하여 테스트의 역할을 검토할 수도 있습니다.
온라인으로 제공되는 경우 논문을 읽는 데 관심이 있습니다. 웹 및 응용 프로그램 모두 GUI에 대한 프로그래밍 방식 액세스를 고려할 가치가 있습니다. 그런 다음 Selenium 또는 Watir와 같은 레코드 및 재생 도구가 있습니다. 물론 자동화의 장단점 - 도구의 제한 (예를 들어 대부분의 자바 애플릿 또는 웹 페이지에서 플래시로 볼 수 없습니다)과 일부 사람들이 자동화 할 때 잊어 버리는 가장 중요한 것은 모든 것이 아닙니다. ~해야 한다 자동화하십시오!
그러나 만약 당신이 이것에 대해 언급 할 수 있다면, 그것이 끝났을 때 우리에게 알리기 위해, 나는 진정으로 읽는 것을 좋아할 것입니다.
올해 테스트 자동화에 관한 훌륭한 책이 방금 출판되었습니다 :“자동 테스트 구현”, Elfriede Dustin, Thom Garrett & Bernie Gauf, Addison Wesley.