gömülü geliştirme için birim testi yaparken en iyi yöntem

Gömülü sistem için yazılmış birim test kodu için bazı en iyi uygulama stratejileri arıyorum. Gömülü sistemle, aygıt sürücüleri, ISR işleyicileri vb. Gibi kodları, metale çok yakın olan şeyleri kastediyorum.

Ünite testlerinin çoğu, bir ICE yardımı ile donanım üzerinde test edilmeden mümkün değildir. Bazen gömülü ünitenin mekanik anahtarlar, step motorlar ve ampuller gibi diğer uyaranlara da bağlanması gerekir. Bu genellikle manuel olarak gerçekleşir, otomasyon harika olur ama elde etmesi zor ve pahalıdır.

Güncelleme

Gömülü projeleri test etmede oldukça başarılı görünen bir C test çerçevesiyle karşılaştım. Alaycı donanım fikirlerini kullanır. Check out Unity , CMock muhtemelen ve Ceedling .

Güncelleme 06Jul2016

Cmocka karşısında geldi - daha aktif olarak üzerinde çalıştı gibi görünüyor.

Mümkün olan en erken aşamada donanım bağımlılıklarından soyutlanacak ve sistemi her türlü test çerçevesini mümkün kılan yazılım emülasyonu / test kablo demeti üzerine inşa edecektim. Genellikle benim gelişim bilgisayarım, tüm sistemin% 95 veya daha fazlasını test etmek için kullanıldı. Fazladan ek maliyetin (başka bir soyutlama katmanı) maliyeti, bu soyutlamanın bir sonucu olarak oluşturulan temizleyici koduyla kolayca geri kazanıldı.

Gömülü bir sistemin gerçekten baremetal parçalarının denenmesi, genellikle, uygulamaların elde etmeyi umabileceklerinin ötesinde, ürün yazılımını zorlayan ayrı bir uygulamadır (Birim testi?). Otomasyon yapılabilir - bir ücret karşılığında, ancak tipik değildir.

Aksi takdirde, tam ICE de dahil olmak üzere bir birim test donanım koşum takımı oluşturma bütçesine sahipsiniz. Genelde fonksiyonel testler küçük olduğu için bu kesindir.

Geliştirilmesi gereken önemli bir araç bir sinyal enjektörüdür. Gömülü sistem, bir ana sistemle (tipik olarak hata ayıklama için ayrılmış bir seri bağlantı noktası aracılığıyla) bir araya gelme yöntemine sahip olacaktır. Test verilerini göndermek için bunu kullanın (en iyi seçenek terse ascii formatlıdır, bu yüzden insanlar tarafından da kolayca simüle edilebilir).

Sorunuzun bu kısmına tamamen katılmıyorum: "otomasyon harika olurdu ama elde etmesi zor ve pahalı olurdu."

TeraTerm'i seri port sinyal enjektörü olarak kullanmak ve bazı TeraTerm makroları yazmak (yaklaşık 20 dakika sürer), gömülü bir sistemin herhangi bir bölümüne karşı çalıştırılabilen dev bir otomatik test paketi vardır - sürücü katmanı, O / S, katman 4-5, vs. TeraTerm: http://en.sourceforge.jp/projects/ttssh2/

Yerleşik sistemde seri bağlantı noktası yoksa, USB / seri bağlantı noktası verilerini dijital sinyallere dönüştürmek için bir donanım aracı kullanın (aynı zamanda ucuz ve kolay elde edilebilir). Bunu okuduğunuz gibi, USB / seri üzerinden gönderilen TeraTerm makroları aracılığıyla uyaran enjekte ederek üretim için gömülü bir sistemi test etmek için 30 dolarlık bir mikrodenetleyici kartı (UBW: http://www.schmalzhaus.com/UBW32/ ) kullanıyorum Dijital girişleri yapan ve hedef gömülü sistemin dijital çıkışlarını izleyen modifiye edilmiş firmware çalıştıran mikrodenetleyici. Bununla birlikte, veri enjeksiyonunu ve veri doğrulamasını otomatikleştirmek için bir python betiği (pyserial ve pexpect kullanır) geliştirdik. Hiçbiri zor değil ve hiçbiri pahalı değil. Tecrübelerime göre, yöneticiler test ekibi tecrübesiz olduğunda ve bu kolay çözümlerden yararlanamadıklarında büyük paraları (30.000 $ test ekipmanı gibi) harcıyorlar - ne yazık ki, genel amaçlı büyük demir ekipmanı genellikle test durumlarını içermiyor hedef sistemin en kötü zamanlamasını / vb. yakalamak. Bu nedenle, ucuz yöntem test kapsamı için tercih edilir. İnan ya da inanma.

Bu çok zor bir problem.

Aslında, donanım olaylarını / kesintileri simüle edebilecek ve uygulamanın zamanlamasını kontrol edebilecek (eşzamanlılık nedeniyle olası tüm birleştirmeleri kapsayacağımızdan emin olmak için) gömülü bir sistem için bir birim test donanımı tasarladım ve bir ekip çalışması aldı. programcılar aslında onu uygulamak ve işe koymak için 2 yıldan fazla. Bu proje tescilli bir gelişmedir, ancak benzer (tasarımda daha basit) bir proje burada mevcuttur .

Yani evet, otomasyon harika olurdu. Evet, elde etmesi çok zor ve pahalı. Evet, bazen bunu yapmak zorundasın. Nadiren, deneyimlerime göre çoğu durumda step motorları ve ampulleri kullanmak daha hızlı ve daha ucuzdur ve hepsini manuel olarak çalıştırır.

Düzenleme: Cevabım mattnz yakın, sanırım ...

Bu sorunu başkalarıyla, kodunuz dışında harici bir şeye bağlı olan tüm testlerle (sistem saati, kalıcı bir dosya sistemi veya bir veritabanı gibi, harici bir web servisine başvurarak ...) ilişkilendirmek istiyorum. Hepsine aynı politikayı öneriyorum, iki seviyeyi iki ayrı kod katmanında izole ediyorum .

Tek bir harici işlemin test edilmesi

Her bir işlemi fiziksel olarak test etmek isteyebilirsiniz. Sistem saatinin doğru zamanı verdiğini kontrol edin, bir dosyanın gerçekten ne yazdığını hatırladığını kontrol edin, bir cihazın tek bir işlem aldığını kontrol edin ...

Bu testler:

• mümkün olduğunca basit olmalıdır: ne olursa olsun algoritma yok, koşul yok veya döngü yok
• siparişe bağlı ve makineye bağlı olabilir: bu nedenle sıkı bir sipariş izlemeniz ve her donanımda tekrarlamanız gerekir.
• Projeniz boyunca çoğunlukla kararlıdır, bu yüzden bu kadar sık ​​çalıştırmanıza gerek yok.
• bu yüzden onları manuel olarak çalıştırmak bir seçenektir; aşırı karmaşık olmasa da otomasyon daha iyi
• O Not neyi test ediliyor kodunuzu değil , test sizin için opsiyonel olabilir Yani kod ihtiyaçlarını ..., farklı bir ekip tarafından yapılmış olabileceğini bir araçtır ...

Harici işlemleri bir araya getiren mantığın (kod, algoritma) test edilmesi

Gerçek dış işlemleri yapmak için bir kod katmanına sahip olarak, kolayca takılabileceğiniz bir arabirimde saklayarak, mantığınız artık gerçek fiziksel aygıtlara bağlı değildir ...

Herhangi bir normal proje olarak, artık test edilmesi zor bir kodda değilsinizdir .

Gömülü CPU simülatörleri genellikle donanımı simüle etmek için programlanabilir. Xen dışındaki tüm sanallaştırma teknolojileri bunu yapıyor. Ancak bazı fiziksel adreslerde ya da x86'da, G / Ç veriyolunda bir adrese sahipmiş gibi yazan kod yazmanız gerekir ve ardından yazılımınız fizikselmiş gibi okuyor ve bu adreslere yazıyor olmalı. Kontrol ve durum kayıtlarına erişilen çip.

Bunu yapmak istiyorsanız, QEMU’yu değiştirmenizi öneririm. Ancak bu kolay olmazdı. Bu tür şeyler genellikle yalnızca bir mikrodenetleyiciye ve G / Ç için bazı diğer çekirdeklere sahip özel bir yonga tasarlarken yapılır.

ARM Holdings tarafından satılan geliştirme sistemi bunu sağlıyor ve QEMU’yu hacklemekten çok çalışmak daha kolay, ancak çok pahalı.

Donanım erişimine bağlı olmayan alt yordamların performansını ayarlamak için hata ayıklamak için kullanabileceğiniz, başka alt yordamları çağırabilen tek bir alt yordam çalıştıran birkaç Açık Kaynak ARM emülatörü vardır. Bunlardan birini ARM7TDMI için bir AES şifreleyicisini optimize etmek için büyük bir başarı için kullandım.

C veya C ++ dilinde basit bir birim test kablo demeti yazabilir, test edilen sınıfı veya alt rutini ona bağlayabilir ve daha sonra simülatörde çalıştırabilirsiniz.

Yıllardır benzer bir problemi, Linux ya da Mac OS X çekirdek kodunu nasıl test edeceğimi düşünüyorum. Bu mümkün olmalı, ama aslında hiç denemedim. Muhtemelen bir tanesi kodunuzu izole olarak test etmek yerine tam bir çekirdek oluşturmaktır, birim test çerçevesi doğrudan çekirdeğinize bağlıdır. Daha sonra, bir tür harici arabirimden birim testlerini ateşlerdiniz.

Belki bir kod kapsamı aracı kullanmak daha verimli olabilir, ardından harici yazılım üzerinden ürün yazılımınızı eksiksiz bir paket olarak test edin. Kapsam aracı henüz test edilmemiş kod yollarını bulacaktır, böylece daha fazla kapsam almak amacıyla ek harici testler ekleyebilirsiniz.

Gömülü olmayan TDD'de olduğu gibi, sahte nesneler kesinlikle arkadaşınızdır.

Arayüzün temel donanımınıza temiz ve basit olmasını sağlayın, böylece en düşük seviyenin üzerindeki her şey alay edilebilir ve çok daha kolay bir zaman geçirirsiniz. .

Ayrıca, projede epey geçinceye kadar on-line test yapamayacağınız için on-line testler de yapmamanız gerektiği anlamına gelmiyor.

Bunların (başlangıçta) yalnızca çevrimdışı test edilemeyen bitleri test etmesi gerekir. Elbette, TDD değil (testleri önceden oluşturduğunuzdan beri) ancak çevrimdışı TDD geliştirmeniz, donanım arayüzünüzün neye benzemesi gerektiği ve dolayısıyla hangi çevrimiçi testleri yapmanız gerektiği konusunda size iyi bir fikir vermelidir.

Ayrıca, çevrimiçi geliştirme çevrimdışı geliştirmeden çok daha pahalıysa (çalıştığım yerde olduğu gibi), çevrimiçi olarak gerçekleştirilmesi için çok iyi anlaşılmış bir testler kümesi elde etmenizi sağlar.

Gömülü geliştirmede , tüm uygulamanın (donanım dahil) çalıştığını doğrulamak için sık sık sınır taramaları yaparsınız . Ayrıca sistem hata ayıklaması için JTAG'a bakınız .

Saf yazılım rutinlerini donanıma bağlamadan test etmek, Check gibi standart bir C Unit Test çerçevesi ile yapılabilir . Ancak bellek sınırlamalarına dikkat edin (özellikle küçük cihazlarda yığın alanı vb.). Sözleşmelerinizi bilin! Ayrıca, daha büyük bir test kapsamı elde etmek için yazılım rutinlerini donanımdan soyutlamayı deneyebilirsiniz, ancak bu genellikle küçük PIC'ler veya AVR'ler gibi gömülü aygıtlardaki performans açısından pahalıdır. Ancak, daha büyük bir kapsama alanı elde etmek için donanım bağlantı noktalarıyla alay edebilirsiniz (ve tabii ki o sahneyi de test edebilirsiniz).

Ayrıca çip veya devre emiciler için emülatörleri kullanmayı deneyebilirsiniz, ancak bu tür aletler pahalıdır (özellikle kombinasyon halinde) ve karmaşıktır.