버그 찾기

Rust regex와 regex_lite의 결과를 비교하는 퍼저로 구버전의 알려진 버그와 또 다른 버그를 발견함. 최신 버전에서는 버그를 찾지 못함 알고리듬 테스트에서는 정답을 판별할 오라클(oracle) 과 결과를 대조하는 것이 중요하며, 신뢰성 있는 시스템을 설계할 때 테스트용 오라클도 함께 마련해야 함 무작정 큰 입력보다 작고 까다로운 예제를 생성하는 데 집중함. 사용할 문자와 정규식 기능의 분포 자체를 무작위화해 소수 기능 사이의 상호작용을 탐색함 기존 퍼저가 놓친 버그를 발견했다면 먼저 퍼저의 결함으로 취급하고, 해당 버그와 유사한 버그를 찾도록 개선한 뒤 수정과 단위 테스트를 추가해야 함 이번 실험은 목표 버그와 퍼징으로 발견 가능하다는 사실을 이미 알고 시작했으므로 생성형 테스트의 우월성을 입증하는 근거는 약함. 주된 목적은 적용 기법을 보여주는 데 있음 출발점과 실험의 한계 lobste.rs 토론에서는 생성형 무작위 테스트가 예제 기반 단위 테스트보다 버그 발견에 훨씬 효과적인지를 논의함 단위 테스트를 옹호하는 근거 중 하나는 일반적인 퍼저가 Rust regex 크레이트의 까다로운 버그를 찾지 못했다는 경험이었음 이를 확인하기 위해 만든 작은 퍼저는 해당 버전에서 다른 버그를 먼저 발견한 뒤 목표 버그도 찾아냄 최신 버전에서는 아무 버그도 찾지 못함 목표 버그의 정체와 퍼저로 발견할 수 있다는 사실을 미리 알고 있었으므로, 테스트 방식의 효과를 입증하는 근거는 약함 별도의 두 번째 버그를 발견한 결과는 이 접근을 어느 정도 뒷받침함 알려진 버그를 찾도록 퍼저를 개선하는 작업도 중요함. 생성형 테스트가 비용 대비 강력하더라도 특정 테스트가 충분히 철저한지는 항상 확인해야 함 테스트가 모든 버그를 찾을 수는 없으므로 심층 방어와 런타임 완화책이 중요함 퍼저를 피해 간 버그가 나오면 먼저 퍼저를 개선해 해당 버그와 관련 버그를 탐지하게 만들고, 그다음 수정과 단위 테스트를 추가해야 함 목표 버그와 오라클 설계 구버전 regex는 정규식 .abb|b 로 입력 zabb 를 검색하면 첫 일치 결과로 b를 반환함 올바른 결과는 전체 문자열 zabb임 예제의 assert_eq!(m.as_str(), "zabb")는 regex-automata=0.4.15에서 실패함 정규식 엔진은 순수한 알고리듬이므로 생성형 테스트를 적용하기 쉬운 대상임. 대규모 시스템 전체가 하나의 알고리듬인 경우는 드물지만, 구성 요소 안에는...