51Testing软件测试论坛

标题: 【你来问我来答第54期】：笑傲测试----测试对象的识别与分析（已结束） [打印本页]

作者: lsekfe 时间: 2015-1-4 09:46
标题: 【你来问我来答第54期】：笑傲测试----测试对象的识别与分析（已结束）
[attach]93457[/attach]
论坛ID：Jackc（论坛版主）
真实姓名：陈华阳
现任公司：武汉明源股份有限公司
现任职位：高级测试工程师
工作经验：
毕业后总是四处奔波，供职于ZTEàTelecaàFIHà Mysoft,。长期侵泡在手持终端的各类测试中，最近开始研究ERP测试。
擅长技术领域：手持终端测试、ERP测试(B/S)、测试管理
[attach]93458[/attach]

作者: lsekfe 时间: 2015-1-4 09:51
本期的专家测试经验很丰富，在移动终端和(B/S）、测试管理上有独特的见解，希望大家踊跃提问。

作者: 楠族开心果 时间: 2015-1-4 13:02
哇，Jackc帅哥露面啦

作者: 赵佳乐SMILE 时间: 2015-1-4 15:55
支持~~~

作者: hlhong 时间: 2015-1-4 17:06
你好！麻烦对ERP的测试给一些建议，谢谢

作者: blackn72 时间: 2015-1-5 08:44
对于终端安全测试、自动化测试、性能测试，有什么好的工具？

作者: zm51testing 时间: 2015-1-5 09:03
一直是用的手工来测试手机终端，请问前辈：需要提高手机终端的测试，应该主要学习哪些？

作者: rose_flower0508 时间: 2015-1-5 11:18
您好，前辈！现在测试发展的趋势，您觉得是移动端测试比较热一点，还是web测试比较热一点。本人是，这两个个测试都会一点，但是现在想选其中一个方面进行深度发展。还有，用您的感受说一下，你觉得web测试和移动端的测试最大区别在哪里，一开始接手这样两个项目时，你是如何做准备的。谢谢您！

作者: zm51testing 时间: 2015-1-5 13:49
前辈：您好！如果要在手机客户端发展，应该往哪些方面深入？是android代码还是mokeyrunner?

作者: 小余最近比较忙 时间: 2015-1-5 17:43
你好，刚接手APP的测试，对于这块有些不明白的，请教下。
1.APP测试需要关注网络连接情况吗？即wifi和移动网络（2G/3G/4G）情况。
2.app的兼容性测试重点是什么？
求大大给些这方面的资料或推荐下这方面的书籍，谢谢。

作者: Jackc 时间: 2015-1-6 10:50

hlhong 发表于 2015-1-4 17:06
你好！麻烦对ERP的测试给一些建议，谢谢

额，其实根据实际问题，才能得到对症的建议。范范的问题，通常只能拿到模板式的答案。。。
传统的ERP系统以下方式分解：
1. 从测试方法的角度来看，可以分为以下7种测试目标类型：
   1.1 数据结构：
         表字段的创建和修改没有什么特殊的测试技能要求，按照需求设计文档查看数据库结构即可
   1.2 程序界面
         界面根据测试目标的不同属性，又可分为查询控件、视图、菜单、按钮…… 等，可将相同类型的测试目标提炼公用测试方法或用例(根据ERP框架对控件的设计，可以考虑在此切入灰盒和自动化测试)
   1.3 程序功能
         程序功能的分解因不同的设计而异，此部分的进一步分解只能根据实际情况来分析。
   1.4 场景流程
         ERP在流程场景中常会遇到2种情况：
         1.4.1 流程同一个分支存在较多的判断条件：单独分解每个判断条件包含的元素(通用的等价分解即可实现)，再将分析结果按判断条件之间的关系使用判定表或正交组合出场景清单
         1.4.2 存在多个循环嵌套的业务流程：将每个循环作为独立的分析对象，从内到外逐层分析。若存在复杂判断，参考1.4.1
   1.5 数据清洗
         以数据源为基准，以等价法独立分析每个数据源字段，再根据数据源之间的关联规则，使用正交或两两组合的方法整理数据源清单。(通常ERP报表/部件的数据源较复杂，故不建议使用判定表法，在整理数据源清单过程中，还可根据数据源特性进行分类，如包含多个独立存储过程的数据清洗，可以按照存储过程对数据源进行二次拆分)
   1.6 数据导数
         导数测试的数据分析并不难，比较麻烦的是需要将导数部分与ERP功能进行关联分析，理清哪些功能受导数影响，以框定测试范围。
   1.7 性能
         性能部分需要根据测试目标实体的瓶颈来具体分析

作者: hlhong 时间: 2015-1-6 15:31

Jackc 发表于 2015-1-6 10:50
额，其实根据实际问题，才能得到对症的建议。范范的问题，通常只能拿到模板式的答案。。。
传统的ERP系 ...

首先，非常感谢您的回复。追问：
1、“数据导数”是什么意思，ERP中什么地方会用到数据导数呢？
2、如果要实施自动化测试的话（包括功能测试和性能测试等），用什么工具比较合适

作者: Jackc 时间: 2015-1-6 15:35

blackn72 发表于 2015-1-5 08:44
对于终端安全测试、自动化测试、性能测试，有什么好的工具？

目前嵌入式测试的工具化没有像PC平台一样规模化(非垄断商业化的必然产物)，所以不存在通用的‘好工具’，而是根据OS进行选择。

就目前而言，在国内开展手持终端的自动化测试，仅仅适用于冒烟测试，而功能和性能的自动化测试，收益不大，仍处于撑门面的东东
（目前手持终端系统各个里程碑版本间的API均可能存在较大差异,甚至经常在国内是无法获取到测试所需的API(目前国内大部分手机企业还处于第三方APP开发的地位，很难获取到OS生产商的全力支持)，导致测试环境搭建与维护均存在瓶颈)

环境搭建：建议使用linux搭建测试服务器环境
*IOS(10.7以上)
  instrument、Appium
*Android(4.2以上)
  Appium、Robotium*Symbian(S60以上)
  TTCN：根据AT指令集为基础开发的测试API，适用于接口与集成测试
  ASTE：根据控件API开发的UI自动化测试工具，适用于功能测试
*MTK
  暂无(可以自己调AT指令集开发monkey tools)

备注：
1. 关于脚本语言的学习选择，如果有明确目标，根据工具要求学习对应语言即可；若无目标，建议学习轻量级的脚本语言，如Ruby
2. 其实目前IOS/Android 的功能自动化测试工具的原理均大同小异，均是基于OS控件，调用已有服务或程序代码桩，实现UI录入与检查
3. 安全测试工具目前没有开源，这部分需根据调用的协议的加密规则，设计测试桩，并通过抓包后反编/解码的方式来自行开发测试工具
4. 至于性能测试，不太明白预期期望是什么。如果是功耗，可考虑将OS自带的系统监控工具信息logs出来，或者通过电流监测来实现；如果是UI反应速度，则可以考虑设计测试桩或使用其他仪器(高速摄像机)实现

作者: Jackc 时间: 2015-1-6 16:58

zm51testing 发表于 2015-1-5 09:03
一直是用的手工来测试手机终端，请问前辈：需要提高手机终端的测试，应该主要学习哪些？

其实我不能很好的回答你的问题，原因是目前你能学到的技能，和你所在的客观环境（公司）存在密切的关系，很难在一家公司里，能将测试域的所有技能都学全，但是你可以根据公司的特点，专精某些测试技能。
-------------------------
测试域的技能大致分为5个方面：
1.业务知识：适用于测试目标的业务背景知识域
2.测试方法：目标分析(需求、测试实体)、测试设计(策略、用例)、测试实例化（环境部署、执行）
3.测试控制：测试标准(入/出口)&流程、质量评估(监控、总结、评估)、测试里程碑管理、人力资源管理
4.流程控制：项目开发标准&流程、项目里程碑管理
5.开发技能：开发模式、代码/脚本编写、测试工具原理
-----------------------
针对于手持终端而言，区别在于对手持终端特有的业务背景与测试方法学习的深度。
1. 手机整机测试(目前国内只有少数生产商，地域受限于珠江三角洲一带)
可以参考之前的一些建议12#：http://bbs.51testing.com/forum.php?mod=viewthread&tid=440341&page=5&authorid=242574
简单来说，如果你正处于一家手机生产商企业，在2年内，则大可将你所有闲余时间都投到手机的各个生产阶段中，了解整机研发的2条主线：
1.1  芯片-->硬件-->驱动-->组装
1.2  芯片-->系统-->程序-->驱动
主线中各个测试目标的可测性及测试方法，至少达到了解的程度。再根据个人对自己的职位目标，选择学习重点。
2. 第三方APP测试
功能手工层面的学习不再累述，主要谈几点额外的东东：
2.1 工具化：‘测试人员开发测试工具，开发人员使用工具，简单功能测试外包’的趋势逐渐浮出水面，如果期望能在测试域的技术上有竞争力，工具化技能是必修课。但是手持终端的工具化还不成熟，不建议像PC测试一样，依靠某1~2个工具的使用端上‘铁饭碗’。学习重点关注于‘工具原理’，在学习使用工具过程中，并不是为了更熟练使用工具而学习，而是为了后期切换‘测试工具开发’作基础准备。在这个学习过程中，将会了解各种协议标准、AT指令等
2.2 测试/项目控制：随着‘敏捷化’流程被越来越多的公司青睐，各种流程标准，质量标准再也不像CMMI年代那么清晰。如果没有理解过‘何为标准流程’，很难在今后的质量评估中有所建树。所以，即使现在用着轻量化流程，但也需要学习重型流程，了解重型-->轻型的过程，才能为各类‘敏捷’问题指明方向。
  2.3  编码：这一点不想多说，如果期望在今后激烈的测试竞争中保留最基础的竞争力，多花点时间在编码上吧。不是说要精通多少门语言，只需要熟练1种语言即可。

学习技能的基础原则：学习过程中自己觉得难的、花费时间长的，往往才是核心竞争力的技能。短时间速成的技能，只能是上岗技能，根本不具有竞争力，因为那玩意任何人都会。

作者: Jackc 时间: 2015-1-6 17:36

rose_flower0508 发表于 2015-1-5 11:18
您好，前辈！现在测试发展的趋势，您觉得是移动端测试比较热一点，还是web测试比较热一点。本人是，这两个 ...

其实Web或Mobile都不是择业的第一优先级条件。
首先，择业选择的是‘公司’，可谓是‘老板指哪里，我就在哪里’。优秀可持续发展的公司，不管它是做Web还是Mobile，都是最优先选择的对象，而该公司对应的业务，自然也是你学习的方向。
其次，如果没有心仪的公司，建议以Web为主，原因有二：
1. Web的测试技能基本可以通用，测试方法相对于终端测试会少一些
2. 国内基本没有手持终端的核心技术(就算有，也离国际水准较远，卖卖第三世界国家还可以。。)，行业主导力不强，导致需要经常学习完全不同的业务背景（其实就是职业竞争力欠佳)
------------------------
至于Web与Mobile的测试根本区别
从手机测试 ---> B/S测试，测试基础方法没有差异。我只是将自己放在测试新人角度，将已掌握的测试方法套用到新的业务背景上去而已。
1. 学习测试目标的业务背景，并按照自己能理解的方式作分类(整个过程大约5个月左右)
2. 将测试目标重新分析，并将测试目标通过基础的测试方法进行实例化 (一般情况下，如果只做单个业务背景的测试，是不需要完全重新分析测试目标的，只需要分析差异点而已)
3. 分析测试结果，识别薄弱的业务背景并补齐。(大约2个月左右)
4. 学习系统结构，数据结构，作手接口/工具化测试

小结：整个过程中，我的目标很单一：‘将测试实例化为可执行，可检测的实体’。实际操作过程，缺什么就补什么。

作者: rose_flower0508 时间: 2015-1-6 17:40

Jackc 发表于 2015-1-6 17:36
其实Web或Mobile都不是择业的第一优先级条件。
首先，择业选择的是‘公司’，可谓是‘老板指哪里，我就 ...

谢谢 Jack

作者: Jackc 时间: 2015-1-7 17:13

小余最近比较忙发表于 2015-1-5 17:43
你好，刚接手APP的测试，对于这块有些不明白的，请教下。
1.APP测试需要关注网络连接情况吗？即wifi和移动 ...

1.APP测试需要关注网络连接情况吗？即wifi和移动网络（2G/3G/4G）情况。
需要关注，但仅仅是关注是否能够使用多种协议连接，而连接的性能不在普通第三方APP关注范围内。
APP网络兼容的测试范围取决于终端支持何种协议，其实可以在APP的系统兼容测试中覆盖，无需独立测试。
举个例子，开发第三方IM类型的APP，要求支持WM6.5+/ Android 4.3+/ IOS10.7+等OS，在系统测试中，先根据OS选择测试实体机，再根据不同OS支持的协议类型，以及不同OS封装协议后遗留的接口确定测试对象范围。（并不是每个协议都预留了接口，有时候会将多个协议打包封装接口，比如将TCP/UDP 打包封装后，提供一个外部接口供第三方APP调用。）
我们在实际测试中，只需要确保APP能调用OS提供的协议模块接口即可，至于被封装协议本身功能，则不在测试范围内。

2.app的兼容性测试重点是什么？
APP兼容性的优先级排序：OS类型-->生厂商品牌-->系统版本(品牌版本)--->产品型号--->显示屏规格
根据测试资源的多寡，对优先级排序中的分支进行覆盖，不需要追求覆盖所有分支，最低保证1,2级根节点被覆盖完全即可。

求大大给些这方面的资料或推荐下这方面的书籍，谢谢。
嵌入式测试的书籍上面我帮不上忙，我自己的理论和经验大多都是从各个公司自身的资料获取提炼的。。。。

作者: Jackc 时间: 2015-1-7 17:30

hlhong 发表于 2015-1-6 15:31
首先，非常感谢您的回复。追问：
1、“数据导数”是什么意思，ERP中什么地方会用到数据导数呢？
2、如 ...

1、“数据导数”是什么意思，ERP中什么地方会用到数据导数呢？
   导数类需求多出现版本升级/个性化底层开发需求中。当需求涉及基础数据结构调整，则可能会出现。
   如，客户部分原始数据存在表table_project 中，客户买了新版本的系统，而新版本系统中，该部分数据已被调整存储到table_N_projct中，且两表之间的数据结构存在部分差异。故我们需要将table_project 的客户数据导入table_N_projct表中，并需要根据新表的数据结构，调整原始客户数据的部分字段。
   这类需求则是‘数据导数’。

2、如果要实施自动化测试的话（包括功能测试和性能测试等），用什么工具比较合适
   自动化测试工具选择，优先考虑目前已规模化的QTP和LR。
   如果因为本身ERP特性（如使用的框架较为久远）无法使用规模化的功能测试工具，则可以考虑使用selenium为核心自行开发UI测试工具(开发和维护成本较高)

作者: Miss_love 时间: 2015-1-8 19:01
你好、1、针对B/S架构测试，如何对session和cookies进行测试？

作者: 心晴~~ 时间: 2015-1-8 21:00
大神，我想请教一下如何写erp的测试用例，我现在也是在测试自己公司用的erp，但由于平常测试偏向于组装测试（看程序是否按设计的流程运行）和确认测试（利用各种类型的数据测试系统的健壮性），所以我平常都是按流程和相应的数据来测试的，都没有写测试用例，求教大神指点。ps：最好能给出几个关于ERP的测试用例的例子。

作者: 心晴~~ 时间: 2015-1-8 21:07
我的提问怎么没看到，太心塞了

作者: lsekfe 时间: 2015-1-9 08:49

心晴~~ 发表于 2015-1-8 21:07
我的提问怎么没看到，太心塞了

可能到了后台在审核吧~

作者: 心晴~~ 时间: 2015-1-9 08:59

lsekfe 发表于 2015-1-9 08:49
可能到了后台在审核吧~

刚刚才看到，呵呵

作者: zhanghl820716 时间: 2015-1-9 13:57
我现在负责测试项目是上万人在用的企业EIP管理平台系统，目前准备替换原来的门户管理系统，目前功能需求实现是成熟了，只要是是否满足大量用户的使用，性能的稳定，针对性能测试方面我应该做哪些准备啊？

作者: 地壳 时间: 2015-1-9 16:18
您在测试的过程中，关于碎片化有什么好的处理方法，可以分享一下吗？

作者: wangyixiong 时间: 2015-1-10 09:14
我想问下jmeter分布式测试，响应数据为空是咋回事呢

作者: Jackc 时间: 2015-1-12 13:16

Miss_love 发表于 2015-1-8 19:01
你好、1、针对B/S架构测试，如何对session和cookies进行测试？

Session和cookie的测试方法并没有什么不同，主要区别在于测试环境的不同(Session在服务器测试，而cookie的测试则在浏览器)
以下以Session举例，cookie可参考。
1. 黑盒测试
1.1黑盒对于Session并没有太好的测试方式。主测试过程为2条：
   1.存储Session（通常是通过事件来触发，如未检索到页面访问请求中的Session ID）-->读取Session(也是通过事件触发，如检索到Session ID)
   2.存储Session-->删除Session-->页面请求消息到来
1.2测试范围：
   Session的主要测试范围取决于需求，也就是‘存什么’和‘删什么’，通常都是存一些地址，用户信息以及时间的东东。
1.3其他测试范围(可选)：
   1.关联功能测试:如，Session 的 Time out时间测试
   2. 容错测试：如，B/S会话过程中，消息中断/回复测试
   3. 兼容测试：如，主流的不同浏览器内核

2. 自动化测试
2.1.自动化测试主要是通过在代码中打测试桩来实现，如，已知服务器某一事件存储Session ID，然后在会话结束的代码前打入测试桩Session["ID"].tostring()，再与工具的验证点进行匹配即可。必要时，也会在浏览器端进行相同的验证。
至于Session的基础属性，如Time Out，也可以通过直接在代码中打印logs的方式进行验证。（当然，一些潜规则还是需要简单了解，比如，如果Time Out没有设置，则为20min）
2.2.系统的自动化测试没有接触过，不做分析。
3.Session 和cookie的区别
3.1 两者在原理上没有区别，但因为各自运行环境和功能目的不同，导致集合和属性有一些差异，这部分建议在测试之前提前学习。
3.2 两者在测试范围上，除功能测试外，其他类型的测试在侧重点上有差异，建议根据产品的最终用户环境来进行取舍（如，通常情况下，Session 测试更关注性能，而cookie测试更关注兼容性）

作者: Jackc 时间: 2015-1-12 14:21

心晴~~ 发表于 2015-1-8 21:00
大神，我想请教一下如何写erp的测试用例，我现在也是在测试自己公司用的erp，但由于平常测试偏向于组装测试 ...

1. 每个测试团队/个人，选择的测试方法往往与客观环境息息相关，所以，我告诉你的东西并不一定适合你，只希望能给你一些思考方式，你再通过自身结合实际情况，创造出适合你自己的测试方法。

2. 根据你提供的已有测试信息，建议使用测试目的为导向的测试分类（即首先确认先确认达到什么样的测试目的，再选择测试方法，最后将相似的测试方法进行分类汇总）。
可参考的测试分类：测试要点控制，测试数据控制，测试流程控制(鉴于以往测试中，未进行较小粒度的测试类型划分，且测试系统相对你个人来说，已经较为熟悉，故不建议使用测试用例控制)
测试要点控制：复杂场景流/数据清洗，均可使用。建议以思维导图的模型为基础，利用树枝图的特点，将复杂的测试对象按照不同的属性逐层分析(分析的最小粒度标准为简单易懂的元素)，在重新分类汇总以后，可以通过组合方法（两两，正交）得到测试要点的场景流和数据流（组合的过程可以在思维导图中完成，也可以使用表格工具完成(如，Excel)）
测试数据控制：有明确的输出验证标准时，还是使用你原先的‘测试流程控制’，如，在ERP中新开发一张客户报表，已有客户数据库及客户历史非ERP报表时，使用测试数据流控制的方式可以更高效。(但是开发人员排查bug的时间会比较长)
测试流程控制：建议分为2类
2.1 简单的ERP功能需求：在需求文档已经足够支撑开发/测试时，并不需要更多的测试策略和设计。此时可以直接‘按需测试’即可。（如，页面添加独立的字段，且与其他页面关联较小的需求）
2.2 验收测试中的主流程测试：首先需要清理一份较为完整详细的ERP功能结构图(建议以页面为骨架，页面元素(列表、视图、最好包含字段)为最小颗粒度)，在图中尽可能标识出的各个元素关联关系（同一页面元素的关联可以不用标识(复杂的可以标记一下)，不同页面元素的关联关系是标识的重点）。需求开发时，将需求功能刷新到ERP结构图中，可以框定该需求功能的关联测试范围，进而得到验收测试的主流程测试场景（此部分也建议使用思维导图完成）

3. 测试方法的拓展：当对ERP业务知识了解更深入时，可以调整原有的测试方法。如，添加某个功能的权限，标准测试模型是测试授予/取消权限以及各种授权方式(岗位/角色授权)等；但是如果熟悉ERP权限配置的文件(.XML/.config)以及功能主键（如function id）等，就可以通过检查配置文件和数据库的方式来进行检查测试，而不需要切入ERP复杂的权限场景流中进行逐一的功能测试。(注意：并不是说，在验收测试中，就可以直接拿掉此功能主流程的测试，只是在功能测试中裁剪掉而已)

备注：公司用例和标准模板不太方便粘贴，请见谅。

作者: 心晴~~ 时间: 2015-1-12 16:01
Jackc大神，您的回复已经很细心了，教给我了大体测试方向和方法，帮助我理清现在测试时较混乱的问题，非常谢谢！

我需要多一点的时间把您教的内容好好消化一下内容

撒花！撒花，再次表示感谢

作者: Jackc 时间: 2015-1-12 17:01

zhanghl820716 发表于 2015-1-9 13:57
我现在负责测试项目是上万人在用的企业EIP管理平台系统，目前准备替换原来的门户管理系统，目前功能需求实 ...

其实，万人用户这个测试依据其实没有太大的意义，关键条件依然是同时在线的用户数

1. 输出性能测试标准
1.1 收集客户使用系统的业务背景资料，主要是客户是怎么用系统的。
      比如，1万用户，每分钟在线的峰值是多少？客户使用频率最高的功能是哪些，各自大约占比为多少？
      这部分资料将为你的性能测试提供重要的评估指标，也将为你在选则性能测试的功能范围提供基础的测试依据。
      理论公式（看看就行，其实它算的相当不准，最终还是要根据收集的资料，对结果数据作二次调整）：每分钟在线用户数=用户总数/用户总登陆时间*单个用户操作时间
1.2 整理服务器资源消耗较大的功能清单。如，EIP中的多层的数据清洗，以及一些复杂界面(复合报表，图形)的加载等等。
1.3 如你们的EIP是分布式部署，则还需要在1.1&1.2的基础上，按照功能部署的服务器和数据库整理出功能分布清单。功能分布清单主要是在复杂系统中，提供可用于测试目标对象的测试重点。

2. 分析其他影响因素，着眼点在于服务器关联信息是否存在性能风险。如内网/外网不同的服务器，性能可能不同。

3. 整理测试工具，哪些可以用开源工具，哪些需要自行开发以及工具需求，最好在测试前期拟定计划并推动。

作者: Jackc 时间: 2015-1-12 17:52

地壳发表于 2015-1-9 16:18
您在测试的过程中，关于碎片化有什么好的处理方法，可以分享一下吗？

你的这个问题，之前的同学已经提到了。
说实话，移动端的碎片化并没有完美的解决方案，因为完美答案是：在客户可能使用的所有环境中进行最低为验收级别的测试活动（可能除了IOS APP，其他APP基本不能做到这一点）
以Andorid为例，在Android的开放平台下，我们看上去只有1种方式来为用户手机进行分类汇总：手机型号（其实IOS也是用这个分类来进行兼容测试的，只是IOS型号较少而已）

没有办法使用标准的方式来框定测试范围，我们只能在容忍部分已知风险下，来进行更大粒度的终端分类：生厂商品牌-->系统版本(品牌版本)--->产品型号--->显示屏规格
分类原理来源于bugs严重级别评估标准中的’客户发现率‘为基础依据，整理出的测试标准和范围。

其实国内外在早2年已经识别到这个问题，目前期望于通过云来解决设备共享问题，如东软的易测云，它们虽然不能完全解决移动端目前的碎片化问题（完成整个Android碎片化测试需要几百台不同的移动终端，我个人认为目前还没有测试团队能够达到这个测试环境的要求）

备注：
假设终端数量超过了测试团队的人力资源，则可以在用户使用频率较低的终端只验证主要功能，如安装/卸载等

作者: Jackc 时间: 2015-1-12 18:07

wangyixiong 发表于 2015-1-10 09:14
我想问下jmeter分布式测试，响应数据为空是咋回事呢

1. 检查一下controller 和agent 的端口号是否被占用。（查看端口使用APPID可以百度）
2. 检查防火墙

作者: 心晴~~ 时间: 2015-1-14 10:19
Jackc大神，我们公司不是专门的软件公司，现在要开发一款APP,需求只是一些简单的功能点，现在老大说我这边要控制APP产品的质量，我该如何控制呢？压力好大的感觉，也不知道如何控制，感觉完全没有一个标准点去控制？

作者: huyouyou1031 时间: 2015-1-14 15:41
请问一下，手机应用APP需要做整机兼容的测试吗？
如果要做的话，市面上这么多手机品牌，岂不是成本很高？
是否有需要去做这个兼容呢？

作者: pilottest 时间: 2015-1-15 16:45
请问一下，我是测试电力产品的，如电力仪表及电力系统类的，测试电力仪表产品居多，我们公司居多是手工测试，有什么好的建议类，这么测试下去感觉到有些迷茫。。。

作者: Jackc 时间: 2015-1-15 16:47

心晴~~ 发表于 2015-1-14 10:19
Jackc大神，我们公司不是专门的软件公司，现在要开发一款APP,需求只是一些简单的功能点，现在老大说我这边 ...

1. 你老大这样说，其实是他对到底怎么控制质量不清楚。不过优秀tester应该具有一定的QA水平。
2. 简易需求文档一般都能支撑测试策略的实例化，如，测试范围、测试执行实例化(测试方法、测试环境、测试工具等)、测试里程碑等
3. 简易需求文档通常不能支撑测试执行的细节部分，如，核心逻辑的测试执行实例化、用户感受用例的实例化等

供参考的测试前期步骤：
1. 需求分析：
1.1 需求分类：
      先将需求文档的各个功能划分出来(我通常是按照物理存储数据的用途来分类，如，客户信息、消息信息、配置信息等)。并在每个类型下根据
需求文档描述的内容，再向下拆分1,2个层次（粒度不需要很细，比如最小粒度为页面或者控件类型就OK了，不需要把同类控件的每个元素都列举出来）
1.2 需求分析：
      根据1.1的目录，整理出实现效果可能存在二义性的部分（如，某类消息数据存储，既可以存在服务器上，也可以存在本地，而需求文档中未指明实现方式）
      将二义性的部分与设计或者开发人员沟通，确认实现效果。
2. 测试实例化：
2.1 先框定需要实例化的测试类型（功能、性能、本地化等），如果某类测试需要前置条件才能实现，将前置条件作为风险写明，而此类测试作为变量安排在后期的测试生命周期里。
      测试类型的选择不难，主要还是需要你自己来度量测试的深度（通常可以和决策者以及开发人员沟通着来制定，如性能部分，只做长周期测试，不做负载测试等。你所有的沟通筹码只有2枚：成本和价值）
2.2 根据2.1框定范围，细化非功能测试的内容。如工具化使用哪种工具，碎片化选择哪些平台等）
3. 功能测试用例设计：
不建议使用测试用例，可以考虑使用测试要点来实现。粒度到可以清晰指导测试执行即可，如，标准文档编辑框(它可以代替文档框的字符类型、字符长度、存储等文本框的测试用例)
4.  注意事项：
   4.1 在设计出口标准时，多和决策者/设计沟通，了解客户使用场景以及尽可能理解用户的实际期望。
   4.2 此类项目需要频繁与开发人员沟通，在沟通过程中，最好能经常站在用户角度多想一下（很多时候，开发人员能做少就不愿意做多，所以在细节实现上，经常出现功能实现，但使用不便的情况）
   4.3 测试里程碑多和开发Leader沟通，根据开发进度来调整测试进度。
   4.4 如果涉及需要开发辅助的部分，如帮忙写个测试工具什么的。尽早与开发沟通，以便双方明确需求，以及方便开发安排计划。
   4.5 这类项目都建议使用Monkey Test，具体的实例化可以与开发共同完成。

作者: Jackc 时间: 2015-1-15 16:55

huyouyou1031 发表于 2015-1-14 15:41
请问一下，手机应用APP需要做整机兼容的测试吗？
如果要做的话，市面上这么多手机品牌，岂不是成本很高？
...

其实目前做兼容测试的公司并不多。如果比较关注成本，可以在熟悉平台后，引入一些等价类策略来减低测试成本（如，OS高版本兼容低版本，屏幕分辨率比例占比高低等。）
备注：
这类的等价类策略都会存在一些风险，比如android 4.0 测试通过，实际上并不能完全保证2.3就没有问题，关键还是要看APP在实际开发过程中是否使用调用了4.0新增的API和方法。

作者: 心晴~~ 时间: 2015-1-15 21:00

Jackc 发表于 2015-1-15 16:47
1. 你老大这样说，其实是他对到底怎么控制质量不清楚。不过优秀tester应该具有一定的QA水平。
2. 简易需 ...

每次jackc大神的回复都很详细，很感谢！

读了几遍后，感觉我现阶段只实现了功能点的细分后，就开始手工测试，测试时会记录每个版本的功能点的测试点和发现的bug（我发现记录了这两项后，做回归测试就方便一点了）；性能部分，是要测试接口处理请求的响应时间长短吗？我现在测试app时，会发现点击某个按钮，实现某个功能（如取消订单那功能），很久才会提示成功，我现在不知道是服务端接口的问题，还是app前端的问题，能给一些建议吗？

作者: neijiangwlz 时间: 2015-1-16 14:25

pilottest 发表于 2015-1-15 16:45
请问一下，我是测试电力产品的，如电力仪表及电力系统类的，测试电力仪表产品居多，我们公司居多是手工测试 ...

我以前也做过类似产品的测试，不过是软硬件结合

作者: Jackc 时间: 2015-1-17 09:14

心晴~~ 发表于 2015-1-15 21:00
每次jackc大神的回复都很详细，很感谢！读了几遍后，感觉我现阶段只实现了功能点的细分后，就开始手 ...

‘性能部分，是要测试接口处理请求的响应时间长短吗？’
手持终端上比较常用的(性价比较高)性能测试包括：
* 长周期(LPT)：持续运行APP（monkey 可以实现）
*功耗(PCT)：包括电量、内存、流量等(大部分都有现成API或规模化工具，简单开发后可实现。(也可以通过其他方式来间接实现，如反复运行/关闭APP，查看是否存在内存泄露等)
*响应时间(RTT)：程序应用在某个功能上的处理时间，具体测试方法也是五花八门。
                           1. 最常规的方式是直接在写测试桩，这样基本能得到所有期望的信息。如，你提到的APP与服务器会话的功能，只需要3类测试桩打印出时间logs就可以辅助你定位问题根源：APP上层指令触发会话的事件的时间、APP每次收/发会话消息的时间。如果对协议格式内容有一定了解，也可以将会话内容logs出来，分析head或者body是否存在冗余。
                           2. 先负载，再做RTT。主要用于存在性能风险的APP功能，如列表页面加载。这类测试在不使用测试桩的方法下，可以使用录像回放的方式来实现。(超过1S的APP响应事件其实都可以用纯黑盒实现)
                        3. 参照物比对。通常在没有性能标准的情况下，可以选择一些业内知名或者成熟的相似APP作为参照物，在相同环境下比对二者之间的差距。
                        （备注：3.1 参照物比对的方式，需要尽量保证2者环境的一致性；因无法做到完全一致，故会容忍一定比例的差异数据以及需要采集多次测试数据
                                       3.2 参照物比对的方式，测试人员需尽量站在用户角度作测试结果判断。如两个APP实现的功能基本一致，但是选择的协议不同，导致测试结果出现差异，也属于bugs，需决策者审核后，才能进入不修复流程，而非开发人员可直接进行非bugs判定。）

作者: Jackc 时间: 2015-1-17 10:32

pilottest 发表于 2015-1-15 16:45
请问一下，我是测试电力产品的，如电力仪表及电力系统类的，测试电力仪表产品居多，我们公司居多是手工测试 ...

电力仪表我没接触过，具体测试方法的建议就不说了，我简单聊一下问题解决方法，希望能对你有所帮助。
其实大部分问题的分析模型和测试分析需求的模型是一致的：目的（Why：为什么要做）-->方法(How：怎么做)--->评估(check:能做什么，不能做什么)-->执行(Do:着手执行，具体执行效果的评估模型可参考PDCA)
所以，得到以下几点

1. 职业规划
自己期望怎么发展？做测试开发，工具测试，测试控制，亦或是产品设计或创业？
建议你先百度一下测试可发展的职位，然后了解一些终极职位所需要的技能。
备注：黑盒手工测试技能并不是终极职位所需的关键技能，相信你是有所体会才会产生迷茫。但黑盒手工测试是其他技能的基石，如它的分析模型可用于所有的测试类型；与它紧密相关的测试策略可用于产品质量出口标准的优化。。。就如游戏的技能树一样，黑盒测试就如‘剑’的熟练度(简单易懂但伤害较低)，而其他技能就如杀伤力强大的‘剑技’，你期望拥有强大的剑技，就先得学习更高的熟练度。

2. 公司还能提供什么
公司的基本要求你只要能做职能内的实事，其他就没有要求了。所以它也不会强推你向前走，也就是说，个人发展还是靠自己。
但是公司其实可以为你提供很多隐性的学习机会，这部分需要你自己去分析。如，产品销售牌照的发放标准及可操作空间(与产品质量出口标准的优化相关)、研发团队可实现的功能范围（与bugs定义以及工具化相关，竞争对手产品质量情况（与性能标准及产品需求相关）。

3. 学什么
每一项测试技能的学习都需要时间成本。而一个人不可能把所有技能都精通，所以需要你有取舍的学习。
可参考的学习优先级较高的类型有：
3.1 获取方便，时间成本低的内容：不管你的职业规划着重哪个方面，测试域广度的了解是目前国内的基本要求之一。考虑到在不同的环境下，学习成本不同，故以长远来看，最短的时间内学习到足够多的技能可以让你面对更多的职场危机
3.2 与未来5年或者10年测试域发展趋势紧密结合的内容：首先，你要认识到自己是弱势群体(爱因斯坦类的不在此类)，改变不了社会，就要适应社会。然而你可以不需要适应现在的社会，但是你必须适应未来的社会(普通人很难一开始就已经适应社会)。在未来，测试黑盒人员将被边缘化(也就是不具备竞争力），测试技术类人员都将转型为开发人员，作为开发人员的辅助支撑角色而存在。简单来说，如果你的code不行，可以着手学一门语言先，不需要精通，但是需要达到熟练。
3.2 与你的职业规划耦合度较高的内容：这部分只要你完成1中的职位树后自然能知晓。

4. 其他
4.1 关于公司的选择
      在国内，公司的选择与个人的能力同等重要。不建议轻易跳槽，但期望在一家无前途的公司终老也不太符合实际。如何判定如何选择公司或者跳槽，其实很简单，找一张白纸，将你能想到利弊以及问题的解决方案写一次，然后你应该就能知道结果了(自己分析不清楚的，可以找朋友一起分析)。
4.2 关于学习时间
      优先选择公司给钱，自己又有技能提升的方式。很多时候并不是公司没有为你提供学习机会，而是你无法拿出双赢的学习方案（公司和个人均获利）
      普通的学习方式就是自己空闲时学习，这部分学习时需要注意：只学习优先级较高的内容，锦上添花的学习内容最好不安排

作者: xiaolijust5 时间: 2015-1-20 15:03
你好！
我们公司现在做的是全部是ERP系统（B/s、手机端都做）
A.手机端主要做的是接口，通过webservice 发布接口，使用.NET的开发语言
1、如果我要通过接口来测试APP的性能，需要关注哪些参数情况？
2、这种接口的测试，你是通过什么工具来做的？

作者: 心晴~~ 时间: 2015-1-20 20:22

Jackc 发表于 2015-1-17 09:14
‘性能部分，是要测试接口处理请求的响应时间长短吗？’
手持终端上比较常用的(性价比较高)性能测试包括 ...

谢谢jackc大神的回复，会好好学习吸收的

作者: //w// 时间: 2015-1-21 11:00
AP底座不知道怎么测试，请指点迷津AP底座测试方法，越详细越好。多谢。。。。。。

作者: Foreever 时间: 2015-1-21 14:50
你好，今年就要毕业，公司要求做一个关于京东购物车相关功能的测试，只针对购物车相关测试，考虑对上下游流程的影响，请问需要做哪些测试

作者: lio_m 时间: 2015-1-21 15:33
不知道有没有录制脚本、回放脚本，试用IOS设备的自动化测试工具？？很是需要！！！

作者: Jackc 时间: 2015-1-22 09:58

xiaolijust5 发表于 2015-1-20 15:03
你好！
我们公司现在做的是全部是ERP系统（B/s、手机端都做）
A.手机端主要做的是接口，通过webservice ...

1、如果我要通过接口来测试APP的性能，需要关注哪些参数情况？
   接口消息的测试一般关注3个部分：
   1. 消息本体：包含2大类测试点：消息格式、消息校验。这两类一般都可以从设计文档直接获取。消息格式的测试方法可以参考text控件；校验的测试则建议考虑场景流。
   2. 消息存储后对ERP功能的影响：这类其实和普通的功能关联测试没有区别，无非是基础数据源如何在ERP中使用。
   3. Mobile特殊用例组：这部分需要分析开发的接口在手持终端上的使用范围。通常，如只是调用TCP/UDP等做一些数据信息的传递，则需要参考PCT的方法进行数据流量的用例设计；如调用GSM（如SMS），则需要考虑消息丢失、反复推送等。简而言之，需要根据手持终端的调用范围进行额外的测试分析。

2、这种接口的测试，你是通过什么工具来做的？
   1 这类的接口测试工具化比较简单(普通开发人员1~2D就能完成)。我们通常是做一个简单的小工具调用webservice,然后将消息格式、网页/数据库地址、脚本路径等需要手工配置的部分预留为工具的UI接口，测试人员在完成测试元素分析后，将消息场景信息录入到工具里就可以完成接口测试了。但ERP系统关联部分大多还是依靠黑盒手工来支撑。
   2 即使不使用工具化，也可以通过在调用webservice的函数、发送/接收函数打上测试桩，将消息参数保存到本地进行手工检查。

作者: Jackc 时间: 2015-1-22 11:08

//w// 发表于 2015-1-21 11:00
AP底座不知道怎么测试，请指点迷津AP底座测试方法，越详细越好。多谢。。。。。。

首先，没有测试人员能熟悉所有的测试对象。所以，我们需要做到：熟悉甚至精通1~2种测试对象。在面对陌生测试对象时，以自己熟知的测试对象进行对比，将两者相同/类似的属性作等价处理，然后将测试分析重心放在测试对象独特的新功能上。通过这种方式可以缩减测试分析的工作量，并将最多的测试资源投入到风险最大的点上。

如何解析AP底座的测试方法
1. AP底座的构成
AP底座由哪些部件构成？可以使用由外至内，由硬件到软件的方式来进行初步的解剖
由外至内：外观（外壳、LED、外部接口触点..)-->电路板-->芯片(可选)
由硬件到软件：芯片-->电路板-->驱动-->接口-->协议-->APP

2. 可测试性分析
对测试对象的产品测试，并不是要求测试人员对它的零件都进行测试。
基本准则为2条：1. 是否具有测试意义
2. 是否有条件进行测试
不满足以上2条的测试对象属性，可直接从后续的测试分析中移除。如，目前很少公司都不具备驱动测试的条件，则测试人员可在前期与决策者讨论此部分的测试裁剪(其实在黑盒上可以间接对驱动进行测试，只是黑盒中的测试，不满足‘问题需尽早发现’的测试原则而已)

3. 测试对象间的等价
假设我们现在已经熟悉手持终端的测试，则我们来简单看一下‘协议‘属性的分析
在手持终端，外部硬件连接通常只有USB一种(圆孔充电器不考虑，因为它主要依靠终端自身驱动来为APP提供必要的消息支持)，而APP接口方式则主要以wifi、蓝牙、红外为主流。
AP底座的连接方式基本与手持终端相同，但是在协议中，底座的协议颗粒度更小，属于广义协议中的一种子协议（如中国移动的WLANAC-AP接口互通规范）。
分析结果：底座协议的测试方法可复用手持终端的，但测试范围及测试用例需根据支持的AP协议重新设计。

作者: zishuijing 时间: 2015-1-22 14:19
感谢！

作者: cloudazure 时间: 2015-1-23 15:54
Jackc老师，你好，本人在银行业务做功能测试有4年之久，一直以来担任都是纯手工偏向业务的测试工程师角色。今年跳槽去到现下比较流行的P2P行业，担任测试组长。目前我们公司要做微信植入的网站（简称“微网站”），手机端的测试我也是第一次接触，我有几个问题想请你解答下：
1、微网站的兼容性测试是否有必要，目前我没有找到好的解决办法来测试微网站的兼容性？
2、手机端的功能测试案例是否可以比较PC端的功能测试案例来编写？
3、在性能方面，由于是在微信中植入网页，是否可以忽略不作为测试范围？
期待Jackc老师的回答，谢谢

作者: Jackc 时间: 2015-1-23 17:44

Foreever 发表于 2015-1-21 14:50
你好，今年就要毕业，公司要求做一个关于京东购物车相关功能的测试，只针对购物车相关测试，考虑对上下游流 ...

以你的作业作为需求来分析，首先需要对测试范围进行裁剪。

1. 分析测试对象的构造
京东的购物车属于B/S架构，那么它就包括Web和数据库的测试。如果你无法获取数据库环境，则可以认为数据结构不在测试范围内。
在这种情况下，可以单只分析web。
2. 功能分析
建议以切蛋糕的方式来对功能进行分类(先切大块的，有明显分界的块(如方形蛋糕的对角线、中线)；再来切复杂的，不容易分割的块（如蛋糕中间有朵小花）)：
2.1. 核心功能
         也就是经常说的主功能，基础功能。购物车主要是拿来做什么的？装订单！
         故可以得到订单/商品展示是购物车的核心功能。
         接着可以分析购物车核心功能的实现方式，如小窗口列表展示，页面详细信息展示等。再逐个分析每类展示方式的具体属性，并生成对应的测试点或用例组。
         此部分分析结果将作为优先级最高的测试点或用例存在。(用例级别对应测试类型不在此说明，可以参考普通的用例书籍或文档都有说明)

2.2. 复杂核心功能
         核心功能中可能存在复杂的功能或逻辑。建议将此部分进行独立分析。如购物车中的订单总价计算，可能包含单价汇总、折扣、减免、付款方式等多种计算公式，故需要仔细将每种计算公式分析清楚，并设计独立的复合计算公式用例组。

  2.3 关联功能
      被测功能可能被其他功能调用，也可能去调用其他功能。简单来说，就是分析被测功能的I/O接口以及接口对应到系统页面的位置和方法。
      分析过程中，先将调用/被调用分类，再按设计文档或系统逐一列举即可。(购物车在此处分析量较大，务必仔细)

  2.4 在所有分析过程中，在每个分类中，还可以按照UI,功能，计算公式等测试单元实体类型再进行分类，并提炼出公共的测试方法和测试点，可以降低类似测试实体分析的消耗。
说明：根据测试目标的特性，通常会存在一些测试分析盲点(设计文档未提到，就很容易被测试分析遗漏的部分)，需要特别注意。目前只能通过对测试目标的熟悉度（业务熟练度）来弥补。所以遇到测试分析遗漏，最好能作一些文字性的个人经验总结。（如，购物车的消息提醒功能）

备注：
我在分析页面过程中，通常会固定存在以下4种分类：
1. 初始化：页面的初始化信息
2. 指标：页面的元素信息
3. 功能：页面提供的功能以及逻辑信息
4. 特殊维度：页面存在复杂功能逻辑时的环境因素信息

作者: Jackc 时间: 2015-1-23 17:52

lio_m 发表于 2015-1-21 15:33
不知道有没有录制脚本、回放脚本，试用IOS设备的自动化测试工具？？很是需要！！！

Instruments 可以满足你的需求。

作者: wangyixiong 时间: 2015-1-24 10:14
jmeter 分布式测试登录接口，当请求成功后，可以读到参数，controller响应结果为空，这是为什么呢？？？
（注：已排除端口占用，防火墙等问题）

作者: wangyixiong 时间: 2015-1-24 10:15
jmeter 分布式测试登录接口，当请求成功后，可以读到参数，controller响应结果为空，这是为什么呢？？？
（注：已排除端口占用，防火墙等问题）

作者: Jackc 时间: 2015-1-26 13:40

cloudazure 发表于 2015-1-23 15:54
Jackc老师，你好，本人在银行业务做功能测试有4年之久，一直以来担任都是纯手工偏向业务的测试工程师角色。 ...

1、微网站的兼容性测试是否有必要，目前我没有找到好的解决办法来测试微网站的兼容性？2
   web兼容性目前主流是是在使用2种策略，但基本原理都是：最少的测试资源满足最大量的用户群
   1.1 根据用户实际使用的浏览器进行测试，甚至一些强势的产品生产商会限制用户使用浏览器的品牌和版本
   1.2 根据浏览器内核和排行，选择部分浏览器版本进行测试。每个内核选1~2种浏览器，每个浏览器选择1~2个版本。如果测试资源仍然不够，甚至会根据排行只选择1~2个主流内核的单个浏览器进行测试。

2、手机端的功能测试案例是否可以比较PC端的功能测试案例来编写？
   可以。在黑盒测试中，针对同一个功能，手机和PC的区别并不大。只是需要注意手机本身的特征用例加入到PC用例中，如中断、后台运行等。（手机特征用例是可以复用的，所以建议定期进行总结并提炼为手机的公共用例组）
   备注：注意有时候手持终端对功能有一些特殊需求，如图片下载，在PC端可能是直接下载，而在手机端则是先下载缩略图，然后再通过手动操作下载原图。

3、在性能方面，由于是在微信中植入网页，是否可以忽略不作为测试范围？
   性能测试还是需要的。响应时间需要在PC和手持终端考虑，而功耗、流量等性能指标需要在手持终端考虑。

作者: 小脚丫的追求 时间: 2015-1-26 16:25
大神，现在公司拓展app产品领域，总是觉得自己对于app的测试除了手工点点点，找不到别的更好的办法，效率不高。对我目前的状态有没有比较可操作的方法来提高测试的含金量和效率呢

作者: thenicedawn 时间: 2015-1-27 20:58
你好，老师我初学测试，不是很理解loadrunner对c/s的意义多大？如果我分析用loadrunner测试winform应该从哪些方面分析

作者: mokoko 时间: 2015-1-28 09:06
前辈能否推荐几款测手机耗电量及流量消耗的软件，谢谢！特别是IOS设备~

作者: Jackc 时间: 2015-1-28 09:33

wangyixiong 发表于 2015-1-24 10:15
jmeter 分布式测试登录接口，当请求成功后，可以读到参数，controller响应结果为空，这是为什么呢？？？
...

1.单独在controller上运行脚本，检查脚本本身是否存在问题(如2.9以下的版本对HTTP请求存在长度控制)
2.检查controller中的端口号是否被其他应用程序占用
3. 至于其他的原因很难在调试环境外进行分析（如浏览器代理服务器地址问题）。
理论上如果问题1能pass，按照分布环境部署的操作说明来做，是可以成功的。

作者: 394819525 时间: 2015-1-28 16:00
学习monkeyrunner、CTS有什么好的书籍推荐吗？

作者: 394819525 时间: 2015-1-29 13:58
公司开发了SDK计费，但是仅仅走计费流程不够的，想深入测试，开发建议按芯片不同的双卡双待来测，我不知道这里跟芯片有什么关联，求指教

作者: Jackc 时间: 2015-1-29 16:40

小脚丫的追求发表于 2015-1-26 16:25
大神，现在公司拓展app产品领域，总是觉得自己对于app的测试除了手工点点点，找不到别的更好的办法，效率不 ...

就目前来看，手持终端的黑盒手工测试依然是主要生产力。但还是可以根据公司客观环境融入部分其他的测试类型。以下简单描述一下各个测试类型和我个人的见解，你再根据实际情况来取舍。

先定义几个术语和一个公式，方便后面引用：(本帖的术语定义仅限于本帖，因为现在测试模型术语多而繁杂，很难找到唯一的国际化术语)
测试产出：测试活动对于项目/产品所产生的实际价值
测试资源：测试活动投入的资源，包括人以及客观环境。本帖中资源权重以人力资源为主。
测试产能：测试活动的价值比，衡量测试活动效率的系数

测试产能 = 测试产出/测试资源
-------------------------------------------------
以下测试类型以测试资源消耗升序排序：
1.静态测试
   静态测试主要以文档分析为主，在标准测试模型中，它涉及的文档涵盖了所有工程文档，但很少公司的测试人员能真正做到静态的全面测试。
   原因有三：一是测试人员的code技能等级普遍没有达标，经常连入门都达不到，又何以走查详细设计，代码片段？
                     二是公司的文档过于敏捷化，甚至无流程。无文档又如何静态？
                     三是测试人员疲于测试执行，没有时间，或者是有时间，却没有方法，导致没有对测试执行结果进行总结，从而无法提炼出适合的静态测试对象。
   其实，在静态测试中，至少有2项仅依靠基础测试技能就可以完成：需求分析、测试报告分析
   需求分析：主要是分析功能设计是否满足需求的业务背景，降低项目中后期的设计变更风险。而测试人员在这个活动过程中，能够学习和巩固分析模型，慢慢将分析模型的基础方法锤炼为条件反射。
                     备注：1.经常会遇到有测试同事说，‘我们连需求文档都没有，如何做静态分析？’。其实这是一种误区，没有任何书籍以及人说过静态测试的对象只有‘文档’，只是‘文档’是最普通的对象。说白了，‘文档’只是个载体，如需求文档，其中‘需求’才是我们需要做静态分析的对象。所以即使需求不以‘文档’作为载体存在，它还是能以其他方式存在的。测试实例化的依据标准其实就是所谓的‘需求’。
                              2.需求分析过程中需要关注分析粒度，不建议进行过于细节的分析。保证分析结果可以支撑测试实例化即可。(非实例化细节（如IM 消息聊天需求，只需要分析出聊天界面各个元素大致的对应的测试方法，且这些测试方法可以在日后执行即可。)
                              3.通常情况下，需求分析过程可控制在项目整体的5%以内。
   测试报告分析：主要分析当前产品风险点，调整测试资源部署。同时也会对之前的测试产出进行评估，刷新测试策略和计划。测试报告分析的对象主要是测试执行结果(如用例执行结果)和bugs清单。测试人员在此活动中，可以明确找到自己的短期目标实体化，还可以更深入理解风险控制的尺度。
                     备注：1. 测试报告的分析方法和目的较多。建议以结果导向驱动，先明确分析目标，再考虑分析方法。
                              2.测试报告分析过程的资源消耗并不太大，但是分析前的资源准备需要消耗不少的资源，且具有时间特性，无法在短时间内临时准备。故，在测试策略阶段，就需要知道需要收集和准备的测试报告数据，并在测试执行过程中记录下来。通常，我们已有用例和bugs清单，但它们可能不方便统计，故在项目前期会根据分析需要，调整数据存储格式或新增某些数据的记录。(如，一些开源的bugs系统由于自身bugs属性参数不足，不足以支撑bugs在某个分类汇总或干脆就不支持报表/图形查看，我们可以在前期设计一些统计的小工具，如EXCEL模板等。将bugs系统与小工具的统计结合在一起，以便于项目开发过程中的数据分析。)

2. 动态测试
2.1 功能测试
      2.1.1 黑盒手工
               作为最主流的测试类型，它上手很容易，真正做起来却不太容易。因为这部分测试的等价法使用率最高，甚至无处不在。但是每一次等价法的使用，都包含着测试泄露风险。所以黑盒手工测试属于入门极低，却无法达到极致的东东。
               黑盒手工测试在执行上本身不具备太多的提高空间。它主要是作为提升测试分析和业务领域的辅助存在，所以，如果在之前未进行最基本的测试思路整理，拿到测试实体就一阵乱点或按部就班按照case执行，并不能对个人有多大提升。建议在测试之前，花费几分钟整理一下测试思路(将要做什么，按照什么模式来做)，然后再执行过程中比照之前的构思存在哪些不足，也可在测试执行结束后，再用几分钟完成一个小结。基本上1~2年内就可以将黑盒测试执行巩固到一个高度：即使需求细节不再完整，或者仅有少量的测试要点框架的情况下，依然可以达到80%以上的执行覆盖率。
      2.1.2 黑盒自动化
            嵌入式的黑盒自动化最近被炒的很热，但是针对于手机APP来说，它的测试产能和适用范围远不如黑盒手工。主要原因是目前大部分黑盒自动化基于UI，而自动化工具的UI控件化成为最大瓶颈，UI控件参数完整性较B/S结构的产品来说，还显得很单薄。所以能应用的范围也较小(如果期望达到如QTP对web的支持，在工具开发以及脚本维护上，手持终端产品要比web产品投入更多的资源)。
            但是也可以选择一些合适的工具来为我们做一些东东，比如完成迭代回归测试中的20%用例组。(不过相对于工具化在非黑盒和性能上的表现，UI的工具化显得比较渺小)
            备注：如果手机APP产品是一个巨型项目(2年以上)，则可以考虑将回归测试整体自动化。
      2.1.3 灰盒自动化
            主要是完成一些接口、协议、API调用的测试，这部分能够工具化就尽量工具化。有时可能无法完全工具化，但是只要是能做的，都会比在黑盒上测试性价比更高，甚至可以将部分性能测试也顺带做了（如，流量测试，如果将activities调用的协议以时间戳形式记录logs，并结合数据筛选或图形展示，则可以很轻易完成测试，甚至将测试标准传递给开发人员，由开发人员在提测前自行检查，更大程度的提高测试效率）

2.2 非功能测试
            手持终端的APP非功能测试在国内的关注度较低(标准低)，但都多少会有涉及。普通APP会考虑功耗、内存，IM APP会考虑流量，播放器APP会考虑画质。其实此部分的测试分类，在手持终端侵泡了2,3后都基本了解或掌握。较难的部分只是如何制定测试标准以及如何将测试用例实例化，转化为可执行测试而已。
            在此前我见过一些奇葩的测试手段，如页面加载响应时间，测试人员没能开发出获取activities 开始/结束时间的工具，干脆就直接录像然后剪接来完成测试需求。
            故，在大多数请款下，非功能的测试的选择基于2个基准：测试产能、可实例化
            备注：在多个平台下，monkey tools 的测试产能都很不错。不管是使用开源工具还是自主研发，开发成本都不高，而测试执行阶段则只需要投入测试硬件即可(堪称测试资源投入最低的测试方法)。而它能为我们提供多种测试辅助：测试分析/用例泄露、负载测试、长周期测试、内存泄露测试等。(测试辅助是指测试执行效果未完整覆盖的某一类测试，仅为部分覆盖)

=======================
小结:
1. 测试方法的拓展来源于自身对测试目的（测试对象）的思考和认识，并结合客观环境，最终融合出测试产能较高的测试执行实体。也就达到了所谓的提升测试效率。
2. 实在找不到如何提升，可直接学习开发技能，日后对测试的认识达到一定程度，就可以将开发与测试技能融合，自然就会领悟到更高效率的测试方法。
3. 没有测试方法是不存在风险的，空闲时可以多思考已掌握的方法是否存在泄漏，哪些泄漏可以容忍，哪些不可以容忍，为什么？当你多得到一个为什么时，就对测试的认识更深一步。日积月累，量变自然可以产生质变。

作者: Jackc 时间: 2015-1-29 17:51

thenicedawn 发表于 2015-1-27 20:58
你好，老师我初学测试，不是很理解loadrunner对c/s的意义多大？如果我分析用loadrunner测试winform应该从 ...

LR 在C/S上基本能实现与B/S相同的效果，其核心优势是可完成压力测试。
但是在C/S环境配置上比较麻烦，这个需要根据自身以及客观环境来判断是否选择LR。
你可以先试着用LR录制一下，看是否能成功。(按照目前的开发模式来说，要成功真心很难)

在LR中，录制/回放是LR自己通过VuGen的规则做自动关联，所以存在失败的情况。这种情况下，可以自己去关联。但是这样对测试人员的要求稍微高一些。

环境部署对测试人员的要求：
1. 熟悉测试对象中影响LR配置的属性参数，主要是测试对象使用的协议和数据库类型。
（LR自带的自动关联功能并不能很好将自身的协议与client APP进行有效关联。所以经常出现录制和回报错。）
2. 熟悉LR脚本设计，并能进行调试和修改(较难，可能要3~6个月的学习时间)
3.会使用1,2种抓包工具，将消息转化为LR脚本(工具可以用wireshark,很简单，用2次就能上手了)

作者: Jackc 时间: 2015-1-29 18:00

mokoko 发表于 2015-1-28 09:06
前辈能否推荐几款测手机耗电量及流量消耗的软件，谢谢！特别是IOS设备~

在做功耗这部分测试过程中，需要注意尽量不要使用需要root权限的工具。
1. IOS的耗电量可以直接用自带的Instruments监控CPU占用率来实现；android可使用System Tuner Pro(不root就可以监控CPU)
不建议直接监控电量，电池容量本身就不是一种不稳定的东东
2. 流量没有现成的方式。不做二次开发的工具只能监控到单个APP的流量(这样的流量监控并不准确，也不便于定位)。各类手机管理软件，几乎都支持监控APP级别的流量。

作者: Jackc 时间: 2015-1-29 18:05

394819525 发表于 2015-1-28 16:00
学习monkeyrunner、CTS有什么好的书籍推荐吗？

额，这个好像没有推荐。
手机测试工具太多，我很少专门去看书学习某一类工具。
很早以前在学习QPT和LR时还稍微看了一些，但是之后用的手机的工具基本都没有专门看书。

在工具使用过程中，我通常只做3件事：
1. 搜索安装配置说明
2. 实际使用+F1
3. 疑难杂症遇到时再搜索
。。。。

作者: Jackc 时间: 2015-1-29 18:18

394819525 发表于 2015-1-29 13:58
公司开发了SDK计费，但是仅仅走计费流程不够的，想深入测试，开发建议按芯片不同的双卡双待来测，我不知道 ...

其实双卡双待提供的应该算是一种标准协议。又分为2类：
真双待：可同时支持2条GSM上下行
假双待：同时只能支持1条GSM上下行，待机时通过轮询保持双卡
------------------
你的这个问题应该问开发，严格意义上来说，芯片和双卡双待是两种的东西，没有可比性。
就像android和ios是两个系统，QQ和微信是两个APP。那在android上的QQ和IOS上的微信是什么关系呢?

------------------------
所以，问题的根源来源于开发这个建议在目的性上不明确，他到底是想做芯片兼容还是想做协议兼容？

-----------------------
个人认为，双卡双待如果是芯片支持，在SDK上开发完成，那么在APP上做协议兼容性测试的价值并不大。
而芯片兼容测试就和普通的手机兼容测试一样了，这个是需要做的。但通常我们看的OS版本，并不关注芯片版本。
如，芯片更新换代了，但是OS版本没有变，实际上在APP层是不需要做兼容测试了。那是驱动兼容测试的事情了。

作者: thenicedawn 时间: 2015-1-29 19:36

Jackc 发表于 2015-1-29 17:51
LR 在C/S上基本能实现与B/S相同的效果，其核心优势是可完成压力测试。
但是在C/S环境配置上比较麻烦，这 ...

恩，谢谢指教，，我打算先做开发然后转测试，，组长让我写一篇关于lr的分析，而且大多数测试对象是c/s结构的，我在做测试前需要准备哪些东西？

作者: neijiangwlz 时间: 2015-1-30 13:39

thenicedawn 发表于 2015-1-29 19:36
恩，谢谢指教，，我打算先做开发然后转测试，，组长让我写一篇关于lr的分析，而且大多数测试对象是c/s结 ...

开发然后转测试

作者: thenicedawn 时间: 2015-1-30 19:10

neijiangwlz 发表于 2015-1-30 13:39
开发然后转测试

我就是先打算做底层，然后走测试

作者: 小脚丫的追求 时间: 2015-2-2 13:14

Jackc 发表于 2015-1-29 16:40
就目前来看，手持终端的黑盒手工测试依然是主要生产力。但还是可以根据公司客观环境融入部分其他的测试类 ...

好感动，抽出时间写了好多，努力学习中

作者: applejuzi 时间: 2015-2-4 13:15
顶一下，好久没上论坛了

作者: a544529651 时间: 2015-12-7 09:18
我悄悄地来，我悄悄地走

作者: 海里的幸福 时间: 2016-10-28 13:17
我很喜欢,太精彩了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)