僅樓主可見

今年测试工具或者测试框架都不火。

@xingxiu

30 够用了吧，不是说 60，就一直运行在 60 的？

我理解为补位，而不是抢……要不然球场上没法踢球了。

做的越来越不错了

嗯，总体挺不错的。给社区的同学们多一个选择。

现在有很多福利待遇都很好的远程工作机会的。你这个五金都不交，估计很难找到愿意长久的人。

除了时间自由外，其他的吸引力几乎没有呀。

1. 接口自动化测试平台足够好，这个很难，100% 的覆盖率，也不能保证用户数据 100% 覆盖，只是保证了 code statement 或者 code line 覆盖率
2. diff 平台足够好的化，理论上是可以吃掉接口自动化。

def load_dot_env_file(dot_env_path: Text) -> Dict:
    """ load .env file.

    Args:
        dot_env_path (str): .env file path

    Returns:
        dict: environment variables mapping

            {
                "UserName": "debugtalk",
                "Password": "123456",
                "PROJECT_KEY": "ABCDEFGH"
            }

    Raises:
        exceptions.FileFormatError: If .env file format is invalid.

    """
    if not os.path.isfile(dot_env_path):
        return {}

    logger.info(f"Loading environment variables from {dot_env_path}")
    env_variables_mapping = {}

    with open(dot_env_path, mode="rb") as fp:
        for line in fp:
            # maxsplit=1
            if b"=" in line:
                variable, value = line.split(b"=", 1)
            elif b":" in line:
                variable, value = line.split(b":", 1)
            else:
                raise exceptions.FileFormatError(".env format error")

            env_variables_mapping[
                variable.strip().decode("utf-8")
            ] = value.strip().decode("utf-8")

    utils.set_os_environ(env_variables_mapping)
    return env_variables_mapping

这个方法现在用不了了？

以前在谷歌做外包就是零食吃多了。。。胖的不可收拾。

分享下有赞的几篇文章：

1. https://testerhome.com/topics/18751 有赞前端质量保障体系
2. https://www.cnblogs.com/finer/p/11895063.html

我们前端的 bug 一直是居高不下的

就是我说的 ron patton

楼主，你可以开个专栏啊

匿名版不适用……

ron patton 软件测试

二、指标

1、QPS（Queries Per Second）

概念：服务器每秒处理查询次数，是一台服务器每秒能够处理的查询次数。用户发起查询请求到服务器做出响应这算一次，一秒内用户完成了 50 次查询请求，那此时服务器 QPS 就是 50。

2、TPS（Transactions Per Second）

概念：服务器每秒处理的事务数，一个事物是用户发起查询请求到服务器做出响应这算一次。纳尼？这难道不是 QPS 的概念吗？划重点，这里就要说清楚一个概念了，在针对单接口，TPS 可以认为是等价于 QPS 的，如访问 ‘order.html’ 这个页面而言,是一个 TPS。而访问 ‘order.html’ 页面可能请求了 3 此服务器（如调用了 css、js、order 接口），这实际就算产生了三个 QPS

所以，总结下就是，在针对单接口的时候 TPS = QPS ,否则 QPS 就要看实际的请求次数了。

2、RT（Res（onse Time）

概念：响应实际，就是从客户端请求发起到服务器响应结果的时间。RT 这个参数是系统最重要的指标之一，它的大小直接反应了当前系统的响应状态。基本和咱们用户体验息息相关，现在好一点监控系统一般都有三个 RT，即平均、最大、最小。

一般系统 RT 100ms 以内是比较正常的，300ms 勉强可以接受，1s 的话再加上一些其他的外因，给用户的体验就是实实在在的不爽了。

3、并发数

概念：系统能同时处理的请求的数量，很多人经常会把并发数和 TPS 理解混淆。举例，请求一个 index.html 页面，客户端发起了三个请求（css、js、index 接口）,那么此时 TPS =1 、QPS =3 、并发数 3。

SO，计算公式 ：QPS=并发数/RT || 并发数=QPS*RT

4、吞吐量（Throughput）

概念：每秒承受的用户访问量，吞吐量（系统能承受多少压力）和当前请求对 CPU 消耗、内存、IO 使用等等紧密相关。单个请求消耗越高，系统吞吐量越低，反之越高。

一个系统的吞吐量和其 TPS 、QPS、并发数息息相关，每个系统针对这些值都有一个相对极限值，只要其中某一个达到最大，系统的吞吐量也就到达极限了。如此时压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，各种资源切换等等的消耗导致系统性能下降。

关系：

所以，理解上面几个关系后，就可以推算出：

QPS（TPS）= 并发数/平均响应时间

5、PV（Page View）

概念：即每个页面的浏览次数，用户每次刷新就算一次。

6、UV（Unique Visitor）

概念：独立访客数，每天访问的用户数，此数据需要根据用户唯一标识进行去重。

7、Load（系统负载）

概念：此数据指的是 Linux 系统的负载情况，也就是咱们平时所用 Top 命令时，最上面显示的数据信息 ( load average: 0.1, 0.2, 0.5)。此时会显示 1 分钟、5 分钟、15 分钟的系统平均 Load，很显然 load average 的值越低，你的系统负荷越小。

简单的说下这个值应该怎么看，如果你是单核 cpu,那此值为 1 的时候就是系统已经满负荷状态了，需要你马上去解决。但实际经验告诉我们，当系统负荷持续大于 0.7 的时候（也就是 70%），就需要你马上来解决问题了，防止进一步恶化。

为什么需要三个值 load average: 0.1, 0.2, 0.5，其实就是给你个参考。比如只有 1 分钟的是 1，其他俩都是 0.1，这表明只是临时突发的现象，问题不大。如果 15 分钟内，系统负荷都是 1 或大于 1，那表明问题持续存在啊。所以你应该主要观察 15 分钟的系统负荷。

最近一直被 ddos，不知道一个小测试网站为啥总被 ddos。

还真的没有

走树莓派路线应该可以