单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。 单元测试任务 　　单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。 　　模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素： 　　1 输入的实际参数与形式参数的个数是否相同； 　　2 输入的实际参数与形式参数的属性是否匹配； 　　3 输入的实际参数与形式参数的量纲是否一致； 　　4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同； 　　5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配； 　　6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致； 　　7 调用预定义函数时所用参数的个数、属性和次序是否正确； 　　8 是否存在与当前入口点无关的参数引用； 　　9 是否修改了只读型参数； 　　10 对全程变量的定义各模块是否一致； 　　11是否把某些约束作为参数传递。 　　如果模块内包括外部输入输出，还应该考虑下列因素： 　　1 文件属性是否正确； 　　2 OPEN/CLOSE语句是否正确； 　　3 格式说明与输入输出语句是否匹配； 　　4缓冲区大小与记录长度是否匹配； 　　5文件使用前是否已经打开； 　　6是否处理了文件尾； 　　7是否处理了输入/输出错误； 　　8输出信息中是否有文字性错误； 　　检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误： 　　1 不合适或不相容的类型说明； 　　2变量无初值； 　　3变量初始化或省缺值有错； 　　4不正确的变量名（拼错或不正确地截断）； 　　5出现上溢、下溢和地址异常。 　　除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。 　　在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括： 　　1 误解或用错了算符优先级； 　　2混合类型运算； 　　3变量初值错； 　　4精度不够； 　　5表达式符号错。 　　比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误： 　　1不同数据类型的对象之间进行比较； 　　2错误地使用逻辑运算符或优先级； 　　3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等； 　　4比较运算或变量出错； 　　5循环终止条件或不可能出现； 　　6迭代发散时不能退出； 　　7错误地修改了循环变量。 　　一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题： 　　1输出的出错信息难以理解； 　　2记录的错误与实际遇到的错误不相符； 　　3在程序自定义的出错处理段运行之前，系统已介入； 　　4异常处理不当； 　　5错误陈述中未能提供足够的定位出错信息。 　　边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。 单元测试过程 　　一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。 　　应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。 　　驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。 　　提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。

在计划配置测试时应该采用的一般过程

1、确定所需的硬件类型

2、确定有哪些厂商的硬件、型号和驱动程序

3、确定可能的硬件特性、模式和选项

4、将确定后的硬件配置缩减为可控制的范围

5、明确与硬件配置有关的软件唯一特性

6、设计在每一种配置中执行的测试用例

7、在每种配置中执行测试

 

我们常见软件测试的技巧 ：

　　软件测试虽然辛苦，但是掌握了一定的技巧之后将使你事半功倍。

　　(1) 边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。

　　(2) 非法测试，例如在输入数字的地方输入字母。

　　(3) 跟踪测试，跟踪一条数据的流程,保证数据的正确性。

　　(4) 在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。

　　(5) 接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。

　　(6) 代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。

　　(7) 突发事件测试，服务器上可能发生意外情况的测试。

　　(8) 外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。

　　(9) 在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。

　　(10) 认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。

　　(11) 文字测试，如果在系统中有用词不当的地方，我想这是不应该的。

　　(12) 系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。

　　(13) 用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。

在 “叶帆小筑” 中看到这篇文章，对我很有帮助，就转了过来。

如何写一份有用的Bug报告?

有用的Bug报告是用于正确修复Bug的。因此一份有用的Bug报告通常地有两个特征：

可复现：

      如果工程师不能发现或最终证明这一Bug存在,工程师或许会将它标记为 "WORKSFORME( 所有要重新产生这个bug的企图是无效的)"或 " INVALID(描述的问题不是一个bug ) "，并且继续进行下一个Bug的修复工作。任何你能提供的详尽描述将为工程师修复Bug提供帮助。

详细精确：

       如果工程师能越早隔离、定位问题，就越可能方便地修复。

        让我们举一个例子：你正在测试一个Web阅览器，在访问foo.com网站时崩溃了，因此你想写一个Bug报告:

       糟糕的Bug报告：“我的浏览器崩溃了。我正在访问foo.com。我的计算机使用 Windows系统。这真是个大问题，你们应该马上修复它。顺便说一下,你们的图标真恶心，如果你们保留那些丑陋的图标，没有人将再使用你们的软件。还有我的祖母的主页看上去外观也不正确，或者，它们全被搞乱了。祝好运。”

         有用的Bug报告：“每当我访问foo.com时应用程序就崩溃了，我使用的是在Win NT 4.0 (Service Pack 5) 系统上的 10.28.99版本。 我也曾重新引导进入Linux，使用10.28.99 Linux版本，这个问题也出现了。我发现每次崩溃都发生在绘制这个页面位于上端的 Foo横幅的时候。我分析了页面，发现除非你删除 " border =0"属性，否则下列图片链接将导致应用程序崩溃 ：(附图片)

如何在Bugzilla中输入你有用的Bug报告?
       在你输入你发现的Bug前，应使用 Bugzilla查询页检查是否你发现的是已知并被报告的Bug。（如果你发现的Bug同第37条已经知道的结果相同，你报告的话，就可能骚扰工程师，从而影响工程师修复Bug的效率。）

       下一步,确认你发现的Bug是在最新的版本中所发生的。（工程师更倾向于对那些他们正在编写的代码中的严重问题感兴趣，而不是对以前那些废弃代码中数以百计的Bug进行修复。）
 
如果你已经在当前版本中发现了一个新的Bug，请在Bugzilla中报告：

      从你的Bugzilla主页中,选择“Enter a new bug”。

       选择你发现Bug的产品。

        输入你的电子邮件地址、密码，然后按“Login”按钮。（如果你遗忘或还没有得到密码,让密码正文框空白，并且按 " E-mail me a password "按钮，不久你将收到包含你的密码的电子邮件。）   

        现在，填写那张出现的表格。以下说明表格中的所有含义：

你在哪儿发现了Bug？

1,产品：在哪一个产品中你发现了Bug？
你在上一页已选择 ,enter前已经选择,

2,版本：在产品的哪一个版本中你找到了Bug？
If applicable.如果有的话。

3,产品单元：在产品的哪一个单元中存在Bug？

      Bugzilla在你输入一个Bug时，要求你必须选择一个产品单元。（如果你无法确定所列产品单元的意思，单击产品单元链接，那将联接到对每个产品单元的详细描述，这会帮助你作出最好选择。）

4, 平台：在哪一个硬件平台上你找到了这个Bug？
（例如Macintosh、SGI、Sun、PC。）如果你知道这个Bug会发生在所有硬件平台上，请选择“All”，否则请选择相应的你发现Bug的硬件平台，如果列表中没有出现你的硬件平台，请选择“Other”。

5,OS：在哪一个操作系统（OS）中你找到了这个Bug？
（例如Linux、Windows NT、Mac OS 8.5。）
如果你知道这个Bug会发生在所有OS中，请选择“All”，否则请选择相应的你发现Bug的OS，如果列表中没有出现你的OS，请选择“Other”。

这个Bug有多重要？

     1,严重性：这个Bug的破坏性有多大？
这项值默认为“normal”。（要为一个特定的Bug界定最适当的严重性，单击严重性链接，你将得到每个选择的完全解释，从Critical到Enhancement。）

     2,谁将跟踪解决Bug？

     3,分配给：哪一个工程师将负责修复这个Bug？
在你提交Bug报告后，Bugzilla将自动把Bug分配给默认工程师；填写正文框将允许你用手工方式把它分配给其它工程师。（要察看每个产品单元的默认工程师列表,请单击产品单元链接。）

      4,Cc：还有哪些人将收到这个Bug修复更新的电子邮件?
列出其他需要通过电子邮件收到这个Bug修复更新的人的完整的电子邮件地址。只要你愿意，你可以输入足够多的电子邮件地址，电子邮件地址之间必须用逗号分隔,不可有空格。 

      5,关于这个Bug你还能告诉工程师什么？ 

      6,URL:在什么 URL中你发现这个Bug？
      如果你是在特殊的 URL中遇到Bug，请在这里提供它（们）。如果你已经将Bug隔离在一段特殊的HTML程序段中，也请在这里为它提供URL。

      7,概述：你如何在大约60个字符之内将这个Bug进行描述？
一个好的概述能很快和唯一识别一份Bug报告，否则，开发者将不能通过Bug概述进行有意义的查询，并且在浏览一份有10页长的Bug列表时，可能忽略你的Bug报告。

      关于“在Tosh Tecra 780DVD w/ 3c589C上安装PCMCIA失败”的概述是有用的标题，而“软件失败”或 “安装问题”将是糟糕的标题的例子。

      8,描述：还有什么你能告诉工程师关于这个Bug的？
      如果可能，在这个域中请提供问题诊断的详细细节。


如果适用，下列的Bug报告模板将帮助你保证不会漏掉所有相关信息：

总的描述：对概述的更为详细的补充

Drag-selecting any page crashes Mac builds in NSGetFactory

Bug复现的步骤：是跟踪Bug必须的最小集，包含所有的特殊安装步骤。

1) View any web page. (I used the default sample page, resource:/res/samples/test0.html) 观看所有网页。 (我使用了缺省样页， 资源:/res/samples/test0.html)
2) Drag-select the page. (Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser's content region to the bottom of the browser's content region.) 扯拽选择页。 (具体地， 当持续鼠标键时， 扯拽鼠标向下从任何点在浏览器的美满的区域对浏览器的美满的区域的底部。) 


目前的结果：应用程序在经过那些步骤后的结果

The application crashed.  应用被碰撞。(程序崩溃)

期望的结果：当Bug不再出现时，应用程序应有的结果

The window should scroll downwards. Scrolled content should be selected. (Or, at least, the application should not crash.) 窗口应该移动向下。 应该选择移动的内容。 (或， 至少， 应用不应该碰撞。) 

时间及硬件平台：第一次出现这个Bug的时间及硬件平台。

11/2/99 build on Mac OS (Checked Viewer & Apprunner) 11/2/99修造在Mac OS (被检查的观察者& Apprunner)

其它环境及硬件平台：Bug是否出现在其他硬件平台或浏览器上。

- Occurs On
Seamonkey (11/2/99 build on Windows NT 4.0)

- Doesn't Occur On
Seamonkey (11/4/99 build on Red Hat Linux; feature not supported) Internet Explorer 5.0 (RTM build on Windows NT 4.0)
Netscape Communicator 4.5 (RTM build on Mac OS)

-在Seamonkey
(11/2/99修造在Seamonkey (基于windows NT 4.0)
-不发生在11/4/99Red Hat Linux; 特点没支持的) Internet Explorer 5.0 (RTM修造在windows NT 4.0)
Netscape Communicator 4.5 (RTM基于Mac OS) 


其它信息：任何其他调试信息

Win32: if you receive a Dr. Watson error, please note the type of the crash, and the module that the application crashed in. (e.g. access violation in apprunner.exe)

Mac OS: if you're running MacsBug, please provide the results of a how and an sc.

Unix: please provide a minimized stack trace, which can be generated by typing gdb apprunner core into a shell prompt.

Win32: 如果您接受一个 Dr. Watson 错误, 请注意崩溃的型, 和模块, 应用碰撞了in. (即访问违例在apprunner.exe)

Mac OS: 如果你是在运行MacsBug, 请提供怎么和sc 的结果。

Unix: 请提供减到最小的栈检索, 可能由键入的gdb apprunner 核心引起入壳提示。

你已经完成了一篇不错的bug报告！