移动应用众测之“Bug探索测试”实战-创新互联
随着移动互联网业务的高速发展，越来越多的人认识到Bug探索众测的重要性。那么什么是Bug探索众测呢？Bug探索众测是测试专家Cem Kaner博士在1983年提出的，Bug探索众测是一种软件测试风格，它强调独立测试人员的个人自由和职责，为了持续优化其工作的价值，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，在整个项目过程中并行地执行。该定义包含三个方面的内容:
一种思维方法
Bug探索众测强调依据当前环境选择合适的测试手段，而不局限于特定的测试技术。测试人员可以在探索式测试中使用任何一种测试技术，也可以将探索式风格应用于任何测试活动。
一种责任
Bug探索众测人员应该为个人和团队负责，调动所有能量，发挥人的灵活性。
循环迭代
Bug探索众测旨在将测试学习、测试设计、测试执行和测试结果分析作为一个循环快速地迭代，以不断收集反馈、调整测试、优化价值。
常规测试方法的不足
常规的测试方法，可以有效确保测试人员设置的单个或者多个常见场景不会出现大的问题，但是用户的使用环境和APP开发方的环境千差万别，与测试人员完全不同的网络环境(2G、3G、4G、WIFI)、 不一致的运营商(电信，移动，联通)，完全不同的手机设备和OS系统，如此种种，传统测试无法覆盖所有可能性和场景，这也是很多产品设计优秀，但依然差评满满的根源。这个时候移动应用Bug探索众测就显得尤为重要和必要。
Bug探索众测在不同企业的应用
在不同的企业应用Bug探索众测有着不同的方式方法。在大型企业中（银行、保险、证券、政府、上市公司等），拥有大量的内部员工，每个员工都拥有1-2款个人移动设备，这种天然的优势为企业内部众测提供了充沛的资源，大型企业可以“足不出户”依托健全的众测信息化管理平台，完成移动应用的Bug探索众测。而中小企业（创业型的互联网公司，无法调动更多内部资源的信息化部门等），并不具备充沛的可用资源优势。这类企业开展Bug探索众测显然需要外部力量的支持，可以选择成熟、口碑好的众测平台，由外部众测平台提供测试专家资源完成相应的Bug探索众测。
常规测试与Bug探索众测
常规测试是测试质量保障的重要手段，Bug探索众测能够有效补充常规测试不能覆盖的场景、多种用户行为等差异化测试内容。两者相互结合，相互补充，缺一不可。
• 探索测试的大特色是在对测试对象进行测试的同时，创造新的、区别于固有的测试思想及方法。这相对于传统软件测试过程中严格的“先设计，后执行”来说，是具有很大区别的。
• 探索测试强调测试过程中要有更多的发散思维，这也是与保守测试方式的大区别。保守测试方式强调设想完善的测试用例，测试人员严格按测试用例执行测试，这多少限制了测试人员的测试思维，测试人员往往缺乏主观能动性。
• 探索测试让测试工作脱离常规用例，深度挖掘应用中不易被发现的Bug，确保产品质量稳定，提升产品体验。
• 多人大面积验证核心功能，通过发散性测试，模拟各种异常场景和极端测试方法，找出各类潜在问题和风险。
• Bug探索众测模拟真实用户角度，结合团队测试经验，大限度探索用户使用习惯和路径，探索复杂操作流程；真实模拟异常应用场景及系统特有功能，确保主要功能使用流畅，避免影响用户体验的问题，发现研发人员不易发觉的Bug。
测试环境准备
移动应用的Bug探索众测，通常是在外网环境进行，可选择有安全防护配套的SIT环境、UAT环境，也可以选择灰度发布环境，以及生产环境。需要特别指出：信息安全防护以及涉及知识产权保护等涉密环节应尽可能回避，因为众测可能在非本机构内开展。APP安装包的加固也是非常重要的环节，通常情况下，研发过程中的测试包未进行加固处理。
Bug探索众测，需要一套相对稳定的环境，如果用于该项任务的测试环境每天都会多次集成和发布版本，会影响众测的效果，可能的情况：提出很多因为环境问题相关的无效缺陷，或者导致测试中断，测试者情绪严重受挫，从而测试效果大打折扣。
测试设计
Bug探索众测，通常是两种模式：基于场景探索或者自由式探索。显然，基于场景的Bug探索众测更具有针对性，无论是问题的聚焦程度，还是Bug的提出质量，都远远好于自由式探索的众测。
基于场景的众测，并不需要给出非常详细的Test Case（Step By Step方式），虽然详细的测试步骤指向性非常明确，但也会极大的限制测试者的思维。基于场景的众测，只需要给出明确的目标，如：1、完成注册 2、完成商品选择 3、完成订单支付等测试内容，让测试者基于目标去探索执行过程中存在的Bug。
测试的组织与执行
Bug探索众测在任务发布后，通常会在很短的时间结束，没有周期的任务一般是24小时内结束。在24小时内，您要做的不只是等待测试结果的反馈，还需要解决参与者提出的各种问题。参与Bug探索众测的人员一般是本Team以外的测试者，可能对产品的首次使用存在一定的疑问。这个是正常的，或许您可以从他们的疑问中能够发现产品设计的问题，因为2C的移动应用是不需要任何操作手册的，如果用户上手困难，这本身就是严重的体验问题。如何处理测试者的疑问和问题，需要有健全的众测信息化管理平台来解决，或通过IM方式，或通过公告管理的方式。
测试结果确认
测试结果确认，主要工作为测试执行过程的确认以及Bug的确认。测试执行过程确认是指，识别测试者确实按照既定的场景完成了整个Bug探索测试过程，通常以截图、视频等方式作为依据。Bug确认是测试结果确认的重点，包括：有效Bug识别、无效Bug识别、重复Bug识别，需要进一步重现的Bug等。这是一件有些工作量的工作，看起来很复杂，但是如果运用了自动识别重复Bug的功能，会让重复Bug识别变得智能高效。目前，很多企业在使用QQ群、微信群等方式管理众测，显然无法达到高效管理众测的目的。
Bug探索众测报告
Bug探索众测报告是对整个测试活动的总结，包括：众测时间的花费、众测费用的花费、众测覆盖程度分析、众测发现的Bug分析，以及众测结果数据能够度量的风险分析等。应用平台化管理，上述内容是可以自动输出的，无须人为重新采集数据。
基于共享经济模式的Bug探索众测模式，让测试一切变得更高效，为敏捷迭代提供了一个非常好的途径方法。
当前题目：移动应用众测之“Bug探索测试”实战-创新互联
当前URL：http://scyanting.com/article/picoe.html
