MUTASYON TESTİ

Yazılım geliştirme projelerinde en sık rastlanan problemlerden birisi de, bir yazılımın geliştirmesi ve doğrulama faaliyetleri tamamlandıktan sonra yazılımın gerçekten kullanıma hazır olup olmadığına ilişkin karar verilmesidir. Bir yazılımda hiç hata kalmadığını garanti altına almak neredeyse olanaksızdır. Bu sebeple doğrulama faaliyetleri esnasında gerçekleştirilen tüm testler başarılı olsa da, yazılım kullanıma alındığında içerisinde ciddi hatalar bulunma olasılığı vardır. Bu problem aslında doğrulama faaliyetleri esnasında yapılan testlerin yeterliliği problemi olarak da ifade edilebilecek bir problemdir. Eğer doğrulama faaliyetleri esnasında kullanılan test seti yeterli bir set ise, büyük olasılıkla bu testlerin başarılı olması yazılımda ciddi bir hata kalmadığına ilişkin önemli bir kanıt olacaktır. Testlerin yeterliliğini ölçmek ise düşünüldüğü kadar kolay değildir. Geliştirilen yazılımlar için milyonlarca hatta milyarlarca bazı durumlarda ise sonsuz sayıda test senaryosu geliştirmek mümkündür. Ancak takvim ve bütçe kısıtları sebebiyle, yazılım doğrulama faaliyetleri esnasında sadece bu olası geniş setin çok küçük bir alt kümesi test senaryosu olarak geliştirilip denenebilmektedir.

Bu noktada, testlerin yeterliliğini ölçebilmek adına bazı yaklaşımlar ortaya konulmuştur. Bunlardan en sık kullanılanı kod kapsama analizleridir. Kod kapsama analizleri ile geliştirilen test senaryoları koşturulup, bu senaryolar aracılığıyla yazılım kaynak kodunun ne kadarlık kısmının kapsandığı ölçülmektedir. Bu ölçümler sonucunda, eğer kaynak kod içerisinde kapsanmayan kod parçaları var ise bunları kapsayacak yeni test senaryoları geliştirilip test setine eklenmektedir. Problemin çözümüne yönelik bir diğer yöntem ise hata-tabanlı test yaklaşımlarıdır. Hata-tabanlı test yaklaşımları, aslında testlerin test edilmesi olarak da ifade edilebilir. Hata-tabanlı test yaklaşımlarında, yazılım kaynak kodunun içerisine bilerek ve kontrollü bir şekilde hatalar yerleştirilmekte, ardından mevcut test senaryo seti çalıştırılıp, setin bu hataları yakalayıp yakalamadığı kontrol edilmektedir. Test setinin yakalayamadığı hatalar için, bu hataları yakalayacak yeni test senaryoları eklenmektedir. Böylece testlerin hata yakalama başarısı bir anlamda test edilmektedir.

Bu yazıda, hata-tabanlı test yaklaşımlarından birisi olan mutasyon testi hakkında bilgi verilmeye çalışılacaktır.

MUTASYON TESTİ

Mutasyon testi, hata-tabanlı test yaklaşımı altında sınıflandırılan bir yazılım testi türüdür. Hata-tabanlı test yaklaşımlarında; geliştirilen testlerin, test edilen yazılımın olası hatalı farklı versiyonlarını doğru olan versiyondan ayırt edebilme yeterliliği kontrol edilmektedir. Bunu yapmak için genellikle, test edilecek olan yazılımın içine çeşitli hatalar bilerek eklenerek yeni hatalı versiyonlar üretilmekte ve testler bu hatalı versiyonların üzerinde tekrar çalıştırılmaktadır. Bir yazılıma küçük sözdizimsel (syntactical) hatalar eklenerek elde edilen yeni yazılım versiyonuna mutant adı verilmektedir. Test setinin oluşturulan mutant yazılım versiyonları üzerinde çalıştırılmasından sonra, setin hataların ne kadarını yakaladığı ölçülür. Eğer üretilen mutant versiyon üzerinde koşturulan tüm test senaryoları başarılı olduysa, ilgili mutasyon yakalanamamış olacaktır. Ancak test senaryolarından birisi bile başarısız olduysa, ilgili test seti yapılan mutasyonu yakalamıştır. Bu sonuçlara bakılarak hem yazılımda ne kadar yakalanmamış hata olabileceği tahmin edilmeye çalışılır, hem de yakalanmayan mutantları yakalayacak yeni test senaryoları test setine eklenir.

Yazılımın mutantlarını üretirken temel prensip, her bir mutant versiyonda sadece bir adet hata eklenmesi prensibidir. Dolayısıyla, mevcut yazılım kodunda, her seferinde sadece bir adet hata eklenerek farklı mutant sürümler elde edilmektedir. Yazılım koduna yalnızca bir adet hata eklenerek oluşturulan mutant versiyonlara “birincil (primary)” mutant adı verilmektedir. Aşağıdaki şekilde bir kod parçası için mutasyon örnekleri verilmiştir.

Şekil 1 Mutasyon Örneği

Üretilen mutantlar üzerinde testler koşturularak, yazılımda ne kadar hata kaldığını hesaplamak için aşağıdaki adımlar izlenebilir:

• Öncelikle oluşturulan test seti (T), yazılım üzerinde koşturularak yazılımdaki mevcut hatalar yakalanır ve düzeltilir. Bu süreç esnasında yakalanan toplam hata sayısı (r) ölçülür.

• Yazılım içine hatalar eklenerek n adet mutant sürüm üretilir.

• Sonra üretilen mutant sürümler üzerinde test seti (T) çalıştırılır ve setin yakaladığı mutant sayısı (k) hesaplanır.

• Yazılımın içinde kalmış olan olası hata sayısı r * (n-k) / k formülüyle hesaplanabilir.

• Test setinin (T) yeterliliği ise k/n formülüyle yüzde olarak hesaplanır.

Bir yazılım için başlangıçta üretilen test setinin (T) çalıştırılması sonucu 100 adet hata (r) yakalanmış olduğunu düşünelim. Bu yazılım için 1000 adet mutant versiyon üretildikten sonra, test seti (T) çalıştırıldığında üretilen 1000 adet mutant versiyondan 200 adedini (k) yakalarsa, yazılımın içinde kalmış olan hata sayısı ve test setinin yeterliliği değerleri aşağıdaki şekilde hesaplanacaktır:

Yazılımın içinde kalan hata sayısı hesabının istatistiksel bir hesap olduğu ve kesin bir değer olmadığı noktasına dikkat edilmelidir. Hesaplanan bu değerin gerçeği yansıtması için, üretilen mutant sürümlerde yazılıma bilerek eklenen hataların, yazılımı üreten ekip özelinde, sıklıkla yapılan hata türlerinden seçilmesi gerekmektedir. Örneğin, yazılımı üreten ekibin, geçmiş dönemde yaptığı hatalar incelendiğinde, sıklıkta aritmetik işlemlerde geçen toplama (+) yerine, yanlışlıkla çıkarma (-) işlemini kullandığı bir durum düşünülecek olursa, bu durumda üretilecek mutant sürümlerde, toplama (+) işareti geçen yerleri çıkarma (-) işareti ile değiştirerek mutantlar üretmek, istatistiksel açıdan anlamlı veriler elde etmek adına yararlı olacaktır.

Test seti üretilen mutant versiyonlar üzerinde çalıştırıldıktan sonra, bazı mutant versiyonlar yakalanırken, bazıları da yakalanmamaktadır. Bu durumun iki sebebi olabilir:

• Çalıştırılan test seti, orijinal program ile yakalanmayan mutant versiyonu ayırabilecek bir test senaryosu içermemektedir.

• Yakalanmayan mutant, davranış olarak orijinal programdan ayırt edilemeyecek bir yapıya sahiptir, dolayısıyla geliştirilecek herhangi bir test senaryosu aracılığıyla bu mutant versiyonu ayırt etmek olanaksızdır.

Yazılım kodunda yapılabilecek mutasyon çeşitleri aşağıdaki gibidir:

• Değer mutasyonları: Yazılım kodunda geçen sabit değerlerin veya değişkenlerin değerlerini değiştirmeye yönelik mutasyonlar bu gruba girmektedir. Örneğin “int a=0;” şeklindeki bir ifadenin “int a=1;” şeklinde güncellenmesi bu tip mutasyonlara örnektir.

• Karar mutasyonları: Yazılım kodunda geçen karar ifadelerinde yapılan mutasyonlardır. Örneğin “if(a>b)” şeklindeki bir ifadenin “if(a<b)” şeklinde güncellenmesi karar mutasyonlarına bir örnektir.

• Satır mutasyonları: Yazılım kodunda geçen satırların silinmesi veya satırlarda geçen operatörlerde güncellemeler yapılması satır mutasyonları olarak adlandırılmaktadır. Yazılım kodunda geçen “k++;” şeklindeki bir satırın silinmesi satır mutasyonuna bir örnektir.

Orijinal programdan testler çalıştırılarak ayırt edilmesi olanaklı olmayan mutant versiyonlara “eşlenik mutant” (equivalent mutant) adı verilmektedir. Aşağıda bir yazılım kodu ve bunun eşlenik mutant örneği verilmiştir. Örnekte orijinal yazılım kodunda 11. satırda yer alan “x = a + b” ifadesi “x = a + a” şeklinde değiştirilerek bir mutant versiyon elde edilmiştir. Ancak 10. satırda b değeri a değerine atandığı için, iki yazılım davranış olarak birbirinin aynısıdır, bu sebeple yazılabilecek herhangi bir test senaryosu ile bu iki yazılımı birbirinden ayırt etmek olanaklı değildir.

Şekil 2 Eşlenik Mutant

Eşlenik mutant konusu, mutasyon testi açısından önemli bir problem teşkil etmektedir. Test seti tarafından yakalanamayan bu mutantların, yakalanmayan diğer mutantlar gibi analiz edilmesi gerekmektedir. Ancak bu analizin sonucunda, eklenmesi gereken bir test senaryosu tespit edilemeyeceği için, yapılan analiz sonuçta bir getirisi olmayan ancak zaman ve emek kaybına yol açan bir analiz haline gelmektedir. Bu noktada, mutant sürüm üretmede kullanılan yazılımların, daha gelişmiş hale getirilmesi ve olası eşlenik mutant üretiminin en baştan azaltılmaya çalışılması mantıklı bir yaklaşım olacaktır. Grün ve arkadaşları tarafından yapılan çalışmada, örnek bir mutant oluşturucu yazılım kullanılmış ve üretilen mutant versiyonların yaklaşık %40’ının eşlenik mutant olduğu tespit edilmiştir. Aynı çalışmada, yakalanmayan mutant versiyonların eşlenik mutant olup olmadığına ilişkin yapılan analizlerin ciddi zaman ve emek kaybına yol açtığı da ortaya konulmuştur. Dolayısıyla eşlenik mutant konusu, mutasyon testi uygulanması durumunda karşımıza çıkan önemli problemlerden biridir.

MUTASYON TESTİNİN TEMEL ALDIĞI VARSAYIMLAR

Mutasyon testinin temel amacı, bir yazılımı test etmek için hazırlanan test setinin hataları bulmaktaki yeterliliğini ölçmek ve test setini daha da yeterli hale getirmektir. Ancak yazılımlarda mevcut olabilecek hata türleri sonsuz sayıda olduğu için, mutasyon testinin bunların hepsini önleyebilecek etkililikte bir test seti üretimiyle sonuçlanması mümkün değildir. Dolayısıyla mutasyon testi, bu sonsuz çeşitlilikteki olası hata türlerinin bir alt kümesini simüle ederek kullanılan test setini hata yakalamada en etkili hale getirmeye çalışmaktadır. Bu noktada mutasyon testi iki temel varsayıma dayanmaktadır:

• Ehil Programcı Varsayımı (Competent Programmer Hypothesis)

• Bağlaşım etkisi (Coupling Effect)

Varsayımlardan ilki olan “Ehil Programcı Varsayımı”, DeMillo ve arkadaşları tarafından 1978 yılında ortaya konulmuştur. Bu varsayıma göre, yazılım kodu geliştiren kişiler işlerinde ehil kişilerdir ve geliştirdikleri yazılımlar geliştirilmesi istenilen yazılımın doğru haline en yakın yazılımlardır. Dolayısıyla, bu ehil yazılım geliştiricilerin geliştirdikleri yazılımlar her kadar hatalar içeriyor olsa da, bu hatalar büyük mantık hatalarından ziyade, küçük sözdizimsel(syntax) hatalardır. Bu varsayımdan hareket edildiğinde, yazılım geliştiricilerin yapacakları olası hataları simüle etmek için yazılım programlarında küçük sözdizimsel değişikliklerin yapılması anlamlı olacaktır.

İkinci varsayım olan “Bağlaşım Etkisi” de ilk varsayım gibi DeMillo ve arkadaşları tarafından 1978 yılında ortaya konulmuştur. İlk varsayım olan “Ehil Programcı Varsayımı” yazılım geliştiren kişilerle ilgiliyken, ikinci varsayım mutasyon testlerinde bilerek eklenen hataların yapısına ilişkindir. Bu varsayıma göre, bir yazılımdaki küçük bir sözdizimsel hatayı yakalayabilecek olan test seti, yazılımdaki olası diğer karmaşık ve büyük hataları da yakalayabilir. Bir başka ifadeyle, bir yazılımdaki bütün sözdizimsel basit hataları yakalayabilecek olan bir test seti, yazılımdaki karmaşık hataların da çok büyük oranını yakalayabilecektir. Bu varsayımdan hareketle, mutasyon testlerinde orijinal yazılım içerisine sadece küçük sözdizimsel hatalar eklenip mutant versiyonlar üretilmektedir.

MUTASYON TESTİNDE KULLANILAN TEMEL OPERATÖRLER

Mutasyon testindeki problemlerden birisi de, yazılımda ne gibi değişiklikler yapılarak mutant versiyonların oluşturulacağı konusudur. Bir yazılımda çeşitli değişiklikler yapılarak, yazılımın sonsuz sayıda mutant versiyonunu oluşturmak mümkündür. Yapılan araştırmalar, belirli mutasyon türlerinin, testlerin yeterliliğini ölçmede gerekli verimliliği sağladığını ortaya koymuştur. Bu ana mutasyon türleri şunlardır:

• Numerik sabitlerin değiştirilmesi: Yazılım kodu içerisinde geçen numerik sabitlerin farklı değerlerle değiştirmesi olarak tanımlanabilir. Örneğin yazılım kodunda geçen bir X sabiti X+1, X-1 veya 0 gibi değerlerle değiştirilerek farklı mutant versiyonlar elde edilebilir.

• Koşulların negatif olarak güncellenmesi: Yazılım kodunda geçen koşulların negatifleri ile güncellenmesidir. Örneğin, yazılım kodunda geçen “if(A)” şeklindeki bir ifade if(NOT(A)) şeklinde güncellenerek bir mutant versiyon elde edilebilir.

• Aritmetik operatörlerin değiştirilmesi: Yazılım kodunda geçen +, -, *, / gibi aritmetik operatörlerin farklı bir operatörle değiştirilmesidir. Örneğin yazılım kodunda geçen “a = b * c” şeklindeki bir ifade “a = b – c” şeklinde güncellenerek yeni bir mutant versiyon elde edilebilir.

• Aritmetik operatörler eklenmesi: Yazılım koduna “++”, “--“ gibi tekli operatörler veya “+=”, “*=”, “-=”, “/=” gibi kısa yol operatörlerinin eklenmesiyle yeni mutant versiyonlar oluşturulabilmektedir.

• Method/Fonksiyon çağrılarının kaldırılması: Kod içerisinde geçen method/fonksiyon çağrılarının kaldırılmasıdır. Bu noktada, ilgili method/fonksiyon eğer bir tamsayı dönüyorsa, çağrının yapıldığı yere 0 gibi sabit bir değer yazılabilir. Örneğin yazılım kodunda geçen “ a = square_root(b)” şeklindeki bir ifade “a = 0” şeklinde güncellenerek yeni bir mutant versiyon elde edilebilir.

Yukarıda sıralanan geleneksel mutasyon operatörleri olarak da adlandırılan mutasyon operatörlerinin dışında, nesne tabanlı programla dilleri için kullanılan ve bu dillere özel kalıtım (inheritance), polimorfizm gibi özellikleri hedef alan mutasyon operatörleri de mevcuttur. Örneğin C++ programlama dilinin nesne tabanlı özelliklerini hedefleyen aşağıdaki mutasyon operatörleri mevcuttur:

• “Base” anahtar sözcüğünün silinmesi

• “Base” anahtar sözcüğünün eklenmesi

• “this” anahtar sözcüğünün silinmesi

• “this” anahtar sözcüğünün eklenmesi

• “Destructor” metodunun silinmesi

• “virtual” sözcüğünün eklenmesi

Son dönemde geliştirilen araçlar sayesinde, yukarıda listelenen temel operatörlerin haricinde birçok mutasyon operatörü kullanılarak, yazılımların farklı mutant sürümleri oluşturulabilmektedir. Ancak bu durum çeşitli problemlere sebebiyet vermektedir. Kullanılabilecek olası mutasyon operatör sayısı arttıkça, üretilen yazılımın birçok mutant versiyonu üretilebilmektedir ve bu versiyonların her biri üzerinde tüm test senaryolarını çalıştırmak ciddi bir zaman ve kaynak gerektirmektedir. Bu sebeple üretilecek olan mutant sürüm sayısını azaltmak veya üretilen mutant versiyonların tamamını koşturmamak üzerine kurulu farklı stratejiler geliştirilmiştir. Bu stratejilerden ilki, mevcut mutasyon operatörlerin tamamını kullanarak yazılımın mutant sürümlerini oluşturmak ve ardından üretilmiş olan bu mutant sürümlerden önceden belirlenmiş bir yüzde (%X) kadarını rastgele seçerek, test senaryolarını bu sürümler üzerinde çalıştırmaktır. Böylece, üretilen tüm mutant sürümler üzerinde testler koşturulmayacağı için daha az zaman ve kaynağa ihtiyaç duyulacaktır. Bir diğer strateji ise, olası tüm mutasyon operatörlerini kullanmak yerine, bu operatörlerin bir alt kümesini seçerek, mutant sürümleri sadece bu alt kümede yer alan mutasyon operatörleri ile oluşturmaktır. Böylece, tüm mutasyon operatörleri kullanılmadığı için, daha az sayıda mutant versiyon oluşturulacak ve testler bunların üzerinde çalıştırılarak gene zaman ve kaynak açısından kazanç sağlanacaktır. Bu yaklaşımın seçilmesi durumunda, kullanılacak olan mutasyon operatörlerinin alt kümesini belirlerken nasıl bir yöntem izleneceği önem arz etmektedir. En optimum yöntem, projelerin geçmiş dönem verilerini analiz ederek, projelerde en sık karşılaşılan hata türlerine yönelik mutasyon operatörlerini seçmek ve bunları kullanarak mutant sürümler oluşturmaktır.

MUTASYON TESTİNE İLİŞKİN BİR ÖRNEK ÇALIŞMA

Çalışmanın bu bölümünde, mutasyon testini daha iyi anlatmak adına, örnek bir kod geliştirilecek bu koda ilişkin önce satır kapsaması(statement coverage) ve karar kapsaması (decision coverage) sağlayan test minimum test setleri oluşturulacaktır. Daha sonra MuJava aracı kullanılarak ilgili kodun mutant versiyonları oluşturulacak ve test setleri mutant versiyonlar üzerinde çalıştırılarak setlerin mutant versiyonlardaki hataları yakalamadaki başarı oranları incelenecektir. MuJava aracı, ilk sürümü 2003 yılında yayınlanmış olan, Java programlama dili ile yazılmış yazılım kodlarının mutant versiyonları üreten ücretsiz bir araçtır. MuJava aracı, Kore Bilim ve Teknoloji Yüksek Enstitüsü (KAIST) ve George Mason Üniversitesi (A.B.D.) ortaklığında geliştirilmiş bir araçtır.

Örnek kod olarak, verilen bir girdinin Internet Protocol (IP) versiyon 4’e göre geçerli bir IP adresi olup olmadığını belirleyen bir fonksiyon kullanılacaktır. Bu protokole göre, geçerli IP adresleri 0 ile 255 arasında sayılardan oluşan ve birbirlerinden nokta(.) ile ayrılan 4 adet alandan oluşmalıdır. Örneğin 172.16.254.1 geçerli bir IP adresi iken, 34.172.13 veya 172.311.2.1 geçersiz IP adresleridir. Verilen bir IP adresinin IP versiyon 4’e göre geçerli olup olmadığını belirlemek üzere java programlama dili ile geliştirilmiş olan kod Şekil 3’te verilmiştir.

Şekil 3 IPV4 Kodu

Geliştirilen kodun satır (statement) ve karar (decision) kapsamasını sağlamak üzere geliştirilen test setleri ise tablo 1’de verilmiştir.

Tablo 1 Satır ve Karar Kapsaması Test Setleri

Geliştirilen kodun mutant versiyonlarını oluşturmak için MuJava’nın sağladığı temel mutasyon operatörleri kullanılmıştır. Bu operatörler tablo 2’de verilmiştir.

Tablo 2 Kullanılan Mutasyon Operatörleri

Kullanılan operatörler ile geliştirilen kodun 147 adet farklı sürümü oluşturulmuştur. Ancak bu sürümlerin sadece 124 adedi çalıştırılabilmiştir. Oluşturulan mutant versiyonların 23 tanesi ise çeşitli sebeplerden dolayı (kodun gerçekleştirilen mutasyon sebebiyle derlenemez hale gelmesi, kodun gerçekleştirilen mutasyon sebebiyle çalıştırılamaması gibi) çalıştırılamamıştır. Çalıştırılan 124 adet mutant versiyon için satır kapsaması test seti ve karar kapsaması test setleri ile sonuçları aşağıdaki tabloda verilmiştir.

Tablo 3 Test Sonuçları

Sonuçlara bakıldığında, gerek satır gerekse karar kapsaması sağlayan test setlerinin mutantların birçoğunu tespit edemediği görülmektedir. Ayrıca karar kapsaması için geliştirilen test setinin, mutant sürümlerde eklenen hataları yakalamada, satır kapsaması için geliştirilen sete göre ciddi oranda daha başarılı olduğu da sonuçlardan anlaşılmaktadır. Hem satır hem de karar kapsaması test setleri tarafından yakalanamayan bazı mutasyon örnekleri aşağıdaki tabloda verilmiştir.

Tablo 4 Yakalanmayan Mutant Örnekleri

Tablo 4’te görüldüğü üzere, koda eklenen belirgin hataları hem satır hem de karar kapsaması sağlayan test setleri yakalayamamıştır. Bu durum, mutasyon testinin test setlerinin yeterliliğini ölçmek adına oldukça başarılı bir yöntem olduğunun göstergesidir.

SONUÇ

Bu çalışmada, hata-tabanlı yazılım test yöntemlerinden birisi olan mutasyon testi incelenmeye çalışılmıştır. Geliştirilen yazılım test setinin hataları yakalamakta ne derece yeterli olduğunu ölçmek adına mutasyon testi kullanılabilecek bir yöntemdir. Mutasyon testi, IEC 61508, EN 50128:2011 ve ISO26262 gibi bazı emniyet kritik yazılım geliştirme standartları tarafından da tavsiye edilmektedir. Ancak günümüzde geliştirilen yazılımlar kod satır sayısı bakımından oldukça büyük oldukları için, mutasyon testi uygulanması pahalı bir yöntemdir. Bu sebeple mutasyon testi kullanılırken, yazılımın içerisinde bulunan kritik bölümlere veya karmaşık algoritmalar içeren kısımlara odaklanmak verimlilik açısından gereklidir. Ayrıca mutasyon testi uygulamak isteyen projelerin, geçmiş dönem verilerini inceleyerek, projelerde en sık yapılan hata türlerine yönelik mutasyon operatörlerini kullanarak mutant versiyonlar geliştirmeleri de verimlilik açısından gereklidir. Böylece hem mutasyon testinin gerektirdiği maliyetler (zaman ve emek) azaltılmış olacak, hem de mutasyon testinden faydalanmış olunacaktır.

Mutasyon testi kullanımı günümüzde gittikçe yaygınlaşıyor olmasına rağmen, test setlerinin yeterliliğini ölçmekte kullanılan bir diğer yöntem olan yapısal kapsama analizi (structural coverage analysis) kadar yaygın hale gelmemiştir. Bunun altında yatan en temel sebeplerin başında, mutant versiyonlar üretmek için gerekli olan araçların dünyada yaygın olarak kullanılan programlama dillerinin bazıları için mevcut olmayışı veya mevcut araçların gerçek projelerde kullanım açısından yeterli olgunlukta olmayışıdır. Zaman içerisinde mutant versiyonlar üretmek için gerekli araçların gelişimiyle, mutasyon testinin daha da yaygınlaşacağı öngörülmektedir.

Kaynaklar:

[1] T. Riley ve A. Goucher, “Beautiful Testing”, O’Reilly Publishing, 1st Edition, 2009.

[2] M. Pezze ve M. Young, “Software Testing and Analysis: Process, Principles and Techniques”, Wiley Publishing, 1st Edition, 2007.

[3] B. J. M. Grün, D. Schuler ve A. Zeller, "The impact of equivalent mutants", Mutation '09, 2009.

[4] Y. Jia ve M. Harman, "An Analysis and Survey of the Development of Mutation Testing", IEEE Trans. Software Eng., vol. 37, no. 5, pp. 649-678, 2011.

[5] S. Hamimoune ve B. Falah, “Mutation testing techniques: A comparative study”, International Conference on Engineering & MIS (ICEMIS), 22-24 Sept. 2016.

[6] P. Delgado-Pérez, S. Segura ve I. Medina-Bulo, “Assessment of C++ object-oriented mutation operators: A selective mutation approach”, Software Testing, Verification and Reliability, Volume 27, 2017.

[7] S. Banzi, T. Nobre, G. B. Pinheiro, J. C. G. Arias, A. Pozo ve S. R. Vergilio, “Selecting mutation operators with a multiobjective approach”, Expert Systems with Applications, 39, 2012.

[8] J. Offutt ve Y. Ma. “Description of muJava’s Method-level Mutation Operators”, 2005.