【转载】如何对软件测试方法分类

　　软件测试方法种类繁多，记忆起来混乱，如果把软件测试方法进行分类，就会清晰很多。我参考一些书籍和网上的资料，把常用的软件测试方法列出来，让大家对软件测试行业有个总体的看法。

　　一、从测试设计方法分类

测试名称	测试内容
Black   box黑盒测试	把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。从软件的行为，而不是内部结构出发来设计测试.
White   box白盒测试	设计者可以看到软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。
Gray box  灰盒测试	介于黑盒和白盒之间

　　总结：实际工作中，对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试，很少有做白盒测试的。因为白盒测试对软件测试人员的要求非常高，需要有很多编程经验。做.NET程序的白盒测试你要能看得懂.NET代码。做JAVA程序的测试，需要你能看懂JAVA的代码。

　　二、从测试是手动还是自动上分类

 

测试名称	测试内容
Manual   Test 手动测试	测试人员用鼠标去手动测试 （测试GUI）
Automation 自动化测试	用程序测试程序 （测试API）

　　对于项目来说，手动测试和自动化测试同等重要，都是保障软件质量的方法。目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化，所以自动化测试无法取代手动测试。对于软件测试人员个人发展来说，做自动化测试是个挑战，也是测试人员发展的一个方向，需要测试人员学习大量的开发知识。从长远角度来看，自动化测试肯定是越来越吃香的。而手动测试比较适合刚工作不久的人，手动测试最大的缺点就是技术含量低，单调乏味，容易使新入行的人感到测试没有前途。总的来说，手工测试胜在测试业务逻辑，而自动化测试胜在测试底层架构。

　　如果被测试的程序可测试性比较好，或者说是被测对象是个研发产品性质的，不是一次性的项目，就很有必要做自动化测试。能做自动化的尽量做成自动化，下面这些情形是可以做自动化的：

　　① 测试存储过程。例如用C#去测试存储过程

　　② 测试Webservies。例如：用SoupUI工具，或者C#，Java去测试Webservies。

　　③ 界面和业务逻辑分离的系统。例如：MVC，MVP架构，或者WPF程序。可以用测试脚本去测试这些程序的API。

　　三、从测试的目的分类

• 　　功能测试

　　　　测试的范围从小到大，从内到外，从程序开发人员（单元测试）到测试人员，到一般用户Alpha/Beta测试

测试名称	测试内容
Unit Test 单元测试	在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员做的)
Functional Test 功能测试	验证模块的功能  （测试人员做的）
Integration Test 集成测试	验证几个互相有依赖关系的模块的功能 （测试人员做的）
Scenario Test  场景测试	验证几个模块是否能完成一个用户场景 （测试人员做的）
System Test  系统测试	对于整个系统功能的测试 （测试人员做的）
Alpha 测试	软件测试人员在真实用户环境中对软件进行全面的测试 （测试人员做的）
Beta 测试	真实的用户在真实的用户环境中进行的测试, 也叫公测   （最终用户做的）

• 　　非功能测试

　　　　一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“Quality of Service requirement”服务质量需求。没有软件的功能，这些特性都无从表现出来，因此，我们要在软件开发的适当阶段（基本功能完成后）做这些测试。

测试名称	测试内容
Stress test   压力测试	验证软件在超过负载设计的情况下仍能返回正确的结果，没有崩溃
Load test   负载测试	测试软件在负载情况下能否正常工作
Performance   test性能测试	测试软件的效能，是否提供满意的服务质量
Accessibility   test	软件辅助功能测试-测试软件是否向残疾用户提供足够的辅助功能
Localization/Globalization	本地化/全球化测试
Compatibility   Test	兼容性测试
Configuration   Test	配置测试-测试软件在各种配置下能否正常工作
Usability   Test	可用性测试 –测试软件是否好用
Security   Test	软件安全性测试

• 　　性能测试

　　　　性能测试要求测试人员熟练性能测试工具，比如Rational Performance Test，LoadRunner，Jmeter。VisualStudio也提供了很多性能测试的工具。要求测试人员对底层协议非常理解和编写脚本能力。性能测试非常有技术含量，很有发展前途，是软件测试人员的一个职业发展方向。

• 　　安全性测试

　　　　安全性测试的内容很广，非常有难度啊。如XSS（跨站脚本攻击）和SQL注入攻击。安全性测试非常有技术含量，也是软件测试人员的一个职业发展方向

　　四、按测试的时机和作用分类

　　在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否畅通。

测试名称	测试内容
Smoke Test	“冒烟”–如果测试不通过，则不能进行下一步工作
Build Verification Test（BVT）	验证构建是否通过基本测试。
Acceptance   Test	验收测试，为了全面考核某功能/特性而做的测试

　　BVT测试是一种Smoke Test，指Build生成好之后，自动运行的自动化测试脚本来检查这个Build的基本功能。如果BVT测试失败了，需要开发人员马上修改，重新生成Build。

　　五、按测试测策略分类

测试名称	测试内容
Regression   Test 回归测试	对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有退化 (regression)
Ad hoc Test   探索性测试	随机进行的，探索性的测试。
Santiy Test	粗略的测试，   只需要执行部分的测试用例

　　Regression Test 回归测试：对软件测试人员来说就是重复测试，所以回归测试最好是自动化的，否则测试人员就要一遍又一遍地重复测试。

　　① 开发人员做些小改动，就需要测试人员做回归测试。确保现有的功能没有被破坏

　　② Bug Fix 也需要回归测试，确保新的代码修复了Fix，也确保现有的功能没有被破坏

　　③ 项目后期，需要做一个完整回归测试，确保所有的功能都是好的。

　　“Ad Hoc” 测试：Ad Hot原意是指 “特定的，一次性的”；就是为了某一个特定目的进行的测试，就这一次，以后一般也不会重复测试或是尝试性测试某种情况，来检测是否有问题，所以并非像许多测试人员所讲的是“猴子测试”，误理解了什么是Ad Hoc Testing；正确的测试应是在测试过程中， “ad hoc” 测试可以用来衡量当前测试用例的完备性，设计某些特定的，一次性的测试用例，去检查在现有测试用例之外的问题，假如测试时，未发现什么问题，说明现有的测试用例是比较完备的，反之，则不是。

　　“Ad-Hoc” 原意是指“特定的，一次性的”，这里专指“随机的，自由的”测试。在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试(Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(Test Case)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regression testing)一起进行。理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。
　　关于Ad-hoc测试的简短问答。

　　问：什么叫“特定”测试？或者“探索式”的测试？
　　答：就是为了某一个特定目的进行的测试，就这一次，以后一般也不会重复测试。在软件工程的实践中，“ad hoc”大部分是指随机进行的，探索性的测试。比如：测试人员阿毛拿到了一个新的Build，按计划是进行模块A的功能测试，但是他灵机一动，想看看另一个功能B做得如何，或者想看看模块A在某种边界条件下会出现什么问题，于是他就“ad hoc”一把，居然在这一功能模块中发现了不少Bug。 “ad hoc”也意味着测试是尝试性的，“我来试试，在这个对话框中一通乱按，然后随意改变窗口大小，看看会出什么问题…”， 如果没问题，那么以后也不会再这么做了。一般情况下，测试人员不会花很多时间进行特定测试，但是在一些缺乏管理的团队中，很多时候测试人员不知道自己此时应该做什么，只好做一些看似“ad hoc” 的测试，比如随机测试各个功能的各个方面。这些测试理论上都应该由测试管理人员规划好属于各个功能模块的测试用例中。 在一个团队中，“ad hoc”太多是一个管理不好的标志，因为“ad hoc”是指那些一时想到要做，但是以后也没有计划经常重复的测试计划。

　　问：我听说有人是“ad hoc”测试的高手，这是什么意思？
　　答：有很多测试人员会按部就班地进行测试，但是还有一些人头脑比较灵活，喜欢另辟蹊径，测试一些一般人不会想到的场景，这些人往往会发现更多的Bug。开发人员对这样的“ad hoc”高手是又爱又恨。

　　问：同时看问题要分两方面，有些“ad hoc”发现的Bug在正常使用软件中几乎不会出现，我们要不要花时间“ad hoc”？
　　答：现在一些成功的通用软件的用户以百万计，按部就班的测试计划很难包括很多实际的场景，这时，“ad hoc”测试能够发现重要的问题；另外一些风险很大的领域，例如安全性，一旦出了问题，威胁就会相当大，这时要多鼓励一些“ad hoc”测试，以弥补普通测试的不足。从这个意义上说，“ad hoc”测试可以用来衡量当前测试用例的完备性，如果你探索了半天，都没有发现什么在现有测试用例之外的问题，那就说明现有的测试用例是比较完备的。 “ad hoc”测试的测试流程是不可重复的，因为它的测试都是“特定”测试，没法重复。由于这一原因，“ad hoc”测试不能自动化，就这一点而言，还达不到CMM的第二级–可重复级。作为管理人员来说，如果太多Bug是在“ad hoc”出来的，那我们就要看看测试计划是否基于实际的场景，开发人员的代码逻辑是否完善，等等。同时，要善于把看似“ad hoc”的测试用例抽象出来，包括到以后的测试计划中。

　　问：做好“ad hoc”测试有什么窍门？ 随机测试有些小窍门，可以帮助测试人员更有效的发现bug。
　　答：窍门一，在发现很多bug的地方，一定可以发现更多的bug。我们在做随机测试的时候，往往会先统计一下，上周哪些模块被发现的bug最多，那么这周一定要狠狠的在那个模块里发掘一下。

　　窍门二，做到知己知彼。知己就是要了解自己在哪些方面有特长，多发挥这些特长；知彼主要是了解两方面，一是程序本身哪些地方最复杂，最薄弱，这些地方最容易发生什么错误，二是程序员最容易在哪些地方犯哪些错误。前者通过对程序的熟悉可以比较好的掌握，后者可以通过CQ(BUG管理工具)分析得到。
　　窍门三，多和程序员沟通。在和程序员沟通的过程中，你可以知道很多你前所未知的东西，你可以通过验证这些东西，来发现未知的bug，并且可以激发你运用更多的测试手段来测试。
【注】Ad Hot 测试内容来自CSDN博客，转载请标明出处：http://blog.csdn.net/wayne_ran/archive/2008/01/08/2030915.aspx

转载于:https://www.cnblogs.com/xiaoTT/p/3900341.html