Edited by Chloe, Esther, May (以字母排序)
此次主題是「如何有效率地測試」，因為我們發現很多測試其之間的轉換狀態是很相似的，讓同類型的測試一再出現會花費不必要的測試時間。
希望透過閱讀「有效率地測試」相關的文章，讓測試在最短的時間內，以最少的工作量，發現最大量的 bug，提升測試的效率，發揮最大效益。
繼續閱讀 “如何有效率地測試"
標籤: practice
測試策略的選擇-時間、範圍、成本與質量的平衡
這篇文章還是在強調說要及早開始測試，讓成本降低；然後測試應優先選擇重要的或常使用的地方。這些理論不斷的出現，所以要記得這些測試的重點。
TDD(Test-Driven Development,測試驅動開發)的幾個想法
TDD(Test-Driven Development,測試驅動開發)的幾個想法
他有提到說當要推動一個新方法或東西時，要先把觀念先建立起來，再來一步一步循序漸進，如此一來成功的機率會比較高。所以未來如果要推動新方法時，不要太急著馬上看到成效，而是慢慢的培養觀念，等大家都有這個觀念後再來推行，應該會比較容易成功！
Test Smarter, Not Harder
裡頭有講到隨機抽取測試是個很常見的測試方法，就想到了我們在做像是頻道或是全部曲庫的時候，也是做了隨機抽取測試的部份，希望做這個測試有達到我們所預期的效果。
Hooray for Buggy Software
參考網址：Hooray for Buggy Software
這篇文章將軟體開發分為三個階段，每個階段有不同的測試跟著並行去做。所以在不同階段發現的 bug 數量有不同的意義。應該要針對不同階段去探討，而不是只是因為發現很多 Bug 而感到開心。
軟體可測試性研究和實踐小結
參考網址：软件可测性研究和实践小结
其實在儘早期去加入開發的階段，可以讓我們更瞭解系統的一些結構，或是什麼樣的情況產品會有什麼樣的反應，哪些功能是比較核心的。那如果當文件不足時還是得透過記錄下問題然後主動去詢問開發人員。
What is Equivalence partitioning in Software testing?
What is Equivalence partitioning in Software testing?
等價類劃分的方法是讓我們可以用有效率的方法找出程式當中的錯誤。我們之前在設計 test case 的時候也有利用一點等價類劃分的方式來撰寫，譬如登入的 test case，在眾多正確的帳號中，只需要選其中一組做登入測試，因為都是在有效類別裡。
微軟與 google 如何進行測試
參考網址: How Google Tests Software
這篇文章裡面有提到說開發與測試應該是並行的，寫了一些 code 就立刻去測試，更好的是在寫 code 之前就先想一下這段程式碼該如何被測試，也是 TDD 的精神。另外，這篇文章裡面也有提到當初 google 的測試人員比例很低，所以測試的工作大部份也是由開發人員去測試，主要的原因就是要讓開發人員對他們自己寫的 code 負責，這也是當初我們在討論 Facebook 開發自己做測試的重點。
The Value of Testing & Test Teams
參考網址: The Value of Testing & Test Teams
文中提到測試人員在系統不同的階段都能帶來不同的價值，但是要做到這些也必須在開發的每個階段中測試皆能參與，因此要在開發的初期就與測試相輔相成，才能在不同的階段中帶來不同的價值。
關於百度的 QA
參考網址:
百度的 QA 在做些什麼，裡面也有提到說他們的 QA 有分為 QAT 跟 QAD ，並且會完整參與到產品的開發流程，與 PM 會保持密切的交流，另外，不只去測試 RD 的程式碼，也會參加 code review，並且協助 RD 做好單元測試。
參考網址: 《我眼中的百度QA》第三篇：百度QA的EP职责提升研发效率
裡面有提到說百度的 QA 除了自動化以外，也會與 RD 密切合作，提出一些可測試性的設計概念給 RD。並且也提到說他們在 2012 年時積極使用探索測試。因此我們之後也要慢慢地將書上所看到的東西，理論等慢慢的實踐。
科科和測試 
你必須登入才能發表留言。