在App的整个测试环节中，性能测试是很重要的，它直接影响到用户的体验，那么，对于App的性能测试，我们到底需要关注哪些点呢？又该如何来测试呢？今天小编有幸采访到了测试专家唐勇老师，请他和大家分享一下如何更好地对App进行性能测试。
您好唐老师！很荣幸今天能与您进行一次深入的交流，在开始之前，您能简单介绍一下您从事软件测试的工作经历吗？
我从事软件测试有10年了，之前的工作经历并没有涉及到软件测试这一行，是后来公司内部调职做测试的。领导觉得我做事细心，比较适合做测试。在调去测试岗位后还算做得不错，自己比较喜欢钻研一些技术方面的东西，转到测试岗位后快速上手，并在性能测试方面有突出表现，2年后升为测试组长，再到副经理、经理，负责整个测试团队的管理。
那您当初刚转测试的时候，您是怎么学习测试的呢？有没有什么经验给大家分享一下？
最开始，主要还是跟着有经验的人学习，后来发现有些问题他们也搞不定的时候就自己上网找，在07年4月，当时转测试岗位半年左右，注册了51testing账号，在上面学习，遇到问题就到上面问，寻求别人的帮助，在这儿也感谢51testing提供这么好的一个测试交流平台，感谢曾经给予帮助的前辈们！
今天借这个机会想和您聊一下App测试，目前App测试越来越多，您能说一下针对一个新的App，测试人员该如何进行测试呢？
对一个App进行测试，主要包括功能测试、客户端服务器性能测试、适配兼容测试以及安全测试等。个人对App功能测试方面实际参与并不多，从团队多年积累下来的经验看：
功能方面：App测试与传统的PC端测试并没有太大的差异，差异主要集中在手机端特有的一些特性及网络相关的处理方面。
性能方面：从实际项目经验来看，用户更注重性能方面的体验。
App性能测试分客户端和服务端，为什么要这样分呢，其实我们要先了解App的架构，一般原生态的App，当用户请求App的某个页面时，App会向服务器发送请求，服务端返回请求数据（一般是json数据），App再将数据与模板合并渲染出页面，展示给用户。（这个过程其实和浏览器本身差不多，只是我们在测试通过浏览器访问的应用性能时，并不关心浏览器本身的性能，因为这个由浏览器厂家完成了）。服务端的性能可以通过接口或者web网页模拟用户输入进行测试，和普通的PC端性能测试方法一样；客户端性能需要借助一些专门的工具来测试，App性能的关注点主要有耗电量、流量占用、启动退出耗时、响应时延、流畅度、cpu内存等。
前面我们已经提到性能分服务端和客户端性能，客户端这里就不详细讲了，说下服务端性能部分。
1、首先我们要清楚对服务端的请求有哪些。
2、请求的压力分布是怎么样的，不同的请求并发量是怎么样的。
分析对服务端的请求有哪些，这个可以通过一些辅助工具来实现，例如charles、fiddler，这2个工具比较常用，都是通过设置代理的模式来抓取请求，另外也可以直接使用压力测试工具的录制功能，例如Loadrunner，Loadrunner也可以通过设置代理来抓取请求包，生成脚本。
压力分布这块，如果要做得比较细，需要从业务用户的使用分布和对应的接口请求来分析取得，简单一些的做法是直接通过分析后端服务器的Accesslog来得到（当然分析accesslog的方式对于有流程的操作可能会失效），我们一般通过请求量的分析，得到并发数和压力数的目标，然后使用压力测试工具，来模拟并发请求，测试接口的响应时间及服务端的各种性能指标，能支持的并发数等，从而看出接口的性能。
做好上面两部分，就可以通过压力测试工具来模拟了，这块与传统的Web性能测试没什么区别。
那么，通常什么样的结果才能体现接口性能不好，能简单举个例子吗？
接口性能不好，一般是指达不到预期结果。一般来讲，我们会通过这样的方式去判断：
1个页面一般3-5秒内用户体验较好，假如这个页面如果调用了10个接口，那么单个接口的响应时间要控制在0.5秒以内。响应时间是一个指标，但另一个并发数是很重要的，响应快了，支持不了那么并发数也是不行的，要兼顾响应和并发。其实做性能的时候不仅仅是看是否满足需求，很多时候是调优。
刚才您提到压力测试工具，为什么进行压力测试，通常使用什么压力测试工具呢？
App的压力测试其实就是对应用承受能力的测试，当App上线后，会和Web一样有很多用户访问，像京东618，天猫618，就会有大量的用户访问，这就需要对App后端的服务器进行压力测试，否则的话过多的访问量，会导致系统崩溃的.而App的压力测试和Web产品一样，主要是通过HTTP请求对后端服务加压，观察后端服务的系统指标和日志，看看是否能撑住大流量。通常，一个产品上线以前，如果预期会有很大用户量，一定要做后端压力测试。后端的问题通常反映了程序框架的问题，一般如果做了一次完整的压力测试、解决了性能问题以后，后续就不用太频繁地做后端压力测试。不过也要看应用的量级，对于上亿用户的量级，如果应用架构复杂的，那还是每个版本都做一下后端压力测试比较保险。
压力测试工具，主要还是Loadrunner了，Loadrunner比较易用，并且现在也是50用户并发免费；如果是大并发的测试Loadrunner可能不行，因为Loadrunner对客户端的资源要求还是挺高的，有时我们会用Apache ab 、Siege等一些小工具。
App测试内容也是相当复杂，您认为在做App测试中，大家认为难点在哪里？又该如何解决这些问题呢？
我个人觉得，难点有两个：
1、兼容性
2、App版本很多
对于兼容性，特别是Android平台，机型太多了，OS版本也很多，这也是iOS和Android的主要区别。兼容性没有太好的办法，最笨的方法就是机型都拿来测试下，然后根据测试情况分析哪些地方容易出问题，后面通过经验来减少不必要的测试，现在有些云平台提供各种机型来跑兼容性测试，可以做最基本的安装、卸载之类的测试，手机的机型很多，并不是测试越多越好，测试覆盖越高成本越高，要看这样做是否有这个价值。
对于版本很多，后端经常变动， 如何保证不影响App各个版本的功能。就需要做接口的自动化测试，以自动化测试来覆盖，每次变更都对接口跑一次自动化测试。
您现在有自己的测试团队，职业发展中也是相当不错的。对于测试人员，该如何更好的规划自己的职业发展？
当你负责的东西越多，责任也就越大，负责一个团队，要为团队负责，尽量为每一位成员发展提供空间和方向，当然对于个人来讲，更重要的还是得靠自己主动。对于职业发展规划建议这块，我个人并没有什么好的建议，因为我自己就不太有规划。只有一个原则，那就是让自己每天进步一点点。真要给点建议的话，那就是要把自己现在在负责的东西，做到极致，真正当做自己的事去做，不要浮躁，不要单纯听别人讲什么性能、自动化测试比较有技术含量，比较有前途，要学以致用，只有真正用了产生价值了，才是进步。这样自己不知不觉中就会有较大的进步。
很多时候一件事做得好不好，最大的问题不在于技术本身！
点击左下角“阅读原文”查看更多内容！
