測試這兩個test case的testng.xml文件：
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="Suite" verbose="1">
<parameter name="max" value="2"></parameter>
<test name="testcase1">
<classes>
<class name="com.ibm.testng.test.TestCase1"></class>
</classes>
</test>
<test name="testcase2">
<classes>
<class name="com.ibm.testng.test.TestCase2"></class>
</classes>
</test>
</suite>
　　目前組織test case的方法的不足：
　　1） 隨著test case數(shù)量的增加，像TestCase1和TestCase2這樣的測試類會越來越多。
　　2）TestCase1這樣的測試類，只是根據(jù)測試邏輯調(diào)用測試方法，并Assert測試方法結(jié)果，并無其他功能。測試類間有很多像setUp，Assert這樣的重復(fù)代碼。
　　3）修改Common Task類和testng.xml都會對測試類產(chǎn)生影響。例如，修改CommonTasks中method1的名稱，TestCase1和TestCase2中調(diào)用method1（）的地方都得修改。修改testng.xml中參數(shù)max的名稱，需要修改TestCase1和TestCase2中所有用到max變量的地方。
　　4）dependsOnMethods不被推薦使用。因?yàn)�，method名稱同時作為Java方法名稱和字符串，只修改任何一個地方，都會導(dǎo)致方法找不到。
　　2. 新的組織test case的實(shí)踐
　　目前的實(shí)踐方法不僅存在很多重復(fù)冗余的代碼，而且為以后的重構(gòu)帶來諸多不便。主要原因是測試類介于Common Task類和testng.xml之間，因此，新實(shí)踐不再為每個test case創(chuàng)建測試類。
　　新實(shí)踐的實(shí)例代碼如下：
　　CommonTasks文件：
import java.util.Random;
public class NewCommonTasks {
@Test(groups="method1")
@Parameters("max")
public void method1(int max) {
System.out.println("Run method1()");
Assert.assertEquals(new Random().nextInt(max)， 0， "Failed");
}
@Test(groups="method2")
@Parameters("max")
public void method2(int max) {
System.out.println("Run method2()");
Assert.assertEquals(new Random().nextInt(max)， 0， "Failed");
}
}
　　測試這兩個test case的testng.xml文件：
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="Suite" verbose="1">
<parameter name="max" value="2"></parameter>
<test name="testcase1">
<groups>
<dependencies>
<group depends-on="method1" name="method2"></group>
</dependencies>
<run>
<include name="method1"></include>
<include name="method2"></include>
</run>
</groups>
<packages>
<package name="com.ibm.testng.test.*"></package>
</packages>
</test>
<test name="testcase2">
<groups>
<dependencies>
<group depends-on="method2" name="method1"></group>
</dependencies>
<run>
<include name="method2"></include>
<include name="method1"></include>
</run>
</groups>
<packages>
<package name="com.ibm.testng.test.*"></package>
</packages>
</test>
</suite>
　　新實(shí)踐基于TestNG的一個設(shè)計目標(biāo)：Create a clean separation between thestatic model (the code of your tests) and the runtime model (which tests get run)。這里的static model指Java代碼中的測試方法，runtime model指運(yùn)行時的test case。
　　新實(shí)踐將之前的測試類刪掉，將測試類的annotation移到Common Task類中，將測試類的測試邏輯移到testng.xml中通過<dependencies>實(shí)現(xiàn)。這樣做具有如下優(yōu)勢：
　　1）理想情況下，一個Common Task類和一個testng.xml可以組織出所有test case。不存在代碼重復(fù)率很高的測試類，class文件數(shù)量也不會隨著test case數(shù)量的增加而增加。
　　2）修改Common Task類和testng.xml，相互之間的影響會非常小。修改Common Task類，再也不用去修改大量的測試類。修改testng.xml中的參數(shù)名稱，也只需要修改Common Task類中很少的地方。
　　3）dependsOnGroups代替了dependsOnMethods，任意修改Common Task類中的method名稱，都不會有印象。
　　當(dāng)然，這種實(shí)現(xiàn)也不是完全沒有缺點(diǎn)。例如：測試邏輯也放到testng.xml中后，在test case數(shù)量較多的情況下文件會比較長。不過可以根據(jù)某些特性將test case放到幾個xml配置文件中，然后通過<suite-files>封裝成一個suite一起測試。另外，當(dāng)測試出現(xiàn)問題的時候，測試人員需要讀testng.xml文件來追蹤錯誤位置。如果在寫testng.xml時將<run>標(biāo)簽中include的groups按邏輯先后順序排列的話，也不會額外增加追蹤錯誤的難度。
　　我們會發(fā)現(xiàn)這種實(shí)現(xiàn)的testng.xml中，每個test case都需要一個相同的<packages>，其實(shí)完全可以把這部分移到<suite>中，使其對所有的test case都有效。不過，這樣的嘗試沒有成功，具體問題描述見testng github，希望知道該問題的人能夠指點(diǎn)一下。同時，如果一個test case中要多次以不同參數(shù)運(yùn)行同一group，會遇到傳參和dependency的問題。目前只有一種間接解決方案：將這個test case執(zhí)行同一group的步驟分配到不同test中，TestNG會按照testng.xml中test的順序去執(zhí)行test case。