【测试理论】-测试方法详述
从测试设计方法分类
Black box 黑盒测试、White box 白盒测试、Gray box 灰盒测试
目前大多数的测试人员都是做黑盒测试，很少有做白盒测试的。 因为白盒测试对软件测试人员的要求非常高，需要有很多编程经验。比如，做JAVA程序的白盒测试，需要你能看懂JAVA的代码。 不过如果你都能看懂了，你还会做测试么
从测试是手工还是自动化上分类
Manual Test 手动测试
Automation 自动化测试
用程序测试程序 （测试API）
对于项目来说， 手动测试和自动化测试同等重要，都是保障软件质量的方法。
目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化，所以自动化测试无法取代手动测试。
而手动测试比较适合刚工作不久的人，手动测试最大的缺点就是技术含量低，单调乏味，容易废人。
自动化测试绝对会越来越吃香，但需要测试人员学习大量的开发知识（其实是一件好事）。
从测试的目的分类
功能测试
Unit Test 单元测试—开发人员做的
在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性
Functional Test 功能测试
验证模块的功能
Integration Test 集成测试
验证几个互相有依赖关系的模块的功能
Scenario Test 场景测试
验证几个模块是否能完成一个用户场景
System Test 系统测试
对于整个系统功能的测试
Alpha 测试
软件测试人员在真实用户环境中对软件进行全面的测试
Beta 测试—最终用户做的
真实的用户在真实的用户环境中进行的测试, 也叫公测
非功能测试
Stress test压力测试
验证软件在超过负载设计的情况下仍能返回正确的结果，没有崩溃
Load test负载测试
测试软件在负载情况下能否正常工作
Perfprmance test性能测试
测试软件的效能，是否提供满意的服务质量。
Accessibility test软件辅助功能测试–残疾用户
Localization/globalization 本地化/全球化测试、Compatibility test兼容测试
Configuration test配置测试
测试软件在各种配置下能否正常工作
Usability test 可用性测试、Security test 安全性测试
按测试的时机和作用分类
在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否畅通。
Smoke test冒烟测试
“冒烟”–如果测试不通过，则不能进行下一步工作
Build verification test(BVT)
BVT测试是一种Smoke Test, 指Build生成好之后，自动运行的自动化测试脚本来检查这个Build的基本功能。 如果BVT测试失败了，需要开发人员马上修改，重新生成Build
Acceptance test 验收测试
验收测试，为了全面考核某功能/特性而做的测试
按测试策略分类
Regression test回归测试
对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有退化。
Ad hoc test 探索性测试
Sanity test粗略的回归测试
回归覆盖面大，却并不深入，不探究较复杂的功能错误，主要在于使用层面的完整上，验证系统是否满足规格说明。
总结：
1.作为一个测试，业务熟悉程度相当的重要。
2.大部分的测试工作为：
黑盒测试+手工测试+系统测试+Alpha测试（+探索性测试）+回归测试。
这个程度,门槛低、技术含量低、单调乏味，能力辨别高低主要靠业务熟悉程度、逻辑思维能力。
更细的说，还需要有 沟通能力（面对面+文字）、细心、耐心、系统思维等能力。
3.想往高处走的话：
自动化测试，自动化测试胜在测试底层架构，需要测试人员学习大量的开发知识（我想走这个方向，其实就是最好有有点开发背景）。
性能测试，要求测试人员熟练性能测试工具，比如QTP、LoadRunner、Jmeter 等工具。（Visual Studio也提供了很多性能测试的工具. 要求测试人员对低层协议非常理解和编写脚本）
安全测试，非常有技术含量，并且内容广。 比如跨站脚本攻击、SQL注入攻击 等。
（
另外，说一下回归测试和探索性测试。
回归测试最好是自动化的，否则测试人员就要一遍又一遍地重复测试。
以下情况需要做回归测试：
1. 开发人员做些小改动，就需要测试人员做回归测试。确保现有的功能没有被破坏
2. Bug Fix 也需要回归测试，确保新的代码修复了Fix, 也确保现有的功能没有被破坏
3. 项目后期，需要做一个完整回归测试， 确保所有的功能都是好的
探索性测试，就是抛开测试用例，按照自己的思路，随便点点。
在测试GUI的时候，探索性测试往往能发现大量的bug。
）