白盒测试心得

白盒测试心得六步骤：

第一步，编写测试案例：程序出口检查案例+路径覆盖选择测试案例+编码规范检查(为防止测试完成后再编写案例文档时会发生案例遗漏补写情况，提议应先给出测试案例的规范计划)

第二步，针对程序出口做数据测试：程序中一般情况下不免存在数据输入出口，包括如return等的返回值，此时可先对其输入出口数据进行正确性测试。如果程序是无直接数据出口的程序，那么我们也可以在程序中恰当变量位置，适当加入一些如print()的输出语句来检查程序执行中数据的准确性。(其实这一步严格地说应属于程序的黑盒测试)

第三步，绘制程序流程，以方便接下来对程序做路径或条件覆盖等测试,流程图应正确清晰给出。流程要是都给错了，那么可能导致你接下来做的东西都是错误的, 所以在这一步时应认真对待，最好可以与编写该程序的开发人员进行沟通，让他确认你给出的流程是否正确(因为现在大多数开发人员在编码前未能事先给出相应的流程图，编码后可能也很少会给出，此时就只能靠测试人员与开发人员的沟通确认)。并对其功能的完整性进行检查。

第四步，依照流程图，选择合适的测试方法，并进行测试：白盒测试方法有很多种类，语句覆盖->判定覆盖->条件覆盖测试->判定/条件覆盖->条件组合覆盖->路径覆盖测试等，其检错能力左到右是由弱到强的，但是不能盲目选择检错性较强的测试方法，因根据程序需要而定，有些程序路径千千万万，这时，就不要硬钻脑门子啦，可以适当选择条件覆盖测试方法。

第五步，检查程序规范性，包括命名是否符合规范等。

第六步，补充测试案例文档：将测试结果补充进先前案例文档中。

黑盒测试 简单讨论

黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：

　　1）功能错误或遗漏；
　　2）界面错误；
　　3）数据结构或外部数据库访问错误；
　　4）性能错误；
　　5）初始化和终止错误。
　　
白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：

　　·如何测试功能的有效性？
　　·何种类型的输入会产生好的测试用例？
　　·系统是否对特定的输入值尤其敏感？
　　·如何分隔数据类的边界？
　　·系统能够承受何种数据率和数据量？
　　·特定类型的数据组合会对系统产生何种影响？
　　
运用黑盒测试方法，可以导出满足以下标准的测试用例集：

　　1）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
　　2）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误
1、架构和算法的可行性测试分析：主要包括性能、并发等方面
2、CodeReview：很简单，但很多人没有这样做；其实这比“黑盒测试”更容易发现边界问题、流程正确性问题等。值得推广！
3、测试驱动和单元测试，很多人为了达到那些并不太懂编程管理层的要求，往往是少了这些看似不容易出成绩的步骤。（很大程度上改变设计思维） 知道可能出错的地方，当然容易避免出错。
4、UML和用例：特别是UI建模，个人觉得最不可少；UML和用例至少要能覆盖核心内容。 具体如何做，要根据每个人、每个单位甚至每个项目做具体优化，这里提供思路。
5、用心架构（各功能模块的关系、分布式计算的节点关系、类的层次结构、升级的备案、数据库架构、数据库表的范式、并发访问和多线程等）：不好的架构，Code起来吃力、问题又多又不好解决！以个人的经验认为，一般可分为六个阶段
A 用户需求收集、访谈和确认-->B 架构和可行性分析并文档化--> C 开发测试部署和维护详细计划--> D1 单元编码、测试<-->D2 部署测试--> E1 开发环境集成和测试-->E2 真实环境模拟测试-->E3 部署预演-->（原系统备份）-->F 部署

1) 各阶段主要的“产出”（不考虑投入）
A：需求说明书、UI建模、用例和UML图和系统使用帮助文件初稿、系统可能存在的风险报告
B：系统架构图（逻辑图和物理图）、核心算法代码和测试报告、第二方和第三方组件的风险分析报告
C：系统各模块的详细说明书，数据库架构和测试，各功能的开发、CodeRivew和测试计划、部署计划（相当于每日构建）、集成测试计划、系统的升级考虑和方案。注意，尽可能在Code前将数据库可能的问题解决掉！
D：代码、BUG管理、可执行文件、开发环境、测试环境
E：可发布的安装包、最终用户文档、修改之前相关的文档到和现在的系统一致
F：可能的问题预案、安装和不断依实际情况优化，进入维护阶段

2)时间分配：A:B:C:D:E:F=10:10:20:50:5:5，A阶段的时间这里指项目启动时算起，启动前的时间不计在内。

转自：junzhongxu.cnblogs.com

强大的Web开源测试工具—Selenium[4]

Test suite和Test case文件：需要编写的由一个表格组成的html文件；
引擎库js文件：位于selenium根目录下的核心文件，其中html-xpath目录下的那个文件，也是必须的库文件；

user-extensions.js：用来扩展selenium的文件；用户自己编写的函数和扩展的命令都应该放在这个文件中；

这四类文件中，除了引擎库以外，其他三类文件都是可以根据具体情况去修改的。selenium 部署完毕后，可以打开浏览器来通过url来访 问TestRunner.html文件。初始的时候，TestRunner.html文件中的 TestSuite是链接到tests目录下的TestSuite.html文件，TestCase的frame(上部中间)中打开了 TestSuite.html文件中的第一个Test Case “TestOpen.html”。

可以直接修改TestSuite.html文件，让其指向自己开发的Test case html文件。我们也可以建立另外一个目录，然后将自己的TestSuite文件和Test case文件都保存在这个目录中。如果使用后一种方式，那么在打开TestRunner.html的时候需要传递一个参数，例子如下：
http://localhost/selenium/TestRunner.html?test=/testDir/myTestSuite.html

下面就是开发测试用例——即编辑测试用例的表格。无论Test Suite还是Test Case，表格的第一行都是描述性文字，selenium的引擎是不会处理这一行的内容的。实际内容都是从第二行开始的。Test case的表格列数一定不能少于3列，否则Selenium会出错。而基本的三列组成是：
|command| Target| value| 

清单 2就是四个测试用例的例子，将执行以下操作：

通过进入 /change_address_form.html 打开变更地址页面。

在 ID 为 address_field 的文本框中输入 Betelgeuse state prison。

单击名为 Submit 的输入区。注意，这里使用 XPath 找到 Submit 按钮，这导致表单数据被发送到服务器。

验证页面是否包含文本 Address change successful。

清单 2. 在测试用例中使用命令和断言的例子

command

Target

Value


open


/change_address_form.html


type

address_field

Betelgeuse state prison

clickAndWait

//input[@name='Submit']


verifyTextPresent

Address change successful<

测试套件要达到对应用程序的完全测试覆盖，通常需要不止一个测试用例。这就是 Selenium 使用测试套件的原因。测试套件用于将具有类似功能的一些测试用例编成一组，以便让它们按顺序运行。

测试套件和测试用例一样，都是用简单的 HTML 表编写的。Selenium 执行的缺省测试套件的名称是 TestSuite.html。测试套件使用一个只包含一列的表，表中的每一行指向一个包含某个测试用例的文件。

对于一个有着多个功能模块、组件的web应用，编写的测试脚本html必然比较多。因此，应该建立一个合理的目录结构来组织这些脚本，一般按web服务、模块、功能来组织，形成层次性结构。

转自：http://www.cnblogs.com/junzhongxu/archive/2008/07/09/1239077.html

强大的Web开源测试工具—Selenium[3]

第一列包含命令 或断言。

第二列包含命令或断言的目标（target）。可以用多种受支持的组件定位符中的一种来指定目标。通常使用的是组件的 ID 或名称，但 XPath 和 DOM 定位符也是受支持的。

第三列包含用于为命令或断言指定参数的值。例如，当使用 type 命令时，这一列可能就是一个文本域所期望的值。
Test runner 脚本通常与所测试的应用程序（AUT）部署在同一个服务器上。这是因为 browser bot 使用 JavaScript 来模拟用户操作。这些脚本在一个受限制的沙箱环境中运行。如果需要绕过这些限制，可以使用一个代理。

driven 脚本开发模式driven Selenium 脚本是用多种受支持的编程语言(Java, .NET, Perl, Python 和 Ruby)中的一种编写的。这些脚本在浏览器之外的一个单独的进程中运行。驱动程序的任务是执行测试脚本，并通过与运行在浏览器中的 browser bot 进行通信来驱动浏览器。驱动程序与 browser bot 之间的通信使用一种简单的特定于 Selenium 的连接语言 Selenese。

driven 脚本比 test runner 脚本更强大、更灵活，可以将它们与 xUnit 框架集成。driven 脚本编写和部署更复杂些，它必须执行以下任务：

启动服务器。

部署所测试的应用程序（AUT）。

部署测试脚本。

启动浏览器。

发送命令到 browser bot。

验证 browser bot 执行的命令的结果。

driven 脚本更依赖于应用程序运行时环境。例如，Java 驱动程序使用一个嵌入式 Jetty 或 Tomcat 实例来部署所测试的应用程序，如将 Selenium 集成到 Ruby on Rails 中。

开发测试用例测试用例开发涉及四类文件

主文件： TestRunner.html/TestRunner.hta(.hta文件是html application，windows平台特有)；


Test suite和Test case文件：需要编写的由一个表格组成的html文件；
引擎库js文件：位于selenium根目录下的核心文件，其中html-xpath目录下的那个文件，也是必须的库文件；

user-extensions.js：用来扩展selenium的文件；用户自己编写的函数和扩展的命令都应该放在这个文件中；

这四类文件中，除了引擎库以外，其他三类文件都是可以根据具体情况去修改的。selenium 部署完毕后，可以打开浏览器来通过url来访 问TestRunner.html文件。初始的时候，TestRunner.html文件中的 TestSuite是链接到tests目录下的TestSuite.html文件，TestCase的frame(上部中间)中打开了 TestSuite.html文件中的第一个Test Case “TestOpen.html”。

可以直接修改TestSuite.html文件，让其指向自己开发的Test case html文件。我们也可以建立另外一个目录，然后将自己的TestSuite文件和Test case文件都保存在这个目录中。如果使用后一种方式，那么在打开TestRunner.html的时候需要传递一个参数，例子如下：
http://localhost/selenium/TestRunner.html?test=/testDir/myTestSuite.html

下面就是开发测试用例——即编辑测试用例的表格。无论Test Suite还是Test Case，表格的第一行都是描述性文字，selenium的引擎是不会处理这一行的内容的。实际内容都是从第二行开始的。Test case的表格列数一定不能少于3列，否则Selenium会出错。而基本的三列组成是：
|command| Target| value| 

清单 2就是四个测试用例的例子，将执行以下操作：

通过进入 /change_address_form.html 打开变更地址页面。

在 ID 为 address_field 的文本框中输入 Betelgeuse state prison。

单击名为 Submit 的输入区。注意，这里使用 XPath 找到 Submit 按钮，这导致表单数据被发送到服务器。

验证页面是否包含文本 Address change successful。

清单 2. 在测试用例中使用命令和断言的例子

command

Target

Value

转自：http://www.cnblogs.com/junzhongxu/archive/2008/07/09/1239072.html

强大的Web开源测试工具—Selenium[2]

支持的平台


Windows:

Internet Explorer 6.0

Firefox 0.8 to 1.5, Mozilla Suite 1.6+, 1.7+

Seamonkey 1.0, Opera 8

Mac OS X:

Safari 1.3+

Firefox 0.8 to 1.5, Mozilla Suite 1.6+, 1.7+

Seamonkey 1.0, Camino 1.0a1

Linux:

Firefox 0.8 to 1.5, Mozilla Suite 1.6+, 1.7+

Konqueror

部署Selenium

selenium目录下的内容：

devtests：试验性功能 dom-images: 查看DOM用图片

dom-styles: 查看DOM用样式表

html-xpath: Xpath库

jsmock: javascript mock library
jsunit: javascript unit test library

tests: samples(以这个为基础开发测试用例)

核心js文件和html文件

如果想要测试自己开发的发布在服务器端的页面，需要把selenium配置在同一个服务器下：

Apache ：直接将selenium目录拷贝至htdocs（Apache的确省根目录）目录下，然后启动Apache，用地址http://server：8080/selenium/TestRunner.html访问例子。

Tomcat ：直接将selenium目录拷贝至webapps目录下，启动Tomcat，用地址http://server：8080/selenium/TestRunner.html访问例子。：

IIS：建立一个虚拟目录selenium，将该虚拟目录直接指向实际的selenium目录，用地址http://server/selenium/TestRunner.html访问例子Selenium test runner 脚本，就是测试用例（test case），是用 HTML 语言通过一个简单的表布局编写的，即使对于非技术人员来说，test runner 脚本也易于阅读和编写。如 清单 1 所示。

清单 1. Selenium 测试用例的结构 (HTML格式)

Command1/Assertion1

Target1

Value1

Command2 Assertion1

Target2

Value2


test runner 脚本使用与 xUnit 框架相同的测试套件（test suite）和测试用例概念。测试用例和命令按照它们在测试套件和测试用例中出现的顺序依次执行。在 清单 1 中：

转自：http://www.cnblogs.com/junzhongxu/archive/2008/07/09/1239070.html