Yazılım Test Metrikleri

Direk ölçülebilen veya yapılan ölçümlere göre hesaplanan değerlere metrik denir.
Testler için alınan metrikler, testi yapılan yazılım, müşteriye gönderebilmek için yeterli kaliteye ulaştı mı? Test ne kadar verimli olduğu gibi sorulara cevap verir.

Yazılım projelerinde özellikle kod satır sayısı ve hata sayısı en önemli metrikleri oluşturuyor.

Yazılım test mühendisliğinde tutulan 3 tip metrik vardır:

• Süreç Öncesi Metrikler
• Süreç Sırası Metrikler
• Süreç Sonrası Metrikler

Süreç Öncesi Metrikler: Test eforunu tahmin etmede kullanılır. Süreç öncesi metrikler genelde test sürecinin en başında, test takvimi belirlenirken test eforunu tahmin etmede kullaılırlar. Testi yapılan yazılımın büyüklüğü örneğin gereksinimlerin sayısı, kod satır sayısı, function points, complexity gibi faktörler göz önünde bulundurulur. Testi yapılan yazılımın kalitesinden kasıt gereksinim gözden geçirmelerinde bulunan hata sayısı, kod gözden geçirmede bulunan hata sayısı olabilir.

Faktörler:
- Testi yapılan yazılımın büyüklüğü
- Testi yapılan yazılımın kalitesi
- Bir önceki projelerde edinilen deneyim

Süreç Sırasında Tutulan Metrikler: Gidişatı izlemeye ve yazılımın kalitesini anlamaya yardımcı olur. Test sürecinin planlandığı şekilde gidip gitmediğine bakılır. Planlanan, koşan, geçen, kalan test prosedür sayıları gözönüne alınır. Hata sayılarına baklılırken, önem seviyeleri de dikkate alınır. Bunlar:

• Seviye 1: Tüm sistem ya da önemli bir fonksiyonalite çalışmıyor ve geçici bir çözüm yok
• Seviye 2: önemli bir fonksiyonalite çalışmıyor ve geçici bir çözüm var ya da önemsiz bir fonksiyonalite çalışmıyor ve geçici bir çözüm yok.
• Seviye 3: önemsiz bir fonksiyonalite çalışmıyor ve geçici bir çözüm var
• Seviye 4: Yazım hatası gibi kozmetik hatalar var ya da gereksinimlerde açık olarak belirtilmeyen iyileştirmeler yapılmamış.

Bu seviyelerin test planında müşteri ile görüşüp onay alınarak belirtilmesi gerekir.

Faktörler:
-Test prosedür sayısı
-Önem seviyelerine göre bulunan hata sayısı
-Testleri koşturmak için harcanan zaman

Süreç Bitiminde Tutulan Metrikler: Yazılımın kalitesini anlamaya ve süreçlerimizi iyileştirmeye yardımcı olur. Yapılan öngörülerle ne kadar örtüştük ona bakılır. Burada hata giderme oranının ne kadar 1’e yakın olduğu, yapılan testin kalite için bir göstergedir. Sistemde bulunan hataların çoğunun, en azından kritik olanların tamamının sistem testlerinde bulunmuş olması gerekir.

Faktörler:
-Süreç öncesi alınan metrikler
-Çözülmemiş, açık olan hata sayısı ve önem seviyeleri
-Test prosedürlerinde bulunan hata sayıları
-Hata Giderme Oranı (HGO)

HGO = Hs / (Hs + Hm)
Hs: Sistem testlerinde bulunan hata sayısıHm: Müşteri tarafından bulunan hata sayısı

Yazılım Test Otomasyonu

Test otomasyonu test ile ilgili olsa da, aslında bir yazılım geliştirme işidir. Genellikle istenir fakat kendi içinde bir takım riskler taşır. Hazır da alınabilir, geliştirilmesi de gerekebilir. Yazılım geliştirmenin erken safhalarında otomasyon çalışmalarına başlamak gerekir. Başarılı test otomasyonu kararlılık, testçiler ve geliştiriciler arasında takım çalışması gerektirir.

Hem zaman kazandırır hem de insan faktörlerinden doğabilecek bir takım problemlerin önüne geçer. Örneğin bir otomasyon aracı hiç bir zaman koşturulması gereken bir test prosedürünü unuttuğu için size eksik sonuç vermez. Test sonuçlarını doğru bir şekilde kayıt altında tutar. Özellikle çok fazla regression test koşturulması gerekliyse yani aynı testler kod değiştikçe birden fazla kere koşturulacaksa otomasyon mutlaka yapılmalıdır.

Kritik iş süreçlerinde, karmaşık uygulamalarda ve bunları tehlikeye atan kullanım durumlarında otomasyon çabalarına odaklanmak anlamlıdır. Ama bir kurumun günde birçok saat çalışan birden çok yazılım testçisi varsa ve hala kalite ve işlevsel sorunlar bulunuyorsa, otomatik teste geçmek yararlı olabilir.

Otomasyon işine erken safhada başlamak gerekir. Çünki geç aşamalarda başlandığı zaman tüm test tasarımlarını, test stratejilerini, test sonuç formatını ve benzeriyi değiştirmek gerekebilir. Bu da maliyet ve aynı zamanda personelin demotivasyonu demektir. Bu etkileri en aza indirebilmek için, otomasyon mimarisini çok iyi yapmak gerekir.

Yazılım otomasyon işinde turnover yani devretme işinin yüksek olmaması gerekir çünki otomasyon işi deneyim isteyen bir iştir. Yoksa başarı şansı azalır.

Bu iş için özel personel ve zaman ayırmak gerekir.

Yazılım otomasyonu da bir yazılım geliştirme projesi olarak ele alınmalı, bu iş için de özel olarak asssign edilmiş testçiler bulunmalı, otomasyon fazının da normalde işleyen yazılım projelerinde olduğu gibi gereksinimlerinin çıkarılması, tasarımının yapılması, hata yönetimi yapılması ve testlerinin yapılması gerekmektedir.

Yazılımda Otomasyonun Avantajlarını şöyle sıralayabiliriz:

• İnsan kaynaklı hataları minimize eder
• Daha fazla hatayı daha erken teşhis eder
• Testlerin yeniden kullanımını kolaylaştırır
• Testlerle kapsanan kod yüzdesini artırır (Code Coverage)
• Testler 7x24 çalışabilir

Ne zaman otomasyon yapmalıyız?

Aşağdıaki sorulardan en az bir tanesine "EVET" cevabı vermişseniz otomasyon yapmak projenin faydasına olacaktır fakat şunu da belirtmekte fayda var ki otomasyon manuel testlerin yerine konan bir yöntem değildir. İşleri kolaylaştırmak için yapılır, bazen en önemli hatalar Ad Hoc testler ile bulunur, yani testçi kendisini müşterinin yerine koyar ve çeşitli senaryolar dener ve genelde de önemli hatalar bu şekilde bulunur.

• Test aktiviteleri ardışık olarak tanımlanabiliyor mu?
• Ardışık aktiviteleri tekrarlamak gerekiyor mu?
• Ardışık aktiviteler için otomasyon yapılabiliyor mu?
• Testler, yarı-otomatik hale getirilebiliyor mu?
• Testi yapılan yazılımın davranışları otomasyon olunca değişmiyor?
• Programın kullanıcı arayüzü olmayan özellikleri mi test ediliyor?
• Aynı testleri farklı donanım konfigürasyonlarında koşturmak gerekiyor mu?

Açık Kutu Test Teknikleri

Bu tip testlerde kaynak kod test mühendisi tarafından görülebilir. Hatta bu yöntemlerden bazıları kaynak kodun değiştirilmesini bile gerektirir. Örneğin mutasyon testi gibi.

Aşağıda listelenen teknikler, açık kutu test tekniklerine birer örnektir:


Reference models for code-based testing (flow graph, call graph)
Kontrol Akışı Tabanlı Test
Veri Akışı Tabanlı Test
Mutasyon Testi

Kapalı Kutu Test Teknikleri

Yazılım test edilirken sadece girdi ve çıktı değerleri bilinir. Yazılımın içinde ne tür algoritmalar çalıştığı, nasıl kodlandığı, tasarım detayları ve kod bilinmez.
Yazılım bir sistem olarak ele alınır ve hangi girdilere sistemin ne cevap verdiği test edilir.

Aşağıdaki teknikler kapalı kutu test teknikleridir:

Equivalence partitioning
Boundary-value analysis
Decision table (Karar Tablosu)
Finite-state machine-based
Formal Spesifikasyonlardan Test
Error guessing
Random testing
Operational profile
SRET

Yazılım Test Teknikleri

Test teknikleri geliştirilmesindeki amaç, sistematik olarak test senaryolarının seçilebilmesini sağlamaktır. Hangi tekniğin ne zaman kullanılacağı test mühendisinin deneyimi, kaynak kodun yapısı, gereksinimlerin yapısı, bulunan gerçek hatalar, alan kullanımı ve uygulamanın doğasıyla ilgili olabilir. Test teknikleri genelde birbirlerine alternatif değil, birbirlerini tamamlayıcı rol oynarlar. Bu teknikler, testin amacına hizmet etmesi için kullanılan araçlardır.

Çeşitli test teknikleri vardır. Bunlar aşağıdaki gibi özetlenebilir. Detaylar için önemli tekniklerle ilgili ayrıca yazılarım olacaktır.

1)Test Mühendisinin Deneyim ve Önsezilerine Dayalı Test Teknikleri:

Ad hoc Test: Herhangi bir dokumantasyonu olmayan, tamamen test mühendisinin bilgi düzeyi ve yaratıcılığıyla oulşturduğu test senaryolarıdır. Belki de en fazla kullanılan tekniklerde birisidir. Test yapan kişinin benzer programlarla olan deneyimine oldukça bağlıdır. Formal methodlarla çıkamayan test senaryoları yaratmak için kullanılan bir yöntemdir.

Exploratory Test: Araştırmacı test olarak da bilinir. Eşzamanlı, anında öğrenme, test tasarlama ve test koşmadır. Etkili olması testi yapan kişinin bilgisine, uzmanlığına, hataların tipne, test sırasında ürünün yaklaşımına, uygulama ile olan yatkınlığa, bunun gibi etkilere bağlıdır.

2)Spesifikasyonlara Dayalı Test Teknikleri:

Equivalence Partitioning

Boundary Value Analysis

Desicin Table (Karar tabloları)

Finite-State Machine Based Test

Formal Spesifikasyonlardan Test
Rastgele (Random) Test

3)Kod Tabanlı Test Teknikleri:

Control Flow Based Test

Data Flow Based Test

REference Models for Code-Based Testing

4)Hataya Dayalı Test Teknikleri:

Error Guessing

Mutation Testing

5)Kullanıma Dayalı Test Teknikleri:

Operational Profile

SRET (Software Reliablility Engineering Testing)

6)Uygulamanın Doğasına Dayalı Test Teknikleri:

Nesneye Yönelik Test (Object Oriented Testing)

Bileşen Tabanlı Test (Component-based Testing)
Web Tabanlı Test
Kullanıcı Arayüzü Testleri
Eşzamanlı Program Testleri
Protokol Uyum Testleri
Gerçek Zamanlı Sistem Testleri
Emniyet Kritik Sistem Testleri

Yazılım Test Başlama ve Bitirme Kriterleri

Test bazen “after-the-fact” aktivitesi olarak düşünülür yani ürünün kodlaması bittikten sonra uygulanacak bir aktivite gibi fakat bu yanlış bir düşünce tarzıdır. Yazılım testi, gereksinimlerin ortaya çıkmasıyla başlaması gereken bir prosestir. Bir çok standard, gereksinimler gözden geçirilirken test senaryolarının da paralel olarak yazılmasını önermektedir. Bu sayede gözden geçirmeler sırasında özellikle “testability”, “ambiguity”, “completeness” gibi sorulara cevap vermek kolaylaşır ve geri dönüşler azalır.

Benim şahsi fikrim test tasarımının gereksinimler aşamasında yapılması, test prosedürlerinin ise yazılımın tasarımı olgunlaştıktan sonra tamamlanmasıdır fakat projenin takvimine göre bu aşama geç de olabilir. Burada yapılabilecek şey, test prosedürlerinin yazılım tasarımından en çok etkilenecek olanlarının belirlenmesi ve belki sadece bu testlerin tasarım olgunlaştıktan sonraki bir aşamaya bırakılmasıdır. Testlerde özellikle de entegrasyon testlerinde kullanılacak olan araçların projenin en başında Test Değerlendirme ve Ana Planında zaten belirlenmiş olması gerekmektedir.

Bence birim testler bir “software development” aktivitesidir. Yani geliştirici tarafından yapılan dinamik gereksinim, tasarım ve kod gözden geçirmesi sayılabilir. Bu sebeple burada bahsettiğim yazılım testi ifadesindeki “test” genelde entegrasyon (yazılım-yazılım, yazılım-donanım) testlerine karşılık gelmektedir.

Testler ne zaman bitmeli gibi sorular ilk defa bir projeye test mühendisi ya da uzmanı olarak başlayan çoğu insanın sorduğu bir sorudur. Aslında bu sorunun tek bir cevabı da yoktur. Fakat bu test sonlandırma kriterleri mutlaka ve mutlaka Test Değerlendirme ve Ana Planında yer almalı ve müşteri tarafından onaylanmalıdır.

Burada bilgi amaçlı örnek olsun diye bazı test sonlandırma kriterlerini de vermek istiyorum:

• Test prosedürlerinin %100’ü koşturulduğunda
• Test prosedürlerinin %95’i “PASS” olduğunda
• Yüksek öncelikli olan tüm testler “PASS” olduğunda
• 1.Öncelikli hatalar = 0
• 2.Öncelikli hatalar ≤ 2
• 3.Öncelikli hatalar ≤ 5
• 4.Öncelikli hatalar ≤ 10
• İstenilen kod kapsamı (code coverage) sağlandığında

Yazılım Testi Nedir?

Yazılım testi için SWEBOK,2004 tarafından verilen tanımı kullanmak istiyorum:

“Software testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected(“specified and implied”) behavior”.

Burada anlatılmak istenen yazılım testinin; yazılımın sınırlı sayıda ve seçilmiş test senaryoları kullanılarak beklenilen davranışı gösterdiğinin dinamik olarak yani kodun çalıştırılarak doğrulanması aktivitesidir.

Test, bir doğrulama aktivitesidir. Yazılımın dinamik olarak geçerlemesidir aslında. Gereksinim, Tasarım, Kodlama gibi aktivitelerde yapılan statik geçerleme analizlerinin tamamlayıcısı sayılabilir. Test aşamasında bulunan bir hatanın düzeltme maliyeti, bakım aşamasında ortaya çıkan bir hatanın düzeltme maliyeti yanında oldukça düşük kalır. Bunun yanında, müşterinin bulduğu hataların size sadece maliyet olarak değil, güvensizlik ve pazardaki rekabeti düşüren bir faktör olarak geri dönmesi de kaçınılmazdır.

Elbette ki müşteriye teslim edilen versiyonda hiç hata olmaması mümkün değildir fakat kritik hataların müşteri tarafından bulunması projenin ne kadar başarısız olduğunun da bir göstergesidir.

Bir çok proje, test sürecinin belirsizliği ve test yönetiminin eksikliğinden dolayı olumsuz sonuçlanmaktadır.Test süreci, proje yaşam döngüsü içinde kurum ve yüklenici arasındaki güçlük derecesi en yüksek olan aşamadır.Projenin en son aşaması olarak yer alan "test süreci”, test planlaması ve yönetimi altında, projenin başından itibaren devreye alınarak, ürün kalitesini ve projede beklenen sonuçların elde edilmesini güvence altına almaktadır. Bence yazılımda iyi bir test sürecinin olması, yazılımın kalitesini etkileyen en önemli faktörleden birisidir.

Yazılım test süreçlerinde özellikle gereksinimlerin ve tasarımın anlaşılması çok önemlidir. Gereksinim bazlı testlerde, gereksinimlerin yanlış yorumlanması hatalı teste, bu da çalışmayan ya da hata vermesi beklenen bir sistemin onaylanmasına sebep olabilir. Test planı oluşturulurken de gereksinimlerin ve de projenin doğası, yapısı girdi olacaktır. Planda belirtilen yaklaşımlarla test tasarımları, durumları ve prosedürleri hazırlanır. Daha sonra hazırlanan bu dokümanlar gözden geçirilir. En sonda yapılıyor gibi görünmesine rağmen, test dokümanlarının hazırlanması aşamasına paralel olarak test ortam ve araçları, kullanılacak veriler hazırlanır. Hatta kullanılacak test ortamı test tasarımlarını ciddi anlamda etkiler, bu tip durumlar için test ortamı ne kadar erken hazırlanırsa o kadar iyi olur.

Günümüzde pek çok yazılım firmasında “Yazılım Test Mühendisliği” kavramı oturmamıştır. Birim testler, modül testleri ve entegrasyon testleri, en nihayetinde de müşteri kabul testleri halen projeyi geliştiren yazılım mühendisleri tarafından yapılmaktadır. Testlerin bağımsız kişiler tarafından yapılmasına gerek görülmemektedir.

Fakat son zamanlarda ülkemizdeki bazı firmaların emniyet kritik askeri projelerde yer alması ve bu projelerin de bir takım standardlara uyma zorunluluğu beraberinde bağımsız yazılım doğrulama aktivitelerinin gerçekleştirilemsine ve bu vesileyle yazılım geliştirme ekibinden bağımsız yazılım doğrulama ve geçerleme grupları oluşturulmasına ön ayak olmuştur.

Statik Kod Analizleri ve kullanılan araçlar

Statik kod analizörleri run-time öncesinde bulunması zor olan implementasyon hatalarını bulmaya yardımcı olurlar. Bunun sebebi, bu tip hataların execution zamanında bulunmasının daha zor hatta imkansız olmasıdır. Bu araçlar, uygulamayı çalıştırmaya gerek duymadan bir çok mantıksal, emniyet ve güvenlik hatalarını bulmaya yardımcı olurlar. Problemler kaynak kodu direk ya da statik olarak analiz edilerek bulunabilir.
Statik analiz araçları kaynak kodu extra bilgi gerekmeden doğrularlar. Statik analiz araçları uygulamanın ya da fonksiyonun ne iş yapacağını bilmediği için herhangi bir geliştirici ya da gözden geçiren kişinin yapması muhtemel bazı varsayımları yapmaz.

Çoğu statik analiz araçlarının kullandığı teknikler aşağıdaki gibidir:

· Semantic checking
· Strong type checking
· Memory allocation checking
· Logical statement checking
· Interface and include problem checking
· Safety/Security checking
· Metrics analysis
· Simulator (data generation)
· Crawl source code
Burada en çok kullanılan iki adet statik kod aracından bahsedeceğim: FlexeLint ve PolySpace.

FlexeLint C/C++ kodunu kontrol eder ve bug, uyumsuzluk, dead kod ve bunun gibi hataları bulmaya yardımcı olur. İhtiyaca göre düzenlenebilir. Örneğin çeşitli doğrulama kurallarını, analizin hassasiyet seviyesini, çıktı formatını ve analiz raporunu detaylarını seçme imkanı tanır. Ayrıca FlexeLint çeşitli kodlama kurallarını destekler. Bunlardan bazıları MISRA C, ANSI C ve K&R kurallarıdır. FlexeLint bir konsol uygulamasıdır ve komut satırından çalıştırılır.Ayrıca çeşitli IDE entegrasyonları da mümkündür.

PolySpace aracı gömülü sistemlerde C,C++ ve Ada kodlarını doğrular. Kod compile etmeden ve koşmadan önce yapılır. Bu yöntemle formal metodlar kullanarak sadece hataları önceden tespit etmekle kalmaz, aynı zamanda belli run-time hatalarının matematiksel olarak olmadığını da ispatlar.
PolySpace client-server tabanlıdır. Bazı doğrulamalar client tarafında yapılırken (örneğin MISRA kontrolü), bazıları da server tarafında yapılır (örneğin statik analizler). Bu mimari yapı, büyük takımlarda çok işe yarar. Hem client hem de server tarafı komut satırı arayüzü ve GUI destekler. Polyspace client ve server tarafından yapılan analizlerin sonuçlarını inceleyen bir uygulamaya sahiptir. FlexeLint’te olduğu gibi Polyspace de çeşitli konfigürasyon ihtiyaçlarına göre düzenlenebilir yapıdadır.
Her iki araç da diğer test ve analiz araçları ile tamamlanarak kullanılmalıdır. Bunlar:
· Manuel kod gözden geçirmeleri
· Dinamik analizler

Yazılım Doğrulama ve Geçerleme Aktiviteleri

Yazılım Test Mühendisleri tarafından bile sıklıkla karıştırılan iki kavramdır doğrulama ve geçerleme.Basitce, aşağıdaki sorulara cevap ararlar:

-Doğrulama (Verification): Yazılımı doğru mu üretiyoruz?
-Geçerleme(Validation): Üretilen yazılım doğru mu?

Doğrulama aktiviteleri kullanılan süreçlerin uygunluğunu statik olarak kontrol ederken, geçerleme aktiviteleri dinamik olarak üretilen yazılımın istenilen ve doğru ürün mü olduğunu kontrol eder.

Yazılım Kalitesi Nedir?

Yazılım Kalitesi, bir ürünün istenilen kalitede olmasını sağlamak üzere ugulanan aktivitelerin tümüdür.

-Değişiklik Yönetimi
-Süreçler ve Prosedürler
-Geçerleme ve Doğrulama
-Standartlar ve Şablonlar

Kaliteli yazılım geliştirme için kullanılan yöntemlerden bazılarıdır.