저는 현재 월별 미납 채무 보고서를 작성 중입니다. 방금 쓴이 보고서는 고객에게 얼마나 많은 돈을 지불 할 것인가에 대한 근거가 될 것입니다. 지금까지 나는 약 5 시간을 자동화 된 테스트를 작성하는 데 보냈으며 지금까지 제로 오류를 발견했습니다. 내가 이미 너무 많은 시간을 테스트하고 있다고 생각하니? 테스트를위한 이상적인 시간 프레임은 무엇이되어야합니까?코드 테스트에 가장 이상적인 시간은 무엇입니까
숫자에는 "정확한"양이 없다는 기능 명세를 작성 후 테스트 코드를 작성에 소요 될 필요가있다. 지금까지 최소/제로 오류가 발생했을뿐만 아니라 몇 가지 테스트 케이스를 작성 했으므로 올바른 방향이라고 말할 수 있습니다.
코드 또는 리펙토링 코드를 추가 할 때이 테스트 케이스는 "안전망"의 역할을합니다.
다른 프로젝트에 대한 테스트에 소비 된 시간의 통계 매핑 비율을 확인했습니다. 대체로 전체 개발 시간의 약 30 %에서 50 %까지 다양했으며, 소규모 프로젝트의 비율이 더 낮았습니다. 이것은 내 경험과도 일치합니다.
감사
감사합니다. 그러나 30 %/50 %는 무엇을 의미합니까? – drikoda
그는 코딩에 소요 된 시간의 30 %를 의미한다고 생각합니다. 따라서 10 시간의 코딩 작업을 마치면 3 시간의 테스트 시간을 소비해야합니다. 내가 동의해도. –
가능한 한 적은 시간 동안 쓰기 테스트를 수행해야합니다. 즉, 코드가 간단하고 직선적 인 단위 테스트를 사용하여 테스트 할 수 있어야하며 코드의 Cyclomatic complexity을 줄이려면 코드를 작성해야합니다.
가능한 한 적은 단위 테스트를 필요로하는 코드 작성에 집중하십시오. 사이클 콤플렉스 복잡성이 적은 간단한 클린 원뿔형입니다.
테스트 또는 코드를 작성하는 데 소요되는 시간의 표준 시간은 없습니다. 유일한 조치는 테스트 적용 범위입니다. 코드가 간단하면 단위 테스트 또한 간단하고 적은 수로 필요합니다. 단위 테스트 작성에 소비 된 시간이 소비됩니다.
코드 테스트를 시작하기 전에.
일반적으로 기능을 추가하자마자 테스트를 시작합니다.
자동화 된 테스트 이외의 코드로 테스트하지 않으려 고합니다. 내 기능을 구축 할 때 빌드 할 때 손으로 직접 시도하지 않고 테스트를 통해 테스트 해 봅니다. 그렇게하면 어쨌든 당신이 해낸 것보다 더 많은 일이 없으며, 나중에 시험을 치르게됩니다.
그런 다음 버그를 발견 할 때마다 테스트를 추가하거나 부주의 한 관리자가 추가 할 수 있다고 생각되는 버그를 가끔 처리합니다. 아이디어는 당신을 돕기 위해 테스트하는 것입니다.
테스트에 소요되는 고정 된 시간은 없습니다. "얼마 동안 기능을 작성하는 것이 적당합니까?"라고 묻는 것과 조금 비슷합니다. 정말 쓰여지는 항목이 얼마나 복잡한 지 표면적이 얼마나 넓은 지에 달려 있습니다. 사용자가 도구로 할 수있는 것이 많을수록 더 많이 테스트해야합니다.
최종 사용자 용 테스트는 두 가지 유형이어야합니다. 1) 자동 테스트. 회귀 테스트, 단위 테스트 등 2) 수동 테스트. 대부분 끝날 때까지 기다린 다음 사용자가 원하는대로 모든 부분을 치도록하십시오. 자동 테스트에서 모든 것을 다루지는 않으며 거기에 부작용을 알리지 않을 수도 있으므로 출하 전에 사람의 눈이 필요합니다.
테스트에 소요되는 시간을 결정하는 대신 테스트해야 할 사항을 결정하고 소요되는 시간을 소비하십시오.
그러나 자신의 테스트에 대해 확실한 시간 프레임이 있습니까? – drikoda
@drikoda : 일반적으로 함수를 만들 때마다 일반적으로 직접 테스트 케이스를 만들어 이러한 새 함수 나 메서드를 테스트합니다. 테스트 할 함수 나 메소드가 작을수록 다른 함수 나 메소드와 결합 될 때 복잡해지기 전에 이전 버그를 쉽게 발견 할 수 있습니다. 또한 함수 또는 메서드가 작을수록 Single Responsibility Principle이 적용되었는지 확인하고 강력하고 잘 테스트 할 수 있습니다. –