模板
教程
环境
性能
功能
管理
软件测试和VSTS 测试工具
1.1 从 测试 设计的方法分类 从测试设计的方法来看，我们知道有两类方法： Black box ( 黑箱 ) White box ( 白箱 ) 这是每个接触过 软件测试 的人都会给出的答案。但是这只是整个软件测试的入门。我们可以跳过去，直接讨论下面的内容。。。 问：我在网上看到
1.1 从测试设计的方法分类
从测试设计的方法来看，我们知道有两类方法：
Black box (黑箱)
White box (白箱)
这是每个接触过软件测试的人都会给出的答案。但是这只是整个软件测试的入门。我们可以跳过去，直接讨论下面的内容。。。
问：我在网上看到有人争论黑箱测试和白箱测试哪一个是另一个的基础，还有那一个更难，那一个更有前途，等等。据说李村数码在搞“灰箱测试”，是不是更高级？能不能简单讲一讲？
阿超：大家都有这些问题么？
杂曰：[略去对此问题热烈的争论500字]
阿超：听了大家的争论，看来我们的确得花不少时间统一认识.
第一个要注意的问题是，所谓黑箱/白箱，是软件测试设计的方法，不是软件测试的方法！注意“设计”二字。
黑箱：在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral Test Design”,从软件的行为，而不是内部结构出发来设计测试。
白箱：在设计测试的过程中，设计者可以“看到”软件系统的的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。
在实际工作中，我们不应画地为牢，严格只用某一种方法来设计测试方法。在实际的测试中，当然是对系统了解的越多越好。所谓“灰箱”的提法，正是这一反映。有些人甚至希望我们全部忘记“箱子”和它们的颜色。
我们并不是要禁止懂得内部构造的人员来进行黑箱测试设计，只不过我们在设计时有意不考虑软件的内部结构。例如：在测试程序内部基本模块的时候（单元测试），我们通常是要求对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且内部基本模块的“行为”通常没有明确的定义。另一个例子是“可用性测试”，在设计此类测试的时候，我们没必要纠缠于程序的内部结构，而是着重于软件的界面和行为。但是软件可用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和“白箱”没有简单的高低之分。
一旦测试用例写出来之后，我们大可以忘了它们是从那种颜色的箱子里出来的，用它就可以了。
1.2 功能测试
以下的测试术语都是主要测试软件的功能。在下表所列的测试中，测试的范围有小到大，测试者也由内到外–从程序开发人员（单元测试）到测试人员，到一般用户（Alpha/Beta测试）。
|
测试名称 |
测试内容 |
|
单元测试–在最低的功能/参数上验证程序的正确性 | |
|
Functional Test |
功能测试–验证模块的功能 |
|
Integration Test |
集成测试–验证几个互相有依赖关系的模块的功能 |
|
Scenario Test |
场景测试–验证几个模块是否能够完成一个用户场景 |
|
System Test |
系统测试–对于整个系统功能的测试 |
|
Alpha/Beta Test |
外部软件测试人员（Alpha/Beta测试员）在实际用户环境中对软件进行全面的测试。 |
|
|
|
|
|
|
|
|
|
