諾基亞手機(jī)軟件測(cè)試基礎(chǔ)知識(shí)、術(shù)語和流程

360寶盒諾基亞(s60v3v5塞班3)2.7通用版

• 類型：塞班平臺(tái)應(yīng)用大�。�1.4M語言：中文 評(píng)分：5.0
• 標(biāo)簽：

立即下載

2.1 測(cè)試與開發(fā)
2.1.1 軟件開發(fā)的一般流程

 Marketing
 Requirement Analysis
 High Level Design
 Low Level Design
 Coding
2.1.2 測(cè)試在軟件開發(fā)中的作用
 由于現(xiàn)在軟件的規(guī)模越來越大，一個(gè)人或者少數(shù)幾個(gè)人已經(jīng)不可能在一定的時(shí)間內(nèi)完成一個(gè)軟件，所以軟件開發(fā)的過程越來越復(fù)雜，層次越來越深。這就導(dǎo)致開發(fā)人員之間的溝通有了一定的隔閡。所以，軟件測(cè)試越來越有單立出來的必要和重要性。
 由于軟件開發(fā)的過程的復(fù)雜性，軟件必然存在著無數(shù)的Bug。而且大多數(shù)是在軟件上市前必須解決的，而開發(fā)者有不定能發(fā)現(xiàn)這些問題，故而測(cè)試就顯得非常必要。測(cè)試是開發(fā)成功的必要保障。
 由于軟件開發(fā)的層次性，所以開發(fā)的結(jié)果很可能與初衷不一樣，這就需要測(cè)試者去發(fā)現(xiàn)這些差異。因此，測(cè)試是軟件成功的重要保證。
 軟件不僅要實(shí)現(xiàn)一些功能，更要完善它的性能。這就需要測(cè)試人員對(duì)軟件進(jìn)行評(píng)測(cè)，從而不斷地完善軟件的性能。
2.1.3 測(cè)試與開發(fā)對(duì)應(yīng)圖

2.1.4 Nokia手機(jī)軟件測(cè)試介入開發(fā)的時(shí)間

 在制定開發(fā)計(jì)劃的同時(shí)就要制定測(cè)試計(jì)劃
 測(cè)試在進(jìn)行結(jié)構(gòu)設(shè)計(jì)時(shí)就已經(jīng)進(jìn)行了
2.1.5 Nokia手機(jī)的開發(fā)流程

 E-1
During this period, an idea box will appear. The ideas in the idea box are collected from Region Marketing and have a certain priority (The lower the priority number is, the higher the priority is). For example:0, 1, 2.
 E0
During this period, the HW designer must make out the B0-HW version.That is to say, B0 must be put out after E0 period.
 E0.5
綜合考慮HW, SW and Cost
 E1
From E0 to E1, Design and Test Plan, Risk, Organization, Schedule must be discussed and made out.
 E1.5
全體討論Design and Test Specification
 E1.9
From E1 to E2, Design and Test Specification must be made out.
During E1.9, Last version of Specification should be made out and be approved.
 E2
During E2, The formal draft SW should be made out.
 E3
From E2 to E3, 對(duì)SW進(jìn)行精美化、完美化測(cè)試和改良
Purpose: No fatal error (市場(chǎng)部可以接受的Fatal Error不算)
 E5
From E3 to E5, 進(jìn)行LCD以及其他HW的改動(dòng)

During E5, 可以讓生產(chǎn)工廠進(jìn)行大批量生產(chǎn)
 Before E5, the test stays in the CE (concurrent engineer)
After E5, the test goes into PE (production engineer)
2.2 測(cè)試的流程
2.2.1 制定測(cè)試計(jì)劃
 開啟測(cè)試項(xiàng)目
 在接了一個(gè)測(cè)試項(xiàng)目后，要在一定的期限內(nèi)制定好測(cè)試的詳細(xì)計(jì)劃以及日程安排表
2.2.2 測(cè)試準(zhǔn)備
 在計(jì)劃制定好之后，在執(zhí)行之前，必須將測(cè)試所需的人力資源，硬件資源，軟件資源，文檔資源以及環(huán)境和人文資源準(zhǔn)備充分
2.2.3 測(cè)試執(zhí)行
 測(cè)試組根據(jù)測(cè)試計(jì)劃和測(cè)試日程安排進(jìn)行測(cè)試，并輸出測(cè)試結(jié)果
2.2.4 測(cè)試評(píng)估
 有測(cè)試結(jié)果評(píng)估小組或評(píng)估人員對(duì)測(cè)試結(jié)果進(jìn)行評(píng)測(cè)，分析，并輸出分析結(jié)果
2.2.5 文檔收集
 將從測(cè)試計(jì)劃開始到評(píng)估結(jié)束的所有文檔進(jìn)行整理收集。
 對(duì)整個(gè)測(cè)試過程進(jìn)行總結(jié)，并對(duì)測(cè)試結(jié)果進(jìn)行總結(jié)
2.2.6 測(cè)試總結(jié)報(bào)告
 提交測(cè)試結(jié)果
 歸還所借相關(guān)資源
 文檔入庫(kù)
 關(guān)閉測(cè)試項(xiàng)目

2.3 測(cè)試的方法
2.3.1 正確性測(cè)試
 正確性測(cè)試又稱功能測(cè)試，它檢查軟件的功能是否符合規(guī)格說明。
 測(cè)試基本的方法是構(gòu)造一些合理輸入（在定義域內(nèi)），檢查是否得到期望的輸出。
 由于定義域是一個(gè)連續(xù)區(qū)間，所以不可能枚舉所有可能的值，那么等價(jià)測(cè)試就很必要了（將定義域分成若干個(gè)等價(jià)區(qū)間）。
 等價(jià)區(qū)間的概念可表述如下：
記（A, B）是命題f(x) 的一個(gè)等價(jià)區(qū)間，在（A, B）中任意取x1進(jìn)行測(cè)試
如果f (x1) 錯(cuò)誤，那么f (x) 在整個(gè)（A, B）區(qū)間都將出錯(cuò)。
如果f (x1) 正確，那么f (x) 在整個(gè)（A, B）區(qū)間都將正確。
2.3.2 容錯(cuò)性測(cè)試
 容錯(cuò)性測(cè)試是檢查軟件在異常條件下的行為（輸入不同的數(shù)據(jù)類型或者定義域之外的值進(jìn)行測(cè)試）。
2.3.3 邊界性測(cè)試
 因?yàn)檫吔缫恢笔潜容^敏感的地方，而且是程序員最容易忽略的地方，所以，這種測(cè)試也往往最容易奏效。
2.3.4 性能與效率測(cè)試
 性能與效率測(cè)試主要是測(cè)試軟件的運(yùn)行速度和對(duì)資源的利用率。
 性能與效率測(cè)試中很重要的一項(xiàng)是極限測(cè)試，因?yàn)楹芏嘬浖�系統(tǒng)會(huì)在極限測(cè)試中崩潰。
2.3.5 易用性測(cè)試
 易用性測(cè)試沒有一個(gè)量化的指標(biāo)，主觀性較強(qiáng)。這主要是從End User的角度去考慮軟件是否會(huì)有一定的使用缺陷。如果對(duì)此有任何看法，可以向Team Leader反應(yīng)或者與客戶負(fù)責(zé)人直接交流。
2.3.6 文檔測(cè)試
 文檔測(cè)試主要檢查文檔的正確性、完備性和可理解性。好多人甚至不知道文檔是軟件的一個(gè)組成部分。
 我們的工作中的文檔主要是UI Spec.和Test Case。UI Spec使我們無法改變的，但是Test Case
是我們測(cè)試的對(duì)象。Test Case是我們用來測(cè)試手機(jī)軟件的參考文檔，但是它本身也有一定的局限性。所以，在測(cè)試的過程中，如果發(fā)現(xiàn)Test Case不正確或者不充分，可以直接補(bǔ)充，或者和Team Leader商議后把不足的地方補(bǔ)充起來。
2.4 測(cè)試的分類
2.4.1 按測(cè)試的手段分
 黑盒測(cè)試(White-box Test)
 Release Test
 (Full Round)SystemTest
 Focus Test
 Stress Test---No Test Case
 Free Test----No Test Case
 白盒測(cè)試(Black-box Test)
 Module Test
 Sub-System Test
 Sub-System Integration Test
 System Integration Test
 Integration Test
The feature groups for Integration Test are decided by Integrator and provided by SW
Component Factory.
2.4.2 按測(cè)試發(fā)生的時(shí)間和目標(biāo)分
 單元測(cè)試(Module Test/Unit Test)
 集成測(cè)試(Integration Test)
 系統(tǒng)測(cè)試(System Test)
2.4.3 按測(cè)試的任務(wù)分
 現(xiàn)場(chǎng)測(cè)試(Field Test)
 互操作測(cè)試(Inter-Operatability Test)
2.4.4 其他測(cè)試
 可接受性測(cè)試(Acceptance Test)
 測(cè)試 -----------手機(jī)研發(fā)公司自己做的測(cè)試
 測(cè)試 -----------非手機(jī)研發(fā)公司做的測(cè)試
2.5 黑盒測(cè)試詳細(xì)介紹
2.5.1 Release Test
 Purpose:
 測(cè)試手機(jī)的基本功能是否實(shí)現(xiàn)，是否有進(jìn)一步測(cè)試的必要性
 Input:
 測(cè)試工程師
 Release Test Cases (較少，一般為200左右)
 手機(jī)以及相關(guān)附件
 測(cè)試環(huán)境
 Output:
 Test result of Release Test
 No Error reports (Optional)
 Attention:
 Release Test的Test Case具有一定的典型性，主要是反映手機(jī)最基本功能的Test Case
 本類測(cè)試只需要依據(jù)Test Case進(jìn)行測(cè)試，不需要進(jìn)一步發(fā)揮
 如果有發(fā)現(xiàn)與Case無關(guān)的Error, 在測(cè)試通過后才可以填報(bào)Error Report
 此類測(cè)試有一門檻值，即Test Case的Pass率達(dá)到一定值（如95%）才能宣布版本發(fā)布成功，進(jìn)入進(jìn)一步的測(cè)試，否則此版本無效。
 除了門檻值外，如果重要功能模塊的Test Case沒通過，也會(huì)終止這個(gè)版本。
2.5.2 System Test
 Full Round System Test
 Purpose
 對(duì)手機(jī)的所有功能進(jìn)行全面的測(cè)試(所有語言包)
 由于Case不可能包含所有方面，所以測(cè)試時(shí)應(yīng)適度發(fā)揮，盡力完成全面測(cè)試
 Input:
 測(cè)試工程師
 Test Cases(較多，一般為25000左右)
 手機(jī)以及相關(guān)附件
 測(cè)試環(huán)境
 Schedule
 Output:
 Daily Report of test cases (number & percent of Pass, Error, NA, NT)
 Summary Report
 Error list and Error reports
 Common System Test (Medium or Minor)
 Purpose:
 對(duì)手機(jī)的一部分的功能進(jìn)行全面的測(cè)試
 由于Case不可能包含所有方面，所以測(cè)試時(shí)應(yīng)適度發(fā)揮，盡力完成全面測(cè)試
 Input:
 測(cè)試工程師
 Test Cases(較多，取決于測(cè)試的目的和范圍)
 手機(jī)以及相關(guān)附件
 測(cè)試環(huán)境
 Schedule
 Output:
 Daily Report of test cases (number & percent of Pass, Error, NA, NT)
 Summary Report
 Error list and Error reports
 Attention:
 System Test一般分為兩個(gè)部分，“跑Case”和Free Test。
 在測(cè)試初期，一般只需要按照Test Case測(cè)，把一些不可重現(xiàn)的Error都記錄下來。同時(shí)遇到Test Case的問題或者不充分，應(yīng)該立即解決（和Team Leader或者Special List討論，補(bǔ)寫Test Case）。在這一階段結(jié)束后，一般要寫一個(gè)Summary Report。把這一階段的測(cè)試結(jié)果和遇到的問題、自己的見解都寫在里面（當(dāng)然是用English）。
 當(dāng)所有Test Case都測(cè)完后，就進(jìn)入Free Test期間。這里的Free Test具有明確的目的性和范圍。一般來說，這段時(shí)間的Free Test只需要測(cè)自己負(fù)責(zé)的模塊。而且Free Test還負(fù)責(zé)重現(xiàn)前期“跑Case”是遺留的不可重現(xiàn)的Error。
2.5.3 Focus Test
 Purpose:
 集中于一個(gè)或幾個(gè)點(diǎn)進(jìn)行測(cè)試(同System Test)
 Input:
 測(cè)試工程師
 Test Cases
 手機(jī)以及相關(guān)附件
 測(cè)試環(huán)境
 Output:
 Test Result
 Error Reports
2.5.4 Stress Test
 Purpose:
 為了解決市場(chǎng)上發(fā)現(xiàn)的重大Error，而進(jìn)行的有針對(duì)性的強(qiáng)度測(cè)試
 主要是利用邊緣測(cè)試（臨界測(cè)試）手段
 Input:
 測(cè)試工程師
 手機(jī)以及相關(guān)附件
 測(cè)試環(huán)境
 Focus List of Phone Features
 Output:
 Expected result: find out the reproducible steps of these errors
 Decrease the steps as possible as we can
 Attention:
 壓力測(cè)試，顧名思義，是給手機(jī)施加一定壓力，從而找出手機(jī)軟件上的Error。一般來說，對(duì)手
機(jī)施加的壓力主要有：
 存儲(chǔ)壓力：由于手機(jī)采用的是棧式存儲(chǔ)，所以當(dāng)一個(gè)存儲(chǔ)塊滿了之后，如果程序員不做相應(yīng)處理或者處理不好的話，很容易造成其他存儲(chǔ)區(qū)被擦除，從而在UI上出現(xiàn)問題（其他功能無法正常使用）。
 邊界壓力：邊界一直是程序員最容易忽略的地方。
 響應(yīng)能力壓力：有時(shí)候某個(gè)操作可能處理的時(shí)間很長(zhǎng)，在處理期間如果測(cè)試者再不斷地進(jìn)行其他操作的話，很容易出現(xiàn)問題。
 網(wǎng)絡(luò)流量壓力（如在接電話時(shí)進(jìn)行短信服務(wù)）等等。
 在項(xiàng)目中，Stress Test有時(shí)也會(huì)用來重現(xiàn)不可重現(xiàn)的Error。
 由于有不少不可重現(xiàn)的Error是由于Memory Leak(內(nèi)存泄漏)引起的，所以不停的重復(fù)同一個(gè)操作是重現(xiàn)一個(gè)不可重現(xiàn)的Error的一個(gè)好方法。
2.5.5 Free Test
 Purpose:
 測(cè)試System Test中沒有做完的不可重現(xiàn)Error
 尋找平時(shí)沒有找到的忽略的Error
 Input:
 測(cè)試工程師
 手機(jī)以及相關(guān)附件
 測(cè)試環(huán)境
 Error List of System Test (especially the irreproducible errors)
 Output:
 Error List and Error Reports
 Attention:
 在System Test階段所用的Free Test具有明顯的目的性和范圍
 平時(shí)的Free Test從理論上應(yīng)該對(duì)所測(cè)試的范圍窮盡所有的測(cè)試方法。但是，這是不現(xiàn)實(shí)的。在實(shí)際項(xiàng)目中，主要有兩個(gè)方面是Free Test所需要重視的。
 一是從UI Spec上找靈感。應(yīng)為Test Case是依據(jù)UI Spec寫的，所以從UI Spec上突破是一個(gè)行之有效的方法。UI Spec有一定的探索深度，加大探索深度，是一種突破的途徑；另外同一個(gè)功能用其他不同的方法去實(shí)現(xiàn)，也是一種突破途徑。
 二是多關(guān)注不同F(xiàn)eature之間的Interaction。這是手機(jī)軟件相對(duì)比較容易出問題，而Test Case又很少能反映的地方。這是一個(gè)很大的Free Test空間。
2.6 測(cè)試相關(guān)文檔說明
2.6.1 測(cè)試計(jì)劃
 測(cè)試的任務(wù)
即需要測(cè)試什么和不需要測(cè)試什么；
 工作量估算
需要多少人，測(cè)試多少天，測(cè)試幾個(gè)周期；
 日程表
每人每天需要做什么；
 測(cè)試方法和流程
采用什么方法，遵循哪些流程；
 測(cè)試資源
需要多少人、設(shè)備、工具、文檔等資源，以及對(duì)上述資源都有哪些要求。
 測(cè)試輸出
測(cè)試中需完成的錯(cuò)誤報(bào)告（Error Report）和進(jìn)度報(bào)告（Progress Report），測(cè)試完成后需完成的總結(jié)報(bào)告（Summary Report）。
2.6.2 測(cè)試用例
 Title
標(biāo)題一般會(huì)描述出當(dāng)前要執(zhí)行的case是哪個(gè)功能模塊的，能實(shí)現(xiàn)怎樣的一個(gè)操作。標(biāo)題下面有當(dāng)前case的ID號(hào)和軟件的版本號(hào)，如Phonebook-Memory Save-Selected memory is Phone and SIM
ID: EK20010829094907
Version: 1.1.0
 Description
整體地描述這個(gè)case的測(cè)試目的，能實(shí)現(xiàn)什么功能。例如：
The purpose of this test case is check out that the phone number can be saved to phonebook
when selected memory is Phone and SIM.
 Required test environment and accessories
必需的測(cè)試環(huán)境和附件。測(cè)試環(huán)境包括硬件環(huán)境和軟件環(huán)境。例如：HW, ESIM，Headset.
 Precondition
描述執(zhí)行case的前提條件。例如：
Select memory in use to be Phone and SIM.
Return to the Idle State.
 Action
詳細(xì)描述執(zhí)行case時(shí)的每一步操作。一般每一步操作都對(duì)應(yīng)著一個(gè)期望中的結(jié)果。執(zhí)行時(shí)可參照下面的期望結(jié)果。例如：
Start the procedure to add a new item to the Phonebook.
Enter some name and press Ok.
Enter some number such as 12345 and press Ok.
 Expected result
描述執(zhí)行該case的期望中的結(jié)果，與上面的操作Action是相對(duì)應(yīng)的。例如：
Name: query is displayed.
Number: query is displayed.
Saved to phone memory information note is shown. Phone goes to detailed memory screen.
2.6.3 錯(cuò)誤報(bào)告
 Title:
標(biāo)題是Error Report中非常重要的一部分，它要求簡(jiǎn)單明了地對(duì)Error作一個(gè)整體的描述，讓不知道這個(gè)Error的人看了之后能夠很清楚地知道這是個(gè)怎樣的Error。記得曾經(jīng)有人提過“3W1H”的概念。也就是說，標(biāo)題里面應(yīng)該包括What is the error, When will the error appear, Where may the error appear and How to make the error appear. 在Title后面，一般要寫上Feature Group的名字。
例如：
Title: Call register: The phone doesn’t remain in the same state after rejecting a call
when viewing items under full window choice items in call register.
 Severity (Fatal/Severe/Minor):
Severity用來描述Error的嚴(yán)重程度，有三個(gè)級(jí)別：較小的、嚴(yán)重的、致命的。Fatal Error一般來說是指影響手機(jī)系統(tǒng)工作的Error；Server Error指的是影響用戶操作的或者某些功能實(shí)現(xiàn)的Error；Minor Error指的是微小的、不影響手機(jī)功能正常使用的Error。一般的Error如中文界面中的某個(gè)字不正確，或者是英文界面中的某個(gè)單詞拼寫不正確；左右功能鍵顯示有誤等等都屬于Minor。若手機(jī)的某個(gè)功能不能實(shí)現(xiàn)，如不能發(fā)短信，不能存電話號(hào)碼，不能進(jìn)行充電等等都屬于Severe；若手機(jī)開不了機(jī)，或經(jīng)常死機(jī)
、重啟等則是Fatal。Severe和Fatal兩種Error對(duì)手機(jī)來說都是很嚴(yán)重的問題，這個(gè)具體在做項(xiàng)目時(shí)可請(qǐng)示項(xiàng)目經(jīng)理。
例如：Minor
 Reproducible Error? (Yes/No, if No, how many times?) in English UI or Chinese UI?
描述Error是否可再現(xiàn)，如果每次操作都能出現(xiàn)，就是可再現(xiàn)的。如果只是某一次操作才會(huì)出現(xiàn)這個(gè)Error
，則是不可再現(xiàn)的。如果是不可再現(xiàn)錯(cuò)誤，要記錄一共出現(xiàn)過多少次，是在英文界面還是在中文界面。每
個(gè)Error都有發(fā)生的前提條件和操作步驟。嚴(yán)格的說，每個(gè)Error都是可重現(xiàn)的。但是，發(fā)現(xiàn)這個(gè)Error的
人可能沒有能夠找到這個(gè)error的完整的前提條件或者完整的操作步驟。所以，現(xiàn)實(shí)中就有了很多不可重
現(xiàn)的Error。對(duì)于一個(gè)手機(jī)而言，硬件，軟件，語言包和SIM卡都是其重要的組成部分。所以，在一個(gè)手機(jī)
中用某種SIM卡在某種語言的UI上發(fā)現(xiàn)了某個(gè)Error，有可能在同樣的手機(jī)，同樣的SIM卡，不同的語言的
UI上就沒有這個(gè)Error;也有可能在同樣得手機(jī)上用不同的SIM卡也會(huì)沒有這個(gè)Error；同樣，在不同的手機(jī)
上也有可能發(fā)現(xiàn)不了這個(gè)Error�？傊�一句話，是否可重現(xiàn)，要考慮手機(jī)硬件、軟件版本、SIM卡類型、UI
類型等等相關(guān)的影響，不能簡(jiǎn)單的說某個(gè)Error可重現(xiàn)，有的時(shí)候要加上注釋。

例如：Yes, both in English UI and Chinese UI
 Precondition:
這里寫的是在錯(cuò)誤發(fā)生之前，手機(jī)的狀態(tài)。為了保證步驟的簡(jiǎn)潔，這里要盡可能的詳細(xì)。當(dāng)然，也不要寫
的很羅嗦。
 How did you get to the state just before the error:
詳細(xì)描述在錯(cuò)誤發(fā)生之前你是如何到達(dá)這個(gè)狀態(tài)的，要具體到每一步的操作。在這個(gè)部分，步驟一定要清
晰、簡(jiǎn)潔，讓別人能夠輕松的理解并完成操作這個(gè)可以分成幾個(gè)步驟來寫，如步驟1、步驟2、步驟3等。
例如：
1. Menu --> Call register --> enter one of full window choice items;
2. Receive a call;　
3. Reject it or remote end terminats the call.
 Description of the error:
對(duì)發(fā)生錯(cuò)誤的描述，用簡(jiǎn)明易懂的話詳細(xì)地把這個(gè)Error描述清楚。注意幾個(gè)要點(diǎn)：“詳細(xì)”、“簡(jiǎn)明”
、“清晰易懂”。例如：
After rejecting a call or having a missed call when viewing items under full window choice
items in call register. The phone goes back to the full window choice items under call
register.
 Description of expected result:
描述期望的操作結(jié)果，這個(gè)在case中一般都有說明，一般情況下，case的執(zhí)行結(jié)果就是期望的操作結(jié)果。
這里描述的是，期望情況下，“應(yīng)該”是什么結(jié)果.例如：
The phone should remain in the same state just as before receiving a call.
 SIM card used:
所用的SIM卡是中國(guó)移動(dòng)（CMCC）還是中國(guó)聯(lián)通(CHN-CUGSM)。例如：CMCC
 SW version and Language package:
所測(cè)手機(jī)軟件的版本號(hào)可通過在待機(jī)狀態(tài)下按“*#0000#”來獲得。
我們現(xiàn)在所測(cè)的手機(jī)語言包大部分都是C包，語言包可通過下面的方法來獲得：
把手機(jī)恢復(fù)出廠設(shè)置，進(jìn)入短信的編輯窗口，此時(shí)默認(rèn)的輸入法如果是“拼音”
，則語言包為C包。例如：V5.20C
2.6.4 進(jìn)度報(bào)告
 工作時(shí)間（小時(shí)數(shù)）；
 測(cè)試用例執(zhí)行情況：
 Total:已經(jīng)完成的測(cè)試用例數(shù)目；
 Fail:其中出錯(cuò)的測(cè)試用例數(shù)目；
 Pass:通過的測(cè)試用例數(shù)目；
 Not Test:未測(cè)的測(cè)試用例數(shù)目；
 Not Available:無法測(cè)試的測(cè)試用例數(shù)目；
 發(fā)現(xiàn)的所有錯(cuò)誤的列表；
 執(zhí)行的所有測(cè)試用例及其結(jié)果的列表。
2.6.5 總結(jié)報(bào)告
 測(cè)試活動(dòng)的時(shí)間
 測(cè)試投入的人力
 測(cè)試效果和結(jié)論
 測(cè)試用例通過情況列表
 發(fā)現(xiàn)所有錯(cuò)誤的列表
 所有仍未關(guān)閉的錯(cuò)誤報(bào)告列表