 |
Nicolaas Kotze是一個(gè)有著離奇扭曲幽默感（這種幽默感諷刺地與墨菲定律及對詳細(xì)解釋質(zhì)量是如何被感知的人類行為的理解很好結(jié)合了起來）的自信的現(xiàn)實(shí)主義悲觀者。他在英國倫敦時(shí)開始接觸游戲行業(yè)的測試，并頭冠不少AAA級稱號。 他的測試職業(yè)生涯正式開始于回到南非測試(使用用來自荷蘭客戶公共服務(wù)交付領(lǐng)域的谷歌地圖的)GIS軟件系統(tǒng)，再后來他轉(zhuǎn)移到繁忙的零售信貸和金融服務(wù)業(yè)。他選擇測試為職業(yè)道路是因?yàn)樗谷藗兡軌驅(qū)?chuàng)造性思維融入常規(guī)程序或規(guī)定中，且仍有“打破”東西的令人振奮的快感。測試與許多其他學(xué)科和專業(yè)交織在一起這件事是：主要驅(qū)動力讓事情一直有趣且充滿挑戰(zhàn)。 目前他擔(dān)任動態(tài)可視化技術(shù)（ DVT）開普敦的一名SQA的Competency 領(lǐng)導(dǎo)的職責(zé)是：將其熱情和精力投入指導(dǎo)，激勵，幫助，并使人們了解測試及改進(jìn)更有效測試流程的好處。已經(jīng)從正在打印取得了經(jīng)驗(yàn)，數(shù)碼影像制作/銷售/支持/培訓(xùn)/，及在接觸測試前成為一名辦公自動化領(lǐng)域的技術(shù)人員賦予他技巧去理解挫敗人們的問題及能有效支持人們所需要的。 欲了解更多詳情，可以訪問za.linkedin.com/in/nicolaasjkotze查看他的LinkedIn個(gè)人資料。 |
很多測試用例設(shè)計(jì)很少或根本不費(fèi)什么力（只需搜索我們社交媒體上的所有建議），但設(shè)計(jì)好的測試用例是復(fù)雜且極具挑戰(zhàn)性的。為設(shè)計(jì)好的測試提供資源這一點(diǎn)往往很容易被對編寫和執(zhí)行測試不負(fù)責(zé)的人所忽視。更不要說為獲得足夠的使我們能夠衡量我們測試工作成效的報(bào)告需要了解哪些信息了。然后還需要有可以定義（或有時(shí)甚至強(qiáng)制執(zhí)行）所需測試的組織，開發(fā)團(tuán)隊(duì)，測試團(tuán)隊(duì)，流程及工具。搜索討論板時(shí)，很多人在上面尋找通用解決辦法的并不意外。
互聯(lián)網(wǎng)上和書中有足夠多的信息介紹：如何分析需求，應(yīng)用測試設(shè)計(jì)技術(shù)，并將它們實(shí)施和執(zhí)行。我建議去看看Cem Kaner寫于2003年的題為《什么是好的測試用例？》的一份簡短卻詳細(xì)的研究報(bào)告。它引用一大堆參考文獻(xiàn)，提供了充足的信息讓你能基本了解。
在這篇簡短的文章中，我不會解釋如何應(yīng)用測試技術(shù)，而會分享信息作為需要考慮的因素的入門指南，使我們能夠設(shè)計(jì)出好的測試，我希望我能為讀者創(chuàng)造一個(gè)分享他們經(jīng)驗(yàn)的平臺。這里的內(nèi)容是基于我的解決呈現(xiàn)在我面前的挑戰(zhàn)的測試經(jīng)驗(yàn)。我也是假設(shè)讀者有一些正式的測試經(jīng)驗(yàn)且已對測試設(shè)計(jì)技術(shù)有了理解才寫的這篇文章。
在閱讀這篇文章時(shí)，我不斷查閱測試設(shè)計(jì)的高層次目標(biāo)和因素：
1. 合并測試分析中定義的執(zhí)行狀態(tài)。
2. 建立特定輸入。
3. 根據(jù)輸入和規(guī)范定義預(yù)期結(jié)果。
和一些基本因素：
1. 覆蓋范圍。
2. 有效性。
3. 彈性和維護(hù)。
4. 執(zhí)行者的技能。
我們遇到的影響設(shè)計(jì)出好測試的第一個(gè)挑戰(zhàn)是使每個(gè)人都了解測試原則。
ISEB / ISTQB
軟件測試基礎(chǔ)突出七項(xiàng)原則。這些原則提醒我們并降低（一些）成員對有時(shí)會超出我們控制的各種挑戰(zhàn)的期望。解釋并使參與的每個(gè)人都了解到這些原則將導(dǎo)致現(xiàn)實(shí)的結(jié)果和一個(gè)更愉快的合作環(huán)境。
1 .測試將顯示出缺陷的存在。開始設(shè)計(jì)更多將顯示缺陷的測試。 “幸福路徑”應(yīng)該會起作用，當(dāng)然，除非你質(zhì)疑交付測試的代碼質(zhì)量。
2 . 許多情況下都不可能測試一切。建議使用風(fēng)險(xiǎn)分析并優(yōu)先關(guān)注測試工作的重點(diǎn)。接受一個(gè)事實(shí)：沒有一個(gè)各種組合和排列的測試會降低壓力水平和期望。有時(shí)候會錯過一些事。如果你想要20個(gè)測試，好設(shè)計(jì)100個(gè)測試，再從中挑選出好的20個(gè) 。
3. 開發(fā)生命周期中盡可能早地開始測試活動。別以為測試只是一旦產(chǎn)品可執(zhí)行時(shí)用來確認(rèn)和驗(yàn)證產(chǎn)品的功能的。相比后來在SDLC這樣做，在驗(yàn)收前正在審核要求時(shí)設(shè)計(jì)測試，比起在SDLC中晚點(diǎn)這么做，可以獲得很高的投資回報(bào)率。
4.缺陷很集中。測試執(zhí)行后不要停止設(shè)計(jì)新測試。如果時(shí)間夠的話，審查被排除在（與在其中新發(fā)現(xiàn)的缺陷被確定的組成部分相關(guān)的）初范圍外的測試集合中的一些測試。
5.在某些時(shí)候，系統(tǒng)會對被多次反復(fù)的測試“免疫”。再次強(qiáng)調(diào)，在設(shè)計(jì)好的測試停止尋找缺陷后不要停止設(shè)計(jì)新測試。審查被排除在初范圍外的測試集合，或者利用更多測試技巧拓寬缺陷類型。
6.你如何設(shè)計(jì)測試受到正在開發(fā)的系統(tǒng)的環(huán)境和業(yè)務(wù)領(lǐng)域的形式影響。不是每個(gè)人都在建橋梁。此外，根據(jù)測試水平去設(shè)計(jì)測試。
7.如果你曾經(jīng)用代碼設(shè)計(jì)了很多測試，后來實(shí)現(xiàn)了代碼并不能解決用戶的需求和期望，那一刻像在經(jīng)歷一次史詩級的失敗。如果規(guī)范欠缺，根據(jù)用戶期望系統(tǒng)如何工作以及它將如何滿足他們的需要去考慮設(shè)計(jì)測試。不要依賴代碼作為規(guī)范的來源。
第二個(gè)挑戰(zhàn)是確定測試什么，為何要測試，以及如何測試。
在團(tuán)隊(duì)中或和不明白測試目的和目標(biāo)的人一起工作時(shí)，這變得非常具有挑戰(zhàn)性的（有時(shí)候爭權(quán)奪利的）。開發(fā)生命周期及利益相關(guān)者和團(tuán)隊(duì)的成熟度或許會成為在設(shè)計(jì)好測試時(shí)有創(chuàng)意的主要障礙。確定測試的內(nèi)容要在分析需求時(shí)提出正確問題。根據(jù)我的經(jīng)驗(yàn)，將這些問題基于ISO / IEC 25010:20113標(biāo)準(zhǔn)文檔中所提到作為一個(gè)起點(diǎn)的軟件質(zhì)量特點(diǎn)是正確方向上邁出的一步。我覺得把這些特性包括問題中是一種非常有效的收集信息并闡明規(guī)格（尤其是與敏捷團(tuán)隊(duì)合作時(shí)），因?yàn)樗峁┝艘粋�(gè)機(jī)會來定義超出原所有者認(rèn)為的需求細(xì)節(jié)。他們也許之前沒有專家?guī)椭_定可測試的細(xì)節(jié)。試著預(yù)測使用這些高水平質(zhì)量特點(diǎn)時(shí)可能出現(xiàn)的客戶需求和經(jīng)驗(yàn)方面的問題：
1. 功能
2. 可靠性
3. 可用性
4. 效率
5. 可維護(hù)性
6. 便攜性
這些高水平特點(diǎn)有子特點(diǎn)，如：精度，性能，可變性，可安裝性等等。現(xiàn)在，你應(yīng)該能夠根據(jù)計(jì)劃，預(yù)算和可用資源去選擇合適的測試技術(shù)了。
我認(rèn)為軟件開發(fā)中不常被提到的一個(gè)特點(diǎn)是可測試性。如果你曾經(jīng)設(shè)計(jì)過電子電路和組件，那么你會明白DFT （為可測試性而設(shè)計(jì)）的驚人效益，或當(dāng)工程師把BIST （內(nèi)建自測試）包含到他們的設(shè)計(jì)能力中時(shí)。許多軟件產(chǎn)品是以一種非常耗時(shí)的，容易出錯的且很難測試方式設(shè)計(jì)的。
理論上，DFT將在設(shè)計(jì)階段從測試專家考慮輸入，以便早早地設(shè)計(jì)出更好地測試。可測試性的一個(gè)簡單的例子是，如果配置設(shè)置被存儲在數(shù)據(jù)庫中，但它僅在系統(tǒng)啟動時(shí)加載。在某些環(huán)境中執(zhí)行重啟可能挺麻煩�？蓽y試性將通過輕擊開關(guān)或點(diǎn)擊按鈕來實(shí)現(xiàn)配置設(shè)置的動態(tài)重載。通過詢問“我們?nèi)绾螠y試，間隔多久需要回歸一次呢？”開始測試性的討論。團(tuán)隊(duì)成員更頻繁地考慮簡單性和自動化是非常令人興奮的。研究為一般軟件設(shè)計(jì)問題提供指導(dǎo)及技巧以幫助發(fā)現(xiàn)問題的測試模式是有益處的。“我們長期辛苦去打造一個(gè)天堂，結(jié)果卻發(fā)現(xiàn)它填充了恐怖。 ”——選自Alan Moore的《守望者》
第三，測試內(nèi)容需是明確且“可測量的”。
這可能并不占設(shè)計(jì)測試多大部分，測試過程中需被測量的內(nèi)容及測試過程的測試控制活動有望被定義。測試像團(tuán)隊(duì)的照明燈。測試活動應(yīng)該指導(dǎo)團(tuán)隊(duì)使他們能夠避開障礙。奇怪的是，這是后一件需要考慮的事。所以，我只是想把它作為一個(gè)提醒。在某些時(shí)候，你會想提供反饋，例如：
1. 測試工作。
2. 改進(jìn)測試重點(diǎn)。
3. 向別人證明一些事。
4. 提高覆蓋率和技術(shù)。
看一個(gè)測試用例需要什么信息的良好的開端是讀取IEEE 8292標(biāo)準(zhǔn)文件。從這里你可以排除那些從長遠(yuǎn)看來無關(guān)緊要的項(xiàng)目，或根據(jù)需要添加更多項(xiàng)目。確定需要什么樣的報(bào)告，然后尋找能夠盡快產(chǎn)生這些報(bào)告的佳工具。不幸的是，測試往往是非常依賴工具來處理大量信息，但工具也可能對測試形式有影響，并需要流程去確保信息準(zhǔn)確。（你是否曾經(jīng)被要求“調(diào)整”數(shù)據(jù)，掩蓋報(bào)告中“無效”數(shù)據(jù)，或收到過了一份其結(jié)果不穩(wěn)定到甚至斯蒂芬•霍金都站起來含淚走出房間的報(bào)告？）記得用和審查代碼一樣的方式經(jīng)常檢查測試。這樣能持續(xù)改進(jìn)。我希望這篇短短的文章為提供了一些理論或?qū)嵺`指導(dǎo)并引起對設(shè)計(jì)好測試用例的討論。
參考文獻(xiàn)
[1] ISTQB Foundation Level in Software Testing Syllabus 2011 (URL: http://www.istqb.org/downloads/syllabi/foundation-levelsyllabus. html)
[2] IEEE829 Standard for Software and System Test Documentation (URL: http://standards.ieee.org/findstds/standard/829-2008.html)
[3] ISO25010 Systems and Software Engineering (URL: http://www. iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics. htm?csnumber=35733)
[4] Testing Object-Oriented Systems: Models， Patterns， and Tools by Robert Binder; ISBN-10: 0201809389 | ISBN-13: 978-0201809381
[5] The Craft of Software Testing by Brian Marick; ISBN-10: 0131774115 | ISBN-13: 978-0131774117
版權(quán)聲明：本文出自 SPASVO澤眾軟件測試網(wǎng)：http://www.dytjszp.cn/news/html/201456140230.html
原創(chuàng)作品，轉(zhuǎn)載時(shí)請務(wù)必以超鏈接形式標(biāo)明本文原始出處、作者信息和本聲明，否則將追究法律責(zé)任。
