了解需求說明書

  現在你開始進入一個項目進行你的測試工作了，你參加了需求評審會議，知道了些項目的背景，得到了項目的需求說明書，從需求說明書開始你的測試工作。 或許你覺得你手上的需求說明書很差，你不想去看，你覺得你可以在系統真正出來以後，根據系統，你可以很容易的設計出測試用例，或者，你可以不用測試用例就能進行測試。如果你這麼想，那麼你肯定不會去設法了解需求說明書，也不會對你将要測試的需求說明書描述的系統有完整的，清晰的認識，或許你依舊可以根據模闆做出測試計劃，設計出測試用例，你的這些測試準備工作，可能也會通過評審，因為公司的評審并不嚴格或者其他的原因。好了，你這樣做了，你知道這樣做會有什麼後果嗎？ 你也知道的，需求說明書是産生 bug 的主要原因，很多缺陷都可以追蹤到需求說明書的不完整，不正确，變動多上面，那麼你對需求說明書沒有認真的檢查，你肯定會遺漏很多的缺陷，你大概也知道如果在項目後期修改 bug 的費用比修改在需求說明書中的缺陷要高多少吧。 你沒有了解需求說明書，對程式很多功能都沒有詳細的考慮，你能保證你看着系統就可以完全了解整個系統，大概不能吧，很多細節的内容，你還是需要對照需求說明書去了解，可是，你在檢查需求說明書的時候都不去認真看它，現在，要測試了，測試任務可能很緊，你還會去看它嗎，你看它的時候能夠了解嗎？肯定不能，那麼你就要有人來明确告訴你系統是怎麼回事。 好了，這個時候，你可能會求助産品經理，可能會求助項目經理，可能會求助程式員，但是，你要知道，如果你有很多的問題去問，你沒有這麼多時間，他們也沒有這麼多時間，你的問題能全部解決麼？就算你的問題不多，可是你在這個時候去問他們關于需求的問題，你覺得他們會樂意解答嗎？他們會認為，你沒有做好你本來應該做好的事情，他們會對你敷衍，因為這不是他們這個是要的工作，他們這個時候的工作是編碼或者是解決 bug 或者是其他，但絕對不是回答你關于需求的問題。 你的問題很大程度上不會被完整，準确的解決，可是你還是要測試，因為這是你的工作。因為你對整個系統的了解存在問題，你肯定會遺漏很多的測試點，你也會報告很多的無效 bug ，你還會無法判斷你測試到的現象是系統特色還是 bug ，你知道這個時候你會有哪些問題麼？ 你遺漏了 bug ，會導緻系統的不穩定，或許嚴重的，會導緻整個系統的崩潰，你的工作沒有做好，上司會找你的責任。你報告了許多無效的 bug ，開發人員對你的能力開始懷疑，對你的信任開始降低，你報告的 bug 他們不再關注，你會有很多未解決的 bug 等着你去跟蹤。你無法判斷你測試到的現象是系統特色還是 bug 同樣會導緻前面的兩個問題。現在，你知道你的問題的嚴重性了吧。 以上所有的問題，僅僅是你在本來應該做事情的時候想當然的認為在以後可以解決而沒有做，測試沒有任何的假設，該你做什麼你就應該做什麼。 那麼，如果你對需求說明書不了解，或者說明書不夠詳細，或者你認為需求說明書很差，你該做什麼。 首先，不要假設說明書上的所有内容都是正确的，也不要等到程式釋出以後再根據程式去了解需求說明書，然後去設計測試。你手上有需求說明書，你就要努力的去了解他，因為這是你這個時候的工作，如果你在了解需求說明書的時候有困難，你可以尋找相關的人來幫助你，可能是需求說明書的作者，也可能是項目經理，或者是相關的程式員，隻要你在這個時候尋求幫助，他們肯定會樂意幫助你的。在這個時候，你就要首先弄明白需求說明書的内容，因為，你後面的測試工作的展開，比如測試需求，測試用例，測試計劃都是依照需求說明書的，如果你不了解測試用例，你就不能準确估算你的測試工作量，你也不能詳細的設計你的測試政策，還有你的測試用例。 其次，努力獲得和你要測試的項目相似的已經成型的系統，然後認真去研究它。