Berita PCB - Mencari Kesalahan Perisian dalam Proses Projek PCB

Artikel ini akan memperkenalkan bagaimana untuk mengelakkan ralat tersembunyi tetapi biasa, dan memperkenalkan beberapa teknik untuk membantu jurutera mencari ralat tersembunyi dalam perisian salinan PCB. Kebanyakan projek pembangunan perisian bergantung pada kombinasi pemeriksaan kod, ujian struktur, dan ujian fungsi untuk mengenalpasti cacat perisian. Walaupun teknik tradisional ini sangat penting dan dapat mencari kebanyakan masalah perisian, ia tidak dapat mengesan banyak ralat umum dalam sistem kompleks hari ini.

Ujian struktur atau ujian kotak putih boleh mencari logik, aliran kawalan, kiraan dan ralat data dalam kod. Ujian ini memerlukan paparan ringkasan lengkap tentang kerja dalaman perisian (oleh itu term a "kotak putih" atau "kotak kaca") untuk memahami perincian struktur perisian. Ia memeriksa setiap ungkapan syarat, operasi matematik, input dan output. Kerana banyak perincian yang perlu diuji, ujian struktur memeriksa satu unit perisian pada masa, biasanya fungsi atau kelas. Revisi kod juga menggunakan teknik kompleks yang sama dengan kekurangan pelaksanaan dan masalah potensi untuk ditemui. Seperti ujian kotak putih, ulasan biasanya dilakukan untuk setiap unit perisian, kerana proses ulasan yang berkesan memerlukan pemeriksaan pusat dan terperinci. Berbeza dari ujian ulasan dan kotak putih, ujian fungsi atau ujian kotak hitam menganggap tiada apa yang diketahui tentang pelaksanaan perisian. Ia menguji output dipandu oleh input terkawal. Ujian fungsional terdiri daripada prosedur ujian ditulis oleh penguji atau pembangun, yang menyatakan output program dijangka yang sepadan dengan set input program khusus. Selepas ujian dijalankan, pengujian membandingkan output sebenar dengan output dijangka untuk mencari masalah. Ujian kotak hitam dapat mencari keperluan yang tidak dipenuhi, masalah antaramuka, masalah prestasi, dan ralat dalam fungsi yang paling biasa digunakan program. Walaupun menggabungkan teknologi ini dapat mencari kebanyakan ralat tersembunyi dalam program perisian tertentu, mereka juga mempunyai keterangan. Revisi kod dan ujian kotak putih hanya sasarkan sebahagian kecil kod pada satu masa, mengabaikan sisa sistem. Ujian kotak hitam biasanya menjaga sistem sebagai keseluruhan, mengabaikan perincian pelaksanaan. Beberapa masalah penting hanya boleh ditemui dengan fokus pada perincian interaksi mereka di seluruh sistem; kaedah tradisional tidak dapat mengenalpasti masalah ini dengan pasti. Sistem perisian mesti disemak sebagai keseluruhan untuk mencari sebab khusus masalah khusus. Kerana biasanya mustahil untuk menganalisis secara teliti setiap perincian dalam program dan interaksinya dengan semua bahagian lain kod, analisis patut ditujukan pada aspek khusus program yang diketahui untuk menyebabkan masalah. Artikel ini akan mengeksplorasi tiga kawasan masalah potensi:* stack overflow* Persyaratan ras* deadlock Readers boleh baca bahagian kedua artikel ini online, yang akan mengeksplorasi isu-isu berikut:* Persyaratan masa* Persyaratan kembali Semua masalah di atas agak umum dalam sistem yang menggunakan teknologi desain masa-realiti berbilang-tugas. stack overflow The processor uses the stack to store temporary variables, pass parameters to the called function, save the thread "state", etc. If the system does not use virtual memory (in other words, it cannot transfer memory pages to disk to free up memory space for other uses), the stack will be fixed at the size of the product when it leaves the factory. Jika untuk sebab tertentu tumpukan keluar dari julat yang diberikan oleh pemrogram, program akan menjadi tidak pasti. Keketidakstabilan ini boleh menyebabkan kegagalan sistem serius. Oleh itu, ia adalah penting untuk memastikan bahawa sistem boleh memisahkan cukup tumpukan dalam kes terburuk. Satu-satunya cara untuk memastikan aliran tumpukan tidak pernah berlaku adalah untuk menganalisis kod, menentukan penggunaan tumpukan maksimum program di bawah berbagai syarat yang mungkin, dan kemudian semak sama ada tumpukan cukup dialokasi. Ujian tidak mungkin akan memicu kombinasi khusus input segera dan menyebabkan skenario kes terburuk dalam sistem. Konsep analisis kedalaman tumpukan adalah relatif mudah: 1. Cipta pepohon panggilan untuk setiap benang independen. 2. Tentukan penggunaan tumpukan setiap fungsi dalam pokok panggilan.3. Semak setiap pokok panggilan untuk menentukan laluan panggilan mana dari punca pokok ke "daun" luaran yang diperlukan yang paling tumpukan. 4. Tambah penggunaan stack maksimum bagi setiap pepohon panggilan benang independen. 5. Tentukan penggunaan stack maksimum setiap rutin perkhidmatan gangguan (ISR) dalam setiap aras keutamaan gangguan dan kira jumlah. Namun, jika ISR sendiri tidak mempunyai tumpukan dan menggunakan tumpukan benang terganggu, bilangan maksimum tumpukan yang digunakan oleh ISR patut ditambah ke tumpukan setiap benang.6. Untuk setiap aras keutamaan, tambah bilangan tumpuan yang digunakan untuk menyimpan keadaan pemproses bila gangguan berlaku.7. Jika anda menggunakan RTOS, tambah bilangan maksimum tumpuan yang diperlukan untuk penggunaan dalaman RTOS sendiri (berbeza dari panggilan sistem disebabkan oleh kod aplikasi, yang termasuk dalam langkah 2). Selain itu, ada dua perkara penting untuk dipertimbangkan. Pertama, pepohon panggilan dibina hanya dari kod sumber bahasa tahap tinggi mungkin tidak lengkap. Kebanyakan kompiler menggunakan perpustakaan-masa berjalan untuk optimumkan tugas komputer umum, seperti pendaraban dan pembahagian integer-nilai-besar, operasi titik-mengapung, dll. Panggilan ini hanya terlihat dalam bahasa kumpulan yang dijana oleh kompiler. Fungsi perpustakaan masa berjalan sendiri mungkin menggunakan banyak ruang tumpukan, dan mereka mesti disertai dalam analisis. Jika anda menggunakan bahasa C++, semua jenis fungsi (kaedah) berikut juga mesti disertai dalam pokok panggilan: strukturer, pemusnah, operator yang dimuatkan berlebihan, struktur salin, dan fungsi konversi. Semua penunjuk fungsi juga mesti dihurai, dan fungsi yang mereka panggil termasuk dalam analisis.