|
來人人都是產(chǎn)品經(jīng)理【起點(diǎn)學(xué)院】，BAT實(shí)戰(zhàn)派產(chǎn)品總監(jiān)手把手系統(tǒng)帶你學(xué)產(chǎn)品、學(xué)運(yùn)營。  首先說下，我們團(tuán)隊(duì)沒有測試人員，所以測試任務(wù)由產(chǎn)品助理來負(fù)責(zé)。在互聯(lián)網(wǎng)行業(yè)，規(guī)模比較小的公司團(tuán)隊(duì)，測試任務(wù)也多是由產(chǎn)品人員負(fù)責(zé)的，因?yàn)樗麄儗?duì)做的出來的東西比較了解。互聯(lián)網(wǎng)項(xiàng)目一定不能少了測試這一環(huán)境，無論是內(nèi)部項(xiàng)目還是對(duì)外項(xiàng)目。人總是要求自己安心，還有別人放心。 互聯(lián)網(wǎng)產(chǎn)品的測試較之軟件行業(yè)的測試技術(shù)上沒有那么復(fù)雜，但是變化性和更新迭代性比較其略有增加。我們主要實(shí)現(xiàn)的是對(duì)其產(chǎn)品功能的測試，目的就是為了檢驗(yàn)最后工程師與設(shè)計(jì)師做出來的產(chǎn)品與我們最初確立的需求和預(yù)期是否吻合，還有就是發(fā)現(xiàn)其中明顯的使用缺陷和實(shí)施錯(cuò)誤。測試的結(jié)果是一個(gè)產(chǎn)品是否完成的標(biāo)準(zhǔn)，也是一個(gè)產(chǎn)品成功迭代更新的保障。 了解需求文檔和項(xiàng)目原型很多公司沒有專門的需求文檔，在此我們可以把市場客戶調(diào)研問卷，產(chǎn)品立項(xiàng)會(huì)議記錄，策劃人員產(chǎn)出的ppt等等作為需求文檔，我覺得所有和這個(gè)項(xiàng)目有關(guān)的文檔都是需求文檔。然后是項(xiàng)目原型，因?yàn)轫?xiàng)目原型是通過需求討論而產(chǎn)生的，在一定程度上已經(jīng)相當(dāng)全面的體現(xiàn)了需求。原型通常由產(chǎn)品經(jīng)理和助理負(fù)責(zé)，所以他們也是最清楚需求的人。 對(duì)于對(duì)產(chǎn)品了解的人來說其實(shí)需求文檔就在你的腦子里。 舉例說一下產(chǎn)品需求文檔，下面是一個(gè)文章信息發(fā)布模塊的需求文檔：
然后是產(chǎn)品原型，他更直觀的表現(xiàn)了我們要做的東西，對(duì)測試來說，需要清楚地認(rèn)知他的各部分模塊功能還有內(nèi)容是什么。而一些細(xì)節(jié)和可能出現(xiàn)的問題都想用下面的東西來解決，它就是測試用例。 寫測試用例在工程師開始進(jìn)行開發(fā)時(shí)我們就可以寫測試用例了，我的測試用例一般就是兩種，一種是用MindManager思維導(dǎo)圖，一種是用EXCEL表格，由于自己感覺表做起來好頭疼，所以有時(shí)就用Word文檔。 用思維導(dǎo)圖能起到梳理思路的作用，從整體到每個(gè)分支，每個(gè)技術(shù)點(diǎn)都有他需要注意和測試的內(nèi)容，當(dāng)然你不必寫的太詳細(xì)，只要把綱列出來就差不多了，而其中的細(xì)節(jié)通過大腦的聯(lián)想也會(huì)基本概括了。而文檔寫測試用例的作用是可以給工程師看作為他的輔助，還可以用來記錄測試結(jié)果。 測試用例一定要拿出單獨(dú)的時(shí)間來完成，最好不要與其他工作交織著進(jìn)行，是為了更安靜的總結(jié)你自己的思路。 下圖是某項(xiàng)目思維導(dǎo)圖的一部分，在此把此模塊各個(gè)分支都列出來了，但是并沒有詳細(xì)預(yù)測列出測試點(diǎn)，因?yàn)榈谝惶M(fèi)時(shí)間，第二具體實(shí)踐過程中會(huì)出現(xiàn)各種情況，包括以下問題但不限于以下問題。  下面這張圖是測試用例文檔，可以根據(jù)具體事宜設(shè)計(jì)具體文檔，測試用例文檔應(yīng)該是沒有固定格式的，其中的幾個(gè)欄目要點(diǎn)也是有的可以省略，有的可以添加。如果最后需要領(lǐng)導(dǎo)看的話，最好把測試結(jié)果寫清楚。  測試的實(shí)施與管理我們知道有BugFree，Bugzilla等bug管理系統(tǒng)，他們能讓我們更高效的提出bug和管理bug，對(duì)測試出的bug有分級(jí)和指派等功能。但是總是覺得這些管理系統(tǒng)，從安裝，維護(hù)，到管理對(duì)互聯(lián)網(wǎng)行業(yè)來說有些局限性。由于互聯(lián)網(wǎng)更新速度塊，講究速度與創(chuàng)新，所以在bug管理這方面，最好也用互聯(lián)網(wǎng)思維去解決。在這里，用一個(gè)在線項(xiàng)目協(xié)作管理工具就挺好，Tower。 在使用它的過程中，我們每開展一個(gè)項(xiàng)目，就為它創(chuàng)建一個(gè)項(xiàng)目測試專題模塊。然后把測試中的問題提到這個(gè)模塊。怎么表述和提交就不細(xì)說了，按照自己和程序人員的習(xí)慣就行。我們把每個(gè)問題指派給負(fù)責(zé)他的人，他也可以又不懂的在上面進(jìn)行回復(fù)溝通。對(duì)于重要的問題，可以對(duì)題目進(jìn)行標(biāo)注，加急處理。也可以把問題當(dāng)做任務(wù)指派給某個(gè)人，最后勾選完成就可以了。 當(dāng)然已經(jīng)完成的任務(wù)也是可以再打開的，因?yàn)榭赡苡捎诤笃谀承┬薷母鲁霈F(xiàn)新的問題。使得其不得不進(jìn)行回歸測試。 這樣既起到了提交作用，又起到了紀(jì)錄作用，還一定程度上完善了遠(yuǎn)程溝通。最重要的的是，Tower有時(shí)效性，更新速度塊，一個(gè)程序和網(wǎng)站可能有多個(gè)版本。有針對(duì)性，指派任務(wù)明確，大家都有責(zé)任感。不死板，系統(tǒng)界面生動(dòng)，溝通人性化，工作有熱情。 在進(jìn)行一般兩輪測試提交和修改之后，等到上面的任務(wù)都完成，測試也就接近尾聲了。 團(tuán)隊(duì)協(xié)作，交給用戶有時(shí)候由于時(shí)間緊迫或者項(xiàng)目工作量大等，需要團(tuán)隊(duì)其他人員的協(xié)助。對(duì)于一些客戶端產(chǎn)品，需要很多類型的手機(jī)或者平板等，也需要?jiǎng)佑霉镜乃腥藖磉M(jìn)行測試。比如各個(gè)手機(jī)上的現(xiàn)實(shí)問題，兼容問題，不同瀏覽器的兼容問題等。 也可以吸取其他公司的經(jīng)驗(yàn)，就是有獎(jiǎng)測試。在進(jìn)行完常規(guī)測試后把項(xiàng)目版本發(fā)給每一個(gè)公司人員，隨測出來新的問題或者提出新的解決方法就給予他們獎(jiǎng)勵(lì)，這樣就更好的完善了產(chǎn)品。 交給用戶，最終的使用者是用戶。 在我們把它交給用戶之前，我們已經(jīng)做了上面的團(tuán)隊(duì)測試?；静粫?huì)出現(xiàn)特別大的失誤和低級(jí)錯(cuò)誤，甚至已經(jīng)趨于完善。接下來就讓用戶去內(nèi)測吧，來看看他們的智慧吧。而對(duì)于針對(duì)企業(yè)客戶的項(xiàng)目，可以讓他們自己或者他們的幾個(gè)客戶先體驗(yàn)一下。 關(guān)于自動(dòng)化與工具其中包括回歸測試工具，性能測試工具，瀏覽器兼容測試工具等。根據(jù)項(xiàng)目的不同需求會(huì)需要不同的自動(dòng)化工具輔助進(jìn)行測試。 比如回歸測試。它是根據(jù)修復(fù)好了的缺陷再重新進(jìn)行測試。目的在于驗(yàn)證以前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)。一般指對(duì)某已知修正的缺陷再次圍繞它原來出現(xiàn)時(shí)的步驟重新測試。通常確定所需的再測試的范圍時(shí)是比較困難的，特別當(dāng)臨近產(chǎn)品發(fā)布日期時(shí)。因?yàn)闉榱诵拚橙毕輹r(shí)必需更改源代碼，因而就有可能影響這部分源代碼所控制的功能。所以在驗(yàn)證修好的缺陷時(shí)不僅要服從缺陷原來出現(xiàn)時(shí)的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應(yīng)當(dāng)鼓勵(lì)對(duì)所有回歸測試用例進(jìn)行自動(dòng)化測試。工具如Selenium等。 使用的目的是為了節(jié)約時(shí)間與人力，這樣的前提下，如果它們提高了我們的效率會(huì)讓事情更完美。 附件：一個(gè)簡單的思維導(dǎo)圖 
|
|
|
