推 hinaeddie:測試腳本沒寫好, 涵蓋率不夠廣, 在你公司是誰的問題? 01/02 22:50
→ hinaeddie:測試層面也分很多,功能,非功能... 01/02 22:55
→ hinaeddie:個人認為, ST只是一種技能,想做好它,要從SQA下手去瞭解 01/02 22:56
推 SHOOTA:看起來測試的工作沒分清楚 01/03 02:23
感謝大大解惑 我家的系統很有趣 一個月更新一次(線上更新包自動下載到客戶端)
所以我們每個月都要出新的功能 而我們的系統範圍是各位意想不到的大
坦白說 目前沒有一家軟體公司系統寫得那麼廣 又那麼常更新功能
說我們是在玩命也不為過阿(汗)
所以說在這種情況下 老闆又耳包聽不進小毛孩兒的話時
測試就只能就測試腳本施測 當然是有與SPEC對過的測試內容
所有包括特殊符號、字元數 都會放進測試的範圍內
先不論測試是否乖乖的照著腳本測 假設有好了
但是還是因為系統範圍過大 有時牽一髮動全身
總會有漏網之魚 測了A漏了B 測試在唉時間不夠測
然後工程師的績效也會被扣得亂七八糟的差
我想我應該要找出一個有效的測試方法 所以才去看了微軟那本書
總是還覺得不夠 因為實在看不是很懂
才上來求救的阿~~~
希望各位大大多分享!
還有呢 因為各位之前有分享過對於UML等文件的看法
但是還滿好奇 如果沒有清楚的UML 對於測試或之後的更新維護
不會覺得很難搞清楚嗎 畢竟 系統是可以很大的...
※ 引述《OriginStar ()》之銘言：
: 原PO可能要先自問測試的目的在那裡了，因為目的不同，方法也不同。
: 功能測試可以拿SPEC來比對，看看各功能是否符合設計，有沒有bug…等。
: 壓力測試可以寫個腳本或自動化測試程式來測試在不同的情況下，軟體
: 運作的效能，或有沒有memory leak。
: 如果是GUI測試，可以隨便抓個路人來會不會、方不方便使用。
: 上述傳統的作法是在軟體產出後來驗證品質。
: 如果想在軟體產出前驗證品質，
: 可以想想採用Test-driven development，或需求分析。
: ※ 引述《saja (莎亞)》之銘言：
: : 想要請問一下各位先進專業
: : 軟體測試除了依照測試腳本之外
: : 還有其他的方法嗎?
: : 我家的測試 就是寫個測試腳本然後人工下去測
: : 我個人認為 這樣的測法跟工程師做完之後測還不是一樣
: : 但是 不知道為什麼這樣還是可以重工(倒)
: : 我看了微軟的測試之道這本書 雖然我也是資管本科的
: : 其中還是有些地方我看不太懂 不知道大大是否有推薦的書籍?
: : 樓上大大推的連結我看了 收益良多
: : 只是我還是想了解在軟體測試這個專業上 還要怎麼補強好?
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.3.173