[大讲堂]"乙醇"测试基础知识脱口秀一

精品内容推荐wangpinqing 发表了文章 • 0 个评论 • 179 次浏览 • 2016-11-21 14:15 • 来自相关话题

Testin测试公开课是为测试者提供的行业内最干的课程分享,本期由业内资深讲师“乙醇”为大家分享测试基础知识视频脱口秀。

“乙醇”简介:
专注于自动化的推广和培训。最早开展开自动化测试公开课的良心老师之一。有着磁性嗓音和颜值担当,是妹子最喜欢的老师。
 

  查看全部
Testin测试公开课是为测试者提供的行业内最干的课程分享,本期由业内资深讲师“乙醇”为大家分享测试基础知识视频脱口秀。

“乙醇”简介:
专注于自动化的推广和培训。最早开展开自动化测试公开课的良心老师之一。有着磁性嗓音和颜值担当,是妹子最喜欢的老师。
 


 

【Testin】崩溃分析全新升级

Bugout内测liuyuexin@testin.cn 发表了文章 • 0 个评论 • 3216 次浏览 • 2016-11-18 12:09 • 来自相关话题

【Testin】崩溃分析全新升级
 
 在崩溃研发小组辛勤的汗水灌溉下的崩溃分析完成了全新升级~
 这是集Bug管理系统与崩溃分析功能优化为一体更加全面的Bug管理工具,我们给他起了一个更具“B”格的名字------Bugout。
 
一、新增功能与优化 

 在新版Bugout中,我们添加了缺陷管理系统并修复旧版本存在的功能问题:

 1. 新增创建项目可以邀请企业中的所有有关成员,时刻关注项目提交的所有问题和整体进行情况。
 2. 新增将提交的问题整理统计,针对问题属性定向指派企业成员解决并跟踪关注问题解决情况。
 3. 新增”摇一摇“反馈问题的功能,并上报到问题列表统一处理。
 4. 优化了上报崩溃信息延迟问题,真正做到“秒”报问题的速度,拒绝延迟。
 5. 优化个别用户上传新版本无法显示的缺陷,全新针对不同版本上报问题统计,第一时间知道上报问题的版本号,方便发现解决。
 
二、用户使用建议 

 目前开发应用类型软件的用户都可以升级使用新版Bugout,而游戏开发者这个版本不建议您升级使用了,游戏部分捕捉插件还没有全面支持,不过请游戏开发者们稍作等待,后续Bugout版本将全面支持游戏的功能,在此聊表歉意。
 
三、轻松升级SDK 

 升级新版SDK依旧秉承简单快捷的风格,只要在Bugout官方网站中创建对应项目后(这里有个简单的链接哦),下载新的SDK后替换便可以了,简单的集成方法已经在文档中详细说明,有一点需要强调,Bugout SDK使用绝对安全,不存在泄露用户信息的问题,还有个细节需要注意,新版本Bugout的项目ID可是独立的哦,在集成SDK是需要将旧版本替换才能够成功。
 
四、Bugout专属服务 

 对于您遇到的疑问还有使用反馈,我们有专属的Bugout服务QQ群:340015081

 如果是需要协助解决的问题,我们还有Bugout美眉客服小新和您1v1交流,小新会为每一个用户准备一份企业小福利的,小新的QQ:3471404024

 

欢迎您升级使用Bugout 查看全部
【Testin】崩溃分析全新升级
 
 在崩溃研发小组辛勤的汗水灌溉下的崩溃分析完成了全新升级~
 这是集Bug管理系统与崩溃分析功能优化为一体更加全面的Bug管理工具,我们给他起了一个更具“B”格的名字------Bugout。
 
一、新增功能与优化 

 在新版Bugout中,我们添加了缺陷管理系统并修复旧版本存在的功能问题:

 1. 新增创建项目可以邀请企业中的所有有关成员,时刻关注项目提交的所有问题和整体进行情况。
 2. 新增将提交的问题整理统计,针对问题属性定向指派企业成员解决并跟踪关注问题解决情况。
 3. 新增”摇一摇“反馈问题的功能,并上报到问题列表统一处理。
 4. 优化了上报崩溃信息延迟问题,真正做到“秒”报问题的速度,拒绝延迟。
 5. 优化个别用户上传新版本无法显示的缺陷,全新针对不同版本上报问题统计,第一时间知道上报问题的版本号,方便发现解决。
 
二、用户使用建议 

 目前开发应用类型软件的用户都可以升级使用新版Bugout,而游戏开发者这个版本不建议您升级使用了,游戏部分捕捉插件还没有全面支持,不过请游戏开发者们稍作等待,后续Bugout版本将全面支持游戏的功能,在此聊表歉意。
 
三、轻松升级SDK 

 升级新版SDK依旧秉承简单快捷的风格,只要在Bugout官方网站中创建对应项目后(这里有个简单的链接哦),下载新的SDK后替换便可以了,简单的集成方法已经在文档中详细说明,有一点需要强调,Bugout SDK使用绝对安全,不存在泄露用户信息的问题,还有个细节需要注意,新版本Bugout的项目ID可是独立的哦,在集成SDK是需要将旧版本替换才能够成功。
 
四、Bugout专属服务 

 对于您遇到的疑问还有使用反馈,我们有专属的Bugout服务QQ群:340015081

 如果是需要协助解决的问题,我们还有Bugout美眉客服小新和您1v1交流,小新会为每一个用户准备一份企业小福利的,小新的QQ:3471404024

 

欢迎您升级使用Bugout

iOS SDK 开发 -- 控制接口暴露

服务使用交流鲁宇星 发表了文章 • 0 个评论 • 84 次浏览 • 2016-11-17 14:39 • 来自相关话题

在 SDK 开发中,经常会碰到一个问题,假设 SDKUser.h 是 SDK 对外暴露的 Header, 其中 SDKUser 类型中的 uid 属性是不对外暴露的,但在 SDK 中的某些私有类需要获取这个属性(或方法),这个时候我们需要怎么处理呢?uid 属性是一个对 SDK 外是不可以见的,但对 SDK 内是可见的,这种情况,就可以使用 Category 来解决这个问题:

SDKUser.h 对外暴露的头文件:

@interface SDKUser : NSObject
 
@property(nonatomic, copy, readonly) NSString *username;
 
@end

在对外暴露的 Header 中,如果我们不希望外部来写这个对象的时候,我们需要将属性设置为只读属性,但是我们又需要在对内支持读写,这时我们需要在实现文件里重新设置该属性支持读写操作。

SDKUser.m 实现文件:

#import "SDKUser.h"
 
@interface SDKUser()
 
// 对外属性
@property(nonatomic, copy, readwrite) NSString *username;
 
// 只对内属性
@property(nonatomic, copy, readwrite) NSString *uid;
 
@end
 
@implementation SDKUser
 
@end

因为 username 属性在 SDK 内是支持读写操作的,所以需要设置为 readwrite,而 uid 这个属性这里是不希望暴露给用户的,所以我们将该属性定义在 .m 文件里中,但是定义 .m 文件里时,只支持类内的访问,如果 SDK 内的其它私有类想访问就无法访问到这个属性了。

这种情况下,我们可以对 SDKUser 这个类进行 Category,并将 SDK 里的相关私有属性(或方法)实现在里面:

#import "SDKUser.h"
 
@interface SDKUser (SDKInner)
 
// 基本属性
@property(nonatomic, copy) NSString *uid;
@property(nonatomic, copy, readonly) NSString *username;
 
@end
 
 
--------------------------------
 
 
#import "SDKUser+SDKInner.h"
 
@implementation SDKUser (SDKInner)
 
@end

这样的话 SDK 内的私有类就可以访问 SDKUser 里面的 uid 属性,并且又不会暴露给开发者。 查看全部
在 SDK 开发中,经常会碰到一个问题,假设 SDKUser.h 是 SDK 对外暴露的 Header, 其中 SDKUser 类型中的 uid 属性是不对外暴露的,但在 SDK 中的某些私有类需要获取这个属性(或方法),这个时候我们需要怎么处理呢?uid 属性是一个对 SDK 外是不可以见的,但对 SDK 内是可见的,这种情况,就可以使用 Category 来解决这个问题:

SDKUser.h 对外暴露的头文件:

@interface SDKUser : NSObject
 
@property(nonatomic, copy, readonly) NSString *username;
 
@end

在对外暴露的 Header 中,如果我们不希望外部来写这个对象的时候,我们需要将属性设置为只读属性,但是我们又需要在对内支持读写,这时我们需要在实现文件里重新设置该属性支持读写操作。

SDKUser.m 实现文件:

#import "SDKUser.h"
 
@interface SDKUser()
 
// 对外属性
@property(nonatomic, copy, readwrite) NSString *username;
 
// 只对内属性
@property(nonatomic, copy, readwrite) NSString *uid;
 
@end
 
@implementation SDKUser
 
@end

因为 username 属性在 SDK 内是支持读写操作的,所以需要设置为 readwrite,而 uid 这个属性这里是不希望暴露给用户的,所以我们将该属性定义在 .m 文件里中,但是定义 .m 文件里时,只支持类内的访问,如果 SDK 内的其它私有类想访问就无法访问到这个属性了。

这种情况下,我们可以对 SDKUser 这个类进行 Category,并将 SDK 里的相关私有属性(或方法)实现在里面:

#import "SDKUser.h"
 
@interface SDKUser (SDKInner)
 
// 基本属性
@property(nonatomic, copy) NSString *uid;
@property(nonatomic, copy, readonly) NSString *username;
 
@end
 
 
--------------------------------
 
 
#import "SDKUser+SDKInner.h"
 
@implementation SDKUser (SDKInner)
 
@end

这样的话 SDK 内的私有类就可以访问 SDKUser 里面的 uid 属性,并且又不会暴露给开发者。

软件测试工作经验分享

服务使用交流鲁宇星 发表了文章 • 0 个评论 • 103 次浏览 • 2016-11-17 14:26 • 来自相关话题

一、测试阶段划分
1、 单个模块功能测试时间相对较长,但每一个项目都应该有专门的集成测试阶段,并且应该不止进行一轮。
每一轮集成测试,应该都有自己的目的,比如第一轮集成测试,是根据集成测试要点验证整体功能情况;第二轮集成测试是回归测试;第三轮集成测试是交叉测试。
每个项目应进行几轮集成测试,根据项目实际情况而定,而决定的因素多与工期、项目问题多少而定。
2、 每个项目都应该有专项测试阶段,比如接口测试、性能测试、异常测试等。(作为测试人员,应主动与项目组沟通,在本项目是否开展此项工作,最后应有书面沟通结果,最好是通过邮件确认。)
 
二、测试过程文档输出
1、 项目需求评审后,或者项目已展开需求讨论后,就应该与项目经理沟通并开始考虑测试的事情。
2、 测试过程文档不能缺失,比如测试计划、测试方案、测试用例、测试报告等,不能因为工期不够而缺失某一部分测试文档的输出,这样只会给别人你测试不够专业的感觉,并且不写文档的效果并不一定比写了文档的效果好。
写文档的目的不只是为了公司财富的积累,更多的是对自己测试思路的梳理,只有思路清晰了,测试过程才不会混乱,否则可能在测试过程中,自己首先就乱了,不知道从哪里下手,哪里结束。
3、 测试的每个阶段都应该有输出,比如计划阶段,输出测试计划、测试方案,执行阶段输出测试用例,系统测试结束后输出测试报告等。整个测试过程都应该是在有条不紊的思路下开展下来的。
4、 提前准备,比如测试计划、测试方案、测试用例,能提前的,尽量提前做出来,否则到了测试执行阶段,就会手忙脚乱,觉得:啊,我用例还没写,但开发已提交测试了,怎么办?先测吧,后面再来补用例。一般这种情况下,当时想的需要补充的用例,基本上都没有补,到最后公司需要资料的时候,随便胡乱凑,结果提交出去的资料不合格,公司很可能就会否定你这次的工作。
 
三、测试思考层面跨越
1、 从我接触的测试人员来看,一般会从大局(整体)考虑,或者不计较个人负责或者其他人负责的人,目前来看发展得都挺不错的;如果只是觉得把我的工作做好就可以了,其他不该我做的跟我没关系,有这种想法的,职业发展一般都不会有太高的提升。
2、 建议有一块砖的思想,哪里需要就可以往哪里搬,能达到这种程度后,基本上团队什么事情都会想到你,那么这个时候,你离发展的提升也就不远了。
3、 作为测试人员,需要避免只把自己当测试人员的思想,我们要站在更高的层面,就像我们属于项目组,但同时又要高于项目组一样,不能所有事情都是项目组说什么就是什么,一定要有自己的思想,我觉得是对的就要坚持,最后都无法达成统一的需要寻求资源协助。当然,我们的想法有时候也可能会有错的,那么别人说的正确的意见我们也要采纳,并不是测试发现的所有问题都必须要解决。
 
四、沟通
作为测试人员,学会沟通是我们的一门必修课。在下面几个环节,我们需要深入思考,并积极发表自己的意见,以及与项目组的沟通。
1、 需求评审时,多发表自己对需求、对产品的看法;
2、 用例评审时,一定要思路清晰,有条不紊的评审用例,因为测试用例的评审是以我们为主导的;
3、 测试过程中与开发确认问题时,需要积极沟通,协助开发定位问题;
4、 与开发沟通时,尽量从这个问题对用户的影响程度方面来说,这样更具有说服力。
 
五、注重细节
1、 测试过程中,每一个词语的定义是否合适、每一个图标的含义,都需要思考(比如项目中,工艺图中,不同的颜色分别代表什么含义,有没有人去询问过、上网查过、或者找设计的人了解过);
2、 文档的细节,作为测试人员,从项目开始到结束,会输出很多测试文档,这些文档里面,可能很多是从其他项目copy过来的,有的时间没改、有的名字没改、有的甚至连项目名称都没改…诸如此类的文档很多,凡是经过自己手写出来的文档,一定要从头到尾认真、仔细的读2遍,否则,就这一点,就可能对你的测试工作、测试能力打折。
 
六、测试技术的积累
1、 不要老在开发面前表现自己的“小白”,时间久了,自己就可能真的会变成“小白”;
2、 平时测试过程中,除了测试界面的功能之外,可以查一下数据库,检查数据是否写入数据库成功,如果自己把数据库的数据再修改一下会怎么样;
3、 前端测试的时候,多看看服务器日志信息,很多时候前端操作的异常,通过服务器错误日志信息可以找到问题原因,如果我们把问题原因告诉开发,将是开发比较高兴的事情;
4、 学会使用页面分析或抓包工具,比如点击某个按钮无反应的时候,我们可以通过IE浏览器的F12,或者fireFox的debug工具,查看请求与响应;
5、 当发现问题后,不要急着记录问题,先自己确认问题,是否与浏览器、缓存等有关系,确认问题后,最好还可以找到问题的根源。
总之,在测试过程中,要学会发现问题并分析问题,在测试过程中积累测试技术专业知识。
 
七、软件测试知识
1、 先从软件测试基础知识学习开始;杜绝误区:测试理论知识不重要
2、 软件知识学习,测试是为软件服务的,软件工程、编程语言、架构、网络等,一切与开发有关的知识,建议都或多或少学一些,作为测试人员,要学习的东西非常多,不要求深度但要求广度;
 
八、软件测试这个职业
刚入门,或者工作了几年的测试人员都或多或少有这样的困惑,为什么测试人员的工资普遍低于开发人员?对于这个问题,我之前看到一篇博客中是这样写的:测试人员与开发人员,就像护士与医生。再优秀再专业的护士,也治愈不了病人的病,同样的,测试人员也做不出软件来,能做出软件来的都被认为是开发人员了。医院里有名的医生很多,但有名的护士几乎没有听到过,开发与测试的关系也是这样。所以,职责不同,必然有轻重之分,存在既有价值,医院不能没有护士,软件开发也需要测试。我也深信,必然有很多一直在软件测试道路上继续前进的人。既然选择了软件测试行业,那么就希望可以在软件测试行业的发展价值达到最大化。 查看全部
一、测试阶段划分
1、 单个模块功能测试时间相对较长,但每一个项目都应该有专门的集成测试阶段,并且应该不止进行一轮。
每一轮集成测试,应该都有自己的目的,比如第一轮集成测试,是根据集成测试要点验证整体功能情况;第二轮集成测试是回归测试;第三轮集成测试是交叉测试。
每个项目应进行几轮集成测试,根据项目实际情况而定,而决定的因素多与工期、项目问题多少而定。
2、 每个项目都应该有专项测试阶段,比如接口测试、性能测试、异常测试等。(作为测试人员,应主动与项目组沟通,在本项目是否开展此项工作,最后应有书面沟通结果,最好是通过邮件确认。)
 
二、测试过程文档输出
1、 项目需求评审后,或者项目已展开需求讨论后,就应该与项目经理沟通并开始考虑测试的事情。
2、 测试过程文档不能缺失,比如测试计划、测试方案、测试用例、测试报告等,不能因为工期不够而缺失某一部分测试文档的输出,这样只会给别人你测试不够专业的感觉,并且不写文档的效果并不一定比写了文档的效果好。
写文档的目的不只是为了公司财富的积累,更多的是对自己测试思路的梳理,只有思路清晰了,测试过程才不会混乱,否则可能在测试过程中,自己首先就乱了,不知道从哪里下手,哪里结束。
3、 测试的每个阶段都应该有输出,比如计划阶段,输出测试计划、测试方案,执行阶段输出测试用例,系统测试结束后输出测试报告等。整个测试过程都应该是在有条不紊的思路下开展下来的。
4、 提前准备,比如测试计划、测试方案、测试用例,能提前的,尽量提前做出来,否则到了测试执行阶段,就会手忙脚乱,觉得:啊,我用例还没写,但开发已提交测试了,怎么办?先测吧,后面再来补用例。一般这种情况下,当时想的需要补充的用例,基本上都没有补,到最后公司需要资料的时候,随便胡乱凑,结果提交出去的资料不合格,公司很可能就会否定你这次的工作。
 
三、测试思考层面跨越
1、 从我接触的测试人员来看,一般会从大局(整体)考虑,或者不计较个人负责或者其他人负责的人,目前来看发展得都挺不错的;如果只是觉得把我的工作做好就可以了,其他不该我做的跟我没关系,有这种想法的,职业发展一般都不会有太高的提升。
2、 建议有一块砖的思想,哪里需要就可以往哪里搬,能达到这种程度后,基本上团队什么事情都会想到你,那么这个时候,你离发展的提升也就不远了。
3、 作为测试人员,需要避免只把自己当测试人员的思想,我们要站在更高的层面,就像我们属于项目组,但同时又要高于项目组一样,不能所有事情都是项目组说什么就是什么,一定要有自己的思想,我觉得是对的就要坚持,最后都无法达成统一的需要寻求资源协助。当然,我们的想法有时候也可能会有错的,那么别人说的正确的意见我们也要采纳,并不是测试发现的所有问题都必须要解决。
 
四、沟通
作为测试人员,学会沟通是我们的一门必修课。在下面几个环节,我们需要深入思考,并积极发表自己的意见,以及与项目组的沟通。
1、 需求评审时,多发表自己对需求、对产品的看法;
2、 用例评审时,一定要思路清晰,有条不紊的评审用例,因为测试用例的评审是以我们为主导的;
3、 测试过程中与开发确认问题时,需要积极沟通,协助开发定位问题;
4、 与开发沟通时,尽量从这个问题对用户的影响程度方面来说,这样更具有说服力。
 
五、注重细节
1、 测试过程中,每一个词语的定义是否合适、每一个图标的含义,都需要思考(比如项目中,工艺图中,不同的颜色分别代表什么含义,有没有人去询问过、上网查过、或者找设计的人了解过);
2、 文档的细节,作为测试人员,从项目开始到结束,会输出很多测试文档,这些文档里面,可能很多是从其他项目copy过来的,有的时间没改、有的名字没改、有的甚至连项目名称都没改…诸如此类的文档很多,凡是经过自己手写出来的文档,一定要从头到尾认真、仔细的读2遍,否则,就这一点,就可能对你的测试工作、测试能力打折。
 
六、测试技术的积累
1、 不要老在开发面前表现自己的“小白”,时间久了,自己就可能真的会变成“小白”;
2、 平时测试过程中,除了测试界面的功能之外,可以查一下数据库,检查数据是否写入数据库成功,如果自己把数据库的数据再修改一下会怎么样;
3、 前端测试的时候,多看看服务器日志信息,很多时候前端操作的异常,通过服务器错误日志信息可以找到问题原因,如果我们把问题原因告诉开发,将是开发比较高兴的事情;
4、 学会使用页面分析或抓包工具,比如点击某个按钮无反应的时候,我们可以通过IE浏览器的F12,或者fireFox的debug工具,查看请求与响应;
5、 当发现问题后,不要急着记录问题,先自己确认问题,是否与浏览器、缓存等有关系,确认问题后,最好还可以找到问题的根源。
总之,在测试过程中,要学会发现问题并分析问题,在测试过程中积累测试技术专业知识。
 
七、软件测试知识
1、 先从软件测试基础知识学习开始;杜绝误区:测试理论知识不重要
2、 软件知识学习,测试是为软件服务的,软件工程、编程语言、架构、网络等,一切与开发有关的知识,建议都或多或少学一些,作为测试人员,要学习的东西非常多,不要求深度但要求广度;
 
八、软件测试这个职业
刚入门,或者工作了几年的测试人员都或多或少有这样的困惑,为什么测试人员的工资普遍低于开发人员?对于这个问题,我之前看到一篇博客中是这样写的:测试人员与开发人员,就像护士与医生。再优秀再专业的护士,也治愈不了病人的病,同样的,测试人员也做不出软件来,能做出软件来的都被认为是开发人员了。医院里有名的医生很多,但有名的护士几乎没有听到过,开发与测试的关系也是这样。所以,职责不同,必然有轻重之分,存在既有价值,医院不能没有护士,软件开发也需要测试。我也深信,必然有很多一直在软件测试道路上继续前进的人。既然选择了软件测试行业,那么就希望可以在软件测试行业的发展价值达到最大化。

Testin远程真机更新日志V1.0.1-1.0.6

真机调试喵二爷 发表了文章 • 1 个评论 • 112 次浏览 • 2016-11-13 14:28 • 来自相关话题

V1.0.1(添加“外链”安装方式)

1.真机控制页,调整页面布局,收起设备信息的显示

2.真机控制页,修改应用安装逻辑,添加“外链”安装方式

3.离开或者刷新页面添加确认提示,避免误操作




V1.0.2(流畅/高清切换)

1.支持流畅/高清的显示切换

2.优化真机所有确认提示框的显示样式




V1.0.3(修改日志布局和交互)

1.调整布局 Logcat调整到屏幕下方,并支持最大化、最小化和上下拖动

2.调整adb信息为单独的Tab,同时添加adb使用说明

3.优化 截图的保存和删除按钮位置

4.优化 默认状态时,日志为空的操作指引




V1.0.4(添加iOS入口)

1.真机列表页,添加iOS机型的入口

2.真机控制页面的打开方式修改为“从新页面打开”

3.真机控制页,应用添加“打开”功能

4.真机控制页,添加“卸载中”状态,设备信息显示等细节优化
 
 
 
V1.0.5(添加一键安装常用应用)

1.安装----安装应用添加“安装QQ等常用应用”

2.配额----修改用户配额少于十分钟的提示和处理逻辑

3.安装----安装应用的限制说明修改为Title的形式







V1.0.6(优化计时规则)

1.计时规则----使用过程中,配额用完之后,提示配额已用完,但还能继续完成本次测试

2.计时规则----手机初始化完成,并正常显示手机屏幕时再开始计时

3.初始化提示----初始化提示显示15分钟,添加下次不再提示的选项

4.其他产品体验细节 查看全部
V1.0.1(添加“外链”安装方式)

1.真机控制页,调整页面布局,收起设备信息的显示

2.真机控制页,修改应用安装逻辑,添加“外链”安装方式

3.离开或者刷新页面添加确认提示,避免误操作




V1.0.2(流畅/高清切换)

1.支持流畅/高清的显示切换

2.优化真机所有确认提示框的显示样式




V1.0.3(修改日志布局和交互)

1.调整布局 Logcat调整到屏幕下方,并支持最大化、最小化和上下拖动

2.调整adb信息为单独的Tab,同时添加adb使用说明

3.优化 截图的保存和删除按钮位置

4.优化 默认状态时,日志为空的操作指引




V1.0.4(添加iOS入口)

1.真机列表页,添加iOS机型的入口

2.真机控制页面的打开方式修改为“从新页面打开”

3.真机控制页,应用添加“打开”功能

4.真机控制页,添加“卸载中”状态,设备信息显示等细节优化
 
 
 
V1.0.5(添加一键安装常用应用)

1.安装----安装应用添加“安装QQ等常用应用”

2.配额----修改用户配额少于十分钟的提示和处理逻辑

3.安装----安装应用的限制说明修改为Title的形式







V1.0.6(优化计时规则)

1.计时规则----使用过程中,配额用完之后,提示配额已用完,但还能继续完成本次测试

2.计时规则----手机初始化完成,并正常显示手机屏幕时再开始计时

3.初始化提示----初始化提示显示15分钟,添加下次不再提示的选项

4.其他产品体验细节

Testin远程真机FAQ

真机调试喵二爷 发表了文章 • 0 个评论 • 170 次浏览 • 2016-11-13 14:21 • 来自相关话题

1.    总共有多少台设备,有多少iOS设备,有海外设备吗?

Testin真机调试服务总共可以接入50000+的真实设备,目前我们根据前期用户需求的情况,只在线上提供了16台iOS设备,其中包括2台iPad设备,后续可以根据商业客户的需要,随时增加特定的机型。我们暂时没有提供海外设备用来进行真机调试,若客户有迫切的海外设备调试需求,我们可以酌情提供海外服务节点,以供客户使用海外设备进行远程真机调试。

2.    UDID是什么,下面那个不稳定是什么意思?

UDID是iOS设备的唯一识别码,可以看作一个UDID就对应了唯一的一台iOS设备,当客户使用iOS真机调试时,需要根据我们提供的UDID来生成对应的证书,具体证书的生成方法可以参考苹果开发者官网,只有在客户的app证书中加入了设备的UDID,才能成功上传并安装一个iOS应用。

3.    对用户网速的要求是多少?

真机调试服务本身的配置是双专线50M+50M带宽,能够保证多用户同时在线并流畅的使用手机设备,对于用户来说,我们推荐使用2Mbps以上的出口带宽,小于这个带宽也是可以使用服务的,并不会带来很明显的卡顿的现象。

4.    是否支持设备预约?

预约功能仅对VIP用户开放。

5.    设备的排队机制是什么?

真机服务实行先到先得原则,对于一个机型有多台设备的情况,每次用户使用都会占用一台具体的设备,直到把这个机型的所有设备全部占用之后,后面的用户会看到这个机型处于使用中状态,无法立即使用,直到有用户退出该设备后,后面的用户才能再进去使用。真机服务原则上设备是不排队的,使用者需要按照先到先得规则来排队。

6.    是否支持客户设备存放在我们机房作为专用设备?

客户的设备,只要不会泄露我们机房内部的信息,并且本身支持远程调试,我们非常欢迎拿到机房来做测试,不过目前我们的公有云服务不支持客户专区,只要连接上服务,就会对所有人开放,客户如果需要单独调试自己的设备,不想要其他用户看到这些专属设备,那么我们可以将其接入征途业务线部署的真机VIP服务,客户需要提前预约VIP服务的时间,由我们的客服人员来协助客户远程进行调试。

7.    兼容测试设备和真机设备匹配吗?

兼容测试和真机调试是Testin一站式测试服务的两个重要环节,兼容测试报告呈现出来的问题,客户立刻能够使用真机调试服务来复现并且解决,线上没有的设备可以进行预约。(预约服务目前只对VIP用开放)

8.    稳定性有没有一个量化的指标?

原则上是提供7x24小时服务,但实际上我们需要预留设备维护的时间,实际我们会提供7x20小时服务。对于使用上的一些问题,我们随时有专人来引导,对于机器临时死机或者掉线等异常情况,我们承诺12小时内解决,对于服务器宕机等重大问题,我们承诺24小时内解决,对于缺少用户需要调试的机型等问题,我们酌情在一周内解决。 查看全部
1.    总共有多少台设备,有多少iOS设备,有海外设备吗?

Testin真机调试服务总共可以接入50000+的真实设备,目前我们根据前期用户需求的情况,只在线上提供了16台iOS设备,其中包括2台iPad设备,后续可以根据商业客户的需要,随时增加特定的机型。我们暂时没有提供海外设备用来进行真机调试,若客户有迫切的海外设备调试需求,我们可以酌情提供海外服务节点,以供客户使用海外设备进行远程真机调试。

2.    UDID是什么,下面那个不稳定是什么意思?

UDID是iOS设备的唯一识别码,可以看作一个UDID就对应了唯一的一台iOS设备,当客户使用iOS真机调试时,需要根据我们提供的UDID来生成对应的证书,具体证书的生成方法可以参考苹果开发者官网,只有在客户的app证书中加入了设备的UDID,才能成功上传并安装一个iOS应用。

3.    对用户网速的要求是多少?

真机调试服务本身的配置是双专线50M+50M带宽,能够保证多用户同时在线并流畅的使用手机设备,对于用户来说,我们推荐使用2Mbps以上的出口带宽,小于这个带宽也是可以使用服务的,并不会带来很明显的卡顿的现象。

4.    是否支持设备预约?

预约功能仅对VIP用户开放。

5.    设备的排队机制是什么?

真机服务实行先到先得原则,对于一个机型有多台设备的情况,每次用户使用都会占用一台具体的设备,直到把这个机型的所有设备全部占用之后,后面的用户会看到这个机型处于使用中状态,无法立即使用,直到有用户退出该设备后,后面的用户才能再进去使用。真机服务原则上设备是不排队的,使用者需要按照先到先得规则来排队。

6.    是否支持客户设备存放在我们机房作为专用设备?

客户的设备,只要不会泄露我们机房内部的信息,并且本身支持远程调试,我们非常欢迎拿到机房来做测试,不过目前我们的公有云服务不支持客户专区,只要连接上服务,就会对所有人开放,客户如果需要单独调试自己的设备,不想要其他用户看到这些专属设备,那么我们可以将其接入征途业务线部署的真机VIP服务,客户需要提前预约VIP服务的时间,由我们的客服人员来协助客户远程进行调试。

7.    兼容测试设备和真机设备匹配吗?

兼容测试和真机调试是Testin一站式测试服务的两个重要环节,兼容测试报告呈现出来的问题,客户立刻能够使用真机调试服务来复现并且解决,线上没有的设备可以进行预约。(预约服务目前只对VIP用开放)

8.    稳定性有没有一个量化的指标?

原则上是提供7x24小时服务,但实际上我们需要预留设备维护的时间,实际我们会提供7x20小时服务。对于使用上的一些问题,我们随时有专人来引导,对于机器临时死机或者掉线等异常情况,我们承诺12小时内解决,对于服务器宕机等重大问题,我们承诺24小时内解决,对于缺少用户需要调试的机型等问题,我们酌情在一周内解决。

多链接合并模式

A↗B测试祁宇 发表了文章 • 0 个评论 • 93 次浏览 • 2016-11-12 16:34 • 来自相关话题

在进行H5页面的试验时,若不同设计方案差异很大,不适用可视化或编程模式时,或者已经拥有多个不同的页面,可采用多链接合并模式。将多个URL合并生成唯一的试验URL,当用户访问试验URL时,将会自动分流到各个试验页面中,并获取行为数据,验证哪个URL转化率更高。

我们将以优化页面上的一个标题的文案为例,来说明如何使用多链接合并模式。先通过一张简单的流程图了解所需的步骤,再一步步进行具体操作:



1.登录Testin A/B 测试,选择相应的项目环境创建应用。建议以「产品名+环境+项目主题」的方式命名,例如:「AppAdhocH5申请页面」。需要注意的是,Testin A/B 测试对名称的设置只支持中英文和数字输入,无法使用特殊字符。



2.创建试验,选择「多链接合并模式」,进入下一步。输入试验名称,试验描述选填,选择试验分层,为了方便寻找,可以将此次测试的内容设置为试验名称。



3.编辑版本,每个试验版本对应一个独立页面,请在此填写您的页面链接,原始版本的链接将作为试验URL。当用户访问试验URL时,将会按照设定的流量比例进入到对应的试验版本中。点击“添加版本”按钮,可添加多个试验版本,并且可删除(建议需要测试的页面有相关性)。

需要注意的是:请在所有试验页面的<head>部分加入javascript代码,否则无法读取和编辑页面。



4.创建「优化指标」(点击了解如何选取优化指标)。同样,将优化指标设置完成后,需要对其进行代码集成。若在试验开始运行前,有指标增减的情况,应及时将代码同步。

需要注意的是:每个试验版本都需要集成优化指标。

Testin A/B 测试支持在多链接合并模式下对复合指标的统计,也就是通过对已添加优化指标的组合计算,来表现一个复合型指标的数据,目前支持+-*÷及()运算。需要说明的是,复合指标无需单独集成代码埋点。



5.在开始运行试验前,Testin A/B 测试支持用户直接通过后台选择,强制进入试验环境,验证代码集成是否正确,并提前检测试验版本的效果。同时,相关测试数据将不计入试验结果。

选择试验版本并点击按钮,就会跳转试验版本页面。同时,当对该页面进行操作,且相应的测试数据也会发生变化时,说明试验版本已经成功集成。若无法进入测试版本(包括原始版本)或无法正常统计试验数据,可能是集成过程中出现了错误,需修正后重新进行检验。 重复上述操作,确保所有版本都验证正确,再进行下一步操作。



优化指标将在下表展示。



试验开始后,也可进入此页面进行调试,调试数据不会干扰试验结果。

6.点击「开始试验」按钮,正式运行试验所有试验版本。进入试验运行中的控制页面,可以实时对试验流量进行调整。多链接合并模式下可以直接在版本管理界面新增版本或者修改版本名称、说明、文案等。若想更换优化指标,则需要重新集成代码。

需要注意的是:添加新的版本后需要再次加入javascript代码。



7.进入试验控制页面,开始分配版本流量。我们提倡先从小流量入手,逐渐增大流量分配。在这里我们首先给试验版本分配了10%的流量,为了便于数据对比,我们同样将原始版本的流量设置为10%。剩余未被分配的80%流量,用户仍将看到原始版本,但这部分的用户行为数据不会计入试验数据中。



8.运行一段时间后,可以通过「试验概况」和「指标详情」查看试验数据详情。关于不同图表的具体解读,请参见如何用数据决策。



9.根据试验情况,适当调整流量。案例中的试验版本在小流量内的表现较好,因此我们将版本流量逐步放大至20%。为了保证版本流量的一致性,原始版本也同时提高到20%。



10.一般来说,为了获得更加可信的数据结果,试验运行周期应至少保证1-2个完整的自然周,如果遇到节假日,运行周期应适当延长。对比不同版本的指标数据,若置信区间上下限同为正或同为负,说明试验结果显著;否则,请延长运行时间,若依然无显著表现,则说明版本间差异不大。在这里,试验版本的95%置信区间显示为[+30%,+35%],说明若上线试验版本,则有95%的可能将转化率提高30%~35%,点击了解更多置信区间详情。在得出可信的试验结果后,根据数据报告,选出表现最优的版本,将试验关停或一键发布。由于试验版本的结果显著且增长,因此我们在「运行控制」页面确定将其发布。


11.至此,我们就完成了一个多链接合并模式测试。试验版本正式发布后,所有用户都会看到优化过的标题文案。若试验结果显示原始版本的表现更好,则可选择关停试验版本,关停后,所有用户都将回到原始版本。



12.Testin A/B 测试支持在同一账户下创建多个应用和试验,可分别在登录页面和「试验列表」模块查看详情。同时,账户内的所有优化指标设置,都可以在任意应用内的「SDK集成」模块中查看。 查看全部
在进行H5页面的试验时,若不同设计方案差异很大,不适用可视化或编程模式时,或者已经拥有多个不同的页面,可采用多链接合并模式。将多个URL合并生成唯一的试验URL,当用户访问试验URL时,将会自动分流到各个试验页面中,并获取行为数据,验证哪个URL转化率更高。

我们将以优化页面上的一个标题的文案为例,来说明如何使用多链接合并模式。先通过一张简单的流程图了解所需的步骤,再一步步进行具体操作:



1.登录Testin A/B 测试,选择相应的项目环境创建应用。建议以「产品名+环境+项目主题」的方式命名,例如:「AppAdhocH5申请页面」。需要注意的是,Testin A/B 测试对名称的设置只支持中英文和数字输入,无法使用特殊字符。



2.创建试验,选择「多链接合并模式」,进入下一步。输入试验名称,试验描述选填,选择试验分层,为了方便寻找,可以将此次测试的内容设置为试验名称。



3.编辑版本,每个试验版本对应一个独立页面,请在此填写您的页面链接,原始版本的链接将作为试验URL。当用户访问试验URL时,将会按照设定的流量比例进入到对应的试验版本中。点击“添加版本”按钮,可添加多个试验版本,并且可删除(建议需要测试的页面有相关性)。

需要注意的是:请在所有试验页面的<head>部分加入javascript代码,否则无法读取和编辑页面。



4.创建「优化指标」(点击了解如何选取优化指标)。同样,将优化指标设置完成后,需要对其进行代码集成。若在试验开始运行前,有指标增减的情况,应及时将代码同步。

需要注意的是:每个试验版本都需要集成优化指标。

Testin A/B 测试支持在多链接合并模式下对复合指标的统计,也就是通过对已添加优化指标的组合计算,来表现一个复合型指标的数据,目前支持+-*÷及()运算。需要说明的是,复合指标无需单独集成代码埋点。



5.在开始运行试验前,Testin A/B 测试支持用户直接通过后台选择,强制进入试验环境,验证代码集成是否正确,并提前检测试验版本的效果。同时,相关测试数据将不计入试验结果。

选择试验版本并点击按钮,就会跳转试验版本页面。同时,当对该页面进行操作,且相应的测试数据也会发生变化时,说明试验版本已经成功集成。若无法进入测试版本(包括原始版本)或无法正常统计试验数据,可能是集成过程中出现了错误,需修正后重新进行检验。 重复上述操作,确保所有版本都验证正确,再进行下一步操作。



优化指标将在下表展示。



试验开始后,也可进入此页面进行调试,调试数据不会干扰试验结果。

6.点击「开始试验」按钮,正式运行试验所有试验版本。进入试验运行中的控制页面,可以实时对试验流量进行调整。多链接合并模式下可以直接在版本管理界面新增版本或者修改版本名称、说明、文案等。若想更换优化指标,则需要重新集成代码。

需要注意的是:添加新的版本后需要再次加入javascript代码。



7.进入试验控制页面,开始分配版本流量。我们提倡先从小流量入手,逐渐增大流量分配。在这里我们首先给试验版本分配了10%的流量,为了便于数据对比,我们同样将原始版本的流量设置为10%。剩余未被分配的80%流量,用户仍将看到原始版本,但这部分的用户行为数据不会计入试验数据中。



8.运行一段时间后,可以通过「试验概况」和「指标详情」查看试验数据详情。关于不同图表的具体解读,请参见如何用数据决策。



9.根据试验情况,适当调整流量。案例中的试验版本在小流量内的表现较好,因此我们将版本流量逐步放大至20%。为了保证版本流量的一致性,原始版本也同时提高到20%。



10.一般来说,为了获得更加可信的数据结果,试验运行周期应至少保证1-2个完整的自然周,如果遇到节假日,运行周期应适当延长。对比不同版本的指标数据,若置信区间上下限同为正或同为负,说明试验结果显著;否则,请延长运行时间,若依然无显著表现,则说明版本间差异不大。在这里,试验版本的95%置信区间显示为[+30%,+35%],说明若上线试验版本,则有95%的可能将转化率提高30%~35%,点击了解更多置信区间详情。在得出可信的试验结果后,根据数据报告,选出表现最优的版本,将试验关停或一键发布。由于试验版本的结果显著且增长,因此我们在「运行控制」页面确定将其发布。


11.至此,我们就完成了一个多链接合并模式测试。试验版本正式发布后,所有用户都会看到优化过的标题文案。若试验结果显示原始版本的表现更好,则可选择关停试验版本,关停后,所有用户都将回到原始版本。



12.Testin A/B 测试支持在同一账户下创建多个应用和试验,可分别在登录页面和「试验列表」模块查看详情。同时,账户内的所有优化指标设置,都可以在任意应用内的「SDK集成」模块中查看。

3.7 Server端编程式试验

回复

A↗B测试鲁宇星 发起了问题 • 1 人关注 • 0 个回复 • 131 次浏览 • 2016-11-12 16:17 • 来自相关话题

3.6 客户端结合 Server 端的试验

回复

A↗B测试鲁宇星 发起了问题 • 1 人关注 • 0 个回复 • 113 次浏览 • 2016-11-12 16:15 • 来自相关话题

3.5 多链接合并模式

回复

A↗B测试鲁宇星 发起了问题 • 1 人关注 • 0 个回复 • 107 次浏览 • 2016-11-12 16:14 • 来自相关话题