Yazılım geliştiricilerinin büyük şirketleri programlarındaki hataları nasıl kontrol eder?

Yazılım geliştiricilerinin büyük şirketlerinin programlarındaki hataları nasıl kontrol ettiğini merak ediyordum.

Sadece birkaç bilgisayarda test ediyorlar mı?

İşte Google'ın kullandığı tekniklerden bazıları.

1. Güvenilir kod üretmesi muhtemel iyi geliştiriciler işe alın.
2. Birim testi ağır.
3. Kod incelemesini kullanın .
4. Entegrasyon sorunlarını yakalamak için sürekli bir yapı oluşturun .
5. Özel KG departmanları var. Hem test yapan hem de son kullanıcıları simüle eden otomatik programlar (örneğin Selenium kullanarak) anlamına gelir.
6. Hatalı davranışların kanıtlarını yakalamak için üretimde izleme yapın.

Bunları, böcek yakalamada etkinlik sırasının azalan olduğundan şüphelendiğimde sıraladım.

Daha büyük şirketler genellikle kodu test etmekten ve kodun olması gerektiği gibi çalıştığından emin olmaktan sorumlu tüm Soru-Cevap bölümlerine sahiptir. Bu genellikle sizin de tanımladığınız gibi - birçok makineyi test eden bir grup insan. Bazen testler otomatiktir, bazen de yapılmaz. Kalite Güvenceye bakın - Wikipedia

Çoğu zaman, geliştiricilerin kendileri geliştirme sürecinde hatalar bulacaklardır. Ayrıca, müşteriler genellikle bir hata bulan ilk kişilerdir.

Şu anda çalıştığım şirket gibi daha küçük şirketler Çevik Test uygulamasını kullanıyor

Onun büyüklüğü değil, bir şirketin olgunluk hakkında söyleyebilirim :) Kötü geliştirme uygulamaları olan büyük şirketler ve kanayan kenarında küçük şirketler vardır.

Genel olarak olgun bir geliştirme ekibi aşağıdaki faaliyetlere 1; sisteme yeni hatalar getirilmesini en aza indirmeli ve 2; mevcut sistemdeki hataları bul.

Birim testi: Bunlar, bir yöntemin söylediklerini yapmasını sağlamak için bireysel yöntemler için 'mini sürücülerdir'. Bunlar her zaman otomatik testlerdir.

Entegrasyon testi: Bu testler, sistem içinde daha büyük bir işlevsellik biriminin çalışıp çalışmadığını kontrol etmeyi amaçlamaktadır. Bu, veritabanı entegrasyonunun veya üçüncü taraf kütüphanelerle entegrasyonun test edilmesini içerebilir. Bunlar da otomatik testlerdir.

Kabul testi: Kullanıcı gereksinimlerini test etmek için kabul testleri yazılmıştır. Bunlar genellikle 'mutlu yolu' test ederler. Ekibimde bu testler, kullanıcı işlevselliği kullanılmak üzere tasarlandığı gibi kullanırsa sorun yaşamayacaklarını göstermek için tasarlanmıştır. Manuel veya otomatik olabilir.

Fonksiyonel test: Bu testler kabul testlerine benzer, ancak 'mutsuz yolu' da test ederler. Bu testler, çok açık olmayan senaryoları test etmek anlamına gelir. Manuel veya otomatik olabilir.

Regresyon testi: Bu terimi, müşterilere sunulmadan önce sistemin 'tam bir testini' yapmak için kullanırız. Manuel veya otomatik.

Goril testi: (Sadece manuel). Bu, çok akıllı insanlar kasıtlı olarak uygulamayı kırmaya çalıştıklarında yapılan bir testtir.

Performans testi Performansın kabul edilebilir olduğundan ve zamanla bozulmadığından emin olmayı amaçlar. Genellikle otomatiktir.

Kararlılık testi: Bu testler, sistemin zaman içinde sabit kalmasını sağlamak için tasarlanmıştır. Otomatik.

Sürekli Entegrasyon: Kodunuzu otomatik olarak kontrol eden, derleyen ve otomatik testlerinizi yapan bir sistemdir. Daha hızlı testleriniz (birim, entegrasyon) bir geliştirici kod her işlediğinde çalışır. Bazıları gece (kabul, işlevsel) veya haftalık (performans, kararlılık) çalışır.

Kod kapsamı raporları: Kodunuzun ne kadarının test edildiğini gösterir. Test kapsamı olmayan kodun kopma olasılığı daha yüksektir.

Kodu analiz eden farklı araçlar: Bunlar genellikle, kodun potansiyel hatalara daha az eğilimli olması için kodun yeniden faktörlendirilmesi gerektiğini gösterir.

Çift programlama: İşlevler sunmak için birlikte çalışan iki geliştirici. "Yapışkan bir çift, parçalarının toplamından daha iyidir."

Kaldırılması gereken en önemli şey: otomasyon ve sürekli entegrasyon .

Şirkete ve geliştirdiği ürünlere bağlıdır.

Birincisi, birçok şirket depoya giren hataların miktarını azaltmak için kod incelemeleri ve zorunlu bağlantı (otomatik hata algılama araçları) gibi kodlama uygulamalarını uygular. Birçok şirket de birim testini benimsedi. Çalıştığım durum bu (Google). Kod iade edildiğinde, yeni hataların verilmediğinden emin olmak için testler her şeye karşı yürütülür.

İkincisi, birçok şirketin davranışı doğrulamaktan sorumlu KG departmanları vardır. Bu özellikle Finans'ta yaygındır (hataların pahalı olabileceği ve doğrulama kurallarının karmaşık olduğu durumlarda), ancak hatırlamaların pahalı olabileceği kullanıcılara ürün satan şirketlerde de vardır (ör. Intel, Microsoft, vb.).

Üçüncüsü, mümkün olduğunda şirketler Dogfooding yapıyor (kendi kullanıcılarının ürünü dahili olarak kullanmasını sağlıyor) ve daha sonra sınırlı betalar yayınlıyorlar. Bu aşamada birçok hata var. Örneğin, Microsoft'ta çalışan kişiler Office ve Windows ve DevStudio'nun dışarıdakilerden daha yeni dahili sürümlerini kullanır. Daha sonra sınırlı kullanıcı grupları veya sözleşmeli şirketler bunu örnekleyebilir. Benzer şekilde, Google'da yayınlanmadan önce GMail ve Google Dokümanlar'ın dahili sürümlerini kullanıyoruz. Oyun şirketleri ürünlerini ve sunuculardaki yükü test etmek için açık betalar düzenlerler.

Tabii ki cevap "Bu dpends", ama şimdiye kadar en büyük projemden, yaklaşık 50 geliştiricinin zirve yaptığı bir örnek vereceğim.

Temel kurulum: BizTalk ile büyük miktarda veri işlemek için bir arka uç yazılımı.

İlk savunma hattı birim testlerdir. Bizim durumumuzda bunlar, kaynak kontrolüne kontrol edilen her şey için günlük olarak yürütüldü ve genellikle bazıları, check-in öncesinde geliştirici tarafından manuel olarak yürütüldü. Birim testleri esas olarak geliştiriciler tarafından yazılmıştır, ancak bazen test kullanıcıları tarafından yapılan ek testlerle değiştirilir.

Bir sonraki adım, testçilerin her bir bileşen için spesifikasyon belgelerine dayanarak veri akışı üzerinde bir dizi temel olarak uçtan uca test gerçekleştirdiği haftalık Sanal PC derlemesiydi.

Bundan sonra aynı Sanal PC, gerçek şeye oldukça yakın bazı iş verileri ile zenginleştirildi ve bazı özel kullanım durumlarıyla tekrar test edildi.

Daha sonra Sanal PC, diğer bölümlerden diğer sistem bileşenleriyle (aynı zamanda çoğunlukla sanal) bir araya getirilerek, verilerin veri akışının sonuna girdiği kullanıcıdan uçtan uca testlere dayanarak bir entegrasyon test döngüsüne getirildi.

Başka bir yolda, kurulum paketleri, üretim benzeri bir ortama doğru bir şekilde kurulduklarını ve bir şey başarısız olursa geri alınabileceklerini görmek için sistem sağlayıcısı tarafından test edildi.

Üretim benzeri ortama kurulumdan sonra, genel kararlılığı test etmek için yük ve stres testleri yaptık (10 BizTalk sunucusunda, 8 SQL Sunucusunda ve bir XML hızlandırıcı gibi diğer özel donanımlarda çalışırken hafifçe alınacak bir şey değil) ve özel bir Arşiv - hepsi elbette kümelenmiştir).

Tüm testlerden memnun kaldığımızda, kod üretime sokuldu. Koddaki hataları düzeltmek için oldukça büyük bir gecikme yaşarsınız (tüm test döngüsü için 4-6 hafta gibi) ve tüm bu testleri yapmak pahalıdır, ancak genel kararlılık oldukça iyiydi. Aslında şimdiye kadar gördüğüm en iyisi. Yine bu, her gün birkaç milyon dolar değerinde işleyen bir sistem için oldukça önemlidir. Gereksinimleriniz değişebilir, ancak biz bunu yaptık ve işe yaradı.

Orijinal soru, sağlanan son derece ayrıntılı cevapların çoğundan daha kavramsal olarak genel görünüyor.

Daha yüksek bir seviyeden bakalım (daha az ayrıntılı). Yazılım, bir kişinin (kişi, şirket, ne olursa olsun) özel gereksinimlerini karşılamak için geliştirilmiştir.

Bu ihtiyaçların, son zamanlarda (bir inşaat aşamasında) kaynak kodunda uygulanacak bireysel öyküler / gereksinimlerle eşleştirilmesi gerekir.

Hikayelerin / gereksinimlerin iyi tanımlanmış olması, Kalite Güvence (KG) ekibinin (gerçek yazılım testçileri), yürütüldüğünde, bu hikayelerin ve gereksinimlerin taleplerine nihai kodu doğrulaması için gereklidir. Bu maksat için KG ekibi bu doğrulamayı yapmak için "testcases" oluşturur.

KG ekibine bırakıldıktan sonra kod test edilecek ve hatalar tespit edilecektir. Farklı tip ve ciddiyette hatalar. Bu hatalar izlenir ve geliştiriciler onları nihayet sabitlemek için atanır.

Günümüzde sanal makinelerin kullanımı, bir test cihazının farklı ortamları aynı gerçek donanımda çalıştırmasına izin verir. Ancak bazen KG aşamasına adanmış bazı bilgisayarlara ihtiyacınız olur.

Umarım bu genel süreci (kabaca) anlamanıza yardımcı olur.

Alaycı olmaktan nefret ediyorum, ancak belirli bir 'cihaz' işletim sistemindeki açık hataların sayısı ile şirket büyüdükçe ve zenginleştikçe, son kullanıcıya daha fazla hata üretebilecek ve teslim edebilecek gibi görünüyor. Yazılım biraz işe yarıyor ve havalı görünüyorsa, yine de serbest bırakırlar. Yöneticiler hazır olduğunu düşünüyorsa, o zaman hazırdır. İşte o zaman gerçekten kötü böcekler ahşaptan çıkmaya başlar ve son kullanıcılar kobay olurlar. On yıl kadar sonra, hataların çoğu işlenmiş olacak (ve birkaç tanesi iyi önlem için eklenecek) ve şirket bir sonraki büyük fikre geçmeye hazır olacak.