tiap- tiap software firewall  (NetbarrierX3, Firewall X2) yang terdapat pada OS X mengijinkan port dan protocol untuk dikonfigurasi semua , kecuali IPNetSentryX yang mengijinkan aplikasi whitelisting dan blacklisting, Dan  semua firewall tidak memberikan peringatan ketika kita mengganti network , dial – up accounts atau menggunakan jaringan Wi-Fi.

Sistem firewall ini dites dengan mematikan semua program firewall yang terdapat pada OS X itu sendiri yaitu , NetBarrier X3, Firewall X2  dan lain – lain (pengujian dengan menggunakan Mac OS X 10.3.6 menggunakan jaringan LAN , wireless dan dial up)

Hasil dari tes tersebut yaitu , Tanpa menggunakan Firewall dari software – software yang disebut (NetBarrierX3 , Firewall X2) kita dapat membuat pelindung yang lebih efektif dari malware, Tetapi cara ini tidak dapat memberikan semua perlindungan system, Hanya NetBarrier yang mempunyai perlindungan semua sistem

Source : http://www.macworld.com/article/42331/2005/01/securityfeaturetestreport.html

Posted by : Hendrawan Ardiansyah (23060163)

POSIX menentukan antarmuka pengguna dan antarmuka perangkat lunak terhadap sistem operasi dalam 15 dokumen yang berbeda. Antarmuka pengguna standar dalam POSIX adalah Korn shell yang digunakan untuk memasukkan perintah command-line dan pembuatan skrip. Program-program pengguna lainnya juga dimasukkan ke dalam standar, seperti awk, echo, ed, dan ratusan program lainnya. POSIX juga mendefinisikan pustaka API standar untuk thread (POSIX Thread) yang banyak diimplementasikan di sistem operasi modern. Sementara itu, layanan-layanan level program yang dimasukkan ke dalam standar adalah input/output dasar (file, terminal, dan jaringan). POSIX juga mendefinisikan bagaimana melakukan pengujian terhadap sebuah aplikasi apakah mendukung POSIX atau tidak, yang disebut dengan POSIX Confirmance Test Suite (PCTS).

Berikut merupakan beberapa standar POSIX :

Standar-Posix

standar POSIX  mempromosikan portabilitas aplikasi melalui platform sistem operasi yang berbeda. Ini penting untuk aplikasi  yang dirancang untuk umur panjang, di mana infrastruktur  perangkat keras dan lunak  akan berubah sepanjang waktu. di dalam real-time sistem, di mana prediksi dan ongkos exploitasi rendah sangat  penting, portabilitas  sering dikorbankan. Di sini saya akan membahas penggunaan POSIX® di dalam real-time sistem, dan  kemudian akan membahas testing performansi suatu real-time sistem operasi. kita menilai kegunaan POSIX di dalam real-time sistem dengan memperhatikan tiga faktor: ( functionality, performance, and availability) Sebab real-time sistem secara khas mempunyai  batasan penekanan performansi ketat yang ditempatkan pada performansi implementasi POSIX. kita menggunakan benchmarks untuk mengukur performansi real-time sistem.

Real-time Systems

Suatu real-time sistem adalah satu di mana ketepatan waktu menyangkut hasil dari suatu kalkulasi itu penting. Contoh  termasuk sistem senjata militer, sistem kontrol pabrik, dan Internet audio dan video streaming. Realtime  sistem secara khas digolongkan ke dalam dua kelas: hard and soft. Di dalam suatu real-time sistem hard waktu  deadline harus dijumpai atau hasil dari suatu kalkulasi invalid. . Internet audio/video streaming adalah suatu contoh dari suatu real-time sistem yang soft. Jika suatu paket data terlambat  atau hilang   audio/video mengalami degradasi, tetapi streaming mungkin tetap dapat didengar.

POSIX Real-time Related Standards

Posix-real-time-related-standard

dari standard 30 POSIX  tujuh standard terdaftar di dalam Tabel 1 terutama relevan kepada  pengembangan real-time dan embedded sistem. Dengan tiga standard yang pertama  ( 1003.1a,1b,1c) disebut  banyak support. Posix 1003.1a menggambarkan interface ke fungsi sistem operasi  dasar, dan   pertama untuk diadopsi pada 1990 . Real-Time extensions digambarkan dalam 1003.1b  standard, 1003.1d,  1003.1j dan 1003.21 . Bagaimanapun, real-time extensions yang asli, digambarkan oleh 1003.1b, hanya standard biasanya diterapkan. Dukungan untuk multiple threads di dalam suatu proses disiapkan dalam bentuk suatu standard terpisah  , POSIX 1003.1c. POSIX juga termasuk support untuk ketersediaan yang tinggi dalam standard 1003.1h  .

Testing the Real-time Performance of Operating Systems

Benchmarks yang digunakan disini dibagi menjadi dua kategori: . yang mengukur determinisme OS dan . yang mengukur latency dari operasi yang penting tertentu. Benchmarks ini adalah termotivasi oleh real-time kebutuhan capaian. Benchmarks menguji inti  kemampuan sistem operasi dan adalah tidak terikat pada manapun aplikasi yang nyata. Juga sebab kita tertarik  di dalam menentukan kemungkinan terbaik real-time capaian itu, semua real-time menyusupkan adalah menabrak; menyerang yang maksimum  real-time prioritas yang mungkin, dan memori sebetulnya yang digunakan oleh benchmarks dikunci ke dalam memori phisik.

Tabel dibawah ini meringkas enam benchmarks yang digunakan disini

Real-time benchmarks

Deterministic benchmarks

Tiga yang pertama benchmarks ditunjukkan di dalam diatas, ( Pengatur Waktu Jitter, Tanggapan, dan Bintime) dirancang untuk mengukurlah determinisme dari suatu sistem operasi  . Sebab determinisme menyiratkan bahwa waktu melaksanakan suatu operasi yang diketahui, kita secara khas melaporkan yang terburuk waktu kasus untuk ini benchmarks.

Latency benchmarks

Tiga test sinkronisasi berbeda ditunjukkan di dalam Gambar dibawah. Dalam test pertama isyarat thread tunggal ( S)  dan kemudian menunggu ( W) pada suatu semaphor. Test ini mengukur latency sistem semaphor panggil. Yang Kedua menguji semaphor penggunaan isyarat antara dua thread. thread adalah salah satu di dalam tunggal, atau dua berbeda proses. Pengukuran dari permulaan dua test dapat digunakan untuk menentukan konteks yang menswitch waktu oleh pengurangan mulai sistem panggil ongkos exploitasi, memperoleh di dalam test, dari separuh roundtrip waktu pemberian isyarat, yang diperoleh di dalam test dua.

Latency-Benchmark

Pesan menghantar benchmark menggunakan POSIX pesan antri untuk mengukur latency dan throughput perpindahan data antara dua thread  dalam proses sama atau di dalam proses yang berbeda. Benchmark yang terakhir mengukurlah latency Posix real-time signal.

Benchmark Results

Benchmarks menggambarkan dalam bagian sebelumnya adalah dimajukan dua sistem operasi yang berbeda: Lynxos dan Solaris 8. Tabel dibawah mengidentifikasi tiga Solaris bentuk yang berbeda. Bentuk yang berbeda ini mengijinkan untuk memeriksa dampak dalam menggunakan berbagai CPUS. Bentuk wujud pertama menggunakan dua pengolah seperti halnya Ultra 60. Karena bentuk wujud salah satu dari CPUS yang kedua   dilumpuhkan. Dalam bentuk wujud akhir salah satu dari CPUS adalah yang dipesan dan real-time benchmarks adalah dimajukan itu.. Juga untuk ini bentuk wujud pengolah dipesan dinaungi dari semua unbound interrupts.

Benchmark-Result

Non real-time external load

Tabel dibawah  menunjukan jenis dalam memproses digunakan untuk menghasilkan beban yang non-real-time. Beban beristilah CPU aplikasi intensive seperti halnya aplikasi yang menggunakan menyela Sarana I/O seperti file dan subsistem jaringan.

Non-real-time-external-load

5.2 Timer Jitter

Gambar dibawah menunjukan hasil menyangkut pengatur waktu jitter tes run pada empat platform. Tanpa suatu beban, menunjukkan di dalam Gambar (a), semua jitter platform bisa diterima di bawah 200 ì detik. Solaris ( 1 rt) bentuk wujud mempunyai jumlah paling sedikit jitter. Jitter untuk Lynx bentuk wujud adalah juga rendah. Di bawah suatu muatan berat, menunjukkan di dalam Gambar (b), jitter untuk Solaris bentuk wujud yang tidak mencadangkan suatu real-processor lewat batas. Yang terburuk kasus jitter, karena bentuk wujud ini, lebih besar dari sepuluh detik/second

Timer-jitter

Application Response

Tabel dibawah menunjukan kasus yang terburuk menanggapi hasil untuk semua bentuk wujud. Tanpa suatu beban semua bentuk wujud mempunyai suatu tanggapan menghasilkan sangat dekat dengan nilai dikalibrasi 10 seperseribu detik. Dengan suatu beban hanya Lynx dan Solaris ( 1 rt) bentuk wujud datang dekat dengan 10 nilai seperseribu detik. Yang terburuk hasil kasus untuk standard itu Solaris platform ( Solaris 2 proses) apakah tiga order lebih buruk dibanding nilai yang dikalibrasi itu.

Application-Response

Synchronization

Gambar dibawah menunjukkanlah rata-rata latencies untuk mekanisme sinkronisasi yang sama. Karena Lynx the lynx semaphor memperlihatkan latency yang paling tinggi,  hampir bisa dipastikan kepada fakta warisan prioritas yang diterapkan untuk/karena semaphor ini. Karena Solaris latency menyangkut POSIX menamai semaphor adalah jauh lebih tinggi dibanding latency menyangkut mekanisme yang lain itu. Suatu penjelasan untuk ini adalah bahwa semaphor menyebut bertahan sistem file.

Sync Test 1 : Lynx and solaris (1rt)

Sync test 1 : lynx and solaris

Sync Test 2 : Lynx and solaris (1rt)

Sync test 2 : lynx and solaris

Sync Test 3 : Lynx and solaris (1rt)

Sync test 3 : lynx and solaris

Context switching times

Context Switching Times

Communication

Real-time signals

Gambar dibawah menunjukan hasil menyangkut signal real-time benchmark untuk semua bentuk wujud. Lynx mempunyai suatu isyarat latency yang lebih rendah dibanding Solaris bentuk wujud yang manapun . Juga Solaris 1 proses dan 2 bentuk wujud proses sungguh dipengaruh oleh penambahan dari suatu beban yang non-real-time.

Real Time Signals

Pesan antri Latency dan throughput POSIX antrian pesan untuk semua bentuk wujud ditunjukkan di dalam Tabel dibawah The latency untuk Lynx platform menjadi lebih baik dibanding Solaris platform, tetapi Solaris platform mempunyai throughput yang lebih baik. Throughput yang lebih baik ini adalah hampir bisa dipastikan ke perangkat keras lebih cepat pada Solaris platform.

Posix message queues no load

Posted by : EFENDI (23060161)

Referensi :  The Use of Posix in real time Systems, Assessing its
Effectiveness and Performance

Saat ini kesalahan-kesalahan yang bersifat tipikal seperti integer overflow, buffer overflow bisa diatasi dengan menggunakan testing software yang mana mampu mengidentifikasi sebagian besar bug yang terjadi tanpa harus melakukan testing satu persatu dan memakan waktu yang sangat lama.

Seperti yang dilakukan SEARCH laboratory, mereka mengunakan framework Flinder untuk mendeteksi error tipikal yang terjadi secara efisien dan cepat. SEARCH Laboratory melakukan test pada implementasi Linux-based TSS(TCG Software Stack). TSS merupakan multi-layer dengan menyediakan akses ke TPM(Trusted Platform Module). Aplikasi tersebut dijalankan dengan mengoperasikan sistem dengan menggunakan layer yang berbeda.

Gambar TCG Software Stack

Pendekatan yang dilakukan meliputi:

Testing, hasil evaluasi berupa benar atau tidaknya suatu operasi dijalankan, didapatkan dari observasi

Static source code analysis, suatu analisis yang dilakukan pada source code untuk menemukan kelemahan atau kesalahan-kesalahan pemrograman

Formal reasoning, yaitu secara otomatis menambahkan metode matematis untuk mengetahui jalan program sudah sesuai atau belum

Untuk testing sendiri, mereka melakukan dengan White-box testing dan juga black-box testing yang masing-masing test memiliki skenario sendiri-sendiri. Hasil dari testing tersebut dapat dilihat pada tabel berikut:

Posted by: I Wayan Sudiana (23060141)

referensi:
http://www.mit.bme.hu/~tgm/publikaciok/2008/eurosec2008/EUROSEC2008-TCP-CaseStudy.pdf

Testing pada ARTISt

Testing pada ARTISt dibagi dalam beberapa kelas, kemudian masing-masing kelas dijabarkan lagi ke dalam unit-unit testing yang lebih spesifik. Kelima kelas tersebut antara lain:

-         Installation

Menguji/cek ulang hasil installasi

-         Enviroment

Menguji apakah konektivitas sistem dengan komponen luar (terutama hardware) berjalan dengan baik.

-         Functionality

Menguji kapabilitas sistem (fungsi-fungsi dan perhitungan-perhitungan teknis), apakah sudah sesuai requirement.

-         Robutstness and Degraded Mode

Menguji sistem jika berada pada kondisi yang tidak semestinya, seperti mendapatkan input yang salah.

-         Test Under Load

Menguji perfoma sistem dalam kaitannya dengan waktu (real time)

Daftar Isi Dokumentasi Testing

Karena testing sistem bergantung pada input data yang diperoleh, sementara testing tidak mungkin dijalankan pada kondisi tes penerbangan, maka untuk menjalani tahap testing dibutuhkan data simulasi. Untuk itu, data simulasi diperoleh melalui modul PCM Simulator yang memberikan data nyata hasil tes penerbangan. PCM Simulator merupakan modul yang berdiri sendiri yang akan digunakan sebagai driver untuk unit testing lainnya.

Masing-masing kelas dibagi lagi dalam unit testing yang lebih detail beserta tujuan, persiapan, dan prosedur tes yang didokumentasi lengkap. Pada keadaan nyata, testing yang dilakukan benar-benar dijalankan dan didokumentasikan secara detail dan terstruktur untuk menjamin semua bagian sistem nantinya bisa berjalan sesuai yang diharapkan.

Salah Satu Test Case dalam ARTISt

Test Result

Referensi: Dokumentasi Pengujian (Testing)

Download  Dokumentasi Software Test Report

Posted by: Heryno (23060169)

Benchmark 1 – Boot Time
Waktu windows booting setelah AV di install, dengan masing-masing produk diulang rata-rata 15 kali.

Benchmark 2 – Kecepatan Scan
Waktu scan, dengan jumlah 6159 file, total 982 MB. Sebagian dari file sistem windows dan lainnya dari file-file office, image, dan lainnya.

Benchmark 3 – Kecepatan Tampilnya Antarmuka
Waktu diukur baik dengan software maupun dengan manual (dengan stop watch)

Benchmark 4 – Penggunaan Memory
Setelah komputer booting maka penggunaan memory di ukur, setiap 5 menit sampai 15 kali pengukuran. Software yang digunakan adalah Sysinternals Process Explorer.

Benchmark 5 – Kecepatan Loading Internet Explorer (IE)
Mengukur seberapa besar efek antivirus/produk dengan kecepatan loading IE.

Benchmark 6 – Waktu Instalasi
Mulai dari awal proses sampai produk siap digunakan. Sehingga mencakup Extraction dan Setup, Copy File dan Post Installasi.

Benchmark 7 – Ukuran File Installasi
Mengukur penggunaan space di hardisk.

Benchmark 8 – Jumlah Key di Registry
Tiap antivirus yang sudah di install, biasanya akan menambahkan key di registry, dan tahap ini akan menghitung jumlah total key yang di buat setelah antivirus di install.

Benchmark 9 – Performa Real Time
Test ini meliputi seberapa cepat proses Copy, Move dan Delete file ketika antivirus sudah terinstall di komputer. Dengan jumlah sample 812, total 760,867,636 bytes.

Benchmark 10 – Installasi program lain (pihak ketiga)
Test ini mengukur seberapa lama ketika antivirus sudah terinstall dan digunakan untuk menginstall dan uninstall program lainnya. Digunakan sample Microsoft .NET Framework 2.0 (*.msi).

Benchmark 11 – Download file Binary
Waktu yang diperlukan untuk download file binary dari internet ( media dan dokumen), total sekitar 550 MB.

Benchmark 12 – Konversi format File
Waktu untuk mengkonversi audio dari MP3 > WAV dan MP3 > WMA.

Benchmark 13 – Kompresi dan Dekompresi File
Waktu yang diperlukan program 7Zip untuk membuat arsip file zip dan dekompresi zip tersebut. Total 404 file dengan ukuran 277 MB meliputi dokumen dan media.

Benchmark 14 – Menulis file, membuka dan Close
Proses ini melakukan test Input/Output (I/O), dengan software OpenClose.exe yang melakukan proses baca tulis file di hardisk.

Adapun hasil Antivirus yang sudah diuji :

Semakin kecil nilai semakin lebih baik.

Kecepatan Scan

Penggunaan Memory (RAM)

Waktu membuka IE (Internet Explorer)

Jumlah Key di Registry

Proses Write, Open Dan Close File

Hasil keseluruhan test :

Posted by : Lea Erita (23060121)

Referensi : Antivirus 2009 Perfomance Testing