功能测试一般用的方法：1、黑盒测试；2、白盒测试；3、灰盒测试；4、自动化测试；5、手动测试。黑盒测试在完全不考虑程序内部结构和内部特性的情况下，着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
1、黑盒测试
黑盒测试法也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试发现的错误类型：
- 基于规格说明的功能错误
- 基于规格说明的构件或系统行为错误
- 基于规格说明的性能错误
- 面向用户的使用错误
- 黑盒接口错误
黑盒测试特点：
- 对于更大的代码单元来说（子系统甚至系统级）比白盒测试效率要高；
- 测试人员不需要了解软件的实现细节，包括特定的编程语言；
- 从用户的视角进行测试，很容易被理解和接受；
- 有助于暴露任何规格不一致或有歧义的问题；
- 没有清洗和简明的规格，测试用例很难设计；
- 不能控制内部执行路径，会有很多内部程序路径没有被测试到；
- 不能直接针对特定的程序段，这些程序可能非常复杂（因此可能隐藏更多的问题）。
黑盒测试主要内容：
- 接受性测试：黑盒测试是从软件的接口接受测试输出结果，具有接受性测试的特点。
- α/β测试：测试是项目组内的成员对被测软件进行的测试，α/β测试是由项目组外的人员参加的测试。α/β测试也适合于黑盒测试。也就是说，当测试发现错误后在开发人员修改的同时，项目经理也会对产品计划做出相应的调整，产品特征不断地被修改。
- 菜单/帮助测试：在软件测试过程中，开发人员将修复测试人员发现的错误，而且对软件的有些功能进行修改，同时项目经理也将根据情况调整软件的特性，因而在软件开发和测试的过程中，所有的功能都可以进行调整。因此，在软件产品开发的最后阶段，文档里发现的问题往往最多。
- 发行测试：在正式发行前，产品要经过非常仔细的测试。除了专门的测试人员外，还需要几千个甚至几十万其他用户与合作者通过使用来对产品进行测试。然后将错误信息反馈到技术部门到了发行测试时，如果出现非改不可的错误，就必须推迟软件的发行，在推迟时间内需要重新对软件产品进行全面的测试，将耗费大量的时间、人力和物力。
- 回归测试：在此阶段，首先要检查以前找到的错误是否已经更正了。回归测试可使已更正的错误不再重现，并且不会产生新的错误。
- RTM测试：RTM测试是指在产品发行阶段所进行的测试。在这一测试阶段，每一个错误都需要经过高端人员同意才能更正。因为这时候修改软件非常容易产生其他的错误，所以只有那种非修复不可的错误才将允许进行修改。如果在发行阶段软件还有许多严重错误的话，就不能按时发布。
2、白盒测试
白盒测试也称结构测试或逻辑驱动测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例（测试用例由测试输入数据以及与之对应的输出结果组成）。白盒测试使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。
白盒测试的实施步骤：
- 测试计划阶段：根据需求说明书，制定测试进度。
- 测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。
- 测试执行阶段：输入测试用例，得到测试结果。
- 测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。
白盒测试中的六种典型覆盖方法：
- 语句覆盖：作为最基本的逻辑覆盖方法，语句覆盖的含义是：选择足够多的测试数据，使得被测程序中的每个语句至少执行一次。通过语句覆盖，可以直观地从源代码得到测试用例，无须细分每条判定表达式；然而，语句覆盖对程序的逻辑覆盖很少，对于一个包含多个条件的判定表达式，它只关心判定表达式的值，并没有分别测试判定表达式中每个条件取不同值的情况。所以语句覆盖无法全面反映多分支的逻辑运算，是很弱的逻辑覆盖标准。
- 判定覆盖：判定覆盖也称分支覆盖。其含义为：不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次，即每个判定的每个分支都至少执行一次判定覆盖相对于语句覆盖，其逻辑覆盖能力更强。然而判定覆盖也具有和语句覆盖一样的简单性，大部分的判定语句是南多个逻辑条件组合而成，它也仅判断判定表达式的最终结果，而忽略每个条件的取值情况，故在执行过程中必然会遗漏部分测试路径。
- 条件覆盖：条件覆盖的含义是，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。相对于判定覆盖，条件覆盖的覆盖能力更强，因为判定覆盖只关心整个判定表达式的值，而条件覆盖使判定表达式中每个条件都取到了不同的结果。条件覆盖增加了对符合判定情况的测试。然而，要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。因此，条件覆盖只能保证每个条件至少有一次为真，而未考虑所有的判定结果。
- 判定/条件覆盖：由于判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。故提出一种既能满足判定覆盖标准又能满足条件覆盖标准的覆盖方法，即：判定／条件覆盖。其含义是：选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。判定／条件覆盖准则的缺点是未能考虑条件的组合情况。
- 条件组合覆盖：条件组合覆盖是更强的逻辑覆盖标准，其含义是：选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。满足条件组合覆盖准则的测试数据必然满足判定覆盖、条件覆盖和判定／条件覆盖准则。因此，条件组合覆盖是述几种覆盖标准中最强的。然而，条件组合覆盖存在两个不足之处：是线性地增加了测试数据的数量；二是满足条件组合覆盖标准的测试数据不一定能使序中的每条路径都执行到。
- 路径覆盖：路径覆盖要求选取足够多的测试数据，覆盖序中所有可能的路径。其优点是：可以对程序进行彻底的测试，比前述五种的覆盖面都广。然而，由于路径覆盖需要对所有可能的路径进行测试(包括循环、条件组合、分支选择等)，故需要设计大量、复杂的测试用例，使得工作量呈指数级增长。
3、灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
灰盒测试的优点：
- 能够进行基于需求的覆盖测试和基于程序路径覆盖的测试。
- 测试结果可以对应到程序内部路径，便于bug的定位、分析、解决。
- 能够保证设计的黑盒测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组合。
- 能避免需求或设计不详细或不完整对测试造成的影响。
灰盒测试的缺点：
- 投入的时间比黑盒测试大概多20%-40%。
- 对测试人员的要求比黑盒测试高。
- 灰盒测试要求测试人员清楚内部系统结构由哪些模块组成，模块之间如何协作。
- 不如白盒测试深入
- 不是用于简单系统。
4、自动化测试
自动化测试一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
自动化测试的优势：
- 减少重复测试的时间，实现快速回归测试
- 创建优良可靠的测试过程，减少人为错误
- 可以在运行更多更繁琐的测试
- 可以执行一些手工困难或不可能进行的测试
- 更好的利用资源
- 测试具有一致性和重复性
5、手动测试
手动测试是一种软件测试过程，需要手动执行测试用例而不是使用自动化工具。测试人员根据最终用户的角度手动执行所有测试用例。它确保应用程序是否正如需求文档中所述那样工作。计划和实施测试用例以完成几乎100%的软件应用程序。测试用例报告也是手动生成的。
手动测试是最基本的测试过程之一，因为它可以找到软件的可见和隐藏缺陷。由软件给出的预期输出和输出之间的差异被定义为缺陷。开发人员修复了缺陷并将其交给测试人员进行重新测试。在自动化测试之前，每个新开发的软件都必须进行手动测试这项测试需要付出很大的努力和时间，但它确保了无错误的软件。手动测试需要手动测试技术的知识，但不需要任何自动测试工具。
延伸阅读
常见的自动化测试工具有哪些？
- QTP：功能性自动化测试工具，适合BC和CS框架
- selenium：WEB自动化测试工具，BC框架
- Ration Robot：功能性自动化测试工具，CS、BS框架
- jmeter：性能化接口测试工具，CS、BS框架
- appium：APP自动化测试工具，不太常用
- soapui：接口自动化测试工具，也是功能性自动化测试工具
文章标题：功能测试一般用什么方法，发布者：Z, ZLW，转载请注明出处：https://worktile.com/kb/p/48876
微信扫一扫 
支付宝扫一扫 
