天天被測試人員叫過去定位一些軟體本身不支援的功能。
目前專案的測試用例非常簡單，簡單到只有一句話。
全憑測試人員的思維發散來測試。發散的多了，故障單就多。發散少了，故障單就少。
專案的測試用例，用乙個專案用例庫，還是這個專案剛開始的時候寫的。都2-3年沒有更新。
心裡的感觸是非常深刻的。
專案在需求開發過程中，一定要有測試人員參與其中，制定好測試用例。研發人員、系統工程師、需求工程師、測試人員一起參與到需求開發中，從需求確定後，測試用例也要寫好，制定好，並及時更新到測試用例庫中，做到實時更新、常常更新；有很多測試人員的測試思路是非常好的，而且符合使用者的思維，要時常讓這樣的員工給大家適時做一些培訓，讓其他人員也能分享到/學習到這樣好的測試理念。
不要為了測試而測試，這個是測試的禁忌。
為了產品而測試/站在使用者的角度測試，按照實際應用場景去測試，這個是測試的目的。
測試完成後，能夠發現：客戶需要的功能都能夠保質的實現，客戶不要的功能，能做到不給使用者添麻煩，不出錯。
相信很多公司都是這樣的，測試人員無法理解到底測試到什麼程度算是合格的，使用者的使用範圍是什麼。
考核測試人員的標準不能只以故障單為標準，更重要的時候以測試的模組中客戶需要的功能是否測試完備--以需求開發過程中制定的測試用例為標準，不能測試人員的發散思維來確定。
為了達到這個目的，要從專案的大領導到具體實施的人員來灌輸這種思維。關鍵是如果大領導只說不幹，不考核這個，或者乾脆不說這個，下面更沒有動力來實施測試參與需求的功能了。
DBA參與開發專案的意義
1.為什麼dba 要了解業務需求 dba 了解業務需求後會給專案代來哪些建議?dba 了解業務需求後 就明白了業務流程 熟悉了業務流程就清楚了資料的流向 然後就可以站在資料的角度來分析資料變化的情況 如資料增長情況 資料分布情況 是否有特殊性資料等 有了以上這些分析 dba 就可以更好的配合開發同事...
參與開源專案的6條建議
開源專案是提高自身能力和做你喜歡的事的好方法，有其他專案的實際經驗也能讓你更符合求職要求,給你帶來更多的機會。問題是大家都不知道從 開始。以下6個簡單的提示告訴你如何開始f oss free and open source software 1.參與那些你使用過的開源軟體背後的專案 這很顯然，請不要...
一些參與開源專案的建議
一直非常想增加到乙個開源專案中去，目的非常easy 分享思路。接受眾人的考驗，可是卻沒成行。看到這篇文章。受到一定的啟示。遂轉之。注 有刪減。人們常下面3個原因而打消了參與到開源專案的念頭 1.我還不足夠優秀 2.我沒有足夠的是時間 3.我不知道什麼樣的專案適合我 尋求機會參與到開源專案中去，應該知...