从测试设计方法分类
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。
）