我们并不是要禁止懂得内部构造的人员来进行黑箱测试设计，只不过我们在设计时有意不考虑软件的内部结构。例如：在测试程序内部基本模块的时候（单元测试），我们通常是要求对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且内部基本模块的“行为”通常没有明确的定义。另一个例子是“可用性测试”，在设计此类测试的时候，我们没必要纠缠于程序的内部结构，而是着重于软件的界面和行为。但是软件可用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和 “白箱”没有简单的高低之分。
一旦测试用例写出来之后，我们大可以忘了它们是从那种颜色的箱子里出来的，用它就可以了。
1.2 功能测试
以下的测试术语都是主要测试软件的功能。在下表所列的测试中，测试的范围有小到大，测试者也由内到外 – 从程序开发人员（单元测试）到 测试人员，到一般用户（Alpha/Beta 测试）。
|
测试名称 |
测试内容 |
|
单元测试 – 在最低的功能/参数上验证程序的正确性 | |
|
Functional Test |
功能测试 – 验证模块的功能 |
|
Integration Test |
集成测试 – 验证几个互相有依赖关系的模块的功能 |
|
Scenario Test |
场景测试 – 验证几个模块是否能够完成一个用户场景 |
|
System Test |
系统测试 – 对于整个系统功能的测试 |
|
Alpha/Beta Test |
外部软件测试人员（Alpha/Beta 测试员）在实际用户环境中对软件进行全面的测试。 |
1.3 非功能测试
一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“non-functional requirement”, 或者“quality of service requirement”- 服务质量需求。没有软件的功能，这些特性都无从表现出来，我们要在软件开发的适当阶段做这些测试。
比如：
|
测试名称 |
测试内容 |
|
Stress/load test |
测试软件在负载情况下能否正常工作 |
|
Performance test |
测试软件的效能 |
|
Accessibility test |
测试软件辅助功能测试 – 测试软件是否向残疾用户提供足够的辅助功能 |
|
Localization/Globalization Test |
本地化/全球化测试 |
|
Compatibility Test |
|
|
Configuration Test |
配置测试 – 测试软件在各种配置下能否正常工作 |
|
Usability Test |
可用性测试 – 测试软件是否好用 |
|
Security Test |
软件安全性测试 |
1.4 Unit Test单元测试
二柱：我们也试过用单元测试来保证质量，要求每人都要写，在签入代码前必须通过单元测试。但是搞了几个星期就不了了之。
大家七嘴八舌的列举了单元测试的问题：
- 有时单元测试报了错，再运行一次就好了，后来大家就不想花时间改错，多运行几次，有一次通过就行了。
- 单元测试中好多错都和环境有关，在别人的机器都运行不成功。
- 花在单元测试上的时间要比写代码的时间还多
- 单元测试中我们还要测试效能和压力，花了很多时间
- 我们都这么费劲地测了，那还要测试人员干什么？
1.4.1 用VSTS写 单元测试
单元测试的基本构成
Setup //设置好环境，准备测试
Test // 测试
Teardown //打扫战场
例子：我们要写一个银行账户的类，那么它的单元测试应该怎么写？
谁自告奋勇上来表演一下写代码？小飞，好请上台。
小飞写了下面的代码：
定义interface IAccount
文章来源于领测软件测试网 https://www.ltesting.net/
