자신의 코드를 더 잘 테스트하는 방법

저는 비교적 새로운 소프트웨어 개발자이며 개선해야 할 것 중 하나는 내 코드를 테스트 할 수있는 능력입니다. 새로운 기능을 개발할 때마다 가능한 모든 경로를 따라 가기가 어려워서 버그를 찾을 수 있습니다. 나는 모든 것이 작동하는 길을 따르는 경향이 있습니다. 나는 이것이 프로그래머에게 잘 알려진 문제라는 것을 알고 있지만, 현재 고용주에 테스터가 없으며 동료들은 이것에 꽤 능숙한 것 같습니다.

우리 조직에서는 테스트 중심 개발이나 단위 테스트를 수행하지 않습니다. 그것은 나에게 많은 도움이 될 것이지만 이것이 바뀌지 않을 것입니다.

이것을 극복하기 위해 내가 무엇을 할 수 있다고 생각합니까? 자신의 코드를 테스트 할 때 어떤 접근법을 사용합니까?

코더의 임무는 물건을 만드는 것입니다.

테스터의 임무는 문제를 해결하는 것입니다.

가장 어려운 것은 방금 만든 것들을 깨는 것입니다. 이 심리적 장벽을 넘어 서면 성공할 수 있습니다.

Franciso, 나는 당신이 말한 것을 바탕으로 몇 가지 가정을 할 것입니다.

"우리는 TDD 나 단위 테스트를 수행하지 않습니다. 그것은 많은 도움이 될 것이지만 이것이 바뀔 것 같지는 않습니다."

이로 인해 귀하의 팀은 테스트에 많은 가치를 두지 않거나 경영진이 기존 코드를 정리하고 기술적 부채 를 최소화하기 위해 시간을 낭비하지 않을 것 입니다.

먼저, 팀 / 관리자에게 테스트의 가치를 확신시켜야합니다. 외교하십시오. 경영진이 팀을 계속 발전시키고 있다면 모든 릴리스의 결함률과 같은 몇 가지 사실을 보여 주어야합니다. 응용 프로그램 개선 및 향후 요구 사항에 대한 적응력 향상과 같은 다른 문제에 대해서는 결함을 수정하는 데 소요되는 시간이 더 좋을 수 있습니다.

일반적으로 팀과 경영진이 코드를 수정하는 것에 대해 냉담하고 코드가 마음에 들지 않으면 내가 말한대로 설득 할 수 없다면 다른 직장을 찾아야 할 수도 있습니다. 내가 일한 모든 곳 에서이 문제가 다른 정도로 발생했습니다. 적절한 도메인 모델이없는 것부터 팀의 의사 소통이 부족한 것까지 가능합니다.

코드와 개발 한 제품의 품질에 대한 관심은 좋은 속성이며 항상 다른 사람들에게 격려하고 싶은 특성입니다.

C, Objective-C 또는 C ++로 코딩 하는 경우 CLang 정적 분석기 를 사용 하여 소스를 실제로 실행하지 않고 비평 할 수 있습니다.

사용 가능한 메모리 디버깅 도구는 ValGrind, Mac OS X의 Guard Malloc, * NIX의 Electric Fence입니다.

일부 개발 환경은 디버깅 메모리 할당자를 사용할 수있는 옵션을 제공합니다.이 할당기에는 새로 할당 된 페이지 및 새로 해제 된 페이지를 가비지로 채우고 할당되지 않은 포인터의 해제를 감지하고 디버거를 사용하여 각 힙 블록 전후에 일부 데이터를 쓰는 등의 작업이 수행됩니다. 해당 데이터의 알려진 패턴이 변경되면 호출됩니다.

Slashdot의 일부 직원은 디버거에서 새로운 스테핑 소스를 사용하여 단일 스테핑에서 많은 가치를 얻었습니다. "그게 다야"그는 말했다. 나는 항상 그의 조언을 따르지는 않지만 제가 가지고있을 때 매우 도움이되었습니다. 드문 코드 경로를 자극하는 테스트 사례가없는 경우에도 디버거의 변수를 돌려서 이러한 경로를 가져 와서 메모리를 할당 한 다음 디버거를 사용하여 새 포인터를 NULL 대신 NULL로 설정하면됩니다. 메모리 주소를 할당 한 다음 할당 실패 처리기를 단계별로 실행합니다.

어설 션-C, C ++ 및 Objective-C의 assert () 매크로를 사용하십시오. 언어가 어설 션 기능을 제공하지 않으면 직접 작성하십시오.

어설 션을 자유롭게 사용하고 코드에 그대로 둡니다. assert () "테스트를 계속하는 테스트"를 호출합니다. 나는 대부분의 함수의 진입 점에서 전제 조건을 확인하기 위해 가장 일반적으로 사용합니다. 이것은 에펠 프로그래밍 언어에 내장 된 "계약에 의한 프로그래밍"의 한 부분입니다. 다른 부분은 사후 조건, 즉 함수 반환 지점에서 assert ()를 사용하지만 전제 조건만큼 많은 마일리지를 얻지 못한다는 것을 알았습니다.

assert를 사용하여 클래스 불변량을 확인할 수도 있습니다. 클래스가 변하지 않는 클래스를 반드시 요구하지는 않지만, 현명하게 디자인 된 클래스에는 클래스가 있습니다. 클래스 불변은 객체를 일시적으로 일관성이없는 상태로 만들 수있는 멤버 함수 내부가 아닌 항상 참인 조건입니다. 이러한 기능은 반환하기 전에 항상 일관성을 복원해야합니다.

따라서 모든 멤버 함수는 시작 및 종료시 불변을 확인할 수 있으며 클래스는 다른 코드가 언제든지 호출 할 수있는 CheckInvariant라는 함수를 정의 할 수 있습니다.

코드 커버리지 도구를 사용하여 실제로 테스트중인 소스 라인을 확인한 다음 테스트되지 않은 라인을 자극하는 테스트를 설계하십시오. 예를 들어 물리적 메모리가 거의없고 스왑 파일이 없거나 매우 작은 VM 내에서 앱을 실행하여 메모리 부족 처리기를 확인할 수 있습니다.

BOS 파일 시스템을 작성한 Dominic Giampaolo는 스왑없이 BeOS를 실행하지 말라고 강력히 권유했습니다. 이것이 왜 중요한지 확인하지만 일종의 구현 아티팩트 일 것입니다.)

또한 I / O 오류에 대한 코드 응답을 테스트해야합니다. 모든 파일을 네트워크 공유에 저장 한 다음 앱의 작업량이 많은 동안 네트워크 케이블을 분리하십시오. 네트워크를 통해 통신하는 경우 마찬가지로 케이블을 분리하거나 무선을 끄십시오.

특히 분노한 것은 강력한 자바 스크립트 코드가없는 웹 사이트입니다. Facebook의 페이지는 수십 개의 작은 Javascript 파일을로드하지만 그 중 하나가 다운로드되지 않으면 전체 페이지가 중단됩니다. 다운로드를 다시 시도하여 오류 허용을 제공하거나 일부 스크립트가 다운로드되지 않은 경우 합리적인 폴백을 제공 할 수있는 방법이 있어야합니다.

크고 중요한 파일을 작성하는 도중에 디버거 또는 * NIX의 "kill -9"로 앱을 종료하십시오. 앱의 아키텍처가 잘 설정되어 있으면 전체 파일이 쓰여지거나 전혀 쓰여지지 않거나 부분적으로 만 쓰여지면 쓰여진 내용이 손상되지 않고 저장된 데이터를 완전히 사용할 수 있습니다. 파일을 다시 읽을 때 응용 프로그램.

데이터베이스에는 항상 내결함성 디스크 I / O가 있지만 다른 종류의 앱은 거의 없습니다. 저널 파일 시스템은 정전 또는 충돌시 파일 시스템 손상을 방지하지만 최종 사용자 데이터의 손상 또는 손실을 방지하기 위해 아무 것도하지 않습니다. 이는 사용자 응용 프로그램의 책임이지만 데이터베이스 이외의 다른 방법으로는 내결함성을 구현하지 않습니다.

코드 테스트를 볼 때 일반적으로 일련의 사고 과정을 거칩니다.

1. 이 "사물"을 테스트 가능한 크기의 덩어리로 나누려면 어떻게해야합니까? 테스트하고 싶은 것을 어떻게 분리 할 수 ​​있습니까? 어떤 스텁 / 모의를 만들어야합니까?
2. 각 청크에 대해 :이 청크를 테스트하여 합리적인 입력 세트에 올바르게 응답하는지 확인하려면 어떻게해야합니까?
3. 각 청크에 대해 : 청크가 잘못된 입력 (NULL 포인터, 유효하지 않은 값)에 올바르게 응답하는지 어떻게 테스트합니까?
4. 경계를 어떻게 테스트합니까 (예 : 값이 부호있는 것에서 부호없는 것, 8 비트에서 16 비트로 바뀌는가 등)?
5. 테스트가 코드를 얼마나 잘 다루고 있습니까? 내가 놓친 조건이 있습니까? [이것은 코드 커버리지 도구를위한 훌륭한 장소입니다.] 누락 된 코드가 있고 실행할 수없는 코드가 있다면 실제로 있어야합니까? [다른 질문입니다!]

내가 찾은 가장 쉬운 방법은 코드와 함께 테스트를 개발하는 것입니다. 코드 조각을 작성하자마자 테스트를 작성하고 싶습니다. 사소한 순환 코드 복잡도로 수천 줄의 코드를 코딩 한 후 모든 테스트를 수행하는 것은 악몽입니다. 몇 줄의 코드를 추가 한 후 하나 또는 두 개의 테스트를 추가하면 정말 쉽습니다.

BTW는 귀하가 근무하는 회사 및 / 또는 동료가 단위 테스트 또는 TDD를 수행하지 않는다고해서 특별히 금지되지 않는 한 시도 할 수 없다는 것을 의미하지는 않습니다. 아마도 그것들을 사용하여 강력한 코드를 만드는 것이 다른 사람들에게 좋은 예가 될 것입니다.

다른 답변에 제공된 조언 외에도 정적 분석 도구 (Wikipedia에는 다양한 언어에 대한 여러 정적 분석 도구 목록 이 있음)를 사용하여 테스트를 시작하기 전에 잠재적 결함을 찾고 관련 메트릭스를 모니터링하는 것이 좋습니다 사이클로 매틱 복잡성 , Halstead 복잡성 측정 , 응집력 및 커플 링과 같은 코드의 테스트 가능성 (팬인 및 팬 아웃으로 측정 가능).

테스트하기 어려운 코드를 찾고 테스트하기 쉽도록하면 테스트 사례를보다 쉽게 ​​작성할 수 있습니다. 또한 결함을 조기에 발견하면 전체 품질 보증 관행 (테스트 포함)에 가치가 추가됩니다. 여기에서 단위 테스트 도구 및 조롱 도구에 익숙해지면 테스트를보다 쉽게 ​​구현할 수 있습니다.

코드에서 가능한 모든 경로를 정의하는 데 도움이 되는 Truth Tables 의 가능한 사용법을 살펴볼 수 있습니다. 복잡한 기능의 모든 가능성을 설명하는 것은 불가능하지만 알려진 모든 경로에 대해 처리가 설정되면 else 사례에 대한 처리를 설정할 수 있습니다.

이 특별한 능력의 대부분은 경험에 의해 배웁니다. 일정 기간 동안 특정 프레임 워크를 사용한 후에는 코드 조각을보고 작은 변경으로 인해 중대한 오류가 발생할 수있는 동작의 패턴과 특징을 볼 수 있습니다. 이것에 대한 당신의 적성을 높이는 유일한 방법은 연습입니다.

당신이 말했듯이 단위 테스트가 필요하지 않다면 직접 코드를 수동으로 끊는 것보다 더 좋은 방법은 없습니다.

코드를 한계 까지 밀어 넣으십시오 . 예를 들어, 경계 한계를 초과하는 함수에 변수를 전달하십시오. 사용자 입력을 필터링하는 기능이 있습니까? 다른 문자 조합을 입력하십시오.

사용자의 관점을 고려하십시오 . 응용 프로그램 또는 기능 라이브러리를 사용할 사용자 중 하나가 되십시오.

하지만 우리는 현재 고용주에 테스터가 없으며 동료들은 이것에 꽤 능숙 해 보입니다.

동료는 TDD 또는 단위 테스트를 따르지 않고 버그를 생성하지 않는 것이 매우 뛰어나야합니다. 따라서 어떤 수준에서는 버그를 생성하지 않으므로 단위 테스트 자체를 수행하지 않을 것입니다.

동료가 허용하는 것보다 더 많은 테스트를 수행하고 있다고 생각하지만 경영진은이 사실을 알지 못하기 때문에 경영진은 진정한 테스트가 수행되지 않고 버그 수가 적다는 인상을 받기 때문에 결과적으로 어려움을 겪습니다. 테스트는 중요하지 않으며 시간이 예약되지 않습니다.

동료들과 이야기하고 그들이 어떤 단위 테스트를하고 있는지 알아 내고 모방하십시오. 나중에 단위 테스트 및 TDD 속성을 개선하는 더 좋은 방법을 프로토 타입하고 이러한 개념을 팀에 천천히 도입하여보다 쉽게 ​​채택 할 수 있습니다.

• 코드를 작성하기 전에 테스트를 작성하십시오.
• 테스트에서 발견되지 않은 버그를 수정할 때마다 해당 버그를 잡기위한 테스트를 작성하십시오.

조직이 전체 범위를 갖지 않더라도 작성한 내용에 대한 범위를 확보 할 수 있어야합니다. 프로그래밍의 많은 것들과 마찬가지로, 그것을 반복해서하는 경험은 그것을 효율적으로하는 가장 좋은 방법 중 하나입니다.

다른 모든 의견 외에도, 동료가 비경로 시험을 잘 작성한다고 말하는 이유는 무엇입니까?

배우는 가장 좋은 방법은 그것이 어떻게 이루어 졌는지보고 배우는 것을 끌어내는 것입니다.

블랙 박스 테스트! 테스트를 염두에두고 클래스 / 메서드를 작성해야합니다. 테스트는 소프트웨어 사양을 기반으로해야하며 사용 사례를 통해 시퀀스 다이어그램에 명확하게 정의되어야합니다.

이제 테스트 중심 개발을 원하지 않을 수도 있습니다.

들어오는 모든 데이터에 입력 유효성 검사를합니다. 아무도 믿지 마십시오. .net 프레임 워크는 유효하지 않은 인수, 널 참조 및 유효하지 않은 상태를 기반으로 많은 예외를 발생시킵니다. UI 계층에서 입력 유효성 검사를 사용하려고 이미 생각하고 있어야 미들웨어에서 동일한 트릭입니다.

그러나 실제로 일종의 자동화 된 테스트를 수행해야합니다. 그 물건은 생명을 구합니다.

내 경험에

테스트 장치가 완전 자동이 아닌 경우 쓸모가 없습니다. 그것은 뾰족한 머리 보스가 살 수있는 것과 비슷합니다. 테스트 유닛이 테스트 프로세스를 자동화하는 시간과 비용을 절약 할 것을 약속했기 때문에 왜 그런가? 그러나 일부 테스트 단위 도구는 반대로 작동하므로 프로그래머는 이상한 방식으로 작업하고 다른 사용자는 초과 확장 테스트를 작성해야합니다. 대부분의 경우 작업 시간이 절약되지 않지만 QA에서 개발자로 이동하는 시간이 늘어납니다.

UML은 또 다른 시간 낭비입니다. 단일 화이트 보드 + 펜을 사용하면 저렴하고 빠르게 동일한 작업을 수행 할 수 있습니다.

BTW, 코딩에 능숙하고 버그를 피하는 방법은 무엇입니까?

• a) 원 자성. 하나의 간단한 작업 (또는 몇 개의 단일 작업)을 수행하는 하나의 기능. 이해하기 쉽기 때문에 추적하기 쉽고 해결하기 쉽습니다.

• b) 상 동성. 예를 들어 저장 프로 시저를 사용하여 데이터베이스를 호출하는 경우 나머지 코드에 대해 수행하십시오.

• c) "크리에이티브 코드"를 식별, 축소 및 격리합니다. 코드의 대부분은 거의 복사 및 붙여 넣기입니다. 크리에이티브 코드는 반대로, 새로운 코드이며 프로토 타입 역할을하며 실패 할 수 있습니다. 이 코드는 논리 버그가 발생하기 쉽기 때문에 코드를 줄이고, 분리하고 식별하는 것이 중요합니다.

• d) "Thin ice"코드는 "잘못된"(또는 잠재적으로 위험한) 코드이지만 예를 들어 다중 작업 프로세스에 대해 안전하지 않은 코드가 여전히 필요하다는 것을 알고있는 코드입니다. 가능하면 피하십시오.

• e) 블랙 박스 코드는 피하십시오. 여기에는 사용자가 수행하지 않은 코드 (예 : 프레임 워크)와 정규 표현식이 포함됩니다. 이런 종류의 코드로 버그를 놓치기 쉽습니다. 예를 들어, Jboss를 사용하여 프로젝트에서 일했고 Jboss에서 10 개가 아닌 10 개의 오류가 발견되었습니다 (최신 안정 버전 사용). 특별히 최대 절전 모드를 피하고 구현을 숨기므로 버그가 발생합니다.

• f) 코드에 주석을 추가하십시오.

• g) 버그 소스로서의 사용자 입력. 그것을 식별하십시오. 예를 들어, SQL 인젝션은 사용자 입력으로 인해 발생합니다.

• h) 팀의 나쁜 요소를 식별하고 할당 된 작업을 분리합니다. 일부 프로그래머는 코드를 망치는 경향이 있습니다.

• i) 불필요한 코드를 피하십시오. 예를 들어 클래스에 인터페이스 가 필요한 경우 인터페이스 를 사용하고 그렇지 않으면 관련없는 코드를 추가하지 마십시오.

a)와 b)가 핵심입니다. 예를 들어, 버튼 (저장)을 클릭하면 양식에 저장되지 않은 시스템에 문제가 있습니다. 그런 다음 체크리스트를 수행했습니다.

• 버튼이 작동합니까? ... 예.
• 데이터베이스는 무엇인가? 아니요, 오류가 중간 단계에있었습니다.
• 그러면 데이터베이스에 저장된 클래스가 작동합니까?. 아니오 <-확인, 오류를 찾았습니다. (데이터베이스 권한과 관련이 있습니다). 그런 다음이 절차뿐만 아니라 동일한 코드를 수행하는 모든 절차를 확인했습니다. 버그를 추적하는 데 5 분이 걸리고 문제를 해결하는 데 1 분이 걸렸습니다 (그리고 다른 많은 버그).

그리고 각주

대부분의 QA 는 Dev의 별도 섹션으로 빨아 들이며 프로젝트에서 작동하지 않으면 쓸모가 없습니다. 그들은 일반적인 테스트를 수행하고 그 밖의 많은 것을 수행하지 않습니다. 대부분의 논리 버그를 식별 할 수 없습니다. 내 경우에는 유명한 은행에서 일하고 있었고 프로그래머는 코드를 완성 한 다음 QA로 보냅니다. 품질 보증팀은 코드를 승인하고 프로덕션에 배치했습니다. 그런 다음 코드가 실패했습니다 (서사시 실패). 누가 비난을 받았습니까? 예, 프로그래머

테스터와 프로그래머는 서로 다른 각도에서 문제에 직면하지만 두 역할은 기능을 완전히 테스트하고 버그를 찾아야합니다. 역할이 다른 곳에 초점이 맞춰져 있습니다. 클래식 테스터는 외부 (예 : 블랙 박스)에서만 응용 프로그램을 봅니다. 그들은 앱의 기능 요구 사항에 대한 전문가입니다. 프로그래머는 기능 요구 사항과 코드 모두에 대해 전문가가 될 것으로 예상되지만 코드에 더 집중하는 경향이 있습니다.

(프로그래머가 요구 사항에 대해 전문가가 될 것으로 예상되는지 여부는 조직에 따라 다릅니다. 그럼에도 불구하고 내재적 기대는 무언가 잘못 설계 한 경우 요구 사항 사람이 아니라 비난을받습니다.)

이 이중 전문가 역할은 프로그래머의 마음에 부담이되며 가장 경험이 많은 사람을 제외하고 요구 사항의 숙련도를 떨어 뜨릴 수 있습니다. 응용 프로그램의 사용자를 고려하기 위해 기어를 정신적으로 전환해야한다는 것을 알았습니다. 다음은 나를 도와줍니다.

1. 디버깅 ; 코드에서 중단 점을 설정하고 애플리케이션을 실행하십시오. 중단 점에 도달하면 응용 프로그램과 상호 작용할 때 회선을 단계별로 실행하십시오.
2. 자동화 된 테스트 ; 코드를 테스트하는 코드를 작성하십시오. UI 아래의 계층에서만 도움이됩니다.
3. 테스터에 대해 알아보십시오 . 그들은 당신보다 응용 프로그램을 더 잘 알 수 있으므로 그들로부터 배우십시오. 응용 프로그램의 약점과 버그를 찾기 위해 어떤 전술을 사용하는지 물어보십시오.
4. 사용자를 알게하십시오 . 사용자의 신발을 걷는 법을 배웁니다. 기능 요구 사항은 사용자의 지문입니다. 기능적 요구 사항에서 명확하게 나오지 않을 수있는 응용 프로그램에 대해 사용자가 알고있는 것이 많습니다. 실제 환경에서의 작업 특성과 응용 프로그램이 사용자를 어떻게 지원해야하는지 사용자를 더 잘 이해하면 응용 프로그램의 상태를 더 잘 이해할 수 있습니다.

두 가지 측면에서 일하고 싶다고 생각합니다. 하나는 정치적이며 조직에서 일정 수준의 테스트를 채택하도록합니다 (시간이 지남에 따라 더 많은 채택을 기대 함). 직장 밖에서 QA 엔지니어와 상담하십시오. 품질 보증서 목록을 찾습니다 . 관련 위키 백과 기사를 둘러 보았습니다 . QA 원칙과 실무에 익숙해 지십시오. 이 내용을 배우면 조직에서 가장 설득력있는 사례를 만들 수 있습니다. 양질의 QA 부서가 존재하며 조직에 상당한 가치를 부여합니다.

개별 개발자로서 자신의 작업에 사용할 전략을 채택하십시오. 코드와 테스트를 공동 개발하여 TDD를 직접 사용하십시오 . 테스트를 명확하고 잘 유지하십시오. 왜 당신이 이것을하고 있는지 묻는다면, 회귀를 막고 있다고 생각할 수 있으며 그것은 생각 과정을 더 체계적으로 유지합니다 (둘 다 맞습니다). 이 테스트 가능한 코드를 작성하는 기술 을 배울 수는. 동료 개발자에게 좋은 모범이 되십시오.

부분적으로 나는 여기에서 나에게 설교하고있다. 왜냐하면 내가 알아야 할 것보다이 일을 덜하기 때문이다.