一個軟件項目從探索階段到發展方向明確階段,會經歷從簡單到復雜的一個過程,需求的不斷疊加,會讓系統越來越龐大,功能繁多,公司業務的擴展也讓軟件系統的生命周期變的更長..
做軟件測試的人,往往會有這樣的想法:由于軟件的復雜導致了測試的復雜,所以不能指望培訓能給我們很多工作中的實際指導。偏重理論是肯定的,但并非沒有意義,雖然理論同樣可..
由于一些人或組織有心或者無心的制造一些焦慮,讓軟件測試的從業者尤其是剛入行的軟件測試工程師,對軟件測試本身的意義,以及軟件測試職業的發展、技術路徑、充滿了疑慮!在..
“探索性測試(Exploratory Testing)”作為一個技術術語,是測試專家Cem Kaner博士于1983年提出的。有人稱其為一種”測試風格“、也有人稱之為”測試方法“、還有人將其等價于手工測試,..
1.參加軟件產品開發前的需求調研和分析; 2.根據需求,概要設計和開發計劃編寫項目總體測試計劃,詳細測試計劃,測試大綱和測試文檔結構表(測試計劃 a.已上線產品維護以及需求..
本文討論的代碼質量指的是代碼本身的質量,包括復雜度、重復率、代碼風格等要素。代碼是團隊的共同財產,代碼質量是團隊技術水平和管理水平的直接體現。..
測試是任何軟件開發項目中最重要的步驟之一。 如果跳過此過程,則結果可能是災難性的-對項目和公司而言。 但是什么時候應該對軟件進行測試? 在項目完成后進行測試似乎是合乎邏..
在探索性測試中,測試人員會在沒有既定計劃的情況下去檢查目標系統,以發現用戶在瀏覽網站或使用應用程序時,可能遇到的各種缺陷。此方式應盡量能夠模仿最終用戶的各種自由選..
了解 CI 和 CD 解決的問題以正確使用它們至關重要。這將使你的團隊可以改善流程。并避免花力氣追求那些不會給你的過程帶來任何價值的幻想指標。 持續集成是一個團隊問題 如果你..
介紹兩種我使用過的后端測試工具..
模糊測試(Fuzzing),是一種通過向目標系統提供非預期的輸入并監視異常結果來發現軟件漏洞的方法。測試的基本思想就是通過向程序中輸入大量的隨機數據,然后觀察輸入這些數據之..
一個軟件、應用或者App的特性表現在兩個方面,功能性與非功能性。功能性好理解,硬指標,開發過程中的里程碑,一定要啃下的山頭,而非功能性需求更偏“軟”,如App好不好用,速..
測試管理,即是組建和管理一個測試團隊,制定和落實一個有效的測試流程,計劃、設計、執行并跟蹤輸出項目的測試報告,為項目質量提供有效保障。..
通過單測方法補充,可以提前發現一部分問題,減少問題解決的成本,但是由于業務形態的原因, 需求變更頻繁,功能迭代快,補充和維護單測的成本比較高, 在業務方的大部分前端工..
DevOps作為對開發和運維人員都極為重要的系統,有望在2019年甚至更長時間內保持穩定增長。事實上,據IDC預測,到2022年,全球DevOps軟件市場將達到80億美元,比2017年的39億美元有所增長..
測試驅動開發,英文全稱 Test-Driven Development(簡稱 TDD),是由Kent Beck 先生在極限編程(XP)中倡導的開發方法。以其倡導先寫測試程序,然后編碼實現其功能得名。 本文不打算扯過多..
運行 A/B 測試和解釋結果可能非常困難,如果做得不對,可能會得到錯誤的結論。 這篇博文的目的不是要說明在運行 A/B 測試時應該做什么,而是要告訴你不應該做什么。 下面是我們在..
如果想要做成一件事,就要做好風險控制。 風險無處不在。 你若不善待她,就會受到她的懲罰。..
過去一年中,我坐在一位資深的軟件工程師旁邊,可以仔細地觀察他是怎么工作的。我們兩人經常共同編程,使得這項觀察更為容易。此外,在團隊文化中,從背后窺探寫代碼的人并不..
不管是做產品還是做項目,也不管是采用瀑布模型還是敏捷開發,我們都有一個終極目標,就是能按時交付質量可靠的功能,其中質量尤為重要。 本文是我對產品質量的一點思考,如果..