嵌入式軟件的測試方法和工具-資料下載頁
2025-08-04 15:12本頁面
【正文】 第一個錯誤的變種。 期望結(jié)果（Expected result） 期望結(jié)果的描述應該與實際結(jié)果的描述方式相同。通常需要列出期望結(jié)果的應該是什么，并且給出期望結(jié)果的原因，可能是引用的規(guī)格說明書、前一版本的表現(xiàn)行為、客戶一般需求、排除雜亂信息的需要等等。 為了更清楚地理解良好的期望結(jié)果應該包含什么信息，請看下面的例子： Expected result： The text that appears should be fully highlighted so that if the user wishes to make changes, they don39。t have to manually highlight and then type (as in Mac OS and Windows behavior.) 為什么說這個例子很好呢？因為它包含了如下內(nèi)容： 應該產(chǎn)生的正確現(xiàn)象：The text that appears should be fully highlighted 為什么應該產(chǎn)生：…so that if the user wishes to make changes, they don39。t have to manually highlight and then type. 給出了具體得參考對象：As in OS and Windows behavior. 注釋（Notes） 注釋應該包括復現(xiàn)步驟中可能引起混亂的補充信息，是對操作步驟的進一步描述，這些補充信息是復現(xiàn)缺陷或隔離缺陷的更詳細的內(nèi)容。 注釋部分可以包含以下各方面的內(nèi)容： 截取缺陷特征圖像文件（Screenshots）； 測試過程需要使用的測試文件； 測試附加的打印機驅(qū)動程序； 再次描述重點，避免開發(fā)人員將缺陷退回給測試人員補充更多信息； 再次指明該缺陷是否在前一版本已經(jīng)存在； 多個平臺之間是否具有不同表現(xiàn)； 注釋包含缺陷的隔離信息，指出缺陷的具體影響范圍。 例如，缺陷的注釋可能包含下面的內(nèi)容： Notes： 1. Text displays outside frame in Win2000 and WinXP, but not Win98. 2. Does not happen after screen has redrawn. 3. Does not occur when two documents are open. 4. Refer to attached screenshots and testing file 5. 缺陷報告的寫作注意事項 提高缺陷報告的寫作水平是不斷積累經(jīng)驗，循序漸進的過程。在正式提交缺陷報告前，請對缺陷報告的內(nèi)容和格式進行自我檢查，避免很多不必要的錯誤。 自我檢查和提問 缺陷報告已經(jīng)向讀者包含完整、準確、必要的信息了嗎？ 一個缺陷報告中是否之報告了一種缺陷？ 讀者是否能容易的搜索該缺陷？ 步驟是否可以完全復現(xiàn)而且表達清楚嗎？ 是否包含了復現(xiàn)該缺陷需要的環(huán)境變量或測試所用的數(shù)據(jù)文件？ 缺陷的標題是按照原因與結(jié)果的方式書寫的嗎？ 實際結(jié)果和期望結(jié)果是否描述不夠清楚而容易引起歧義嗎？ 避免常見的錯誤 使用“I（我）”、“You（你）”等人稱代詞?？梢灾苯邮褂脛釉~或必要時使用“User（用戶）”代替； 使用情緒化的語言和強調(diào)符號，例如黑體、全部字母大寫、斜體、感嘆號、問號等。只要客觀地反映出缺陷的現(xiàn)象和完整信息即可，不要對軟件的質(zhì)量優(yōu)劣做任何主觀性強烈的批評、嘲諷； 使用諸如“Seems（似乎）”、“Appears to be（看上去可能）” 等含義模糊的詞匯，而需要報告確定的缺陷結(jié)果； 包含認為比較幽默的內(nèi)容，因為不同讀者的文化和觀念不同，很多幽默內(nèi)容在別人看來，往往難以準確理解，甚至可能引起誤解。只需客觀地描述缺陷的信息即可； 將不確定的測試問題（Issues）放在缺陷管理數(shù)據(jù)庫中。如果對測試軟件的某個現(xiàn)象不確定是否是軟件缺陷，可以通過電子郵件或口頭交流，確認是缺陷后再報告到數(shù)據(jù)庫中。避免查詢和統(tǒng)計結(jié)果的不準確性。
公司管理相關推薦
鄂ICP備17016276號-1