2010軟考軟件測(cè)試中面臨的問(wèn)題及解決辦法(6)

　　軟件測(cè)試中遇到的5個(gè)問(wèn)題及解決對(duì)策

　　軟件測(cè)試中遇到的5個(gè)問(wèn)題：

　　1 需求說(shuō)明差 (poor requirements) ── 需求不清楚、不完整、太概括、或者不可測(cè)試，都會(huì)造成問(wèn)題。

　　2 不切實(shí)際的時(shí)間表 (unrealistic schedule) ── 如果在很短的時(shí)間里要求做許多事，出現(xiàn)錯(cuò)誤是不可避免的。

　　3 測(cè)試不充分 (inadequate testing) ── 只能根據(jù)客戶意見(jiàn)或者系統(tǒng)崩潰來(lái)判斷系統(tǒng)質(zhì)量的高低。

　　4 不斷增加功能 (featuritis) ── 在開(kāi)發(fā)正在進(jìn)行過(guò)程中要求增加許多新的功能。這是常見(jiàn)的問(wèn)題。

　　5 交流問(wèn)題 (miscommunication) ── 如果開(kāi)發(fā)人員對(duì)客戶的要求不了解，或者客戶由不恰當(dāng)?shù)钠谕�，必然�?huì)導(dǎo)致錯(cuò)誤。

　　針對(duì)這些問(wèn)題，有5個(gè)解決辦法：

　　1 可靠的需求 (solid requirements) —— 應(yīng)當(dāng)有一個(gè)經(jīng)各方一致同意的、清楚的、完整的、詳細(xì)的、整體的、可實(shí)現(xiàn)的、可測(cè)試的需求。為幫助確定需求，可使用模型 (prototypes) 。

　　2 合理的時(shí)間表 (realistic schedules) —— 為計(jì)劃、設(shè)計(jì)、測(cè)試、改錯(cuò)、再測(cè)試、變更、以及編制文檔留出足夠的時(shí)間。不應(yīng)使用突擊的辦法來(lái)完成項(xiàng)目。

　　3 適當(dāng)?shù)臏y(cè)試 (adequate testing) —— 盡早開(kāi)始測(cè)試;每次改錯(cuò)或變更之后，都應(yīng)重新測(cè)試。項(xiàng)目計(jì)劃中要為測(cè)試和改錯(cuò)留出足夠的時(shí)間。

　　4 盡可能堅(jiān)持最初的需求 (stick to initial requirements as much as possible) —— 一旦開(kāi)發(fā)工作開(kāi)始，要準(zhǔn)備防止修改需求和新增功能。要說(shuō)明這樣作的后果。如果必須進(jìn)行變更，必須在時(shí)間表上有相應(yīng)的反映。如果可能，在設(shè)計(jì)階段使用快速的模型，以便使客戶了解將會(huì)得到的東西。這將會(huì)使他們對(duì)他們的需求有較高的信心，減少以后的變更。

　　5 溝通 (communication ) —— 在適當(dāng)時(shí)機(jī)進(jìn)行預(yù)排和檢查;充分利用團(tuán)組通信工具 —— 電子郵件、群件 (groupware) 、網(wǎng)絡(luò)故障跟蹤工具、變更管理工具、以及因特網(wǎng)的功能。要確保文件是可用的和最新的。優(yōu)選電子版文檔，避免紙介質(zhì)文檔;進(jìn)行遠(yuǎn)距離聯(lián)合作業(yè)及協(xié)作;盡早使用模型，使得客戶的預(yù)想是清楚的。