测试能力等级划分
最近看一本书，上面说到测试工程师随着工作经验的提高，能力也会提高，但是有时候也会问自己，工作三年与工作四年的区别在哪里，书上对测试工程师分了几种等级，等级与技术无关，与测试方法与测试经验有很大的关系。在此总结出来，再加上自己的理解，基本能解决心中一直以来的困惑。

测试一级

能根据测试用例描述的步骤来执行测试用例，能对照用例的预期结果发现产品的问题，能够将问题清晰想记录下来反馈给开发，开发能够读懂bug的含义。

个人理解：执行用例的tester，只有大型的公司或外包公司才会有这种岗位，一般公司都会要求写测试用例的。

测试二级

对产品需求有一定理解，能够根据产品需求设计产品的测试用例，发现问题后能进行初步定位。

个人理解：这条涉及到两方面的能力。
1、独立编写测试用例的能力。
2、发现问题后能大概判断出是哪里的问题，这个定位不是代码级别的定位，而是功能模块方面的定位。就好比我测试一个系统，由a、b、c、组成，a出了问题，能判断是数据经过b时处理错误了还是经过c时处理错误了。但是这个能力需要你对被测试的产品有很深的理解，对于跳槽就基本等于换行业的IT技术来说，这个能力通俗点讲应该叫“上手速度快”。这个应该算是合格的测试工程师的基本能力。

测试三级

对产品的需求和实现都有较为深入的理解，设计用例时会注意用例的有效性，测试用例时会考虑使用自动化测试等方法提升测试执行的效率；

个人理解：编写测试用例时不再是严格按照规范来编写，而是会根据被测产品，找出测试重点来有针对性的编写测试用例，而其他的一些不太重要的地方则大概写一些测试case来提醒自己不要漏测就好。自动化方面小规模做还行，大规模得要领导与公司的支持，毕竟也要投入人力与时间。

测试四级

深入理解产品需求和实现，理解产品质量，理解产品的隐形需求，对产品性能、可靠性、易用性等非功能属性的测试均有所涉及，并掌握其中的测试方法，会使用测试缺陷分析技术，会评估产品质量；

个人理解：不明白具体的是什么能力

测试五级

不断追求最适合产品的测试技术，关注测试过程改进，推动产品测试技术的进步；

个人理解：不断学习新的技术，关注测试过程，应该根据每次的测试结果来

环境

ECS：4 vCPU 8 GiB
php-fpm配置

pm = dynamic
pm.max_children = 100
pm.start_servers = 11
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 2048
pm.process_idle_timeout = 10s
request_terminate_timeout = 120
request_slowlog_timeout = 2

一台ECS
2001400并发的时候开始出现故障，1800的时候完成全部失败，请求成功率57.51%(120541/89051)

弹性伸缩
自动伸缩增加机器的时候会出现异常

没有弹性伸缩2台ECS，请求成功率67.15%(144956/70903)详情

没有弹性伸缩4台ECS，请求成功率88.57%(316114/40810)详情

结论：
并发1300的时候会出现4分异常

一、输入框

1、字符型输入框：

1. 英文半角、英文全角、数字、汉字、特殊符号（( ' & $ !）、英文双引号、英文单引号、&、系统保留字、编程保留字、数据库保留字、；所有键盘可以输入的字符（全角、半角）
2. 复制粘贴不允许输入的字符
3. 空
4. 空格（半角、全角）：仅空格、字符前中后有空格
5. 输入null、NULL
6. 最大边界值、最大边界值+1、最小边界、最小边界值-1、超长字符
7. 输入htm代码：比如"<font>你好</font>"
8. 输入javascript代码：比如 <param name="MovieWindowWidth" value="320">；<b>hello</b>;alert("hello");doucment.write("abc");
9. 转义字符：比如<Script Language="JavaScript"> </script>；<br>；<tr>；<td>；</tr>；</td>；</html>；</body>；</table>等
10. Tab、Enter键
11. 多行文本框输入：
    
    • 允许回车换行、保存后再显示能够保存输入的格式；
    • 仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）

2、数值型输入框：

1. 边界值：最大值、最小值、最大值+1、最小值-1
2. 位数：最小位数、最大位数、最小位数-1、最大位数+1、输入超长值、输入整数
3. 异常值、特殊字符：输入空白（NULL）、空格或"~!@#$%^&*()_+{}|[]:"<>?;',./?;:'-=等可能导致系统错误的字符、禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能，通过剪贴板拷贝到输入框，分页符，分节符类似公式的上下标等、数值的特殊符号如∑，㏒，㏑，∏，+，-等、不能直接输入，就copy，是否数据检验出错；
   输入负整数、负小数、分数、输入字母或汉字、小数（小数前0点舍去的情况，多个小数点的情况）、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制，8进制数值、货币型输入（允许小数点后面几位）
4. 正数、负数、0、0.0、+0.0、-0.0、指数、对数、分数、整数、小数、复数

在线用户数：用户同时在一定时间段的在线数量

并发用户数：某一时刻同时向服务器发送请求的用户数

一般而言，我们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即，并发与在线的比例约为5%-20%

比如，某网站存在注册用户数为10W人，但同时在线最多1W人，但这1W个人，可能只有500人会浏览帖子，500人会进行发帖，只有这1000个人对服务器才有交易，那我们计算并发量的时候，就可以以1000为标准！

昨天读完了段念写的《软件性能测试过程详解与案例剖析》一书的第一章，感觉学到了不少东西，以下将该书中的我认为是精华的一篇过来给大家一起看看：

在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。

假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

在实际的性能测试工作中，测试人员一般比

一、经典公式1：

一般来说，利用以下经验公式进行估算系统的平均并发用户数和峰值数据
 
1. 平均并发用户数为 C = nL/T
2. 并发用户数峰值 C‘ = C + 3*根号C

C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
C’是并发用户数峰值
 
举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。
那么，
平均并发用户数为：C = 400*4/8 = 200
并发用户数峰值为：C‘ = 200 + 3*根号200 = 243

举例2， 某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会用这个系统，假设只有50%的人会定期用该系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。
则一个月最后一周的平均并发用户数为（朝九晚五）：
n = 170000*0.5*0.7/5 = 11900
C= 11900*5/60/8 = 124
 
吞吐量计算为：F = Vu * R / T 单位为个/s
F为事务吞吐量，Vu为虚拟用户数个数，R为每个虚拟用户发出的请求数，T为处理这些请求所花费的时间
 

二、通用公式2：

对绝大多数场景，我们用（用户总量/统计时间）*影响因子（一般为3）来进行估算并发量。
比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为50000*80%/（3*60*60）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！
 

三、根据PV计算公式：

比如一个网站，每天的PV大概1000w，根据2/8原

一．系统吞度量要素：

一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。

单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

QPS（TPS）：每秒钟request/事务 数量

并发数： 系统同时处理的request/事务数

响应时间： 一般取平均响应时间

（很多人经常会把并发数和TPS理解混淆）

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

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

一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

决定系统响应时间要素

我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。

系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间；

关键路径是有CPU运算、IO、外部系统响应等等组成。

二．系统吞吐量评估：

我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。

而通常境况下，我们面对需求，我们评估出来的出来QPS、并发数之外，还有另外一个维度：日PV。

通过观察系统的访问日志发现，在用户量很大的情况下，各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。

通常的技术方法：

1. 找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响之外）
2. 通过压力测试或者经验预估，得出最高TPS，然后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS和PV关系比例也不一样。

A)淘宝

　　今天逛测试之道论坛，发现这篇文章，虽然标题是写着为了面试，但其中的理论知识对在座的同仁也会有很大的帮助！

01. 为什么要在一个团队中开展软件测试工作？

　　因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

02. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？　

　
　　我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试

03. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）

　测试类型有：功能测试，性能测试，界面测试。　
　功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术**设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。　

　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。　　

　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。　　
　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试