Ubuntu 팀은 자동화된 테스트를 어떻게 수행합니까?

Ubuntu 팀은 자동화된 테스트를 어떻게 수행합니까?

Ubuntu 팀은 버그가 다시 나타나지 않을 것이라고 어떻게 확신합니까?

나는 그것을 여러 번 보았습니다. 설치 후 패키지를 사용할 수 없습니다.

예, 때로는 버그가 매우 빨리 수정되는 경우도 있습니다.

그러나 버그가 다시 나타나지 않도록 자동화된 테스트를 개선하려는 노력은 보이지 않습니다.

지난 2주 동안 나에게 영향을 미친 두 가지 사례는 다음과 같습니다.

더 많은 예가 있지만 나열하는 것은 문제의 일부가 아닙니다.

버그 페이지 의 댓글 중 하나 vsftp:

이 새로운 패키지를 테스트하여 우리를 도와주세요. 보다https://wiki.ubuntu.com/Testing/EnableProposed제안을 활성화하고 사용하는 방법을 문서화하려면 귀하의 피드백은 이 업데이트를 다른 Ubuntu 사용자에게 알리는 데 도움이 됩니다.

좋습니다. 하지만 위 인용문의 "테스트"는수동테스트.

품질을 보장하기 위해자동화된테스트가 필요합니다.

나에게 있어서 수동 테스트는 시간 낭비이다. 반면에 자동화된 테스트를 구축하면 품질이 보장됩니다.

여기에 다시 질문이 있습니다.

Ubuntu 팀은 버그가 다시 나타나지 않도록 어떻게 보장합니까?

이 질문의 역사

첫 번째 제목은 "Ubuntu 팀은 버그가 다시 나타나지 않도록 어떻게 보장합니까?"였습니다. 이제 "Ubuntu 팀은 자동화된 테스트를 어떻게 수행합니까?"입니다. 이는 수동 테스트가 해결책이 아니라고 믿기 때문에 수행되었습니다. 수동 테스트가 수행되는 방식만 설명하는 답변에 반대표를 던지지 마십시오.

답변1

우분투에는 자동화된 테스트가 있습니다. 예를 들어, 첫 번째 버그 사례가 다시 발생하는 것을 방지하기 위해 자동화된 테스트가 사용됩니다. 나는 당신이 언급한 첫 번째 vsftpd 버그를 수정한 사람이었고, 동시에 동일한 일이 다시 발생하지 않도록 자동화된 테스트도 추가했습니다. 버그 자체에 게시된 변경 로그 항목에서 이를 확인할 수 있습니다.

vsftpd (3.0.2-1ubuntu2.14.04.1) trusty; urgency=medium

  * d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging
    calls (LP: #1219857).
  * Add dep8 smoke test.
 -- Robie Basak <[email protected]> Tue, 29 Apr 2014 15:33:07 +0000

버그에서 이에 대해 여러 번 언급했는데 왜 이 버그를 자동화된 테스트가 부족한 사례로 간주하는지 모르겠습니다. 예를 들어 요약에서 "향후에 이를 감지하기 위해 dep8 테스트가 추가되었습니다" 및 "포함된 dep8 테스트가 자동으로 이 버그에 대한 수정 사항을 확인합니다"라고 말했습니다.

Ubuntu는 배포판이라는 점을 기억하십시오. 이는 우리가 업스트림이라고 부르는 많은 외부 프로젝트의 통합 집합입니다. Ubuntu는 더 넓은 자유 소프트웨어 생태계에서 다른 사람들의 작업 없이는 불가능할 것이며 마찬가지로 우리는 소프트웨어 전문가이기 때문에 업스트림 작성자에게 테스트를 제공하는 경우가 많습니다.

또한 우리는 다양한 프로젝트의 집합체이므로 단일 자동 테스트 인프라는 의미가 없습니다. 지역마다 요구 사항이 다릅니다. 따라서 우리의 테스트 전략은 이러한 요구 사항을 충족하기 위해 매우 광범위하며 다양한 인프라를 통한 수동 및 자동 테스트를 모두 포괄합니다.

업스트림 프로젝트가 자동화된 테스트를 제공하는 경우 패키지 빌드의 일부로 이를 실행합니다. 테스트를 통과하지 못하면 패키지 빌드가 실패합니다. 이러한 방식으로 사용 가능한 자동화 테스트를 활성화하는 것은 우리의 일부입니다.주요 포함 요구 사항:패키지가 테스트 스위트를 제공하고 빌드 중에 작동할 수 없는 명확한 이유가 없는 경우(예: 루트 권한 또는 네트워크 액세스 필요) 패키지 빌드 중에 실행되어야 하며 실패한 테스트 스위트는 빌드에 실패해야 합니다.

또한 우리는 다음과 같은 사양을 기반으로 "설치 시 자동 패키지 테스트"를 실행합니다.dep8는 패키지 간의 통합이 올바르게 작동하는지 테스트하기 위해 설계되었습니다. dep8 테스트를 회귀하는 패키지 업데이트는 수정될 때까지 개발 릴리스로 전달되지 않습니다.

나는 데스크톱 및 전화 팀이 수행하는 자동화된 테스트에 대해 잘 알지 못하지만 수년에 걸쳐 참조를 보았기 때문에 더 많은 메커니즘이 존재한다는 것을 알고 있으며 여기에는 매우 인상적이라고 생각하는 자동화된 GUI 테스트가 포함됩니다. 자동화된 데스크톱 및 전화 테스트를 다루는 또 다른 답변을 환영합니다.

답변2

다양한 방법.

  1. 많은 눈.

    Ubuntu는 오픈 소스이므로 누구나 코드를 보고 문제가 무엇인지 확인할 수 있습니다. 코드를 살펴보는 데 관심이 있는 사람들은 코드에서 또는 코드를 사용하면서 버그를 발견하는 경우가 많습니다.런치패드에 신고하세요그리고대중이 고칠 수도 있어요.

    테스트하고 수정 사항을 제안한 후 기본 Ubuntu 패키지와의 병합을 요청합니다. 다른 개발자들이 이 변경 사항을 검토하고 승인되면 추가할 것입니다.

    누구나 고칠 수 있기 때문에 빠르게 발견되고 검토되기 때문에 한동안 머뭇거릴 가능성이 적습니다. 이것은 다음 요점으로 이어진다.

    이 눈에는 컴퓨터 눈도 포함됩니다.

    업스트림 QA 프로세스는 문서화/시연되어야 하며 SRU 추적 버그에서 연결되어야 합니다. 그러한 업스트림 자동 테스트를 사용할 수 없는 다른 경우에는...

    이는 일반적으로 자동 테스트가 진행되고 있음을 보여줍니다.

  2. 베타 릴리스

    Ubuntu가 대중에게 출시되기 전에 베타 버전이 있습니다. 현재 15.10 베타 버전입니다.2015년 10월 22일 출시. 정말 많은 사람들이 이 제품이 출시되기 전에 이 제품을 사용하고, 검토하고, 버그를 수정했을 것입니다(예:5개월 22일이 경우).

    즉, Many Eyes로 인해 모든 버그가 즉시 제거되고 공식적으로 출시되기 전에 수정되므로 일반 사용자는 영향을 받지 않습니다.

  3. 전문 코드 작성자

    고품질 코드를 잘 작성하는 사람은 코드를 작성하는 사람입니다. 우분투를 이렇게 쓰는 사람은 단 한 명도 없습니다.

    전 세계 사람들이 있고 Ubuntu를 만든 회사인 Canonical에 고용된 사람들도 있습니다. 이 모든 사람들은 약간의 새로운 코드를 기여합니다. 2000줄의 코드를 작성하면 버그가 많이 생길 것입니다. 200명이 10개만 쓴다면 훨씬 적은 양이 될 것입니다.

  4. 안정적인 기초

    내가 아는 한, Ubuntu는 새 릴리스가 나올 때마다 처음부터 다시 작성되지 않습니다. 대신, 다음 버전은 현재 버전(즉, 2015/04/30에 15.10과 15.04가 모두 동일함)으로 시작하고 거기에서 새로운 기능이 추가됩니다.

    작업할 수 있는 좋은 기반이 있으면 작성할 코드가 적고 이미 존재하는 것을 신뢰할 수 있습니다. 거기에 있는 것에 의존할 수 있다면 버그가 줄어들 것입니다.

  5. 버전 관리 및 기록 소프트웨어

    동일한 버그가 두 번 이상 발생하는 경우(다른 버전에서, 수정 사항이 작동하지 않거나, 다른 패치로 인해 버그가 다시 발생한 경우) 수정 방법을 설명하는 문서가 있으며 다시 수정할 수 있습니다. .


내가 아는 한, 자동화된 테스트는 없습니다. 그런데 자동화된 테스트란 무엇일까요? 컴파일하면 그게 그거인가요? 그것이 무엇인지 설명하지 않고 단지 "자동화된 테스트"라고 말할 수는 없습니다.

답변3

버그가 있는 코드를 작성하지 마세요. ㅋㅋㅋ 알았어. 이에 대한 자세한 답변을 쓸 의욕을 잃었습니다. 괜찮은 기사는 다음과 같습니다. https://www.iiitd.edu.in/~jalote/papers/CommonBugs.pdf

그리고 여기 만들기에 관한 좋은 책이 있어요C++의 실수

가장 좋은 대답은 일부 소프트웨어 개발 작업을 수행하고 문제가 어디서 발생하는지 직접 확인하는 것입니다. 예상치 못한 입력/결과를 처리하는 것은 내 경험상 꽤 큰 문제입니다. 그런 다음 다운 스트림 버그가 있습니다. 누군가가 iostream.h에서 취약점을 발견하고 해당 라이브러리를 호출하는 모든 소프트웨어에 해당 버그가 있을 수 있는 것처럼 최소한 검토가 필요합니다.

자동화된 테스트의 경우 존재하지만 제한 사항도 있습니다. 모든 언어에서 작동하는 단일 솔루션을 알지 못합니다. 정말 관심이 있으시면 AI가 포함된 유전 코드 디버거를 작성해 주세요. 내가 아는 한, 모든 것이 아직 초기 단계에 있습니다. 박사 과정 학생들의 작업은 다음과 같습니다. https://www.cs.cmu.edu/~clegoues/docs/legoues-icse09.pdf

관련 정보