blog: 05-07-duncan

blog/2023/05-07-duncan/index.md

@@ -0,0 +1,83 @@
+---
+authors: duncan
+slug: software-testing-and-debugging
+---
+
+# 소프트웨어 테스팅이란?
+
+안녕하세요, SPARCS에서 개발자로 활동 중인 duncan입니다!
+
+이번 포스팅에서는 테스팅을 왜 해야 하는지, 테스팅에는 어떤 종류가 있는지 알아보겠습니다.
+
+## 왜 우리는 테스팅을 안 할까?
+
+저는 처음 개발을 배우면서 테스팅이 중요하다는 것은 배웠지만 이를 체감하지는 못했습니다.
+아마 저를 제외한 많은 학생 개발자분들도 처음에는 "테스팅 이거 왜 해야 하는 거야?" 이런 생각 한 번쯤 해보셨을 겁니다.
+우리가 제작하는 과제 프로그램, 토이 프로젝트들은 테스팅이 필요할 만큼 높은 퀄리티가 요구되지도 않고, 테스팅의 효과를 체감할 만큼 복잡도가 높지도 않습니다.
+특히, 과제로 제출한 프로그램의 경우 주어진 채점 프로그램에서 실행되고 나면 영원히 실행되지 않는 일회용 프로그램에 불과합니다.
+이런 프로그램만을 개발하는 환경에서는 테스트팅의 중요성을 느낄 수 없는 것이 당연해 보입니다.
+
+![과제물 밈](./badqt.jpeg)
+
+
+### 프로그램 퀄리티가 낮으면 어떻게 되나요?
+
+오늘날 사용하는 거의 모든 프로그램들은 버그를 가지고 있습니다.
+내가 만든 엉성한 토이 프로젝트부터, 빅테크 기업들이 제작한 크롬, 윈도우와 같은 프로그램 중 버그가 없는 프로그램은 존재하지 않습니다.
+버그를 100% 제거하는 것은 현대 프로그램의 복잡도 상에서는 불가능한 일입니다. 중요한 것은 버그의 유무가 아닌 버그의 빈도입니다.
+잦은 버그는 유저 경험의 퀄리티를 하락시키게 되고 결국 이런 서비스를 찾는 고객은 사라지게 될 것입니다.
+또한, 치명적인 보안 버그가 발생하는 경우 중요한 정보들을 탈취당할 수 있습니다.
+
+어플리케이션 레벨이 아닌 시스템 프로그램으로 내려가면 문제는 더욱 심각해집니다.
+항공기, 자동차, 로켓, 원자로 등에 사용되는 시스템 소프트웨어의 결함은 심각한 인명피해를 발생시킵니다.
+실제로 보잉 737기의 MCAS라는 프로그램의 버그로 인해 2번의 항공기 추락 사고가 발생하게 됩니다.
+
+![보잉 373](https://www.claimsjournal.com/app/uploads/2019/03/users_iqjWHBFdfxIU_iCBELMV0mnyQ_v0_piFq5T3pJF0qzS8rF9LjsWaQ_-1x-1.png)
+*출처: https://www.claimsjournal.com/news/international/2019/04/11/290347.htm*
+
+### 테스팅을 하면 개발 비용이 줄어든다고요?
+
+테스트 코드를 작성하는 작업이 오히려 개발 비용을 늘리는 것처럼 보일 수 있습니다.
+하지만, 테스팅을 통해 빠르게 버그의 존재를 파악하여 수정하게 되면 버그를 수정하는 데 드는 비용을 대폭 줄일 수 있습니다.
+일반적으로 버그를 늦은 시기에 잡아낼수록 버그를 수정하는 데 드는 비용이 기하급수적으로 늘어나게 됩니다.
+버그 픽스에 사용되는 비용을 대폭 줄여주기 때문에 장기적으로 보았을 때는 비용이 절감됩니다.
+
+## 테스팅의 종류
+
+#### Whitebox testing VS Blackbox testing
+먼저, whitebox testing과 blackbox testing에 대해서 알아보겠습니다.
+whitebox testing은 소스 코드의 내용을 기반으로 테스팅을 진행합니다.
+해당 소스 코드가 어떤 semantic을 가지고 있고, 그 semantic이 요구사항을 위반하진 않았는지 검증합니다.
+blackbox testing은 소스 코드는 고려하지 않고, 프로그램의 기능만을 테스트합니다.
+어떤 입력을 주었을 때 올바른 입력값이 나오는지 확인하는 방식으로 진행됩니다.
+
+일반적으로 whitebox testing가 bug detection 능력은 뛰어나지만, 높은 비용을 요구합니다.
+
+#### Functional testing vs Non-functional testing
+Functional testing은 프로그램의 기능이 올바르게 작동하는지 테스트합니다.
+Non-functional testing은 프로그램의 퍼포먼스와 같이 비기능적인 부분을 테스트합니다.
+
+## 버그의 탐지와 위치 추정
+테스팅을 자동화하기 위해서는 버그를 잡는 과정을 두 단계로 나누어야합니다.
+우선, 프로그램에 버그가 존재하는지를 알아내야하며 이를 위해 여러 가지 분석 기법이 사용됩니다.
+
+#### Dynamic analysis VS Static analysis
+Dynamic analysis(동적 분석)는 프로그램을 실제로 실행시켜 보고 버그가 있는지 확인합니다.
+분석의 진행 상황을 파악하기 위해서 "Coverage"라는 metric을 사용합니다.
+어떤 coverage를 사용하느냐에 따라 분석의 탐지 능력이 달라집니다.
+일반적으로 높은 coverage를 달성하기 어려울수록 탐지 능력도 강화됩니다.
+
+Static analysis(정적 분석)는 프로그램의 상태를 추상화합니다.
+어떻게 상태를 추상화하느냐에 따라 탐지할 수 있는 버그의 종류가 달라집니다.
+대표적으로 Type이 있습니다. 프로그램 각 변수들의 값을 실제 값(concrete value)가 아닌 타입(abstract value)로 관측하면서 변화를 추적합니다.
+이렇게 Type으로 정적분석을 하게 되면 프로그램에 있는 Type error를 탐지할 수 있게 됩니다.
+만약 변수들의 값을 zero or non-zero로 추상화하게 되면 div-by-zero bug를 탐지할 수 있습니다.
+
+#### Fault localization
+프로그램에 버그가 있는 것이 드러나면 해당 버그를 찾아내기 위해서 Fault locatlization을 수행합니다.
+프로그램상에서 버그가 있을 것으로 추정되는 부분을 점차 줄여나가며 버그의 위치를 찾아내는 방식을 사용합니다.
+버그 위치를 추정하는 방법으로 커버리지 기반 추정 기법, 스펙트럼 기반 기법, 뮤테이션 기반 기법 등 다양한 기법이 있습니다.
+# 마무리
+지금까지 테스팅에 관한 기초적인 내용들을 말씀드렸습니다.
+테스팅은 분야에 따라 개발 자체보다 더 중요한 요소가 될 수 있습니다.
+테스팅의 중요성이 조금이나마 전달되길 바라며 이 글을 마칩니다. 감사합니다!

blog/authors.yml

@@ -69,3 +69,9 @@ suwon:
   title: 곧 카이스트 졸업할 몸
   url: https://github.com/14kgun
   image_url: https://github.com/14kgun.png
+
+duncan:
+  name: 이동재 (duncan)
+  title: 척척박사가 될래요
+  url: https://github.com/duncan020313
+  image_url: https://github.com/duncan020313.png