一、传输数据方式

• GET : 是放在URL后，？分割请求数据，&分割请求参数
• POST：四种常见的提交方式

二、安全性

POST将请求数据放在请求体中，GET放在URL中，HTTP是明文传输，所以从攻击角度，为了安全要用HTTPS协议

三、请求数据大小

在HTTP协议中，并未对GET请求限制大小，是浏览器限制，并且不同浏览器限制不同。
POST无此限制，但理论上，IIS4中最大量为80KB，IIS5中为100KB。
为什么GET浏览器会限制？
URL这种东西必须当作一个整体看待，无法一块一块处理，于是就处理一个请求时必须分配一整块足够大的内存。如果URL太长，而并发又很高，就容易挤爆服务器的内存；

post提交的数据必须放在实体(entry-body)中，但协议没规定必须使用什么编码方式。
请求头（heads）中Content-Type字段来获知实体是用何种编码方式，从而对实体进行解析。
Accept：是能接受的编码方式，而不是发请求编码方式。

一、application/x-www-form-urlencoded

Nginx 是一款自由的、开源的、高性能的 HTTP 服务器和反向代理服务器；同时也是一个 IMAP、POP3、SMTP 代理服务器；是个轻量级的高并发服务器。

代理服务器概念(proxy)

N-UNCOUNT If you do something by proxy, you arrange for someone else to do it for you. 代理权
客户端⇄代理服务器⇄目标服务器

测试分析可总结为四步：

建模 - 输出业务/系统流程（分析：业务流程 - 系统流程）
设计 - 测试场景（设计：测试场景=业务场景）
细分 - 测试用例/数据（设计：测试用例）
扩展 - 多类型测试（性能，安全，异常等等）（基于经验）

将需求说明转化为业务流程，完成事件流（基本流+备选流）以及业务分析过程和技术分析过程的梳理。细化出原子级别的场景分支。

转自：https://mp.weixin.qq.com/s/Y_DhYHYecl84WAcSdl0mCw
　　自动化的能力并非在于自动执行用户任务（并非怀疑所有的价值，我承认有一类自动化测试是有价值的：编写简单的测试，定时运行跨多平台和操作性的测试，以确保兼容性等）。测试自动化的真正威力，是编写代码来测试代码，使得计算机执行的测试工作是用其他方法无法替代的。

　　好的测试设计必须考虑到软件行为功能（它是否做了所期望的事情，又是否做了不被期望的事），以及非功能的属性，比如可靠性、性能和安全性等。一个好的测试设计方法是将这些东西视为整体（系统性思维）。我经常通过头脑风暴产生脑图来开始这个过程的，以确定测试方法。下面是一个脑图的例子：

　　在创建这张脑图的时候，并没有考虑任何要不要执行自动化的问题，只是写了许多关于要测试的笔记、想法和问题。最终，我会使用脑图来帮助我组织测试思路，并通过脑图与其他人交流。
现在，就可以着手考虑自动化了！脑图里有许多关于需要发送的字符串的不同想法，每个测试的设置都手动执行是极其无聊而烦人的（此时正好就需要一个好的启发思维来决定哪些部分进行自动化测试），于是就从这里开始：
For Each string in TestString.txt
{
SendSackMessage(string);
VerifyMessageAppears(string);
VerifyRemoteMessageAppears(string);
}

A同学现在有个测试任务正做着，突然来了一个PM，说有需求要宣讲，二话不说跟着去了，需求刚宣讲完，屁股没坐热乎，另一个PM发邮件说线上有个bug帮确认复现一下，接着又搞这个了，不知不觉，时间过去2个多小时了，测试任务还未有实质性的进展，突然QQ亮了，哎呀是暗恋的一个大学MM，荷尔蒙急剧升高，聊会儿吧。。。有人叫一起吃饭去了，一看时间，午饭时间快到了。午饭归来，浏览下网页，看看微薄，接着干活，测着测着，哎妈呀好不容易发现个bug，但是自个儿还不敢报，怕自己对业务不熟悉提了个NOTABUG的bug，找了下他师傅B同学确认了下，B同学说是bug，兴致勃勃的提交上去感觉很有成就感。不一会儿开发来了，我看看是不是你环境有问题配置有问题啊，一屁股坐在A同学位置上了，啪啦啪啦开始找问题，开发人员终于还是承认了自己的失误，灰溜溜回去解bug了。A同学一看，哇塞，都三点多了，一看用例才执行了10多条，还有好几十条，今晚要发布这可如何是好，必须得加快测试了，执行到一半的样子，发现一个大bug，而且这个bug不修复的话严重影响后面很多case的执行，赶紧报上去。然后自己接着测试，到了5,6点多了，用例跑完了，终于松一口气，胸有成竹的告诉了B说自己用例跑完一遍了，B结果一看bug一个都没解呢。等到开发修复完，时针指向了7点钟方向。回归测试完毕达到上线标准时已经10点钟了，又是一个苦逼的日子…

日志文件的需求

“软件要将所有的访问者都要记录下来，对每次访问要记录访问开始时间、访问结束时间、访问者的IP地址这三个信息作为一条日志记录。要求以天为单位每天生成一个访问记录日志文件。

需求中三个元素：访问者、访问记录、访问文件，下面依次对其分析

一、 访问者和访问记录

每条记录仅仅包含访问时间和ip，对其分析只能看出哪段时间访问的人数多，得到用户的时间规律，很难对用户进行深入的分析，只有知道访问者在访问时的内容才能获得更大价值。

一、被测功能在系统中的地位

　在一个软件内部，不同功能模块的质量标准一般来说也会有差异。客户最关注的功能显然应该得到测试的重视，需要投入较多的精力对其进行验证。除此之外，对那些非核心功能、但对核心功能产生影响的模块，我们也不应该忽视，至少要保证这些模块在一般情况下能够正常运转，在遇到异常情况时能够做出令人接受的合理反应，不会导致核心功能发生超出耐受度的错误。

Android App兼容性测试是一个比较重要的App质量评价内容，与功能测试不同，兼容问题只是影响部分用户，但一旦发生在用户覆盖率较大的机型上，则会升级成极为严重的问题。
以下也是一个新设备需要关注的点

一、用户

每款APP的用户群体都有自己的特征，针对用户对应的特征来设计兼容性。
比如拥有大量海外用户，可以考虑币种、多语言、时区、本地化。
比如用户群体中老人较多，可以考虑大字体的适配

转自：https://mp.weixin.qq.com/s/HxfEi_SGJjGABCDF0EqADw

等价类

　等价类是指某个输入域的子集合 在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，子集合中包含的元素要么全部被正确处理，要么全部都没有被正确处理。因此，可以把全部的输入数据划分成若干的等价类，在每一个等价类中取一个数据来进行测试。这样就能以较少的具有代表性的数据进行测试，而取得较好的测试效果。等价类划分是将程序的输入域(较多见)或输出域(较少见)的不同区间划分为不同的数据类，以便导出测试用例