자가 진단 팁?

Question

기본적으로 누군가가 제한된 시간 내에 다른 사람의 도움을받지 않고 코드를 잘 테스트 할 수 있도록하기위한 조언이 있다면 궁금합니다.

과거에는 항상 내 코드로 테스트를 수행 할 사람을 찾거나 전용 된 품질 보증 팀이 모든 것을 검토하고 모든 오류를 찾았습니다.

나는 보통 아주 조심 스럽지만 나는 항상 내가 놓친 것을 발견하고, 나는 그들을 시험 할 때 나는 단지 그들을 보지 못한다.

그러나 현재 나의 직업에서는 매우 제한된 시간 내에 글을 쓸 수있는 두 개의 PHP 웹 응용 프로그램을 제공 받았으며 이것이 좋지 않다고하는 의견에도 불구하고 모든 테스트를 직접 수행해야한다고 들었습니다. 생각.

다른 사람이 이전에이 문제가 있었는지 궁금 해서요. 일부 통찰력을 제공 할 수 있었습니까?

저는 각 영역을 코딩하기 전에 빠른 테스트 계획을 작성하고 테스트를하기 전에 요구 사항을 다시 확인하는 것이 좋을지도 모른다고 생각했습니다.

Answer 1

확실하게 단위 테스트는 테스트 우선이든 아니든간에 가장 먼저 방어선이되어야하며 각 응용 프로그램이 사용자가 생각하는대로 작동하도록 보장해야합니다. 그러나, 당신이 말하고있는 테스트의 유형은 또 다른 한 쌍의 눈을 얻는 데 도움이 될 수 있으며, 수용 테스트 분야에서 더 많이 사용됩니다. 애플리케이션을 전체적으로 작동시켜야합니까? 다양한 이상한 시나리오 나 행동 등을 위해 작동합니까?

유용한 방법 중 하나는 개인 설정을 상상해 보는 것입니다. 먼저 응용 프로그램을 직접 테스트하고 85 세에 상상해보십시오. 잘 사용하는 마우스는 사용하지 마십시오. 가장 밝은 것 또는 가장 큰 것을 클릭하는 경향이 있습니다. 귀하가해야 할 일이라고 가정 할 때, 그렇지 않을 수도 있습니다. 이제 12 살이고 서두름하는 모습을 상상해보십시오. 당신은 지침을 읽지 않을 것입니다. 아직도 작동합니까?

주어진 필드의 경우 사람이 입력 할 수있는 가장 큰 경우는 무엇입니까? 공백 만 입력하면 어떻게됩니까? 숫자 만 텍스트 필드에 넣으시겠습니까? HTML을 입력하면 어떻게됩니까? 자바 스크립트? 비 서구 알파벳의 어떤 것? 정말로 정말로 긴 것을 타이핑하면 어떨까요?

사용자가 염두에 두었던 것처럼 응용 프로그램을 사용하는 "행복한 경로"를 테스트하는 것이 핵심은 아닙니다. 아무도 할 수없는 방식으로 응용 프로그램을 살펴보십시오. 왜냐하면 ... 그럴거야.

다른 중요한 부분은 절대로 무시하지 마십시오. 기묘한 화면이 나타나서 "오, 그냥 우연 일뿐입니다."라고 쉽게 말할 수 있습니다. 당신은 스스로를 알아 차리고 그것이하는 것처럼 모든 것을 추적해야합니다.

Answer 2

나는 TDD가 당신이 찾고있는 것이라고 생각합니다. 먼저 테스트를 작성한 다음 테스트를 통과 한 코드를 작성하십시오. 당신은 따로 따로 당신을 필요로하지 않는다. (테스트에 대한 도움이 필요할 것이지만) 코딩을 시작하기 전에 툴이 무엇을해야하는지 더 명확하게 알 수있다.

http://en.wikipedia.org/wiki/Test-driven_development

Answer 3

고용주는 명확 테스트가 중요하다고 생각하지 않습니다. 그만하고 적절한 직업을 찾아야합니다.

Answer 4

나는 그것을 싫어하지만, 나는 당신의 경우 알렉스 짤글 링이 맞다고 생각합니다. 그것은 불가능한 상황입니다.

JacobM과 Santi는 단위 테스트, 수용 테스트 및 테스트 주도 개발에 대해 언급합니다. 코드 적용 범위와 정적 분석 도구를이 목록에 추가했습니다.

그러나 TDD 또는 기본 단위 테스트는 일반적으로 테스트 시간 단축, 불량률 감소 및 유지 관리의 용이성에서 보탬이되지만, 죽음에 따라 정시에 전달하는 데 도움이되지는 않습니다. 자동화 된 테스트를 작성하는 데 익숙하지 않은 경우 특히 그렇습니다.

당신의 상사가 기술적 인 부채를 요구합니다. 정확하게 말하면, 그는 직업 윤리를 무시하라고 당신에게 요구하고 있습니다.

스마일, "네 선생님"이라고 말하면 할당 된 시간 내에 최선을 다해 이력서를 업데이트하십시오.

Answer 5

나는 테스트 주도 개발 및 단위 테스트의 가치와 효과에 게시 된 이전 답변에 동의합니다. 올바르게 수행되면 제작/인도 가능 코드를 작성하기 전에 단위 테스트를 작성하는 TDD 프로세스가 초점을 유지하고 설계 및 인터페이스의 유효성을 확인하는 데 도움이됩니다. 또한 다른 개발자는 매우 직선적 인 방법으로 코드를 사용하고 소비하는 방법을 명확하고 일관되게 유지할 수 있습니다. 단위 테스트는 동일하지 않으며 완전한 통합 테스트를 대신 할 수는 없습니다. 이 접근법에서는 완전한 통합 테스트 계획을 작성해야 할 수도 있습니다.

저는 .NET에서 primarliy로 작업하며, NUnit을 사용하여 좋은 결과를 얻었습니다.

필자는 전에 PHP로 일한 적이 없지만, 내가 본 것으로부터 SimpleTest 또는 PHPUnit을 고려해 볼 수 있습니다.

Answer 6

할 수있는 테스트의 양에는 항상 제약이 있습니다. 제약 조건 내에서 분명히 테스트를 구성해야합니다. 분명히 가장 중요한 영역에 대한 테스트 (보안, 손상 가능성, 데이터 손실, 기능)를 구성하려고합니다.

기능 사양 이외에 테스트 할 사항을 결정하기 위해 많은 수동 도움말을 얻지는 않습니다. 그러나 테스트 커버리지 도구의 형태로 자동화 된 도움말을 얻을 수 있습니다. 이 도구는 테스트 한 코드와 테스트하지 않은 코드를 알려줍니다. 테스트되지 않은 코드를 검사함으로써 코드의 중요성을 판단 할 수 있습니다. 따라서 코드가 릴리스되기 전에 코딩 된 코드를 테스트 할 필요가 있습니다. 테스트 커버리지 도구는 테스트 된 코드 대 전체 코드의 비율을 알려주고이 비율이 70 % 이상인지를 확인하는 업계 최상의 방법을 알려줍니다. 이 데이터를 사용하여 상사와 더 많은 시간을 협상 할 수 있습니다. "우리는 15 %의 테스트 범위 밖에 없습니다 ... 우리가 감히 공개 할 수 있습니까?"

PHP와 함께 작동하는 테스트 커버리지 도구는 여기에서 찾을 수 있습니다 : 은 Semantic Designs PHP Test Coverage Tool는

는 는

Answer 7

는

은 당신이 그를 위해 일을하고 당신이 그의 마음을 바꿀 수있는 최대까지하면서 존중해야 상사의 요구 사항을 감안할 때, 당신은 준 질문에서 정답.

Answer 8

개발자가 코드에 대한 "최적의 경로"를 테스트하는 것은 자연스러운 경향이 있다는 것을 명심해야합니다. 다른 말로하면, 당신은 그것을 썼다. 그래서 당신은 특정 장소를 클릭하고 특정 물건을 입력해야한다는 것을 알기 때문에 그것을 시험한다. 이것은 물론 중요합니다.

여기에 몇 가지 좋은 제안이 있지만, 대부분 (전부는 아님)에 빠진 것으로 보이는 것은 부정 시험입니다. 기본적으로 경계를 테스트해야하며 악성 코드를 테스트해야합니다.

<script>alert('abc')</script> 

그것은 당신이 당신이 경고를받을 경우 제대로 인코딩하는 데 실패 꽤 명확하게 : 언급 한 바와 같이, 같은 필드에 스크립트 코드를 넣어! 또 다른 할 일은 다음과 같습니다.

abc' or 'a' = 'a' 

이렇게하면 인증과 관련하여 SQL 주입 문제가 발생할 수 있습니다.

abc'; drop table users; select * from dual where 'a' = ' 

테이블을 방금 떠났다면 문제가 발생했습니다. 엄청난 수의 예제가 있지만 적어도 OWASP 상위 10 개를 테스트하는 데 시간을 투자해야합니다.

테스트하려는 다른 곳은 매우 큰 숫자와 같은 것입니다. 특히 정수 입력을 예상 할 때 특히 그렇습니다. 32 비트 플랫폼, 음수 값, 값 없음 등 기본적으로 원하는 흐름이 작동하는지 테스트 한 다음 가능한 모든 작업을 수행하여 중단하십시오.