测试分为什么，白盒，黑盒，单元，集成测试？

1. 设计测试时的思路问题

白盒、黑盒：是指我们看待所测试对象时的位置，是以“身处其中”（白盒）也即可以知晓其内部运作机制的角度看待并设计和执行测试用例，还是以“置身事外”（黑盒）也即只知道外面可以看见的情况完全不知道内部情况如何的方式看待并设计和执行测试用例。在往年那个生产力匮乏、工具也欠缺的年代，这种说法还很有启发作用，毕竟要去观察和跟踪系统内部运行状态并不那么容易，但在如今这个时代，哪还有什么白盒、黑盒之分？难道你在白盒测试编程语言本身的时候，会深入到编译器内部去观察语言执行情况？或者是检查硬件的数字或脉冲信号？

2. 跟被测对象强相关的测多大东西、测哪个方面的问题

单元测试、系统测试等：是我们所选定的测试对象的范围或规模的不同，单元测试就是关注一个类、一个函数这个级别的表现的测试，系统测试则是关注系统整体的行为。每个公司可能都会有自己的一些测试范围的名词，例如模块测试之类的。

功能、压力、性能等：是我们所测试对象的不同面或者说不同的属性，或者说是被测对象在不同维度所表现出来的不同行为，也可以简称为测试类型。就好像一个人，会不会洗碗（功能）？能够连续洗碗4个小时吗（压力）？最快能够在10分钟内洗几个碗（性能）？

3. 跟整体研发方式强相关的测试时间点问题

集成测试、回归测试等：其实是测试的阶段，也即是说我们在计划一个项目时，按照时间顺序以及自身测试水平和能力所需要的中间过程，并非是必须的，也会因为不同的测试开展方式而有极大的不同。例如，在敏捷方式下开展测试，就没有单独的集成测试和回归测试阶段，可以认为是无时无刻不再进行集成和回归。又例如，在传统方式（例如瀑布）下，由于需求分析和测试用例设计进行方式的原因，集成和回归则会被看作是一种测试类型，以覆盖其他测试类型没有覆盖的部分。

4. 跟整体测试活动相关的生产力问题

测试工具：测试工具这个词本身是很泛（也即很广义）的，简单来讲，就是测试工作中用到的任何工具都可以称之为测试工具。而测试工作又包含了很多活动，例如分析需求、拟订测试计划、设计测试用例、执行测试用例、编写测试报告、提交缺陷等等，这也意味着会有很多种不同用途的测试工具，甚至，可能还有不同厂商打包不同用途的（狭义）测试工具而提供的测试工具包（也被称为测试工具）……

如果你们的需求文档是用Word编写的，那么你可以认为Word是你们的一种需求工具。如果你们用DOORS或其他工具保存，那你可以认为DOORS是你们的需求管理工具。

如果你们用了Lotus Notes或者QC等来管理你们的测试计划和测试用例，那么你可以认为它们是测试管理工具。

如果你使用了Jira或Bugzilla等来管理你们的缺陷，那么你可以认为它们是你们的缺陷追踪系统。

如果你们用了Redmine、VersionOne等敏捷项目管理工具来管理你们的测试工作任务，那么你可以认为它们也是你们的项目管理工具。

如果你们使用了Robotframework、Watir、Robotium、LoadRunner等各种工具来编写自动化测试用例和执行，那么你可以认为它们就是你们的测试自动化工具。