测试方法及常用测试工具介绍

测试方法介绍

冒烟测试：冒烟测试（Smoke Testing）的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。

                  冒烟测试的执行者是版本编译人员（或开发测试协同）。

                  进行冒烟测试之前需要确定冒烟测试的用例集，对用例集要求覆盖软件的基本功能（即准入用例，全部P1级+部分P2级用例）。

功能测试：Functional testing（功能测试），也称为 behavioral testing（行为测试），根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。

                  冒烟测试的执行者是测试人员。

                  功能测试需要执行全部测试用例，并随时补充完善测试用例库。

回归测试：回归测试（Regression Testing）是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

                  回归测试的执行者是测试人员。

                  回归测试的方式包括：再测试全部用例、基于风险选择测试、基于操作剖面选择测试、再测试修改的部分。

项目中最常用的测试方法就是回归验证，每次项目发布前都要进行不同程度的回归测试，那么怎么把控任务执行力度，可以从以下几点入手：

测试回归：一轮回归测试环境主功能，确保bug修复后的版本能正常运行；

                   二轮回归预发布环境（较稳定版环境，一般预发布环境等同于线上环境）；

                   三轮回归生产环境，确保发布的内容对主功能没有影响。

回归用例是各个级别用例中重复使用最高的用例，当项目逐步成熟后，可以考虑加入自动化辅助回归测试，通常有以下几个方向：

看日志：监控日志平台，严格定义error级别，完善报警机制；

代码覆盖率：例如：现在的主流的框架JaCoCo，每次测试后可以查看代码逻辑是否覆盖完整，可以避免漏测；

Case自动化：现在主流的web自动化Unnitest+Python，轻量级的可以借助工具实现：Jmeter,Postman,httprunner。

现在回归测试基本涉及两种：全面回归测试、选择性回归测试

(1)全面回归测试

全面回归测试是指不管发现多少个问题，也不管哪些功能有问题，哪些功能没有问题，都进行测试。全面回归测试的优点是对所有功能进行验证，尽最大可能保证系统没有问题，但是这样同样带来一个很重要的问题，就是如果进行全面回归测试，那么测试的成本就会大大提高，并且从测试心理学角度来说，测试工程师是不可能全面回归测试的，即使给你足够的测试时间，也不可能全面回归。前面我们谈到测试心理学，关于测试心态的两种情况，在我们回归测试时，随着测试的不断迭代，我们测试的心理会发生变化，后面测试时我们更多的是这种心态：“测试是为了证明系统不存在问题。”这就决定着我们不可能对所有测试用例进行验证，很可能是只挑选了一部分用例进行验证测试。

(2)选择性回归测试

选择性回归测试是指，在回归测试时我们只对出现问题的这些功能进行验证，没有出现问题的功能就不进行测试。例如，一个系统一共有20 个功能点，第一轮测试时，发现10 个BUG，这10个BUG 是测试其中8 个功能点发现的，那么选择性回归测试就只对这8 个功能进行回归测试。但这样存在一个问题，在修改某个BUG 时，如果修改了A 函数，而这个A 函数又被其他的功能所调用(假设是F1 功能，这个F1 功能在上一轮测试中是正确的)，这个时候就不能仅仅验证存在问题的8 个功能，还应该验证F1 功能是否正确，即除了验证这些BUG 外，还要关注那些可能影响到的模块。但是这里又存在一个问题，测试工程师如何知道哪些功能可能会受到影响呢?所以这就需要开发工程师在修复BUG 时写清楚，当前这个BUG 是由什么原因引起的，这个问题是如何修改的以及可能产生的影响，所以选择性回归测试除了需要验证当前的问题外，还要验证修改的这些问题可能对其他功能带来的影响。

 

测试方法是依据项目质量标准制定，前期提供的文档和规范越完善，质量把控就会越严谨（当然具体情况具体分析，任何事情都考虑投入产出比）