Bagikan melalui

Tes Windows App Certification Kit

  • Artikel

Di bawah ini adalah detail pengujian untuk mensertifikasi aplikasi desktop. Untuk informasi, silakan merujuk ke Menggunakan Kit Sertifikasi Aplikasi Windows.

Bersihkan penginstalan yang dapat dibalik

Menginstal dan menghapus instalan aplikasi dan memeriksa file residu dan entri registri.

  • Latar belakang
    • Penginstalan yang bersih dan dapat dibalik memungkinkan pengguna untuk menyebarkan dan menghapus aplikasi. Untuk lulus pengujian ini, aplikasi harus melakukan hal berikut:
      • Aplikasi tidak memaksa sistem untuk memulai ulang segera setelah menginstal atau menghapus instalan aplikasi. Proses penginstalan atau penghapusan instalasi aplikasi seharusnya tidak memerlukan hidupkan ulang sistem tepat setelah selesai. Jika ini mengharuskan sistem dimulai ulang, pengguna harus dapat menghidupkan ulang sistem dengan nyaman.
      • Aplikasi ini tidak bergantung pada 8.3 nama file pendek (SFN). Proses penginstalan dan penghapusan instalasi aplikasi harus dapat menggunakan nama file dan jalur folder yang panjang.
      • Aplikasi tidak memblokir penginstalan/penghapusan instalasi senyap
      • Aplikasi ini membuat entri yang diperlukan dalam registri sistem. Alat inventori Windows dan alat telemetri memerlukan info lengkap tentang aplikasi yang diinstal. Penginstal aplikasi harus membuat entri registri yang benar untuk memungkinkan deteksi dan penghapusan instalasi yang berhasil.
    • Jika Anda menggunakan alat penginstal berbasis MSI, MSI secara otomatis membuat entri registri di bawah ini. Jika Anda tidak menggunakan penginstal MSI, modul penginstalan harus membuat entri registri berikut selama penginstalan:
      • DisplayName
      • InstallLocation
      • Publisher
      • UninstallString
      • VersionMajor atau MajorVersion
      • VersionMinor atau MinorVersion
    • Aplikasi harus menghapus semua entrinya di Tambahkan/Hapus Program.
  • Detail pengujian
    • Pengujian ini memeriksa proses penginstalan dan penghapusan instalasi aplikasi untuk perilaku yang diperlukan.
  • Tindakan Korektif
    • Tinjau desain dan perilaku aplikasi terhadap persyaratan yang dijelaskan di atas.

Menginstal ke pengujian folder yang benar

Memverifikasi bahwa aplikasi menulis program dan file datanya ke folder yang benar.

  • Latar belakang
    • Aplikasi harus menggunakan sistem pengguna dan folder per pengguna dengan benar sehingga dapat mengakses data dan pengaturan yang dibutuhkan sambil melindungi data dan pengaturan pengguna dari akses yang tidak sah.
  • Folder File Program
    • Aplikasi harus diinstal di folder File Program secara default (%ProgramFiles% untuk aplikasi 32-bit dan 64-bit asli, dan %ProgramFiles(x86)% untuk aplikasi 32-bit yang berjalan di x64).
    • Catatan: Aplikasi tidak boleh menyimpan data pengguna atau data aplikasi di folder File Program karena izin keamanan yang dikonfigurasi untuk folder ini.
    • ACL pada folder sistem Windows hanya mengizinkan akun administrator untuk membaca dan menulis kepada mereka. Akibatnya, akun pengguna standar tidak akan memiliki akses ke folder ini. Namun, virtualisasi file memungkinkan aplikasi menyimpan file, seperti file konfigurasi, di lokasi sistem yang biasanya hanya dapat ditulis oleh administrator. Menjalankan program sebagai pengguna standar dalam situasi ini dapat mengakibatkan kegagalan jika mereka tidak dapat mengakses file yang diperlukan.
    • Aplikasi harus menggunakan Folder Yang Diketahui untuk memastikan mereka akan dapat mengakses data mereka.
    • Catatan: Windows menyediakan virtualisasi file untuk meningkatkan kompatibilitas aplikasi dan menghilangkan masalah saat aplikasi berjalan sebagai pengguna standar di Windows. Aplikasi Anda tidak boleh mengandalkan virtualisasi yang ada di versi Windows yang akan datang.
  • Folder data aplikasi khusus pengguna
    • Dalam penginstalan "per mesin", aplikasi tidak boleh menulis data khusus pengguna selama penginstalan. Data penginstalan khusus pengguna hanya boleh ditulis saat pengguna memulai aplikasi untuk pertama kalinya. Ini karena tidak ada lokasi pengguna yang benar untuk menyimpan data pada saat penginstalan. Upaya oleh aplikasi untuk memodifikasi perilaku asosiasi default di tingkat komputer setelah penginstalan tidak akan berhasil. Sebaliknya, default harus diklaim pada tingkat per pengguna, yang mencegah beberapa pengguna menimpa default satu sama lain.
    • Semua data aplikasi eksklusif untuk pengguna tertentu dan tidak dibagikan dengan pengguna lain komputer harus disimpan di Users\<username>\AppData.
    • Semua data aplikasi yang harus dibagikan di antara pengguna di komputer harus disimpan dalam ProgramData.
  • Folder sistem dan kunci registri lainnya
    • Aplikasi tidak boleh menulis langsung ke direktori Windows dan atau subdirektori. Gunakan metode yang benar untuk menginstal file, seperti font atau driver, ke direktori ini.
    • Aplikasi tidak boleh dimulai secara otomatis saat startup, seperti dengan menambahkan entri ke satu atau beberapa lokasi ini:
      • Registri menjalankan kunci HKLM dan, atau HKCU di bawah Software\Microsoft\Windows\CurrentVersion
      • Registri menjalankan kunci HKLM, dan atau HKCU di bawah Software\Wow6432Node\Microsoft\windows\CurrentVersion
      • Start Menu AllPrograms > STARTUP
  • Detail pengujian
    • Pengujian ini memverifikasi bahwa aplikasi menggunakan lokasi tertentu dalam sistem file yang disediakan Windows untuk menyimpan program dan komponen perangkat lunak, data aplikasi bersama, dan data aplikasi yang khusus untuk pengguna.
  • Tindakan korektif
    • Tinjau bagaimana aplikasi menggunakan folder sistem dan pastikan aplikasi menggunakannya dengan benar.
  • Pengecualian dan Keringanan
    • Pengabaian diperlukan untuk aplikasi desktop yang menulis ke cache perakitan global (GAC) (aplikasi.NET harus menjaga dependensi rakitan tetap privat, dan menyimpannya di direktori aplikasi kecuali berbagi rakitan diperlukan secara eksplisit).
    • Penginstalan ke folder File Program bukanlah persyaratan untuk paket Desktop SW untuk mencapai Logo SW, hanya di bawah kategori Dasar-Dasar SW.

Pengujian file yang ditandatangani secara digital

Menguji file yang dapat dieksekusi dan driver perangkat untuk memverifikasi bahwa mereka memiliki tanda tangan digital yang valid.

  • Latar belakang
    • File yang ditandatangani secara digital memungkinkan untuk memverifikasi bahwa file asli dan untuk mendeteksi apakah file telah dirusak.
    • Penerapan penandatanganan kode mode kernel adalah fitur Windows yang juga dikenal sebagai integritas kode (CI). CI meningkatkan keamanan Windows dengan memverifikasi integritas file setiap kali dimuat ke dalam memori. CI mendeteksi apakah kode berbahaya telah memodifikasi file biner sistem dan menghasilkan peristiwa log diagnostik dan audit sistem ketika tanda tangan modul kernel gagal diverifikasi dengan benar.
    • Jika aplikasi memerlukan izin yang ditingkatkan, permintaan elevasi menampilkan info kontekstual tentang file yang dapat dieksekusi yang meminta akses yang ditingkatkan. Bergantung pada apakah aplikasi ditandatangani Authenticode, pengguna mungkin melihat permintaan persetujuan atau permintaan kredensial.
    • Nama yang kuat mencegah pihak ketiga melakukan spoofing kode Anda, selama Anda menjaga keamanan kunci privat. .NET Framework memverifikasi tanda tangan digital baik saat memuat rakitan atau menginstalnya di GAC. Tanpa akses ke kunci privat, pengguna berbahaya tidak dapat mengubah kode Anda dan menandatanganinya lagi.
  • Detail pengujian
    • Semua file yang dapat dieksekusi, seperti yang memiliki ekstensi file .exe, .dll, .ocx, .sys, .cpl, .drv, dan .scr, harus ditandatangani dengan sertifikat Authenticode.
    • Semua driver mode kernel yang diinstal oleh aplikasi harus memiliki tanda tangan Microsoft yang diperoleh melalui program WHQL atau DRS. Semua driver filter sistem file harus ditandatangani WHQL.
  • Tindakan Korektif
    • Tanda tangani file yang dapat dieksekusi aplikasi.
    • Gunakan makecert.exe untuk menghasilkan sertifikat atau mendapatkan kunci penandatanganan kode dari salah satu otoritas sertifikasi komersial (CA), seperti VeriSign, Thawte, atau Ca Microsoft.
  • Pengecualian dan keringanan
    • Keringanan hanya akan dianggap untuk distribusi ulang pihak ketiga yang tidak ditandatangani. Bukti komunikasi yang meminta versi yang ditandatangani dari redistributable diperlukan agar pengabaian ini diberikan.
    • Paket perangkat lunak bernilai tambah perangkat dikecualikan dari sertifikasi driver mode kernel, karena driver harus disertifikasi oleh Sertifikasi Perangkat Keras Windows.

Mendukung pengujian Windows x64

Uji aplikasi untuk memastikan .exe dibangun untuk arsitektur platform tempat aplikasi akan diinstal.

  • Latar belakang
    • File yang dapat dieksekusi harus dibangun untuk arsitektur prosesor tempat file diinstal. Beberapa file yang dapat dieksekusi mungkin berjalan pada arsitektur prosesor yang berbeda, tetapi ini tidak dapat diandalkan.
    • Kompatibilitas arsitektur penting karena proses 32-bit tidak dapat memuat DLL 64-bit dan proses 64-bit tidak dapat memuat DLL 32-bit. Demikian juga, Windows versi 64-bit tidak mendukung menjalankan aplikasi berbasis Windows 16-bit karena handel memiliki 32 bit signifikan pada Windows 64-bit sehingga tidak dapat diteruskan ke aplikasi 16-bit. Oleh karena itu, mencoba meluncurkan aplikasi 16-bit akan gagal pada Windows versi 64-bit.
    • Driver perangkat 32-bit tidak dapat berjalan pada Windows versi 64-bit dan oleh karena itu, mereka harus di-port ke arsitektur 64-bit.
    • Untuk aplikasi mode pengguna, Windows 64-bit mencakup WOW64, yang memungkinkan aplikasi Windows 32-bit untuk dijalankan pada sistem yang menjalankan Windows 64-bit, meskipun dengan beberapa kehilangan performa. Tidak ada lapisan terjemahan yang setara untuk driver perangkat.
    • Untuk mempertahankan kompatibilitas dengan Windows versi 64-bit, aplikasi harus secara asli mendukung aplikasi berbasis Windows 64-bit atau, minimal 32-bit harus berjalan dengan mulus pada sistem 64-bit:
      • Aplikasi dan penginstalnya tidak boleh berisi kode 16-bit atau mengandalkan komponen 16-bit apa pun.
      • Penyetelan aplikasi harus mendeteksi dan menginstal driver dan komponen yang tepat pada Windows versi 64-bit.
      • Plug-in shell apa pun harus berjalan pada Windows versi 64-bit.
      • Aplikasi yang berjalan di bawah emulator WoW64 tidak boleh mencoba melewati mekanisme virtualisasi Wow64. Jika ada skenario khusus di mana aplikasi perlu mendeteksi apakah aplikasi berjalan di emulator WoW64, aplikasi harus melakukannya dengan memanggil IsWow64Process.
  • Detail pengujian
    • Aplikasi tidak boleh menginstal biner 16-bit apa pun. Aplikasi tidak boleh menginstal driver mode kernel 32-bit jika seharusnya berjalan pada komputer 64-bit.
  • Tindakan Korektif
    • Buat file dan driver yang dapat dieksekusi untuk arsitektur prosesor yang ingin Anda instal.

Pengujian pemeriksaan versi OS

Menguji bagaimana aplikasi memeriksa versi Windows tempat aplikasi berjalan.

  • Latar belakang
    • Aplikasi memeriksa versi OS dengan menguji versi yang lebih besar dari atau sama dengan versi yang diperlukan untuk memastikan kompatibilitas dengan versi Windows di masa mendatang.
  • Detail pengujian
    • Mensimulasikan menjalankan aplikasi pada versi Windows yang berbeda untuk melihat bagaimana reaksinya.
  • Tindakan korektif
    • Uji versi Windows yang benar dengan menguji apakah versi saat ini lebih besar dari atau sama dengan versi yang dibutuhkan aplikasi, layanan, atau driver Anda.
    • Penginstal driver dan modul penghapusan instalan tidak boleh pernah memeriksa versi OS.
  • Pengecualian dan Keringanan
    • Keringanan akan dipertimbangkan untuk aplikasi yang memenuhi kriteria berikut: (Hanya berlaku untuk sertifikasi aplikasi desktop)
      • Aplikasi yang dikirimkan sebagai satu paket yang berjalan pada Windows XP, Windows Vista, dan Windows 7 dan perlu memeriksa versi OS untuk menentukan komponen mana yang akan diinstal pada sistem operasi tertentu.
      • Aplikasi yang hanya memeriksa versi minimum OS (selama penginstalan saja, bukan saat runtime) dengan hanya menggunakan panggilan API yang disetujui dan mencantumkan persyaratan versi minimum dalam manifes aplikasi sesuai kebutuhan.
      • Aplikasi keamanan seperti aplikasi antivirus dan firewall, utilitas sistem seperti utilitas defrag dan aplikasi cadangan, dan alat diagnostik yang memeriksa versi OS hanya dengan menggunakan panggilan API yang disetujui.

Uji kontrol akun pengguna (UAC)

Menguji aplikasi untuk memverifikasi bahwa aplikasi tidak memerlukan izin yang tidak perlu ditingkatkan untuk dijalankan.

  • Latar belakang
    • Aplikasi yang beroperasi atau diinstal hanya ketika pengguna adalah administrator memaksa pengguna untuk menjalankan aplikasi dengan izin yang tidak perlu ditinggikan, yang dapat memungkinkan malware memasuki komputer pengguna.
    • Ketika pengguna selalu dipaksa untuk menjalankan aplikasi dengan token akses yang ditinggikan, aplikasi dapat server sebagai titik masuk untuk menipu atau kode berbahaya. Malware ini dapat dengan mudah memodifikasi sistem operasi, atau lebih buruk, memengaruhi pengguna lain. Hampir tidak mungkin untuk mengontrol pengguna yang memiliki akses administrator penuh, karena Administrator dapat menginstal aplikasi dan menjalankan aplikasi atau skrip apa pun di komputer. Manajer TI selalu mencari cara untuk membuat "desktop standar" di mana pengguna masuk sebagai pengguna standar. Desktop standar sangat mengurangi biaya meja bantuan dan mengurangi overhead TI.
    • Sebagian besar aplikasi tidak memerlukan hak istimewa administrator pada waktu proses. Akun pengguna standar harus dapat menjalankannya. Aplikasi Windows harus memiliki manifes (disematkan atau eksternal) untuk menentukan tingkat eksekusinya yang memberi tahu OS hak istimewa yang diperlukan untuk menjalankan aplikasi. Manifes aplikasi hanya berlaku untuk file .exe, bukan file .dll. Kontrol Akun Pengguna (UAC) tidak memeriksa DLL selama pembuatan proses. Aturan UAC tidak berlaku untuk layanan Microsoft. Manifes aplikasi dapat disematkan atau eksternal.
    • Untuk membuat manifes, buat file dengan nama <app_name.exe.manifest> dan simpan di direktori yang sama dengan EXE. Perhatikan bahwa manifes eksternal diabaikan jika aplikasi memiliki manifes internal.
      • Misalnya, <requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>
      • Proses utama aplikasi harus dijalankan sebagai pengguna standar (asInvoker). Setiap fitur administratif harus dipindahkan ke dalam proses terpisah yang berjalan dengan hak istimewa administratif.
      • Aplikasi yang menghadap pengguna yang memerlukan hak istimewa yang ditingkatkan harus ditandatangani Authenticode.
  • Detail pengujian
    • Semua exes yang dihadapi pengguna harus ditandai dengan atribut asInvoker. Jika ditandai sebagai highestAvailable atau requireAdministrator maka mereka harus ditandatangani authenticode dengan benar. Setiap exe aplikasi tidak boleh memiliki atribut uiAccess yang diatur ke true. Setiap exe yang berjalan sebagai layanan dikecualikan dari pemeriksaan khusus ini.
  • Tindakan korektif
    • Tinjau file manifes aplikasi untuk entri dan tingkat izin yang benar.
  • Pengecualian dan keringanan
    • Pengabaian diperlukan untuk aplikasi yang menjalankan proses utamanya dengan hak istimewa yang ditinggikan (requireAdministrator atau highestAvailable). Proses utamanya adalah proses yang menyediakan titik masuk pengguna ke aplikasi.
    • Keringanan akan dipertimbangkan untuk skenario berikut:
      • Alat administratif atau sistem dengan tingkat eksekusi diatur ke highestAvailable, requireAdministrator, atau keduanya.
      • Hanya aksesibilitas atau aplikasi kerangka kerja otomatisasi UI yang mengatur bendera uiAccess ke TRUE untuk melewati isolasi hak istimewa antarmuka pengguna (UIPI). Untuk memulai pemanfaatan aplikasi dengan benar, bendera ini harus ditandatangani Authenticode, dan harus berada di lokasi yang dilindungi dalam sistem file, seperti File Program.

Mematuhi pesan manajer hidupkan ulang sistem

Menguji bagaimana aplikasi merespons penonaktifan sistem dan memulai ulang pesan.

  • Latar belakang
    • Aplikasi harus keluar secepat mungkin ketika diberi tahu bahwa sistem dimatikan untuk memberikan pengalaman matikan atau matikan responsif bagi pengguna.
    • Dalam pematian kritis, aplikasi yang mengembalikan FALSE ke WM_QUERYENDSESSION akan dikirim WM_ENDSESSION dan ditutup, sementara waktu tersebut habis sebagai respons terhadap WM_QUERYENDSESSION akan dihentikan secara paksa.
  • Detail pengujian
    • Memeriksa bagaimana aplikasi merespons mematikan dan keluar dari pesan.
  • Tindakan korektif
    • Jika aplikasi Anda gagal dalam pengujian ini, tinjau caranya menangani pesan Windows ini:
      • WM_QUERYENDSESSION dengan LPARAM = ENDSESSION_CLOSEAPP(0x1): Aplikasi desktop harus segera merespons (TRUE) sebagai persiapan untuk memulai ulang. Aplikasi konsol dapat memanggil SetConsoleCtrlHandler untuk menerima pemberitahuan matikan. Layanan dapat memanggil RegisterServiceCtrlHandlerEx untuk menerima pemberitahuan matikan dalam rutinitas handler.
      • WM_ENDSESSION dengan ENDSESSION_CLOSEAPP LPARAM = (0x1): Aplikasi harus mengembalikan nilai 0 dalam waktu 30 detik dan dimatikan. Minimal, aplikasi harus mempersiapkan dengan menyimpan data pengguna apa pun dan menyatakan info yang diperlukan setelah menghidupkan ulang.
    • Aplikasi konsol yang menerima pemberitahuan CTRL_C_EVENT harus segera dimatikan. Driver tidak boleh mem-veto kejadian pematian sistem.
    • Catatan: Aplikasi yang harus memblokir penonaktifan karena operasi yang tidak dapat diganggu harus menggunakan ShutdownBlockReasonCreate untuk mendaftarkan string yang menjelaskan alasannya kepada pengguna. Setelah operasi selesai, aplikasi harus memanggil ShutdownBlockReasonDestroy untuk menunjukkan bahwa sistem dapat dimatikan.

pengujian mode Brankas

Menguji apakah driver atau layanan dikonfigurasi untuk memulai dalam mode aman.

  • Latar belakang
    • mode Brankas memungkinkan pengguna untuk mendiagnosis dan memecahkan masalah dengan Windows. Hanya driver dan layanan yang diperlukan untuk pengoperasian dasar sistem operasi atau menyediakan layanan diagnostik dan pemulihan yang harus dimuat dalam mode aman. Memuat file lain dalam mode aman membuatnya lebih sulit untuk memecahkan masalah dengan sistem operasi.
    • Secara default, hanya driver dan layanan yang telah diinstal sebelumnya dengan Windows yang dimulai dalam mode aman. Semua driver dan layanan lain harus dinonaktifkan kecuali sistem memerlukannya untuk operasi dasar atau untuk tujuan diagnostik dan pemulihan.
  • Detail pengujian
    • Driver yang diinstal oleh aplikasi tidak boleh ditandai untuk memuat dalam mode aman.
  • Tindakan korektif
    • Jika driver atau layanan tidak boleh dimulai dalam mode aman, hapus entri aplikasi dari kunci registri.
  • Pengecualian dan keringanan
    • Driver dan layanan yang harus dimulai dalam mode aman memerlukan pengabaian untuk disertifikasi. Permintaan pengabaian harus mencakup setiap driver dan layanan untuk ditambahkan ke kunci registri Brankas Boot dan menjelaskan alasan teknis mengapa driver atau layanan harus berjalan dalam mode aman. Alat penginstal aplikasi harus mendaftarkan semua driver dan layanan tersebut dalam kunci registri ini:
      • HKLM/System/CurrentControlSet/Control/Brankas Boot/Minimal
      • HKLM/System/CurrentControlSet/Control/Brankas Boot/Network
  • Catatan: Anda harus menguji driver dan layanan yang ingin Anda mulai dalam mode aman untuk memastikan bahwa mereka berfungsi dalam mode aman tanpa kesalahan apa pun.

Tes sesi multipengguna

Uji bagaimana aplikasi berperilaku saat dijalankan dalam beberapa sesi secara bersamaan.

  • Latar belakang
    • Pengguna Windows harus dapat menjalankan sesi bersamaan. Aplikasi harus memastikan bahwa saat dijalankan dalam beberapa sesi, baik secara lokal atau jarak jauh, fungsionalitas normal aplikasi tidak terpengaruh secara merugikan. Pengaturan aplikasi dan file data harus spesifik pengguna dan privasi dan preferensi pengguna harus dibatasi untuk sesi pengguna.
  • Detail pengujian
    • Menjalankan beberapa instans bersamaan aplikasi untuk menguji hal berikut:
      • Beberapa instans aplikasi yang berjalan pada saat yang sama diisolasi satu sama lain.
    • Ini berarti bahwa data pengguna dari satu instans tidak terlihat oleh instans lain. Suara dalam sesi pengguna yang tidak aktif tidak boleh didengar dalam sesi pengguna aktif. Dalam kasus di mana beberapa instans aplikasi menggunakan sumber daya bersama, aplikasi harus memastikan bahwa tidak ada konflik.
      • Jika aplikasi diinstal untuk beberapa pengguna, aplikasi menyimpan data di folder dan lokasi registri yang benar.
      • Aplikasi ini dapat berjalan dalam beberapa sesi pengguna (Peralihan Pengguna Cepat) untuk akses lokal dan jarak jauh.
    • Untuk memastikan hal ini, aplikasi harus memeriksa sesi layanan terminal (TS) lain untuk instans aplikasi yang ada. Jika aplikasi tidak mendukung beberapa sesi pengguna atau akses jarak jauh, aplikasi harus dengan jelas mengatakan ini kepada pengguna saat diluncurkan dari sesi seperti itu.
  • Tindakan korektif
    • Pastikan aplikasi tidak menyimpan file atau pengaturan data di seluruh sistem di penyimpanan data khusus pengguna, seperti Profil Pengguna atau HKCU. Jika ya, info tersebut tidak akan tersedia untuk pengguna lain.
    • Aplikasi Anda harus menginstal konfigurasi di seluruh sistem dan file data selama penginstalan dan membuat file dan pengaturan khusus pengguna setelah penginstalan saat pengguna menjalankannya.
    • Pastikan bahwa aplikasi tidak memblokir beberapa sesi bersamaan, baik secara lokal atau jarak jauh. Aplikasi tidak boleh bergantung pada mutex global atau objek bernama lainnya untuk memeriksa atau memblokir beberapa sesi bersamaan.
    • Jika aplikasi tidak dapat mengizinkan beberapa sesi bersamaan per pengguna, gunakan namespace layanan per pengguna atau per sesi untuk mutex dan objek bernama lainnya.

Crash dan tes macet

Memantau aplikasi selama pengujian sertifikasi untuk merekam saat crash atau macet.

  • Latar belakang
    • Kegagalan aplikasi seperti crash dan hang adalah gangguan besar bagi pengguna dan menyebabkan frustrasi. Menghilangkan kegagalan tersebut meningkatkan stabilitas dan keandalan aplikasi, dan secara keseluruhan, memberi pengguna pengalaman aplikasi yang lebih baik. Aplikasi yang berhenti merespons atau crash dapat menyebabkan pengguna kehilangan data dan memiliki pengalaman yang buruk.
  • Detail pengujian
    • Kami menguji ketahanan dan stabilitas aplikasi selama pengujian sertifikasi.
    • Kit Sertifikasi Aplikasi Windows memanggil IApplicationActivationManager::ActivateApplication untuk meluncurkan aplikasi Windows Store. Agar ActivateApplication meluncurkan aplikasi, Kontrol Akun Pengguna (UAC) harus diaktifkan dan resolusi layar harus minimal 1024 x 768 atau 768 x 1024. Jika salah satu kondisi tidak terpenuhi, aplikasi Anda akan gagal dalam pengujian ini.
  • Tindakan Korektif
    • Pastikan UAC diaktifkan pada komputer pengujian.
    • Pastikan Anda menjalankan pengujian pada komputer dengan layar yang cukup besar.
    • Jika aplikasi Anda gagal diluncurkan dan platform pengujian Anda memenuhi prasyarat ActivateApplication, Anda dapat memecahkan masalah dengan meninjau log peristiwa aktivasi. Untuk menemukan entri ini di log peristiwa:
      1. Buka eventvwr.exe dan navigasikan ke node \Windows Logs\Application.
      2. Filter tampilan untuk menampilkan Id Peristiwa: 5900-6000.
      3. Tinjau entri log untuk info yang mungkin menjelaskan mengapa aplikasi tidak diluncurkan.
    • Pecahkan masalah file dengan masalah, identifikasi, dan perbaiki masalahnya. Bangun ulang dan uji ulang aplikasi.
  • Sumber daya tambahan

Uji kompatibilitas dan ketahanan

  • Latar belakang
    • Pemeriksaan ini akan memvalidasi dua aspek aplikasi, aplikasi utama yang dapat dieksekusi, misalnya titik masuk aplikasi yang menghadap pengguna harus dimanifestasikan untuk kompatibilitas, serta mendeklarasikan GUID yang tepat. Untuk mendukung pengujian baru ini, laporan akan memiliki sub simpul di bawah 'Kompatibilitas & ketahanan'. Aplikasi akan gagal jika salah satu atau kedua kondisi ini hilang.
  • Detail Pengujian
    • Kompatibilitas: Aplikasi harus berfungsi penuh tanpa menggunakan mode kompatibilitas Windows, pesan AppHelp, atau perbaikan kompatibilitas lainnya. Manifes kompatibilitas memungkinkan Windows memberikan perilaku kompatibilitas yang tepat kepada aplikasi Anda di bawah versi OS yang berbeda
    • AppInit: Aplikasi tidak boleh mencantumkan DLL untuk dimuat di kunci registri HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs.
    • Switchback: Aplikasi harus menyediakan manifes switchback. Jika manifes hilang, Kit Sertifikasi Aplikasi Windows memberikan pesan peringatan. Kit Sertifikasi Aplikasi Windows juga akan memverifikasi manifes berisi GUID OS yang valid.
  • Tindakan korektif
    • Perbaiki komponen aplikasi yang menggunakan perbaikan kompatibilitas.
    • Pastikan bahwa aplikasi tidak mengandalkan perbaikan kompatibilitas untuk fungsionalitasnya.
    • Pastikan aplikasi Anda dimanifestasikan dan bagian kompatibilitas menyertakan nilai yang sesuai
  • Informasi Tambahan

pengujian praktik terbaik Keamanan Windows

  • Latar belakang
    • Aplikasi tidak boleh mengubah pengaturan keamanan Windows default
  • Detail Pengujian
    • Menguji keamanan aplikasi dengan menjalankan Attack Surface Analyzer. Pendekatannya adalah menambahkan kategori kegagalan berdasarkan per pengujian. Misalnya beberapa kategori untuk pengujian keamanan dapat mencakup:
      • Kegagalan inisialisasi
      • Kegagalan Arsitektur Keamanan
      • Kemungkinan kegagalan luapan Buffer
      • Kegagalan crash
    • Untuk detailnya, lihat di sini.
  • Tindakan korektif
    • Memecahkan masalah dan memperbaiki masalah yang diidentifikasi oleh pengujian. Bangun ulang dan uji ulang aplikasi.

Uji fitur keamanan Windows

  • Latar belakang
    • Aplikasi harus memilih fitur keamanan Windows. Mengubah perlindungan keamanan Windows default dapat membuat pelanggan berisiko meningkat.
  • Detail pengujian
    • Menguji keamanan aplikasi dengan menjalankan BinScope Binary Analyzer. Untuk detailnya, lihat di sini.
  • Tindakan korektif
    • Memecahkan masalah dan memperbaiki masalah yang diidentifikasi oleh pengujian. Bangun ulang dan uji ulang aplikasi.

Tes DPI tinggi

Sangat disarankan agar aplikasi Win32 sadar akan DPI. Ini adalah kunci untuk membuat UI aplikasi terlihat baik secara konsisten di berbagai pengaturan tampilan DPI tinggi. Aplikasi yang tidak sadar DPI yang berjalan pada pengaturan tampilan DPI tinggi mungkin memiliki masalah seperti penskalaan elemen UI yang salah, teks yang diklip, dan gambar buram. Ada dua cara untuk mendeklarasikan aplikasi yang diketahui DPI. Salah satunya adalah mendeklarasikan DPI.

  • Latar belakang
    • Pemeriksaan ini akan memvalidasi dua aspek aplikasi, yang dapat dieksekusi utama, misalnya titik masuk aplikasi yang menghadap pengguna harus dimanifestasikan untuk kesadaran DPI TINGGI dan bahwa API yang tepat dipanggil untuk mendukung HIGH-DPI. Aplikasi akan gagal jika salah satu atau kedua kondisi ini hilang. Pemeriksaan ini akan memperkenalkan bagian baru dalam laporan desktop, lihat contoh di bawah ini.
  • Detail Pengujian
    • Pengujian akan menghasilkan peringatan ketika kami mendeteksi salah satu hal berikut:
      • EXE utama tidak menyatakan kesadaran DPI dalam manifesnya dan tidak memanggil SETProcessDPIAware API. (Peringatkan pengembang jika dia lupa menambahkan manifes kesadaran DPI).
      • EXE utama tidak menyatakan kesadaran DPI dalam manifesnya, tetapi memanggil SetProcessDPIAware API (Peringatkan pengembang bahwa dia harus menggunakan manifes untuk menyatakan kesadaran DPI alih-alih memanggil API).
      • MainEXE menyatakan kesadaran DPI dalam manifesnya, tetapi juga memanggil SetProcessDPIAware API (Peringatkan pengembang yang memanggil API tersebut tidak diperlukan).
      • Untuk biner yang bukan EXE utama, jika mereka memanggil API, berikan peringatan (Memanggil API tidak disarankan).
  • Tindakan korektif
    • Penggunaan fungsi SetProcessDPIAware() tidak disarankan. Jika DLL menyimpan pengaturan DPI selama inisialisasinya, memanggil SetProcessDPIAware() di aplikasi dapat menghasilkan kondisi balapan. Memanggil fungsi SetProcessDPIAware() dalam DLL juga bukan praktik yang baik.
  • Informasi Tambahan