入行测试开发，马上就要10年了。创业公司待过，大公司也待过，工作这一路走来，一些心得，转变，职场体会，早就想写出来分享一下。这个历程包含了技术的提升，工程师的素养和对这个行业的点滴感悟。


自动化测试vs测试开发

记得刚入行那会，我的title是自动化测试工程师。那时对这两者的区别还没那么明显，面试时候两者的问题也都比较类似。当时招聘“会写代码的测试人员”比较偏向称之为“自动化测试工程师”；不过现在很多企业的招聘都变为“测试开发工程师”了。

究其概念，其实自动化测试工程师更偏向于业务方向的效率提升；而测试开发则更偏向于基础架构方向的效率提升。打个简单的比方，测试开发工程师产出的框架可以认为是父类，自动化测试工程师按业务线不同，可以理解是继承自父类的不同子类。

测试开发到底在做什么

测试开发，最早起源于《Google软件测试之道》这本书，里面第一次提出了SET(Software Engineer in Test)。不过不同的公司称谓也不一样，像国内很多时候还是统称为QA。

那么SET具体在做什么呢？在我看来，SET偏向于测试部门的基础架构开发和流程的设定，比如前面说到的自动化底层框架搭建，或者改写一些开源的类和方法，去提供给组内其他的测试人员使用；再比如，我们所熟知的CICD，单元测试or集成测试的覆盖率统计，以及自动化部署发布的脚本，都可以归到测开的工作范畴里；还有，我们常说测试也需要新技术的引入，现在常见的Docker跟k8s也在逐渐普及到测试团队，因为测试最大的一个障碍是“测试环境众多”，而容器化可以很好的解决这一点。

当然不同的公司情况多有差异。一般来说，越是大型的企业，它的测试流程越规范，测开的作用也就越明显，对应的产品测试效率，也就越高。

质量保障的终极任务

我相信现在很多测试工程师，其实都有足够的共鸣，就是“我们不是测bug的，我们是产品的质量保障员”。但是很多不成熟的企业和团队还是会有误区。比如，bug数目确实可以代表你工作的产出，但如果你的团队或领导把bug数目作为唯一指标，我觉得你是时候考虑跳槽了。质量保障，在我看来涵盖很多东西，是一个很庞大的概念，大概可以包括四点：

1.正确的流程

现在很多都是敏捷开发模式了。在需求评审阶段，测试同学参与并对需求or产品有一定的理解和初步的测试计划

2.基础的质量

开发代码的规范度，基础代码的走查，监督单测覆盖率的稳步提升，毕竟基础决定上层

3.业务的覆盖

确切可以拆分成服务接口的测试/前端UI测试/性能测试/稳定性测试/系统集成测试/回归测试，这一点可以说是测试同学交叉最多的地方。

4.产品终端的保证

协同制定灰度发布策略/规范线上的操作/了解用户使用过程中常见的风险点/制定止损策略

简单来说，测试保障质量，质量决定产品。测试应该是对需求，对产品逻辑最最了解的那个角色。所以，只要关于产品变更的，测试同学都应该下意识去跟进。

而以上的任何一点，都可以深究，去做的更好。

工程师文化

我相信再牛逼的测试开发，也要从业务抓起，你不了解业务，不了解一些开发代码或者的话，有些东西也是扯淡。业务测试在我看来一点都不low，反而是一个很考验人的事情。不管是测试工程师也好，测试开发也好，我们都是工程师，都服务于产品。既是工程师，就该有工程师的素养，我认为完成一个好的测试任务，大概需要同时做到以下几点：

1.对测试结果负责

我们是产品的最后一道关卡，我们对产品发布与否有绝对的话语权，同时，我们也要对自己的测试结果负责。

2.测试到最终场景

现在很多产品链路都很长，这就需要测试同学主动去塑造自己产品的大局观，而不局限在某个单元的测试，不考虑全局，有时会造成致命的线上灾难。

3.对日志敏感，能够精准定位问题

如果开发流程足够规范的话，有完整的日志系统，其实定位问题并不难；我们每发现一个bug，都可以尝试去追溯它的根源，时间久了，你会对工程代码或逻辑摸的很清楚，这对你接下来的测试工作简直如虎添翼。

4.对相似问题和漏洞的归纳

不管是前方客户的问题，PM发现的问题还是自己的bug库，经常归纳可以节省很多时间，会让你对自己的工作产生一种“直觉”，但这种直觉有时很准哦。

面对不同的产品该怎么办

开发技术或框架可能是通用的，但测试可能会随着产品形态而产生“独特”的调整，我称之为“测试形态”。比如，现在的人工智能测试，因为每次模型迭代，测试所需的数据量很大，你用传统的并发去请求可能就不行，那你可能就需要学一些分布式技术；再有就是云服务测试，这种绝大部分是纯后端服务测试，或者SDK测试，没有前端去assert你的预期，那么你就需要足够熟悉curl命令，网络命令等，甚至去生成一些shell脚本，来执行你的测试请求；还比如手机端的测试，那它的兼容和稳定性呢怎么保证，则又是一门学问；最后还有比较火的智能硬件，盒子啊TV啊这些，怎么保证它的质量，则又是另一种路子。

但，归根结底：测试思想不会变，以不变应万变。

总之，测试是一门大学问，它入门门槛并不高，但是越深入，你发现自己了解的越少。作为一个职场人员，不随业务转变而转变，有自己的沉淀和技术底子，才能更长久。而测试开发这个行业，鄙人认为未来也会愈加重要，它是衔接产品/测试/开发的一根纽带，它在背后默默支撑着整个测试体系有条不紊的进行，某种程度上说， 算是一个隐者吧。
欢迎加入 51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】... 51与你共同学习，一起成长！期待你的加入： QQ                     群：                    755431660

1、我想问一下关于自动化测试工具Selenium和QTP的区别。假如一个系统现在需要一款自动化测试工具，要求可以重复提交表单进行功能性测试，不用纯手工去做（因为工作量过大），现在有两个工具（Selenium和QTP），哪个比较适合？

这个要看情况:

1）你们公司是不是土豪，可以买qtp，可以买就用qtp。不能买，敢不敢用盗版？敢用，就用qtp。

2）页面元素的识别麻烦不？如果qtp搞不定，就只有努力学习，提升自己的编码能力，使用selenium去操控底层的页面元素来实现。如果页面元素不麻烦，想偷懒，请参考第一条。

2、目前很多项目自动化最多就是跑冒烟测试，所以更大的意义在哪里呢？求解。

冒烟测试也是很有意义的，可以在最短的时间内验证程序是否跑得起来，而且因为测试用例少，实施起来门槛低，容易实现。比如我要做的一个windows客户端程序，冒烟测试就只有登录和3个基本功能。如果登录失败，则可以第一时间发现平台环境（包括数据库）是否正常。测试好立即恢复环境，以免影响后续测试工作。

3、毕业一年半一直做功能测试，想转自动化测试，不知道怎么开始第一步？老师有没有什么建议？

其实才毕业，任务安排还不能随心所欲，要听老大的。做好老大安排的任务是最基本的。功能测试技术含量听起来不高大上，但是可以深入了解自己公司产品的业务流程。业务流程对测试人员来说才是最重要的。

如果一定想转学自动化测试，可以先自己自学，等待老大给机会。自动化测试对一般公司来说还是比较奢侈的（哈哈），需要等待机会。希望你好运。

4、如果想要把自动化发挥更多更广阔的地方，应该是朝哪个方向呢？

冒烟测试的基础上，下一步就是要实现基本功能的自动化回归测试了。

基本功能测试用例集的确定非常重要，一定是那些最基本最核心最稳定的功能。基本功能用例集实现自动化测试后，这些测试用例会被反复执行（特别是在每日构建流程中），所以性价比是最高的。

下一步就是将更多的功能加入自动化测试。这些非基本功能可能不会每次都自动化回归。但是在一个开发周期中可能会被反复执行。所以也很重要。

5、想请教一下，如果测试场景中，涉及到输入验证码，能实现自动化吗？

基本上这个很难。如果自动化测试能够绕开验证码，那这个验证码得多笨。

这种情况下，一般都需要开发配合，提供去掉验证码的测试版本。

6、自动化测试后是否还要提交给单独的测试部进行系统测试？

这是必须的。千万不要以为自动化测试是万能的。即便微软、谷歌等公司也不是这样。

记住，自动化测试只能用于回归测试，而且要在脚本通过了长期验证，证明没有问题的情况下。

刚刚做自动化测试的同事，常常碰到一个问题，自动化测试脚本其实也是代码，开发写的代码靠自动化测试脚本来保证质量，那自动化测试脚本靠谁来保证质量呢？只能靠脚本编写人员的能力来保证，和长时间的实践来检验了。

7、看了好多jenkins自动化测试的配置，都是说在构建的时候执行测试用例，可是构建的时候，连服务都没有怎么可能测试成功啊？

我认为的过程应该是：（1）提交代码；（2）构建编译；（3）自动部署（4）自动化测试，求大神解释一下，jenkins怎么做到我说的过程的？

如果是代码级的单元测试 集成测试，可以在自动部署前，构建的时候运行。不过我还是建议单元测试 集成测试和构建分开为两个步骤。

如果是系统测试，就只能在自动化部署后。你的理解是正确的。

8、我正在学习web开发，哪一个版本的火狐浏览器适合做web开发测试？

用chrome吧，chrome浏览器比较常用一些

9、我在学习QTP，我用的版本是UFT12，为了实现拖动浏览器的滚动条，网上查到的脚本代码是Browser().Page().Object.body.doScroll("scrollbarDown") ，但是我在编写这条代码时，Object的属性和方法里却没有body，是什么原因？

没有实际环境，我也不好回答你。不过这种找不到属性的问题在QTP使用的时候是常事。这也是我喜欢sikuli的原因之一。我建议一个偏方，你试试发送page-down键盘消息看看呢。

10、为何国内的前端对自动化测试好像不是很看重？

自动化测试的重点不是实现自动化测试或者把它加入到开发上线流程中，而是要对用例做收集管理，借助丰富的用例来保证代码质量。而用例的收集管理是否可以成功，取决于业务是否稳定可预测。现阶段国内的IT行业还处于高速增长期，业务善变不稳定。尤其是UI的变化更是频繁。此时收集管理用例成了西西弗斯的惩罚，消耗人力不说，还无法用来保证代码质量。对于与业务无关的底层框架、库来说，自动化测试一直是存在的。但正如他们所处的位置，相对公司范围，只会是小范围小团队对其它有依赖，难以扩大影响，在频繁变更的业务线也无法推广。所以，我想，等高速增长期结束了，业务趋于稳定后，它才有可能被普遍重视吧。

11、APP UI自动化测试框架都包含哪些内容?

所有的自动化测试框架都牵涉到3个阶段：setup, execution, teardown。setup阶段你需要想好你的case执行策略和之间的关联关系如何解决（支持并发执行吗？case需不需要做前后关联？关联的话并发执行如何解决？），数据准备，配置（包括环境如何分隔）。execution阶段需要考虑调用测试代码如何实现，肯定会包括你的执行机制和验证结果机制如何做能让用的人比较方便。teardown阶段就是最麻烦的地方了，牵涉到数据结果收集，展示，异常处理机制。前端的话你只要做到上面3点，再做到UI元素库的封装就行，一般的话都是用的POM。其实一般不要一个人去造这种轮子，累不说，做完了可能还不如开源项目，不如二次开发通用型测试框架。比如Robot Framework和Gauge这种。

 

版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。

     摘要: 引言：年初参与到一个后台系统开发的项目中，里面涉及了很多接口，我做为项目组测试人员，需要对这些接口进行测试，一开始使用 postman 工具测试，很是方便。但随着接口数量的增加，不光要执行手动点击测试，而且，一旦接口参数变动，都重新更改接口参数，次数多了，使得测试效率严重下降。后来我将目光转向了自动化测试，考虑到项目组对接口质量要求很高，需要快速开发。最终选定 python 作为脚本开发语言，使用...  阅读全文

对于刚刚经历过校园招聘的研三即将毕业的学生，我这边总结了面试时常被问到的几个问题，希望对即将或正在参加校园招聘的朋友们有所帮助（笑脸）。

1、微信点赞功能测试用例？

①点赞和取消点赞功能

②点赞是否按时间顺序显示

③点赞是否正确显示昵称或备注

④点赞之后是否还能评论

⑤弱网络的情况下点赞能否实时更新

⑥点赞时有短信或电话进来，能否显示点赞情况

⑦点赞的人是否在可见分组里

⑧点赞之后共同好友的点赞和评论是否会提醒你

2、APP测试需要考虑的点都有哪些？

· 性能测试：

CPU，内存，耗电量，耗流量，APP的安装和卸载和启动的耗时

· 适配兼容性：

在不同的操作系统上的安装，拉起，点击，和卸载是否正常

· 耗电量测试：

当手机冲满格电的时候能玩多久，挂机10分钟耗多少电，APP每小时耗电多少

· 中断测试：

app在前台和后台运行状态时与来电，文件下载，音乐等关键运行的交互情况测试，测试电话，短信，微博或其他通知进来是APP的反应

· 弱网络测试

3、请描述你对测试的了解，内容可以涉及测试流程，测试类型，测试方法，测试工具等

· 测试流程：

需求分析---需求评审（项目需求人员，开发人员，测试人员）--定排期（开发人员制定开发计划，测试人员定测试计划）--开发人员进行代码开发，同时测试人员编写测试用例--开发人员开发完成提交代码--测试人员showcase用例评审--运维人员部署软件测试线--测试--开发修bug--测试完成，提交测试报告--上线--线上检查--邮件抄送组内进行上线通报。

· 测试类型：

根据项目流程阶段划分：单元测试，集成测试，系统测试，验收测试

根据对代码的可见程度划分：黑盒测试，白盒测试，灰盒测试

根据是否投入大量人力划分：手工测试，自动化测试

还有冒烟测试，回归测试，随机测试

· 测试方法：

黑盒测试：边界值，等价类划分，因果图，决策表，错误推测法

白盒测试：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖

· 测试工具：

接口测试工具：jmeter，postman，robotframework

性能测试工具：Jmeter，loadrunner

UI测试：Selenium

4、为什么报测试，作为测试的优势？

是自己作为测试开发实习生的时候那种找bug的成就感，能发挥价值的满足感以及做自动化测试时一直学习充实自己的挑战感。优势是有在BAT实习经验，对测试流程和常见测试类型和方法有一定了解，有自动化测试经验。

5、谈谈你对Selenium2原理的理解？

Selenium2将浏览器原生的API封装成WebDriver API，可以直接操作浏览器页面里的元素，甚至操作浏览器本身（截屏，窗口大小，启动，关闭，安装插件，配置证书之类的），所以就像真正的用户在操作一样。

Webdriver的工作原理：

● 启动浏览器后，selenium-webdriver会将目标浏览器绑定到特定的端口，启动后的浏览器则作为webdriver的remote server。

● 客户端(也就是测试脚本)，借助ComandExecutor发送HTTP请求给sever端（通信协议：The WebDriver Wire Protocol，在HTTP request的body中，会以WebDriver Wire协议规定的JSON格式的字符串来告诉Selenium我们希望浏览器接下来做什么事情）。

● Sever端需要依赖原生的浏览器组件，转化Web Service的命令为浏览器native的调用来完成操作。

the WebDriver Wire Protocol是Selenium自己设计定义的协议，几乎可以操作浏览器做任何事情，包括打开、关闭、最大化、最小化、元素定位、元素点击、上传文件等。

WebDriver Wire协议是通用的，也就是说不管FirefoxDriver还是ChromeDriver，启动之后都会在某一个端口启动基于这套协议的Web Service。

6、负载测试和压力测试？

①负载测试是指在超负荷环境下，系统的性能

②压力测试是指在当前软硬件条件下系统所能承受的最大负荷并找出系统的瓶颈所在。

针对一个网站：性能测试：要验证打开首页到与服务器的交互完成后所耗费的时间是否在预定的时间内，如2秒；或者比如新浪网首页改版，要验证改版后的首页访问时间是否小于等于改版前的访问时间； 负载测试：要验证有多少人同时访问新浪网首页，不会发生异常（网页无法显示的情况）； 压力测试：要验证当有多少人同时访问新浪网首页，会发生异常，比如网页无法显示的情况等等。然后调查是在哪里出现了问题，进行调优。反复进行，最终达到一个既定目标；

7、JMeter性能测试主要关注哪些性能指标？

Average：平均响应时间--默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间。

Min：最小响应时间。

Max：最大响应时间。

Throughput：吞吐量，默认表示单位时间内服务器处理的请求数。

8、测试人员需要的能力？

①心理素质，任何一个测试最先面对的心理压力就是重复性的劳动。

②主观能动，必须主动去网上查找资料，主动的找人进行沟通，主动的进行实践主动进行分享。

③乐观精神，你往往面临着一个复杂的功能性产品，往往会被误解，往往会被很多人在心里看不起、会因为找不到缺陷而心情不好等等。

④沟通表达能力，描述问题，倾听问题。

⑤分析能力，如何去发现问题，如何去分析问题，如何去解决问题，如何去总结问题。这里的问题不是指测试中的缺陷。可能是一种模型的运用，可能是一种测试技术，也可能是一种人际关系等等。

9、对自己的职业规划（面试必问）

我认为这个题目每个人都有自己的见解，但如果让面试官听起来你有一个明确的计划时，我认为应该分为1-2年和3-5年计划，参照之前实习时的同事在测试知识积累，业务能力，自动化框架的建设，测试工具的使用熟练程度，测试工具的开发的参与度上等方面，在1-2年内希望自己成长为在组内有什么影响的人，在1-2年之后根据自己的现状和计划做一些改动，并在3-5年内希望自己的职业处于哪个等级。

请关注官方公众号“Atstudy网校”，回复关键词：“学习”就可以免费拿到软件测试学习资料~~

摘要：

我们希望在划分我们的测试时，我们将考虑所有的场景，但是太容易忽略不常用的用例。这就是随机测试生成器的好处。我们可能在测试几十个测试用例后感觉很舒适；这些工具能生成几百个。随着更多的东西被扔到墙上，一些有趣的东西更有可能被粘在墙上。

在第一个尝试FsCheck和基于属性的测试后，我恼火了。

Haskell编程语言已经存在一段时间了，然而我从来不用它。吸引我注意的是一个名为QuickCheck的工具和它引进的算法。因为我一直工作在.NET领域，我采选用FsCheck做研究，一个F#端口的QuickCheck。我的恼火来自于演示list集合的属性。

当我们反转一个列表，然后再反转一次，我们希望得到初始列表，对吗？在不考虑这个列表有多长或者包含什么，这个属性应该是真的。想象一下当我第一次用FsCheck测试失败时，我有多么惊讶。第一次带有整数列表的测试通过了，但是当我把它变成持有浮点型时，它失败了。

FSCheck生成随机值填入列表，然后检查属性是否被测试持有。它做了很多很多次测试，为了查找失败的值的组合。在整数的用例中，它不仅仅是我们首先考虑到的1、2、3……，还有会被存储成固定浮点整数、零和负数的最大和最小整数值。我们也需要考虑空列表。FsCheck所有这些都做了。为什么当我考虑浮点数时，它失败了？

解释来自于对浮点值的定义。他们采用一种位的模式，并将该模式解释为一个带有小数点的数字。无论如何，并不是所有可能的比特组合都可以用这种方式进行有意义的解释。我们把这些麻烦的模式NaN定义为：不是一个数。令我惊讶的是，NaN变量可以是逐位相同的，但不相等。让他们明白这一点。这似乎合情合理，但却有违直觉——而且很容易被忽视。

我们希望在设计测试的时候，考虑所有这样的病态情况，但是很容易忽略像NaN这样的东西。这就是像FsCheck这样的随机测试生成器的好处。我们在测试几十个测试用例后可能感觉很舒服。FsCheck生成几百个。随着更多的东西被扔到墙上，一些有趣的东西更有可能粘在墙上。

在FsCheck发现故障之后，它将采取第二步:它试图减少引发问题所需的数据量。我不详细讨论这第二步，因为我的观点是，看到像我刚才用NaN描述的那样的错误有助于我们更深入地思考代码库在做什么——尤其是在将它的测试缩减到最小的形式之后。

在浮点值列表的情况下，我们可能认为NaN业务是假的。我们这样做甚至可能是正确的。但是运行测试的目的是让我们考虑代码库。也许我们应该在系统的边缘添加一些东西来使NaN值出现在系统之外，或者我们应该确保NaN不能从系统内部的任何转换中产生。

我们的代码有缺陷，因为我们对它的思考存在盲点。即使是世界上最大的自动测试用例生成器也会有盲点。令人高兴的是，机器和人类有不同的盲点。

像FsCheck或QuickCheck这样的工具利用了一种不同的测试范例，利用机器的优势来弥补我们的不足。机器可以通过算法制定出大量的测试数据集，这些数据集手工组装起来既昂贵又枯燥。但是他们需要基于属性的测试来消耗所有的数据。

当我还是一名新程序员时，我并不欣赏这一点。我正在研究一个统计应用程序，它严重依赖于贝叶斯统计和概率。有一些事情你可以依靠条件概率。首先，概率总是在0到1之间。另一方面，当我们总结所有条件时，我们应该得到一个。无论我们在代码中添加什么，这些属性是我们可以自动检查的。

同样，我最近与一些朋友进行了一次对话，他们正在构建一个计费系统。我问了一些问题:所有的项目都是正数的吗?我们是否知道许多行项目的小计将超过更少项目的小计?在不考虑求和顺序的情况下，总数是否会发生变化?我问，还有哪些属性是不变的，我们可以断言。每个这样的不变量都可以作为基于属性的测试的基础。跟你打赌，我肯定会给这个系统一些负的价格。

广泛的属性测试可以教会我们很多关于代码库的知识。测试从不确定代码库是无错误的，但是测试确实缩小了错误可以隐藏的范围。为了学得更多，我们必须理解测试的作用和它们所显示的内容。这可能意味着我们应该更多地关注理解我们的测试，而不是仅仅增加少量理解的测试的乘法。就像FsCheck将大型失败测试简化为更简单的表单一样，我们也应该定期检查我们的测试套件。

是否每个测试告诉我们的不仅仅是重现过去几年bug报告的环境?这些测试是否可以重新组织以阐明我们为什么关心它们?我们的目标应该是策划测试，以最大限度地从每个测试的成功或失败中得到理解。

当我对浮点的基于属性的测试失败时，NaN让我感到惊讶。这并不是由于列表倒转的故障;它失败的原因是测试中固有的关于如何比较浮点数的假设。这提醒我们寻找与我们的假设相矛盾的数据。我们在测试中加入的惊喜越多，我们的系统就会变得越健壮。这需要结合多种不同的范例和功能来利用每种范例和功能的优势。

被NaN吓到似乎是个坏消息。它让我们陷入了一个失败的测试，这个测试只与我们正在测试的代码间接相关。但是这样做会让我们想起一些我们可能已经忘记的软件。这样的提醒会把惊喜变成好消息。

欢迎加入 51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】... 51与你共同学习，一起成长！期待你的加入： QQ                     群：                    755431660

从步入测试领域开始，无论哪个公司，哪个团队都在谈论自动化测试、动手实现自动化测试，从而让测试显得更加“高大上”。那么是不是所有的业务都适合自动化？是不是自动化做的越多，效果越好呢？下面就自己一些经验和感悟，聊聊自己的一些体会。

我一直以来获得了太多关于何时实现测试自动化、以及如何实现测试自动化方面的问题。不再一一针对每个人的问题来回答，这里针对这些问题一些讨论吧。

下面我将就何时自动化，如何自动化，是否应该自动化谈一谈自己的看法。

我知道一些读者比我要聪明。因此，对这样一个大的主题进行的讨论是值得的，以便从不同领域的专家那里获得深入的想法和思考，以及他们在自动化测试方面的经验。

二、为什么自动化测试?

1) 在测试时，你进行了新的部署、bug修复，这是你如何保证新bug没有被引入老功能？你需要测试之前的功能。

因而，每当有bug修复，或新功能添加时，你都要手工测试所有功能？考虑到花费、资源、时间等等因素，你这么测试不是高效的。

因而自动化有了需求：

当你有太多回归测试工作要做时，请自动化你的测试工作

2) 当你正在测试一款web应用时，与此同时，这个应用可能有数千用户正在使用。

你将如何测试这样的web应用？你将如何使用手工方式，同时模拟这些多的用户呢？这是一件十分困难的手工操作。

模拟众多虚拟用户，来测试应用的负载容量时，请将你的负载测试自动化

3) 你正在测试一款代码被频繁修改的应用，虽然GUI几乎一样，但功能变动越多，需要的测试“维修”就越多。

当你的GUI几乎不变，功能频繁发生变化时，请将你的测试工作自动化。

三、关于自动化测试，有哪些风险?

在一些不同的情况下，你可以考虑自动化测试工作。这里我介绍自动化测试的一些风险。如果你已经下定决心要做自动化或者想要更早地采取措施，那么请先考虑以下问题。

1) 你能找到有经验的人力吗?

想要自动化，你需要有一些编程经验的人员。

考虑一下你的人力资源。他们有足够的自动化测试经验吗？如果没有，他们有技术能力或编程背景来轻松应对新技术吗？你打算投资建立一个好的自动化团队吗？如果你的答案是肯定的，那么考虑自动化你的工作吧。

2) 自动化的初始成本非常高

我赞同这个观点：由于要雇用熟练的手动测试人员，因而手动测试的相关成本很高。但如果你正在考虑将自动化作为方案，请三思而后行。

自动化的初始新建成本太高，例如：自动化工具的购买，测试脚本的培训和维护。

很多自动化工具用户都会后悔做自动化。如果你花费了很高的成本，却只得到了一些好看的测试工具和一些基本的自动化脚本，那么自动化的用途是什么？

3) 如果UI不是一成不变的，不要试图自动化

自动化测试用户界面前务，请必要小心。如果用户界面正在大范围发送变化，那么自动化脚本的维护成本将会非常高。在这种情况下，基本的UI自动化就足够了。

4) 你的应用是否足够稳定，可以支持你的自动化测试工作?

在早期的开发周期中自动化测试工作将是一个坏主意（除非它处在一个敏捷的环境）。 在这种情况下，脚本的维护成本将非常高。

5) 你正在考虑100%自动化?

别异想天开了，你不可能100%将测试工作自动化。当然，有一些领域，如性能测试，回归测试，负载/压力测试，你可以有机会达到接近100％的自动化。但用户界面，文档，安装，兼容性和恢复等领域，必须手动完成测试。

6) 不要自动化只执行一次的测试任务

某些识别应用领域和测试用例，可能只需要运行一次，并且不需要包含在回归测试中。避免自动化此类模块或测试用例。

7) 你的自动化套件会长期使用吗?

每个自动化脚本套件都应该有足够长的使用寿命，其新建成本应该绝对低于手动执行成本。然而分析每个自动化脚本套件的有效成本有点困难。

对于单独的构建（一般假设，取决于具体的应用程序的复杂性），大约应该使用或运行至少15到20次自动化套件，才能获得良好的ROI。

四、总结

自动化测试是实现大多数测试目标和有效利用资源和时间的最佳方式。但在选择自动化工具之前，你应该谨慎。在决定自动化测试工作之前，请确保有熟练的人力。否则，您的工具只是一个空架子，无法获得ROI。

将昂贵的自动化工具交给非技术人员会带来失望。在购买自动化工具之前，请确保该工具最适合你的要求。你不太可能拥有与你的要求100％匹配的工具。

你需要找出最符合你要求的工具的局限性，然后使用手动测试来克服这些测试工具的限制性。开源工具也是开始自动化的好选择。

不是100％依赖于手动或自动化，而是要使用手动测试和自动化测试的最佳组合。这是每个项目的最佳解决方案（我认为）。自动化套件不会找到所有的错误，也不能替代真正的测试人员。在许多情况下，随机测试也是必要的。
欢迎加入 51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】... 51与你共同学习，一起成长！期待你的加入： QQ                     群：                    755431660

对，你没有读错。是叫能力表达，不是表达能力。我们大多数测试工程师或从事IT行业领域的技术人才，有很多都是技能OK，但是说到如何进行自身能力的表达，不是有些内敛，就是不知道从何“说”起？尤其是自我介绍、项目经验、工作经验、职业技能等到底在具备了相应的工作能力后，应该如何表达清楚？如何表达才能凸显自己的能力优势？这是困扰很多IT人才的普遍问题。

而关于表达自身技能又是我们平时工作尤其是面试时必不可少的重要事项，所以此次想针对如何提升“能力表达”和大家进行分享、交流以及实践，通过具体可行的方法，让我们每一位IT人才的“能力表达”能够与日增长！课程分为多个不同的主题进行交流分享，此次交流分享的内容如下：

1、问题出在何处？

1)经常会遇到技术工作已经能做了，或者做了一段时间了。但是一遇到要说，就有各种各样的尴尬：不会说，不敢说，说不清楚.....

2)我们的技术能力和工作能力可以通过工作成果物来证明和验证，那我们的能力表达又该通过何种“成果物”进行证明和验证呢？

3)影响我们能力表达的要素有哪些？有针对性的可行的方法可以快速提升吗？

2、如何提升“能力表达”

1)以自我介绍为背景，逐一说明如何进行能力表达

2)具体以“接口测试能力”为背景进行实训。前提：以具备接口测试全流程能力

3、“自我介绍”训练窍诀

不仅测试脚本的研发可以分版本进行，我们对于“能力表达”的训练也依据可以分为不同的版本，此次的自我介绍的案例以“接口测试能力”为背景进行试训。

1)V1.0版本的自我介绍

2)V2.0版本的自我介绍

3)V3.0版本的自我介绍

在过去的几十年里，软件测试已经根据用于执行不同活动的工具和使用这些工具的人的心态发生了变化。那时用于软件测试的工具很少，但是现在我们有很多的工具可以选择，从专有的到开源的。同样地，人们开始把软件测试者当作信息代理者而不是看门人，并且在敏捷的世界中已经出现很多积极的开发团队，这些开发对团队在软件开发生命周期中遵循的流程进行了重要的更改。技术的进步要感谢这些进化。

从我们看待软件、评估风险、考虑复杂性、设计我们的测试方法和策略，以及帮助向用户发布一个稳定的产品的方式来看，技术确实对我们测试软件的方式产生了影响，并且这种影响将只会随着技术的进步而继续。在高层次上，我们已经看到将决定软件测试未来的5件重要事情。

1．人工智能

大约5年前，每个人都在谈论“移动优先”，并为用户提供使用手机网页、本机和混合应用程序的移动体验。现在，新的流行词是人工智能。它在自动驾驶汽车、家庭助理（人们当然喜欢Alexa）、计算机视觉、健康保健、金融，以及现在的软件测试领域都有使用。

现在，在市场上很少有可靠的工具使用机器学习来帮助编写程序和执行功能测试、端到端测试和回归测试。它们主要集中在基于用户界面的测试自动化——用户创造的测试越多，算法变得越智能，这使得测试更稳定。

幸亏有人工智能，有一些我们可以期望开始看到的在测试中的好处：

更容易编写测试代码

降低测试脚本的维护工作

减少片状测试

使非技术人们开始进行自动化

更容易集成CI/CD

更多可复用测试

举个例子，我用Cucumber、 Java和Appium构建了一个自动化框架。虽然我有一个健壮的框架，并且在编写自定义代码来执行各种操作时具有很大的灵活性，但我经常遇到维护方面的常见问题。当开发人员更改我的自动化测试已经覆盖的元素的属性时，测试开始失败。结果，我花了很多时间来维护这些测试，而不是编写新的自动化代码来覆盖实现的新功能。

这个问题现在可以通过使用人工智能从文档对象模型提取的动态定位器来解决。在实时的情况下，人工智能分析会分析DOM中的所有对象树和属性，并为特定元素创建不同属性的列表。因此，当一个元素的属性变化时，人工智能会尝试进入列表中的下一个属性来定位该元素，并一直遍历列表，直到找到该元素为止。这种测试更加稳定，测试程序的编写和执行速度会快得多，而且测试者在维护上花的时间会更少。

2．开发运营

开发运行帮助软件开发团队和运营团队更好地协作，从而确保在整个软件开发生命周期(SDLC)中有持续的自动化和监视，包括基础设施管理。

您可能会问，这将如何影响软件测试？答案是：作为测试的一部分，我们所做的一切都会改变。我预计的变化包括：

需要在软件开发生命周期的开始时就启动自动化，并且确保几乎所有的测试用例都是自动化的

所有的质量保障工作都需要对齐，以确保CI/CD周期的顺利进行

需要高水平的协作，以确保在生产环境有持续的监控

所有的QA环境都需要被标准化

测试思维从“在此模块上完成测试”转变为“在发布候选版本中已经减轻了哪些业务风险？”

以上所有变化的关键是自动化。开发运营和自动化手携手并进——缺少其一，另一个将无法工作。这就是聪明的人类和工具能帮助缩短和更可靠的发布周期的地方。

我曾在一家公司工作，那里的开发、测试、运营团队之间的协作很少。我们在软件开发生命周期里发现了很多缺陷，比如更多的bug进入生产环境，不稳定的CI/CD基础设施，以及对生产监控和统计的不可见性。注意到这些差距，团队决定实施开发运营实践，每个人都开始在软件开发生命周期的每个阶段进行协作和贡献。这从需求收集开始，一直扩展到产品发布和监控上。

这种增强的协作文化开始对团队士气产生积极影响，更多自动化开始产生，整个团队开始作为一个单元一起工作。

3．质量保证即服务

就像我们有软件即服务、基础设施即服务、平台即服务一样，我们现在也有质量保障即服务。在过去的几年里，这已经成为公司满足软件测试需求的一种流行方式。

拥有质量保障即服务解决方案的公司可以通过以下方式使软件测试过程的不同方面变得更简单：

测试用例管理和维护解决方案

测试自动化工具，减少编码需求

强大的测试报告功能，包括日志、视频录制和屏幕截图

易于与CI系统集成

在过去7年做自动化的过程中，像手机、虚拟机、安全网络和测试人员等资源里，我经常遇到的一个大问题是，必须维护自己的服务器来运行自动化测试。服务器的机器有不同的问题，如存储空间，一个片状的互联网连接，处理速度慢的测试正在运行持续整个星期，和需要频繁更新的最新操作系统，构建工具，安全补丁、集成开发环境等等。这些问题可以通过质量保障即服务的提供商解决，因为他们可以为您完成所有这些活动，因此团队成员可以将精力集中在更关键的任务上。

将来，质量保障即服务的供应商将考虑更多的方法来改进他们的产品，以保持领先于他们的竞争对手，这也将使软件测试人员受益。

4．物联网

随着可穿戴设备、智能家居、联网汽车和其他基于云技术的出现，物联网已经开始成为一个大的讨论的主题。这些设备的惊人之处在于，每秒钟都有如此多的通信和集成发生。

让我们来分析一下，在高水平上，可穿戴健身追踪器发生不同通信。首先，手机app和健身追踪器需要相互沟通。你的移动应用程序捕获的数据与该应用程序的桌面、移动web和平板电脑版本无缝集成，所有这些跨设备的通信都应该实时发生。所有的数据都在云、设备和应用程序之间来回传输。人们还可以通过应用程序组成小组，互相竞争，所以这些计算和通信也需要实时进行。根据触发的不同事件，需要在正确的时间向正确的用户发送正确的通知。所有这些通信都发生在互联网上。

假设您是测试这个健身跟踪器的测试人员。从哪里开始呢？您将如何设计您的测试策略和方法？

物联网将其自身的复杂性引入软件测试。它将影响我们对测试的看法，特别是因为集成测试需要比单独测试每个组件的旧方法给予更多的关注。

举个例子，当我在一家旅游预订公司工作时，我们为Apple Watch开发了一款新的应用程序，它使用的是WatchOS (Apple Watch最初由Apple推出)。该应用程序具有有限但有用的功能，比如查看通知和奖励信息、预定以及定位酒店、航班和租车位置的能力。在测试这个应用程序时，我注意到当Apple Watch应用程序连接到我手机上的同一个应用程序时，出现了一些奇怪的问题:当我将手机上的应用程序最小化时，Apple Watch一片空白，只有一个黑屏;但当我再次在手机上打开应用程序时，黑屏消失了，Apple Watch应用程序运行正常。

这是一个很好的例子，说明了集成测试的重要性。随着越来越多的设备进入市场，这对于组织和用户来说将是至关重要的。

5．机器人

现在有做测试的机器人。有些人可能认为这是可怕的工作保障，但我仍然相信，人类的思想是无法取代的。仍然需要人类来监控机器人，以确保它们在做人们期望它们做的事情，并为它们编写程序。这种可扩展性有多强？只有时间才能证明。

总之，技术的进步已经开始影响我们进行软件测试的方式。这也导致公司重新思考他们的组织结构：QA团队正在向嵌入开发团队的方向发展，并且整个团队将拥有质量。研究和开发团队与开发团队的频繁互动也将变得非常重要，以使产品更智能，对客户更有用。

还需要有处理大量数据的程序，以及适当的计算能力来梳理这些数据以获得有用的信息和反馈。最后，为了使这一切成为现实，公司需要采用精益流程，并且更加透明，以防止成为创新的一个障碍。精益转型对有效增长至关重要。

重要的是改变我们看待系统的思维方式，并相应地进行测试。我们可以选择忽略它，也可以选择接受它。你将会怎么做？

欢迎加入 51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】... 51与你共同学习，一起成长！期待你的加入： QQ                     群：                    755431660

一、 开发和测试的通性困扰？

面对复杂性（客户）：不断地修改计划、不断地增加预算、低劣的产品质量……

面对复杂性（项目组成员）：经常加班到深夜、提交的产品不合格……

二、敏捷开发中的敏捷测试目的：

敏捷宣言

个体和交互比过程和工具更有价值；能工作的软件比全面的文档更有价值；顾客的协作比合同谈判更有价值；及时响应变更比遵循计划更有价值。其核心是:以人为本,发挥人的主观能动性.

三、传统测试和华为敏捷测试区分：

3.1 、传统的测试

1.守门员:质量保证者，阻止那些不可靠的、无效的、充满 BUG 的版本发布。

2.信息提供者:提供大量积极的、关于项目开发的状态的信息。告诉大家哪些功能正常工作、哪些功能不能正常工作、哪些 BUG 必须处理。

3.2 、 华为敏捷测试

测试和开发的角色界线变得模糊。有些人主要做测试工作，有些人主要做开发工作，但是在快速推进的过程中，所有人都会被号召起来测试或支持测试的工作。更多职责:帮助开发人员理解需求,尽早确定测试规范。

3.3 、 敏捷测试中测试人员扮演的角色

1.测试是项目的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。

2.测试为项目组提供信息，使得项目组基于可靠的信息作出正确的决定。

3.测试人员不作出项目发布的决定。

4.测试员不保证质量，整个项目组对质量负责。

5.测试不是抓虫子的游戏，它的目的不是纠缠在错误中，而是帮助找到目标。

四 、 敏捷测试用例的设计和评审要素：

4.1 、 基于需求的用例场景来设计测试用例：

1.基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。

2.把测试用例当成“活”的文档,因为需求是“活”的、善变的。因此在设计测试用例方面应该符合敏捷的“及时响应变更比遵循计划更有价值”这一原则。

3.测试用例的设计不是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。

4.2 、 敏捷测试用例设计原则

通常我们所看到的测试用例的设计是其中一项。

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像银行取款机系统中工作指令系统界面一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。

测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。

4.3 、 敏捷中测试用例评审：

1．同行评审是最敏捷的检查测试用例的方式，它主要强调测试用例设计者之间的思想碰撞、互补，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例，从而体现敏捷的“个体和交互比过程和工具更有价值”。

2．除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。

备注：这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。

五、 华为常用敏捷的测试方法和测试流程：

1．进行敏捷测试主要分以下几个步骤：

敏捷测试采用的功能测试方法是我们常用的基本的测试方法，例如：

等价类划分、

边界值分析法、

错误推测法……

2．敏捷测试和传统测试不同的是：

需要高度的迭代工作、

频繁得到客户的反馈，

需要动态调整测试计划、

测试的执行。

3．敏捷测试过程中性能测试方法和考虑：

性能测试的方法？

性能测试、负载测试、压力测试、配置测试、并发测试

性能测试：通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。

负载测试：通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资料使用已经达到饱和状态。

配置测试：通过对被测系统的软/硬 件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。

压力测试：测试系统在一定的饱和状态下，例如 CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。

并发测试：通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。

六 、 与您共勉

最后送大家一句话，兵无常势，水无常形，能因敌变化而取胜者谓之神，相信在测试的过程程中只有找对了方法，不管是传统的测试还是现当今国外比较流程的敏捷测试，只要应用得当就是好的测试。

欢迎加入 51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】... 51与你共同学习，一起成长！期待你的加入： QQ                     群：                    755431660

走进海外测试开发工程师的生活!测试开发、自动化、测试流程等！

1、能不能介绍一下国外的工作模式和方法 国外测试的关注是在哪方面？

我不清楚国内的工作模式，但我觉得类似。

对于工作流程来说：

每天都会有scurm meeting（我们组是下午meeting，别的公司是在上午），简单讲自己的工作进程，有没有地方不会做，或是遇到问题需要帮助，有些时候会唠嗑。

每周五有mini demo，就是给老板和老板的老板展示工作进程，然后得到这些大佬的反馈。

每月都有sprint demo，就是给老板和老板的老板展示工作进程，然后之后发布。

对于测试人员来说：

月初的工作，将上个月的自动化代码完成（或是其他tech debt没做完的做完）。

月中的工作，写测试计划，案例，步骤和测试环境的部署和数据的准备，然后进行手工测试

月末的工作，主要就是自动化测试案例，并且将自动化代码加入CI 和 CD中。

对于国外关注的是什么的问题，我觉得国外小公司和国内小公司一样，大公司和大公司一样，基本没啥区别：

小公司基本上对于测试要求很不严格，自测，或是tech lead测，开发人员自己写自动化测试。

大公司对测试要求极其严格，（由于产品和业务非常值钱），所以不仅要开发人员自测，写unit test，还要有测试人员对产品进行各种测试regression test， performance test 以及 intergration test等等，以及自动化测试。

国外对于测试是非常注重的，只要测试不通过，事情再紧急也不能发布。

2、请问“测试知识库”的建立指的是公司内部学习知识网吗？

没有错，测试知识库是一个系统的，可参考，可规范的测试知识库和标准，包含但不限于以下内容：

测试分类/名词解释

bug分级/分类

手动化测试流程 自动化测试流程

开bug的方法，应该给谁解决

如何写测试计划/测试案例/测试流程

标准化的测试流程

测试框架的使用方法

测试工具的使用方法

一些有用的测试链接等

3、什么样的自动化测试框架才能最大限度的减少脚本的维护？

这个问题我不太清楚想问的是自制一个测试框架，然后使用的时候脚本不用频繁的更新，还是使用一个测试框架，然后让自己的自动化测试脚本尽可能少的维护。

如果你问的是自制测试框架：

如果是高素质的测试开发团队，完全可以自制测试框架；

如果不是高素质的，最好是用现有的开源测试框架；

当然了，最保险的方式就是对当前最成熟的框架进行深度的定制化；

如果你问的是测试脚本，这个问题将会很复杂一发而动全身，因为频繁修改测试脚本意味着开发流程和规范可能有问题，管理不当，测试人员水平不高。

全体人员：必须要达成共识，交流通畅且有效

开发人员：必须要对开发语言进行规范化，不能乱起名，比如说class 和 ID 就最好是不要频繁的更改，不要给variable和method乱起名，使用swagger这样的描述性语言

测试人员：测试代码一定要可配置，可自定义，可读，无hard code

管理人员：一定要促使工作人员合作和交流

4、如何能让组内的工作效率得到明显的提升，有哪些具体的措施和方法呢？

根据当代女性哲学家Marth Nussbaum的Creating Capabilities的理论：整体的生产力是由个人的生产力的整合，而提高整体生产力的方式是提高个人能力。

我相信这句话已经告诉你答案~

5、想请教下，个人的成长达到一个瓶颈了，不知道怎么突破怎么办？我是自学的，目前除了开发经验，测试基本，工具之类的还是理解了很多，想请您给我一些指引。

个人瓶颈的发生时基本上就是机遇和能力其中之一不足导致的。

当你觉得你学的足够多的时候，却受限于瓶颈的时候，往往就是自我感觉良好，但是技术不足的时候；就像我，我不会觉得我的知识有多么丰富，技术有多好，反而知识越学越多，边觉得不懂的就越多吧。

我看你问题中说了，你自学了一些东西，估计很说你学的知识体系化和结构化，知识还是那些知识，但是没有被你内化。如果我是你，我会进行系统化的学习，我相信会有一些成果。

（有了技术，但是没有机会展现也觉得像是遇到的瓶颈，这就需要伯乐来发掘你，让你的能量能够得以释放。）期待你的进步！

6、自动化测试用的是哪些测试工具？

常规UI 测试主要是Selenium

框架的UI测试主要是取决于前端框架

接口测试会用自制的接口测试框架

以上是自动化测试的基础

等等……

7、UI WEB测试真的是个高投入低产出吗，值不值得做？

是的，因为前端页面改变太快了；有多余测试力量就值得做，没有的话就算了。

8、设计和架构网站性能检测、监控和报警平台，如何做的？

检测部分：将网站加载和渲染速度（包括点击按钮）和网络情况（数据很像Chrome的Performances）

监控部分：使用时面板的框架，用来展示数据的；每次merge to master branch的时候，进行全方位的测试统计，更新数据并展示

报警部分：数据spike时，自动发送slack和Email

9、可以根据swagger自动化生成自动化接口测试的框架(Rest Test Code Generator)，如何操作？

Swagger 本身就是一个非常规范的JSON，包括了所有可Rest call的option，即测试方法都已经在上面了；并且Rest call返回的格式也写好了，即测试结果也在上面。

基于以上完美的测试方法和测试结果，一个完美的自动化接口测试框架就形成了。

10、关于优化测试流程，能举几个简单的案例嘛 测试流程的瓶颈在哪 如何优化 优化后的效果又是什么样的？

关于优化细节：

优化的都是本组的测试流程的小细节，比如说程序员要参与测试计划的制定等等，太多太杂很难讲清楚。

关于瓶颈：

测试流程的瓶颈就是团队内的个人能力和团队间的合作能力，如果两者都很强，那么什么测试流程都不需要。

而优化测试流程的瓶颈就是你在团队中影响力和能力，没能力没影响力，你优化不了流程的。

关于如何优化：

着重于最耗时的地方进行优化，这个最耗时的地方，是可以通过技术优化手段省时，或是通过使用技术优化效果大于改变人的习惯的效果（通过流程修改或是培训），那么就使用技术手段（比如说写自动化程序、框架、工具、平台）。

这个最耗时的地方，只能通过改变人的习惯（通过流程修改或是培训）才能节省时间，那么就修改流程（比如说优化流程，创造流程）。

11、互联网小公司应该如何规范软件测试流程，才能应付频繁的迭代？

首先不推荐TDD或是其他复杂的开发或测试流程，因为小公司往往不足以支撑。

你们团队的人员组成是什么测试的现状：

是开发者同时负责测试，还是有一两个测试人员；

是你们能不能实现一定条件的测试自动化，还是只能完成手动测试；

建议使用TPDD；

大概的核心思想为：由开发人员与测试人员紧密合作以及管理人员的参与下，在开发周期的初期迅速的制作测试计划，然后测试人员和开发人员同时进行测试和开发的工作。

他适用的对象为：

不喜欢怎么 TDD 开发模式的开发者，和相关的团队和企业；

没有严格要求按照 TDD，然而对外声称使用 TDD 开发模式的开发者，和相关团队和企业；

执行了 TDD 这种开发模式，然而质量没有明显的提高的团队和企业；

使用 TDD 导致开发效率降低的团队和企业；

开发者不喜欢 TDD 这种开发模式，嫌麻烦，但是还想要保证代码质量的团队或企业；

开发者没有足够的能力进行 TDD 的团队和企业；

产品的截止日期很紧张的企业 （你们适合使用TPDD）；

初创团队和企业；

正在上升期的团队和企业；

还没有应用 TDD 这种开发模式，但是准备使用 TDD 的团队或企业；

12、本人做软件开发2年了，现在突然想转测试行业，测试行业，特别测试开发近年来很火爆，本人喜欢玩游戏，想往游戏测试发展，想请问下游戏行业中是如何进行功能测试的，跟普通软件业也是基本类似吗？

问题2是如何开展性能测试，听说能用LR，那使用什么协议，脚本是录制的还是编写的，一般的性能指标是什么？

支持转业，也支持你的梦想。

游戏测试问题回答：游戏由于他的独特性，测试的重点也跟其他测试略有不同，但是有些是一样的：

Unit Test还是会有的，举一个Unity的例子，C#和JS都需要单元测试；

手动测试，游戏初期有你想象不到多的低级或是高级错误，比你现在玩的游戏的bug多得多，非常无趣；

单一手动测试，让你不断的点击测试，看看会出什么问题，看看有什么游戏逻辑是不是对的；

自动化测试，一般情况游戏都有自己的测试框架，自动化操作；

平衡测试，这个就是最最特殊的测试，要记录很多数据，牵扯到很多统计学的东西；

AB测试，实际的产品发布前的测试；

剧本对照，就是有些大型的RPG有对话，需要检查；

内测、公测需要对这些用户上传的反馈，进行筛选并且总结给开发人员，让他们进行修改（自动反馈和手动反馈），暂时想不到别的了。

性能测试问题回答：

LR主要是录制的测试，模拟的Rest call（HTTP），主要是并发性的测试，服务器是否可以handle，网站的性能测试就是渲染速度和效率，接口的速度。

PS：游戏测试并不是你所想的玩玩游戏就可以了，可能会让你玩游戏玩到“吐”，转行需谨慎

13、我在公司里面使用jmeter工具进行自动化接口测试，偶尔结合swagger进行配合（还在研究，不是很懂），有这次项目比较紧急，又是异地开发，感觉与开发沟通成本挺大的，想知道如何解决这样的困境。技术上，jmeter的自动化测试脚本在项目的不同模块的复用性不是很高，也在很努力的想做成通用性的脚本，同时会担心使用jmeter会不会让自己的测试的技术下降（也许可能是自己对核心的思想不太了解），本人现只会java和C，求老师给点建议。

沟通问题：

最好的方式就是尝试与他做朋友，多聊一些别的，这样的话他说不定会愿意多于你交流和沟通；

最巧的方式是多用话术，用最少的话表达最多的意思，引导他多说一些细节；

最稳当的方式是多看他写的代码，了解他的想法和逻辑，多看一下他写的文档或是需求文档，然后多多看书学习知识。

使用工具的问题：

使用工具的熟练度不就是测试的技术嘛。

未来提升的问题：

根据你说的你近期在处理大数据的东西，那么就可以多了解一下大数据的知识，了解和学习更加深层次的知识，比如说Jmeter的核心原理，大数据的核心原理，这样的话，测试更加得心应手。另外，可以学习一些python的东西。

欢迎加入  51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】... 51与你共同学习，一起成长！期待你的加入： QQ                     群：                    755431660