<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    qileilove

    blog已經(jīng)轉(zhuǎn)移至github,大家請(qǐng)?jiān)L問 http://qaseven.github.io/

    如何保持在QA這條路上, 而不會(huì)想轉(zhuǎn)換到RD去呢?

    這個(gè)問題, 我想是大多數(shù)公司或是QA manager的夢(mèng)靨. 一方面找不到好人才, 一方面人才也不易留住. 很容易地, QA不是離職就是換跑道到RD去. 讓我們來看看Microsoft資深的QA manager如何看待這個(gè)問題.
      在某一場(chǎng)合, 作者被問到一個(gè)問題: 你如何保持在QA這條路上, 而不會(huì)想轉(zhuǎn)換到RD去呢?
      他說他已經(jīng)聽過很多次這樣的問題. 許多人把QA視為是RD的一個(gè)跳板, 一個(gè)先期訓(xùn)練中心. 他說如果是這樣也不錯(cuò), 因?yàn)槟菍?huì)有許多RD知道QA在做什么, 會(huì)比較注重質(zhì)量, 也會(huì)比較容易和QA溝通.
      作者也認(rèn)為并不是因?yàn)镽D要寫code, 所以QA想過去. 其實(shí)QA自己也是需要寫code, 去做automation或是幫助測(cè)試更方面. 他認(rèn)為QA會(huì)想離開是因?yàn)樘郠A manager無法求新, 只考慮shipment和 schedule, 缺乏有求新求變的環(huán)境和心態(tài).
      而至于愿意留下來的QA, 則是因?yàn)樵趖eam里面, 他們有機(jī)會(huì)去做invent, investigate and discover, 使得他們有成就感.
      所以如何讓你的QA愿意留下來呢? 讓他們有機(jī)會(huì)去創(chuàng)新. 如果他們都只是focus 在test cases execution和ship schedule, 那大家都會(huì)想跑的
      以下是一些讀者的響應(yīng)
      ===============================
      calkelpdiver said:
      他提到QA會(huì)想換工作的原因
      (1)  lack of credibility & respect, lack of pay, lack of support, insane work schedules, finger pointing
      (2) getting the opportunity to do new and innovate things in this line of work doesn't come often for the average tester in the average company (Microsoft, and other large shops may be different).
      (3) Want to earn more money (RD's pay is higher)
      ===============================
      swn1 said:
      他提出一個(gè)可能的改善方法: rotation
      Assign testers to development teams, assign developers to test rotations.
      Developers became very conscious of the need for documentable designs, meaningful messages, and such. And customers were shocked to have the phone answered by someone who understood and could actually fix their problem.  Good for everyone.
      ===============================
      ru_altom said:
      他認(rèn)為rotation不太可行, 原因如下
      (1) 你需要假設(shè)RD是一個(gè)好的QA, QA 也是一個(gè)好的RD
      (2) RD 和QA的mindset不同, A tester will write code to break someone else's code, while a developer will aim to write unbreakable code.
      所以他贊同JW的作法:
      Innovation is the best way to keep your testers (and developers as well) content and at their best. Give them a chance to invent, to find new ways, to try their ideas - and they won't leave, not for another department and not for another company.

    posted @ 2014-09-15 09:33 順其自然EVO 閱讀(193) | 評(píng)論 (0)編輯 收藏

    自動(dòng)化測(cè)試—想說愛你不容易

      正如許多事情都有其兩面性一樣,測(cè)試方法也是這樣。要保證測(cè)試方法正確,最簡(jiǎn)單、最直觀地想法就是多寫些測(cè)試用例,從更多地角度去測(cè)試,但這必然增加我們的測(cè)試成本。小步快跑要求我們頻繁進(jìn)行測(cè)試,假如我們重構(gòu)的周期是20分鐘,但測(cè)試卻要花掉10分鐘,那么這樣的成本就實(shí)在太大了。假如這種測(cè)試還是開發(fā)人員手工測(cè)試,每天都有對(duì)同樣的測(cè)試反復(fù)執(zhí)行數(shù)十遍,那么開發(fā)人員估計(jì)就要瘋掉了。
      你可能立即就想到自動(dòng)化測(cè)試了。是的,在許多重構(gòu)的書籍中,大師們都建議我們?cè)谥貥?gòu)開始前,首先建立自動(dòng)化測(cè)試機(jī)制。但遺憾的是,我經(jīng)過多年的實(shí)踐總結(jié)出來的經(jīng)驗(yàn)是,這幾乎不可能實(shí)現(xiàn)。每次重構(gòu),我們面臨的都是一個(gè)個(gè)遺留系統(tǒng)。大多數(shù)遺留系統(tǒng)都有一些共同的特征:代碼凌亂,沒有清晰的接口;代碼間耦合度高,相互依賴嚴(yán)重;web層、業(yè)務(wù)層、數(shù)據(jù)訪問層往往沒有清晰的界限,代碼相互參雜其中。在這樣的情況下,編寫自動(dòng)化測(cè)試代碼是幾乎不可完成的任務(wù)。當(dāng)然,這里所說的自動(dòng)化測(cè)試代碼,是指那些基于JUnit編寫的自動(dòng)化測(cè)試程序
      舉一個(gè)簡(jiǎn)單的例子:假如你現(xiàn)在要測(cè)試一個(gè)開票類,想編寫它的測(cè)試代碼。本來這個(gè)開票類并不復(fù)雜,業(yè)務(wù)也很清晰。但是在函數(shù)傳遞參數(shù)時(shí),其中一個(gè)參數(shù)是Web容器中的Request、Response或Session。這下麻煩了,為了測(cè)試一個(gè)簡(jiǎn)單的函數(shù),我們必須啟動(dòng)整個(gè)Web應(yīng)用,這是我們不可接受的。
      隨后你可能會(huì)說了,我們?yōu)槭裁捶且獋鬟f一個(gè)真正地Request、Response或Session呢?我們Mock一個(gè)假的嘛!想法不錯(cuò),但你真正去嘗試Mock時(shí)你會(huì)發(fā)現(xiàn)這也是一個(gè)不可完成的任務(wù)。Request、Response或Session有許多的狀態(tài),屬性變量中又有對(duì)象,又有屬性變量。除此還有大量集合變量,集合變量里都有什么對(duì)象,天才知道。因此,即使你費(fèi)盡千辛萬苦Mock出來,也可能因某些屬性不對(duì)而使得測(cè)試失敗。
      另一個(gè)寫自動(dòng)化測(cè)試程序比較忌諱的就是訪問數(shù)據(jù)庫(kù)。比如你這次執(zhí)行的插入操作成功了,并不意味著下次執(zhí)行就可以成功。下次執(zhí)行會(huì)報(bào)“主鍵沖突”錯(cuò)誤,出現(xiàn)這個(gè)錯(cuò)誤并不是被測(cè)程序錯(cuò)了,而是測(cè)試程序錯(cuò)了。上次執(zhí)行一個(gè)查詢產(chǎn)生的結(jié)果集,不一定就是下一次執(zhí)行同樣一個(gè)查詢產(chǎn)生的結(jié)果。查詢結(jié)果變了,并不意味著被測(cè)程序錯(cuò)了,而是測(cè)試程序不對(duì)。自動(dòng)化測(cè)試程序之所以能夠自動(dòng)化執(zhí)行,必須要保證測(cè)試過程是可以反復(fù)執(zhí)行的,并且不論什么時(shí)候執(zhí)行都有一個(gè)確定的結(jié)果。
      總之,自動(dòng)化測(cè)試不是銀彈,并不是所有代碼都適合自動(dòng)化測(cè)試。與Web容器或其它設(shè)備驅(qū)動(dòng)相關(guān)的代碼是不適合自動(dòng)化測(cè)試的,因?yàn)槲覀冊(cè)跍y(cè)試的時(shí)候不希望去啟動(dòng)Web容器或其它設(shè)備。因此,我們?cè)谧鲎詣?dòng)化測(cè)試程序前,首先應(yīng)當(dāng)確保要測(cè)試的程序已經(jīng)與Web容器或其它設(shè)備驅(qū)動(dòng)相關(guān)的代碼充分解耦。一個(gè)比較好的辦法就是分離出Web層與BUS層,Web層負(fù)責(zé)從Web容器中獲取數(shù)據(jù),并打包傳遞給BUS層,而BUS層則完成真正需要測(cè)試的業(yè)務(wù)邏輯。
      另一個(gè)不適合自動(dòng)化測(cè)試的就是要訪問數(shù)據(jù)庫(kù)的程序,因?yàn)樗鼈儓?zhí)行的結(jié)果總是與數(shù)據(jù)庫(kù)狀態(tài)有關(guān),無法獲得穩(wěn)定而可以不斷復(fù)現(xiàn)的結(jié)果。所以,我們解決它的最好辦法就是將訪問數(shù)據(jù)庫(kù)的部分Mock掉。如何Mock呢?你不能Mock一個(gè)JDBC,也不能Mock一個(gè)Hibernate,因?yàn)槟嵌歼^于復(fù)雜了,你唯一可以做的就是將DAO層Mock掉。這就要求我們對(duì)系統(tǒng)重構(gòu)的時(shí)候,要將數(shù)據(jù)庫(kù)訪問的代碼從業(yè)務(wù)代碼中脫離出來,寫入到DAO層。最后,被Mock的DAO層代碼并不真正去訪問數(shù)據(jù)庫(kù)。每當(dāng)客戶程序傳入一個(gè)參數(shù)時(shí),它首先作為測(cè)試程序去驗(yàn)證這個(gè)參數(shù)是否與預(yù)期一致,然后返回一個(gè)確定的結(jié)果。

    posted @ 2014-09-15 09:32 順其自然EVO 閱讀(329) | 評(píng)論 (0)編輯 收藏

    MariaDB和MySQL性能測(cè)試比較

     現(xiàn)在選擇繼續(xù)使用MySQL或拋棄它切換到MariaDB有足夠的理由。
      現(xiàn)在把目光移到benchmark上面來,它其實(shí)也是由MariaDB團(tuán)隊(duì)開發(fā)的,并加了一下額外的說明。這篇博客提到了一個(gè)有趣的地方:把MYSQL5.6的線程數(shù)一直增加到16,性能都很好,但是超過了16的話,盡管性能也有提升一點(diǎn)點(diǎn),但比較發(fā)現(xiàn),遠(yuǎn)不如其他版本(包括MairaDB-5.5.28a和MairaDB-10.0.1;參考文章頂部的性能測(cè)試圖)。這在單核計(jì)算機(jī)里面試圖達(dá)到多核多線程的效果的并行程序時(shí),都會(huì)有此類的通病。如果算法設(shè)計(jì)得當(dāng),隨著CPU核心數(shù)的增加,性能也會(huì)跟著提升。當(dāng)然問題是,你必須在并行程序中處理好2個(gè)方面:(1)跨多核的多線程問題(2)矢量化。這也是當(dāng)前面向多核編程的兩個(gè)方向,你編寫的必須能很好的控制這兩個(gè)方面。
      如果沒有正確的編寫代碼將會(huì)得到一個(gè)共同的結(jié)果,即在用8到16個(gè)線程的開始你就想看到好的結(jié)果,但在這些線程運(yùn)行之后你不會(huì)看到你期望的結(jié)果。你將會(huì)看到這個(gè)問題,這意味這可能是算法問題。(這也不是超線程或是硬件線程造成的)這就是我們?cè)谶@里看到MySQL 基準(zhǔn)的問題。對(duì)于我來說,這就是MySQL規(guī)模化產(chǎn)生問題的跡象,這也是令人擔(dān)心的原因之一。MariaDB在同樣的基準(zhǔn)中也有一些小問題,但是比MySQL要輕微的多,只能說是勉強(qiáng)吧;我推測(cè)這個(gè)問題在并行計(jì)算中可能不會(huì)出現(xiàn)。
      我也不知道在測(cè)試中怎樣才能很好的根據(jù)不同機(jī)器指定不同的編譯器來與之匹配。當(dāng)你為Intel編譯代碼時(shí),你需要為目標(biāo)機(jī)器編譯生成合適的SIMD代碼;如果不匹配,你將不會(huì)得到你所期望執(zhí)行的矢量代碼。為了能正確處理,你需要在代碼中插入正確的編譯指示代碼,然后要寫下正確的矢量算法,最后在選擇合適的編譯器。我知道這樣看起來很愚笨,但我看過一個(gè)發(fā)行產(chǎn)品用錯(cuò)誤的編譯器所造成的結(jié)果是你無法想象的。好歹,很明顯,MySQL代碼在多核和矢量化中的優(yōu)化沒有MariaDB好。
      (我真正想看到的是,MySQL或MariaDB的一個(gè)分支為Intel Xeon Phi處理器核心做一個(gè)特別的編譯,使代碼轉(zhuǎn)移到61 核心協(xié)處理器,并且有人能嘗試加速所有244個(gè)線程。可惜我沒有接觸過這樣的機(jī)器。同樣的,如果你想學(xué)習(xí)更多關(guān)于向量化和并行方式編寫代碼方面的知識(shí),檢索最近Intel公司 James Jeffers 與 James Reinders寫的文章“Intel Xeon Phi 協(xié)處理器高性能編程”。)
      很明顯,MariaDB的新特性并不是都這么好——你可能需要連接 Cassandra 來獲取一些數(shù)據(jù),但是我很懷疑你會(huì)使用 MySQL 去做這件事情。關(guān)于這個(gè)平臺(tái)上提供的其他引擎也有類似的爭(zhēng)議。MariaDB的性能看起來在多核環(huán)境下表現(xiàn)不錯(cuò),但是我強(qiáng)烈懷疑其實(shí)通過調(diào)優(yōu),MySQL 也可以做到。
      所以你還應(yīng)該轉(zhuǎn)移到 MariaDB 嗎?
      首先,考慮潛在的風(fēng)險(xiǎn)(高層管理者都喜歡聽風(fēng)險(xiǎn)和利益)。如果你遷移到 MariaDB,你可能會(huì)使用特定于 MariaDB 的特性(但目前似乎還不可能),然后發(fā)現(xiàn)很難再用很小的資源切換回 MySQL 。但是我想說的是,這個(gè)并不真的是一個(gè)風(fēng)險(xiǎn),下面從更大的范圍里討論一些問題。
      考慮一下關(guān)于 Oracle 以及 Oracle 對(duì) MySQL 授權(quán)的問題。免費(fèi)以及開源的 MySQL 要與 Oracle 極具競(jìng)爭(zhēng)力的專有軟件競(jìng)爭(zhēng)。那么,Oracle 會(huì)做什么事情阻止 MySQL 的開發(fā)呢?(一些人可能會(huì)說,這樣的事情已經(jīng)發(fā)生了)
      那么,MySQL 和 MariaDB 的兼容性如何呢?MariaDB 團(tuán)隊(duì)正盡力去保持對(duì) MySQL 的全面兼容,他們繼續(xù)向源碼中提交 bug 修復(fù)。但那些新特性(以及版本方案)表明,盡管盡了最大的努力,這兩個(gè)平臺(tái)還是會(huì)繼續(xù)分裂。
      如果 Oracle 向 MySQL 添加 MariaDB 不采納的新特性,這些特性明顯不會(huì)對(duì)你可用。如果你正在使用 MySQL 不具備的 MariaDB 特性,你將不能輕易地切換到 MySQL 。 MariaDB 表示這樣的情況很可能存在一段時(shí)間,然而你也不能說相同的情況不會(huì)在 MySQL 中出現(xiàn)。就是說,即使 MariaDB 的新特性并不那么有用,但是(在我看來)已經(jīng)有足夠的理由從 MySQL 遷移到 MariaDB 了。
      (在結(jié)束這篇文章前說一件事:即在 blogosphere 的作者提出過的一個(gè)關(guān)鍵問題——服務(wù)協(xié)議。如果在你的公司總經(jīng)理瘋狂到向 Oracle 購(gòu)買了服務(wù)協(xié)議來幫助你開發(fā)管理 MySQL 數(shù)據(jù)庫(kù),那么你可能愿意停留在MySQL 以避免因?yàn)檫`反協(xié)議而造成的財(cái)務(wù)和法律上的問題。但除此以外,我看不到什么理由繼續(xù)使用 MySQL 數(shù)據(jù)庫(kù))

    posted @ 2014-09-15 09:32 順其自然EVO 閱讀(322) | 評(píng)論 (0)編輯 收藏

    測(cè)試用例的關(guān)鍵的認(rèn)知

     無論缺陷預(yù)防工作貫徹落實(shí)地多好,軟件組件總有缺陷。這很明顯,因?yàn)殚_發(fā)商無法阻止/消除軟件開發(fā)周期的所有缺陷。因此,軟件必須進(jìn)行徹底的測(cè)試,然后才交付給最終用戶。測(cè)試人員的責(zé)任是:設(shè)計(jì)既可以(ⅰ)找軟件缺陷,又能(ii )評(píng)估該軟件的性能,可用性和可靠性等方面的測(cè)試。
      現(xiàn)在,為了實(shí)現(xiàn)這些目標(biāo),測(cè)試人員必須(往往是從一個(gè)非常大的執(zhí)行域中)選擇和/或制定測(cè)試用例的有限數(shù)量。不幸的是,完整的測(cè)試通常不是在這個(gè)范圍,預(yù)算和時(shí)間的約束內(nèi)實(shí)現(xiàn)和/或執(zhí)行的。重要的是,當(dāng)測(cè)試開始失控且不按計(jì)劃地運(yùn)行時(shí),由于預(yù)期無法實(shí)際,測(cè)試人員往往承受了來自管理層和利益相關(guān)者的巨大壓力。
      因此,測(cè)試人員必須有效地計(jì)劃測(cè)試并制定正確的測(cè)試用例,選擇并執(zhí)行合適的用例,監(jiān)控過程,以確保有效利用工作資源和時(shí)間。所以,要列出這些無疑是一項(xiàng)艱巨的任務(wù);要有效地實(shí)施,測(cè)試人員需要受過適當(dāng)?shù)慕逃团嘤?xùn)并擁有贏得管理層支持的能力。
      一般情況下,測(cè)試人員會(huì)用兩種不同的測(cè)試方法,其中,使用常規(guī)方法,測(cè)試人員主要是嘗試用所有可能的輸入去測(cè)試一個(gè)模塊或組件,用所有可能的軟件結(jié)構(gòu)去實(shí)踐。盡管這種做法仍在使用,測(cè)試人員卻在慢慢灌輸推理軟件的一切的價(jià)值,最終使他們能夠檢測(cè)出所有可能存在的缺陷。但見多識(shí)廣且有學(xué)問的測(cè)試員們都明白,這在現(xiàn)實(shí)或經(jīng)濟(jì)上是不可行,不可實(shí)現(xiàn)的目標(biāo)。
      現(xiàn)在,另一種方法可能就是讓測(cè)試員們隨機(jī)選擇測(cè)試輸入,希望這些測(cè)試能將大的缺陷找出來。不過,測(cè)試專家認(rèn)為,隨機(jī)生成的測(cè)試輸入在評(píng)估系統(tǒng)的質(zhì)量屬性方面表現(xiàn)紀(jì)錄欠佳。所以,從測(cè)試的角度來看,這是一個(gè)無休止的爭(zhēng)論和懸而未決的問題。盡管如此,我們還是認(rèn)為,測(cè)試員的最終目標(biāo)是了解測(cè)試的功能、輸入/輸出域和使用環(huán)境,等等。
      同樣,對(duì)于某些特定類型的測(cè)試,測(cè)試人員也需要詳細(xì)地了解代碼是如何構(gòu)造的。此外,測(cè)試人員也需要利用關(guān)于常在軟件開發(fā)或維護(hù)過程中生成的特定缺陷的知識(shí)。有了這些信息,測(cè)試者就必須明智地選擇測(cè)試輸入的子集,以及被認(rèn)為最有可能找測(cè)試過程中條件和限制內(nèi)的缺陷的測(cè)試輸入組合。然而,這個(gè)過程需要時(shí)間和精力。所以,測(cè)試人員知道且贊同:只有開發(fā)出基于執(zhí)行的測(cè)試的有效測(cè)試用例,才能最大化和/或優(yōu)化對(duì)時(shí)間和資源的利用。
      “有效測(cè)試用例”我們是指:“一個(gè)很可能找出缺陷的測(cè)試用例” 。因此,制定有效測(cè)試用例的能力對(duì)于一個(gè)組織邁向一個(gè)更高質(zhì)量的測(cè)試過程來說是非常重要的;反過來,一個(gè)組織邁向一個(gè)更高質(zhì)量的測(cè)試過程對(duì)制定有效測(cè)試用例的能力也有許多積極影響。
      例如,如果測(cè)試用例是有效的,那么:
      檢測(cè)缺陷的概率更大。
      更有效地利用組織資源。
      測(cè)試再用的可能性更高。
      更符合測(cè)試、項(xiàng)目進(jìn)度、預(yù)算,更重要地,提供更高質(zhì)量的軟件產(chǎn)品的可能性。
      測(cè)試用例設(shè)計(jì)方法 - 概念化
      上面介紹了有效測(cè)試用例的種種好處,但縝密考慮測(cè)試人員用來設(shè)計(jì)這些有效測(cè)試用例的方法也同樣重要。為了回答這個(gè)問題,有必要把軟件作為一個(gè)精心設(shè)計(jì)的產(chǎn)品來查看和/或檢查。現(xiàn)在,有了這個(gè)觀念,就有兩個(gè)基本方法可以用來設(shè)計(jì)測(cè)試用例:
      黑盒(有時(shí)也稱為功能或規(guī)格)測(cè)試方法。
      白盒(有時(shí)也稱為clear或透明盒 )測(cè)試方法。
      使用黑盒測(cè)試方法,測(cè)試人員把SUT (測(cè)試中的軟件)當(dāng)作一個(gè)不知道其內(nèi)部結(jié)構(gòu)(即如何運(yùn)作)的不透明盒子,測(cè)試人員只知道它的作用。使用這種方法的SUT的大小可以是一個(gè)簡(jiǎn)單的模塊、成員函數(shù)、對(duì)象群、一個(gè)子系統(tǒng)、或一個(gè)完整的軟件系統(tǒng)。此外, SUT的基礎(chǔ)行為或功能的描述可以由正式規(guī)格,輸入/處理/輸出圖( IPO),或一套定義明確的先決、后置條件來提供;重要的是,另一個(gè)值得一提的信息來源是:需求規(guī)格說明文檔,通常描述SUT的功能,輸入及預(yù)期輸出。現(xiàn)在,鑒于上述來源,測(cè)試員提供指定輸入到SUT,進(jìn)行測(cè)試運(yùn)行,然后確定所產(chǎn)生的輸出是否與說明文檔中提供的一致。因?yàn)楹诤袦y(cè)試方法只考慮了軟件的行為和功能,它通常被稱為功能測(cè)試,或基于規(guī)范的測(cè)試。這種方法特別有用,極有助于找到要求和規(guī)格中的缺陷。
      與此相反,白盒測(cè)試方法關(guān)注將被測(cè)試的軟件的內(nèi)部結(jié)構(gòu)。因此,使用白盒測(cè)試方法來設(shè)計(jì)測(cè)試用例,測(cè)試人員應(yīng)該先了解結(jié)構(gòu),且為了實(shí)現(xiàn)這一目標(biāo),必須可隨時(shí)參考和理解代碼或適當(dāng)?shù)念悅未a的要求。一旦對(duì)結(jié)構(gòu)有了必要的了解,測(cè)試者就可以選擇合適的測(cè)試用例去實(shí)踐特定的內(nèi)部結(jié)構(gòu)要素,并確定它們是否正常工作。例如,測(cè)試用例通常被設(shè)計(jì)來實(shí)踐所有語(yǔ)句或發(fā)生在一個(gè)模塊或成員函數(shù)中的真/假分支。但是,由于白盒測(cè)試的設(shè)計(jì),執(zhí)行和結(jié)果分析非常耗時(shí),這種方法被限制和/或通常只適用于軟件的小部分,如模塊或成員函數(shù)。然而,白盒測(cè)試方法對(duì)于找出設(shè)計(jì)和基于代碼的控件的邏輯缺陷和順序缺陷,初始化缺陷和數(shù)據(jù)流缺陷等特別有用。
      然而,從測(cè)試員的角度來看,要實(shí)現(xiàn)向用戶提供低缺陷高質(zhì)量的軟件的目標(biāo),必須把這兩種方法都用來設(shè)計(jì)測(cè)試用例。另外,這兩種方法都支持測(cè)試員選擇有限數(shù)量的將被用于測(cè)試的測(cè)試用例。這兩種方法可以相互補(bǔ)充,因?yàn)槊總€(gè)都或許有助于找到某些特定類型的缺陷。重要的是,有了使用這兩種方法設(shè)計(jì)出的一組測(cè)試用例,測(cè)試員找到SUT中各種不同類型缺陷的機(jī)會(huì)就增加了。
      測(cè)試員還有一套有效的可再用的用來進(jìn)行回歸測(cè)試(更改后的重新測(cè)試),以及軟件測(cè)試的新版本。
      上面是一份概要:使用任一設(shè)計(jì)方法制定測(cè)試用例的各種可用方法。
      但是,在使用任一設(shè)計(jì)方法準(zhǔn)備測(cè)試用例前有一些因素需要考慮清楚。它們分別是:
      測(cè)試相關(guān)風(fēng)險(xiǎn)。
      預(yù)期缺陷類型。
      測(cè)試員的知識(shí)和經(jīng)驗(yàn)。
      測(cè)試水平和必須進(jìn)行分組和管理的小組活動(dòng)。
      用于執(zhí)行測(cè)試用例的工具。
      應(yīng)用程序,軟件和問題域的類型。
      客戶要求,等等。
    現(xiàn)在除了上述因素,以下幾個(gè)要點(diǎn)和/或問題在選擇正確的測(cè)試用例設(shè)計(jì)技術(shù)中發(fā)揮了至關(guān)重要的作用:
      基于“經(jīng)驗(yàn)”的測(cè)試用例設(shè)計(jì)
      在基于經(jīng)驗(yàn)的技術(shù)中,是人們的知識(shí),技能和專業(yè)知識(shí)(關(guān)于域,技術(shù)等)構(gòu)成了測(cè)試條件和測(cè)試用例的基礎(chǔ),且對(duì)制定測(cè)試條件和測(cè)試用例很重要。
      在這兒,人們技術(shù)和業(yè)務(wù)兩方面的經(jīng)驗(yàn)都是絕對(duì)必需的,必要的,因?yàn)檫@給測(cè)試分析和設(shè)計(jì)過程提供了不同的角度。
      重要的是,有了他們使用類似系統(tǒng)工作的豐富(前)的經(jīng)驗(yàn),他們或許對(duì)什么會(huì)出錯(cuò),什么有助于測(cè)試有了想法和/或深入的理解。
      因此,基于經(jīng)驗(yàn)的技術(shù)與基于規(guī)范既與基于結(jié)構(gòu)的技術(shù)偕行,又可用于沒有規(guī)格,或者規(guī)格不足或過時(shí)的時(shí)候。
      這可能是用于設(shè)計(jì)測(cè)試低風(fēng)險(xiǎn)系統(tǒng)的測(cè)試用例的唯一技術(shù),但是這種方法可能在非常緊急的情況下特別有用,事實(shí)上,這是導(dǎo)致探索性測(cè)試的一個(gè)因素。
      “隨機(jī)”方式—考慮了嗎?
      通常,任何軟件模塊或系統(tǒng)都有輸入域,從這個(gè)域里選擇并使用測(cè)試輸入數(shù)據(jù)建和/或執(zhí)行測(cè)試用例。
      現(xiàn)在,如果一個(gè)測(cè)試人員從必要輸入域中隨機(jī)選擇輸入,準(zhǔn)備測(cè)試用例,并用它們來測(cè)試應(yīng)用程序,這種方法被稱為“隨機(jī)測(cè)試”。
      例如,如果一個(gè)模塊的有效輸入域是1到100之間所有的正整數(shù),然后用這種方法測(cè)試人員會(huì)隨機(jī)或胡亂地從該領(lǐng)域內(nèi)選擇值,如,選15 , 27和33。
      但是,使用這種方法,也有一些一直無解的問題:
      值(上面的例子中三個(gè)值)足以表明,執(zhí)行測(cè)試用或運(yùn)行例測(cè)試時(shí),模塊符合其規(guī)格嗎?
      是否有其他輸入值,比那些(在本例中)被選中的值,更能找缺陷?
      抑或有效輸入域外的任何值應(yīng)該作為執(zhí)行測(cè)試用例的測(cè)試輸入?
      這就是說,測(cè)試數(shù)據(jù)應(yīng)包括大于100的浮點(diǎn)值,負(fù)值或整數(shù)值?
      因此,上述問題可以立即通過更加結(jié)構(gòu)化的黑盒測(cè)試設(shè)計(jì)方法解決,盡管使用隨機(jī)測(cè)試輸入可以節(jié)省一些時(shí)間和精力,其他測(cè)試輸入選擇方法要求。
      但是,根據(jù)許多測(cè)試專家,隨機(jī)選擇測(cè)試輸入會(huì)產(chǎn)生一個(gè)有效的用于執(zhí)行測(cè)試用例的測(cè)試數(shù)據(jù)集的機(jī)會(huì)非常小,并且對(duì)于一個(gè)更結(jié)構(gòu)化的方法,隨機(jī)方法生成測(cè)試輸入的相對(duì)有效性總成為自省和/或研究的課題。

    posted @ 2014-09-15 09:22 順其自然EVO 閱讀(167) | 評(píng)論 (0)編輯 收藏

    使用Siege測(cè)試Web服務(wù)器

     好處是可以對(duì)一組url進(jìn)行測(cè)試
      參見 http://m.tkk7.com/crespochen/archive/2009/06/02/279573.html 和 http://baike.baidu.com/link?url=Uv0KtwM83hvFTjudQsP37FIfeUDJxMW4Kvodfk6oSTJ4B4ctpr1R6P4CGXdyMExyU7rGL2bold_aGJHwKaV2l_
      郭揚(yáng)提供了1.73上的應(yīng)用,拷貝到/guodian/uap2,部署上Weblogic的Server-0(端口號(hào)是7010)。uap2依賴于uap_server。通過http訪問是
      查詢
      http://192.168.1.73:7010/sguap-client/SmallCase/rest/smallCase/
      增加:
      http://192.168.1.73:7010/sguap-client/SmallCase/rest/smallCase/insert?uuid=XXX&name=XXX
      修改:
      http://192.168.1.73:7010/sguap-client/SmallCase/rest/smallCase/update?uuid=XXX&name=XXX
      刪除
      http://192.168.1.73:7010/sguap-client/SmallCase/rest/smallCase/delete?uuid=XXX
      我們?cè)?.74上做測(cè)試。
      yum -y install siege #安裝siege,安裝不上的話,就從前面提供的URL上下載siege,再安裝。
      據(jù)此,寫了個(gè)shell生成url
    #!/bin/bashfunction get_random_name(){MATRIX="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"LENGTH=8while[${n:=1}-le$LENGTH]; doPASS="$PASS${MATRIX:$(($RANDOM%${#MATRIX})):1}"let n+=1doneecho$PASS}function make_link(){act=$1#echo $actfor i in$seqc; do#echo $i
    linkarr[$i]="\$link/$act?uuid=${idarr[$i]}&name=$(get_random_name)"echo${linkarr[$i]}>>$outdone}num=$1out=$2[ x$num = x ]&&num=10[ x$out = x ]&&out=link.out
    link=http://192.168.1.73:7010/sguap-client/SmallCase/rest/smallCase
    declare-a idarr
    seqc=`seq$num`for i in$seqc; do
    idarr[$i]=$[$RANDOM%1000]doneecholink=$link>$outecho${idarr[@]}declare-a linkarr
    $(make_link insert);
    echo \$link/>>$outecho>>$out
    $(make_link update);
    echo \$link/>>$outecho>>$out
    $(make_link delete);
    echo \$link/>>$outecho>>$out
      測(cè)試命令
      siege -c20 -r2 -f link.out
      參數(shù)說明:
      -c20 并發(fā)20個(gè)用戶
      -r2 重復(fù)循環(huán)2次
      -f link.out 任務(wù)列表:URL列表
      測(cè)試結(jié)果:
    ** SIEGE 3.0.0
    ** Preparing 20 concurrent users for battle.
    The server is now under siege...
    HTTP/1.1 200   0.37 secs:     340 bytes ==> GET  /sguap-client/SmallCase/rest/smallCase/insert
    HTTP/1.1 200   0.38 secs:     340 bytes ==> GET  /sguap-client/SmallCase/rest/smallCase/insert
    ...............................................  #代替很多條HTTP/1.1 ...
    Transactions:          40 hits
    Availability:      100.00 %
    Elapsed time:        2.14 secs
    Data transferred:        0.01 MB
    Response time:        0.21 secs
    Transaction rate:       18.69 trans/sec
    Throughput:        0.01 MB/sec
    Concurrency:        3.87
    Successful transactions:          40
    Failed transactions:           0
    Longest transaction:        0.58
    Shortest transaction:        0.00
      Concurrency是并發(fā)數(shù)
      siege還包含了一些輔助工具:bombardment,是一個(gè)輔助工具:用于按照增量用戶壓力測(cè)試。
      bombardment link.out 5 5 10 1
      這樣測(cè)試,效果也良好,就是費(fèi)時(shí)間。

    posted @ 2014-09-12 10:06 順其自然EVO 閱讀(192) | 評(píng)論 (0)編輯 收藏

    搭建LVS負(fù)載均衡測(cè)試環(huán)境

     實(shí)現(xiàn)負(fù)載均衡有很多種方式
      土豪直接F5,性能最好,價(jià)格最貴
      沒錢也可以使用Apache,Nginx 工作在網(wǎng)絡(luò)的第四層,雖然性能一般,但是很靈活,比如可以將80端口映射到真實(shí)服務(wù)器的8080端口.
      還有一種選擇LVS ,它工作在網(wǎng)絡(luò)的第三層,性能較好,非常穩(wěn)定.
      但是它不能實(shí)現(xiàn)端口的重新映射.因?yàn)樵诰W(wǎng)絡(luò)的第三層,并不清楚端口的信息。
      下面的實(shí)驗(yàn)搭建了一個(gè)LVS負(fù)載均衡測(cè)試環(huán)境,采用DR的方式。
      客戶端訪問LVS前置機(jī)
      這個(gè)請(qǐng)求如下
      源MAC(client mac) 目標(biāo)MAC(DR mac) 源IP(client IP) 目標(biāo)IP(DR IP,VIP)
      LVS前置機(jī)會(huì)將報(bào)文改寫之后轉(zhuǎn)發(fā)真實(shí)的服務(wù)器
      改寫如下
      源MAC(client mac) 目標(biāo)MAX(真實(shí)服務(wù)器MAC) 源IP(client IP) 目標(biāo)IP(DR IP,VIP)
      因?yàn)檎鎸?shí)的服務(wù)器將VIP綁定到了環(huán)回地址,所以會(huì)處理這個(gè)請(qǐng)求,并返回響應(yīng)的報(bào)文.
      網(wǎng)絡(luò)層的源目對(duì)掉
      源MAC(真實(shí)服務(wù)器MAC) 目標(biāo)MAC(client mac) 源IP(DR IP,VIP) 目標(biāo)IP(client IP)
      所以LVS DR的本質(zhì)就是網(wǎng)絡(luò)層的欺騙。
      實(shí)驗(yàn)采用VirtualBox虛擬機(jī),并且配置內(nèi)部網(wǎng)絡(luò),關(guān)閉SELinux和防火墻
      首先,在LVS DR前置機(jī)上安裝ipvsadm命令
      yum install ipvsadm -y
      然后配置兩臺(tái)真實(shí)服務(wù)器(RealServer)的Http服務(wù)
      yum install httpd -y
      service httpd start
      chkconfig httpd on
      并分別改寫/var/www/html/index.html的內(nèi)容為"real server 1"和"real server 2"
      然后在兩臺(tái)真實(shí)服務(wù)器上執(zhí)行如下的腳本
    vim lvs_real.sh
    #!/bin/bash
    # description: Config realserver lo and apply noarp
    SNS_VIP=192.168.16.199
    source /etc/rc.d/init.d/functions
    case "$1" in
    start)
    ifconfig lo:0 $SNS_VIP netmask 255.255.255.255 broadcast $SNS_VIP
    /sbin/route add -host $SNS_VIP dev lo:0
    echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
    echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
    echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
    echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
    sysctl -p >/dev/null 2>&1
    echo "RealServer Start OK"
    ;;
    stop)
    ifconfig lo:0 down
    route del $SNS_VIP >/dev/null 2>&1
    echo "0" >/proc/sys/net/ipv4/conf/lo/arp_ignore
    echo "0" >/proc/sys/net/ipv4/conf/lo/arp_announce
    echo "0" >/proc/sys/net/ipv4/conf/all/arp_ignore
    echo "0" >/proc/sys/net/ipv4/conf/all/arp_announce
    echo "RealServer Stoped"
    ;;
    *)
    echo "Usage: $0 {start|stop}"
    exit 1
    esac
    exit 0
     最后,在DR前置機(jī)上執(zhí)行如下腳本
    vim lvs_dr.sh
    #!/bin/bash
    VIP1=192.168.16.199
    RIP1=192.168.16.3
    RIP2=192.168.16.4
    case "$1" in
    start)
    echo " start LVS of DirectorServer"
    /sbin/ifconfig eth1:0 $VIP1 broadcast $VIP1 netmask 255.255.255.255 broadcast $VIP1 up
    /sbin/route add -host $VIP1 dev eth1:0
    echo "1" >/proc/sys/net/ipv4/ip_forward
    /sbin/ipvsadm -C
    /sbin/ipvsadm -A -t $VIP1:80 -s rr
    /sbin/ipvsadm -a -t $VIP1:80 -r $RIP1:80 -g -w 1
    /sbin/ipvsadm -a -t $VIP1:80 -r $RIP2:80 -g -w 1
    /sbin/ipvsadm
    ;;
    stop)
    echo "close LVS Directorserver"
    echo "0" >/proc/sys/net/ipv4/ip_forward
    /sbin/ipvsadm -C
    /sbin/ifconfig eth1:0 down
    ;;
    *)
    echo "Usage: $0 {start|stop}"
    exit 1
    esac
      通過client訪問LVS前置服務(wù)器,可以看到已經(jīng)實(shí)現(xiàn)了負(fù)載均衡的效果。
      關(guān)于LVS的調(diào)度算法,轉(zhuǎn)載自張逸群的博客
      http://www.zhangyiqun.net/56.html
      1. 大鍋飯調(diào)度(Round-Robin Scheduling RR)
      rr – 純輪詢方式,比較垃圾。把每項(xiàng)請(qǐng)求按順序在真正服務(wù)器中分派。
      2. 帶權(quán)重的大鍋飯調(diào)度(Weighted Round-Robin Scheduling WRR)
      wrr -帶權(quán)重輪詢方式。把每項(xiàng)請(qǐng)求按順序在真正服務(wù)器中循環(huán)分派,但是給能力較大的服務(wù)器分派較多的作業(yè)。
      3. 誰(shuí)不干活就給誰(shuí)分配(Least-Connection LC)
      lc – 根據(jù)最小連接數(shù)分派
      4. 帶權(quán)重的誰(shuí)不干活就給誰(shuí)分配(Weighted Least-Connections WLC 默認(rèn))
      wlc – 帶權(quán)重的。機(jī)器配置好的權(quán)重高。
      5. 基于地區(qū)的最少連接調(diào)度(Locality-Based Least-Connection
      Scheduling LBLC)
      lblc – 緩存服務(wù)器集群。基于本地的最小連接。把請(qǐng)求傳遞到負(fù)載小的服務(wù)器上。
      6. 帶有復(fù)制調(diào)度的基于地區(qū)的最少連接調(diào)度(Locality-Based Least-Connection Scheduling with Replication Scheduling LBLCR)
      lblcr – 帶復(fù)制調(diào)度的緩存服務(wù)器集群。某頁(yè)面緩存在服務(wù)器A上,被訪問次數(shù)極高,而其他緩存服務(wù)器負(fù)載較低,監(jiān)視是否訪問同一頁(yè)面,如果是訪問同一頁(yè)面則把請(qǐng)求分到其他服務(wù)器。
      7. 目標(biāo)散列調(diào)度(Destination Hash Scheduling DH)
      realserver中綁定兩個(gè)ip。ld判斷來者的ISP商,將其轉(zhuǎn)到相應(yīng)的IP。
      8. 源散列調(diào)度(Source Hash Scheduling SH)
      源地址散列。基于client地址的來源區(qū)分。(用的很少)
      9. 最短的期望的延遲(Shortest Expected Delay Scheduling SED)
      基于wlc算法。這個(gè)必須舉例來說了
      ABC三臺(tái)機(jī)器分別權(quán)重123 ,連接數(shù)也分別是123。那么如果使用WLC算法的話一個(gè)新請(qǐng)求進(jìn)入時(shí)它可能會(huì)分給ABC中的任意一個(gè)。使用sed算法后會(huì)進(jìn)行這樣一個(gè)運(yùn)算
      A:(1+1)/1
      B:(1+2)/2
      C:(1+3)/3
      根據(jù)運(yùn)算結(jié)果,把連接交給C 。
      10.最少隊(duì)列調(diào)度(Never Queue Scheduling NQ)
      無需隊(duì)列。如果有臺(tái)realserver的連接數(shù)=0就直接分配過去,不需要在進(jìn)行sed運(yùn)算。
      遇到的問題..
      這個(gè)實(shí)驗(yàn)看著簡(jiǎn)單,做了足足半個(gè)月,但是還有一些不明白的問題,可能和網(wǎng)絡(luò)知識(shí)的匱乏有關(guān)系。
      在DR前置機(jī)上不能通過VIP訪問真實(shí)的服務(wù)器
      在DR前置機(jī)上執(zhí)行命令,報(bào)錯(cuò)如下
      查看ipvsadm,連接狀態(tài)是SYN_RECV
      一開始我使用了三臺(tái)虛擬機(jī),卡在這個(gè)地方很長(zhǎng)時(shí)間。
      后來偶然發(fā)現(xiàn),用第四臺(tái)虛擬機(jī)就可以正常訪問了..

    posted @ 2014-09-12 10:05 順其自然EVO 閱讀(422) | 評(píng)論 (0)編輯 收藏

    Oracle靜態(tài)監(jiān)聽注冊(cè)詳解

     網(wǎng)上有很多關(guān)于oracle 監(jiān)聽靜態(tài)注冊(cè)的文章,但大多都是簡(jiǎn)單說說,并沒有詳細(xì)的例子,這里,將結(jié)合linux as4 下的oracle 10gR2.0.1 舉一個(gè)具體的例子
      1、在 $ORACLE_HOME/network/admin/listener.ora 文件中加入一個(gè)靜態(tài)注冊(cè)的節(jié)點(diǎn)
    [oracle@prudent oracle]$ cd $ORACLE_HOME/network/admin
    [oracle@prudent admin]$ vi listener.ora
    # listener.ora Network Configuration File: /mydatafile2/app/oracle/oracle/product/11.2.0/db_1/network/admin/listener.ora
    # Generated by Oracle configuration tools.
    SID_LIST_LISTENER =
    (SID_LIST =
    (SID_DESC =
    (SID_NAME = PLSExtProc)
    (ORACLE_HOME = /mydatafile2/app/oracle/oracle/product/11.2.0/db_1)
    (PROGRAM = extproc)
    )
    (SID_DESC =
    (SID_NAME = ORCL)
    (ORACLE_HOME = /mydatafile2/app/oracle/oracle/product/11.2.0/db_1)
    (GLOBAL_DBNAME=WOO.COM)
    )
    )
    LISTENER =
    (DESCRIPTION_LIST =
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
    (ADDRESS = (PROTOCOL = TCP)(HOST = prudent)(PORT = 1521))
    )
    )
      注意這里的GLOBAL_DBNAME=WOO.COM
      SID_NAME=ORCL
      這個(gè)SID_NAME 應(yīng)與你對(duì)外提供服務(wù)的 $ORACLE_SID 一致
      [oracle@prudent admin]$ echo $ORACLE_SID
      ORCL
      2、配置對(duì)應(yīng)的tnsnames.ora 中的節(jié)點(diǎn)
    [oracle@prudent admin]$ vi tnsnames.ora
    # tnsnames.ora Network Configuration File: /mydatafile2/app/oracle/oracle/product/11.2.0/db_1/network/admin/tnsnames.ora
    # Generated by Oracle configuration tools.
    ORCL=
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = prudent)(PORT = 1521))
    (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = ORCL)
    )
    )
    WOOORCL=
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = prudent)(PORT = 1521))
    (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = WOO.COM)
    )
    )
    [oracle@prudent admin]$ vi tnsnames.ora
    # tnsnames.ora Network Configuration File: /mydatafile2/app/oracle/oracle/product/11.2.0/db_1/network/admin/tnsnames.ora
    # Generated by Oracle configuration tools.
    ORCL=
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = prudent)(PORT = 1521))
    (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = ORCL)
    )
    )
    WOOORCL=
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = prudent)(PORT = 1521))
    (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = WOO.COM)
    )
    )
    tnsname WOOORCL 中的 SERVICE_NAME=WOO.COM
      這里的服務(wù)名為 WOO.COM 而不是通常的 ORCL,因?yàn)樵?listener.ora 中已經(jīng)注冊(cè)了 WOO.COM,lsnrctl 啟動(dòng)時(shí)會(huì)監(jiān)聽 WOO.COM ,并對(duì)應(yīng)到 SID_NAME=ORCL 上。3、啟動(dòng)監(jiān)聽和服務(wù)
    [oracle@prudent oracle]$ cat dbstart
    lsnrctl start
    sqlplus /nolog <<EOF
    connect /as sysdba
    startup
    EOF
    [oracle@prudent oracle]$ ./dbstart
    LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 13-FEB-2011 20:11:15
    Copyright (c) 1991, 2005, Oracle.  All rights reserved.
    Starting /mydatafile2/app/oracle/oracle/product/11.2.0/db_1/bin/tnslsnr: please wait...
    TNSLSNR for Linux: Version 11.2.0.1.0 - Production
    System parameter file is /mydatafile2/app/oracle/oracle/product/11.2.0/db_1/network/admin/listener.ora
    Log messages written to /mydatafile2/app/oracle/oracle/product/11.2.0/db_1/network/log/listener.log
    Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
    Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=prudent)(PORT=1521)))
    Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
    STATUS of the LISTENER
    ------------------------
    Alias                     LISTENER
    Version                   TNSLSNR for Linux: Version 11.2.0.1.0 - Production
    Start Date                13-FEB-2011 20:11:15
    Uptime                    0 days 0 hr. 0 min. 0 sec
    Trace Level               off
    Security                  ON: Local OS Authentication
    SNMP                      OFF
    Listener Parameter File   /mydatafile2/app/oracle/oracle/product/11.2.0/db_1/network/admin/listener.ora
    Listener Log File         /mydatafile2/app/oracle/oracle/product/11.2.0/db_1/network/log/listener.log
    Listening Endpoints Summary...
    (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
    (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=prudent)(PORT=1521)))
    Services Summary...
    Service "WOO.COM" has 1 instance(s).
    Instance "ORCL", status UNKNOWN, has 1 handler(s) for this service...
    Service "ORCL" has 1 instance(s).
    Instance "ORCL", status UNKNOWN, has 1 handler(s) for this service...
    Service "PLSExtProc" has 1 instance(s).
    Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
    The command completed successfully
    SQL*Plus: Release 11.2.0.1.0 - Production on Sun Feb 13 20:11:16 2011
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    SQL> Connected to an idle instance.
    SQL> ORA-32004: obsolete and/or deprecated parameter(s) specified
    ORACLE instance started.
    Total System Global Area  461373440 bytes
    Fixed Size                  1220000 bytes
    Variable Size              75498080 bytes
    Database Buffers          381681664 bytes
    Redo Buffers                2973696 bytes
    Database mounted.
    Database opened.
    SQL> Disconnected from Oracle Database 10g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
      可以看到
      Service "WOO.COM" has 1 instance(s).
      Instance "ORCL", status UNKNOWN, has 1 handler(s) for this service...
      正在被監(jiān)聽。
      4、驗(yàn)證該服務(wù)可以到達(dá)
    [oracle@prudent oracle]$ tnsping WOOORCL
    TNS Ping Utility for Linux: Version 11.2.0.1.0 - Production on 13-FEB-2011 20:14:59
    Copyright (c) 1997, 2005, Oracle.  All rights reserved.
    Used parameter files:
    /mydatafile2/app/oracle/oracle/product/11.2.0/db_1/network/admin/sqlnet.ora
    Used TNSNAMES adapter to resolve the alias
    Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = prudent)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = WOO.COM)))
    OK (10 msec)
      5、利用靜態(tài)注冊(cè)的服務(wù)登入oracle
    [oracle@prudent oracle]$ sqlplus system@oracleWOOORCL
    SQL*Plus: Release 11.2.0.1.0 - Production on Sun Feb 13 20:17:27 2011
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    SQL> select count(*) from date_log;
    COUNT(*)
    ----------
    SQL>
      至此:已驗(yàn)證該靜態(tài)注冊(cè)可以成功的被解析,監(jiān)聽,連接。

    posted @ 2014-09-12 10:04 順其自然EVO 閱讀(3041) | 評(píng)論 (0)編輯 收藏

    Java學(xué)習(xí)之反射機(jī)制

    java語(yǔ)言區(qū)別于C,C++等準(zhǔn)靜態(tài)語(yǔ)言的最大特點(diǎn)就是java的反射機(jī)制。靜態(tài)語(yǔ)言的最直接定義就是不能在運(yùn)行時(shí)改變程序結(jié)構(gòu)或變量的類型.按照這樣的定義,python,ruby是動(dòng)態(tài)語(yǔ)言,C,C++,Java不是動(dòng)態(tài)語(yǔ)言。雖然在這樣的定義下java不是動(dòng)態(tài)語(yǔ)言,但java的反射機(jī)制(Reflection)卻是可實(shí)現(xiàn)動(dòng)態(tài)的相關(guān)機(jī)制。java反射機(jī)制的作用有
      1、在運(yùn)行時(shí)判斷任意一個(gè)類所具有的成員變量和方法
      2、在運(yùn)行時(shí)構(gòu)造任意一個(gè)類的對(duì)象
      3、在運(yùn)行時(shí)判斷任意一個(gè)對(duì)象所屬的類
      4、在運(yùn)行時(shí)調(diào)用任意一個(gè)對(duì)象的方法
      在java的jdk中,有java.lang.reflect包,在該包中有5個(gè)比較重要的類,
      1、Class類:代表一個(gè)類。
      2、Constructor類:表示類的構(gòu)造方法,通過該類來操作構(gòu)造方法
      3、Field類:代表類的成員變量(屬性)。
      4、Method類:代表類的方法。通過該類可操作方法。
      5、Array類:提供了動(dòng)態(tài)創(chuàng)建數(shù)組,以及訪問數(shù)組的元素的靜態(tài)方法。
      Class 類十分特殊。它和一般類一樣繼承自O(shè)bject,當(dāng)一個(gè)class被加載,或當(dāng)加載器(class loader)的defineClass()被JVM調(diào)用,JVM 便自動(dòng)產(chǎn)生一個(gè)Class 對(duì)象。Class并沒有構(gòu)造方法,不能人為生成。
      要想使用java的反射,首先要獲得類的Class,而獲得的方法有以下幾種
      String str = "CIACs";
      1、Class c1 = str.getClass();
      2、Class c2 = Class.forName("java.lang.String");//調(diào)用Class的靜態(tài)方法
      3、Class c3 = String.class;//每個(gè)包裝類都有自身的class
      獲得Class后,就可以生成對(duì)象了,對(duì)象的構(gòu)造方法有帶參數(shù)的和不帶參數(shù)的,當(dāng)通過不帶參數(shù)的構(gòu)造方法來生成對(duì)象時(shí)有以下兩種方式
      1、通過newInstance()方法生成
      Class<?> classType = str.getClass();
      Object obj = classType.newInstance();
      2、通過構(gòu)造方法實(shí)現(xiàn)
      Class<?> classType = str.getClass();
      Constructor con = classType.getConstructor(new Class[]{});
      Object obj = con.newInstance(new Object[]{});
      若要通過帶參數(shù)的構(gòu)造方法生成對(duì)象實(shí)例,就只能使用如下方法
      Class<?> classType = str.getClass();
      Constructor con = classType.getConstructor(new Class[]{String.class});
      Object obj = con.newInstance(new Object[]{"CIACs"});
     獲得類的對(duì)象實(shí)例后就可以操作對(duì)象的方法和屬性了。以下是一個(gè)例子
    1packagereflection;
    2
    3importjava.lang.reflect.InvocationTargetException;
    4importjava.lang.reflect.Method;
    5
    6publicclassTestClass{
    7
    8publicintadd(inta,intb)
    9{
    10returna+b;
    11}
    12
    13publicStringecho(Stringstr)
    14{
    15returnstr;
    16}
    17
    18publicstaticvoidmain(String[]args)throwsException{
    19Class<?>classType=TestClass.class;//獲得Class
    20
    21ObjectTest=classType.newInstance();//通過classType獲得對(duì)象實(shí)例
    22
    23MethodaddMethod=classType.getMethod("add",newClass[]{int.class,int.class});//運(yùn)行中獲得add方法
    24
    25Objectresult=addMethod.invoke(Test,newObject[]{1,2});//傳入?yún)?shù)調(diào)用add方法
    26
    27System.out.println((Integer)result);
    28
    29MethodechoMethod=classType.getMethod("echo",newClass[]{String.class});
    30
    31Objectresult2=echoMethod.invoke(Test,newObject[]{"http://www.cnblogs.com/zhi-hao/"});
    32
    33System.out.println(result2);
    34
    35}
    36
    37}
      運(yùn)行結(jié)果:
      java學(xué)習(xí)中反射機(jī)制跟動(dòng)態(tài)代理相關(guān),動(dòng)態(tài)代理也是java中的重要知識(shí)。

    posted @ 2014-09-12 09:56 順其自然EVO 閱讀(185) | 評(píng)論 (0)編輯 收藏

    關(guān)于線上與線下性能測(cè)試結(jié)果的差異

     有幾個(gè)學(xué)員經(jīng)常會(huì)對(duì)線上與線下測(cè)試結(jié)果不一樣的問題產(chǎn)生糾結(jié)...所以還是統(tǒng)一寫一篇這樣的文章
      其實(shí)這個(gè)問題本身不用糾結(jié),就好比再牛逼的雙胞胎還是有他們不一樣的地方。本身性能測(cè)試就是一個(gè)預(yù)估風(fēng)險(xiǎn)、排查瓶頸、了解系統(tǒng)現(xiàn)有性能的一個(gè)手段。就好比小時(shí)候你是個(gè)好孩子,但不意味這你長(zhǎng)大了也是一個(gè)好孩子,也許你會(huì)像海波兄那樣的...so,性能測(cè)試只是一種手段,減小風(fēng)險(xiǎn)的方法而已。
      再者,本身線上和線下的測(cè)試結(jié)果就不太具有可比性,原因?yàn)椋?/strong>
      1、線下與線上機(jī)器環(huán)境配置的差異
      2、線下和線上業(yè)務(wù)數(shù)據(jù)的差異,雖然我們線下要最大可能的模擬用戶行為,但你不能拿保證100%的模擬啊,那么多用戶你都能兼顧到?
      3、線下和線上產(chǎn)生壓力時(shí)間的差異,線下是模擬高壓力大并發(fā)的情況,而線上通常壓力不大,大并發(fā)主要集中在某幾個(gè)特殊時(shí)段。
      說道這里,又會(huì)有童鞋繼續(xù)糾結(jié)了,那為毛還做測(cè)試啊,都不準(zhǔn)確,做個(gè)毛毛?好吧,那我想反問你一句,一輛汽車開的人不同,開車的習(xí)慣不同,會(huì)對(duì)車造成不同程度的影響,既然我們沒法100%測(cè)試模擬,那我們干脆就產(chǎn)出汽車后直接賣給你好了,做個(gè)什么測(cè)試和路測(cè),多tmd費(fèi)勁。對(duì)吧?這時(shí)候你不干了,你說那多危險(xiǎn),萬一有大問題呢,不就要了我的命了嗎?呃...這時(shí)候你明白了?那換到性能測(cè)試中就不明白了?
      我們做性能測(cè)試的意義其實(shí)很簡(jiǎn)單:
      1、預(yù)防、評(píng)估風(fēng)險(xiǎn),如果有大問題可以早點(diǎn)發(fā)現(xiàn),減小風(fēng)險(xiǎn)。這里理解極其簡(jiǎn)單,你程序存在內(nèi)存泄漏的問題,難道線下2g和線上4g這個(gè)內(nèi)存差異就不會(huì)有內(nèi)存泄漏了?這就好比,你不會(huì)騎永久牌自行車,難道給你換個(gè)小強(qiáng)牌(瞎編的...)自行車你就瞬間會(huì)騎了?
      2、前端性能測(cè)試。可以通過前端性能測(cè)試保證頁(yè)面性能,給用戶帶來較好的用戶體驗(yàn)。
      3、單接口性能調(diào)優(yōu)。主要目的是優(yōu)化接口性能,排查接口性能問題,及應(yīng)用內(nèi)存隱患。
      比如,我們會(huì)準(zhǔn)備幾種業(yè)務(wù)場(chǎng)景,比如全走DB和全走緩存,分別得到這幾種場(chǎng)景下,應(yīng)用最佳處理能力情況下,在測(cè)試中排查是否存在性能提升的地方,及代碼問題導(dǎo)致的內(nèi)存泄露等。
      4、容量評(píng)估。可以根據(jù)線上機(jī)器比例,線下模擬配比來估算。

    posted @ 2014-09-12 09:55 順其自然EVO 閱讀(207) | 評(píng)論 (0)編輯 收藏

    軟件測(cè)試面試題答案整理

      1、你的測(cè)試職業(yè)發(fā)展是什么?
      測(cè)試經(jīng)驗(yàn)越多,測(cè)試能力越高。所以我的職業(yè)發(fā)展是需要時(shí)間積累的,一步步向著高級(jí)測(cè)試工程師奔去。而且我也有初步的職業(yè)規(guī)劃,前3年積累測(cè)試經(jīng)驗(yàn),按如何做好測(cè)試工程師的要點(diǎn)去要求自己,不斷更新自己改正自己,做好測(cè)試任務(wù)。
      2、你認(rèn)為測(cè)試人員需要具備哪些素質(zhì)
      做測(cè)試應(yīng)該要有一定的協(xié)調(diào)能力,因?yàn)闇y(cè)試人員經(jīng)常要與開發(fā)接觸處理一些問題,如果處理不好的話會(huì)引起一些沖突,這樣的話工作上就會(huì)不好做。還有測(cè)試人員要有一定的耐心,有的時(shí)候做測(cè)試很枯燥乏味。除了耐心,測(cè)試人員不能放過每一個(gè)可能的錯(cuò)誤。
      3、你為什么能夠做測(cè)試這一行
      雖然我的測(cè)試技術(shù)還不是很成熟,但是我覺得我還是可以勝任軟件測(cè)試這個(gè)工作的,因?yàn)樽鲕浖y(cè)試不僅是要求技術(shù)好,還有有一定的溝通能力,耐心、細(xì)心等外在因素。綜合起來看我認(rèn)為我是勝任這個(gè)工作的。
      4、測(cè)試的目的是什么?
      測(cè)試的目的是找出軟件產(chǎn)品中的錯(cuò)誤,是軟件盡可能的符合用戶的要求。當(dāng)然軟件測(cè)試是不可能找出全部錯(cuò)誤的。
      5、測(cè)試分為哪幾個(gè)階段?
      一般來說分為5個(gè)階段:單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試
      6、單元測(cè)試的測(cè)試對(duì)象、目的、測(cè)試依據(jù)、測(cè)試方法?
      測(cè)試對(duì)象是模塊內(nèi)部的程序錯(cuò)誤,目的是消除局部模塊邏輯和功能上的錯(cuò)誤和缺陷。測(cè)試依據(jù)是模塊的詳細(xì)設(shè)計(jì),測(cè)試方法是采用白盒測(cè)試
      7、怎樣看待加班問題
      加班的話我沒有太多意見,但是我還是覺得如果能夠合理安排時(shí)間的話,不會(huì)有太多時(shí)候加班的。
      8、結(jié)合你以前的學(xué)習(xí)和工作經(jīng)驗(yàn),你認(rèn)為如何做好測(cè)試。
      根據(jù)我以前的工作和學(xué)習(xí)經(jīng)驗(yàn),我認(rèn)為做好工作首先要有一個(gè)良好的溝通,只有溝通無障礙了,才會(huì)有好的協(xié)作,才會(huì)有更好的效率,再一個(gè)就是技術(shù)一定要過關(guān),做測(cè)試要有足夠的耐心,和一個(gè)良好的工作習(xí)慣,不懂的就要問,實(shí)時(shí)與同事溝通這樣的話才能做好測(cè)試工作。
      9、你為什么選擇軟件測(cè)試行業(yè)
      因?yàn)橹傲私廛浖y(cè)試這個(gè)行業(yè),覺得他的發(fā)展前景很好。
      10、根據(jù)你以前的工作或?qū)W習(xí)經(jīng)驗(yàn)描述一下軟件開發(fā)、測(cè)試過程,由哪些角色負(fù)責(zé),你做什么
      要有架構(gòu)師、開發(fā)經(jīng)理、測(cè)試經(jīng)理、程序員、測(cè)試員。我在里面主要是負(fù)責(zé)所分到的模塊執(zhí)行測(cè)試用例
      11、根據(jù)你的經(jīng)驗(yàn)說說你對(duì)軟件測(cè)試/質(zhì)量保證的理解
      軟件質(zhì)量保證與測(cè)試是根據(jù)軟件開發(fā)階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)的一批測(cè)試用例(即輸入數(shù)據(jù)和預(yù)期的輸出結(jié)果),并根據(jù)這些測(cè)試用例去運(yùn)行程序,以發(fā)現(xiàn)錯(cuò)誤的過程。它是對(duì)應(yīng)用程序的各個(gè)方面進(jìn)行測(cè)試以檢查其功能、語(yǔ)言有效性及其外觀排布。
      12、軟件測(cè)試的流程是什么?
      需求調(diào)查:全面了解系統(tǒng)概況、應(yīng)用領(lǐng)域、軟件開發(fā)周期、軟件開發(fā)環(huán)境、開發(fā)組織、時(shí)間安排、功能需求、性能需求、質(zhì)量需求及測(cè)試要求等。根據(jù)系統(tǒng)概況進(jìn)行項(xiàng)目所需的人員、時(shí)間和工作量估計(jì)以及項(xiàng)目報(bào)價(jià)。
      制定初步的項(xiàng)目計(jì)劃。
      測(cè)試準(zhǔn)備:組織測(cè)試團(tuán)隊(duì)、培訓(xùn)、建立測(cè)試和管理環(huán)境等。
      測(cè)試設(shè)計(jì):按照測(cè)試要求進(jìn)行每個(gè)測(cè)試項(xiàng)的測(cè)試設(shè)計(jì),包括測(cè)試用例的設(shè)計(jì)和測(cè)試腳本的開發(fā)等。
      測(cè)試實(shí)施:按照測(cè)試計(jì)劃實(shí)施測(cè)試。
      測(cè)試評(píng)估:根據(jù)測(cè)試的結(jié)果,出具測(cè)試評(píng)估報(bào)告。
      13、你對(duì)SQA的職責(zé)和工作活動(dòng)(如軟件度量)的理解?
      SQA就是獨(dú)立于軟件開發(fā)的項(xiàng)目組,通過對(duì)軟件開發(fā)過程的監(jiān)控,來保證軟件的開發(fā)流程按照指定的CMM規(guī)程(如果有相應(yīng)的CMM規(guī)程),對(duì)于不符合項(xiàng)及時(shí)提出建議和改進(jìn)方案,必要時(shí)可以向高層經(jīng)理匯報(bào)以求問題的解決。通過這樣的途徑來預(yù)防缺陷的引入,從而減少后期軟件的維護(hù)成本。SQA主要的工作活動(dòng)包括制定SQA工作計(jì)劃,參與階段產(chǎn)物的評(píng)審,進(jìn)行過程質(zhì)量、功能配置及物理配置的審計(jì)等;對(duì)項(xiàng)目開發(fā)過程中產(chǎn)生的數(shù)據(jù)進(jìn)行度量等等。
      14、說說你對(duì)軟件配置管理的理解
      項(xiàng)目在開發(fā)過程中要用相應(yīng)的配置管理工具對(duì)配置項(xiàng)(包括各個(gè)階段的產(chǎn)物)進(jìn)行變更控制,配置管理的使用取決于項(xiàng)目規(guī)模和復(fù)雜性及風(fēng)險(xiǎn)的水平。軟件的規(guī)模越大,配置管理就越顯得重要。還有在配置管理中,有一個(gè)很重要的概念,那就是基線,是在一定階段各個(gè)配置項(xiàng)的組合,一個(gè)基線就提供了一個(gè)正式的標(biāo)準(zhǔn),隨后的工作便基于此標(biāo)準(zhǔn),并只有經(jīng)過授權(quán)后才能變更這個(gè)標(biāo)準(zhǔn)。配置管理工具主要有CC,VSS,CVS,SVN等,我只用過SVN,對(duì)其他的工具不是很熟悉。
      15、怎樣寫測(cè)試計(jì)劃和測(cè)試用例
      簡(jiǎn)單點(diǎn),測(cè)試計(jì)劃里應(yīng)有詳細(xì)的測(cè)試策略和測(cè)試方法,合理詳盡的資源安排等,至于測(cè)試用例,那是依賴于需求(包括功能與非功能需求)是否細(xì)化到功能點(diǎn),是否可測(cè)試等。
      16、說說主流的軟件工程思想(如CMM、CMMI、RUP,XP,PSP,TSP等)的大致情況及對(duì)他們的理解
      CMM:SW Capability Maturity Model軟件能力成熟度模型,其作用是軟件過程的改進(jìn)、評(píng)估及軟件能力的評(píng)鑒。
      CMMI:Capability Maturity Model Integration能力成熟度模型集成 CMMI融入了大部分最新的軟件管理實(shí)踐,同時(shí)彌補(bǔ)了SW-CMM模型中的缺陷。
      RUP:rational unified process是軟件工程話過程。
      XP:extreme program,即極限編程的意思,適用于小型團(tuán)隊(duì)的軟件開發(fā),像上面第三個(gè)問題就可以結(jié)合原型法采用這樣的開發(fā)流程。要明白測(cè)試對(duì)于xp開發(fā)的重要性,強(qiáng)調(diào)測(cè)試(重點(diǎn)是單元測(cè)試)先行的理念。編程可以明顯提高代碼的質(zhì)量,持續(xù)集成對(duì)于快速定位問題有好處。
      PSP,TSP分別是個(gè)體軟件過程和群體軟件過程。大家都知道,CMM只是告訴你做什么但并沒有告訴你如何做,所以PSP/TSP就是告訴你企業(yè)在實(shí)施CMM的過程中如何做,PSP強(qiáng)調(diào)建立個(gè)人技能(如何制定計(jì)劃、控制質(zhì)量及如何與其他人相互協(xié)作等等)。而TSP著重于生產(chǎn)并交付高質(zhì)量的軟件產(chǎn)品(如何有效的規(guī)劃和管理所面臨的項(xiàng)目開發(fā)任務(wù)等等)。總之,實(shí)施CMM,永遠(yuǎn)不能真正做到能力成熟度的提升,只有將實(shí)施CMM與實(shí)施PSP和TSP有機(jī)結(jié)合起來,才能發(fā)揮最大的效力。因此,軟件過程框架應(yīng)該是CMM/PSP/TSP的有機(jī)集成。
      17、你是怎樣保證軟件質(zhì)量的,也就是說你覺得怎樣才能最大限度的保證軟件的質(zhì)量?
      測(cè)試并不能夠最大限度的保證軟件的質(zhì)量,軟件的高質(zhì)量是開發(fā)和設(shè)計(jì)出來的,而不是測(cè)試出來的,它不僅要通過對(duì)軟件開發(fā)流程的監(jiān)控,使得軟件開發(fā)的各個(gè)階段都要按照指定的規(guī)程進(jìn)行,通過對(duì)各個(gè)階段產(chǎn)物的評(píng)審,QA對(duì)流程的監(jiān)控,對(duì)功能及配置的審計(jì)來達(dá)到開發(fā)的最優(yōu)化。當(dāng)然測(cè)試也是保證軟件質(zhì)量的一個(gè)重要方式,是軟件質(zhì)量保證工程的一個(gè)重要組成部分。
      18、基于目前中國(guó)的國(guó)情,大多數(shù)公司的項(xiàng)目進(jìn)度緊張、人員較少、需求文檔根本沒有或者很不規(guī)范,你認(rèn)為在這種情況下怎樣保證軟件的質(zhì)量?(大多數(shù)公司最想知道的就是在這種困難面前你該怎么保證軟件的質(zhì)量,因?yàn)檫@些公司一般就是這種情況--既不想投入過多又想保證質(zhì)量)
      出現(xiàn)以上的情況,如果僅僅想通過測(cè)試來提高軟件質(zhì)量,那幾乎是不可能的,原因是沒有足夠的時(shí)間讓你去測(cè)試,少而不規(guī)范的文檔導(dǎo)致測(cè)試需求無法細(xì)化到足夠且有針對(duì)行的測(cè)試。所以,作為公司質(zhì)量保證的因該和項(xiàng)目經(jīng)理確定符合項(xiàng)目本身是和的軟件生命周期模型(比如RUP的建材,原型法),明確項(xiàng)目的開發(fā)流程并督促項(xiàng)目組按照此流程開展工作,所有項(xiàng)目組成員(項(xiàng)目經(jīng)理更加重要)都要制定出合理的工作計(jì)劃,加強(qiáng)代碼的單元測(cè)試,在客戶既定的產(chǎn)品交付日期范圍內(nèi),進(jìn)行產(chǎn)品的持續(xù)集成等等,如果時(shí)間允許可以再配合客戶進(jìn)行必要的系統(tǒng)功能測(cè)試。
      19、一個(gè)測(cè)試工程師應(yīng)該具備哪些素質(zhì)和技能?
      1-掌握基本的測(cè)試基礎(chǔ)理論
      2-本著找出軟件存在的問題的態(tài)度進(jìn)行測(cè)試,不要以挑刺的形象出現(xiàn)
      3-可熟練閱讀需求規(guī)格說明書等文檔
      4-以用戶的觀點(diǎn)看問題
      5-有強(qiáng)烈的質(zhì)量意識(shí)
      6-細(xì)心和責(zé)任心
      7-良好的有效的溝通方式(與開發(fā)人員及客戶)
      8-具有以往的測(cè)試經(jīng)驗(yàn)?zāi)軌蚣皶r(shí)準(zhǔn)確的判斷出高危險(xiǎn)區(qū)在何處
      20、做好軟件測(cè)試的一些關(guān)鍵點(diǎn)
      1-測(cè)試人員必須經(jīng)過測(cè)試基礎(chǔ)知識(shí)和理論的相關(guān)培訓(xùn)
      2-測(cè)試人員必須熟悉系統(tǒng)功能和業(yè)務(wù)
      3-測(cè)試要有計(jì)劃,而且測(cè)試方案要和整個(gè)項(xiàng)目計(jì)劃協(xié)調(diào)好
      4-必須實(shí)現(xiàn)編寫測(cè)試用例,測(cè)試執(zhí)行階段必須根據(jù)測(cè)試用例進(jìn)行
      5-易用性,功能,分支,邊界,性能等功能行和非功能性需求都要進(jìn)行測(cè)試
      6-對(duì)于復(fù)雜的流程一定要進(jìn)行流程分支,組合條件分析,再進(jìn)行等價(jià)類劃分準(zhǔn)備相關(guān)測(cè)試數(shù)據(jù)
      7-測(cè)試設(shè)計(jì)的一個(gè)重要內(nèi)容是要準(zhǔn)備好具體的測(cè)試數(shù)據(jù),清楚這個(gè)測(cè)試數(shù)據(jù)是測(cè)試那個(gè)場(chǎng)景或分支的。
      8-個(gè)人任務(wù)平均每三個(gè)測(cè)試用例至少應(yīng)該發(fā)現(xiàn)一個(gè)BUG,否則只能說明測(cè)試用例質(zhì)量不好
      9-除了每天構(gòu)建的重復(fù)測(cè)試可以考慮測(cè)試自動(dòng)化外,其他暫時(shí)都不要考慮去自動(dòng)話
      21、軟件測(cè)試員自身素質(zhì)培養(yǎng)
      1-首先,應(yīng)對(duì)軟件測(cè)試感興趣和對(duì)自己有自信,如果具備了這兩點(diǎn),那么在開發(fā)過程中不管遇到什么樣的困難,相信一定能克服
      2-善于懷疑,實(shí)際上沒有絕對(duì)正確的,總有錯(cuò)誤的地方,具有叛逆心理,別人認(rèn)為不可能發(fā)生的事情,我卻認(rèn)為可能發(fā)生,別人認(rèn)為是對(duì)的,我卻認(rèn)為不是對(duì)的。
      3-打破沙鍋問到底的精神,對(duì)于只出現(xiàn)過一次的BUG一定要找出原因,不解決誓不罷休。
      4-保持一個(gè)良好的心情,否則可能無法把測(cè)試做好。不要把生活中的不愉快的情緒帶到工作中來。
      5-做測(cè)試時(shí)要細(xì)心,不是所有的BUG都能很容易找出,一定要細(xì)心才能找到這些BUG。
      6-靈活一些,聰明一點(diǎn),多造一些容易產(chǎn)生BUG的例子。
      7-在有條件的情況下,多和客戶溝通,他們身上有你所需要的。
      8-設(shè)身處地為客戶著想,從他們的角度去測(cè)試系統(tǒng)。
      9-不要讓程序員,以“這種情況不可能發(fā)生”這句話說服你,相反,你應(yīng)該去說服他,告訴他在客戶心理,并不是這樣的
      10-考慮問題要全面,結(jié)合客戶的需求,業(yè)務(wù)流程和系統(tǒng)的架構(gòu)等多方面考慮問題。
      11-提出問題不要復(fù)雜化,這點(diǎn)和前面矛盾,如果你是一個(gè)新手,暫時(shí)不要管這點(diǎn),因?yàn)樽罱K將有你的小組成員討論解決。
      12-追求完美,對(duì)于新測(cè)試員來說,努力追求完美,這對(duì)你很好,盡管有些事情無法做到,但你應(yīng)該嘗試。
      13-幽默感,能和開發(fā)小組很好的溝通是關(guān)鍵,試著給你的開發(fā)小組找一個(gè)BUG殺手,或?qū)λ麄冋f“我簡(jiǎn)直不敢相信,你寫的程序居然到現(xiàn)在沒有找到BUG”。
      22、為什要在一個(gè)團(tuán)隊(duì)中開展測(cè)試工作?
      因?yàn)闆]有經(jīng)過測(cè)試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量,就好比ISO質(zhì)量認(rèn)證一樣,測(cè)試同樣也需要質(zhì)量認(rèn)證,這個(gè)時(shí)候就需要在團(tuán)隊(duì)中開展軟件測(cè)試的工作。在測(cè)試的過程中發(fā)現(xiàn)軟件中存在的問題,及時(shí)讓開發(fā)人員得知并修改問題,在即將發(fā)布時(shí),從測(cè)試報(bào)告中得出軟件的質(zhì)量情況。
      23、你所熟悉的軟件測(cè)試類型有哪些?
      測(cè)試類型有:功能測(cè)試、性能測(cè)試、界面測(cè)試
      功能測(cè)試在測(cè)試工作中占有比例最大,功能測(cè)試也叫黑盒測(cè)試。
      性能測(cè)試是通過自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。負(fù)載測(cè)試和壓力測(cè)試都屬于性能測(cè)試,兩者可以結(jié)合進(jìn)行。
      界面測(cè)試,界面是軟件與用戶交互的最直接的層,界面的好壞決定用戶對(duì)軟件的第一印象。
      區(qū)別在于,功能測(cè)試關(guān)注產(chǎn)品的所有功能,要考慮到每個(gè)細(xì)節(jié)功能,每個(gè)可能存在的功能問題。性能測(cè)試主要關(guān)注產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測(cè)試則關(guān)注與用戶體驗(yàn)相關(guān)內(nèi)容,用戶使用該產(chǎn)品的時(shí)候是否已用,是否易懂,是否規(guī)范(用戶無意輸入無效的數(shù)據(jù),當(dāng)然考慮到體驗(yàn)性,不能太粗魯?shù)膹棾鼍?。做某個(gè)性能測(cè)試的時(shí)候,首先它可能是個(gè)功能點(diǎn),首先要保證她的功能是沒有問題的,然后再考慮性能的問題。
      24、你認(rèn)為做好測(cè)試用例設(shè)計(jì)工作的關(guān)鍵是什么
      白盒測(cè)試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)構(gòu)。黑盒測(cè)試用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測(cè)試,以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題。軟件的黑盒測(cè)試意味著測(cè)試要在軟件的接口處進(jìn)行,這種方法是把測(cè)試對(duì)象看作是一個(gè)黑盒子,測(cè)試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性,只依據(jù)程序的需求規(guī)格說明書,檢查程序的功能是否符合它的功能說明。因此黑盒測(cè)試又叫功能測(cè)試或者數(shù)據(jù)驅(qū)動(dòng)測(cè)試。黑盒測(cè)試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤:、
      1-是否有不正確或遺漏的功能
      2-在接口上,輸入是否能正確的接受?能否輸出正確的結(jié)果。
      3-是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息(例如數(shù)據(jù)文件)訪問錯(cuò)誤
      4-性能上是否能夠滿足要求
      5-是否有初始化或終止性錯(cuò)誤
      軟件的白盒測(cè)試是對(duì)軟件的過程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測(cè)試對(duì)象看作一個(gè)打開的盒子,它允許測(cè)試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)和有關(guān)信息,設(shè)計(jì)或者選擇測(cè)試用例,對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。通過在不同點(diǎn)檢查程序狀態(tài),確定實(shí)際狀態(tài)是否與預(yù)期的狀態(tài)一直。因此白盒測(cè)試又稱為結(jié)合測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。白盒測(cè)試主要是想對(duì)程序模塊進(jìn)行如下檢查:
      1-對(duì)程序模塊的所有獨(dú)立的執(zhí)行路徑至少測(cè)試一遍。
      2-對(duì)所有的邏輯判定,取“真”與取“假”的兩種情況都能至少測(cè)一遍。
      3-在循環(huán)的邊界和運(yùn)行的界限內(nèi)執(zhí)行循環(huán)體。
      4-測(cè)試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性,等等。
      25、請(qǐng)?jiān)敿?xì)介紹一下各種測(cè)試類型的含義
      1-單元測(cè)試(模塊測(cè)試)是開發(fā)者編寫的一小段代碼,用于檢驗(yàn)被測(cè)試代碼的一個(gè)很小的、很明確的功能是否正確。通常而言,一個(gè)單元測(cè)試是用于判斷某個(gè)特定條件(或者場(chǎng)景)下某個(gè)特定函數(shù)的行為。單元測(cè)試是由程序員自己來完成,最終受益的也是程序員自己。可以這么說,程序員有責(zé)任編寫功能代碼,同時(shí)也就有責(zé)任為自己的代碼編寫單元測(cè)試。執(zhí)行單元測(cè)試,就是為了證明這段代碼的行為和我們期望的一致。
      2-集成測(cè)試(也叫組裝測(cè)試、聯(lián)合測(cè)試)是單元測(cè)試的邏輯擴(kuò)展。它最簡(jiǎn)單的形式是:兩個(gè)已經(jīng)經(jīng)過測(cè)試的單元組合成一個(gè)組件,并且測(cè)試它們之間的接口。從這一層上講,組件是指多個(gè)單元的集成聚合。在現(xiàn)實(shí)方案中,許多單元組合成組件,而這些組件又聚合成程序的更大部分。方法是測(cè)試片段的組合,并最終擴(kuò)展進(jìn)程,將您的模塊與其他組的模塊一起測(cè)試。最后,將構(gòu)成進(jìn)程的所有模塊一起測(cè)試。
      3-系統(tǒng)測(cè)試是將經(jīng)過測(cè)試的子系統(tǒng)裝配成一個(gè)完整系統(tǒng)來測(cè)試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中制定功能的有效方法。(常見的聯(lián)調(diào)測(cè)試)。系統(tǒng)測(cè)試的目的是對(duì)最終軟件系統(tǒng)進(jìn)行全面的測(cè)試,確保最終軟件系統(tǒng)滿足產(chǎn)品需求而遵循系統(tǒng)設(shè)計(jì)。
      4-驗(yàn)收測(cè)試是部署軟件之前的最后一個(gè)測(cè)試操作。驗(yàn)收測(cè)試的目的是確保軟件準(zhǔn)備就緒,并且可以讓用戶將其執(zhí)行軟件的既定功能和任務(wù)。驗(yàn)收測(cè)試是向未來的用戶表明系統(tǒng)能夠像預(yù)訂要求那樣工作。經(jīng)集成測(cè)試后,已經(jīng)按照設(shè)計(jì)把所有的模塊組裝成一個(gè)完整的軟件系統(tǒng),接口錯(cuò)誤也已經(jīng)基本排除了,接著就應(yīng)該進(jìn)一步驗(yàn)證軟件的有效性,這就是驗(yàn)收測(cè)試的任務(wù),即軟件的功能和性能如同用戶所合理期待的那樣。
      26、測(cè)試計(jì)劃工作的目的是什么?測(cè)試計(jì)劃工作的內(nèi)容都包括什么?其中哪些是最重要的?
      軟件測(cè)試計(jì)劃是知道測(cè)試過程的綱領(lǐng)性文件,包含了產(chǎn)品概述、測(cè)試策略、測(cè)試方法、測(cè)試區(qū)域、測(cè)試配置、測(cè)試周期、測(cè)試資源、測(cè)試交流、風(fēng)險(xiǎn)分析等內(nèi)容。借助軟件測(cè)試計(jì)劃,參與測(cè)試的項(xiàng)目成員,尤其是測(cè)試管理人員,可以明確測(cè)試任務(wù)和測(cè)試方法,保持測(cè)試實(shí)施過程的順暢溝通,跟蹤和控制測(cè)試進(jìn)度,應(yīng)對(duì)測(cè)試過程中的各種變更。
      測(cè)試計(jì)劃和測(cè)試詳細(xì)規(guī)格、測(cè)試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系,測(cè)試計(jì)劃主要從宏觀上規(guī)劃測(cè)試活動(dòng)的范圍、方法和資源配置,而測(cè)試詳細(xì)規(guī)格、測(cè)試用例是完成測(cè)試任務(wù)的具體戰(zhàn)術(shù)。所以其中最重要的是測(cè)試策略和測(cè)試方法(最好能先評(píng)審)。
     27、您認(rèn)為做好測(cè)試計(jì)劃工作的關(guān)鍵是什么?
      1-明確測(cè)試的目標(biāo),增強(qiáng)測(cè)試計(jì)劃的實(shí)用性
      編寫軟件測(cè)試計(jì)劃的重要目的就是使測(cè)試過程能夠發(fā)現(xiàn)更多的軟件缺陷,因此軟件測(cè)試計(jì)劃的價(jià)值取決于它對(duì)幫助管理測(cè)試項(xiàng)目,并且找出軟件潛在的缺陷。因此,軟件測(cè)試計(jì)劃中的測(cè)試范圍必須高度覆蓋功能需求,測(cè)試方法必須切實(shí)可行,測(cè)試工具并且具有較高的實(shí)用性,便于使用,生成的測(cè)試結(jié)果準(zhǔn)確
      2-堅(jiān)持“5W”規(guī)則,明確內(nèi)容與過程
      “5W”規(guī)則指的是“WHAT(做什么)”、“WHY(為什么做)”、"WHEN(何時(shí)做)"、"WHERE(在哪里)"、"HOW(如何做)"。利用“5W"規(guī)則創(chuàng)建軟件測(cè)試計(jì)劃,可以幫助測(cè)試團(tuán)隊(duì)理解測(cè)試的目的(WHY),明確測(cè)試的范圍和內(nèi)容(WHAT),確定測(cè)試的開始和結(jié)束日期(WHEN),指出測(cè)試的方法和工具(HOW),給出測(cè)試文檔和軟件存放的位置(WHERE)。
      3-采用評(píng)審和更新機(jī)制,保證測(cè)試計(jì)劃滿足實(shí)際需求
      測(cè)試計(jì)劃完成后,如果沒有經(jīng)過評(píng)審,直接發(fā)送給測(cè)試團(tuán)隊(duì),測(cè)試計(jì)劃內(nèi)容的可能不準(zhǔn)確或遺漏測(cè)試內(nèi)容,或者軟件需求變更引起測(cè)試范圍的增減,而測(cè)試計(jì)劃的內(nèi)容沒有及時(shí)更新,誤導(dǎo)測(cè)試執(zhí)行人員。
      4-分別創(chuàng)建測(cè)試計(jì)劃與測(cè)試詳細(xì)規(guī)格、測(cè)試用例
      應(yīng)把詳細(xì)的測(cè)試技術(shù)指標(biāo)包含到獨(dú)立創(chuàng)建的測(cè)試詳細(xì)規(guī)格文檔,把用于指導(dǎo)測(cè)試小組執(zhí)行過程的測(cè)試用例放到獨(dú)立創(chuàng)建的測(cè)試用例文檔或測(cè)試用例管理數(shù)據(jù)庫(kù)中。測(cè)試計(jì)劃和測(cè)試詳細(xì)規(guī)格、測(cè)試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系,測(cè)試計(jì)劃主要從宏觀上規(guī)劃測(cè)試活動(dòng)的范圍、方法和資源配置,而測(cè)試詳細(xì)規(guī)格、測(cè)試用例是完成測(cè)試任務(wù)的具體戰(zhàn)術(shù)。
      28、當(dāng)開發(fā)人員說不是BUG時(shí),你如何應(yīng)付?
      開發(fā)人員說不是BUG,有2種情況,一是需求沒有確定,所以我可以這么做,這個(gè)時(shí)候可以找來產(chǎn)品經(jīng)理進(jìn)行確認(rèn),需不需要改動(dòng)。3方商量確定好后再看要不要改。二是這種情況不可能發(fā)生,所以不需要修改,這個(gè)時(shí)候,我可以先盡可能的說出是BUG的一句是什么?如果被用戶發(fā)現(xiàn)或出了問題,會(huì)有什么不良結(jié)果?程序員可能會(huì)給你很多理由,你可以對(duì)他的解釋進(jìn)行反駁。如果還是不行,那我可以給這個(gè)問題提出來,跟開發(fā)經(jīng)理和測(cè)試經(jīng)理進(jìn)行確認(rèn),如果要修改就改,如果不要修改就不改。其實(shí)有些真的不是BUG,我也只是建議的方式寫進(jìn)測(cè)試文檔中,如果開發(fā)人員不修改也沒有大問題。如果不是BUG的話,一定要堅(jiān)持自己的立場(chǎng),讓問題得到最后的確認(rèn)。
      29、你自認(rèn)為測(cè)試的優(yōu)勢(shì)在哪里?
      優(yōu)勢(shì)在于我對(duì)測(cè)試堅(jiān)定不移的信心和熱情,雖然經(jīng)驗(yàn)還不足,但測(cè)試需要的基本技能我有信心在工作中得以發(fā)揮。
      30、什么是系統(tǒng)瓶頸?
      瓶頸主要是指整個(gè)軟硬件構(gòu)成的軟件系統(tǒng)某一方面或者幾個(gè)方面能力不能滿足用戶的特定業(yè)務(wù)要求,“特定”是指瓶頸會(huì)在某些條件下會(huì)出現(xiàn),因?yàn)楫吘勾蠖鄶?shù)系統(tǒng)在投入前。
      嚴(yán)格的從技術(shù)角度講,所有的系統(tǒng)都會(huì)有瓶頸,因?yàn)榇蠖鄶?shù)系統(tǒng)的資源配置不是協(xié)調(diào)的,例如CPU使用率剛好達(dá)到100%時(shí),內(nèi)存也正好耗盡的系統(tǒng)不是很多見。因此我們討論系統(tǒng)瓶頸要從應(yīng)用的角度討論:關(guān)鍵是看系統(tǒng)能否滿足用戶需求。在用戶極限使用系統(tǒng)的情況下,系統(tǒng)的響應(yīng)仍然正常,我們可以認(rèn)為改系統(tǒng)沒有瓶頸或者瓶頸不會(huì)影響用戶工作。
      因此我們測(cè)試系統(tǒng)瓶頸主要是實(shí)現(xiàn)下面兩個(gè)目的:
      -發(fā)現(xiàn)“表面”的瓶頸。主要是模擬用戶的操作,找出用戶極限使用系統(tǒng)時(shí)的瓶頸,然后解決瓶頸,這是性能測(cè)試的基本目標(biāo)。
      -發(fā)現(xiàn)潛在的瓶頸并解決,保證系統(tǒng)的長(zhǎng)期穩(wěn)定性。主要是考慮用戶在將來擴(kuò)展系統(tǒng)或者業(yè)務(wù)發(fā)生變化時(shí),系統(tǒng)能夠適應(yīng)變化。滿足用戶目前需求的系統(tǒng)不是最好的,我們?cè)O(shè)計(jì)系統(tǒng)的目標(biāo)是在保證系統(tǒng)整個(gè)軟件生命周期能夠不斷適應(yīng)用戶的變化,或者通過簡(jiǎn)單擴(kuò)展系統(tǒng)就可以適應(yīng)新的變化。
      31、文檔測(cè)試主要包含什么內(nèi)容?
      在國(guó)內(nèi)軟件開發(fā)管理中,文檔管理幾乎是最弱的一項(xiàng),因而在測(cè)試工作中特別容易忽略文檔測(cè)試也就不足為奇了。要想給用戶提供完整的產(chǎn)品,文檔測(cè)試是必不可少的。文檔測(cè)試一般注重下面幾個(gè)方面:
      文檔的完整性:主要是測(cè)試文檔內(nèi)容的全面性與完整性,從總體上把握文檔的質(zhì)量。例如用戶手冊(cè)應(yīng)該包括軟件的所有功能模塊。
      描述與軟件實(shí)際情況的一致性:主要測(cè)試軟件文檔與軟件實(shí)際的一致程度。例如用戶手冊(cè)基本完整后,我們還要注意用戶手冊(cè)與實(shí)際功能描述是否一致。因?yàn)槲臋n往往跟不上軟件版本的更新速度。
      易理解性:主要是檢查文檔對(duì)關(guān)鍵、重要的操作有無圖文說明,文字、圖表是否易于理解。對(duì)于關(guān)鍵、重要的操作僅僅只有文字說明肯定是不夠的,應(yīng)該附有圖表使說明更為直觀和明了。
      文檔中提供操作的實(shí)例:這項(xiàng)檢查內(nèi)容主要針對(duì)用戶手冊(cè)。對(duì)主要功能和關(guān)鍵操作提供的應(yīng)用實(shí)例是否豐富,提供的實(shí)例描述是否詳細(xì)。只有簡(jiǎn)單的圖文說明,而無實(shí)例的用戶手冊(cè)看起來就像是軟件界面的簡(jiǎn)單拷貝,對(duì)于用戶來說,實(shí)際上沒有什么幫助。
      印刷與包裝質(zhì)量:主要是檢查軟件文檔的商品化程度。有些用戶手冊(cè)是簡(jiǎn)單打印、裝訂而成,過于粗糙,不易于用戶保存。優(yōu)秀的文檔例如用戶手冊(cè)和技術(shù)白皮書,應(yīng)提供商品化包裝,并且印刷精美。
      32、功能測(cè)試用例需要詳細(xì)到什么程度才是合格的?
      這個(gè)問題也是測(cè)試工程師經(jīng)常問的問題。有人主張測(cè)試用例詳細(xì)到每個(gè)步驟執(zhí)行什么都要寫出來,目的是即使一個(gè)不了解系統(tǒng)的新手都可以按照測(cè)試用例來執(zhí)行工作。主張這類寫法的人還可以舉出例子:歐美、日本等軟件外包文檔都是這樣做的。
      另外一種觀點(diǎn)就是主張寫的粗些,類似于編寫測(cè)試大綱。主張這種觀點(diǎn)的人是因?yàn)檐浖_發(fā)需求管理不規(guī)范,變動(dòng)十分頻繁,因而不能按照歐美的高標(biāo)準(zhǔn)來編寫測(cè)試用例。這樣的測(cè)試用例容易維護(hù),可以讓測(cè)試執(zhí)行人員有更大的發(fā)揮空間。
      實(shí)際上,軟件測(cè)試用例的詳細(xì)程度首先要以覆蓋到測(cè)試點(diǎn)為基本要求。舉個(gè)例子:“用戶登陸系統(tǒng)”的測(cè)試用例可以不寫出具體的執(zhí)行數(shù)據(jù),但是至少要寫出五種以上情況(),如果只用一句話覆蓋了這個(gè)功能是不合格的測(cè)試用例。覆蓋功能點(diǎn)不是指列出功能點(diǎn),而是要寫出功能點(diǎn)的各個(gè)方面(如果組合情況較多時(shí)可以采用等價(jià)劃分)。
      另一個(gè)影響測(cè)試用例的就是組織的開發(fā)能力和測(cè)試對(duì)象特點(diǎn)。如果開發(fā)力量比較落后,編寫較詳細(xì)的測(cè)試用例是不現(xiàn)實(shí)的,因?yàn)楦緵]有那么大的資源投入,當(dāng)然這種情況很隨著團(tuán)隊(duì)的發(fā)展而逐漸有所改善。測(cè)試對(duì)象特點(diǎn)重點(diǎn)是指測(cè)試對(duì)象在進(jìn)度、成本等方面的要求,如果進(jìn)度較緊張的情況下,是根本沒有時(shí)間寫出高質(zhì)量的測(cè)試用例的,甚至有些時(shí)候測(cè)試工作只是一種輔助工作,因而不編寫測(cè)試用例。
      因此,測(cè)試用例的編寫要根據(jù)測(cè)試對(duì)象特點(diǎn)、團(tuán)隊(duì)的執(zhí)行能力等各個(gè)方面綜合起來決定編寫策略。最后要注意的是測(cè)試人員一定不能抱怨,力爭(zhēng)在不斷提高測(cè)試用例編寫水平的同時(shí),不斷地提高自身能力。
      33、配置和兼容性測(cè)試的區(qū)別是什么?
      配置測(cè)試的目的是保證軟件在其相關(guān)的硬件上能夠正常運(yùn)行,而兼容性測(cè)試主要是測(cè)試軟件能否與不同的軟件正確協(xié)作。
      配置測(cè)試的核心內(nèi)容就是使用各種硬件來測(cè)試軟件的運(yùn)行情況,一般包括:
      (1)軟件在不同的主機(jī)上的運(yùn)行情況,例如Dell和Apple;
      (2)軟件在不同的組件上的運(yùn)行情況,例如開發(fā)的撥號(hào)程序要測(cè)試在不同廠商生產(chǎn)的Modem上的運(yùn)行情況;
      (3)不同的外設(shè);
      (4)不同的接口;
      (5)不同的可選項(xiàng),例如不同的內(nèi)存大小;
      兼容性測(cè)試的核心內(nèi)容:
      (1)測(cè)試軟件是否能在不同的操作系統(tǒng)平臺(tái)上兼容;
      (2)測(cè)試軟件是否能在同一操作系統(tǒng)平臺(tái)的不同版本上兼容;
      (3)軟件本身能否向前或者向后兼容;
      (4)測(cè)試軟件能否與其它相關(guān)的軟件兼容;
      (5)數(shù)據(jù)兼容性測(cè)試,主要是指數(shù)據(jù)能否共享;
      配置和兼容性測(cè)試通稱對(duì)開發(fā)系統(tǒng)類軟件比較重要,例如驅(qū)動(dòng)程序、操作系統(tǒng)、數(shù)據(jù)庫(kù)管理系統(tǒng)等。具體進(jìn)行時(shí)仍然按照測(cè)試用例來執(zhí)行。
      34、軟件文檔測(cè)試主要包含什么?
      隨著軟件文檔系統(tǒng)日益龐大,文檔測(cè)試已經(jīng)成為軟件測(cè)試的重要內(nèi)容。文檔測(cè)試對(duì)象主要如下:
      -包裝文字和圖形;
      -市場(chǎng)宣傳材料、廣告以及其它插頁(yè);
      -授權(quán)、注冊(cè)登記表;
      -最終用戶許可協(xié)議;
      -安裝和設(shè)置向?qū)В?/div>
      -用戶手冊(cè);
      -聯(lián)機(jī)幫助;
      -樣例、示范例子和模板;
      -……
      文檔測(cè)試的目的是提高易用性和可靠性,降低支持費(fèi)用,因?yàn)橛脩敉ㄟ^文檔就可以自己解決問題。因文檔測(cè)試的檢查內(nèi)容主要如下:
      -讀者對(duì)象——主要是文檔的內(nèi)容是否能讓該級(jí)別的讀者理解;
      -術(shù)語(yǔ)——主要是檢查術(shù)語(yǔ)是否適合讀者;
      -內(nèi)容和主題——檢查主題是否合適、是否丟失、格式是否規(guī)范等;
      -圖標(biāo)和屏幕抓圖——檢查圖表的準(zhǔn)確度和精確度;
      -樣例和示例——是否與軟件功能一致;
      -拼寫和語(yǔ)法;
      -文檔的關(guān)聯(lián)性——是否與其它相關(guān)文檔的內(nèi)容一致,例如與廣告信息是否一致;
      文檔測(cè)試是相當(dāng)重要的一項(xiàng)測(cè)試工作,不但要給予充分的重視,更要要認(rèn)真的完成,象做功能測(cè)試一樣來對(duì)待文檔測(cè)試。
      35、沒有產(chǎn)品說明書和需求文檔地情況下能夠進(jìn)行黑盒測(cè)試嗎?
      這個(gè)問題是國(guó)內(nèi)測(cè)試工程師經(jīng)常遇到的問題,根源就是國(guó)內(nèi)軟件開發(fā)文檔管理不規(guī)范,對(duì)變更的管理方法就更不合理了。實(shí)際上沒有任何文檔的時(shí)候,測(cè)試人員是能夠進(jìn)行黑盒測(cè)試的,這種測(cè)試方式我們可以稱之為探索測(cè)試,具體做法就是測(cè)試工程師根據(jù)自己的專業(yè)技能、領(lǐng)域知識(shí)等不斷的深入了解測(cè)試對(duì)象、理解軟件功能,進(jìn)而發(fā)現(xiàn)缺陷。
      在這種做法基本上把軟件當(dāng)成了產(chǎn)品說明書,測(cè)試過程中要和開發(fā)人員不斷的進(jìn)行交流。尤其在作項(xiàng)目的時(shí)候,進(jìn)度壓力比較大,可以作為加急測(cè)試方案。最大的風(fēng)險(xiǎn)是不知道有些特性是否被遺漏。
      36、測(cè)試中的“殺蟲劑怪事”是指什么?
      “殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟件測(cè)試技術(shù)》第二版中提出。用于描述測(cè)試人員對(duì)同一測(cè)試對(duì)象進(jìn)行的測(cè)試次數(shù)越多,發(fā)現(xiàn)的缺陷就會(huì)越來越少的現(xiàn)象。就像老用一種農(nóng)藥,害蟲就會(huì)有免疫力,農(nóng)藥發(fā)揮不了效力。這種現(xiàn)象的根本原因就是測(cè)試人員對(duì)測(cè)試軟件過于熟悉,形成思維定勢(shì)。
      為了克服這種現(xiàn)象,測(cè)試人員需要不斷編寫新的測(cè)試程序或者測(cè)試用例,對(duì)程序的不同部分進(jìn)行測(cè)試,以發(fā)現(xiàn)更多的缺陷。也可以引用新人來測(cè)試軟件,剛剛進(jìn)來的新手往往能發(fā)現(xiàn)一些意想不到的問題。
      37、在配置測(cè)試中,如何判斷發(fā)現(xiàn)的缺陷是普通問題還是特定的配置問題?
      在進(jìn)行配置測(cè)試時(shí),測(cè)試工程師仍然會(huì)發(fā)現(xiàn)一些普通的缺陷,也就是與配置環(huán)境無關(guān)的缺陷。因此判斷新發(fā)現(xiàn)的問題,需要在不同的配置中重新執(zhí)行發(fā)現(xiàn)軟件缺陷的步驟,如果軟件缺陷不出現(xiàn)了,就可能是配置缺陷;如果在所有的配置中都出現(xiàn),就可能是普通缺陷。
      需要注意的是,配置問題可以在一大類配置中出現(xiàn)。例如,撥號(hào)程序可能在所有的外置Modem中都存在問題,而內(nèi)置的Modem不會(huì)有任何問題。
      38、為什么盡量不要讓時(shí)間有富裕的員工去做一些測(cè)試?
      表面上看這體現(xiàn)了管理的效率和靈活性,但實(shí)際上也體現(xiàn)了管理者對(duì)測(cè)試的輕視。測(cè)試和測(cè)試的人有很大關(guān)系。測(cè)試工作人員應(yīng)該是勤奮并富有耐心,善于學(xué)習(xí)、思考和發(fā)現(xiàn)問題,細(xì)心有條理,總結(jié)問題,如果具備這樣的優(yōu)點(diǎn),做其它工作同樣也會(huì)很出色,因此這里還有一個(gè)要求,就是要喜歡測(cè)試這項(xiàng)工作。如果他是專職的,那么肯定更有經(jīng)驗(yàn)和信心。國(guó)內(nèi)的小伙子好象都喜歡做程序員,兩者工作性質(zhì)不同,待遇不同,地位不同,對(duì)自我實(shí)現(xiàn)的價(jià)值的認(rèn)識(shí)也不同,這是行業(yè)的一個(gè)需要改善的問題。如果只是為了完成任務(wù)而完成任務(wù),或者發(fā)現(xiàn)了幾個(gè)問題就覺得滿意了,這在任何其它工作中都是不行的。
      39、完全測(cè)試程序是可能的嗎?
      軟件測(cè)試初學(xué)者可能認(rèn)為拿到軟件后需要進(jìn)行完全測(cè)試,找到全部的軟件缺陷,使軟件“零缺陷”發(fā)布。實(shí)際上完全測(cè)試是不可能的。主要有以下一個(gè)原因:
      -完全測(cè)試比較耗時(shí),時(shí)間上不允許;
      -完全測(cè)試通常意味著較多資源投入,這在現(xiàn)實(shí)中往往是行不通的;
      -輸入量太大,不能一一進(jìn)行測(cè)試;
      -輸出結(jié)果太多,只能分類進(jìn)行驗(yàn)證;
      -軟件實(shí)現(xiàn)途徑太多;
      -軟件產(chǎn)品說明書沒有客觀標(biāo)準(zhǔn),從不同的角度看,軟件缺陷的標(biāo)準(zhǔn)不同;
      因此測(cè)試的程度要根據(jù)實(shí)際情況確定。
      40、軟件測(cè)試的風(fēng)險(xiǎn)主要體現(xiàn)在哪里?
      我們沒有對(duì)軟件進(jìn)行完全測(cè)試,實(shí)際就是選擇了風(fēng)險(xiǎn),因?yàn)槿毕輼O有可能存在沒有進(jìn)行測(cè)試的部分。舉個(gè)例子,程序員為了方便,在調(diào)試程序時(shí)會(huì)彈出一些提示信息框,而這些提示只在某種條件下會(huì)彈出,碰巧程序發(fā)布前這些代碼中的一些沒有被注釋掉。在測(cè)試時(shí)測(cè)試工程師又沒有對(duì)其進(jìn)行測(cè)試。如果客戶碰到它,這將是代價(jià)昂貴的缺陷,因?yàn)榻桓逗蟛疟豢蛻舭l(fā)現(xiàn)。
      因此,我們要盡可能的選擇最合適的測(cè)試量,把風(fēng)險(xiǎn)降低到最小。

    posted @ 2014-09-12 09:48 順其自然EVO 閱讀(807) | 評(píng)論 (0)編輯 收藏

    僅列出標(biāo)題
    共394頁(yè): First 上一頁(yè) 48 49 50 51 52 53 54 55 56 下一頁(yè) Last 
    <2025年5月>
    27282930123
    45678910
    11121314151617
    18192021222324
    25262728293031
    1234567

    導(dǎo)航

    統(tǒng)計(jì)

    • 隨筆 - 3936
    • 文章 - 404
    • 評(píng)論 - 179
    • 引用 - 0

    常用鏈接

    留言簿(55)

    隨筆分類

    隨筆檔案

    文章分類

    文章檔案

    搜索

    •  

    最新評(píng)論

    閱讀排行榜

    評(píng)論排行榜

    主站蜘蛛池模板: 亚洲人成综合在线播放| 亚洲欧洲AV无码专区| 亚洲国产成人久久精品app| 中文毛片无遮挡高清免费| 99精品视频免费观看| 永久久久免费浮力影院| 国产专区一va亚洲v天堂| 亚洲一级片免费看| 亚洲资源在线观看| 亚洲欧美熟妇综合久久久久| 免费成人激情视频| 亚洲 综合 国产 欧洲 丝袜| 91嫩草私人成人亚洲影院| 黄页网站在线免费观看| 在线免费中文字幕| 亚洲国产天堂久久久久久| 亚洲第一男人天堂| 全黄大全大色全免费大片| 好爽…又高潮了毛片免费看| 亚洲国产精品VA在线看黑人| 亚洲精品无码aⅴ中文字幕蜜桃| 嫩草成人永久免费观看| 免费大香伊蕉在人线国产| 亚洲国产香蕉碰碰人人| 丁香六月婷婷精品免费观看| 2020因为爱你带字幕免费观看全集| 亚洲精品人成无码中文毛片| 老司机精品视频免费| 免费人妻av无码专区| 曰批全过程免费视频免费看| 99视频在线精品免费观看6| 亚洲ⅴ国产v天堂a无码二区| 免费激情网站国产高清第一页| 又粗又大又猛又爽免费视频| 羞羞视频免费观看| 亚洲精品高清在线| 牛牛在线精品免费视频观看| 亚洲av无码不卡私人影院| 国产 亚洲 中文在线 字幕| 欧美男同gv免费网站观看| 亚洲一区二区三区丝袜|