Downcodes의 편집자는 간소화된 웹 기반 결함 관리 도구인 BugFree를 소개합니다. 이는 Microsoft의 소프트웨어 개발 철학을 바탕으로 이를 무료 오픈 소스 코드의 형태로 제공하며 Microsoft의 내부 버그 관리 도구인 Product Studio(이전의 Raid)를 성공적으로 "복제"한 몇 안 되는 무료 소프트웨어 중 하나입니다. 이 글에서는 BugFree의 소개, 코드 완성 과정, 소프트웨어 결함 처리 방법에 대해 자세히 알아보고 이 도구를 더 잘 이해하고 사용하는 데 도움이 되기를 바랍니다.
BugFree는 Microsoft의 소프트웨어 개발 철학을 활용하는 무료 오픈 소스 웹 기반의 간소화된 결함 관리 도구입니다. 이는 현재 Microsoft의 내부 버그 관리 도구인 Product Stuido(이전의 Raid)를 "복제"하는 몇 안 되는 무료 소프트웨어 중 하나입니다.
BugFree는 Microsoft의 소프트웨어 개발 철학을 활용하는 무료 오픈 소스 웹 기반의 간소화된 결함 관리 도구입니다. 이는 현재 Microsoft의 내부 버그 관리 도구인 Product Stuido(이전의 Raid)를 "복제"하는 몇 안 되는 무료 소프트웨어 중 하나입니다.
BugFree는 PHP+MySQL로 작성되었으며 Linux와 Windows 플랫폼 모두에서 실행될 수 있습니다. BugFree 2.0에 포함된 디자인 아이디어는 다음과 같습니다.
– 코드: 프로그램은 요구사항 설계 사양 문서(Spec)를 구현(매핑)합니다.
– 테스트 케이스: Spec의 구현(매핑)이기도 하지만 테스트 관점에서 본 것입니다.
– 테스트 결과: 테스트 케이스(테스트 매핑)를 사용하여 코드(개발 매핑)를 확인합니다.
– 버그: 두 매핑 간의 불일치는 버그일 수 있습니다(코드가 사양에서 벗어남).
이렇게 테스트 케이스(Test Case)부터 테스트 결과(Test Result), 결함(Bugs)까지 이 세 가지가 유기적으로 결합된다.
"Digital Nervous System"의 BugFree는 오픈 소스 PHP+MySQL로 작성되었으며 브라우저 기반으로 실행됩니다. 저는 이전에 Linux+Apache+MySQL+PHP를 사용한 개발 경험이 없었지만, 단 두 달 만에 이러한 시스템을 구축할 수 있었던 두 명의 우수한 웹 프로그래머를 채용할 수 있는 행운을 얻었습니다. 그 중 BugFree는 내 동료인 Wang Chunsheng이 개발했는데, 코드를 작성하는 데 한 달도 채 걸리지 않아서 놀랐고 Linux 기반 웹 개발의 매력을 깨닫게 되었습니다.
한 달 이상 테스트를 거쳐 실제 업무에 활용 가능하다. BugFree는 일상 업무에서 가장 중요한 도구가 되었습니다. 모든 직원은 버그를 사용하여 사물을 기록하고 추적하는 데 익숙합니다. 코드의 결함뿐만 아니라 새로운 요구 사항, 디자인 변경 등에서도 이 버그를 사용할 수 있습니다. 관리 시스템을 효과적으로 관리합니다. 실제로 버그는 소프트웨어의 결함을 기록하는 데 사용될 수 있을 뿐만 아니라 회사의 일상 업무를 추적하는 데에도 사용될 수 있습니다. 예를 들어 회사의 온라인 환급 시스템이 구축되기 전에는 BugFree를 사용하여 환급을 처리했습니다. 심지어 동료가 나에게 다음과 같은 버그를 주었습니다. 바탕 화면이 너무 지저분합니다. 정리해주세요 :-)
추가 자료:
일반적으로 사람들은 소프트웨어 결함을 발견할 때 이를 분류하는 방법은 한 가지뿐입니다. 심각도 수준을 분류하는 다른 방법은 없습니까? 예를 들어, 다음과 같은 상황이 발생하는데, 이때 테스터는 추가해야 할 기능이 있다고 말하는데, 프로그래머는 시간이 없거나 그럴 필요가 없다고 말합니다. 이 상황은 둘 사이에 갈등을 일으킬 것입니다. 와플하면 최종 결과를 알 수 없습니다. 그러면 테스터의 열정이 다음 번에는 가능한 한 제품 문제를 고려하지 않을 것입니다. 실행할 수 있습니다. 실제로 이 상황은 해결될 수 있습니다. 아래에서는 이 문제를 효과적으로 해결하기 위한 새로운 소프트웨어 결함 분류 개념을 언급하겠습니다.
소프트웨어 결함은 심각한 오류일 뿐만 아니라 구현되지 않은 기능도 포함합니다. 이 시점에서는 요구 사항이 고려되지 않았지만 요구 사항이 한 번 완벽할 수는 없으며 지속적으로 개선하려면 모든 사람의 공동 노력이 필요하다는 점을 모두가 이해할 것입니다. 그렇다면 테스터가 제안한 좋은 제안을 어떻게 효과적으로 구현할 수 있을까요? 이것이 제가 다음에 말하고 싶은 것입니다. 소프트웨어 결함을 분류하는 또 다른 방법이 있는데, 결함 내용에 따라 크게 요구사항 버그와 프로그램 버그로 구분된다. 이 분류의 장점은 버그 처리 담당자가 명확하다는 점이다. 프로그램 버그는 해당 개발자가 처리한다는 사실은 모두가 알고 있습니다. 다음은 주로 수요 버그에 대해 설명합니다. 이름에서 알 수 있듯이 수요 버그는 수요 담당자가 처리해야 합니다. 이를 처리하는 방법과 그 과정에서 효과적인 방법은 무엇입니까? 이때 우리 테스터들은 요구사항 버그를 프로그래머가 아닌 요구사항 분석가에게 제출하여 처리합니다. 그러나 여기서 강조하고 싶은 것은 요구사항 버그의 위치입니다. 이 버그가 소프트웨어 요구사항 사양에 명확하게 언급되어 있으면 이를 요구사항 버그로 찾는 것이 불가능하며 이를 소프트웨어 기능적 버그라고 합니다. 결함. 제출은 프로그래머가 처리합니다. 그러나 요구 사항 사양에 명확하게 언급되어 있지 않은 경우 요구 사항 버그로 찾을 수 있습니다.
이상은 bugfree에 관한 내용입니다. 모든 분들께 도움이 되었으면 좋겠습니다.
BugFree에 대한 이 소개가 모든 사람에게 도움이 되기를 바랍니다. Downcodes의 편집자는 계속해서 더 실용적인 기술 기사를 제공할 것입니다. 질문이나 제안사항이 있으시면 메시지를 남겨주세요!