Derleyiciler, birleştiriciler, makine talimatları vb. Gibi bilgisayar programcılığının düşük bileşenlerinin kusursuz olduğundan nasıl emin olabiliriz?

Günlük yaşamın çok kritik görevleri de dahil olmak üzere bilgisayar kullanımına giderek daha fazla güven duyduğumuzdan, bu hayati bileşenlerin nasıl test edildiğini merak ediyordum.

Daha teknik olarak, derleyiciler ve montajcılar nasıl test edilir? (Sanırım bu , durma problemiyle ilgili !!)

Emin olamazsınız, ancak öyle olmadığını farz edemezsiniz. Derleyicilerde ve donanımda yıllar boyunca birçok hata olmuştur.

Bunların, örneğin bir derleyicinin test edilme şekli, çok dar ve katı bir şekilde tanımlanmış olmaları, dikkatlice yazılmış olmaları ve daha sonra doğruluğunu doğrulamak için çok büyük bir test takımıyla test edilmeleridir . Bir derleyicinin geniş kullanıcı tabanı ve buna ek olarak daha fazla hata tespit edilip raporlanacaktır. Bir diş hekimi randevu planlama uygulaması, nispeten daha az sayıda kullanıcıya sahiptir ve hala kusurları tespit edebilen daha az sayıda kullanıcıya sahiptir.

SQLite yaklaşık 73k kod satırından, test takımı ise 91378k kod satırından, 1250x kat daha fazla SQLite kodundan oluşuyor. Derleyiciler ve diğer çekirdek araçların benzer oranlarda olmasını bekliyorum. Günümüzde işlemciler, Verilog veya VHDL gibi donanım tanımlama dilleri kullanılarak temel olarak yazılımla tasarlanır ve bu yazılımlar, üzerinde çalışılan yazılım testlerinin yanı sıra, üretim noktasında kendi kendini sınamak için özel IO pinleri içerir.

Sonuçta bu bir olasılık oyunudur ve tekrarlanan ve geniş kapsamlı testler, hata olasılığını diğer bir yazılım projesinde olduğu gibi kabul edilebilir derecede düşük bir seviyeye indirmenizi sağlar.

Layman'ın terimiyle:

1. Yapamazsın.
2. Derleyiciler ve tercümanlar, başka herhangi bir (profesyonel) yazılım olarak test edilir.
3. Başarılı bir test, bir programın hatasız olduğu anlamına gelmez, yalnızca hata tespit edilmediği anlamına gelir.
4. Derleyiciyi uzun süre kullanan geniş bir kullanıcı tabanı, çok az hataya sahip olduğunun güzel bir göstergesidir, çünkü kullanıcılar genellikle tasarımcıların düşünmediği durumları test eder.
5. Açık kaynak olmak da iyi bir göstergedir. "Yeterli göz küresi verildiğinde, tüm böcekler sığdır ... Yeterince büyük bir beta-test cihazı ve geliştirici tabanı göz önüne alındığında, hemen hemen her sorun hızlı bir şekilde tanımlanacak ve düzeltme birisi tarafından anlaşılacaktır." . Kapalı kaynak kodlu bir derleyicide çok belirli zamanlarda ortaya çıkan ya da en uygun makine kodundan daha az üreten hatalar olabilir ve arkasındaki şirket sadece varlıklarını açıklayamazlardı ve ürün yol haritasına çok düşük bir öncelik verdiler.

Alt çizgi:

Ben OOP için gitmek (söyleyebilirim Ç ld, Ey kalem ve P opular). Ben sadece bu kısaltmayı yaptım.

Tamamen aşağı kaplumbağalar.

Hiç bir şey kesin değildir. Güven derecelendirmesine karar vermekten başka seçeneğin yok.

Bunu bir yığın olarak düşünebilirsiniz: Matematik> Fizik> Donanım> Firmware> İşletim Sistemi> Assembler / Compiler / etc

Her seviyede, güven derecenizi geliştirmek için yapabileceğiniz testlere sahipsiniz. Bu testlerin bazıları resmi ispat kalitesine sahiptir, bazıları gözlemlere dayanmaktadır, çoğu ikisinin bir kombinasyonudur.

İşin zor yanı, bu testlerin bazılarında özyinelemeyi çözmektir, çünkü şimdi bunu elle yapmak çok zorlaşan kanıtlar ve gözlemsel analizler yapmak için programlar kullanıyoruz.

Sonuçta cevap, aklınıza gelebilecek her şeyi denemeniz. Statik analiz, raporlama, simülasyon, amaçlara göre seçilen aşırı girdiler veya rastgele girdiler ile çalıştırma, her kontrol yolunu çalıştırma / haritalama, resmi provalar, vb. yonga / program) amaçlandığı gibi çalışmıyor. Gerçek bir çaba gösterirseniz ve hala başarısız olursanız, ürününüzün doğruluğundaki güven derecenizi artırmanıza izin verilir.

Test, en iyi ihtimalle bir semidecision işlemidir, yani sonunda bulacağınız bir hata olduğu için hepsini bulacağınızdan asla emin olamazsınız. Resmi olarak doğrulanmış yazılımlarla bile, hala fiziğe, araçların resmi kanıtları yapmak için kullanılan araçlara güvendiğinizi ve kanıtladığınız şeyin programınızın (genellikle öznel olarak) "amaçlanan" şeyi yapması için gerekli ve yeterli olduğunu kanıtlayın. Resmi kanıtları olmayan, kullandığınız tüm bileşenlerden bahsetmiyoruz.

Bu, yeni geliştiriciler için kodlarını kullanmak yerine araçlarını suçlamaya başlayacakları için "tehlikeli" bir sorudur (orada bulundular, bunu yaptım, çok fazla gördüm). Derleyicilerde, çalışma zamanı ortamlarında, işletim sistemlerinde, vb. Hatalar olsa da, geliştiricilerin gerçekçi olması gerektiğini ve bunun aksi belirtildiğini gösteren kanıtlar ve birim testleri yapılıncaya kadar hatanın kodunuzda olduğunu unutmayın .

25 yaş ve üstü programlarda çoğunlukla C, C ++ ve Java ile buldum:

• derleyici hatası nedeniyle iki hata (gcc ve SunOS C)
• Java JVM sorunu nedeniyle her yıl yaklaşık bir veya iki hata (genellikle bellek tüketimi / çöp toplama ile ilgili)
• Bir kütüphanede yaklaşık olarak ayda bir ya da iki kez, en son sürüm kullanılarak veya kütüphanenin önceki sürümüne geri döndürülerek giderilen bir hata var.

Diğer hataların tümü doğrudan bir hatayla veya daha sık olarak bir kütüphanenin nasıl çalıştığını anlama konusundaki eksikliğiyle ilgilidir. Bazen bir hata gibi görünen şey uyumsuzluğa bağlı olabilir, örneğin Java sınıfı yapısının bazı AOP kitaplıklarını bozan nasıl değiştiği.

Burada ilginç bir nokta, ticari yazılımların (ve aslında açık kaynaklı yazılımların) lisanslarının büyük bir kısmının özellikle yazılıma güvenemeyeceğinizi belirtmesidir.

YAZILIM, TİCARİ AMAÇ VE ZIMNİ GİDERME GARANTİSİNE SINIRLANMAMIŞTIR, HERHANGİ BİR TÜR, AÇIK VEYA UYGULANMASI GARANTİSİ YOKTUR.

Microsoft Word Lisans sözleşmesinden

. Sınırlı Garanti dışında ve yürürlükteki yasaların izin verdiği azami ölçüde, Microsoft ve tedarikçileri (varsa) Yazılım ve destek hizmetlerini (varsa) TÜM HATALARLA OLDUĞU GİBİ İLE SÖZLÜTÜR; (varsa) herhangi bir (varsa) zımni garanti, görev veya koşul, belirli bir amaca uygunluk, güvenilirlik veya bulunabilirlik, cevapların, sonuçların, işçiliğin gayretinin kesinliği veya eksiksizliği gibi Yazılım ile ilgili olarak virüslerin ve ihmallerin eksikliği ve Yazılım aracılığıyla destek veya başka hizmetler, bilgiler, yazılımlar ve ilgili içerik sağlama veya Yazılımın kullanımından doğacak şekilde temin edilmemesi veya sağlanamaması .

Temel olarak, lisansta bu cümleyi, özellikle kullandığınız hemen hemen her yazılım parçasında, kullanılan derleyiciden bağımsız olarak yazılıma güvenemeyeceğinizi söylersiniz.

Yazılım, bilimsel bir teori gibidir, çalışmayana kadar belirtilen şekilde çalışmış sayılır.

Bir matematik dili için derleyici bir yazar olarak *, tecrübelerime dayanarak söyleyemeyeceğinizi söyleyebilirim. Ve hataların bazıları (utanç listemden) 6/3*2sağdan hesaplama 6/(3*2)ve çarpışmadan ya da saçma derleme hataları vermeden 1 çıktısı alma gibi yanlış sonuçlar veriyor.

Ancak IMHO'nun birçok derleyicisinin diğer yazılımlar kadar fazla hatası yok çünkü:

• Birim testleri yazmak kolaydır. Her ifade bir birimdir ve testleri aşağıdaki kadar basit yazabilirsiniz:test_unit("2+(-2)*(-2+1)*3+1",9);
• Bir program ifadelerin bir birleşimidir ve herhangi bir programın doğru sonucu vermesi için her bir ifadenin doğru sonucu vermesi gerekir (çoğunlukla). Bu nedenle, program doğru sonucu verirken herhangi bir hatanın olması olası değildir.
• Yazılı programların büyüklüğü ve sayısı arttıkça, böcek yakalama ihtimali de çarpıcı biçimde artmaktadır.

Montajcılar, makine talimatları vb. İçin yukarıdakiler de geçerlidir; Diğer taraftan, çip tasarımı ve üretiminde doğrulama ve doğrulama, çok büyük bir iş olduğu için çok daha katı süreçlere sahiptir: Elektronik tasarım otomasyonu .

Üretime geçmeden önce her bir CPU titizlikle test edilmelidir, çünkü her bir böcek yaklaşık olarak birkaç milyon dolara mal olur: çip üretiminde tekrarlayan devasa üretim maliyetleri vardır. Böylece şirketler üretime başlamadan önce tasarımları için çok fazla para harcarlar ve çok fazla simülasyon kodu yazarlar, ancak bu% 100 garanti vermez - örneğin: Pentium FDIV hatası.

Kısacası, derleyicilerde, makine kodlarında vs. ciddi hataların olması pek mümkün değildir.

Mütevazi matematik dilim *

Kusursuz? Onlar değil. Son zamanlarda bazı "güncellemeler" yükledim ve ASP.NET sitemin çeşitli temel işlerin nasıl yürüdüğü veya başarısız olduğu konusundaki açıklanamayan değişiklikler nedeniyle, aylar (ve yeniden programlanmış kod bölümleri) daha sonra ASP.NET sitem tekrar düzgün bir şekilde çalışıyordu.

Bununla birlikte, çoğu şeyi fark etme ve bildirme ve düzeltme eğilimi gösteren çok akıllı detay odaklı birçok kişi tarafından test edilir ve kullanılır. Yığın Değişimi, bu araçları kullanan tüm insanların, şaşırtıcı derecede karmaşık ve düşük seviyeli araçların en azından pratik kullanımda olduğu gibi nasıl çalıştığını test etmeye ve analiz etmeye yardımcı olan harika bir örnektir (ve iyileştirme).

Ama kusursuz, hayır. Stack Exchange'de insanları performans detayları ve standartlara uygunluk ve tuhaflıklar hakkında etkileyici bir kavrayış kazandığını görebilseniz de, özellikle farklı insanlar bir kusurun ne olduğu konusunda farklı görüşler varsa, her zaman kusur ve kusurlar vardır.

Altta yatan sistemlerin de kusursuz olduğunu göstermek için

a) Kusursuz olduklarını ispatlamak gerekir

1. Matematiksel kanıt
2. Önemsiz programlar için yalnızca gerçekçi olarak mümkün

b) Kapsamlı bir test yapın

1. Sadece önemsiz programlar ve bazı basit programlar için mümkün
2. Bir zamanlama elemanı teste girer girmez, süresiz olarak bölünebildiği için kapsamlı bir test yapmak mümkün değildir.
3. Önemsiz programların ötesinde, olası uygulama seçenekleri katlanarak patlar.

Yazılım testinde, kapsamlı test sadece bazı basit fonksiyonların birim testinde kullanılır.

Örnek: 8 karakter utf-8 girişini bir alana test etmek istiyorsanız, girişi 8 * 6 = 48 bayt veren bayt cinsinden utf-8'in maksimum uzunluğunun 6 katı kadar 8 kesmeyi seçebilirsiniz. sınırlı miktarda olasılık.

Şimdi sadece 8 karakterin her birinin 1.112.064 geçerli kod noktasını test etmeniz gerektiğini düşünebilirsiniz . 1.112.064 ^ 8 (10 ^ 48 diyelim) testleri (ki zaten mümkün değildir), ama aslında satranç ile aynı karmaşıklıkta olan 10 ^ 120 civarında olan 48 baytın veya 256 ^ 48'in her bir değerini test etmeniz gerekir. kabaca 10 ^ 80 evrendeki toplam atom sayısı ile karşılaştırıldığında.

Bunun yerine, artan çaba sırasına göre kullanabilirsiniz ve her test önceki tümleri kapsamalıdır:

a) iyi ve kötü bir örneği test edin.

b) kod kapsamı, yani. Her kod satırını test etmeye çalışın, bu kod çoğu kod için göreceli olarak kolaydır. Şimdi test edemediğiniz kodun% 1'inin ne olduğunu merak edebilirsiniz ... hatalar, ölü kod, donanım istisnaları vs.

c) yol kapsamı, tüm kombinasyonlardaki tüm dalların sonuçları test edilir. Artık fonksiyonlarınız 10'dan fazla koşul içerdiğinde test departmanının neden sizden nefret ettiğini biliyorsunuz. Ayrıca, son% 1'in neden test edilemediğini merak ediyorsunuz ... bazı şubeler önceki şubelere bağlı.

d) veri testi, sınır değeri, ortak problematik değerler ve sihirli sayılar, sıfır, -1, 1, min +/- 1, maks +/- 1, 42, rnd değerleri olan bir dizi numuneyi test edin. Bu size yol kapsamı vermezse, analizinizdeki tüm değerleri yakalayamadığınızı bilirsiniz.

Bunu zaten yaptıysanız, ISTQB kuruluş sınavına hazır olmalısınız.