软件测试方法是指测试软件的方法。随着软件测试技术的不断发展，测试方法也越来越多样化，针对性更强；选择合适的软件测试方法可以让我们事半功倍。本文主要介绍的是软件测试方法和规范，跟随小编一起来了解一下具体的测试流程及规范吧。
测试代码和项目开发代码应该利用配置管理工具（如SVN）分开管理。测试代码编写完成后，存放在配置库中。开发过程中，可根据需要对自己编写代码进行测试。
并且测试环境和开发环境应分隔开来，以免相互影响，便于缺陷的复现和定位，在条件允许的情况下，性能测试环境应和功能测试环境分开，以免在性能测试过程中对功能测试造成影响。
1、测试阶段所基于的文档（包括但不限于）
测试规范形成的前提是需要有有章可循的依据，这些依据需要基于标准的项目文档，常见的文档包括下面几种：
1.1、软件需求规格说明书
软件需求说明书是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个项目组开展工作的基础。包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等等。
软件需求说明书的作用在于便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据，并作为确认测试和验收的依据。
1.2、软件设计说明（概要设计或详细设计）
软件设计又划分为概要设计和详细设计。概要设计是在用户提出的需求和软件的设计实现之间架起桥梁，是将用户提出的目标和需求转换成具体界面设计解诀方案的重要阶段。概设的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机交互的界面等。从而设计建立一个目标系统的逻辑模型。
而详细设计是软件工程中软件开发的一个步骤，就是对概要设计的一个细化，就是详细设计每个模块实现算法，所需的局部结构。在详细设计阶段，主要是通过需求分析的结果，设计出满足用户需求的软件系统产品。软件设计说明对测试工作开展有很大影响，没有软件设计说明很多问题将无法溯源，测试准备的前期工作也是根据软件设计说明来制定的。
1.3、软件设计原型（demo）
页面原型是项目人员快速熟悉项目的最佳路径，让开发人员和测试人员更直观的了解客户的需求和产品的实现方式、业务逻辑，帮助项目人员更快的理解用户需求、业务逻辑，用更直观，具体的界面化方式来说明用户想要如何来实现他们需要的功能。或者在需求不够明确，设计说明书不够全面的情况下，页面原型也是后期测试用例编写思想的重要根据。
1.4、接口文档
当项目中各个子系统间、各个功能模块间有交互，需要开发接口时，接口文档会定义出参数传递、参数返回的规则，比如：参数的名称、参数的类型、长度、是否必填、各个返回码所代表的含义。。，当项目中有接口测试需求的时候，此文档是很重要的测试依据。
1、测试的策略：
（1）静态测试：不测试程序本身，而直接寻找程序中可能存在的缺陷或评估代码品质的行为。主要是在单元测试行为中，对技术、设计文件进行评核，程序无法执行或需要对原始程序进行规范符合性检查时该使用这种策略。
（2）动态测试：运作被测程序，输入测试资料，检查运作结果与预期结果的差异，从而判断系统中是否存在缺陷的过程。
2、动态测试的测试技术：
（1）黑箱测试：测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能性说明的测试方法。主要是在系统测试阶段时采用。
（2）白箱测试：使用被测程序内部如何工作的资讯，允许测试人员对程序内部逻辑结构及有关资讯来设计和选择测试案例，对程序的逻辑路径进行测试。其测试基于覆盖全部代码、分枝、路径、条件。
（3）灰箱测试：基于被测试程序逻辑结构的基础上，从系统功能接口上设计测试案例。通常是作为黑箱测试的补充或在黑箱发现缺陷以后，回到原始代码分析原因确认问题时采用。
3、测试的阶段：
（1）单元测试：为最小单位的测试。在单元测试行为中，各独立单元模块在与系统其他模块隔离的情况下进行测试，检查每个程序模块是否实现了规定的功能。
（2）整合测试：是在单元测试的基础上将已经通过测试的单元模块按照设计要求组装成系统或子系统进行测试的活动。测试着重在各模块、各子系统之间界面上的缺陷。
（3）系统测试：透过整合测试的软件，同其运作环境、资料和使用者结合在一起，在实际或模拟实际环境下，对系统进行全面的测试。目的在于通过与系统需求规格书进行比较，发现软件与系统定义不符合的地方。
（4）验收测试：为最后一个测试行为。它是以使用者为主的测试，由使用者设计测试案例，使用实际资料进行测试。
4、测试的方法：
（1）功能测试：检查软件的功能是否符合规格说明书上的需求。
（2）性能测试：检察系统是否实现了规定的性能指标要求。
5、测试的实施组织划分：
（1）开发者测试（α测试）：开发者透过检测和提供客观证据，证实软件的实现是否满足规定的需求。主要是在系统交付给第三方测试或验收测试之前进行的活动。
（2）使用者测试（β测试）：在使用者的应用环境下，透过使用检测软件来验证是否符合自己预期的需求。
（3）第三方测试（外包测试）：软件发展方和使用者方之间的测试团队进行的测试行为。
6、测试的其他概念：
（1）人工测试：由测试人员来执行测试案例，然后根据实际的结果和预期的结果进行比较，并记录测试结果。
（2）自动化测试：透过回放录制或编写的自动化脚本，驱动系统运行的测试行为。
（3）回归测试：软件在修改以后再次运作之前，为寻找错误而执行程序曾用过的测试案例，以测试缺陷是否再次出现的行为。
（4）冒烟测试：软件版本交付后，对其重要的部分先进行大概的测试，检查主要功能是否正确，再进行后面的测试。
1、边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。
2、非法测试，例如在输入数字的地方输入字母。
3、跟踪测试，跟踪一条数据的流程，保证数据的正确性。
4、在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。
5、接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。
6、代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。
7、突发事件测试，服务器上可能发生意外情况的测试。
8、外界环境测试，有些系统在开发时依赖于另外一个系统，当另外一个系统发生错误时， 这个系统所受到的影响的情况。
9、缺陷验证：在程序员刚修复Bug之后的地方，一定要在次验证、测试，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。
10、做好BUG管理工作，认真做好测试记录，在做完一天的测试记录之后，第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。
11、错字、错词测试，如果在系统中有用词不当的地方，我想这是不应该的。
12、系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。
13、用户的易用性测试，往往用户的需求是不断的变化的，而其中一部份变化的原因，是由用户操作上不方便引起的。
转载于:https://www.cnblogs.com/zgq123456/p/10082622.html
