测试常见名词解释

记录一下这两天实习听到/用到的新名词。

一、bugbash

Bug Bash 通常发生在项目开发各阶段（里程碑）的末期，比如 Beta 版发布前，划出一个专门的时间段（通常 1-3 天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的 Bug 。

经验

1、         尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益。

2、         要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的 Bug 。

3、         为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现 Bug 最多，发现最严重 Bug 的个人，给以物质和精神奖励。

4、         可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。

5、        as usual we'll have pizza and other fun food. Sometimes there's prizes for most bugs kept, most heinous bug, etc.

二、jenkins

Jenkins是基于Java开发的一种 持续集成工具，用于监控持续重复的工作，功能包括：

1、持续的软件版本发布/测试项目。

2、监控外部调用执行的工作。

Jenkins+Maven+SVN快速搭建持续集成环境(转)

http://www.cnblogs.com/sunzhenchao/archive/2013/01/30/2883289.html

三、打包、渠道包

渠道包指的是在各大应用市场，发布的apk包的清单文件中，某个meta-data标签下，配置的value不一样，这个标签的作用就是用来区分是哪个市场的，比如你发布到360.这个值就是你就可以配置成360，豌豆荚就可以配置成wandoujia，那么这么配置的作用是干嘛的？很简单，就是用来做统计的，比如我们项目中用的是友盟统计，它可以统计用户从哪个平台下载了你们的app，从而更好的掌握用户的操作习惯。所以，如果app没有统计功能的需求，你只需要打一个同样的包，直接发布到各个平台即可，根本不用关心什么渠道。            作者：孟远    链接：http://www.zhihu.com/question/22168194/answer/91813384

四、埋点文档

埋点的需求是有些前置要和各方确认的

用来埋点的数据是用来干嘛的（看运营转化的？加强风控的？还是功能迭代的？）
埋点后的数据怎么展现（很难一步到位的，一定先有什么，再有什么样子的对比）
之后根据上面的结论，和技术实现的负责人探讨怎么落实
这些有初步的结论就够写需求了


举个埋点的思路
某应用使用了友盟的插件，但还是需要看到运营活动时间段里的数据
可以埋点的除了登录日志这里，还可以在登录框那里，也可以在运营活动入口的按钮那里

作者：陈璐
链接：http://www.zhihu.com/question/40502836/answer/90113749

 五、冒烟测试

一、冒烟测试的准备工作

1、主流程和主功能的确认

因为我们公司的冒烟测试是测试在正式进入三轮之前对整个项目的主流程地验证，如果主流程不通过，是不可以开始正式测试的。这点就要求测试人员对自己项目的整体把握程度要强，在前期了解清楚需求后，把最重要的流程和功能列举出来，在冒烟测试前和开发人员一一确认，这对于冒烟测试是非常重要的一环。最好能够将功能点和流程在冒烟测试时要的预期结果和开发人员说明清楚。（虽然冒烟测试不像正式进入测试阶段要求测试结果那么准确，但是冒烟测试也最好列一个指标。有指标我们才能测衡量试是否通过。）

2、预计冒烟测试的最短和最大时间

 根据列出来的功能点和开发人员以往提交测试人员代码质量的可信度，评估下冒烟测试在不同环境下可能花费的最大时间和最小时间，然后列到测试计划中。

3、冒烟测试数据的准备

必须在前期对主要功能对应表的结构都了解地很透彻，需要准备的数据及时准备好。真正冒烟测试开始后，就不会因为准备数据或者了解表存储结构而浪费时间。

二、冒烟测试的执行工作

测试工程师严格按照前期的约定去校验主流程，全部校验完和开发人员报告情况！这个阶段其实在考验测试工程的执行能力，1就是1，2就是2，不可以马虎。可能放过一个主要的测试功能点，都可以对后面的测试进度有所影响，从而影响软件质量。

三、冒烟测试的总结工作

冒烟测试结束后的报告很重要，在报告里将冒烟情况说明：

1、时间：冒烟测试是否按时完成？按时完成皆大欢喜；但有延误的话，要分析这段时间是不是会对后面正式测试的时间有影响。如果影响比较大可以给开发提建议，看后期有什么补救的方法可以既保证了质量又保证了按时上线，比如提高开发人员修复BUG的效率，测试时间顺延等。

2、问题：分析冒烟测试中发现的问题，和开发人员强调这个影响主流程的问题在冒烟修复验证通过后，不能在正式测试中再次出现，否则加大测试人员重复验证的工作量，影响测试进度。

对于一个小项目，也许冒烟测试只是花费2，3个小时就结束了，但是冒烟测试是麻雀虽小，五脏六腑全有。从前期确认主要功能，到最后的总结报告，我觉得每个流程都不能马虎，只有都准备好了，才能真正意义达到“冒烟测试”意义：仅用一袋烟功夫完成测试。