软件測试方法
软件測试方法种类繁多，从不同的角度上去划分，能够划分为下面经常用法：
一、软件測试分类
以下我本文主要谈论的是白盒測试、黑盒測试盒和灰盒測试。
二、软件測试定义
白盒測试：在測试类书籍中，白盒測试有多种称法，如玻璃盒測试。透明盒測试，开放盒測试，结构化測试，基于代码的測试，逻辑驱动測试等。白盒測试是一种測试用例设计方法。在这里盒子指的是被測试的软件，白盒。顾名思义即盒子是可视的，你能够清楚盒子内部的东西以及里面是怎样运作的，因此白盒測试须要你对系统内部的结构和工作原理有一个清楚的了解，而且基于这个知识来设计你的用例。
黑盒測试：又叫功能測试。这是由于在黑盒測试中，主要关注于被測软件的功能实现，而不是内部逻辑。
黑盒測试发现下面类型的错误：
1）功能错误或遗漏
2）界面错误
3）数据结构或外部数据库訪问错误
4）性能错误
5）初始化和终止错误。
灰盒測试：介于白盒和灰盒之间的測试。最常见的灰盒測试时集成測试。
（1）白盒測试和黑盒測试的优缺点比較：
| 比較 | 长处 | 缺点 |
| 白盒測试 |
迫使測试人员细致的思考软件的实现。 能够检測代码中的每条分支和路径。 揭示隐藏在代码中的错误。 对代码的測试比較彻底。 最优化。 |
昂贵。 无法測试代码中遗漏的路径和数据敏感性错误。 不验证规格的正确性。 |
| 黑盒測试 |
測试效率高。 測试人员不须要了解具体的细节。包含特定的编程语言。 測试人员和编码人员是彼此独立的。 从用户的视角进行測试，非常easy被大家理解和接受。 有助于暴露不论什么规格不一致或有歧义的问题。 測试用例能够在规格完毕之后立即进行。 |
仅仅有一小部分可能的输入被測试到，要測试每一个可能的数据流差点儿是不可能的。 没有清晰和简明的规格，測试用例是非常难设计的。 怎样測试人员不被告知开发者已经运行过的用例，在測试数据上会存在不必要的反复。 会有非常多程序路径没有被測试到。 不能直接针对特定的程序段，这些程序可能很复杂（因此可能隐藏很多其它的问题）。 |
通过白盒測试与黑盒測试的比較。能够看出，白盒和黑盒这两类測试的出发点是不同的：
白盒測试考虑的是測试软件的代码，它不保证完整的需求规格是否被满足。
而黑盒測试仅仅考虑需求规格。它不保证实现的全部部分是否被測试到。黑盒測试会发现遗漏的缺陷。指出规格的部分没有被完毕。
（2）黑盒和白盒測试的经常使用技术
黑盒和白盒測试的经常使用技术，參考以下的图中内容。
三、參考资料：
我推荐2篇博客：个人看来后认为人家总结的更专业，更好，值得我去学习。在这里分享给大家。
软件測试方法大汇总——小坦克：http://www.cnblogs.com/TankXiao/archive/2012/02/20/2347016.html#undefined
软件測试方法汇总：http://www.360doc.com/content/11/0613/14/54470_126627944.shtml