원인분석 - 자판기 버그 사례

Personal Computer/misc 2008. 2. 17. 12:52 posted by tolkien
자판기 버그 사례 - 시즈하님의 글

하고 있는 일도 그렇구, 그때문에 타국에 끌려나와서 우울한데
제대로 낚시에 걸렸다. 이왕 걸린거 변명이나 할란다.
사례1: 빈 종이컵이 나온다!
사례2: 종이컵이 없다?!
사례3: 동전 반환과 메뉴 선택을 동시에 했을 경우
사례4: 버튼을 연타했을 경우
사례5: 500원짜리 동전 반환시
사례6: 위폐를 넣었을 때 정상적인 지폐로 인식...

사례 1. 명백한 s/w 오류라고 하지만, h/w 오동작인 경우가 맞을 듯. s/w 오류라면 재현경로가 존재. button을 누르고 동전을 넣고 다시 button을 누르면.이라던지. 그런 문제가 아니라 정상적인 시나리오인 동전을 넣고, button을 눌렀는데, 빈 종이컵만 나오도록 programming할 바보는 없슴. 문제는 아주 가끔 h/w가 오동작한다는거.

사례 2. h/w 문제. 컵로더 문제거나 또는 컵을 잘못 로딩했을 경우, 컵이 내려왔는지 감지할 수 있는 센서가 있다면 처리할 수 없지만, 단가! 낮추기 위해서 그런 센서를 넣을리 없다면... 답 없음. 그냥 고객이 항의하는 경우 커피값을 지불하기.가 비용이 더 쌈.

사례 3. button driver를 한곳에서 일괄적으로 처리하면 생길 수 없는 문제. h/w가 분리되어 있더라도 같은 handler에서 처리하면 race condition을 피할 수 있슴. 하지만, button 각각에 handler를 별도로 처리하게 하면 개별 test는 통과, 사례 3과 같은 경우는 검증하기 전까지 알아채기 힘듬. 경험으로 피하는 code가 될 듯.

사례 4. billing 처리에 문제가 있는 경우, 이건 해당 programmer를 짤라야해. 차라리 돈을 먹도록 해야지, 받은 돈 이상 서비스하도록 하면 안됨.

사례 5. h/w 문제. 처리불가. s/w는 인식된 금액 - 판매금액 = 잔돈. release_500원()을 호출했는데, 600원이 나오면 어쩌라구... (중간에 잔돈 buffer를 만들고 거기서 금액을 확인하는 식으로 하면... -> 그 설비를 추가하느니 그냥 손해보고 만다)

사례 6. h/w 문제. but, 지폐인식하는 firmware를 update해서라도 수정하라는 고객의 요구가 있으면 대략 난감. (h/w를 한계까지 돌리고 싶어하는 사람들이 많다. 비싼 h/w == 단가 증가.이지만 (싼 h/w + s/w 개선) == 단가 절감.이라고 생각하는 사장님 많음. 그때문에 밝혀죽는 개구락지 좀 생각해주세요.)