在進度較緊的情況下,如何開展測試工作

提高軟件測試效率與測試質(zhì)量的措施由于軟件測試工作的特點以及我國軟件開發(fā)和管理的現(xiàn)實成熟度，軟件測試工作的確會受到諸多外界因素的影響。因此，從表面上看，測試效率和測試質(zhì)量的提高好象不由測試人員所左右。實際上，這種認(rèn)識是不正確的，只要我們測試人員采用一些有效的措施，我們就能變被動為主動，從而更好地發(fā)揮測試的作用。以下結(jié)合工作的直接經(jīng)驗和間接經(jīng)驗，總結(jié)出軟件測試人員提高測試效率和措施（一）：一定要保持良好的工作態(tài)度良好的工作態(tài)度是做好一切事情的基礎(chǔ)。因為，一個工作態(tài)度惡劣的人是很難得到別人的配合和認(rèn)可的。軟件測試工作雖然是QC（質(zhì)量控制），但我個人認(rèn)為，軟件測試人員需要將自己的工作定位為服務(wù)類型的工作而不僅僅是行使“控制”的權(quán)利（特別是在軟件開發(fā)和管理還不規(guī)范的情況下）。有了良好的工作態(tài)度，我們表現(xiàn)出來的行為往往就會更加適合項目的實際需要，也才能真正為提高產(chǎn)品的質(zhì)量發(fā)揮應(yīng)有的作用；否則即使你擁有超強的技術(shù)能力，工作起來也會“舉步唯艱”。措施（二）：腳踏實地工作軟件測試工作相對開發(fā)工作來說，成績的“可見性”要小一些，因此成就感也會小一些。另外，軟件測試工作是一項比較枯燥的工作，它需要測試人員認(rèn)認(rèn)真真、一絲不茍地去重復(fù)那些已經(jīng)測試過一遍甚至是多遍的功能模塊。如果軟件測試人員沒有一個良好的心態(tài)去真心付出，腳踏實地的工作，而是采用應(yīng)付的做法的話，自然也就無法提高測試效率和測試質(zhì)量，甚至讓開發(fā)人員反感，進而影響到后續(xù)測試工作的正常開展。措施（三）：做好前期準(zhǔn)備，規(guī)劃好自己的時間“有備”才能“無患”。前期準(zhǔn)備包括熟悉需求、了解產(chǎn)品特性、準(zhǔn)備測試數(shù)據(jù)、熟悉開發(fā)團隊成員等方面。軟件測試人員一定要提前規(guī)劃好自己的時間，讓自己早熟悉、多熟悉項目各方面的情況。實踐經(jīng)驗表明，測試人員越早介入項目，后續(xù)測試工作就會越有序和順利，測試效率和測試質(zhì)量也就會越高。措施（四）：認(rèn)真組織測試用例評審產(chǎn)品測試實際上就是運行產(chǎn)品，執(zhí)行已經(jīng)準(zhǔn)備好的測試用例（當(dāng)然，每個測試人員也可能會根據(jù)自己的經(jīng)驗臨時準(zhǔn)備并執(zhí)行一些用例），因此測試用例在很大程度上決定了缺陷被發(fā)現(xiàn)的數(shù)量和質(zhì)量，即測試用例的質(zhì)量直接影響到測試質(zhì)量。保證測試用例的質(zhì)量，最有效的辦法就是對其進行認(rèn)真而嚴(yán)格的評審。措施（五）：積極配合開發(fā)人員工作測試工作是一定需要開發(fā)人員配合的，如何才能贏得開發(fā)人員的支持？作為測試人員，我們絕不能消極等待或一味埋怨開發(fā)人員的不理解和不重視。我們首先需要正視自己、改進自己，通過自身的不斷努力讓開發(fā)人員真正體會到測試的價值；同時也需要理解并配合開發(fā)人員的工作；這樣才能贏得開發(fā)人員的支持。配合好了，工作的效率及質(zhì)也就提高了。措施（六）：加強溝通和信息收集我碰到過不少這樣的案例：測試人員測試了一段時間之后，才發(fā)現(xiàn)用戶的需求已經(jīng)變更了，而測試時參考的還是原來的需求。導(dǎo)致這種情況的原因很明顯是缺乏溝通。出現(xiàn)類似這樣的情況，有些測試人員比較喜歡把責(zé)任歸咎于需求分析人員或項目經(jīng)理沒能將變更之后的需求及時告知測試人員（當(dāng)然項目經(jīng)理和需求分析人員是有責(zé)任的）。但要避免這類問題，我們測試人員是完全可以做到的，我們只需要在測試前，和項目組相關(guān)人員溝通一下就可以了。以上六大措施希望對軟件測式人員有幫助，也希望軟件測試工作能夠做的更加的完善。在進度較緊的情況下，如何開展測試工作?1hongyan發(fā)表于2009-4-716:32在進度較緊而資源也不是十分充足的情況下,個人認(rèn)為可以先考慮以下幾個測試點:1.分析該項目中,哪些功能是最重要的.2.哪些功能對用戶最明顯?用戶最關(guān)心的是什么?3.哪些問題對安全問題存在高風(fēng)險?4.在開發(fā)過程中,哪些功能點可以先進行測試.5.哪一部分的代碼最復(fù)雜最容易出錯.哪些是在時間比較緊迫的情況下研發(fā)出來的.6.開發(fā)人員認(rèn)為在應(yīng)用軟件中哪些部分是高風(fēng)險的7.哪些測試可以容易地覆蓋多種功能,8.哪些測試在覆蓋高風(fēng)險部分的測試時使用時間最少2hutter2006發(fā)表于2009-4-717:57從問題的本身來看顯得提問者有點浮躁，進度緊張到什么程度？資源怎么個不足？這些情況作為回答者都不太清楚，當(dāng)然，做了這么多的測試項目我也遇到過類似的情況，例如一個中型的旅游網(wǎng)站今天改版好，老板說明天就要上線的情況，測試組3個人，如何在12小時內(nèi)完成功能測試？（吃個盒飯，睡覺就別想了）我們需要關(guān)注的問題：1.網(wǎng)站的主要業(yè)務(wù)流程要全部跑通（訂單的查詢、預(yù)訂、生成、支付、成功出票等）2.會員的登錄等3.積分的計算以及獎勵方式等。另外我想說的是，開展這類測試工作需要結(jié)合項目本身的性質(zhì)。有些小項目完全可以搞定。有些則不然。這個度需要你自己把握好。3luna_jia發(fā)表于2009-4-810:06進度緊張的情況在做客戶項目的時候可能經(jīng)常遇到，軟件交付的時間是定好了的。一個比較無奈的辦法是和業(yè)務(wù)部門或者客戶溝通，適當(dāng)延緩幾天，交出一個合格的產(chǎn)品比按時交付有利無害，這對一些比較小的項目可能并不困難，但對一些大的客戶，本身對按時交付要求比較嚴(yán)格的，在前期的的需求和開發(fā)階段已經(jīng)擠占了測試時間的情況下，測試方面能采用的應(yīng)對方法：1、關(guān)注重點功能，次要功能僅做簡單測試，只保證不出現(xiàn)嚴(yán)重錯誤。比如業(yè)務(wù)系統(tǒng)主要測試業(yè)務(wù)操作功能，對基礎(chǔ)資料一類的功能適當(dāng)減少測試時間。2、保證在正常業(yè)務(wù)操作下的測試，減少邊界測試、非法數(shù)據(jù)等比較極端的異常測試，異常方面用幾條數(shù)據(jù)稍做測試即可。3、允許軟件中存在并不嚴(yán)重的BUG，不要追求盡善盡美。這些BUG可以暫時不改，或者不做回歸測試?？梢缘较到y(tǒng)上線實施的這個緩沖階段中逐步修復(fù)這些早已發(fā)現(xiàn)的問題。4、資源緊張是一個內(nèi)部的問題。如果能協(xié)調(diào)其他的人員，比如客服人員等做一些簡單的功能、UI方面的測試，開發(fā)人員到了測試階段，任務(wù)相對也少一些，可以加強單元測試，讓一些BUG不要流到測試這里來。這樣都可以減少測試人員本身的一些工作量。5、超時加班。不過要記得維護自己的合法權(quán)益哦。4sogoc發(fā)表于2009-4-810:37測試按最低標(biāo)準(zhǔn)來測試，也就是輸入正常的數(shù)據(jù)，保存，提交，編輯...等等的操作都不會有錯誤。不去測試比如：特殊字符，字段長度，輸入非法，輸入錯誤等等的反應(yīng)，整個系統(tǒng)只針對正確輸入輸入后表現(xiàn)是否正確即可！[[i]本帖最后由sogoc于2009-4-810:40編輯[/i]]5kuailederen發(fā)表于2009-4-810:54[color=Red]看了大家的回答，我后面講述了自己的一個親身經(jīng)歷[/color]這個問題很含糊，缺少背景，不好回答。如同問題：早上起晚了，時間比較緊張，交通又不是很方便，那我應(yīng)該怎么去上班？原問題：有一個測試項目馬上上線，時間比較緊張，測試資源又不是十分充分，那我們應(yīng)該怎么展開測試？問題解讀：1.早上起晚了，必須是一個比較的結(jié)果，說明以往起的要早些。同樣，這個測試項目的工作，按以往經(jīng)驗需要兩個月，而現(xiàn)在只有1個月多點。2.時間比較緊張，說明如果順利的話，還是能夠按時上班的。同樣，測試項目如果順利的話，少bulid次，也是可以順利上線的。3.交通不是很方便，指出準(zhǔn)時上班存在的風(fēng)險，萬一我要等的公交車遲遲不來呢？同樣，測試資源不充分，說明缺少一些測試環(huán)境，測試工具，軟硬件設(shè)施等，導(dǎo)致一些測試工作無從展開。4.我們怎么去上班呢？這才是問題的關(guān)鍵，只有知道遲到的后果，才決定我們怎么去上班的決心和應(yīng)該付出怎樣的代價。如果上班遲到一次就辭退，那么你必須考慮是否找一位飆車高手載你上班，順便說服警車為你開道；如果遲到一次，領(lǐng)導(dǎo)會批評你，然后扣100元錢，那么你只需要盡量趕到就行，遲到了只是讓領(lǐng)導(dǎo)發(fā)發(fā)官威，損失點人民幣而已；如果遲到不會收到懲罰，那你還擔(dān)心什么呢？晨練完再去上班吧。同樣，對這個項目的測試必須有個預(yù)期，也就是測試要達(dá)到的目標(biāo)。①如果項目不能延期，而且必須全功能覆蓋，那么增加人手來抵消時間緊張，必須去購買（或者其它途徑）缺少的測試資源，來滿足測試需要；②如果項目可以延期，但也必須全功能覆蓋，那么考慮到測試成本，可以不增加人手的前提下稍作延期，但測試資源的投入還是必須的；③如果項目可以延期，而且缺少測試資源的部分非重要功能，本次上線可以不測，那么項目做延期，測試該測的功能就行了。④如果問題的原意是：項目測試時間明顯不夠，既不能增加人手，缺少的測試資源肯定不能滿足，又要求全功能覆蓋，必須按時上線，那我們怎么才能把測試工作做的盡量好呢？我的回答是，兄弟跑路吧，這次測試你肯定做不好。如果不想跑路，那么兄弟要雄起一次，大膽的說不。針對這種情況，可能很多人采取的措施是：在現(xiàn)有的條件下，先從能測的重要的功能測起，在有限的時間里測多少算多少。如同考試一樣，明知道答卷時間不夠了，那就先找分多的，容易的做起，蒙上選擇題，最后能做多少做多好吧。試問，試卷你可以得50分不及格，那么我們的軟件可以不及格嗎？試卷上有選擇題可以蒙，1/4的概率，我們的軟件功能點只有正確和不正確，1/2的概率，但你能蒙嗎？試卷這次不會，回頭老師可以答疑，而我們的軟件可以答疑嗎？我覺得軟件測試是一門需要用科學(xué)的精神去對待的學(xué)科，結(jié)果只有正確的才算科學(xué)，過程是需要仔細(xì)嚴(yán)謹(jǐn)?shù)膶Υ椒梢杂卸喾N，但只有一種才是最高效的。所以我們的測試工作是用仔細(xì)嚴(yán)謹(jǐn)?shù)膽B(tài)度，去尋找一條最有效的方法，然后把測試工作做的最好，而不會存在模棱兩可和含糊的結(jié)果。[color=Red]我的經(jīng)歷：[/color]如果測試時間不夠，肯定不能全功能覆蓋，我們是否應(yīng)該只測客戶比較關(guān)心的，比較常用的功能？測試目前主要是產(chǎn)品測試和項目測試。做自己公司的產(chǎn)品測試，如果碰到不能按原計劃完成，本著為質(zhì)量負(fù)責(zé)，一般都可以申請延期。如果是做項目，迫于合同和客戶驗收的壓力，碰到不能按原計劃完成的情況，就是項目風(fēng)險了。而處理的方式基本都是“先測客戶比較關(guān)心的，比較常用的功能”，保證通過客戶驗收，拿到項目款。分析客戶驗收所關(guān)心的功能點（比如客戶最近幾天提過什么需求，肯定要測試，因為時間短，他肯定記得），分析系統(tǒng)最脆弱的地方，走通所有業(yè)務(wù)流程等。而客戶驗收時候，不關(guān)心和不可能想到得地方可以不測試（比如系統(tǒng)中很多同步功能）。我講個自己的經(jīng)歷，做的是國內(nèi)最大保險公司的一個平臺，由幾個系統(tǒng)共同構(gòu)成。由于前期公司為了節(jié)約成本，一直投入比較少的資源，到了后期，明顯感覺到項目不可能如期完成，更要命的是，測試前期沒有跟進，對于這個項目的質(zhì)量沒有任何把握。公司處理措施：1.增加研發(fā)人手，由前期三人，增到5人；2.由我?guī)?名測試人員介入，一名性能測試工程師，開始測試。3.研發(fā)部門經(jīng)理每天跟進進度。4。提出延期請求?？蛻魬B(tài)度：1.對前期項目成果極度不滿意，狠批改項目的負(fù)責(zé)人。2.為了項目進度，非常配合提供測試環(huán)境和資源。3.一頓臉色后，給出15天的延期許可。公司接下來的工作：1.完成未完成的功能和客戶新提出的功能。2.在提供的環(huán)境上進行測試。3.集中處理長期積累的缺陷。4.集成幾個系統(tǒng)。發(fā)現(xiàn)問題：1.沒有良好的需求管理，平時客戶開會或郵件發(fā)來的需求忘記或者沒有完全理解。2.發(fā)現(xiàn)測試進展緩慢，人手不夠，不了解需求，缺少測試環(huán)境，經(jīng)常發(fā)現(xiàn)嚴(yán)重問題而停止測試，發(fā)布新的測試版本。3.幾個系統(tǒng)集成后，發(fā)現(xiàn)更多的新問題4.性能測試結(jié)果表明，性能無法達(dá)到客戶的要求。項目進入風(fēng)險處理期，公司的處理：1.更換項目經(jīng)理2.編造謊話應(yīng)付客戶，說一定能如期交付。3.指示測試人員（具體說是說），只測試客戶關(guān)心的功能和主要業(yè)務(wù)流程。4.指示測試人員（我），修改測試報告，不合格的功能刪除，只寫測試通過的功能。5.指示我修改性能測試數(shù)據(jù)，說明性能指標(biāo)基本達(dá)到。測試人員的處理（我）：1.請示了測試部經(jīng)理后，按項目經(jīng)理的要求做了。項目的結(jié)果：1.交付了一個客戶根本無法正常使用的平臺，客戶暴怒。2.客戶中止了所有與公司的合同，包括結(jié)束了持續(xù)兩年的合作友誼。3.客戶拒付剩余的項目款。4.公司開除所有參與項目的開發(fā)人員，包括項目經(jīng)理（雖沒有影響到測試，但我感覺公司管理混亂，也主動請辭了）。5.公司失去了一個大客戶。這是血的教訓(xùn)，對于公司損失的是錢和信譽，對于客戶損失的是錢和無限拖延的項目以及產(chǎn)品延期造成的競爭力影響。對于開發(fā)，除了瘋狂加班的勞累，還有開除的冤屈；對于測試，沒有堅持自己的職業(yè)道德。我講述的這個經(jīng)歷，可能大部分的項目都不會發(fā)展到這種地步，到我們必須充分意識到風(fēng)險的存在。所以我覺得作為測試，碰到時間緊張，測試資源欠缺，所唯一能做的是上報公司，讓他們協(xié)調(diào)人工和資源，做延期處理。這樣做公司可能因不能如期交付而受到一些經(jīng)濟上的損失，但交付一個合格的產(chǎn)品給客戶，絕對不會有信譽上的損失，從長久看，會有更多的收益。作為測試，你沒有任何權(quán)利自己做風(fēng)險處理---測“客戶關(guān)心的，測主要功能”，都是錯誤的做法。作為測試，堅守住自己的職業(yè)道德，只做自己職責(zé)范圍的工作和力所能及的事；作為測試，不但要為支付給你工資的老板負(fù)責(zé)，也請為你手中的軟件負(fù)責(zé)，為客戶支付的金錢負(fù)責(zé)。[[i]本帖最后由kuailederen于2009-4-1516:53編輯[/i]]6Ancen發(fā)表于2009-4-811:05這種情況，應(yīng)該時有發(fā)生，只是問題不太詳細(xì)，是一個很短的時間還是一個小的開發(fā)周期內(nèi)？這里就列下我們在一個星期的時候遇到這種問題的處理方法吧：1.確定重新確定當(dāng)前測試目標(biāo)，并進行計劃和任務(wù)重新劃分。2.列出軟件功能列表，確定優(yōu)先級。（使用最頻繁的模塊，最容易出錯的模塊，最重要的模塊）3.在時間按照優(yōu)先級對功能列表逐個測試，這過程需要確定一個schedule,詳細(xì)到每人每天。4.首先，功能的完整實現(xiàn)是必須要求的。如果在時間不夠的情況下，對一些用戶體驗性方面的bug可以延后再去做。5.此過程中必會存在測試用例疏漏和覆蓋不完整的情況。這里我們建議是暫時先測試，項目結(jié)束后再維護測試用例。6.因為時間上的緊迫我們就需要開發(fā)即時的解決問題和測試即時的回測。那這樣也就需要測試人員保持與開發(fā)的溝通，跟蹤open的bug，push對應(yīng)的開發(fā)人員。7.要求dailybuild，如果時間緊肯定也會要求更頻繁的發(fā)布，但必須確定系統(tǒng)修改無影響部分功能避免測似人員太多的重復(fù)工作。這樣也是為了讓bug即時的被關(guān)閉。8.另外還有一個難以避免的方法就是加班。7sn_asd520發(fā)表于2009-4-811:47個人認(rèn)為還是能測什么就測什么，如果時間不允許了，那就看那些重要就先測那些8black_tulip發(fā)表于2009-4-909:55我靠，此類帖子看到現(xiàn)在，六樓kuailederen朋友的回帖最高質(zhì)量！同樣是列12345，此人邏輯最清楚。9yolander發(fā)表于2009-4-912:11其實這是個如何制定測試策略的問題，首先前提假設(shè)出來說進度緊，資源不充分，而反過來說即使是在理想條件下，給你足夠的資源預(yù)留足夠的進度，你能做到100%測試么？顯而易見的答案，不能！作為每個測試人員，都要明確這一點“YOUCANNOTTESTEVERTHING!”，測試不是提高質(zhì)量，而是降低風(fēng)險的手段之一，如果項目團隊給你的資源不充分，進度緊，OK，那我們一起來做個風(fēng)險分析吧，而事實上，無論是否資源充分，我們也都需要在制定測試計劃前，先做風(fēng)險分析，再基于風(fēng)險來制定測試策略，那么這個基于風(fēng)險分析的測試策略到底是如何制定呢一、風(fēng)險分析團隊組建：這時我們需要有兩隊人馬，一隊是技術(shù)專家，另一隊是用戶代表（不一定是最終用戶、服務(wù)人員、市場人員、有經(jīng)驗的資深測試人員都可以擔(dān)當(dāng)此角色）二、風(fēng)險分析活動流程：1、首先做需求分析，形成功能列表2、技術(shù)專家為列表中的每一條功能進行評估、打分，至少要考慮如下幾條計分項，如：人員經(jīng)驗（新人風(fēng)險高，有經(jīng)驗的老員工則風(fēng)險較低），是否采用新技術(shù)（全新技術(shù)風(fēng)險高，復(fù)用已有技術(shù)平臺則風(fēng)險低），該功能的接口和與其他功能的交互性（毫無疑問的，接口和交互越多的，則風(fēng)險就越高）等等，其他的可以根據(jù)需要來自我界定3、用戶代表為列表中的每一條功能進行評估、打分，至少要考慮如下幾條計分項，如：失效影響（一旦失效是否有安全隱患？肯定的答案則得分高），商業(yè)價值（是否為產(chǎn)品的賣點），用戶的使用頻率（頻率越高，被探測到問題的風(fēng)險也就越高），如有需要還可以增加計分項4、將各項分?jǐn)?shù)統(tǒng)計之后，形成風(fēng)險矩陣，橫縱坐標(biāo)分別為技術(shù)風(fēng)險得分和用戶代表評估風(fēng)險得分，此時，就可以將功能列表中的功能項劃分出四種不同的風(fēng)險區(qū)間，兩項得分居高的，肯定是測試重點，也是測試力度最應(yīng)該投入的部分，采取的測試手段也應(yīng)該是最嚴(yán)謹(jǐn)?shù)?，居中的兩個區(qū)間（分別為高技術(shù)風(fēng)險或者高用戶代表評估風(fēng)險），則可以適當(dāng)投入力度和資源，風(fēng)險最低的區(qū)間內(nèi)可以權(quán)衡項目的QCD目標(biāo)來確定要不要投入力度和資源以上，一切取決于項目團隊的集體意見，并非是測試人員一個人要考慮的問題，對于預(yù)留風(fēng)險的接受情況一定是經(jīng)過集體權(quán)衡出來的結(jié)果，并不是測試人員的個人職責(zé)，也就是說風(fēng)險要共同分擔(dān)，質(zhì)量是掌握在每個人的手里，并非測試人員說了算三、根據(jù)風(fēng)險矩陣得出測試策略后，再合理分配測試資源投入情況以上方法適用于所有的項目，并非只有緊急或者資源不足的時候才需要做，因為在任何時候，測試都需要平衡資源投入以提高效率，因為“YOUCANNOTTESTEVERYTHING”……[[i]本帖最后由yolander于2009-4-912:13編輯[/i]]10uChrist發(fā)表于2009-4-913:10[quote]原帖由[i]yolander[/i]于2009-4-912:11發(fā)表[url=/redirect.php?goto=findpost&pid=1197994&ptid=145131][img]/images/common/back.gif[/img][/url]其實這是個如何制定測試策略的問題，首先前提假設(shè)出來說進度緊，資源不充分，而反過來說即使是在理想條件下，給你足夠的資源預(yù)留足夠的進度，你能做到100%測試么？顯而易見的答案，不能！作為每個測試人員，都要明...[/quote]LS回答很專業(yè)，受教了11liuchunyanli發(fā)表于2009-4-917:23嚴(yán)重同意6樓的回答，借用10樓的一句話測試人員：YOUCANNOTTESTEVERTHING!同理，測試人員：YOUCANNOTCONTROLEVERTHING!如果是一般的“進度較緊、資源也不是十分充足的情況下”，可以通過加班和盡量協(xié)調(diào)來完成，但其工作方式也由具體情況決定，無法一刀切。6樓切重要害，嚴(yán)重同意，作為測試人員，或只主管測試工作，能做的也只有這么多10樓的回答有點類似于回答“和諧社會如何實現(xiàn)”[[i]本帖最后由liuchunyanli于2009-4-917:25編輯[/i]]12yolander發(fā)表于2009-4-917:33呵呵，和諧社會如何實現(xiàn)，這目標(biāo)太崇高，不敢奢望了我說的其實跟六樓的回答并不沖突，他說的更多的是一種想法，而我說的是做法引用他的回帖里的一句“明知道答卷時間不夠了，那就先找分多的，容易的做起，蒙上選擇題，最后能做多少做多好吧?！薄@就是辦法了但是被測試的系統(tǒng)不是白紙黑字的考卷，分?jǐn)?shù)都已經(jīng)標(biāo)在了上面，所以才需要我們基于風(fēng)險對系統(tǒng)的各項功能進行打分，這樣才能知道哪些題目的分?jǐn)?shù)高，哪些題目的分?jǐn)?shù)低，也好把精力更多的投入到更有用的地方去，盡可能的減少測試的盲目性，即使是加班，也要進行合理規(guī)劃，讓加班也加的更有意義些吧13liuchunyanli發(fā)表于2009-4-1010:53只是覺得“yolander”的說法更適用于項目主管人員，而不只是測試人員或測試主管的工作。并且其中提到的一些工作，包括評估、客戶關(guān)注點等，在項目開始時就應(yīng)該做好了，如果到測試階段再考慮已經(jīng)來不及了。測試人員拿到的是需求、設(shè)計和相關(guān)客戶分析文檔，哪些分值高、哪些會做，已一目了然，只要根據(jù)客戶現(xiàn)有的要求，決定這些題目所用的時間并做完、做好、做對就可以了。如果按照“yolander”的做法，我們還需要提到測試后，針對開發(fā)人員對BUG的修改進行回歸測試等工作，需要對修改BUG后出現(xiàn)的不可預(yù)期的問題進行評估，整個過程的時間都需要調(diào)整。而對于測試人員，我們不是QA，我們不是項目經(jīng)理，做好本職的測試工作，提出測試過程中和過程后可能遇到的各種情況，在規(guī)定的時間內(nèi)完成可完成的工作，盡量找出中存在的BUG就夠了。呵呵，純因問題進行討論，觀點供大家評論[[i]本帖最后由liuchunyanli于2009-4-1010:54編輯[/i]]14feifeimao發(fā)表于2009-4-1011:30說說我的看法吧進度緊，資源不充足，建議這樣測試：1、全員測試：開發(fā)人員、質(zhì)保人員、項目經(jīng)理等等一切可調(diào)用的資源都投入測試中，前提當(dāng)然是不耽誤他們的本職工作哈。但又由于進度緊，那么加班也是不可避免的哈。2、保證最常用、最重要功能點的測試。由于進度緊，這些模塊發(fā)現(xiàn)的bug如果不能及時修改的話，建議要有全面的bug記錄，這樣可以在用戶面對系統(tǒng)吹毛求疵的時候說明，我們知道這些問題的，并且都已經(jīng)記錄下來了，放在下一階段進行修改。3、保證功能測試和性能測試。因為開展白盒測試需要編寫額外的一些程序，花的時間會多一些。所以建議保證進行功能測試和性能測試。交付用戶時，對自己的系統(tǒng)性能畢竟是要有了解的吧。4、必要時提起變更。列出理由和如果不進行變更會有什么風(fēng)險，提出自己的意見和建議，給領(lǐng)導(dǎo)決策去吧。下面再來說說我的另外一點想法進度緊資源不充足下測試，在大家的公司里肯定都存在吧。那為什么會造成這個問題呢？現(xiàn)在中國大多軟件公司都存在這樣的現(xiàn)象，開發(fā)計劃，開始開發(fā)，工期假定為6個月，如果前期工作反工較多，那么最后壓縮的必然是測試的時間，于是就造成這次討論的話題。就像我們常說的治標(biāo)不治本，這次討論的是治標(biāo)的問題，求其根源，還是要治本才行。以上是個人的一點看法，有不當(dāng)之處，還請大家批評指正:)15yolander發(fā)表于2009-4-1016:47[quote]原帖由[i]liuchunyanli[/i]于2009-4-1010:53發(fā)表[url=/redirect.php?goto=findpost&pid=1198560&ptid=145131][img]/images/common/back.gif[/img][/url]只是覺得“yolander”的說法更適用于項目主管人員，而不只是測試人員或測試主管的工作。并且其中提到的一些工作，包括評估、客戶關(guān)注點等，在項目開始時就應(yīng)該做好了，如果到測試階段再考慮已經(jīng)來不及了。測試人...[/quote]所以我一直比較提倡測試人員要盡可能早的參與項目過程，而不是等開發(fā)人員一切都就緒了，他們才開始準(zhǔn)備，在系統(tǒng)工程中，要將測試跟開發(fā)提到平等地位，而且測試與開發(fā)的過程也是互相促進，相輔相成，不能總是居于開發(fā)之后，否則就永遠(yuǎn)無法改變測試人員的被動和無奈16kuailederen發(fā)表于2009-4-1017:39討論的很熱鬧討論的很熱鬧，論壇很少有這種氣氛了。其實我6樓說的，只是一個意思，測試人員要堅持自己的原則。我們的出發(fā)點不是考慮項目成本，也不考慮項目周期，這些不是測試人員關(guān)心的，我們所考慮的只是我們的測試工作是否做的滿意。時間不夠我們要告訴項目負(fù)責(zé)人，讓他解決，資源不夠也要告訴他，讓他調(diào)配。但我們自己不能采取折中的辦法，去自作主張的劃分測試重點，決定優(yōu)先測試的內(nèi)容。這是職責(zé)問題，不是推卸責(zé)任。而我們所堅持的原則就是，絕對不讓測試不充分的軟件通過測試。公司領(lǐng)導(dǎo)可以命令停止測試，但我不會在測試報告中證明測試通過，軟件運行良好，我必須會如實的說明白測試過的地方如何，而那些沒有經(jīng)過我的測試。為什么讓測試部門獨立？那是為了讓這個部門能獨立的決斷。這個題目，時間不夠，資源不夠，你肯定測試不好，解決的辦法只有一個，延期（或增加人手）和調(diào)配資源。你可以被領(lǐng)導(dǎo)強制要求做10樓寫出的那些工作，但一定不要同意出具測試報告證明測試通過?，F(xiàn)在想想，開發(fā)人員大都比較強勢，可能是因為缺少堅持原則的測試吧。17UU1983發(fā)表于2009-4-1309:20這種問題時常發(fā)生你說的這種問題在我以前的項目工作中時常發(fā)生，如果解決不當(dāng)對項目來說是致命的我們來分析下其中的原因這種問題大多出在國內(nèi)項目中，為什么會這樣呢主要根源在于甲方和乙方的立場不同，認(rèn)識不同，導(dǎo)致利益無法達(dá)到最大話一句話互相推卸責(zé)任，不能積極合作我們無法將這種現(xiàn)實扭轉(zhuǎn)所以我們必須積極調(diào)動我們每一根神經(jīng)來應(yīng)對突發(fā)事件沒有資源怎么辦？以前我們的做法是等開發(fā)人員搞定需求，我們在來按照需求寫測試用例搞測試現(xiàn)在我們不但沒有資源而其沒有時間，我們必須調(diào)動自己，從開發(fā)哪里獲取最新需求，如有可能我們可以和客戶直接聯(lián)系獲取一首材料，使我們的工作快速的開展有些人會想這些本不是我們該做的，我們?yōu)槭裁匆?，是的這些本不是測試應(yīng)該做的，但是你要完成你的工作，所以你只能如此當(dāng)我們獲得了資料如何安排進度呢其實這個現(xiàn)實可能大家都不愿意接受就是-----加班但是我們必須接受這個事實這樣的項目通常都是靠我們自己的私人時間加班才堆砌成的。。。。。所以大家努力吧18liuchunyanli發(fā)表于2009-4-1310:09可以上升到領(lǐng)導(dǎo)級處理方法了如果只針對題目，進度較緊，加班；資源不是很充足，在現(xiàn)在資源基礎(chǔ)上進行工作，電飯煲可以做飯，高壓鍋也可以；如果是關(guān)鍵性短缺，無法通過變通解決，且會直接影響測試工作進行，只能申請。放棄單純從測試角度考慮，在分工相對細(xì)一些的公司，在內(nèi)部緊張工作的同時，測試負(fù)責(zé)人可以把該項目的客戶經(jīng)理、項目經(jīng)理、開發(fā)負(fù)責(zé)人和項目總監(jiān)聚在一起，開一個會，看看具體是哪個環(huán)節(jié)出現(xiàn)問題，尋求其他的可能的解決方法。如果是調(diào)研時出了問題，可以讓項目經(jīng)理與客戶協(xié)商進行順延等等。我一直認(rèn)為測試人員的工作只是完成系統(tǒng)中各環(huán)節(jié)的測試，可以包括文檔和系統(tǒng)的測試。但測試人員無法對整個項目實施過程進行控制，我們不是QA，不是項目經(jīng)理，我們沒有對項目風(fēng)險控制的權(quán)力和責(zé)任。我們只在測試測試過程中提出系統(tǒng)中存在的、潛在的問題就可以了。大家提出了很多理論的東西，但在項目實施過程中，每個公司有每個公司的管理方法，各公司中，具體項目的具體情況也是不同的，沒有決對的理論可以解決一切。19yoyoalphax發(fā)表于2009-4-1313:21[quote]原帖由[i]yolander[/i]于2009-4-912:11發(fā)表[url=/redirect.php?goto=findpost&pid=1197994&ptid=145131][img]/images/common/back.gif[/img][/url]其實這是個如何制定測試策略的問題，首先前提假設(shè)出來說進度緊，資源不充分，而反過來說即使是在理想條件下，給你足夠的資源預(yù)留足夠的進度，你能做到100%測試么？顯而易見的答案，不能！作為每個測試人員，都要明...[/quote]這個回答貌似偏向于評審需求分析吧，并不完全是討論測試策略吧還有這句話..:測試不是提高質(zhì)量，而是降低風(fēng)險的手段之一用既..也..是不是比較恰當(dāng)？畢竟，說測試不是提高質(zhì)量有點說不過去...質(zhì)量的定義不是物質(zhì)的某個屬性，而是對某個屬性的滿足程度，不是固定的，而是有度的。不知道我這樣理解對不對20yoyoalphax發(fā)表于2009-4-1313:24:loveliness:沒什么經(jīng)驗，就不在這里參合了，不過看下來，覺得6樓說的比較實在~問題本身就有問題...21阿七發(fā)表于2009-4-1314:43這樣的情況會導(dǎo)致一個結(jié)果-----那就是加班!22hyj785發(fā)表于2009-4-1317:21看項目的規(guī)模，進度，和人手。需求的變動頻率。但是實際上說老實話，看公司和客戶要求了。但是最基本上要求所有業(yè)務(wù)流程都要跑通。使用時沒有太過明顯的延時，不會經(jīng)常出現(xiàn)數(shù)據(jù)庫報錯等情況。時間來不急，就拿著流程圖和需求測吧。分清主次，憑經(jīng)驗了。代碼出來就按流程跑下。bug就截圖，標(biāo)注發(fā)生頁面，不寫步驟了。直接截圖快些。驗證如果是js做的,就去看看方法。那就靠經(jīng)驗了。測試數(shù)據(jù)就自己來，直接在數(shù)據(jù)庫插。一句話，靠自己。上面只是自己能做的，實際情況，如果是公家單位，就不要急。只要能保證基本上能用，就是我上述的標(biāo)準(zhǔn)，拖到最后，也就完工了。23yolander發(fā)表于2009-4-1417:26[quote]原帖由[i]yoyoalphax[/i]于2009-4-1313:21發(fā)表[url=/redirect.php?goto=findpost&pid=1199639&ptid=145131][img]/images/common/back.gif[/img][/url]這個回答貌似偏向于評審需求分析吧，并不完全是討論測試策略吧還有這句話..:測試不是提高質(zhì)量，而是降低風(fēng)險的手段之一用既..也..是不是比較恰當(dāng)？畢竟，說測試不是提高質(zhì)量有點說不過去...質(zhì)量的定義不是物...[/quote]不是評審需求分析，測試人員參加需求分析的評審，其主要目的是幫助需求文檔去除二義性，并提高其可測試性，對不可測試的需求盡早發(fā)現(xiàn)，并建議采用其他方式，如設(shè)計評審等來控制另外關(guān)于“測試不能夠提高質(zhì)量，而是降低風(fēng)險的手段”，那是因為產(chǎn)品的質(zhì)量無論是從前，還是現(xiàn)在都是源于設(shè)計，它從設(shè)計開發(fā)人員手中出生的那一刻，就已經(jīng)決定了其品質(zhì)的好壞，測試只能幫助把它出問題的風(fēng)險降低到可控制的范圍內(nèi)24tengmy發(fā)表于2009-4-1511:29路過，留下幾筆[url]/?uid-47068-action-viewspace-itemid-117069[/url]25imutou發(fā)表于2009-4-1514:05:(貌似碰到下午客戶說要需求，明天就要給他們。當(dāng)然這是maintain的。加上中美的12小時時差，能擠的幾乎全用上了。26aman_cao發(fā)表于2009-4-1516:48測試過程中，這個問題比較突出成本與完全測試是矛盾的，在當(dāng)這種情況下，同意2＃的觀點，測試的重點是軟件是否實現(xiàn)了客戶的需求，所以將客戶的需求整成列表，按工作量和優(yōu)先級（影響范圍）進行分類。優(yōu)先測試高優(yōu)先級，高影響范圍的功能如果是時間短，剛可多人并行工作，如果是硬件問題，則要再投入硬件成本呵呵，雖然進度緊急，但測試人員還是要堅守測試原則的。27zhyb_2008發(fā)表于2009-4-1523:26看貼學(xué)知識.28allenzgw發(fā)表于2009-4-1616:43全方位管控這個問題首先，我覺得這個問題是一個非常具有現(xiàn)實意義的問題，特別是國內(nèi)企業(yè)，這類問題很嚴(yán)重，相對國外企業(yè)項目也會遇到這類問題，但是相對而言更容易解決?；旧显谌魏我粋€項目都沒有說是人員充足，時間充足的，這個永遠(yuǎn)都是多多益善。主要談一下我自己的經(jīng)驗和看法：在進度較緊、資源也不是十分充足的情況下，如何開展測試工作1.對外部，對客戶，如果這個項目是在某個時期才發(fā)現(xiàn)時間緊迫，或者出現(xiàn)什么問題才導(dǎo)致這個時間相當(dāng)緊迫的，那首先第一點，我們要讓客戶經(jīng)理，拖住客戶，向客戶那邊找各種理由多要時間，當(dāng)然，不一定要告訴客戶我們真正的困難，因為也許你說出來，客戶更要著急。即使不能拖時間，也要最起碼不讓客戶再壓縮時間。如果是非常正規(guī)的客戶，你們也是非常正規(guī)的大公司，在和另外一個公司合作，真的有問題，而且很難隱藏的住，那就跟客戶明說，并且尋求客戶的幫助，很多國外大公司還是相當(dāng)開明的，并且喜歡坦誠的這種合作，喜歡共同克服問題，這樣效益也是最高的。當(dāng)然這個看具體情況。這個做目的是穩(wěn)住客戶2.對內(nèi)，分3部分看：1）向領(lǐng)導(dǎo)說明情況（后面會提到不少問題需要老板知道，并且決定，需要首先跟你的老板說明情況）。然后在繼續(xù)要人手，當(dāng)然，你要確保人手進來要能提高進度，而不是延慢進度，帶來更多問題，最好心有某些人選，無論給不給，先要再說。2）對開發(fā)團隊，要求開發(fā)協(xié)助，開發(fā)人員其實很清楚自己的程序那個地方可能有問題，讓他們自己說出來，省的你去找了。然后同時需要問開發(fā)很多具體的問題，這個我們下面談測試團隊內(nèi)部問題是會涉及到和開發(fā)的合作。這里目的先跟開發(fā)打好招呼，需要分一定時間你們合作，到時候不能讓他們賴掉。同時跟QA團隊也打好招呼，先預(yù)告有問題了，在下面具體的論述中我說明談啥內(nèi)容。3）對測試團隊內(nèi)部的處理，這個是重點：a).首先我們需要搞清楚，我們處理這類問題的原理，我們的目標(biāo)是我們要在這，比如剩下的1各月時間內(nèi)，產(chǎn)生最大的效益。同樣的一個月，也許我們以前能發(fā)現(xiàn)60%的缺陷，假設(shè)其中缺陷嚴(yán)重從最嚴(yán)重到最不嚴(yán)重的程度比例是(1:3:6)，那現(xiàn)在我們的目標(biāo)是，能夠發(fā)現(xiàn)70%的缺陷，缺陷的比例是(1.5:4:4.5)，就是說達(dá)到投入產(chǎn)出比例最高，盡量把所有最嚴(yán)重的問題都能找出來，這個是我們的目的。然后剩下30%的缺陷沒有發(fā)現(xiàn)怎么辦？沒關(guān)系，首先他不夠嚴(yán)重，我們遺留下來的缺陷，是那些客戶絕對不會在剛上線使用的前，比如1個月之內(nèi)會發(fā)現(xiàn)的缺陷，我們可以利用上線之后1個月的時間，繼續(xù)測試這個項目，找出剩下的20%，然后打補丁過去，在客戶還沒有完全發(fā)現(xiàn)這些缺陷之前，我們這個補丁包過去就全部搞定了。當(dāng)然這個過程需要老板審批，老板決定后面上線后能繼續(xù)留出多少時間來給這個系統(tǒng)測試，這個也需要先跟老板打好招呼。然后如何做到，下面說具體的方法：b).根據(jù)80-20原理，80%的重要缺陷是發(fā)現(xiàn)在20%的代碼中的，實際中可能不是完全一致。但是這對我們打到最高的效益有相當(dāng)?shù)闹笇?dǎo)意義。c).分析歷史數(shù)據(jù)，或者從QA那里得到相關(guān)的數(shù)據(jù)，查看同類型的產(chǎn)品，或者本產(chǎn)品的以前版本，發(fā)現(xiàn)的各種類型的缺陷的分布，然后和我們當(dāng)前的測試數(shù)據(jù)比較，看看我們的具體的未發(fā)現(xiàn)的問題主要可能在什么地方，然后重點測試。這里其實能分析出來的問題非常多，具體內(nèi)容可以單獨另辟文章討論d).和系統(tǒng)分析員、開發(fā)負(fù)責(zé)人一起分析，各個模塊的重要性，哪些地方關(guān)聯(lián)度最高，缺陷影響最大，這些地方一定要測試。就是把模塊按照重要程度排序，然后測試順序按照這個順序測試，這可以保證測試完最重要的模塊，和主流程。和需求人員、維護人員溝通，找出以前的上線版本經(jīng)常出現(xiàn)的問題，現(xiàn)在盡早關(guān)注搞定。e).測試過程，指導(dǎo)測試人員，對于某些非主流程模塊，小缺陷不需要寫入缺陷庫，找出來記住就好了，不影響功能的話，不寫，直接寫影響功能的缺陷，因為寫缺陷還是消耗不少時間的，還有有些缺陷是否可以直接跟開發(fā)講，自己同時記下來，但是不寫到缺陷庫，我這里是說可以考慮這么做，但是這樣的話對后期的缺陷分析有一點問題，后期也可以補充，這些方法可以考慮，自己權(quán)衡f).跟項目總負(fù)責(zé)人，QA打好招呼，裁剪流程，某些不必要的文檔工作，先等等再說，文檔的中間過程可以盡量省略，但是最后的重要討論結(jié)果最好記錄g).項目進行過程中，注重溝通而不是文檔，加強口頭溝通，并加強溝通效率，面對面的溝通能減少很多非必要的時間消耗，并且問題說明的更加清楚。這個剛開始要和開發(fā)負(fù)責(zé)人打好招呼，否則這么多溝通，人家不一定愿意，可能他會認(rèn)為這樣浪費了他們時間，這個一定要達(dá)成共識，當(dāng)然，你確實要保證溝通高效h).優(yōu)化項目內(nèi)部測試人員安排，一般情況下，我們都是經(jīng)驗豐富的人，能力強的人做比較復(fù)雜的模塊，能力一般的人，做簡單的模塊，這時候，我們可以考慮時間效益，是否需要讓一個能力強的對業(yè)務(wù)熟悉去做相對簡單的模塊，這樣可能只需要50%的時間，讓那個能力一般的做難的部分，可能只多用30%的時間，這樣你還多賺了20%的時間。盡管有一定風(fēng)險，但是你可以考慮，這里我只是說考慮這些因素，考慮優(yōu)化人員的安排。i).以前可能測試人員對業(yè)務(wù)的了解都需要看需求文檔等等，但是，在目前時間緊迫的情況下，可以考慮直接讓需求人員來講解，然后測試?yán)斫?，再?fù)述給需求人員聽，然后需求人員再問他們問題，通過這種方式來確保對業(yè)務(wù)的理解，同樣對開發(fā)也是盡量多口頭溝通，少書面溝通。3.以上步驟，同步進行，自己作為項目測試負(fù)責(zé)人，一定要心里有譜，同時盡量放權(quán)，讓每個人責(zé)任清晰明確，意識到當(dāng)前的形勢，盡早反饋他們發(fā)現(xiàn)的問題，提出各類風(fēng)險。自己做主要掌控全局的人，同時抽查各個地方的質(zhì)量?？傮w就這么多吧，實際操作完全看個人能力和以前對隊伍的培養(yǎng)了。因為平時是流程起作用，但是流程的彈性不夠，關(guān)鍵時刻一定是人的因素更重要，[[i]本帖最后由allenzgw于2009-4-1616:57編輯[/i]]一刀仙發(fā)表于2009-4-1617:371、增加人手，合理分工2、邀請研發(fā)人員參于測試3、關(guān)注主要業(yè)務(wù)流程的實現(xiàn)aliceella發(fā)表于2009-4-1711:38回復(fù)16#的帖子主要的問題是在于不是每個公司都會很重視測試工作的，有的公司在做項目需求分析、概要設(shè)計包括詳細(xì)設(shè)計，都不讓測試人員參與，包括測試計劃都是由開發(fā)人員在編寫，就相當(dāng)于開發(fā)人員根本就沒有把測試放在眼里，等系統(tǒng)做好了，就直接把系統(tǒng)扔給測試人員，說了大體的功能，測試人員就開始盲目的測試了！快樂海豚發(fā)表于2009-4-1711:57我個人看來，這個是需要根據(jù)當(dāng)前情況，客戶最關(guān)心的問題測試，還有就是行業(yè)的幾個測試標(biāo)準(zhǔn)符合就可以了西貝發(fā)表于2009-4-1716:34一、客戶1.企業(yè)80%的利潤來自20%的客戶，看是哪類客戶吧，這個是從利潤角度考慮，從信譽角度考慮當(dāng)然是個個重要了。2.事先跟客戶溝通，讓客戶參與裁決什么才是他們最急最重要最關(guān)心的功能及其他功能優(yōu)先級別排序，也可完成重要功能，以后通過補丁提交次要功能。二、流程時間統(tǒng)籌安排，能盡早開始測試的不等最后累計一起測試，一些準(zhǔn)備工作事先做好，萬事俱備，只欠東風(fēng)嘛。三、協(xié)調(diào)1.與其他部門協(xié)調(diào)調(diào)動人員參與測試。2.合理分工，正確的人做正確的，各取所長。3.溝通。與本部門及其他部門完美溝通，避免因