caicai – 简桀玄

性能指标	Best	Good	Acceptable
冷启动速度（单位：ms）	≤600	≤700	≤1000
热启动速度（单位：ms）	≤200	≤300	≤600

搭建博客

1、通过阿里云或者腾讯云申请一台服务器，安装操作系统选择centos

购买配置：内存大于1G，centos选择7.x

2、使用ssh链接工具登录linux

3、安装宝塔linux面板

安装命令：yum install -y wget && wget -O install.sh http://download.bt.cn/install/install_6.0.sh && bash install.sh

会出现如下图片：

出现如下图时，输入y，然后回车

然后等待大概2分钟左右的时间出现如下图代表安装完成

Congratulations! Installed successfully!
==================================================================

Bt-Panel: http://xxx.xxx.xxx.xxx:8888/????????
username: xxxxxxxxx
password: xxxxxxxx

看到这个提示代表控制面板安装完成，Bt-Panel是登录地址，username和password分别为账号密码

4、接下来登录这个控制面板

登陆后看到如下界面，我一般选择左边的lnmp下面的一键安装，采用nginx，如果你个人喜好apache也可以选择右侧lamp

接下来将看到如下图的界面，进入漫长的等待时间

安装完成后，选择软件商店，找到“宝塔一键部署源码”插件，并安装

安装完成后，点击右侧的设置，然后找到要安装的博客源码，比如wordpress或者typecho，点击后面的“一键部署”

将我们申请好的域名指向这台服务器的ip地址，然后再这里填写自己申请的域名

安装完成后，你的博客就搭建好了。

直接访问http://www.jianjiexuan.com/即可访问博客。

下次讲解如果将http免费变为https访问，增加你网站的安全性。

传送门汇总

Tips：

感觉自己的博客越来越乱了，所以想建个目录，这样方便大家快速定位到自己想要的东西，
当然也是方便自己，如果觉得对你有所帮助，可以加我微信：jianjiexuan520

新人能量包

工作效率加速包

测试用例评审检查单及如何评审

功能测试升级塔

业务逻辑
客户端测试
web端测试
服务端测试

自动化测试几日游 这个我是有点欠缺的，主要我的工作环境，不是经常用到，人力和维护成本都比较大，不适宜，所以相关的产出比较少。

性能测试终极试炼

概念汇总

系统性能关注点

JMeter

瓶颈分析

安全测试刺探区

持续更新中。。。

测试部新人培训计划文档

以下是我给当前我们公司入职新人的一份必读文档，因为目前主要产品是app应用，所以偏向于客户端测试，大家可以参考下，某些和公司业务相关的内容隐藏了

一、公司情况的了解

熟悉公司的基本情况有助于快速融入公司，此阶段大约3天的时间。

公司人员的熟悉
公司组织架构的熟悉
了解目前项目组有哪些在线项目，熟悉、使用、把玩，其中遇到不明白的问题可以记录下来
了解部分(隐藏)专业知识

二、测试的前项准备

预先完成以下准备，能减少新人在实际测试过程中犯低级错误的几率，此阶段大约一周到两周的时间。

禅道、redmine、svn、企业邮箱等账号的申请
常用软件的安装（svn、fiddler、Edit）
环境配置（sdk、jdk等）
禅道项目需求熟悉（过一遍大致需求），有不明白的是问题可以记录下来
使用同类型的产品

两周后一般会进行一次深度谈话，可以把不明白的点一次性问清楚

三、项目的学习

了解项目中的敏捷开发流程
了解项目的测试切入点及测试流程
掌握需求，并写出对应的测试用例，按照当前公司的模版
掌握不同环境的测试方式
不同方向的测试注意点
独立完成所负责模块的验收测试
写月总结，给组成员做月回归总结

项目的学习是最关键的阶段，最终的目的是让新人能系统的把项目需求都熟悉，
能快速的融入实际测试中，此阶段大约两周到三周的时间。针对不同方向的测试注意点需要做具体的细化。具体如下：

1. 基本功能测试（主要指app是否完成了设计的所有功能）

安装/卸载时，系统正常安装/卸载成功（注意覆盖安装）
安装成功后，系统图标显示正确；
根据测试用例进行需求点的覆盖测试；
对于中途中的一些返回或退出，应有相应的提示信息；
显示的数据与接口返回的数据一致（抓包查看，如fiddler、charles）；
信息上传到数据库，上传的数据保持正确

2. 系统交互测试（系统正在使用一些功能时，外界给与的干扰是否会影响）

电话短信干扰；
低电量提醒；
push提醒；
usb数据线插拔提醒；
充电提醒；
音乐播放器干扰等

3. 兼容性测试（系统能够在不同的环境下都能正常运行）

软件产品在软件本身的兼容性；
不同平台下的兼容性；
软件对运行设备的兼容性；
软件互操作性（微信等）

4. 易用性测试（内容较多，可参照行业界面测试规范）

路径短，用户操作简单；
界面是否吸引人、容易理解；
界面整洁、简单，色调统一；
无错别字，字体格式统一；
点击范围确定，利于用户操作等

5. 性能测试（作为了解）

客户端稳定性：monkey的执行，会发现一些ANR及CRASH的问题；
app运行的内存消耗和cpu消耗；
app后台长时间运行的耗流量，耗电量；
不同网络下的响应速度测试；
服务端的压力测试，高并发、吞吐量；
服务端稳定性，利用7*24方式去进行测试

6. 其他全局测试

网络切换下的app运行情况及功能正常（wifi/4G/3G/2G）。
网络信号强、弱甚至无网络情况下的app运行情况。

作为测试，你真的入门了吗？

前言：

不同的人对测试或多或少都有不同的定义，最直白的，就是找bug。我们不必纠结它的术语具体是哪些字组成，而是要知道其含义，死记硬背的做法只适合学生时代。

测试的定义：

一般我们对软件测试的专业定义如下：

（1）软件测试是在现有软件（程序+文档）中寻找缺陷的过程；

（2）软件测试是指使用人工或者自动化手段来运行或测试某个系统的过程，目的是检验系统是否满足需求规格说明书中的要求

这两句话我们只需记住3w即：who where what？who？即为人工或其他手段；where？现有软件中；what？寻找缺陷。何为缺陷？与预期不一致的实际结果即为缺陷。这样就算你不刻意去背它的含义，你也已经很明确地知道了何为软件测试。

举例说明：

定义总是看看就明白了，看懂了不一定就真的会了。很多人就真的理解为，说到底不还是找bug么？还是跟着需求找，就像给你两份东西，让你去做校对，这多简单，有什么难度？任何人都可以从事测试这个行业。这不仅仅是外人对测试的理解，甚至很多测试工作者本身也是这么理解的。外人不明白，这么想也情有可原，作为该职位的从业人员也这么想，那说明你真的还没入门。

我们刚开始学习测试或刚出来工作面试的时候，总会遇到一个万年不变的题型，即如何测试“用户登录”。很简单的测试场景，却能完美体现出一个测试人员的根基。很多时候一些公司是不具备完整且非常巨细的需求文档的，所以不要一上来就说，给我一份完整的需求规格说明书，那你和机器真没什么区别了。

那么不妨，我们来挑战下，用一张纸，写下你所知道的测试点，时间限制为5分钟。

下面是三个人的答案，A刚工作，B工作5年，C工作6年，由于时间有限，所以肯定是影响发挥的。

A的答案：

1. 未注册，点击登录；

2. 已注册，输入密码，点击登录；

3. 已注册，忘记密码；

4. 输入不存在的用户名，正确的密码，点击登录。

B的答案：

1.输入正确的手机号和密码可以正常登录

2.输入错误的手机号，点击登录会有对应的登录失败提示语

3.输入错误的密码，点击登录会有对应的登录失败提示语

4.输入未注册的手机号，点击登录，会头对应的提示语

5.手机号格式不正确，点击登录，会有对应提示：请输入正确手机号

6.是否支持邮箱或昵称登录，不支持也需要有对应提示

7.密码设置时若有特殊字符，登录时输入密码，能否校验通过

8.手机号和密码都为空，点击登录，会提示不能为空

9.手机号和密码输入栏，是否一键清除内容功能

C的答案：

1、输入正确的用户名和密码，登录成功

2、输入错误的用户名或密码，给与相应的提示

3、根据需求确定等价类或边界值，进行输入框测试

4、特殊字符的验证

5、文案的正确性，是否有暗文字提示

6、密码是否需要隐藏

7、忘记密码与注册的入口

8、密码框不能复制粘贴

9、是否需要图形验证码

10、界面的正确性及兼容性

11、单个用户的登录响应时间

12、多个用户并发的响应时间

13、传输过程中是否加密处理

14、对于xss的攻击处理

15、抓包无法获取密码明文

16、登录是否唯一，退登操作

17、登录后的权限角色一致

18、修改密码后仍然正确登录成功

对照下自己的答案，你属于哪种？从上面的三份答案，我们可以看出，测试并不仅仅是表面上看的那么简单，由于时间的限制，上面的答案都是不完整且欠缺的，就算这样，出入门和有几年工作经验的差距还是蛮大的，所以，新手不要自我膨胀，测试之路也是一条漫长的路，虚心学习，脚踏实地，方是正道（哈哈，扯远了）。

这边我还想提一点题外话，很多人觉得功能测试者没什么技术含量，搞自动化或者搞性能的才是高手。但在我看来，功能测试厉害的才是真正的大师，技术什么的，只要你愿意，你总能花时间学会，但是功能测试，却要拥有很强的逻辑思维，很全的用例设计，这是花时间也不一定学得来的。所以，会点自动化，搞点小压测，就觉得自己很牛逼的，我是从来不屑的，哪怕你会的东西我都不会。

最后，感谢大家的阅读。

一学就会的接口自动化工具-HttpRunner

当当当！好久没更新了，是不是特别想念，哈哈，下面为大家带来一篇超级简单的接口自动化工具文章~

这篇文章出处不属于我，这边只是拿来共同分享下，比较简单，适合初学者，我本人觉得整体的逻辑和JMeter还是很类似的，只是它的脚本维护比JMeter方便很多，也更加轻便。

运行环境

HttpRunner 是一个基于 Python 开发的测试框架，可以运行在 macOS、Linux、Windows 系统平台上。HttpRunner 支持 Python 2.7 和 Python 3.3 以上的所有版本。

安装方式

解压提供的安装包(下载链接：https://pan.baidu.com/s/1yPglfEVGrRKS-Td6OyJ7kg)
进入目录下运行安装。
运行如下命令，若正常显示版本号，则说明 HttpRunner 安装成功。

录制生成用例

为了简化测试用例的编写工作，HttpRunner 实现了测试用例生成的功能，对应的转换工具为一个独立的项目：har2case。

获取 HAR 数据包

在转换生成测试用例之前，需要先将抓取得到的数据包导出为 HAR 格式的文件。在fiddler中的操作方式为，选中需要转换的接口（可多选或全选），点击菜单栏file-Export Sessions-Selected Sessions（选中HTTPArchive v1.1）-next,保存该har格式文件

转换生成测试用例

由于我们公司接口加密，生成的测试用例需要自己稍微修改

运行测试

可以在Report文件中查看测试报告

用例编写语法介绍

- config:
    name: BaseServer
    parameters:
        - type: ["gold", ""]
    request:
        base_url: https://base.sojex.net
        headers:
            Content-Type: application/json

- test:
    name: GetETFList
    request:
        url: /BaseServer/FinanceBaseApi/GetETFList
        method: GET
        params:
            type: $type
    validate:
    - eq: [status_code, 200]
    - type_match: [status_code, int]
    - eq: [content.status, 1000]
    - eq: [content.desc, "OK"]
    - contains: [content.data.list,{"as":"29112014.13","d":"823.87000","dat":"2019-01-30","v":"34624068366.41","ud":"8.23"}]

config：作为整个测试用例的全局配置项，作用域为整个测试用例
test：测试步骤的变量空间（context）会继承或覆盖 config 中定义的内容
- 若某变量在 config 中定义了，在某 test 中没有定义，则该 test 会继承该变量
- 若某变量在 config 和某 test 中都定义了，则该 test 中使用自己定义的变量值
name: 测试用例名称
request
- base_url：测试用例请求url的公共host

validate：结果断言

| comparator | Description | A(check), B(expect) | examples |
| -- | -- | -- | -- |
| `eq`, `==` | value is equal | A == B | 9 eq 9 |
| `lt` | less than | A < B | 7 lt 8 |
| `le` | less than or equals | A <= B | 7 le 8, 8 le 8 |
| `gt` | greater than | A > B | 8 gt 7 |
| `ge` | greater than or equals | A >= B | 8 ge 7, 8 ge 8 |
| `ne` | not equals | A != B | 6 ne 9 |
| `str_eq` | string equals | str(A) == str(B) | 123 str_eq '123' |
| `len_eq`, `count_eq` | length or count equals | len(A) == B | 'abc' len_eq 3, [1,2] len_eq 2 |
| `len_gt`, `count_gt` | length greater than | len(A) > B | 'abc' len_gt 2, [1,2,3] len_gt 2 |
| `len_ge`, `count_ge` | length greater than or equals | len(A) >= B | 'abc' len_ge 3, [1,2,3] len_gt 3 |
| `len_lt`, `count_lt` | length less than | len(A) < B | 'abc' len_lt 4, [1,2,3] len_lt 4 |
| `len_le`, `count_le` | length less than or equals | len(A) <= B | 'abc' len_le 3, [1,2,3] len_le 3 |
| `contains` | contains | [1, 2] contains 1 | 'abc' contains 'a', [1,2,3] len_lt 4 |
| `contained_by` | contained by | A in B | 'a' contained_by 'abc', 1 contained_by [1,2] |
| `type_match` | A is instance of B | isinstance(A, B) | 123 type_match 'int' |
| `regex_match` | regex matches | re.match(B, A) | 'abcdef' regex 'a\w+d' |
| `startswith` | starts with | A.startswith(B) is True | 'abc' startswith 'ab' |
| `endswith` | ends with | A.endswith(B) is True | 'abc' endswith 'bc' |

参数化
- 直接指定参数列表
- 引用csv数据文件
  - 文件需放置在与测试用例文件相同的目录中；
  - CSV 文件中的第一行必须为参数名称，从第二行开始为参数值，每个（组）值占一行；
  - 若同一个csv文件中具有多个参数，则参数名称和数值的间隔符需实用英文逗号。

```
    - config:
        name: BaseServer
        parameters:
            - type: ${parameterize(ETF.csv)}
            - type: ${P(ETF.csv)}  # 简写方式
        request:
            base_url: https://base.sojex.net
            headers:
                Content-Type: application/json
    
    - test:
        name: GetETFList
        request:
            url: /BaseServer/FinanceBaseApi/GetETFList
            method: GET
            params:
                type: $type
        validate:
        - eq: [status_code, 200]
        - type_match: [status_code, int]
        - eq: [content.status, 1000]
        - eq: [content.desc, "OK"]
    ```

自定义函数生成参数列表

对于没有现成参数列表，或者需要更灵活的方式动态生成参数的情况，可以通过在debugtalk.py中自定义函数生成参数列表，并在用例引用自定义函数的方式。

- config:
    parameters:
        - username-password: ${get_account(10)}

参数关联

- config:
    name: testcase description
    variables: {}

- test:
    name: /api/get-token
    request:
        headers:
            Content-Type: application/json
        json:
            sign:9c0c7e51c91ae963c833a4ccbab8d683c4a90c98
        method: POST
        url: http://127.0.0.1:5000/api/get-token
    extract:
        token: content.token
    validate:
        - eq: [status_code, 200]
        - eq: [headers.Content-Type, application/json]
        - eq: [content.success, true]

- test:
    name: /api/users/1000
    request:
        headers:
            Content-Type: application/json
            User-Agent: python-requests/2.18.4
            device_sn: FwgRiO7CNA50DSU
            token: $token
        json:
            name: user1
            password: '123456'
        method: POST
        url: http://127.0.0.1:5000/api/users/1000
    validate:
        - eq: [status_code, 201]
        - eq: [headers.Content-Type, application/json]
        - eq: [content.success, true]
        - eq: [content.msg, user created successfully.]

小作坊也可出高质量——测试流程优化

测试流程优化

适用于创业型及规模不是很大的公司，一般用于敏捷开发

需求分析

需求预览
- 关于下一阶段的需求会在群里贴出，需要提前消化，疑惑点先行列出，并且告知测试内部评审时间。
评审需求
- 测试内部需求评审，提出疑惑点，领取需求
需求文档维护
- 每一阶段都有一位成员补充该阶段需求到需求文档，以便追溯（一般小作坊是没有规范的需求文档的，有时候需要测试自己去维护）
测试点提取
- 各人领取对应需求后，分析该需求的测试点

测试用例

测试用例
- 不需要写具体的操作步骤，着重写测试点，分基本流和备选流
- 对应需求测试用例由最终负责人编写
- 注意测试用例的格式的统一
- 交叉补充，保证测试点的全面性

范例：
前置条件中加入涉及的需求编号；
用例类型默认为功能测试；
试用阶段默认为系统测试阶段；
用例标题：
【7.9.0】工行支持充值、提现等能力验证
步骤                                      预期
1、工行充值能力验证                        基本流：
                                          1、输入金额等正常信息充值成功，有返回信息
                                          2、*****
                                          备选流：
                                          1、充值过程中，金额不足
                                          2、充值过程中，网络中断
                                          3、控件输入特殊符号容错
                                          4、*****
2、工行提现能力验证                        *******

冒烟测试用例
- 主要用来给开发自测，将本版本所有用例的基本流列入即可。
- 每一阶段都有一位成员提供冒烟测试用例
- 注意标题格式：【V_7.9.0客户端冒烟用例】
- 完成后链接发给对应客户端负责人
封板用例
- 每一阶段都有一位成员补充新增功能到最终封板用例中

冒烟测试

提测阶段
- 开发完成开发后，会发送提测邮件，相关需求领取人走下冒烟测试用例，并反馈是否通过
- 如中途有新增需求或更改需求，需开发、测试再次合理估期，可二次追加提测邮件，以保证质量的可控。
冒烟测试邮件反馈
- 拿到提测包后，一小时内给出需求冒烟测试结果反馈
- 综合测试结果给与邮件反馈，通过则进入系统测试；不通过则打回。

系统测试

测试周期

交叉测试
- 第一轮系统测试由领取需求的人执行
- 最后一轮系统测试由需求负责人执行

需求编号	用例（负责人）	第一轮（领取人）	第二轮（测试环境）	第三轮（正式环境）	第四轮（负责人）
1293-工行充提能力验证	A	B	C	D	A
***	***	***	***	***	***

bug规范

范例：
下图中根据禅道已经给出详细说明

验收测试
- 即根据封板用例测试一下所有功能的主流程，确保所有模块不出大的问题
- 一般是在新增需求已经完全结束测试的情况下进行
性能测试-启动/流量/响应
- 即应用冷启动/热启动的时间（不同版本/竞品的对比）
- 变更大的时候考虑不同版本间耗流量的对比
- 变更大的时候考虑不同版本间响应时间的对比
Monkey测试-提取crash
- 基本流程走通后进行
- 一般是下班后进行，具体操作可参见https://www.jianjiexuan.com/tools/android-sdk/293.html
- 每一位小伙伴都需要执行，提取crash交由开发修改

备注：

这些只是我结合实际调整的方式，力求在最短的时间内，充分利用人力资源保证质量，每个人可以结合公司实际找出最适合的那种方式，测试本身就要灵活点，不能按部就班、死板。

测试人员的发展路线

测试人员的发展路线大概可分为两类：管理路线和技术路线。两条路线的初期阶段基本一致，如图所示：

一、管理路线

每一个阶段有不同的要求和侧重点，可以自己对照下自己处于什么阶段。

1、初级测试工程师

这条路线的初始级别，一般经过试用期后，如果基本符合测试的各项需求，则转成初级测试工程师。初级测试工程师要求具备基本的测试执行能力和测试理论知识，主要集中在手工测试和基本的功能验证性测试方面。

2、中级测试工程师

在初级测试工程师的位置锻炼了一段时间后，就可以考虑转向中级测试工程师。中级测试工程师一般要求具备一到两种完整测试项目的经验。要求具备基本的测试设计能力，对测试理论知识的进一步理解，主要集中在黑盒测试的执行及其测试用例的设计方面；还应具备一定制作测试计划和测试报告的能力。

3、高级测试工程师

从中级测试工程师到高级测试工程师之间有一个明显的界限，就是测试经验。一般要成为高级测试工程师，需要具备3～5个大小测试项目的经验。具备较强的测试用例设计能力，能把测试理论知识融入到测试工作实践中。测试类型包括黑盒测试、白盒测试、性能测试等方面。具备较好的制作测试计划和测试报告的能力。

4、测试组长

在成为高级测试工程师后，则很有可能被委任为某个测试项目的测试组长。测试组长与高级测试工程师在测试技能方面的能力相当，但是具备相对较强的制作测试计划和测试报告的能力，测试的组织能力及沟通能力。测试组长担负着测试、开发以及其他部门之间沟通的角色，负责处理很多沟通上的事情，同时，还负责测试任务的分配、测试资源的安排、测试分工等事项。需要具备一定的测试风险意识，以及与开发人员针对某些焦点问题交涉的能力。需要具备Bug评审的组织和缺陷分析的能力。

5、测试主管

在成为测试组长后，需要表现出较强的组织和沟通能力以及人员管理能力。最好能在公司的大部分项目中做过测试工作，那么就很有可能被委任为测试主管。测试主管与测试组长的主要区别在于：测试主管需要管理的是多个测试项目的资源调度、人员招聘及培训、能力评估和绩效考核。测试主管需要协调测试部门与其他部门之间的工作。测试主管一般不参与具体的测试工作，但是需要对所有测试的进度进行监控，需要关注测试部门的工作和学习氛围以及人员之间的凝聚力。

6、质量主管

如果公司的规模足够大，还可能在测试主管之上设置一位质量主管。质量主管除了管理测试工作外，可能还要管理QA的工作，负责整个公司质量方面的管理。质量主管主要关注测试的整体组织架构设置是否合理，测试工具的选型是否合理，测试人员与其他人员的沟通和交流是否存在问题。另外，质量主管还会重点关注流程的质量，负责引入ISO、CMMI等质量改进模型，并负责质量管理体系的建立和维护，负责整个公司范围内的质量问题的发现，协助管理者制定纠正预防措施，并跟踪措施的有效执行。

二、技术路线

前面的发展路线与管理路线一致，到了高级测试工程师后，就可以考虑在某方面的测试技术领域深造了。

1、单元测试工程师

单元测试是一个可以持续研究、深入研究的领域，本着尽早测试的原则，单元测试无疑是测试性价比最高的一类测试。但是，由于测试人员在编码方面不具备优势，因此，对这方面感兴趣的测试人员可以持续地研究和锻炼自己，让自己成为一名单元测试工程师。

2、白盒测试工程师

白盒测试也是一个需要深入学习和研究才能精通的领域，并且里面有很多技术有待人们进一步发展。代码检查和错误预防技术、自动错误检测等都是很新的话题，对这方面感兴趣的测试人员完全可以持续研究，让自己成为一名白盒测试工程师。白盒测试工程师同样需要具备丰富的代码设计和编写经验。

3、性能测试工程师

性能测试由于其涉及的知识广泛，每一个项目的性能测试都有可能出现一些很具有挑战性的内容，因此，也吸引了很多测试人员的专注，希望成为专职的性能测试工程师。性能测试工程师需要具备丰富而全面的知识，包括程序代码的架构、操作系统、数据库、网络等方面的知识。

4、功能自动化测试工程师

软件测试的自动化一直是很多测试人员心中的梦想，梦想着有一天，测试人员不需要重复地进行劳作，全部测试工作都交给工具进行，测试人员只需要设计测试用例就可以了。梦想总归是梦想，现实中，测试人员需要在自动化测试领域深入地研究，发现更多实用的自动化测试技术。功能自动化测试工程师同样具备一定的编码技巧，同时需要具备丰富的底层API知识。

5、安全测试工程师

安全是近年来软件行业的关注点，安全测试也是相对空白的一个领域。安全测试要求测试人员具备丰富的安全知识，需要了解很多安全漏洞和黑客技术的原理。

6、测试设计架构师

如果具备了多方面或多个测试领域的丰富经验和知识，就具备了成为测试架构师的条件。测试架构师负责测试方面的整体设计，包括测试类型的制定，测试技术和工具的应用，测试工具的开发，整体测试框架的设计和自动化测试框架的搭建。

看完这些，是不是对自己未来的发展明确了些？测试其实包含很多，我们说开发，其实都知道开发分web 端、server端、iOS端、Android端等，同理，作为测试的自己，也要清楚怎么样划分。

HTTP状态码汇总及默认端口号

一、常见HTTP状态码

100	Continue	初始的请求已经接受，客户应当继续发送请求的其余部分
101	Switching Protocols	服务器将遵从客户的请求转换到另外一种协议
200	OK	指示请求成功，且请求的信息包含在响应中。这是最常接收的状态代码
201	Created	指示请求导致在响应被发送前创建新资源
202	Accepted	指示请求已被接受做进一步处理
203	Non-Authoritative Information	指示返回的元信息来自缓存副本而不是原始服务器，因此可能不正确
204	No Content	指示已成功处理请求并且响应已被设定为无内容
205	Reset Content	指示客户端应重置（或重新加载）当前资源
206	Partial Content	指示响应是包括字节范围的 GET 请求所请求的部分响应
207	Multi-Status	多状态响应，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。
226	IM Used	im 使用，服务器已完成对资源的 get 请求, 响应是应用于当前实例的一个或多个实例操作的结果的表示形式。
300	Multiple Choices	指示请求的信息有多种表示形式。默认操作是将此状态视为重定向，并遵循与此响应关联的 Location 头的内容
301	Moved Permanently	指示请求的信息已移到 Location 头中指定的 URI 处。接收到此状态时的默认操作为遵循与响应关联的 Location 头。原始请求方法为 POST 时，重定向的请求将使用 GET 方法（重定向问题）
302	Found	指示请求的信息位于 Location 头中指定的 URI 处。接收到此状态时的默认操作为遵循与响应关联的 Location 头。原始请求方法为 POST 时，重定向的请求将使用 GET 方法（重定向问题）
303	See Other	类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取
304	Not Modified	客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用
305	Use Proxy	客户请求的文档应该通过Location头所指明的代理服务器提取
306	Unused	是未完全指定的 HTTP/1.1 规范的建议扩展
307	Temporary Redirect	和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清除地区分几个状态代码：当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向
400	Bad Request	请求出现语法错误（无法解析此请求）
401	Unauthorized	访问被拒绝，客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。IIS 定义了许多不同的 401 错误，它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在 IIS 日志中显示： 401.1 – 登录失败。 401.2 – 服务器配置导致登录失败。 401.3 – 由于 ACL 对资源的限制而未获得授权。 401.4 – 筛选器授权失败。 401.5 – ISAPI/CGI 应用程序授权失败。 401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
402	Payment Required	保留 PaymentRequired 以供将来使用
403	Forbidden	资源不可用（禁止访问，访问被拒绝）。服务器理解客户的请求，但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。禁止访问：IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因： 403.1 – 执行访问被禁止。 403.2 – 读访问被禁止。 403.3 – 写访问被禁止。 403.4 – 要求 SSL。 403.5 – 要求 SSL 128。 403.6 – IP 地址被拒绝。 403.7 – 要求客户端证书。 403.8 – 站点访问被拒绝。 403.9 – 用户数过多。 403.10 – 配置无效。 403.11 – 密码更改。 403.12 – 拒绝访问映射表。 403.13 – 客户端证书被吊销。 403.14 – 拒绝目录列表。 403.15 – 超出客户端访问许可。 403.16 – 客户端证书不受信任或无效。 403.17 – 客户端证书已过期或尚未生效。 403.18 – 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。 403.19 – 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。 403.20 – Passport 登录失败。这个错误代码为 IIS 6.0 所专用。
404	Not Found	无法找到指定位置的资源。这也是一个常用的应答。 · 404.0 -（无） – 没有找到文件或目录。 · 404.1 – 无法在所请求的端口上访问 Web 站点。 · 404.2 – Web 服务扩展锁定策略阻止本请求。 · 404.3 – MIME 映射策略阻止本请求。
405	Method Not Allowed	请求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）对指定的资源不适用，用来访问本页面的 HTTP 谓词不被允许（用于访问该页的HTTP动作未被许可）
406	Not Acceptable	指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容，客户端浏览器不接受所请求页面的 MIME 类型
407	Proxy Authentication Required	要求进行代理身份验证，类似于401，表示客户必须先经过代理服务器的授权
408	Request Time-out	在服务器许可的等待时间内，客户一直没有发出任何请求。客户可以在以后重复同一请求
409	Conflict	通常和PUT请求有关。由于请求和资源的当前状态相冲突，因此请求不能成功
410	Gone	所请求的文档已经不再可用，而且服务器不知道应该重定向到哪一个地址。它和404的不同在于，返回407表示文档永久地离开了指定的位置，而404表示由于未知的原因文档不可用。（文件已删除）
411	Length Required	服务器不能处理请求，除非客户发送一个Content-Length头
412	Precondition Failed	请求头中指定的一些前提条件失败
413	Request Entity Too Large	目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求，则应该提供一个Retry-After头
414	Request-URI Too Large	指示 URI 太长
415	Unsupported Media Type	不支持的媒体类型
416	Requested range not satisfiable	服务器不能满足客户在请求中指定的Range头
417	Expectation Failed	执行失败
423	Locked	锁定的错误，意味着一个方法的源或目标资源是锁着的。这种反应应该包含一个适当的先决条件或后置条件代码
424	Failed Dependency	失败依赖项，状态代码意味着无法对资源执行该方法，因为请求的操作依赖于另一个操作，而该操作失败。例如，如果 PROPPATCH 方法中的命令失败，则至少其余命令也将失败。
425	Unordered Collection	无序集合
426	Upgrade Required	需要升级，客户端应当切换到TLS/1.0。
500	Internal Server Error	服务器遇到了意料不到的情况，不能完成客户的请求（服务器内部错误）： 500.12 – 应用程序正忙于在 Web 服务器上重新启动。 500.13 – Web 服务器太忙。 500.15 – 不允许直接请求 Global.asa。 500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。 500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。 500.100 – 内部 ASP 错误。
501	Not Implemented	服务器不支持实现请求所需要的功能，页眉值指定了未实现的配置。例如，客户发出了一个服务器不支持的PUT请求。（标题值指定的配置没有执行）
502	Bad Gateway	服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。亦说Web 服务器用作网关或代理服务器时收到了无效响应 · 502.1 – CGI 应用程序超时。 · 502.2 – CGI 应用程序出错。
503	Service Unavailable	服务不可用，服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个 Retry-After头。这个错误代码为 IIS 6.0 所专用
504	Gateway Time-out	网关超时，由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答
505	HTTP Version not supported	服务器不支持请求中所指明的HTTP版本
506	Variant Also Negotiates	代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。
507	Insufficient Storage	存储不足，表示方法不能在资源上执行，因为服务器无法存储，表示需要成功完成请求。
516	Not Extended	不扩展

二、常见协议端口号

HTTP	80
FTP	20用于数据连接, 21用于端口连接
SSH	22
Telnet	23
HTTPS	443

三、常见数据库端口号

MYSQL	3306
SQL Server	1433
Oracle	1521

常用adb命令及monkey命令详解

基于这篇文章，给大家再深入一下。

传送门：https://jianjiexuan.com/tools/android-sdk/293.html

我将有一段时间进行人生的思考，所以，这边插播一下我的微信，文章可能暂时停停。

一、常用adb命令

1、adb devices：查看已连接的设备

2、adb version：查看adb的版本序列号

3、adb -s <设备名字>：指定某设备做什么（设备名字用1的方法可以查看）

4、adb install <安装包.apk>：安装应用（写清楚apk的完整路径）

adb -s <设备名字> install <安装包.apk>：指定设备安装应用

5、adb shell：通过远程shell命令来控制模拟器/设备

6、exit：退出shell远程连接，回到原路径。（Ctrl+d，退出shell，回到默认路径）

7、adb pull <设备端路径> <pc端路径>：将指定的文件从设备/模拟器上拷贝到pc端（后面的pc端路径可以不指定，默认存储在当前路径下）。例：

adb pull /sdcard/log.txt c:/monkey

8、adb push <pc端路径> <设备端路径>：将指定的文件从pc端拷贝到设备/模拟器上

9、adb shell pm list packages：列出电脑端所有apk的包名

10、adb shell pm path packages：获取包名对应的apk路径

11、adb shell ps ：查看已链接设备上所有进程

12、adb logcat：查看pc端的日志输出。

adb shell界面只需输入logcat，查看设备端日志输出（退出Ctrl+c）

13、adb reboot：重启设备，强制停止monkey时可以使用此命令，简单粗暴。

二、Monkey命令扩展

1、最简单的monkey执行语句：

（adb shell）monkey –p com.jianjiexuan.na –v 500 (对com.jianjiexuan.na 这个程序包单独进行一次500次的monkey测试)

名词解释：

-p：用于约束限制，用此参数指定一个或多个包。指定包之后，Monkey将只允许系统启动指定的APP。如果不指定包，Monkey将允许系统启动设备中的所有APP。

指定多个包：monkey -p <packagename1> –p <packagename2> -p <packagename3> -v 500

-v：用于指定反馈信息级别（信息级别就是日志的详细程度），总共分3个级别，分别对应的参数如下表所示：

日志级别 Level 0

例 monkey –p com.jianjiexuan.na –v 500

说明：缺省值，仅提供启动提示、测试完成和最终结果等少量信息

日志级别 Level 1

例 monkey –p com.jianjiexuan.na –v -v 500

说明：提供较为详细的日志，包括每个发送到Activity的事件信息

日志级别 Level 2

例 monkey –p com.jianjiexuan.na –v -v -v 500

说明：最详细的日志，包括了测试中选中/未选中的Activity信息

2、延时及固定序列

（adb shell）monkey -s 100 -p com.jianjiexuan.na – -throttle 1000 -v 500 （每次执行一次有效的事件后休眠1000毫秒）

（adb shell）monkey -p com.jianjiexuan.na – -throttle 1000 – -randomize-throttle -v 500 （每次执行一次有效事件后随机延时0-200毫秒）

名词解释：

-s：用于指定伪随机数生成器的seed值，如果seed相同，则两次Monkey测试所产生的事件序列也相同的。出现问题下次可以重复同样的系列进行排错。

–throttle：固定延时，用于指定用户操作（即事件）间的时延，单位是毫秒；

–randomize-throttle：随机延时，用于指定用户操作（即事件）间的时延，单位是毫秒。

3、保存monkey运行结果

1）保存在PC中

adb shell monkey –p com.jianjiexuan.na –v 500 > d:\monkey\log.txt

2)保存在手机中

手机端进入shell模式：adb shell

monkey –p com.jianjiexuan.na –v 500 > /mnt/sdcard/monkey/log.txt

4、monkey事件百分比的调整

（adb shell）monkey -p com.jianjiexuan.na -v – -pct-anyevent 100 500

指定多个类型事件的百分比：

monkey -p com.jianjiexuan.na -v –pct-anyevent 50 –pct-appswitch 20 500

名词解释：

–pct-****：设置某个事件的百分比。后面接数字（0-100），100即100%的概率执行该事件

monkeygai01

注意：各事件类型的百分比总数不能超过100%。如果不进行设置则显示默认百分比。

5、正在运行的monkey如何终止

如在命令窗口端直接打印结果，想要停止monkey的运行，除去重启设备的粗暴方式停止monkey的运行，也可以这样：再打开一个cmd命令窗口

查看monkey的进程：adb shell ps | find “monkey”

monkeygai02 kill掉该进程就可以

adb shell kill + 进程编号，即adb shell kill 5182

关于其他的细化的，后续会继续更新中。。。

作者： caicai

客户端性能之冷热启动

一、冷热启动

1、定义

2、测试方法

3、数据分析

4、场景分析

搭建博客

传送门汇总

测试部新人培训计划文档

作为测试，你真的入门了吗？

前言：

测试的定义：

举例说明：

一学就会的接口自动化工具-HttpRunner

运行环境

安装方式

录制生成用例

获取 HAR 数据包

转换生成测试用例

运行测试

可以在Report文件中查看测试报告

用例编写语法介绍

小作坊也可出高质量——测试流程优化

测试流程优化

需求分析

测试用例

冒烟测试

系统测试

备注：

测试人员的发展路线

HTTP状态码汇总及默认端口号

常用adb命令及monkey命令详解

一、冷热启动

1、定义

2、 测试方法

3、数据分析

4、场景分析

前言：

测试的定义：

举例说明：

运行环境

安装方式

录制生成用例

获取 HAR 数据包

转换生成测试用例

运行测试

可以在Report文件中查看测试报告

用例编写语法介绍

测试流程优化

需求分析

测试用例

冒烟测试

系统测试

备注：

2、测试方法