Ana Sayfa / Yazılar / Savunabileceğiniz Hesaplar HES-01
Testler Neden Yanlış Değeri Onaylar?
Bu sitenin hesap motorlarında bir denetim sırasında beş hesap hatası bulundu. Hepsinin testi vardı ve hepsi testlerden geçiyordu. Bu yazı, bir testin bir hatayı nasıl "onaylayabildiğini" ve bunun nasıl önleneceğini anlatıyor.
1. Bir itiraf
archi-civil.com'un sloganı "savunabileceğiniz hesaplar". Ekim 2026'da sitenin hesap motorları sistematik olarak denetlendi ve beş hesap hatası bulundu. Bu yazı o hataları saklamak yerine anlatıyor, çünkü her biri, mühendislik yazılımında doğruluğun nasıl sağlanmadığına dair genel bir ders taşıyor. Hepsi düzeltildi ve hepsi artık hatayı yakalayan testlerle korunuyor.
2. Beş hata, beş test
| Hata | Belirti | Testler neden yakalamadı? | Düzeltildi |
|---|---|---|---|
| Güneş azimutu | Öğlede 180°, doğrusu 0° | Test, öğlede 180° bekliyordu | v565 |
| Kinetik cephe | Güney cephe yaz öğlesinde "güneş arkada" | Test, güney cepheyi 180° ile temsil ediyordu | v566 |
| Kafes çubuk kuvvetleri | Her kuvvet çubuk boyuna bölünmüş | Testler yalnızca tepkileri denetliyordu | v569 |
| Cross yöntemi | İki eşit açıklıkta 45 yerine 15 kNm | Tek doğru çıkan durum, dağıtma gerektirmeyen simetrik durum | v570 |
| Cross örnek çözümü | "M_B = −qL²/8 = −18" (qL²/8 = 54; doğrusu 36) | Doğrulama tablosu doğru hesabı yanlış beklenenle karşılaştırıyordu | v570 |
Dikkat çekici olan şu: Beş hatanın hiçbiri test edilmemiş bir koddan çıkmadı. Hepsinin testi vardı ve hepsi geçiyordu.
3. Kâhin sorunu
Bir test iki şeyden oluşur: kodun ürettiği sonuç ve doğru sonucun ne olduğu bilgisi. Yazılım mühendisliğinde ikincisine "kâhin" (oracle) denir. Test, ancak kâhini kadar iyidir. Kâhin yanlışsa, test yanlış sonucu onaylar ve bunu güvenle, her seferinde yapar. Beş hatanın her biri, kâhinin bir biçimde bozulduğu bir durumdu.
4. Kalıp 1: beklenen değer koddan kopyalandı
Güneş azimutu testinde öğle vakti beklenen değer 180° olarak yazılmıştı. Oysa sayfanın kendi etiketi "güney = 0°" diyordu; öğlede güneş tam güneydedir ve doğru değer 0°'dir. Büyük olasılıkla test yazılırken kod çalıştırılmış, çıkan değer beklenen değer olarak teste kopyalanmıştı. Böyle bir test, kodun değişmediğini denetler; doğru olduğunu değil. Kinetik cephe testi de aynı kalıptaydı: Güney cepheyi kodun kuralına göre 180° ile temsil ediyordu.
5. Kalıp 2: yanlış şey denetlendi
Kafes motorunun testleri mesnet tepkilerini dikkatle denetliyordu, işaretleri bile. Ama kullanıcının asıl gördüğü çubuk kuvvetlerine hiç bakmıyordu. Hata da tam oradaydı: Rijitlik matrisi ile kuvvet hesabı farklı varsayımlarla yazılmıştı ve her çubuk kuvveti çubuk boyuna bölünmüş çıkıyordu. Tepkiler kendi içinde tutarlı olduğu için doğruydu.
6. Kalıp 3: kolay durum denetlendi
Cross yöntemi motoru, iki ucu ankastre simetrik bir kirişte doğru sonuç veriyordu. Bu durumda orta düğüm başlangıçta zaten dengededir; yani motor hiç dağıtma ve taşıma yapmaz. Hata tam da bu adımdaydı: Taşıma, aynı çubuğun karşı ucu yerine komşu açıklıklara yapılıyordu. Yalnızca kolay durum denetlendiği için hata görünmez kalmıştı.
Örnek sayfası ise başka bir biçimde bozuktu: "Analitik" çözüm hem aritmetik olarak (qL²/8 = 54, 18 değil) hem mekanik olarak (simetride orta mesnet dönmez, doğru değer qL²/12 = 36) yanlıştı. Sayfanın doğrulama tablosu doğru hesabı bu yanlış değerle karşılaştırıyor ve %200–300 sapma gösteriyordu.
7. Ne işe yaradı?
- Bağımsız referans çözüm: Cross yöntemi için testin içine ayrı bir açı-yer değiştirme çözücüsü konuldu; 50 rastgele kiriş iki yöntemle karşılaştırılıyor. Kafes için geometriden bağımsız bir denge denetimi eklendi: her düğümde ΣF = 0.
- Mutasyon testi: Her düzeltmeden sonra eski hata bilerek geri getirildi ve yeni testlerin onu yakaladığı doğrulandı. Hatayı yakalamayan bir test, test değildir.
- Fiziksel gerçekler: "Yaz öğlesinde güney cephe güneş alır, kuzey cephe almaz" gibi koddan bağımsız, herkesin bildiği gerçekler, en sağlam kâhinlerdir.
Bir sonraki yazı, aynı denetimin ikinci dersini anlatıyor: Bir hesabı okumak ile doğrulamak arasındaki fark.
Kaynaklar
- archi-civil.com sürüm notları (README), v565–v572: her hatanın belirtisi, nedeni, düzeltmesi ve eklenen testler.
- Barr, E. T., Harman, M., McMinn, P., Shahbaz, M. ve Yoo, S. (2015). The Oracle Problem in Software Testing: A Survey. IEEE Transactions on Software Engineering, 41(5), 507–525.
- Jia, Y. ve Harman, M. (2011). An Analysis and Survey of the Development of Mutation Testing. IEEE Transactions on Software Engineering, 37(5), 649–678.
Yazıdaki sayılar sitenin motorlarıyla üretilmiştir; yönetmelik değerleri kaynak madde numarasıyla verilmiştir.