改進自動化測試套件的可維護性（二）

1.對從自動化中獲益的時機重新設定管理期望值

　　We all agreed that when GUI-level regression automation is developed in Release N of the software, most of the benefits are realized during the testing and development of Release N+1. I think that we were surprised to realize that we all shared this conclusion, because we are so used to hearing about (if not experiencing) the oh-so-fast time to payback for an investment in test automation.

　　當GUI級回歸自動化測試在軟件的發行版N中被開發后，我們都認為在發行版N+1的測試和開發中會有很多收益。我想我們會驚奇地發現所有人都贊成該結論，因為我們總是聽說(并沒有實際經歷)對自動化測試的投入會有快速的回報。

　　Some benefits are realized in release N. For example:

　　以下例子體現了發行版N中的一些收益：

　　o There’s a big payoff in automating a suite of aclearcase/" target="_blank" >cceptance-into-testing (also called "smoke") tests. You might run these 50 or 100 times during development of Release N. Even if it takes 10x as long to develop each test as to execute each test by hand, and another 10x cost for maintenance, this still creates a time saving equivalent to 30-80 manual executions of each test case.

　　對一套用于測試目的的測試(也叫“煙霧測試”)進行自動化可以獲得很大的收益。在開發第N版時，你或許會運行它們50次或100次。即使開發每一個測試是手動執行測試時間的10倍，且在可維護性方面的成本也會是10倍，但仍然對每個測試用例節省了相當于30至80倍的手動執行時間。

　　o You can save time, reduce human error, and obtain good tracking of what was done by automating configuration and compatibility testing. In these cases, you are running the same tests against many devices or under many environments. If you test the program’s compatibility with 30 printers, you might recover the cost of automating this test in less than a week.

　　你能通過自動化配置和兼容性測試節省時間，減少人為錯誤，并獲得對已完成工作的良好跟蹤。在這樣的情況下，你會對很多設備或在很多環境下運行相同的測試。如果你要測試兼容30個打印機的程序，那么你可以在不到一周的時間里收回自動化該測試的成本。

　　o Regression automation facilitates performance benchmarking across operating systems and across different development versions of the same program.

　　回歸自動化有助于性能基準跨越不同的操作系統以及同一程序的不同開發版本。

　　Take advantage of opportunities for near-term payback from automation, but be cautious when automating with the goal of short-term gains. Cost-justify each additional test case, or group of test cases.

　　雖然可以利用自動化近期回報的優點，但是在進行目的是短期收效的自動化時，需要注意對每個額外測試用例或測試用例組進行成本驗證。

　　If you are looking for longer term gains, across releases of the software, then you should seriously thinking about setting your goals for Version N as:

　　如果要尋找更長期的收效，跨越軟件的不同發行版，那么你就應該為第N版認真地考慮設置如下目標：

　　o providing efficient regression testing for Version N in a few specific areas (such as smoke tests and compatibility tests);

　　在一些特殊的領域(如煙霧測試和兼容性測試)，為版本N提供有效的回歸測試。

　　o developing scaffolding that will make for broader and more efficient automated testing in Version N+1.

　　為N+1版中范圍更廣、更有效的自動化測試做一些支持工作。

　　2.Recognize that test automation development is software development.

　　2.承認測試自動化開發是軟件開發的一部分

　　You can’t develop test suites that will survive and be useful in the next release without clear and realistic planning.

　　不能在缺乏明晰且實際的計劃的情況下，開發在下個發行版中繼續有效并適用的測試套件。

　　You can’t develop extensive test suites (which might have more lines of code than the application being tested) without clear and realistic planning.

　　不能在缺乏明晰且實際的計劃的情況下，開發可擴展的測試套件(所產生的代碼量可能比正在測試的應用程序更多)。

　　You can’t develop many test suites that will have a low enough maintenance cost to justify their existence over the life of the project without clear and realistic planning.

　　不能在缺乏明晰且實際的計劃的情況下，開發很多沒有足夠可維護性開銷來證明在項目生命周期中的存在性的測試套件。

　　Automation of software testing is just like all of the other automation efforts that software developers engage in—except that this time, the testers are writing the automation code.

　　軟件自動化測試與軟件開發人員進行的其它所有自動化工作類似。但有一個例外，那就是測試人員要編寫自動化代碼。

　　o It is code, even if the programming language is funky.

　　就算程序語言很怪異，它也是一種編碼。

　　o Within an application dedicated to testing a program, every test case is a feature.

　　在專門用于測試的某個應用程序中，每個測試用例都是一種特性。

　　o From the viewpoint of the automated test application, every aspect of the underlying application (the one you’re testing) is data.

　　從自動化測試應用程序的觀點來看，應用程序(你正在測試的那個)的每個方面都是數據。

　　As we’ve learned on so many other software development projects, software developers (in this case, the testers) must:

　　在研究眾多其它軟件開發項目后，我們認為軟件開發人員(在這種情況下，也就是測試人員)必須做到：

　　o understand the requirements;

　　理解需求;

　　o adopt an architecture that allows us to efficiently develop, integrate, and maintain our features and data;

　　采用一個能使我們能有效開發、集成以及維護特性和數據的架構;

　　o adopt and live with standards. (I don’t mean grand schemes like ISO 9000 or CMM. I mean that it makes sense for two programmers working on the same project to use the same naming conventions, the same structure for documenting their modules, the same approach to error handling, etc.. Within any group of programmers, agreements to follow the same rules are agreements on standards);

　　采用并遵守標準。(我不是指如ISO 9000 或者CMM這樣的大型標準。我的意思是務必使在同一個項目中的兩個程序員使用相同的命名規則、相同的模塊文檔結構、相同的錯誤處理方法等。在任何一個程序員團隊中，遵守相同規則本身就是一種標準)

　　o be disciplined.

　　遵守紀律。

　　Of all people, testers must realize just how important it is to follow a disciplined approach to software development instead of using quick-and-dirty design and implementation. Without it, we should be prepared to fail as miserably as so many of the applications we have tested.

　　在所有人中，測試人員必須認識到，遵循一個規范方法而不是為了圖快而不保證質量地去設計與實現，這對于軟件開發很重要。否則，我們就只能面臨失敗，與我們已測試的眾多應用程序的失敗結局一樣。

　　3.Use a data-driven architecture. [6]

　　3.使用數據驅動的架構

　　In discussing successful projects, we saw two classes of approaches, data-driven design and framework-based design. These can be followed independently, or they can work well together as an integrated approach.

　　在對成功項目的討論中，我們可以看到兩類方法：數據驅動設計和基于框架設計。它們既可以被單獨遵循，也可以被綜合起來使用。

　　A data-driven example: Imagine testing a program that lets the user create and print tables. Here are some of the things you can manipulate:

　　下面是一個數據驅動設計的例子：假設要測試一個讓用戶創建并打印表格的程序。以下是你能操控的事情：

　　o The table caption. It can vary in typeface, size, and style (italics, bold, small caps, or normal).

　　表格的標題?？梢愿淖冏煮w、大小和風格(斜體、粗體、小寫還是常規)。

　　o The caption location (above, below, or beside the table) and orientation (letters are horizontal or vertical).

　　標題的位置(表格的上邊、下邊還是兩側)和方向(文字水平或垂直排列)。

　　o A caption graphic (above, below, beside the caption), and graphic size (large, medium, small). It can be a bitmap (PCX, BMP, TIFF) or a vector graphic (CGM, WMF).

　　標題圖形的位置(標題的上邊、下邊還是兩側)，圖形大小(大號、中號、小號)。是位圖格式(PCX, BMP, TIFF)還是向量格式(CGM, WMF)。

　　o The thickness of the lines of the table’s bounding box.

　　表格邊框線條的粗度

　　o The number and sizes of the table’s rows and columns.

　　表格行、列的數量和大小

　　o The typeface, size, and style of text in each cell. The size, placement, and rotation of graphics in each cell.

　　每個單元格中字符的字號、大小和風格。每個單元格中圖形的大小、位置和旋轉角度。

　　o The paper size and orientation of the printout of the table.

　　打印表格的紙張型號和輸出方向

　　

　　Figure 1 Some characteristics of a table

　　圖1 一張表格的特征

　　These parameters are related because they operate on the same page at the same time. If the rows are too big, there’s no room for the graphic. If there are too many typefaces, the program might run out of memory. This example cries out for testing the variables in combination, but there are millions of combinations.

　　這些參數是相互關聯的，因為它們同時在同一頁起作用。如果行太大，就沒有放置圖形的空間。如果有太多的字號，程序則可能會用光內存。本例非常需要把各個變量組合到一起來測試，可是這樣就會產生大量組合方式。

　　Imagine writing 100 scripts to test a mere 100 of these combinations. If one element of the interface should change—for example, if Caption Typeface moves from one dialog box to another—then you might have to revise each script.]

　　假設編寫100段腳本來測試僅僅100種這樣的組合方式。如果某界面的一個元素改變，例如，標題字體從一個對話框轉移到另外一個，那么你就可能不得不重新編寫每一個腳本。

　　

　　Figure 2 The first few rows of a test matrix for a table formatter

　　圖2 某表格格式的測試矩陣的前幾行

　　Now imagine working from a test matrix. A test case is specified by a combination of the values of the many parameters. In the matrix, each row specifies a test case and each column is a parameter setting. For example, Column 1 might specify the Caption Location, Column 2 the Caption Typeface, and Column 3 the Caption Style. There are a few dozen columns.

　　現在，假設根據一個測試矩陣來工作。我們用很多參數值的一種組合來確定一個測試用例。在矩陣中，每一行確定了一個測試用例，而每一列則代表一個參數。例如，第1列可以是標題位置，第2列可以是標題字體 ，而第3列則是標題風格。這樣就會得到若干列。

　　Create your matrix using a spreadsheet, such as Excel.

　　接著，用一個電子表格制作軟件來創建你的矩陣，比如Excel.

　　To execute these test cases, write a script that reads the spreadsheet, one row (test case) at a time, and executes mini-scripts to set each parameter as specified in the spreadsheet. Suppose that we’re working on Row 2 in Figure 2’s matrix. The first mini-script would read the value in the first column (Caption Location), navigate to the appropriate dialog box and entry field, and set the Caption Location to Right, the value specified in the matrix . Once all the parameters have been set, you do the rest of the test. In this case, you would print the table and evaluate the output.

　　為了執行這些測試用例，我們編寫一個讀這個電子表格的腳本，一次讀一行(測試用例)，并執行這些小腳本來設置每個電子表格中指定的參數。假設我們正在處理圖2矩陣中的第2行。第一段小腳本會讀取第一列(標題位置)的值，并導航到合適的對話框和入口域，然后根據矩陣中的值把標題位置設置為右。一旦設置好所有的參數，你就能進行剩下的測試。這時，你可以打印出表格并對輸出做出評估。

　　The test program will execute the same mini-scripts for each row.

　　測試程序將為每一行執行同樣的小腳本。

　　In other words, your structure is:

　　換句話說，工作的流程如下：

　　Load the test case matrix

　　載入測試用例矩陣

　　For each row I (row = test case)

　　讀每一行I(測試用例)

　　For each column J (column = parameter)

　　讀每一列J(參數)

　　Execute the script for this parameter: 為該參數執行腳本：

　　· Navigate to the appropriate dialog box or menu 導航至合適的對話框或菜單。

　　· Set the variable to the value specified in test item (I,J) 把變量設置為測試項(I，J)指定的值

　　Run test I and evaluate the results

　　運行測試I并評估測試結果

　　If the program’s design changed, and the Caption Location was moved to a different dialog, you’d only have to change a few lines of code, in the one mini-script that handles the caption location. You would only have to change these lines once: this change will carry over to every test case in the spreadsheet. This separation of code from data is tremendously efficient compared to modifying the script for each test case.

　　如果改變程序的設計，把標題位置移動到一個不同的對話框，你只需在那個處理標題位置的小腳本中改變幾行代碼。并且，你只需改變這幾行一次。這個改變將對電子表格中的每個測試用例都起作用。與修改每個測試用例的腳本相比，把代碼從數據中剝離會非常有效率。

　　There are several other ways for setting up a data-driven approach. For example, Bret Pettichord (one of the LAWST participants) fills his spreadsheet with lists of commands. [7] Each row lists the sequence of commands required to execute a test (one cell per command). If the user interface changes in a way that changes a command sequence, the tester can fix the affected test cases by modifying the spreadsheet rather than by rewriting code. Other testers use sequences of simple test cases or of machine states.

　　還有其它幾種建立數據驅動的方法。例如，Bret Pettichord(LAWST的成員之一)在他的電子表格中添加了命令行。每一行都列出執行一個測試所需的命令序列(一個單元格對應一個命令)。如果用戶界面的一個命令序列發生了變化，那么測試人員可以通過修改電子表格，而不是重寫代碼來更正相關的測試用例。另外，還有其他測試人員使用簡單測試用例序列或狀態機序列來建立數據驅動。

　　Another way to drive testing with data uses previously created documents. Imagine testing a word processor by feeding it a thousand documents. For each document, the script makes the word processor load the document and perform a sequence of simple actions (such as printing).

　　另一種數據驅動的方法是使用預先創建的文檔。假設通過輸入一千份文檔來測試一個文字處理器。對每一份文檔，腳本都要使文字處理器載入文檔并執行一系列簡單動作(例如打印)。

　　A well-designed data-driven approach can make it easier for non-programming test planners to specify their test cases because they can simply write them into the matrix. Another by-product of this approach, if you do it well, is a set of tables that concisely show what test cases are being run by the automation tool.

　　一個設計良好的數據驅動方法能夠使非編程測試規劃人員更容易地說明他們的測試用例。因為，他們能把它們簡潔地寫到測試矩陣中。如果你做得好的話，這種方法會產生另一個作用，即通過自動化工具用一系列表格簡明地顯示出正在運行的測試用例。

原文轉自：http://www.kjueaiud.com