easy mock 了解一下

一般不会把测试报告放邮件里面吧
一般都是把报告放 Web 服务器上，然后邮件里面就发 测试结果概要 和 报告 url 地址就好了

还是觉得 JMeter 比较好，并发这些可以到很高
Locust 优点就是写用例很方便
如果能把两者的优点结合起来就好了，Python 生成 jmx 脚本，然后 JMeter 去 Run..

"""
2018-05-14 Created by arrow.
文件 A + 文件 B -> 排序的文件C
ref: https://testerhome.com/topics/12900
"""
import os
from collections import OrderedDict

BASE_DIR = 'd:\\practice\\'
FILE_A = 'file_a.txt'
FILE_B = 'file_b.txt'
RESULT = 'result.txt'

# 用 顺序字典 来存放26个文件句柄
HANDLER = OrderedDict()

for letter in range(97, 123):
    HANDLER[chr(letter)] = open(os.path.join(BASE_DIR, chr(letter) + '.txt'), 'w', encoding='utf-8')

for file in [FILE_A, FILE_B]:
    with open(os.path.join(BASE_DIR, FILE_A), encoding='utf-8') as fs:
        while True:
            content = fs.read(1)
            letter = content.lower()
            if not content or letter not in HANDLER:  # 排除异常字符
                break
            HANDLER[letter].write(content)

# 关闭文件流
for k, v in HANDLER.items():
    v.close()

# 读取26个文件
for letter in range(97, 123):
    HANDLER[chr(letter)] = open(os.path.join(BASE_DIR, chr(letter) + '.txt'), encoding='utf-8')

# 合并26个文件
with open(os.path.join(BASE_DIR, RESULT), 'w', encoding='utf-8') as fs:
    for k, v in HANDLER.items():
        while True:
            content = v.read(1024)
            if not content:
                break
            fs.write(content)
        v.close()

# 删除产生的临时文件
for letter in range(97, 123):
    os.remove(os.path.join(BASE_DIR, chr(letter) + '.txt'))

文件 A

文件 B

输出结果

还有这种操作？

土豪啊 羡慕你们公司

围观一下

IOS 主要根据分辨率来选吧，Android 的话要根据分辨率，Android 版本，系统型号等，比例覆盖主流的机型就 OK 了。
系统升级，最好是升级前测试一下，升级后再测试一下，对比起来比较容易看出来问题。
IOS 一般的更新不会让 APP 崩溃吧。

WebService 也是通过 HTTP 请求的啊，抓包看一下参数就知道了

不是和 selenium 一起的，你可以在 python 里面调用命令行来执行 AutoIT 生成的 exe

可以用 AutoIT 试一下，我之前上传文件就是用它写的

这个好像是浏览器的弹窗，selenium 应该没办法操作，可以通过配置关闭这个弹窗
这里有个链接 链接

可以用图片比较，Python 有对应的库
还可以比较图片的 url，一般 url 对了，图片也就对了。

每次重启一个浏览器，那运行起来就太慢了
可以在每个用例的 tearDown 里面写个回到首页的处理（APP 同理）

大神！！有没有读书笔记可以分享一下

查看 html，发现超链接前多了一个/，应该是/xxxxx/xxx，写成了//xxxxx/xxx

测试的私活太少了，现在大部分厉害的都做培训去了

感觉楼主有点太乐观了，对于这种场景，根据 20/80 定律，大部分人会选择在最后的几分钟内提交，峰值请求可能会达到均值的 6,7 倍。
而且测试的并发量和时间都不够，可以用 500 并发跑一个小时，再分析结果。

跟排队一个道理，处理速度恒定，但是刚开始堆积了很多人，刚开始去的那批人，等待时间会越来越长，但是到后面时间会趋于稳定 2000/300 约为 6.6 秒；

你可以设置一下 tomcat 的maxProcessors-最大处理线程、acceptCount-最大连接数，比如都设置成 1000。
还有，测试的时候监控一下服务器的 CPU、内存、IO，看看瓶颈在哪里。
具体情况还要根据你们的业务类型来具体分析。

如果你的服务器性能只能处理 110QPS 的请求，那么即使 JMeter 在第一秒发起了 200 个请求，服务器只能处理 110 个，剩下的 90 个会在 Web 服务器的处理队列里面，连接会被挂起，JMeter 也会一直等待这些请求响应，所以 QPS 才会稳定在 110。
而且现在的 Web 服务器这方面都处理得很好，基本不会出现因为并发量高使服务器宕机的情况。
除非请求量特别大特别大，比如双 11 那种量级的。。。

用 Chrome 打断点

比如携程网的城市控件也是没法定位，打了断点之后就可以了

可以用普通的自动化 python + appium 来测吧，长时间运行，测一下稳定性就可以了。
按理来说，你们的 APP 对性能要求应该不是很高吧，毕竟需要输入很多表单，用户操作的速度也是有限的。

一样的，脚本

netstat -tunlp | grep 1099 | awk '{print $7}' | cut -d '/' -f 1 | xargs kill -9