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