Cloud_Huan的专栏

移动app测试之个人理论

前言 在测试的过程中，你是否会有下面的几个烦恼？嗯，反正我有 。既然有烦恼，我们就应该解决它，今天就来分享一下一个测试策略的思路，帮助解决下面的问题用例的精简发版前checklist的优化版本发布太多，覆盖测试怎么办机型太多？兼容性很难测自动化主功能覆盖的依据专项测试的依据(性能、专项、压力).如何应对快速发版的压力如何最准确模拟用户环境和行为进行测试，完善测试点呢...

为啥有这篇文章？本来嘛，还没上升到模型理论这个高度，更多的只是吐槽。加入了个创业公司，app刚起步，作为一个有经验的测试(笑)，对所在团队人员组成以及能力突然有了自己的看法，再结合以前刚毕业所在公司的非创业项目组的经验，于是便有了这篇文章，人员只覆盖了产品测试开发这三个最相关最核心的职能，其他的没有深入了解也就不多说。 本文仅代表个人观点，本人不负法律责任。

功能测试层面经过两年多的踩坑和总结，测试思路基本稳定下来了。工作一年的时候有过一次测试方法和测试思路的总结，本篇正是在这篇基础上的扩充完善，基础思路就这么多，剩下的只是根据项目变化，所以命名为2.0的总结 :) 每一个优秀的测试人员都会在工作中形成自己测试方法—我刚毕业的时候一个大牛和我说的一句话，影响至今测试模式？建模！在编程中我们把一类问题的解决方法抽象成设计模式，那么测试也是一样的，可以

本文纯属个人观点，如果有不同意见，轻喷说道测试流程，很多人都知道需要评审，然后根据需求设计用例，然后测试。那么评审测试究竟在干嘛呢？我概述一下我以前刚工作问周边同事的理解，他们是这么样说的： 作为一个测试的角度评价这个需求，看需求完不完善，哪里有补充的地方，哪里有改进的地方。然后我抱着这样个心态做了两年测试，然后发现，每次评审其实测试都属于最打酱油的类型，评审玩之后除了了解需求提提小改进的地方

处在离职期，除了交接工作，空余时间还是挺多的，所以必须对以前的职业有一个总结。那么本篇讨论的是什么是一个真正的测试。那么期望是能写下这类文章，这也是那些年我走过的路 :) 纯粹是个人的理解，仅供参考，转载请注明出处(估计也没人会看 >.<) 论一个真正的软件测试工程师 自动化在项目中的应用 性能专项在项目中的应用 一、 半个产品 半个开发　　正真的测试，难道我们平常做的

前言： 作为系统测试工程师，你不需要对代码了如指掌，不需要掌握每一个方法，每一个逻辑，但是适当的阅读代码是有必要的。可是到底阅读到什么深度，需要掌握多少，这也是每一个测试工程师要面对的问题。阅读得浅了，往往会遗漏；阅读得深了，浪费时间，我又不是开发，也没必要，是不 @.@分级理论：为了更好地区分对代码的理解程度，个人主观是把开发代码分级了，这个分级个人主观偏多，如有不当，欢迎指出。 分级一

插件式开发是什么，有什么优缺点，测试有什么注意点，这个今天就来谈一谈。在开始前先来复习一下基础知识反射 反射，在程序运行的时候才根据名字去动态加载类，方法，相比于import的方式，不需要在编译的时候就必须知道，而是运行的时候一个动态的过程，因此，具有非常好的灵活性。.dex文件 这是安卓的二进制文件，java最终输出是.class或者.jar，而android则是对许许多的.class

因为现在服务公司的原因，然后去面了个试，有点感触，关于能力的。分为两个部分吧： 1.对业务内在的理解能力 2.对业务服务的技术能力个人感觉这两点是衡量初级中级测试工程师的能力吧，高级不敢乱发表意见，因为我最多算是中级(拿工作年限衡量能力的除外，我也才工作了一年半)1.对业务内在的理解能力其实对应的是写过的测试分析方法中的客户端逻辑类，客户端的逻辑实现，不否认开发GG的代码是根据需求文档实现的，但

咳咳，元宵节再写一篇出来吧，因为项目近期不忙，这一篇要说的是测试流程的知识，基本面试必问的了，回答也会回答得出，区别只是在于描述得详细与否了。下面会有两个部分，一个是基本的核心，另一个是改进版本。核心版本(喂，这是个真正工作过的测试应该都知道吧)：需求评审--开发--编写用例--开始测试--回归BUG--发布改进版本(各个公司的改进版本，更适合某一项目，而不是通用)

最后补充测试方法

其实有时候自己会思考，假如有一天需要自己负责一个新的apk，整个测试组只有我一个人，那么我会怎么办。这个问题也是挺有意思的，之所以会思考写出来，是因为我知道如果面对这个问题，我一定会手足无措的，所以先来玩玩 :)整个立项到发布的整体流程以后再写吧，这里从开发的预研开始。其实我还是建议测试了解开发逻辑是从有一个成品的apk开始，因为如果从预研就去深入的话，中间变动太大，前期app

前言： nick说过，没个人都要有一套自己的测试方法，针对模块有一套自己的解决思路，之后一直在寻找。这就是个人的测试分析思路，元素分析： 这里之前一篇只分析了静态的元素，经过工作中实践后应该扩展为动态的元素以及关联的元素：元素分析法=静态+动态+关联静态： 一个activity(界面)中的一个view(组成的最小单元)为一个元素，那么元素分析就是针对这里的没一个view设计测试点。动

遗漏的知识点 adb分为三个部分，PC端的client pc端的service以及手机端的adb进程 Adb bugreport 打印dumpsys dumpstate logcat的输出 Adb uninstall -k参数表示保留数据 Adb shell pm list package [-s] [-3][-f存放位置][-i来源] Adb shell pm path [pkgname

背景： 对于没学习UML语言之前，整理逻辑时候是world文档格式进行的，通过自然语言描述需求和逻辑点，小的需求逻辑还好，但是大的逻辑点写的东西也就特别多，然后过一两周回来看的时候脑袋都会晕乎乎的，而且给别的测试同学看我写的模块的时候，理解成本增加了许多，所以试着引入了UML语言来帮助整理逻辑模块以及提高平常测试工作中的效率。 UML是什么？ Unified Modeling

那么这一篇呢，针对的是逻辑做的灰盒测试，一般是指需求文档上没有的内容，但却是技术方案的核心，逻辑分析针对的就是实现测试。

写在前面：咳咳，翻了下博客，发现已经有两个月没有写任何东西了，理由很简单：忙着旧公司的离职交接和找新工作。那么新的工作已经敲定了，成功进入了深圳的某BAT公司(撒花~~~)，磨合了一周总算是大部分习惯了公司的文化，终于可以安静下来思考思考了。关于如何快速上手项目：刚入职接触的不仅仅是新项目，还有新的工作环境，再加上新项目接触的技术都是和以前方向不太一致的方向，或多或少心里会有一些焦虑。...