2 如下两个cȝ源码:
Car.java
public
class
Car
{ 2
3
public
int
getWheels()
{
//
单的q回3
4
return
3
; 5
}
6
7
}
8
import junit.framework.*; 2
public class TestCar extends TestCase { 3
protected int expectedWheels; 4
protected Car myCar; 5
6
public TestCar(String s) { 7
super(s); 8
} 9
10
protected void setUp() { 11
expectedWheels = 6; 12
myCar = new Car(); 13
} 14
public static Test suite() { 15
return new TestSuite(TestCar.class); 16
} 17
public void testGetWheels() { 18
assertEquals(expectedWheels, myCar.getWheels()); //一个简单的试ҎQ判断expectedWheels的gmyCar对象取得大值是否相{?/span>19
} 20
protected void tearDown() {//todo 21
} 22
23
}
3 q行l果:
junit.framework.AssertionFailedError: expected:<6> but was:<3>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at TestCar.testGetWheels(TestCar.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
如果把Car.java中的q回值改?,q行l果会成?
]]>
在控制台中简单的范例如下Q?
1、写个待试的Trianglec，创徏一个TestCase的子cExampleTest:
2?ExampleTest中写一个或多个试ҎQ断a期望的结?注意Q以test作ؓ待测试的Ҏ的开_q样q些Ҏ可以被自动找到ƈ被测?
3?ExampleTest中写一个suite()ҎQ它会用反动态的创徏一个包含所有的testXxxxҎ的测试套Ӟ
4?ExampleTest可以写setUp()、tearDown()ҎQ以便于在测试时初始化或销毁测试所需的所有变量和实例。（不是必须的）
5、写一个main()Ҏ以文本运行器或其它GUI的方式方便的q行试
6、编译ExampleTestQ执行测试?
3.7、Eclipse中JUnit的?
Eclipse自带了一个JUnit的插Ӟ不用安装可以在你的目中开始测试相关的c，q且可以调试你的试用例和被试cR?
使用步骤如下Q?
1、新Z个测试用例，点击“File->New->Other…菜单项Q在弹出的“New”对话框中选择”Java->JUnit?下的TestCase 或TestSuiteQ就q入“New JUnit TestCase”对话框
2、在“New JUnit TestCase”对话框填写相应的栏目，主要有NameQ测试用例名Q，SuperClassQ测试的类一般是默认的junit.framework.TestCaseQ，Class Under TestQ被试的类Q，Source FolderQ测试用例保存的目录Q，PackageQ测试用例包名）Q及是否自动生成main,setUp,tearDownҎ?
3、如果点M面的”Next>”按钮，你还可以直接N你x试的被测试类的方法，Eclipse自动生成与被选方法相应的试ҎQ点几ZFishish”按钮后一个测试用例就创徏好了?
4、编写完成你的测试用例后Q点几ZRun”按钮就可以看到q行l果了?
3.8、JUnit的扩展应?
以下|列了些JUnit的扩展应用：
JUnit + HttpUnit=WEB功能试工具
JUnit + hansel =代码覆盖试工具
JUnit + abbot =界面自动回放试工具
JUnit + dbunit =数据库测试工?
JUnit + junitperf=性能试工具
3.9、一些用JUnitl验
不要用TestCase的构造函数初始化Q而要用setUp()和tearDown()Ҏ?
不要依赖或假定测试运行的序Q因为JUnit利用Vector保存试Ҏ。所以不同的q_会按不同的顺序从Vector中取出测试方法?
避免~写有副作用的TestCase。例如：如果随后的测试依赖于某些特定的交易数据，׃要提交交易数据。简单的回滚可以了?
当承一个测试类Ӟ记得调用父类的setUp()和tearDown()Ҏ?
测试代码和工作代码攑֜一P一边同步编译和更新?
试cd试Ҏ应该有一致的命名Ҏ。如在工作类名前加上test从而Ş成测试类名?
保试与时间无养I不要依赖使用q期的数据进行测试。导致在随后的维护过E中很难重现试?
如果你编写的软g面向国际市场Q编写测试时要考虑国际化的因素。不要仅用母语的Localeq行试?
可能地利用JUnit提供地assert/failҎ以及异常处理的方法，可以使代码更为简z?
试要尽可能地小Q执行速度快?
参考资料与附g
1. http:// www.junit.org JUnit官方|站
2. http://bbs.51cmm.com 的测试论?
3. http://www.uml.org.cn 的Y件测试专?
4. 单元试 《程序员?2002q??
5. JUnit设计模式分析 《程序员?003q??
6. 《Y件测试和JUnit实践?
7. 附gTriangle.java 一个要试的类
Triangle.java
/**
* this is Triangle class
* @author liujun
*/
public class Triangle
{
//定义三角形的三边
protected long lborderA = 0;
protected long lborderB = 0;
protected long lborderC = 0;
//构造函?
public Triangle(long lborderA,long lborderB,long lborderC)
{
this.lborderA = lborderA;
this.lborderB = lborderB;
this.lborderC = lborderC;
}
/**
* 判断是否是三角Ş
* 是返回tureQ不是返回false
*/
public boolean isTriangle(Triangle triangle)
{
boolean isTrue = false;
//判断边界Q大?于200Q出界返回false
if((triangle.lborderA>0&&triangle.lborderA<200)
&&(triangle.lborderB>0&&triangle.lborderB<200)
&&(triangle.lborderC>0&&triangle.lborderC<200))
{
//判断两边之和大于W三?
if((triangle.lborderA<(triangle.lborderB+triangle.lborderC))
&&(triangle.lborderB<(triangle.lborderA+triangle.lborderC))
&&(triangle.lborderC<(triangle.lborderA+triangle.lborderB)))
isTrue = true;
}
return isTrue;
}
/**
* 判断三角形类?
* {腰三角形返回字W串“等C角Ş”；
* {边三角形返回字W串“等边三角Ş”；
* 其它三角形返回字W串“不{边三角形”；
*/
public String isType(Triangle triangle)
{
String strType = "";
// 判断是否是三角Ş
if(this.isTriangle(triangle))
{
//判断是否是等边三角Ş if(triangle.lborderA==triangle.lborderB&&triangle.lborderB==triangle.lborderC)
strType = "{边三角?;
//判断是否是不{边三角?
else if((triangle.lborderA!=triangle.lborderB)&&
(triangle.lborderB!=triangle.lborderC)&&
(triangle.lborderA!=triangle.lborderC))
strType = "不等边三角Ş";
else
strType="{腰三角?;
}
return strType;
}
}
8. 附gExampleTest.java 一个测试用例类
ExampleTest.java
import junit.framework.*;
/**
* Some tests.
*
*/
public class ExampleTest extends TestCase {
public Triangle triangle;
//初始?
protected void setUp() {
triangle=new Triangle(10,2,9);
}
public static Test suite() {
return new TestSuite(ExampleTest.class);
}
//函数isTriangle()的测试用?
public void testIsTriangle() {
assertTrue(triangle.isTriangle(triangle));
}
//函数isType()的测试用?
public void testIsType()
{
assertEquals("q次试",triangle.isType(triangle),"不等边三角Ş");
}
//执行试
public static void main (String[] args) {
//文本方式
junit.textui.TestRunner.run(suite());
//Swingui方式
//junit.swingui.TestRunner.run(suite().getClass());
//awtui方式
//junit.awtui.TestRunner.run(suite().getClass());
}
}
]]>
白盒试——把试对象看作一个打开的盒子，E序内部的逻辑l构和其他信息对试人员是公开的?
回归试——Y件或环境的修复或更正后的“再试”，自动试工具对这cL试尤其有用?
单元试——是最粒度的试Q以试某个功能或代码块。一般由E序员来做，因ؓ它需要知道内部程序设计和~码的细节?
JUnit ——是一个开发源代码的Java试框架Q用于编写和q行可重复的试。他是用于单元测试框架体pxUnit的一个实例（用于java语言Q。主要用于白盒测试，回归试?
2、单元测试概q?
2.1、单元测试的好处
A、提高开发速度——测试是以自动化方式执行的，提升了测试代码的执行效率?
B、提高Y件代码质量——它使用版本发布至集成Q便于实Ch员除错。同时引入重构概念，让代码更q净和富有弹性?
C、提升系l的可信赖度——它是回归测试的一U。支持修复或更正后的“再试”，可确保代码的正确性?
2Q?、单元测试的针对对象
A、面向过E的软g开发针对过E?
B、面向对象的软g开发针对对象?
C、可以做cL试，功能试Q接口测试（最常用于测试类中的ҎQ?
2.3、单元测试工具和框架
目前的最行的单元测试工hxUnitpd框架Q常用的Ҏ语言不同分ؓJUnitQjavaQ，CppUnitQC++Q，DUnit QDelphi Q，NUnitQ?netQ，PhpUnitQPhp Q等{。该试框架的第一个和最杰出的应用就是由Erich Gamma Q《设计模式》的作者）和Kent BeckQXPQExtreme ProgrammingQ的创始?Q提供的开放源代码的JUnit?br />3.Junit入门?
3.1、JUnit的好处和JUnit单元试~写原则
好处Q?
A、可以ɋ试代码与品代码分开?
B、针Ҏ一个类的测试代码通过较少的改动便可以应用于另一个类的测试?
C、易于集成到试人员的构E中QJUnit和Ant的结合可以实施增量开发?
D、JUnit是公开源代码的Q可以进行二ơ开发?
C、可以方便地对JUnitq行扩展?
~写原则Q?
A、是化测试的~写Q这U简化包括测试框架的学习和实际测试单元的~写?
B、是使测试单元保持持久性?
C、是可以利用既有的测试来~写相关的测试?
3.2、JUnit的特?
A、用断aҎ判断期望值和实际值差异，q回Boolean倹{?
B、测试驱动设备用共同的初始化变量或者实例?
C、测试包l构便于l织和集成运行?
D、支持图型交互模式和文本交互模式?
3.3、JUnit框架l成
A、对试目标q行试的方法与q程集合Q可UCؓ试用例(TestCase)?
B、测试用例的集合Q可容纳多个试用例(TestCase)Q将其称作测试包(TestSuite)?
C、测试结果的描述与记录?TestResult) ?
D、测试过E中的事件监听?TestListener)?
E、每一个测试方法所发生的与预期不一致状늚描述Q称其测试失败元?TestFailure)
F、JUnit Framework中的出错异常QAssertionFailedErrorQ?
JUnit框架是一个典型的Composite模式QTestSuite可以容纳Mz自Test的对象；当调用TestSuite对象的run()Ҏ是，会遍历自己容U的对象Q逐个调用它们的run()Ҏ。（可参考《程序员?003-6期）?
3.4、JUnit的安装和配置
JUnit安装步骤分解Q?
?a >http://download.sourceforge.net/junit/中下载JUnit包ƈJunit压羃包解压到一个物理目录中Q例如CQ＼Junit3.8.1Q?
记录Junit.jar文g所在目录名Q例如CQ＼Junit3.8.1\Junit.jarQ?
q入操作pȝQ以Windows2000操作pȝ为准Q，按照ơ序点击“开始 讄 控制面板”?
在控刉杉K项中选择“系l”，点击“环境变量”，在“系l变量”的“变量”列表框中选择“CLASS-PATH”关键字Q不区分大小写）Q如果该关键字不存在则添加?
双击“CLASS-PATH”关键字d字符东yC:QJunit3.8.1\Junti.jar?注意Q如果已有别的字W串请在该字W串的字W结֊上分号“；?Q这L定修改后Junit可以在集成环境中应用了?
对于IDE环境Q对于需要用到的JUnit的项目增加到lib中，其设|不同的IDE有不同的讄 ?
3.5、JUnit中常用的接口和类
Test接口——运行测试和攉试l果
Test接口使用了Composite设计模式Q是单独试用例 QTestCaseQ，聚合试模式QTestSuiteQ及试扩展QTestDecoratorQ的共同接口?
它的public int countTestCasesQ）ҎQ它来统计这ơ测试有多少个TestCaseQ另外一个方法就是public void runQ?TestResult Q，TestResult是实例接受测试结果， runҎ执行本次试?
TestCase抽象cZ—定义测试中固定Ҏ
TestCase是Test接口的抽象实玎ͼQ不能被实例化，只能被承）其构造函数TestCase(string name)Ҏ输入的测试名Uname创徏一个测试实例。由于每一个TestCase在创建时都要有一个名Uͼ若某试p|了，便可识别出是哪个试p|?
TestCasecM包含的setUp()、tearDown()Ҏ。setUp()Ҏ集中初始化测试所需的所有变量和实例Qƈ且在依次调用试cM的每个测试方法之前再ơ执行setUp()Ҏ。tearDown()Ҏ则是在每个测试方法之后，释放试E序Ҏ中引用的变量和实例?
开发h员编写测试用例时Q只需l承TestCaseQ来完成runҎ卛_Q然后JUnit获得试用例Q执行它的runҎQ把试l果记录在TestResult之中?
Assert静态类——一pd断言Ҏ的集?
Assert包含了一l静态的试ҎQ用于期望值和实际值比Ҏ否正，x试失败，Assertcd会抛Z个AssertionFailedError异常QJUnit试框架这U错误归入Failesq加以记录，同时标志为未通过试。如果该cL法中指定一个Stringcd的传参则该参数将被做为AssertionFailedError异常的标识信息，告诉试人员改异常的详细信息?
JUnit 提供?大类31l断aҎQ包括基断言、数字断a、字W断a、布断a、对象断a?
其中assertEqualsQObject expcted,Object actual)内部逻辑判断使用equals()ҎQ这表明断言两个实例的内部哈希值是否相{时Q最好用该Ҏ对相应类实例的D行比较。而assertSameQObject expected,Object actualQ内部逻辑判断使用了Javaq算W?=”，q表明该断言判断两个实例是否来自于同一个引用（ReferenceQ，最好用该Ҏ对不同类的实例的D行比寏VasserEquals(String message,String expected,String actual)该方法对两个字符串进行逻辑比对Q如果不匚w则显C着两个字符串有差异的地斏VComparisonFailurecL供两个字W串的比对，不匹配则l出详细的差异字W?
TestSuite试包类——多个测试的l合
TestSuitec负责组装多个Test Cases。待得cM可能包括了对被测cȝ多个试Q而TestSuit负责攉q些试Q我们可以在一个测试中Q完成全部的对被类的多个测试?
TestSuitecdCTest接口Q且可以包含其它的TestSuites。它可以处理加入Test时的所有抛出的异常?
TestSuite处理试用例?个规U（否则会被拒绝执行试Q?
A 试用例必须是公有类QPublicQ?
B 试用例必须l承与TestCasec?
C 试用例的测试方法必L公有的（ Public Q?
D 试用例的测试方法必被声明为Void
E 试用例中测试方法的前置名词必须是test
F 试用例中测试方法误M传递参?
n TestResultl果cd其它cM接口
TestResultl果c集合了L试累加l果Q通过TestResult实例传递个每个试的RunQ）Ҏ。TestResult在执行TestCase是如果失败会异常抛出
TestListener接口是个事g监听规约Q可供TestRunnercM用。它通知listener的对象相关事ӞҎ包括试开始startTest(Test test)Q测试结束endTest(Test test),错误Q增加异常addError(Test test,Throwable t)和增加失败addFailure(Test test,AssertionFailedError t)
TestFailurep|cL个“失败”状늚攉c，解释每次试执行q程中出现的异常情况。其toString()Ҏq回“失败”状늚要描q?
]]>
本文探讨了单元测试和功能试之间的差别，同时介绍在你的日常开发的q程中如何来利用它测试和开发过E作Z个开发h员，试如此之重要，以至于你甚至应该p几乎所有的旉来完成它。它不仅需要只被划分ؓ开发过E中的某个特定阶Dc显Ӟ它不该是在你把系l交付给客户之前完成的最后一Q务。然而，你又如何得知它在何时l束呢？或是你如何得知是否因Z改一个微的bug而破坏了pȝ的主要功能呢Q或是系l可能会演化成超乎现在想象的模样Q测试，单元的和功能的都应该是开发的q程中的一部分?/p>
单元试应成Z~写代码的核心环节，其当你在从事一个项目时Q紧张的旉U束你的开发进度，你也很想让它是在可控的有序下q行。我希望试也是在你~写代码之前~写试时的重要内容?/p>
一套适用的单元测试应具备以下功能Q?br />说明可能的最佳适用设计
提供cL档的最x?br />判断一个类何时完成
增强开发h员对代码的信?br />是快速重构的基础
在系l中自然要包含单元测试所需的设计文档。重新阅dQ你会发现这是Y件开发进E中的圣杯，文档跟随pȝ的变化而逐步演化。ؓ每一个类提供完备的文档比起ؓ它提供一pd的用框Ӟ或是一pd可控的输入要好得多。这P设计文档׃因ؓ单元试的逐步通过而随时更新?/p>
你应该在你编写代码之前完成编写测试的工序。这样做会ؓ试所涉及的类提供设计ҎQƈ促你关注代码中更小的程序模块。这U练习也会设计Ҏ变得更加单。你不能试图M解将来的情ŞQ去实现不必要的功能。编写测试工作也会让你清楚类会在什么时间结束。可以说Q当所有的试通过Ӟd也就完成了?/p>
最后，单元试会提供给你更高别的依据Q这l对会满_发者的。如果你在改动代码的同时Q进行单元测试，你就会在你破坏的同时立即察觉C态的发生?/p>
功能试甚至比单元测试更加重要，因ؓ它们说明了你的系l就要预备发布了。功能测试将把你的工作系l放|于一个可用的状态中?/p>
一套适用的功能测试应具备以下功能Q?br />有效地掌握用L需?br />向项目组成员Q包括用户和开发者）l出pȝ面͘q些需求的依据
功能试要在有效地情况下掌握用户的需求。而传l的开发者是在用的q程中发现需求的。通常Qh们赞同用项目工Eƈ且花费相当的旉去重新定制它们。当它们被完成时Q它们所得到的仅仅是一堆废U。功能测试雷同于自行生效的用项目的情况。极端程序设计方法（ExtremeProgrammingQ能够说明这U概cXP 的说法就是对未来发生在用户和开发者之间的交流技巧的描述。功能测试也是这U交的l果。而没有功能测试，q种说法也不会徏立v来的?/p>
功能试恰好填充了在单元试和向目组提交的代码依据之间的I隙。单元测试会漏过许多的bug。它可以l出代码中你所需的所有有效部分，它也会给你所需的整个系l。功能测试可以单元试里漏掉的问题曝光。一pd可维护的Q自动化的功能测试也会有漏网的情况，但是它至比独立地进行最全面的单元测试要有用得多?/p>
单元试VS 功能试
单元试告诉开发者代码事情正确地被执行Q而功能测试所说的则是代码在正地发挥功效?/p>
单元试
单元试是从开发者的角度来编写的。它们确保类的每个特定方法成功执行一pd特定的Q务。每一个测试都要保证对于给定的一个已知的输入应该得到所期望的输出?/p>
~写一pd可维护、自动化、没有测试框架的单元试几乎是不可能的。在你开始之前，选择一个项目小l都认可的框架。不断地应用它，逐渐地喜Ƣ它。在极端~程的介l网上Q见资源一节）Q有很多适用的单元测试框架。我喜欢用的是Juint 来进行Java 代码的测试?/p>
功能试
功能试则是从用L角度来编写的。这些测试保证系l能够按照用h期望的那样去q行。很多时候，开发一个完整的pȝ更像是徏造一座大楹{当Ӟq种比喻q不是完全地恰当Q但我们可以扩展它，来理解单元测试和功能试之间的区别?/p>
单元试cM于一个徏{检查员Ҏ屋的现场q行查。他注重的是房屋内部不同的系l，地基Q架构设计，甉|化，垂直的线条等{。他查房屋的某个部分Q以保它在安全状态下Q正无误地工作Q即是说Q直接针Ҏ屋的代码。功能测试在q个剧本里类g房屋的主人在查同L场地。他所期望的是房屋的内部系l正常地q{Qƈ且房屋检查员执行了他的Q务。房屋的Mh看重的是生活在这L房屋中会是什么样子。他xq间房屋的外貌，不同的房间有合适的I间Q房屋适用于家庭的需要，H户恰好位于最佳采光的位置。房屋的Mhq行的是Ҏ屋的功能试Q他站在用户的角度上。房屋检查员q行的是单元试Q他是站在徏设者的角度上?/p>
象单元测试一P~写一pd可维护、自动化、没有测试框架的功能试几乎是不可能的。Junit在单元测试方面做得很好；然而，它在试图~写功能试时就昑־比较松散。Junit 不等同于功能试。现在已l有满q个功能的品问世了Q但是我q没有看到它们被应用于开发品过E里。如果你不能扑ֈ一个测试框架的话，只好自己创Z个了。无论我们在建立一个项目时多么聪明Q徏立的pȝ多么灉|Q如果我们的产品不能用，我们是在浪Ҏ间。结论是Q功能测试是开发进E中最重要的一部分?/p>
因ؓ两种cd的测试都是必要的Q你会需要编写它们的指南?/p>
如何~写单元试
在你开始编写单元测试很Ҏ被激动的情A感染。最单的h方式是为新的代码创建单元测试。ؓ已经存在的代码创建单元测试是一U比较有隑ֺ的开始方式，但是也是可行的。）从新的代码开始，习惯了这L步骤后，q要坚持重新阅读现有代码Qƈ为它们创Z套测试程序?/p>
像前面提到q的一P你应该在你编写要试的代码之前编写单元测试。如何做Cؓq不存在的事物编写测试呢Q好问题Q掌握这个能力需?0Q的智力?0Q技巧。我的意思是你只需假装是在为已有的cȝ写测试。接下来Q进行编写的工作。最初，你将出现很多语法错误Q但是let it beQ不要理会它。紧接着q行单元试Q修改语法错误（x_只用你自己定义的试接口来实现类Q，再一ơ进行测试。重复这个过E，每一ơ都写下充的代码去修改错误Q进行测试直到它们通过为止。当所有的单元试都通过Ӟ代码才算真正地完成了?/p>
一般地_你的cdh开攄单元试方式。然而，带有直截了当的功能性的Ҏ比如_Java 语言里的Getting 和Setting dҎQ就不需要单元测试，除非它们是以“特D”的方式q行的。接下来的指导就是，当你感到需要对代码中的某些Ҏ添加注释时Q同时要~写出单元测试。如果你同很多的E序员一P厌恶Z码写注释Q单元测试就是将你的代码的特性文档化的一U好Ҏ?/p>
单元测试同被测试的相关的类打包在一赗（q种l织的方式允许每一个单元测试都能够直接讉KcM被打包和保护的方法和参数Q。要避免在单元测试中用到域对象（domain objectQ。域对象是对于一个应用程序特定的对象?/p>
例如Q电子表格应用程序有个工作簿对象Q它是一个域对象。如果你的一个类已经知道了域对象Q在你的试中用到这些对象是很好的。但是如果你的类没有涉及到这些对象，׃要在试里让它们同类U缠不清了。不q样做的话，׃产生打包的代码被重用。经常是Z个项目创建的cM可以应用于其他的目Q这样可能会出现直接重用q些cȝ情况。但是如果针对这些类的测试也用于另外的项目对象，让测试生效会很费Ӟ通常试不是被抛弃掉是被重新编写?/p>
以上的一些技巧会让你从中受益Q但最重要的是如果你不实际地去做，永q不会对单元试有全面、深入的理解。更早地q行试Qƈ且在整个q程中都在代码中l出全面的依据。当目q展Ӟ你会随时d更多的特性。运行测试就会提醒你Q实现刚d的特性会不会破坏已有的东ѝ?/p>
在你已经掌握~写单元试的技巧之后，你需要重新阅d存在的代码。的，为它们编写代码可能会是一场挑战。但是千万不要ؓ了测试的目的而测试。可以说Q编写测试是一件紧跟时效的事情Q尤其是当你发现要修改一个没有好的测试程序的cLQ那是d试的恰当时机。和q_一P单元试应该具备cL个方法的Ҏ。实现测试的一个最单的Ҏ是Q测试的同时一定要注意代码的注释。在单元试中，不能放过M一个注释，在描q测试方法的开始就要ؓ单元试d大量的注释中?/p>
如何~写功能试
管功能试是如此重要，它也有个开发过E里丑陋的生子的坏名声。在大多数的目里，是由一个独立的工作l来完成功能试的工作。通常需要一h在系l中的相互协助才能保证工序的正确q行。这U通常的看法和队伍的组建的做法Q都是非常愚蠢的?/p>
功能试同单元测试相cM。一旦要~写有用h入的产品的代码（例如Q对话框Q时Q就要编写测试，但是一定要在实际编写代码之前做。一旦你开始了一ҎdQ就要在功能试的框枉清楚地描q这个Q务的内容。你加入的新代码的同时进行单元测试，开发工作就向前持箋q行?/p>
当所有的单元试都进行通过后，再进行最初的功能试来判断项目是否可以通过Q或是需要修攏V理想的状况下，功能试组的概念应该不存在的。开发者应该同用户一同编写功能测试。系l通过了一pd的单元测试后Q负责进行功能测试的组成员p改变初试试的参敎ͼ再进行系l的功能试?/p>
单元试和功能测试之间的界线
一般情况下Q很隑ֈ清在单元试和功能测试之间的界限。说实话Q一直以来，我就不知道这个界U应该定在哪里。当~写单元试Ӟ我用以下几个Ҏ来判定单元测试是不是已经变成了功能测试：
如果单元试越了类之间的界限，它可能变成了功能试
如果单元试变得非常的复杂，它可能变成了功能试
如果单元试变得很脆弱（x_它已l成Z个测试，但是却因q合不同用户需求的改变而被动地变化Q，它可能变成了功能试
如果单元试比需要测试的代码q要难于~写Q它可能变成了功能测?/p>
注意“它可能变成了功能测试”的说法Q在q里没有严格的标准。在单元试和功能测试之间是有界U的Q但是你必须自己判定它在哪里。单元测试进行地利Q特定的试逾越两者界U的q渡p明显?/p>
l论
单元试以开发者的角度来编写，q注重被试cȝҎ。当~写单元试Ӟ利用以下几条指导Q?br />在类代码q行试之前~写单元试
在单元测试里掌握代码的注?br />试所有执行特定功能的公用E序Q即是说Q和Java 语言中的Getting 和Setting dҎ不同的方法。除非它们是通过一U特D的方式来完成Getting 和Setting 功能的。）
所有的试目同被试的类打包在一Pq且分配它们对在模块包内的和被保护成?br />的访问权?br />在单元测试中避免使用某些特定的对?/strong>
功能试也需要从用户的角度出发来~写Qƈ且注重用h感兴的pȝ功能。选择一个适当的功能测试框Ӟ或是开发出一U，q利用这些功能测试来制定用户们想要的东西。通过q种方式Q功能测试的人员可以获得一个自动的工具Qƈ且对使用工具的习惯有了一个好的v炏V?/p>
单元测试和功能试作ؓ开发进E的核心内容。这样做Q你׃定pȝ在正常运转。如果没有，你恐怕不能保证系l是正常工作的。测试可能不是一件好玩的事情Q但是从事单元测试和功能试会开发过E里含有更多的乐?/p>
资源
“利用Ant 和JUnit 改进开发过E”（开发工作，2000 q?2 月）揭示了单元测试的益处Q尤其是应用了Ant 和Junit 之后?br />开始了解极端编E的Ҏ
从极端编E的|页上下载各U单元测试的框架
]]>
3. 试用例开?/p>
一个好的测试用例就是有一个合理的概率来找到BugQ不要冗余，要有针对性，一个测试只针对一件事情。特别是功能试的时候，如果一个测试是了两项功能Q那么如果测试结果失败的话，׃知道到底是哪功能出了问题?/p>
试用例开发中主要使用的技术有{hcd分，边界值的分析QError Guessing Testing?/p>
{hcd分是Ҏ输入输出条gQ以及自w的一些特性分成两个或更多个子集，来减所需要测试的用例个数Qƈ且能用很的试用例来覆盖很多的情况Q减测试用例的冗余度。在{hcd分中Q最基本的划分是一个ؓ合法的类Q一个ؓ不合法的cR?/p>
边界值的分析是利用了一个规律，即程序最Ҏ发生错误的地方就是在边界值的附近Q它取决于变量的cdQ以及变量的取D围。一般对于有n个变量时Q会?n 1个测试用例，取值分别是min-1, min, min 1, normal, max-1, max,max 1的组合。边界值的分析的缺点，是对逻辑变量和布型变量不v作用Q还有可能会忽略掉某些输入的l合?/p>
Error Guessing Testing完全靠的是经验，所设计的测试用例就是常说的猜测。感觉到软g在某个地方可能出错，去设计相应的测试用例，q主要是靠实际工作中所U篏的经验和知识。其优点是速度快，只要惛_刎ͼp很快设计出测试用例。缺点就是没有系l性，无法知道覆盖率会有多，很可能会遗漏一些测试领域?/p>
实际上在微Y是采用一些专门的软g或工兯责测试用例的理Q有一些测试信息可以被记录下来Q比如测试用例的单描qͼ在哪些^台执行，是手工测试还是自动测试，q行的频率是每天q行一ơ，q是每周q行一ơ。此外还有清晰的试通过或失败的标准Q以及详l记录测试的每个步骤?/p>
4. Bug跟踪q程
在Y件开发项目中Q测试h员的一Ҏ重要使命是Ҏ有已知Bugq行有效的跟t和理Q保证品中出现的所有问题都可以得到有效的解冟뀂一般地Q项目组发现、定位、处理和最l解决一个Bug的过E包括Bug报告、Bug评估和分配、Bug处理、Bug关闭{四个阶D：
1Q测试工E师在测试过E中发现新的Bug后，应向目l报告该Bug的位|、表现、当前状态等信息。项目组在Bug数据库中d该Bug的记录?/p>
2Q开发经理对已发现的Bugq行集中讨论Q根据Bug对Y件品的影响来评估Bug的优先Q制定Bug的修正策略。按照Bug的优先序和开发h员的工作安排Q开发经理将所有需要立卛_理的Bug分配l相应的开发工E师?/p>
3Q开发工E师Ҏ安排对特定的Bugq行处理Q找Z码中的错误原因，修改代码Q重新生成品版本?/p>
4Q开发工E师处理了Bug之后Q测试h员需要对处理后的l果q行验证Q经q验证确认已正确处理的Bug被标Cؓ关闭QCloseQ状态。测试工E师既需要验证Bug是否已经被修正，也需要确定开发h员有没有在修改代码的同时引入新的Bug?/p>
5. Bug的不同处理方?/p>
在某些情况下QBug已处理ƈ不意味着Bug已经被修正。开发工E师可以推迟Bug的修正时_也可以在分析之后告知试工程师这实际上不是一个真正的Bug。也是_某特定的Bugl开发工E师处理之后Q该Bug可能包括以下几种状态?/p>
已修正：开发工E师已经修正了相应的E序代码Q该Bug不会出现了?/p>
可推q：该Bug的重要程度较低，不会影响当前应提交版本的主要功能Q可安排在下一版本中再行处理?/p>
设计问题Q该Bug与程序实现无养I其所表现出来的行为完全符合设计要求，Ҏ应提交给E序l理处理?/p>
无需修正Q该Bug的重要程度非怽Q根本不会媄响程序的功能Q项目组没有必要在这些Bug上浪Ҏ间?/p>
五、成ZU试工程师的要求
要成Z名优U的测试工E师Q首先对计算机的基本知识要有很好的了解，_N一门或多门的编E语aQ具备一定的E序调试技能，掌握试工具的开发和使用技术。同时要比较l心Q会按照d的轻重缓急来安排自己的工作，要有很好的沟通能力。此外，q要善于用非常规的方式思考问题，可能多的参加Y件测试项目，在实践中学习技能，U篏l验Q不断分析和ȝ软g开发过E中可能出错的环节。这P一名优U的测试工E师׃软g试的实践中脱颖而出了?/p>
模型实际上就是用语言把一个系l的行ؓ描述出来Q定义出它可能的各种状态，以及它们之间的{换关p，即状态{换图。模型是pȝ的抽象。基于模型的试是利用模型来生成相应的测试用例，然后Ҏ实际l果和原先预想的l果的差异来试pȝQ过E如下图所C?/p>
三、Y件测试的cd
常见的Y件测试类型有Q?/p>
BVT (Build Verification Test)
BVT是在所有开发工E师都已l检入自q代码Q项目组~译生成当天的版本之后进行，主要目的是验证最新生成的软g版本在功能上是否完整Q主要的软gҎ是否正。如无大的问题，可以进行相应的功能试。BVT优点是时间短Q验证了软g的基本功能。缺Ҏ该种试的覆盖率很低。因行时间短Q不可能把所有的情况都测试到?/p>
Scenario TestsQ基于用户实际应用场景的试Q?/p>
在做BVT、功能测试的时候，可能试主要集中在某个模块，或比较分ȝ功能上。当用户来用这个应用程序的时候，各个模块是作Z个整体来使用的，那么在做试的时候，需要模仿用戯样一个真实的使用环境Q即用户会有哪些用法Q会用这个应用程序做哪些事情Q操作会是一个怎样的流E。加了这些测试用例后Q再与BVT、功能测试配合，p使Y件整体都能符合用户用的要求。Scenario Tests优点是关注了用户的需求，~点是有时候难以真正模仿用L实的使用情况?/p>
Smoke Test
在测试中发现问题Q找C一个BugQ然后开发h员会来修复这个Bug。这时想知道q次修复是否真的解决了程序的BugQ或者是否会对其它模块造成影响Q就需要针Ҏ问题q行专门试Q这个过E就被称为Smoke Test。在很多情况下，做Smoke Test是开发h员在试图解决一个问题的时候，造成了其它功能模块一pd的连锁反应，原因可能是只集中考虑了一开始的那个问题Q而忽略其它的问题Q这可能引起了新的Bug。Smoke Test优点是节省测试时_防止buildp|。缺Ҏ覆盖率还是比较低?/p>
此外QApplication Compatibility TestQ兼Ҏ测试）Q主要目的是Z兼容W三方YӞ保W三方Y件能正常q行Q用户不受媄响。Accessibility TestQY仉用性测试）Q是保软g对于某些有残疄人士也能正常的用，但优先比较低。其它的试q有Functional TestQ功能测试）、Security TestQ安全性测试）、Stress TestQ压力测试）、Performance TestQ性能试Q、Regression TestQ回归测试）、Setup/Upgrade TestQ安装升U测试）{?/p>
四、微软的软g试工作
1. 基本情况
试在微软公司是一w帔R要的工作Q微软公司在此方面的投入是非常巨大的。微软对试的重视表现在工程开发队伍的人员构成上，微Y的项目经理、Y件开发h员和试人员的比例基本是1Q?Q??Q?Q?Q可以看出开发h员与试人员的比例是1Q?。对于测试的重视q表现在最后品要发布的时候，此品的所有相关部门都必须{֭Q而测试h员则hl对的否x?/p>
试人员中分成两U职位，Software Development Engineer in TestQ测试组的Y件开发工E师Q实际上q是属于开发h员，他们具备~写代码的能力和开发工兯Y件的l验Q侧重于开发自动化试工具和测试脚本，实现试的自动化。Software Test EngineerQY件测试工E师Q具体负责测试Y件品，主要完成一些手工测试以及安装配|测试?/p>
2. 试计划
试计划是测试h员管理测试项目，在Y件中LBug的一U有效的工具。测试计划主要有两个作用Q一是评判团队的试覆盖率以及效率，让测试工作很有条理的逐步展开。二是有利于与项目经理、开发h员进行沟通。有了测试计划之后，他们p够知道你是如何开展测试工作的Q他们也会从中提出很多有益的意见Q确保测试工作顺利进行。MQ有了测试计划可以更好的完成试工作Q确保用L满意度?/p>
试人员在编写测试计划之前，应获得以下文档：
1Q程序经理编写的产品功能说明书或产品开发计划；
2Q程序经理或开发h员提供的开发进度表?/p>
Ҏ产品的特性及开发进度安排，试人员制定具体的测试计划。测试计划通常包括以下内容Q?/p>
1Q测试目标和发布条gQ?/p>
a. l出清晰的测试目标描qͼ
b. 定义产品的发布条Ӟ卛_辑ֈ何种试目标的前提下才可以发布品的某个特定版本?/p>
2Q待品范_
a. 软g主要Ҏ?功能说明Q即待测软g主要Ҏ的列表Q?/p>
b. Ҏ?功能试一览，应涵盖所有特性、对话框、菜单和错误信息{待内容，q列举每个测试范围内要重点考虑的关键功能?/p>
3Q测试方法描qͼ
a. 定义试软g产品时用的试ҎQ?/p>
b. 描述每一U特定的试Ҏ可以覆盖哪些试范围?/p>
4Q测试进度表Q?/p>
a. 定义试里程；
b. 定义当前里程的详细试q度?/p>
5Q测试资源和相关的程序经?开发工E师Q?/p>
a. 定义参与试的h员；
b. 描述每位试人员的职责范_
c. l出与测试有关的E序l理/开发工E师的相关信息?/p>
6Q配|范围和试工具Q?/p>
a. l出试时用的所有计机q_列表Q?/p>
b. 描述试覆盖了哪些硬件设备；
c. 试时用的主要试工具?/p>
此外Q还应列出测试中可能会面临的风险及测试的依赖性，x试是否依赖于某个产品或某个团队。比如此Ҏ试依赖性WindowsCEq个操作pȝQ而这个系l要明年2月䆾才能做好Q那么此Ҏ试就可能只有在明q?月䆾才能完成Q这样就存在着依赖关系。如果那个团队的开发计划往后推Q则此项试也会被推q?br />
]]>
软g试是Y件开发过E的重要l成部分Q是用来认一个程序的品质或性能是否W合开发之前所提出的一些要求。Y件测试的目的Q第一是确认Y件的质量Q其一斚w是确认Y件做了你所期望的事情（Do the right thingQ，另一斚w是确认Y件以正确的方式来做了q个事gQDo it rightQ。第二是提供信息Q比如提供给开发h员或E序l理的反馈信息，为风险评估所准备的信息。第三Y件测试不仅是在测试Y件品的本nQ而且q包括Y件开发的q程。如果一个Y件品开发完成之后发C很多问题Q这说明此Y件开发过E很可能是有~陷的。因此Y件测试的W三个目的是保证整个软g开发过E是高质量的?/p>
软g质量是由几个斚w来衡量的Q一、在正确的时间用正确的的Ҏ把一个工作做正确QDoing the right things right at the right time.Q。二、符合一些应用标准的要求Q比如不同国家的用户不同的操作习惯和要求Q项目工E中的可l护性、可试性等要求。三、质量本w就是Y件达C最开始所讑֮的要求，而代码的优美或精巧的技巧ƈ不代表Y件的高质量（Quality is defined as conformance to requirements, not as “goodness?or “elegance?Q。四、质量也代表着它符合客L需要（Quality also means “meet customer needs?Q。作Y件测试这个行业，最重要的一件事是从客L需求出发，从客L角度ȝ产品Q客户会怎么M用这个品，使用q程中会遇到什么样的问题。只有这些问题都解决了，软g产品的质量才可以说是上去了?/p>
试人员在Y件开发过E中的Q务：
1、寻找BugQ?/p>
2、避免Y件开发过E中的缺P
3、衡量Y件的品质Q?/p>
4、关注用L需求?/p>
ȝ目标是：保软g的质量?/p>
二、常用的软g试Ҏ
1. 黑盒试
黑盒试思义是被系l看成一个黑盒，从外界取得输入，然后再输出。整个测试基于需求文档，看是否能满需求文档中的所有要求。黑盒测试要求测试者在试时不能用与被测pȝ内部l构相关的知识或l验Q它适用于对pȝ的功能进行测试?/p>
黑盒试的优ҎQ?br />1Q比较简单，不需要了解程序内部的代码及实玎ͼ
2Q与软g的内部实现无养I
3Q从用户角度出发Q能很容易的知道用户会用到哪些功能，会遇到哪些问题；
4Q基于Y件开发文档，所以也能知道Y件实C文档中的哪些功能Q?/p>
5Q在做Y件自动化试时较为方ѝ?/p>
黑盒试的缺ҎQ?br />1Q不可能覆盖所有的代码Q覆盖率较低Q大概只能达到M码量?0%Q?/p>
2Q自动化试的复用性较低?/p>
2. 白盒试
白盒试是指在测试时能够了解被测对象的结构，可以查阅被测代码内容的测试工作。它需要知道程序内部的设计l构及具体的代码实现Qƈ以此为基来设计测试用例。如下例E序代码Q?/p>
HRESULT Play( char* pszFileName ){
if ( NULL == pszFileName ) return;
if ( STATE_OPENED == currentState )
{PlayTheFile();}
return;}
M代码之后可以知道Q先要检查一个字W串是否为空Q然后再Ҏ播放器当前的状态来执行相应的动作。可以这栯计一些测试用例：比如字符Ԍ文gQؓI的话会出现什么情况；如果此时播放器的状态是文g刚打开Q会是什么情况；如果文g已经在播放，再调用这个函C是什么情c也是_Ҏ播放器内部状态的不同Q可以设计很多不同的试用例。这些是在纯_做黑盒试时不一定能做到的事情?/p>
白盒试的直接好处就是知道所设计的测试用例在代码U上哪些地方被忽略掉Q它的优Ҏ帮助软g试人员增大代码的覆盖率Q提高代码的质量Q发C码中隐藏的问题?/p>
白盒试的缺ҎQ?/p>
1Q程序运行会有很多不同的路径Q不可能试所有的q行路径Q?/p>
2Q测试基于代码，只能试开发h员做的对不对Q而不能知道设计的正确与否Q可能会漏掉一些功能需求；
3Q系l庞大时Q测试开销会非常大?/p>
3. Z风险的测?/b>
Z风险的测试是指评估测试的优先U，先做高优先的测试，如果旉或精力不够，低优先的测试可以暂时先不做。有如下一个图Q横轴代表媄响，竖u代表概率Q根据一个Y件的特点来确定：如果一个功能出了问题，它对整个产品的媄响有多大Q这个功能出问题的概率有多大Q如果出问题的概率很大，Z问题Ҏ个品的影响也很大，那么在测试时׃定要覆盖到。对于一个用户很用到的功能Q出问题的概率很，qZ问题的媄响也不是很大Q那么如果时间比较紧的话Q就可以考虑不测试?/p>
Z风险试的两个决定因素就是：该功能出问题对用L影响有多大，出问题的概率有多大。其它一些媄响因素还有复杂性、可用性、依赖性、可修改性等。测试h员主要根据事情的轻重~急来军_试工作的重炏V?br />
]]>
2Q项目需求及相关资源了解Q?br />试l组长（或测试经理）需要对目的客户需求和目本n要求q行了解Q明测试范围、测试指标、测试要点，试所需软硬件环境等Qؓ制定试计划打好基础?/p>
二、制定测试计?br />主要包括试软硬件资源，人力资源Q测试指标，_略q度Q采集的度量数据Q风险，U定{。网l上有很多这斚w的模板资料，定义好测试过E中要收集的度量数据Q一般包括缺hw的属性，例如严重E度Q功能类别，发现阶段Q工作量Q对应用例等Q各周期内（例如以周为单位）~陷的收敛情况（发现数量Q解x量，遗留数量Q，
阶段分布情况Q缺陷存zL늭?/p>
三、编制测试用?br />1Q了解项目需求（客户需求与目需求）
一斚w为编制测试用例打好基Q另一斚w可以扑և需求中存在的问题?br />2Q明公q?br />扑և试需求中Q在~写用例时会出现重复的需求，~写公共用例Q这样回减少后期用例~写工作量，也方便后期用例的l护?br />3Q明手动测试用例与自动化测试用例范?br />可以避免重复力_Q有些业务流E可以用自动化的用例来代替手动工作?br />4Q确定用例编写进?br />5Q正式编?br />6Q用例验?br />7Q明测试用例执行顺?/p>
四、实施测?br />1Q确定实施进度?br />2Q搭建测试环境?br />3Q执行测试用例，记录用例执行l果Q报告缺陗?br />4Q记录度量数?br />5Q维护测试用?/p>
五、测试ȝ
1Q测试停止评伎ͼ参照试用例执行情况Q缺h敛情况，与测试指标偏差情늭Q?br />2Q测试ȝ报告
3Q提交汇d量数据，试部门存档?br />
]]>