-
APP测试之找回密码
2016-12-13 17:11:04
在移动互联时代，每个人的智能手机上都安装了各种各样的APP，那我们在使用这些APP的时候都会用到找回密码这个功能，这个功能极大的方便了用户，但是如果这个功能没有做好，或者对于测试工程师来说，如果没有对这个功能测试好，也会造成一些严重的后果，比如，任意用户密码重置，用户数据泄露等一系列安全问题。这个看起来很简单的功能，却被开发工程师挖了很多坑，我们一不小心就会掉下去。下面我们就一起探讨一下，APP找回密码这一功能中的那些坑。APP端的手机找回密码流程通常如下：输入手机号-获取短信验证码-设置密码如下图：图1：
图2：
坑1：验证码没有和手机号绑定测试过程：找回密码时，输入自己的手机号点获取验证码，此时验证码会发到自己手机上，输入获取到的验证码，这个时候再修改手机号为B（B也是注册用户），点下一步进行设置密码。查看是否可以重置成功。实际测试过程中，某些APP竟然可以重置成功。也就是说用自己的手机获取的验证码，重置了用户B的密码。这个坑是个明显的逻辑漏洞，很明显程序并没有把验证码和手机号进行绑定，只要验证码是合法的，就可以重置任意用户的密码，一个小小的逻辑错误，导致了一个严重的后果，如果做为测试人员，没有测试出这样的问题，在市场上让用户反馈回来，是否会追究我们的责任，这还得看老板的心情。感觉这样的开发人员一定和测试有仇，要不怎么会挖个这样的坑。坑2：短信验证码出现在返回的数据包中大家都知道，一般我们APP客户端和服务器交互走的都是HTTP或者HTTPS协议。对于HTTP协议来说，我向服务器发送一条请求信息，那服务器必返回一条响应信息。而发送给用户的验证码，竟然也在服务器返回的数据包中。那意味着任何人都可以获取到这个验证码，有了验证码就可以重置密码。此时验证码形同虚设，重置别人的密码变得如此简单，你怕不怕？测试过程：这个测试过程要借助抓包工具，这样的工具很多，大家可以随意选择。我这里用的是Fiddler ，首先设置手机代理上网，手机网络应和电脑处于同一个WIFI下面，代理端口设置成和Fiddler上和端口一致。具体设置教程可自行网上搜索，设置好后，启动APP，进行抓包。 -
敏捷测试下采取怎样的反馈机制
2016-12-13 16:43:29
-
适合于小团队产品迭代的APP测试流程
2016-12-13 15:11:46
-
App进阶测试指南
2016-12-13 15:01:59
以前有个开发的同事问我，你的生活中是不是充满了bug？我对这个问题感到很稀奇，然而这却是个很有趣的问题。同样的情况，在我和我的家人意见不统一，我为一件事一直坚持的时候，他们会问我是不是有职业病？对于这些问题，在生活中，我只能承认我是一个完美主义者或者强迫症患者。在工作中，我并不是一个经验十分丰富的测试工作者，但是我很看好测试这份工作职责的重要性。一个团队，尤其是一个创业性的团队，对于测试人员的选择要和团队的整体水平一致，一个优秀的测试工程师不但可以做好测试，还可以培养开发对测试的态度，以及推动整个团队的效率。怎样的App受用户喜爱这是互联网公司发展需要考虑的必要问题，也是帮助测试工作者更好地测试的一个思路。站在用户的角度去体验，能发现更多的bug和可以优化的功能点。一个好的app，是受用户喜爱的，能做到维持老客户并且能够吸引新客户。用户的角度，无非就是这个app操作起来如何，占用内存大不大，性能如何，干扰信息是否多，符不符合自己想要的视觉体验。
互联网app的性能是决定app生涯的首要点。测试角度去看，app启动难，加载慢，不流畅，耗流量，占内存，耗电快，影响设备运行速度，卡顿，闪退，无反应，这些都是用户很难接受的，这样的用户体验可想而知。
在App黑盒手工测试中，最常遇到的性能相关的问题就是卡死，闪退，反应慢。这是用户不能接受的也是测试工作者不能接受的。一旦出现这样类似的bug，一次也需要提高警惕，属于严重bug范畴。
如果公司的测试团队不健全，或者压根不存在测试人员，App 问题频出，那将意味着什么？
现在市场上app软件的数量增多，用户的选择越来越多，大家也不愿花那么多时间在一大堆应用里试出好的应用，更想直接找到相应使用场景下最好、最合适的应用。所以一个app开发要有明确的切入点，以简约快捷为主。测试可以从简约角度去选择优化。App项目生命周期App 项目生命周期分为三个阶段，开发阶段，测试阶段，发布阶段。测试人员是需要全程参与的。
测试的基本思路测试范围－测试内容－测试计划－测试方案－测试用例－测试执行一般看来，测试并不是拿到手就可以直接做的这样一种工作，我们需要先熟悉整个项目的流程，心中有个大体的框架才能入手。测试的执行是在整个项目的中间以及发布前所进行的。然而实际上测试是需要贯穿整个项目的，在一个项目测试任务被告知前，作为测试的我们需要通过邮件，会议之类了解新项目的框架范围，要知道接下来整个团队的任务，我们应该如何去完善这份项目计划。了解了测试的范围，我们需要通过产品经理给出的原型图以及需求文档去了解详细的测试内容。在此基础上，我们对自己的测试任务已经有个基本的概念了，但依然会存在一些细节方面的问题，接下来我们要做的就是和开发沟通。测试和开发是相辅相成的，开发少不了测试帮助优化，测试需要开发的支持才能顺利地完成任务，双方沟通越细，后续能够避免的问题就越多。开发沟通完毕，需要对照已有的项目相关的需求文档开始立项，准备测试计划方案，列出每个功能模块，大致的功能点和执行方法。个人认为，此处测试用例可以列出雏形，后续测试过程中可以加以完善。其实，这里我考虑的还有一点就是测试用例是永远不可能补全的，每一个测试工程师的想法，操作手法以及思维角度是不一致的，随时都可能产生新的操作手法，所以我们只需要列举出基本的功能点，后续的一些特殊操作可以作为测试用例附加，但不属于基础用例的范畴。这一点，对于测试人员来说，更方便管理测试用例，但对于公司来说，app模块更新变动较大，测试用例过于详细的话维护成本过高，实际上也是节省了公司项目的执行时间。APP测试用例的那些事初入测试的工作者来说，一份很好的测试用例能引导新人跟上测试所需要的思路，因为这些都是有经验的老人无数次查漏补缺迭代更新的产出，可以细节到每一个常人想不到的步骤，考虑到全方位的各种情况。在我从事的这几年工作以来，接触过DELL的test case，虽然不用自己动手去写case用例，但是需要我们对test case非常熟悉。当然，我见过一些很牛的测试工程师，他们可以做到细节到每一个步骤，以至于test case拿到手就可以想到接下来这个case有哪些操作步骤，通常会发生哪些issue。这些是需要时间经验积累的。测试用例也是有规律的，一般来说是由浅入深，由表至里。基本上可以分为几个模块，大标题小标题，测试模块，详细测试步骤，附带测试结果供后续测试工作者参考。APP测试用例设计思路：测试项目：App应用软件需求测试：查看App的需求文档，原型图界面测试：查看App的界面外观是否符合标准功能测试：查看App的功能是否可以使用可靠性测试：使用App过程中是否退出等情况兼容性测试：安装App到平台（Android2.2/4.2），不同的分辨率是否成功疲劳测试：安装App程序一直置于后台是否退出或闪退等情况，idle测试易用性测试：App程序是否容易操作、人性化，用户角度体验，也就是简约便捷的趋势压力测试：重复安装、卸载App程序或不断点击某一个按钮是否退出等情况并发测试：安装、卸载App程序过程中或操作App程序功能时受到第三方的干扰回归测试：对App过程中Bug进行回归测试，在回归测试的同时要注意在bug是否修复的基础上有没有产生其他新的bug数据连接测试：数据、WIFI、热点等情况下测试，包括网络切换等各种情况用户手册测试：查看使用手册是否对App程序用法、限制、条件等有详细描述测试常用的方法等价类划分、边界值、场景法、错误推测法1.等价类划分：等价类划分法原则是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。等价类划分法是一种系统性的确定要输入的测试条件的方法。2.边界值：长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。3.场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。4.错误推测法：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。总之，就是进行错误的操作。测试用例的误区1）测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试。作为一个测试人员，我一直被灌输的思想正是这些。所谓的好的测试用例，就是可以让一个从头到尾都没有接触过你要测试的产品的人，能通过你的测试用例产品拿到手就会用。这句话不是不对的，我也并没有否认这句话的意思，的确是这样。之所以放在误区，是需要提醒大家考虑一点，这句话是需要一个前提的。对于测试用例，我有过犹豫，写的太简单，担心使用者看不懂，每一点都要过来亲自问我，这样反而会耗费更多的时间。写的太详细，个人时间耗费太多不说，在一个互联网时代，版本更新迭代太快的时代，这样的用例是很快就会被更新淘汰的。其实，我们忽略了一点，我们之所以为了让测试用例尽可能详细，是为了测试目的，为了完善产品。测试的目的是尽可能发现程序中存在的bug，测试活动本身也可以被看作是一个项目，也需要在给定的资源条件下尽可能达成目标，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。测试用例的详细程度也需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就可以。在测试计划阶段，一般建议测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。2）测试用例是一劳永逸的事情这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中却是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试人员牢记。3）能发现到目前为止没有发现的bug的用例是好的用例。作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。测试需要保证以下两点：程序做了它应该做的事情程序没有做它不该做的事情 -
无线测试之H5测试方法（1）：功能测试
2016-12-13 14:59:00
1、概述H5与JavaScript、CSS等紧密结合后，H5一改"网页即文档"的传统局面，大大增强了网页的富媒体特性。而相比较移动原生应用，H5有着很多优点，最为显著的是：·无需iOS、android等多端多版本开发，其跨平台可用性令应用只需一次开发，极大的节省了开发时间和成本；·快速灵活发布，尤其相比较iOS较长的更新审核周期，任何时候都能快速更新，在唯快不破的互联网时代，是核心竞争力；·他的致命缺点是响应速度慢、交互体验较差，但随着软件、硬件技术的不断快速发展，这其中的差距只会越来越小，将来只会越来越广泛的应用到各种移动场景中其实，我们已能发现，现在各种尤其是营销类app都从Native APP往Hybird APP（Hybrid APP指的是半原生native半H5的混合类App）发展，比如微信、QQ、手机淘宝、支付宝等等重量级应用，都在多个入口嵌入了H5。因此，H5的测试需求也是非常大的。笔者结合自己平时的工作实战测试经验，做了较为系统且细致的测试技能总结，也希望能帮助到大家。注意：以下主要是针对大部分的应用场景，即手机Hybird应用下嵌入的H5，其他场景会专门注明列个提纲，主要总结的有以下几点：·功能测试·测试辅助工具及技巧·接口测试·性能测试·适配测试2、功能测试， 最基础且必须要保证的1)登录和退出（hybird应用，浏览器隐私模式）2)关注缓存（cookie，Application Cache，localStorage）3)用户行为事件（点击、滑动、刷新、返回、与app切换，输入框、键盘、横竖屏切换）4)页面请求（翻页、请求重复、接口降级、请求慢）5)网络（无网络、弱网络、网络切换）6)多媒体（图片、音频和视频、动画、地图、表格）2.1、登录和退出对于hybrid应用：a)native已登录，h5保持登录状态；b)native未登录，在H5发起需要登录的请求，则唤起native登录，登录成功后能返回到之前H5页面；c)native主动退出，H5随之更新为未登录状态；d)native的session失效，H5即时捕获未登录状态；e)native切换账号，H5随之更新到新账号登录状态隐私模式下：因为cookie取不到，页面打开即未登录状态，登录后可以保持登录状态，但一旦浏览器关闭，重新打开后又需要重新登录2.2、关注缓存（cookie，Application Cache，localStorage）Cookie只有4k，被携带在HTTP头中，把数据保存到本地，可设置失效时间。localStorage有5~10M，持久化本地存储，数据不会被发到服务器。Application Cache可让开发人员指定浏览器应缓存哪些文件以供离线用户访问。在chrome自带开发工具-> Application中可以查看
一般建议与服务器交互的、主要的功能不要用到本地存储，具体校验点：Cookie中值是否正常，比如token等数据，清掉cookie是否使用localStorage存放数据：a)存放的数据是否正确；b)清除数据后功能是否正常；c)想要重新再走一次相关的同样的流程前，建议先把数据清除d)获取数据失败后是否有重试机制（PS：举个例子）用户在A页面做了操作后，又去B页面进行同样操作，结果直接在B页面上显示已经操作过了，导致他无法再次对B进行相关操作。我们去排查，发现后端没有出错，是前端发送的请求错了，发送的一直是A的信息。然后才发现，A页面，把相关数据存储在了localStorage，但是代码有漏洞，localStorage中的相关诗句还是老的A的，没有更新为B的。解决方案，直接A页面相关信息传递给B，不通过localStorage
如果按照之前的方式，测试过程中，把实体内存对象中的数据清除掉，就会发现无法提交，所以我们不建议在localStorage存影响流程的数据。清除localStorage方法：1)手动在上面的视图删除2)在chrome-console中写代码，然后运行，见下图
3)在隐私模式下测试使用Application Cache存放数据：a)访问页面后再断网重启应用，查看相应页面数据是否正确展示b)清除数据后功能是否正常；c)想要重新再走一次相关的同样的流程前，建议先把数据清除d)获取数据失败后是否有重试机制清除Application Cache方法：1)在服务器端删除掉manifest文件2)直接在隐私模式下测试隐私模式下（3种存储都不可获取）：校验主要功能是否正常2.3、用户行为事件点击：a)单次点击，注意点击事件是否被误触发；b)多次点击，关注点是当H5等待服务器返回数据过程中，用户继续点击其他功能按钮，是否会造成业务逻辑出错；c)点击触发表单事件，如点击后触发下拉表单、时间选择表单等，是否正常；d)点击触发media事件，如点击后触发视频、图像、音频等，是否正常（具体后面会讲）；e)点击特殊格式文字，如连续数字串是否会唤起电话，含@字符串是否会唤起邮件f)点击穿透，在页面有多层时，是否点击上层而出发下一层的点击事件滑动：a)慢速滑动与快速滑动，功能上应该一致；b)页面在快速滑动时点击一次屏幕，应该视为用户"停止屏幕滑动"事件，而不应当"点击按钮"事件；c)页面滑动规范，一般整个页面只允许上下滑动不允许左右滑动；d)滑动过程中，动画流畅，数据加载不能太慢刷新a)下拉刷新是否仍然处于当前页面；b)注意iOS下，下拉刷新和下滑页面的作用域范围，以及用户交互体验返回a)返回到上一个页面，即后退，会刷新页面请求b)返回即关闭一个webview，不会刷新页面请求c)页面中的返回要考虑业务逻辑，友好返回到相应层次。d)list列表中，滑到一位置，点击到下一页，再返回，需定位到之前的位置e)不能出现死循环f)浏览器自带的返回需要测试H5与Native切换a)从native app切换到H5页面、从H5到native客户端b)H5调用其他appc)H5调用系统app，如电话、相机、地图等d)H5使用过程中有电话进来，中断app正常运行，再次恢复app运行，功能状态是否正常e)切换时登录信息是否记录、流程是否顺畅、是否出现中断闪退等问题输入框a)内容格式控制，b)特殊字符显示，c)js是否会执行，d)其他，如过滤黑词，一串长字母是否会换行等；键盘界面a)键盘弹出是否正常，是否会覆盖输入框，b)键盘隐藏是否正常c)安全键盘，密码等敏感输入区横屏竖屏间切换：有些应用支持横屏显示，则需要测试横屏竖屏间切换后是否能自适应，页面布局不会错乱2.4、页面请求对于每个页面，要查看发送的请求是否正确，推荐用chrome中自带的开发工具查看网络请求
需要注意的点：翻页，数据分页加载时，后续页面请求数据的正确性（需要注意在快速操作场景中，请求页数是不是依次递增），快速操作（如第一页尚未loading出来的时候仍然继续上拉操作）时是否发出去对应的请求了；请求的接口是否有重复，比如上面的翻页场景；接口降级，接口返回异常错误提示时如何处理，前端要给出友好提示；请求比较慢时，要有loading图片，图案在数据出来后要消失，且不能与转场动画等其它有冲突。。2.5、网络不同网络类型测试a)考虑2G\3G\4G\wifi网络b)考虑移动网络2G\3G\4G基站的变化的影响c)无连接、关闭连接状态d)弱网络信号状态e)有网络信号但网络不可达状态测试注意点a)从wifi切换到2G/3G网络、从2G/3G网络切换到wifi等b)弱网络降级：处于2G/3G网络省流量模式的一些特殊处理，比如2G网络下测试，图片多时是否要懒加载等c)无网络时，执行需要网络的操作，给予友好提示，并确保不会导致应用crash；d)内网测试时，要注意选择到外网操作是的异常情况处理；e)弱网络下，检查功能状态是否正常，确保不因提交数据失败而造成异常甚至应用crash；f)弱网络下，检查数据是否一直处于提交中的状态，如遇数据交换失败要给予提示；g)弱网络下，执行操作后，在回调没有完成的情况下，退出本webview或者其他操作，有无异常2.6、多媒体图片a)图片的放大及还原；b)多张图片的滑动切换要流畅；c)图片适配，是否根据不同设备像素比做适配，高端机取双倍尺寸的图，低端机单独处理，不取高清图；d)2G\3G网络下，不取高清图，最好加上webp图片的支持，可减少流量。音频和视频，一般都是调用已有的组件a)测试对于内部域名的，以及外部域名的视频支持情况b)视频的交互体验，如是否直接播放、是否点击播放，如何退出等等，iOS和android的有可能处理还不一样，一定要分别看c)音频和视频，是否有声音d)视频的适配，尤其要测试不同android机下视频播放支持情况动画特别需要注意在中低端机的显示和动画流畅度。最好让前端单独处理，去掉一些复杂的动画效果地图，一般都是调用已有的地图组件a)测试地图的全景、退出全景模式b)非全景模式下的拖动是否正常c)地图适配，尤其要测试不同android机下视频播放支持情况表格一般校验是否和PC后台编辑的表格格式一致，格式布局不要错乱，也要注意不同机型下的支持 -
搜索框功能测试分析
2016-12-13 14:55:57
搜索功能分为简单搜索和高级搜索，部分需求参考了百度简单搜索先展示百度的简单搜索界面，仅供参考：
界面测试搜索框UI显示正常，布局合理；搜索页面布局合理，无错别字；搜索出的结果展示，布局合理；已查看过的结果链接，链接的眼神要灰化处理，和没有点击过的结果链接区分；结果数量庞大时，页面的分页布局合理；链接测试：页面上的链接都可连接至正确的页面搜索历史内容记录，便于查找检索过的内容搜索内容联想输入，便于用户搜索的便捷与准确性搜索功能测试（重点）搜索内容为空，验证系统如何处理搜索内容为空格，查看系统如何处理边界值验证，在允许的字符串范围内外，验证系统的处理超长字符串的输入，系统是否会截取允许的长度来检索结果合法的字符串长度后，加空格，验证检索结果多个关键词中间加入空格，tab，逗号后，验证系统的结果是否正确验证每种合法的输入，结果是否正确是否支持检索内容的复制、黏贴、编辑等操作是否支持回车键搜索多次输入相同的内容，查看系统每次检索的结果是否正确，相同特殊字符，转义符，html脚本等需作处理敏感词汇，提示用户无权限等信息输入的内容，是否支持快捷键操作等只能输入允许的字符串长度安全性测试（没有做过，只能列出一些简单的注意点）脚本的禁用SQl注入，检索sql select语句等敏感内容的检索是禁止的特殊字符的检索被删除、加密、授权的数据，不允许被查出来的，是否有安全控制设计兼容性测试多平台windows，mac移动平台ios，android多浏览器FF，Chrome，IE，国内主流浏览器等性能测试搜索页面打开的速度是否满足设计要求搜索出结果消耗的时间，是否满足设计要求本地化测试登录时，自动切换至相应语言国家的搜索主页高级搜索先展示百度的高级搜索页面，仅供参考：
场景法测试，主要是为了验证搜索结果的正确性：
每个场景，对应了一种高级搜索活动从开始到退出搜索的完整过程 -
功能测试中遇到的一些有意思的bug
2016-12-13 14:55:01
-
黑盒测试进阶之网页加载速度评测
2016-12-13 14:12:56
-
黑盒测试之做好功能交接
2016-12-13 14:10:40
-
关于项目管理，我们要学会哪些方式？
2016-12-13 14:09:50
-
性能测试解惑之并发压力
2016-12-13 14:05:30
前言：之前一直做的软件质量工作，有过一些经验和一些不太**的思路，尽管与现在从事产品运营不同，但无论是内涵还是联系，都是非常紧密的，无论如何，我都会继续关注产品的质量问题。
上周跟一朋友阐述性能中并发的概念，叽里咕噜一大通，完了兴致勃勃地让她总结一下，她说了一句：感觉你研究的东西太初级，并发这种概念，太简单，没什么好说的。我听了差点没晕倒，估计她也晕了，真是失败。
并发真的这么简单？性能真的如我们所理解的那样？
也许并不像我们想象的那么简单，之所以我们去探究这些基本的概念，是因为在实际的工作中，我们发现，很多问题到最后才发现，根源在于概念没有统一，抑或没有理解，而无论作为研发人员，还是顾问、销售人员，我们除了自己理解，还需要与客户交流沟通，因此，深刻理解并能通俗易懂的表达出来是非常重要的。
由于软件性能的范围比较大，我们将选取几个典型的问题进行探究，相关概念的理解与分析将逐步进行公开。
● 如何考察性能
这个问题相信很多同事都了然于心了，基本都有自己的理解，我们也很少接到不懂性能的反馈，但很多人甚至包括客户，都把响应时间或者并发用户作为衡量性能的惟一依据，支持10000并发？性能好！响应时间1秒？性能好！有些时候我们也会接到客户一些要求，让我们哭笑不得，某次一客户就要求我们的产品支持10000并发，有点汗，哈哈。
实际上性能是一项工程，严格地说，性能是在某一个特定环境下，系统所表现出来的最大事务处理能力。如果我们将这个问题细化，性能取决于具体环境，取决于系统架构，取决于软件与服务器的优化等等，也就是，我们所提供的内部测试报告是具备一定的前提的（在一定的网络或硬件环境下），如果我们的架构是包含了10台机器的集群，而客户方提供的却是2台PC机，这种条件下还要求测试结果保持一致，就有点为难了。
尽管性能有很多范围、指标、概念，比如响应时间、吞吐量、并发用户、软硬件负荷等等，但对普通用户来说，并发用户数与响应时间这两个概念还是最为直观与普通，认可度也最高，搞清楚这两个概念非常重要。后面我们会逐步阐述其他概念。
● 理解压力
在谈起并发这个概念之前，我们先来说说压力，对系统而言，性能问题归根到底，都会体现为实实在在的压力。因此，我们一般说的“你这个系统的性能最高能到多少？”，其内在含义指的就是“系统所能承受的最大压力是多少”。
那么压力究竟是什么呢？
我突然想起天天坐的地铁，没有比坐地铁这件事情更便于形容性能与压力了，哈哈。话说我每天在立水桥南上地铁，绝对是考验体力耐力心理素质的事情啊（说岔了）。
我们可以把一班地铁列车看成是一个被测的系统，对于这个系统而言，其压力显而易见，就是列车中所有的人，比如北京地铁5号线，每列车的定员人数是1424人，折合每节车厢237人（当然包括站着的），而最多容纳是1820人，折合每车厢303人，这个总承受人数。
其实就是系统（也就是列车）的最大设计承受压力（也就是吞吐量了），当然，北京地铁比较变态，超员现象比较严重，我每天占用的面积还不超过10平方厘米（脚踮起来了），实际最大负荷估计超过2000了。对列车而言，超过最大负荷是比较危险的，要么是拉不动（这个估计可能性不大），要么人挤坏（君不见每天争吵哀嚎无数）。
如果超出设计负荷值，系统就会存在危险，危险是多方面的，因此，一般的，系统应该具备超出负荷的处理预案，对照到地铁，高峰时期就会进行限流。
搞清楚这个问题后，再来看看常规的系统，就好理解了，系统的压力是什么呢？压力是对被测系统而言的，只要系统在处理事务，就有压力，这种压力不仅仅体现在网络上（数据的吞吐），还体现在服务器上（如CPU、内存等），因此，我们不要混淆了吞吐量与压力的关系，应该这么说，在一些web系统上，吞吐量可以在一定程度上反映系统承受的数据压力。
另外，我们需要清楚，压力不等于性能，压力只是检验性能的一种手段，对一个性能良好的系统，在一定的压力下，应该可以保持正常运转，如果超过负荷，则应该分流或化解压力，这也是我们需要检验的。
● 理解并发
说完压力，我们已经知道，压力其实就是一种作用力，当然，还可以理解为一种量的度量，比如列车的承载数，既然有量，就肯定有速度，承载总量（吞吐量）是一定的，但速度却是变化的，我们早晚高峰的时候去乘地铁，当然是拥挤非常，但如果你晚上11点去做地铁，我可以很高兴地告诉你，你还会有座位！
原因在于，早晚高峰时坐地铁的人多，深夜时坐地铁的人少（这不是废话吗）。我们再来想想，高峰的时候可能同一时间挤进门的人很多，基本上门有多大，同时挤进去的人就能把门给塞满。
那么这个并发（虚拟用户）是什么呢？
并发是有场景条件的，要看我们考察的是什么事情，我们再来想象一下地铁，在整个地铁大厅里（包括列车），有刚刚进站的，有正在买票的，有正在登车的，有坐在车上的，还有闲逛的，这么多人，但对列车有压力的，其实就是已经在车上的这些人（包括挤车的），如果我们考察性能的系统就是列车，很显然，重点关心的就只需要看看车上现有的这些人。
再次强调，并发跟考察的具体场景是有关系的，即并发做什么，并发这个词，原始的翻译是concurrent，意为同时发生的，或同时存在的。至于同时做什么，要看我们定义了，同时在地铁大厅里，同时在地铁上，同时在挤地铁，考察的事情不一样，并发的意义就不一样。
对地铁这个系统而言，每个时间都有新来的人，也有走的人，大家做的事情基本都相同，乘地铁。假定某个时刻地铁大厅中有10000人，检票口候车的有100人，刚刚开走的地铁上乘有2000人，那此时对考察的系统（列车）而言，并发就是2000人，而如果考察的是检票处，则并发为100人，同样，如果考察的系统是地铁大厅，那此时的并发就是10000人。这种并发我们一般称之为“广义并发”。
广义并发有点类似与通常我们所说的在线用户，但存在关键的区别，即并发用户针对的是某一件事务，譬如注册、登录、上传、浏览等，而在线用户是一个很泛的概念，一般包括前面所述的所有事务，可以理解为一个事务集合。
在性能的理论中，还有一个概念，simultaneously，翻译为同步的，当前，为方便计算，我们一般把“同步”理解为“同1秒”，也就是说，这个同步的就是单位时间内发生的数量。也即我们通常所说的“狭义并发”。需要注意的是，实际的测试中经常会遇到被测事务响应时间低于这个1秒的单位时间，此时的并发计算仍需要按1秒计算，具体参见“我们的定义”中的说明。
很多时候，我们（特别是客户）往往搞混了这两个并发的概念。对系统来说，广义的并发实际上是在一个时间内操作事务的虚拟用户，而狭义的并发指的是单位时间内向系统发起请求的虚拟用户，前者是“存在”，后者是“请求”，勿容置疑，压力不仅仅受成功发出请求的用户带来的压力，同时也受“存在”的用户影响。
换种理解方式，并发考察的是系统的处理能力，最多能支持多少用户同时处理某件事务，而不是压力发出端发出的请求。
除此之外，并发作为一个量化的指标，是对应着具体的取值的，因此，很多系统会去寻求最大并发，实际上，我们来回顾5号线的承载力的例子，核定载客1424人，这种情况可能考虑到乘客的感受（还算舒服，站着也算，哈哈）
● 理解我们的定义
在我们已经做过的很多测试中，都有并发这个概念，当然也包括我们很多开发人员，所谓的并发是怎么定义的呢？
客观的说，我们的定义比较接近于“广义并发”，但有所不同。这与我们的考察对象（web系统）、衡量事务（通常我们衡量的都是单个事务，很少把多个事务放在一起处理，原因在于尽量避免事务的耦合性所带来的影响）有关，具体到地铁的例子，如果我们考察的系统指“地铁大厅”，那么我们所谓的并发一般通常指同时进入地铁大厅的人。而如果我们考察的系统指“地铁列车”，那么我们所谓的并发则指同时进入站台的人。
在实际的产品测试中，比如我们在测试IDS登录的时候，如果说，支持800并发，其涵义为“支持800个虚拟用户同时进行登录操作”，需要说明的是，这个同时并非指同一秒，要知道，并发本身是没有单位的。在800并发下的结果如何，要看响应时间，这个问题本文不进行仔细阐述。如有兴趣可以参考相关资料。
测试中，我们也会考虑“狭义并发”的情况，但狭义并发需要考虑到被测系统的入口，比如，假定地铁总共有10个入口且全部开放，每个入口只能容纳1个人进出，则“狭义并发”下最大值就是10？不一定！因为我们还没有考虑速度问题，前面提到，狭义并发的单位是秒，如果每个人通过每个入口的耗时就是1s，则最大“狭义并发”值就是10，如果通过的时间少于1秒呢？还是按1秒算，比如还是这个情景，乘客通过入口的耗时假定为0.1秒，则最大狭义并发就是10/0.1=100了。
简单点说，我们可以这么理解实际工作中的并发，被测的事务总得有人（其实就是虚拟的用户）来做，对吧，同时允许多少用户来做这件事情呢？这个多少用户就是我们需要的并发值。
● 如何估算并发
那么我们如何来估算这个并发值呢？
在此我们需要作出说明，一般我们需要的数据应该来自于实际数据（比如系统日志的记录），这样最可靠，只有当系统新启动且无任何数据参考的时候我们才需要进行估算。
比如我们测试地铁大厅的性能情况，该如何去估算当乘客进入大厅时，地铁大厅的性能呢？下面以笔者经常乘坐的地铁5号线立水桥南站为例进行估算，过程与数据仅供参考。
假定每天从该站乘坐地铁的人数为5万人次，每天的早高峰为7-9点，晚高峰为6-7点，根据8/2原则，80%的乘客（人次）会在高峰期乘坐该站的地铁，则平均每秒到达地铁检票口的人数为（50000×80%）/（3×60×60） = 3.7～=4人，当然这个4人不能作为计算所用的并发值，因为对此时的受压入口检票口来说，4只是每秒到达的压力（即请求）数量，考虑到安检、入口关闭等因素，实际堆积在检票口的人数可能要大于这个数目，假定每个人需要3秒左右才能入站，则实际并发应该为（4人/秒）×3秒=12。当然我们必须指出，这种方法得到的情况并非极端值，因为即使作为早晚高峰，人数的分布也不是平均的（具体情况需要根据实际数据进行分析），但对大部分系统的大部分场景，我们可以用（用户总量/统计时间）×影响因子（一般为3，为经验系数）来进行估算。
实际上，还有一种估算方法，而这种估算方法为国内众多书籍、文章反复转载，其来源与Eric Man Wong在2004年公布的一篇“论文”《Method for Estimating the Number of Concurrent Users》，其核心公式如下：
C=nL/T
其中，C代表在线用户，n代表执行事务的用户总数，L代表每用户的平均在线时间，T为待统计的总时间，依旧以地铁入站的情况进行估算，依旧考虑8/2原则，即n为50000*80%人，T为3小时，L即我们在地铁中停留的时间（从进站到上车），假定为5分钟，因此得到的公式为：
C=（50000人×80%×5min）/3×60min = 1111
并发数是1111，比前面一种算法要高的多，这是为什么呢？
实际上，后面这种统计方法是由一定的局限性与适用范围的，对其统计的每个并发用户而言，每个用户所在线的时间（如上面的5min），并不一定是我们所需要的场景耗时，该5分钟应该是整个大场景（如从进站到离开），而我们通常所使用的场景往往包含了一连贯的子场景，如进站、等待、上车等，因此，如果我们测试的场景是某一个具体的动作，不建议采用这种公式（当然，如果单独为每个动作估算时间也是可以的。）
从本质上来说，两种公式的统计，结果都是一样的，关键取决与统计口径。
极限的问题也是我们需要考虑的，数据的估算往往是一个大的工程，涉及到很多复杂的情况，比如用户的进入与离开，人流异常等，因此我们考虑的多为常规的情况，在一些特殊的情况下，用户的峰值往往要大很多，此时需要去对极限情况下进行估算。
此时的目的在于检查系统的极限承载情况，如列车最大承载2000人，站内极限承载10000人是一样的，超出这个极限，就需要采取一些紧急措施，比如限流（对应到普通的系统，就是设置最大连接数，超出的必须等待）之类。
这种值的计算，不可能给出准确值，可以根据实际情况，协商而定，比如把经验系数更改为5，这种情况下，如果有日志或者统计数据予以支撑，会更加精确。
● 回答客户的疑惑
面对客户，经常需要去解答一些问题，常见的几类疑惑如下：
1、客户坚持要求并发2000，怎么办？
这个问题非常关键，即上面所谓的阐述只是为了让大家对并发等概念有个大体的理
解，但我们的工作重心不是一来就跟客户讲理论，而是合理、有效、迅速地完成项目，因此，特别是一些项目的咨询阶段，如果客户坚持提出达到某个并发要求，我们首先需要看下这个情况产品能否支持，如果不支持，通过修改架构（比如增加服务器，公司的大部分产品都支持集群）来完成，如果还是没法达到要求，我们再来跟客户交流，从客户能理解的方式，从客户的角度去计算并发，最后得到认可就行了。当然，解决这些问题，需要我们对公司的产品性能基本比较了解（可以通过产品的性能测试报告来了解，质保将来会考虑出台所有产品的性能指标集合供参考），如果难度还是很大，可以申请质保的支持。大家一起去解决这个问题。
2、你们的系统能支持10000并发吗？
一些客户经常提出非常高的并发要求，此类客户通常对性能并不了解，或者之前有客户对其做了错误的解释，此时我们需要解释我们测试并发的概念：同时向服务器发出请求的虚拟用户数。（而我们通常会采用严格的方法进行场景测试：即采用集合点的方式进行操作。这种方式也即前面介绍的狭义并发的概念。）
另外，并发值需要考虑实际情况，需要根据实际的需求进行计算，与此同时，并发的影响因素并非仅仅是软件本身，还有网络、架构等等，TRS的产品性能测试往往给出单位机器的性能，用户可以根据这个基础值来构造实际架构。
3、你们的系统怎么才支持200并发？
并发的概念在于同时在处理某一件事情，而且系统一直保持这样的一个强度，并不是说总共只有200人，另外，我们测试的一般是单机，也就是说，如果更好的性能要求，可以通过集群的方式来获得更优的结果，目前TRS的产品基本都支持集群的部署架构。需要注意的是，并发的支持除了软件本身，还受到网络、服务器性能等多方面原因的影响。
4、是否可以使用每秒处理事务来衡量。
性能测试的衡量指标除了响应时间，还有吞吐量、每秒点击数、每秒PV、每秒事务处理能力等，因此我们可以通过多种方式进行衡量，在更大意义上，各个指标间也存在一定的内涵联系，结合起来考虑更能够检查系统的性能。但受制于一些客观原因（如定制），在之前的报告中，指标衡量存在一定的限制。
5、响应时间与并发、压力是什么关系？这么操作的响应怎么才6秒，太慢了，你们的产品性能不行啊！
一般的，一定的并发下将对系统造成一定的压力，而对每个并发（用户）而言，所体现出来的性能多是直观的响应时间，在环境一定的情况下，响应时间越快说明系统性能越好。但此处需要清除一个问题，假定一个用户获取的响应时间是5秒，这5秒都在对系统产生压力吗？
后面这个是一个有趣而有意义的问题，我们知道这个响应时间是从用户发出请求到接收到响应的为止的总耗时，如果我们使用httpwatch之类的工具，可以很清晰的看到时间消耗的分布区间，我们可以把这个问题比作是向墙壁击出一个球，从击出到弹回来的时间即为响应时间。
大家打过壁球吗？打壁球的过程其实就完美的诠释了用户发起请求到接受响应整个过程，可以我们可以把墙壁看作系统，打球者就是用户，球是用户发出的请求，击打一次球包含有三个动作：击出球、球接触墙壁、收到弹回的球。三个过程加起来的总时间就是这个请求（打出一发球）所得到的响应，但很显然，真正对系统产生压力的动作在于接触墙壁的时间，大部分的时间消耗在空中，即球在空中飞行时的时间，而这个飞行时间并不受系统控制，对应到常规系统，就很可能是网络在传输过程中出现了问题。
这个壁球的例子实际上还可以解释一些相关的概念，比如并发就是同时击出多个球，系统（墙壁）所能承受的最大并发压力就是墙壁的面积所能容纳的壁球数量，假定墙壁面积可以容纳1000个球，则墙壁瞬间可以接触的球的数量就是1000个，这个就是狭义并发的概念了，考虑到空中飞行，即将触碰墙壁的球，理论上的广义并发值要高于1000。击球时的力度可以理解为客户端的性能，性能好发球就快，否则就慢，只要系统性能没有达到瓶颈（比如墙壁没有坏），系统的性能是跟客户端呈正比的，即击球速度越快，返回越快。
因此，当遇到客户对响应时间有疑问时，我们需要解释的重点在于，压力在于球接触墙壁的瞬间，但性能测试考核的响应时间确实包含了两次飞行（发送与接受）的时间，而这个时间是受包含服务器性能、网络性能、客户端性能在内的多因素影响的，相信客户可以理解。
● 简单的结论
如果您觉得上面说的东西过于繁琐，以下基本概念可能更适合阅读。
1、并发分为狭义并发与广义并发两种，狭义并发指同一时间点开始做某件事情，广义并发指同一时间段正在做某件事情；
2、并发与被考察的场景是息息相关的，测试中所指的并发一般指同一时间段在做某件事情（被测事务）的用户数，在严格测试的环境下，我们会要求所有用户在同一时间点集合并执行；
3、在线用户与并发用户不是一个概念，在线用户包含了很多非测试事务用户、空闲的客户等，因此不能把在线的用户全计作并发用户，一般的并发用户占在线用户总量在10%～20%左右，当然，这个值仅供参考，实际问题需要实际分析。
4、理论上说并发越大性能越好，但其取决与很多因素，比如网络、服务器数量、服务器性能、系统架构、软硬件优化等，另外，并发的计算需要在需求阶段根据实际情况进行估算，这样得到的结果才是合理的。
5、几个概念的再次说明：
→ 并发用户数：同时在操作被考察事务的用户数
→ 在线用户数：当前被测系统中的活动用户数（包括考察事务与非考察事务）
→ 平均响应时间：每个用户操作事务获得的平均响应时间（算术平均值）
→ 90%响应时间：90%用户平均响应时间在此值范围内（取除去10%极高值后的最大值）
→ 平均事务数：单位时间完成的事务数（如登录、首页读取等）
→ 平均吞吐量：单位时间内的数据传输量
→ 平均点击数：单位时间完成的请求数量
→ PV：某时间段内完成的页面请求数量
-
测试负责人和测试工程师在日常工作的区别
2016-12-13 13:56:38
-
SQL注入测试用例
2016-12-13 13:55:10
-
我在测试移动弱网时踩过的坑
2016-12-13 13:53:45
什么是弱网测试
从测试角度来说，需要额外关注的场景就远不止断网、网络故障等情况了。对于弱网的数据定义，不同的应用所界定的含义是不一样且不清晰的，不仅要考虑各类型网络最低速率，还要结合业务场景和应用类型去划分。按照移动的特性来说，一般应用低于2G速率的都属于弱网，也可以将3G划分为弱网。除此之外，弱信号的Wifi通常也会被纳入到弱网测试场景中。为何要进行弱网测试我当前所在项目的产品是一款适配于低资源环境的医疗IT系统，目前主要是在坦桑尼亚地区使用。根据资料显示，在坦桑尼亚等东非国家，普遍使用的都是2G网络，覆盖率达到40%以上，3G网络的覆盖都非常少，并且稳定性较差。由此，对于当前的App应用交付要求即至少在弱网以及无网状态下能正常运行。
如何做弱网测试弱网环境测试主要依赖于弱网环境的模拟。环境搭建方式一般有两种：软件方式和硬件方式。软件方式的成本低，主要就是通过模拟网络参数来配置弱网环境，通常来讲可以达到测试目的.一般可通过热点共享设置，或者第三方，例如 : Charles , Network link Conditioner . 在各类网络软件中，主要就是对带宽、丢包、延时等进行模拟弱网环境。如果要求更接近弱网环境，比如现在很多的专项测试，会更倾向于通过硬件方式来协助测试，但这种方式相对会麻烦很多，一般会由网维协助搭建，例如 树莓派 。当然，对于有些无法模拟的情况，只能靠人工移动到例如电梯、地铁等信号比较弱的地方。弱网测试时碰到的问题和解决方案1、 现象：用户登录应用时下载初始化数据，下载过程中因网速太慢点击取消并重新登录，数据初始化完成后出现重复，造成数据不一致。原因：数据下载过程中、下载失败后，未进行数据回滚，中止后重新下载，出现数据重复解决方案 ：通过事务处理数据下载逻辑，下载失败后，应用本地数据库进行数据回滚。2、 现象：用户点击数据上传，数据上传过程中网络弱且不稳定，基于联网状态自动触发数据上传，导致出现数据重复写入，形成脏数据原因：数据上传过程中， 由于失败重传机制，会出现连续两次写操作，并且未做唯一识别处理解决方案 ：根据数据特性，对可能造成脏数据的地方，通过关键字段，例如创建时间，key-value值等生成hash键，标记记录唯一性，即数据写入时，检查hash键是否存在，如果已经存在，当前重复数据丢弃。3、 现象：在弱网环境下，用户输入用户名和密码点击登录，应用链接超时返回用户名和密码错误提示。原因：在弱网环境下的连接超时后，按照强网业务逻辑处理，导致返回超时异常。解决方案 ： 弱网连接超时后，检查应用本地数据库是否有用户登录信息，若存在，获取应用本地用户信息进行登录。4、 现象：在弱网环境下，用户输入用户名和密码后点击登录，登录过程中应用崩溃并且闪退。原因：弱网环境下数据下载超时，加载数据 严重依赖于后来的异步加载。数据还没来得及返回，应用跳转到下个activity，导致崩溃。解决方案 ：健壮数据加载流程，通过标记后台数据下载状态加载界面，依赖数据下载完成后，再进行页面跳转。5、 现象：弱网络环境下，用户请求页面响应时间较长，等待的过程中，页面上的部分控件仍然可以操作，当用户点击控件时，出现应用闪退现象；原因：没有对数据加载流程进行判断，直接暴露控件可控，当出现依赖数据的控件操作时，没有在数据返回前做兼容处理。解决方案 ：在数据加载过程中，设置页面对外暴露的控件为“不可操作”，当数据加载完再释放。6、 现象：在弱网环境下，用户第一次输入搜索关键字没有得到响应后，再次输入全新关键字并发送请求，等待搜索结果返回后，当前结果页被之前的关键字搜索结果刷新覆盖原因：中间的请求返回较慢，显示最终的结果后，之前请求返回的数据应不做处理。解决方案 ：对异步请求未完成的任务进行cancel.总结当然，出现以上问题的根本因素并不是弱网，在我们平时的PC应用中一样会遇到，但是这些问题在移动弱网环境下会表现的更突出。所以综上所述，从功能、性能、稳定、异常处理等几个维度来归纳场景特性，弱网测试主要集中在如下场景：
-
互联网高级测试工程师至少具备的能力
2016-12-13 13:52:37
业务熟悉熟悉本系统测试人员参与测试的系统的各种业务场景，必须做到精熟 。一旦需求有改动，可以清楚快速的知道上下文。同时可以清楚的知道哪些点是需要重点测试的。熟悉跟本系统有通讯的上下游系统业务跟本系统有通讯的上下游系统也要非常熟悉。这样一旦系统出现问题，可以知道影响的范围。熟悉公司主流程业务熟悉公司主流程业务。虽然不是自己测试的系统，但是熟悉公司主流程业务，可以让测试人员在考虑问题的时候，有更好更广的思路。
逻辑思维好，气场也要好互联网应用一般是切分成多个子系统的，各个系统都有自己的业务范围，一个任务的完成，通常要有多个部门或者小组进行协作。这个时候，就不可避免的进行各种会议沟通，小组内的或者小组之间的。那么测试人员如果脑子不好使，不能快速的理解别人的意图和想法，会很容易被人忽悠或者陷入各种坑，到时候就会有无穷无尽的测试任务了。另外，当对方太强势的时候，测试人员不能太弱势，应该根据自己对业务和系统理解，提出自己的意见，该做的就做，不应该做的别硬塞过来。积极配合对方，但不是傻傻的啥都做。掌控系统上线排期如果开发任务非常的多，测试人员要测试的功能也就非常的多。这个时候，如果功能的上线时间都是由开发经理或者PMO等来定，那测试人员就只能进行无穷无尽的加班。这样是不行的。测试人员有自己专业，对业务精熟，必须清楚的知道哪些任务的优先级是高的，哪些是低的，将任务进行优先级排序。规定某个时间段里，就只能上多少个功能。测试小组能够承受的最大任务队列是多少，测试人员必须有个底。测试任务超过这个队列，可以根据优先级把部分任务挤出去。能编写覆盖关键路径的测试用例对业务需求准确的理解后，测试人员能根据业务需求，设计关键的测试用例，能够完整的覆盖业务关键路径和场景,保证只要这些重点用例能通过，就说明需求的重点功能已经OK了。重点功能OK了，就算立刻上线，如果出现问题，也只是小问题。当然能够用测试用例覆盖所有当然是最好的。熟悉测试技术在测试互联网应用的时候，测试至少得掌握下面的技术和概念：1. 懂得用jmeter进行性能测试；2. 懂得搭建性能测试需要的环境，例如服务器、redis、memcache等等；3. 懂得如何编写性能测试报告。例如至少包含接口响应时间、QPS、最佳并发数、CPU使用情况、内存情况、抖动、GC情况等等。4. 懂得上下文切换、内存溢出、内存泄露、QPS、稳定性测试等等的概念。约束开发人员，保证开发质量当开发提测代码的时候，测试人员应该具备下面的意识：1. 让开发人员先把master分支的代码merge或者rebase到自己分支上，保证提测的时候，代码已经包含了master的代码，这样可以提前发现问题。2. 代码功能测试完毕后，必须再做一次回归测试。这个时候必须强烈的约束开发人员，不许再提交代码了。除非是bug。不然的话，测试人员回归测试完后，开发人员跑来告诉测试说，代码有改动。这样的话，测试人员辛辛苦苦的回归测试就白测了，又得重新回归一次。3. 测试人员必须回收master分支的代码提交权限，一旦开发者要提交代码，只能通过和测试沟通，说明代码做了什么改动。绝对不能让开发人员悄悄的提交代码，这种行为非常造成线上故障的。要懂的写代码进行接口自动化测试现在微服务非常的流行，各大互联网公司都在搞微服务接口。针对微服务接口，测试人员一定要懂得编写代码去进行接口自动化测试。大家想想看，假设某系统有50个微服务接口，测试人员测试完一次后，开发人员修改了其中10个接口的代码，这个时候应该可以通过跑自动化case来验证这10个接口的改动有没有影响到其他40个接口。这种回归测试的效率非常的高。如果每次都得人工手动的进行接口回归测试，那测试人员就得累死了。 -
测试经理每天到底在忙些什么？
2016-12-13 13:50:46
-
移动APP项目研发流程及版本规划
2016-12-13 13:32:01
项目研发流程一般来说分3个阶段第一阶段：需求策划。在需求阶段产品经理内部进行需求讨论：讨论下版本需求重点是什么，做什么功能，怎么做。通过反复调研、讨论、输出交互方案。确认需求可行性：产品在输出交互方案后找相应的开发讨论需求方案是否可行，这个讨论阶段产品和开发的思维方式不同，往往会擦出新火花、新惊喜；但讨论控制不好或者会演化为产品和程序员的撕逼大战，呵呵。UI设计：设计师将产品的交互方案变得更生动精美，不过精美的设计稿不见得都能实现出来。在这个过程中产品经理需要协调设计师和前端人员的沟通，制定设计规范。同时保证设计稿的质量，出稿进度。需求宣讲：产品经理将交互方案和实现逻辑完善以及将上版本的bug、其他优化需求等整合出完整的版本需求文档后，拉上项目所有成员宣讲。宣讲目的主要让项目成员清楚新版本需求的重点是什么，做什么功能，为什么做（重点讲）；简单介绍怎么做，讲解交互方案或设计稿，给大家有一个整体的印象，让大家都了解版本功能的意义。第二阶段：需求研发。项目启动：需求宣讲后，开发根据产品需求文档进行需求评审，评估出研发周期、提测时间、预发布时间点、正式发布时间点。产品根据评审结果发送项目启动邮件。研发：需求研发过程中，产品跟进研发进度，保持与开发沟通确保需求被正确理解，及时解决研发过程中发现的新问题。测试用例：产品、测试、开发共同确认版本测试用例，并同步研发过程中变更的需求和细节。提测：产品验收开发输出的功能模块，并输出体验回归文档；测试根据用例验证需求逻辑，提bug、优化给开发。内网环境测试通过后，测试继续验证预发布环境、正式环境。第三阶段：版本发布。客服培训：测试验证的过程中，版本发布前，产品提前给客服培训新版本内容。发布：后端开发、运维人员将代码发布外网环境，前端输出外网正式包。产品运营将正式包上传各大安卓市场或ios -appstore提审。升级：所有安卓渠道包更新好，或者appsore审核通过，新版本也没有发现什么问题时，后端开发和运营人员打开升级配置，并发送升级通知。运营报告：版本发布完毕还未算完呢，运营人员在新版本发布后，收集用户反馈，进行数据监测、数据分析；评估新版本功能效果和影响，验证新版本功能以及输出下版本需求开发和优化建议。----哥不是分隔线----从以上APP项目研发流程来看，每一个版本研发都要经历以上3个阶段12环节，理论图上看是一条完整的流水线，但是如何保证流程顺畅进行？如何使项目成员工作效率最大化？这十分考验产品经理/项目经理的版本规划能力。当然项目成员间的默契和沟通也很重要。从笔者实践经验来看，要保证流水线顺畅，理想情况产品需求文档要领先前端开发2个版本，设计领先前端开发1个版本，后端开发领先前端开发半个版本。即在当前项目启动同时，产品经理已经在调研讨论下下版本需求；设计开始搞下版本的稿子；当前项目进行到一大半时，后端已经完成当前版本的需求，并开始准备下版本的需求预研。版本规划是产品经理根据需求优先级和开发进度预估定出来的，即每个版本要做什么，重点是什么，研发时间，上线时间等。一般来说，项目每发布一个版本都应该有它的意义和主打功能。App首个版本相对来说时间较长：app需要搭配开发环境，确定app技术框架，以及研发各种基础系统等。像这样时间较长的版本研发，产品经理和技术在需求评估时要将开发需求分阶段进行并且设置里程碑（尽量不超过3个），在每个里程碑（最长不超过1周）时间点，产品经理需要确认完成的情况，发现问题及时调整研发计划，控制项目风险，保证项目如期完成。后续开发的每一个版本都应该至少有一个重要功能，版本研发周期最好控制在2周-3周内。这样的好处一方面是保证项目成员有个良好的开发节奏，使研发效率最大化；另一方面保证每个版本有新东西给到用户体验，以及符合各大市场申请首发条件，获得免费的推广资源（ps：一般首发活动可以获得几千到几万的免费用户，还是挺吸引的）。当然重大功能上线的话，确保上线后版本的稳定性，可以将研发周期延至1个月，或者进行灰度发布。要尽量避免安排超过一个月研发周期的版本，否则要将长版本设置为若干个里程碑验收。经验来看研发周期过长往往会导致研发技术人员精力分散，工作拖沓，积极性下降。一般情况不建议频繁发布小版本，因为每个版本发布都需要测试，打包，发布市场，发升级配置和升级提醒等。频繁发布小版本造成测试和运营重复性工作增加，造成资源浪费；用户侧看频繁的升级提醒也是件很讨厌的事情。另外，建议外网运营客户端版本最多不要超过4个。维护老版本成本还是比较高的，比如做新功能还要考虑新老版本兼容情况，和各种后台数据接口升级、更新的兼容问题等。在特殊的情况下，有紧急的bug和漏洞时，才建议紧急发布一个bugfix版本。 -
敏捷游戏项目测试策略
2016-12-13 13:28:57
敏捷游戏项目测试策略(二)－摸着石头过河
以笔者所在项目为例，在项目初期我们也遇到了上文所说的各种困境，后来我们做了很多努力和探索，终于让项目逐步走上正轨，基本规避了大部分问题，那么我们是怎么做的呢？
笔者总结了下，基本可以用下面的12字真言概括，即：做减法、改思想、定流程、常总结。
我们通过实际例子来详细描述下12字真言，以及我们通过这么做取得了哪些效果。
一：做减法。为什么做减法？作为测试本身来讲，做减法是痛苦的，意味着某些更稳妥或从前被验证过有效的测试流程要做改变，也意味着保证品质的难度增加。然而为了整体项目的进度我们不得不这么做。那么我们怎么做才能在做减法的同时做好品质保证呢？
1.1，抛弃不必要的流程：
1.1.1）砍掉回归测试的大部分内容。如果我们按照传统的方式做测试，我们至少要做详细的回归测试，而实际项目版本更新速度是1周更新1版，时间根本来不及，只能砍，但是怎么保证品质呢？在做减法的基础上做加法，更加细化版本上线前的checklist检查，基本做到类似回归的概念，但是时间会减少很多。砍多加少，整体上是做减法。
1.1.2）砍掉不必要的测试用例评审。用例评审继续做，但是只做重点功能的用例评审，非重点功能用例不再评审。
1.1.3）砍掉会议中的无效时间。会议需要谁谁参加，只讨论必要内容，非群体沟通私下进行。
1.2，分拆功能测试与非功能测试。
项目组测试只测试游戏功能本身，其他的类似sdk测试，性能测试等统一放到平台组去做，让专业的人做专业的事，提升效率。项目中的测试人员减少了，但是更加专注于版本功能本身，从而也有利于保证质量本身。
1.3，灵活的集中测试。
举个实际例子，比如app提交审核前的检查，放到项目里做可能会耗费较长时间才能做完，而且鉴于测试人员的经验，还可能会发生遗漏现象。我们的办法是临时抽调几个对app审核非常熟悉的人，大家坐在会议室里，快速的把检查点做完。即能保证质量也能提升效率。
二：改思想：思维不改变，则执行无效率。
2.1，拒绝等待。
2.1.1）以前经常遇到某项工作没开始是因为等别人的结果，这种理由经常让人无可奈何。我们怎么做的呢？在每日进度核对（这个流程我们后面会讲）上，我们详细的核对每项任务开始结束时间，如有有必须等上一项任务完成才能开始的情况出现，我们会安排新的任务来填充这段等待时间。以此来保证工作饱和度。
2.1.2）另一个层面，敏捷项目，测试是不能等开发都开发完毕打好包后再开始测试的，而是任何一个功能开发完毕，甚至一个功能中某个阶段开发完毕，我们立刻更新资源到本地，然后立刻开始测试，尽量保证测试与开发同步进行。
2.1.3）坚决不等，我们测试要催促开发按时或提前提交代码，让我们能尽早开始测试工作。
2.2，少抱怨，多思考。
这里不是说不能抱怨，在我们的团队中我们甚至鼓励相互吐槽，目的是让大家尽可能从多方面得到反馈，哪些地方做的不好要及时改进，我们这种抱怨可以说是正方向的激励方式，大家关注的不再是抱怨本身，而是工作出了问题，怎么能第一时间得到反馈，怎么能想办法把问题解决掉，从而以后不再范同样的错误。
2.3，随时沟通。
当然这一项也可以归并到拒绝等待里面，单拿出来说是笔者个人认为再敏捷项目，沟通变得比以往更重要。我们项目中会提倡随时沟通的概念，有问题不要发邮件，或者聊天软件留言，尽量找到责任人工位，随时当面沟通，提升沟通效率和信息准确性。最怕的就是大家坐的很近还要通过邮件你来我往的沟通，不仅浪费大量时间，还会再沟通过程中降低信息的准确性。
2.4，抛弃内网bug数量的概念。
笔者经历过很多公司，很多项目中的测试管理者非常重视内网bug提报的数量，如果时间充裕的话，我觉得没什么问题，但是再敏捷项目，这可能成为项目的一个阻力。我个人认为提报bug很重要，但是比数量则失去了其本身的意义。在敏捷项目由于各种条件限制，我们把指标更换为外网事故数量。以此来衡量测试对项目质量保证工作的好坏。注意此处外网事故指的是通过现有技术手段能够测出来而没有测出来的bug。
三：定流程：
3.1，优化流程，并坚决执行。
不合适的流程一定要优化，还是说个项目真实实践流程改进的例子，之前项目任务不拆分，每周一大家开个会定下本周做什么就完事了，结果经常出现功能延期，版本无法定期或足量上线的情况。大家很郁闷，因为没法定量，很难确定到底是哪个环节出问题，等知道哪个环节出问题，再做调整时间上也来不及了。痛定思痛我们仔细分析讨论后，逐步把所有当周任务都拆分到每人每天工作量的细度，并每天下班前一起核对当天的完成量，这样我们能及时了解到版本进度，一旦出了问题，也可以及时协调资源来弥补。这个流程实施后，基本杜绝了版本延期的风险。
3.2，及时反馈，随时改进。
流程不是一成不变的，要根据实际工作情况及时调整改进。还是举个实际例子。我们的测试绩效考核内容变更过好几次。因为每个项目工作内容不大一样，而且由于我们分拆功能测试和平台测试，导致工作差异进一步扩大。所以我们前前后后根据实际情况调整了好几次绩效考核方案。最后调整到考核方案基本能跟实际工作内容相匹配。
四：常总结：
4.1，不在同一个地方失败2次。
我们经常会发现同一个bug会在不同的版本中出现，弄的大家挺没有面子。我们发现这个问题后，做了2个措施，让这种情况大大的降低了。一是我们每周组织一次测试部门与运营部门的事故核对会议，通过相互监督促进测试人员更加谨慎小心。二是我们开发了一套外网事故数据系统，将以往的各种外网事故数据都上传到数据系统中，让各个项目都能借鉴，尽量规避相同的问题再次出现。
游戏测试工程师之殇(三)－策略篇
接上两篇，本篇我们主要谈谈在整体游戏测试工程师综合素质趋于下降的趋势下，处在中小公司的游戏测试的工程师们为了做好日常工作和管理工作，应该采取怎样的措施呢？在此笔者结合近两年来在不同的项目采取的实践，来谈一谈这个问题。
三，策略篇
正式开始之前，继续解释一下，本文谈及的很多问题在BAT这种巨无霸公司里面是不存在的，毕竟他们有钱有时间去培养和沉淀。主要还是谈论在中小公司存在的问题。中小公司在资源投入上和知识沉淀上存在很多局限性，但是问题也是可解的，只要我们不断的努力寻求解决之道，努力结合公司实际情况不断改进，我相信在中小公司的测试工作都可以与BAT相媲美，无论是技术还是管理。毕竟，毛爷爷说过“星星之火，可以燎原”，微小的力量也许有一天也会发展成燎原之势。
好了，我们正式谈谈在中小公司可以采取的最佳实践有哪些？基本都是笔者经历过的几家公司不断总结实践而来，大家可以多多探讨，也许有更好的方式方法，一起来提升游戏测试工作。
01）把尽可能多的工作checklist化。
俗话说“好记性不如烂笔头”，一个游戏项目，研发领域各种各样的系统非常多再加上运营后各种各样的工作内容，单靠脑袋去记，很难避免遗忘，而任何遗忘都可能导致非常严重的事故。同样作为一些新人或者能力不够高的测试工程师，如何把工作做细致，尽可能的保证测试质量，各种检查内容checklist化是很好的一个解决方案。无需掌握太多技能和经验，一步一步自习按照检查列表走，就能保证不出问题。这也是我们放心让新手和经验不足的工程师承担更多工作和责任的有效机制。
02）培训培养。
在小公司搞培训培养很难，但是从投入产出比来讲，我们可以就适当的内容和技术进行一些培训，耗用尽量少的资源，来让团队的人员不断成长。这里的培训也不一定是指专门拿出时间来給大家讲课，也可以以多种形式进行，比如就某项技术或流程写成文档，让大家在业余时间学习。比如安排一项特定的任务，让员工在实际工作中去应用学习等等。一味的只让员工工作，而不去培养他们，从长远看，反而是对公司不利的。员工不断的成长的同时也能为其工作岗位带来更大的价值，从而提升了公司的整体价值。
03）鼓励和帮助员工进行一些新技术和新方法的探索。
在工作中，有的员工可能对某项技术有兴趣，那么我们应该鼓励和支持这种探索学习，引导他们把探索的技术应用到实际工作中，甚至为他们提供一些专业的书籍或者不限于公司内部的培训机会。员工和公司都会在这种探索学习中受益。举两个实际的例子，一个是笔者之前服务的公司，笔者的一个同事对ruby很有兴趣，团队鼓励和支持她，并给予了很多时间上的支持，从而完成了游戏后端的自动化测试框架。另一个例子是笔者现在服务的公司，某员工对自动化很感兴趣，笔者就跟她一起研究了基于python的selenium自动化测试，并在公司外联系了培训机构，利用业余时间給他们进行培训。我们最终把该自动化测试框架推广到了实际工作中，一定程度上提升了web测试小组的工作效率。
04）专业小组。
在笔者其他文章中也提到过这种方式，在中小公司，测试的技术实力和沉淀都是有限的，那么面对某些专业的测试工作，我们可以临时抽调一些经验丰富的测试人员组成一个测试小组，对这些专业化的测试任务进行测试，从而尽可能的提升测试效率。这个小组的工作内容也在工作过程中持续总结积累，自身也在不断成长，一些东西可以文档化的积累下来。那么当我们再次面临这种专业化比较高的任务时，我们就可以从容的去应对。这种方式比较适合人手不够多的中小公司。
05）绩效考核方式的变革。
很多公司对测试人员的考核过多的集中在bug数量上，笔者个人认为这在中小公司是不适合的。在考核日常工作上，笔者认为bug数的考核已经不再适应当前环境和时代，笔者把这方面的考核变更为工作量与事故比这种方式，工作量高，事故低都会带来更大的比值结果，相对公平和有效一些。毕竟我们绩效考核的目的还是促进员工不断进步，而不是消极的去惩罚员工。另外，笔者把员工的个人成长也放到绩效考核占比之中，虽然一个季度很快就过去了，但是日积月累的不断成长，还是会在绩效考核中有所体现，从而給员工自身带来实实在在的好处。
06）事故总结。
尽量保持每周都进行事故总结，中小公司在这方面反而是有优势的，不用费尽力气组织n多人一起开会，随便找个会议室就解决了。出错不怕，人非圣贤，大家在工作中都会范错误，怕的是在同一个地方犯错，我们经常组织事故总结的目的就在于希望大家能不断总结经验教训，不断保持谨慎务实的工作态度，这样整个测试团队就会逐渐重视自身的问题，从而不断的改进自身，达到自我进化的目的。一些经验不足和能力不足的测试工程师也会在不断总结中受益。
-
软件测试人员何时介入项目小组
2016-12-13 13:26:59
-
测试工程师KPI考核
2016-12-13 13:19:03
标题搜索
我的存档
数据统计
- 访问量: 33251
- 日志数: 23
- 建立时间: 2007-07-18
- 更新时间: 2016-12-13
