一些自动化测试的自我理解

目录

前言:

自动化用例和普通测试用例

自动化断言和普通断言

自动化测试用例的颗粒度

自动化的环境问题

自动化的维护成本

---

前言:

自动化测试是一种使用计算机程序来验证和验证软件的过程。它可以帮助软件开发人员更快更准确地测试软件，特别是在需要重复执行测试的情况下，如测试一个应用程序的不同版本或对其进行定期更新时。自动化测试的目标是提高测试的效率和准确性，并确保软件的质量。

自动化用例和普通测试用例

自动化测试因为需要给到机器去测试，所以在用例变更时，不仅要定义用例步骤，还要对应完成用例实现。所以一个常常改变的系统不应该为此编写自动化用例。

自动化断言和普通断言

如上面所述，断言也是需要我们编写的，当然借助现有的一些框架，我们可以避免很多的编写。第二个我要说的是，如果你从事过 UI、AI 方面的测试工作，你会发现在反复执行的过程中你会发现某一次会出现一些返回的偏差，这一偏差是由被测对象决定的。设备会在某种环境下，渲染失败或者是异常，而 AI 本身就是一个概率的模型，结果本身就是随机的。所以我们需要编写复杂断言来处理这类问题吗？答案是否定的，我们应该先人工测试保证被测对象的稳定性。甚至我们对于这些用例回到手工测试。

自动化测试用例的颗粒度

在自动化测试中，被测对象和测试环境都是影响自动化测试稳定性的因素。所以针对这两者，我们可以控制用例的颗粒度来降低我们的维护成本。
假设有这样的一个接口，支持门店名称 (name) 和业务员手机号 (phone) 的模糊查询，接口响应数据如下:

{
  "code":200,
  "data":[
      {"id":1,"name":"121","sale_info":{"phone":135}},
      {"id":2,"name":"12","sale_info":{"phone":1351}},
      {"id":3,"name":"2","sale_info":{"phone":0135}},
      {"id":4,"name":"002","sale_info":{"phone":01351}},
  ],
  "msg": null
}

测试用例如下,我们针对不同的元数据进行了断言，分别是门店和门店的相关信息。

import unittest
def get_value_by_jsonpath(value,path):
    """通过jsonpath获取数据"""

def get_api():
    """请求接口"""

class TestStoreList(unittest.TestCase):
    def setUp(self):
        pass

    def template(self,diff_param:dict,jsonpath="$."):
        url = ''
        body = {"name":"","phone":""}
        body.update(diff_param)
        resp = get_api(url,json=body)
        assert 200 == resp.status_code
        if '$.' == jsonpath:
            return resp.json()
        return get_value_by_jsonpath(resp.json(),jsonpath)

    def sql_select(self,sql):
        """数据库查询"""

    def test_name_like(self):
        """断言门店数据"""
        names = self.template({"name":"2"},'$.data.*.name')
        sql = ""
        select_names = self.sql_select(sql)
        assert names == select_names

    def test_phone_like(self):
        """断言门店关联业务员数据"""
        phones = self.template({"phone":135},'$.data.*.phone')
        sql = ""
        select_phones = self.sql_select(sql)
        assert phones == select_phones

    def teardown(self):
        pass

下一个版本中，业务员和门店从一对一变为一对多的情况我们只需修改门店相关的用例即可。

自动化的环境问题

被测环境如何保证数据稳定性，这一问题其实是测试用例的问题，只不过在手工测试中，我们主动避障了，造不了 A 数据，我们去造 B 数据了。在自动化测试中，由于程序没有我们人那么智能，所以这个问题十分明显。但是这一问题往往是运维的问题，不过我们可以假设我们拥有一个和线上数据库结构一致的数据库，里面没有数据。我们通过 setUp 和 teardown 保证不同用例间互不干扰、和可重复执行，而 setUpClass 和 tearDownClass 则是用于我们有一个基础数据来保证环境已经满足一定的前提条件，全部用例完成后保证环境如测试前一致，它们还是保证我们的用例互不干扰，只是维度更高。

import unittest

class TestStoreList(unittest.TestCase):

    @classmethod
    def setUpClass(cls):
        """增加一些基础数据"""

    @classmethod
    def tearDownClass(cls):
        """清理新增的基础数据,还原环境"""

    def setUp(self):
        """不同用例去新增不同的测试数据"""

    def test_name_like(self):
        """断言门店数据"""

    def test_phone_like(self):
        """断言门店关联业务员数据"""

    def teardown(self):
        """不同用例去清理不同的测试数据，还原环境"""

上面的讨论，需要一些运维技巧，包括如何部署数据库、中间件、服务器、等等的一些东西。如果系统架构过于复杂、硬件资源紧张、运维能力不足，可能我们不能奢望我们拥有一个可控的环境。你大概只能编写更加复杂断言来保证你健壮，维护成本会响应提高。

自动化的维护成本

从上面的讲述中，我们的维护成中由维护环境和维护用例组成，在用例维护中，用例逻辑维护和数据维护，是相互影响的 (请不要将测试步骤和测试数据分离当成是测试数据和用例分离，在自动化测试用例中测试数据和用例是一起的) 。我们应该更加倾向于低逻辑维护、高数据维护的这样一种模式。高逻辑会带来一些逻辑错误，从而导致我们使用 bug 来测试 bug。而我们可以用过 execl，数据库，造数平台来提高我们维护数据的效率。

  作为一位过来人也是希望大家少走一些弯路

在这里我给大家分享一些自动化测试前进之路的必须品，希望能对你带来帮助。

（软件测试相关资料，自动化测试相关资料，技术问题答疑等等）

相信能使你更好的进步！

点击下方小卡片

【自动化测试交流】：574737577（备注ccc）http://qm.qq.com/cgi-bin/qm/qr?_wv=1027&k=OetrT9f88edRYNIQKFJOmrs6RHyWXP3y&authKey=bgPQfqmHo0NrA1BoVHRRETiUqnaJESQZRv5yxL9Ab4YfabTZAQ481HuPpZ6kA%2Ftd&noverify=0&group_code=574737577