测试是保证产品质量的关键环节，不论是从开发人员开始的单元测试，集成测试，到测试人员的系统测试，产品的需求测试，客户的验收测试，都是为了保证产品能够更健壮的在市场上服务于用户，但是测试的整个工作和过程并不像开发的工作一样有一个产品的产出，所以更大程度上增加了对测试工作质量的考核，也就造成了对产品测试完成后无法有一个可靠的依据去判断是否能够保证产品在市场中稳定运行，测试过程中也必然存在着在各种各样的问题和困难。
在传统的测试中，测试后期往往会出现如下几个问题：
经常出现开发改动测试不知道、或者测试范围评估不足以及测试人员对产品没有足够的了解等都会导致测试漏洞风险高，成为线上事故的导火线，并期望能够通过代码覆盖率工具提高覆盖度。
测试：“时间太紧，感觉没测试全就上线啦！再有几天就好了。” 时间紧迫，根本无法规划自己的测试思路和范围，感觉自己没有测全，心里没有底儿。如果可以有工具帮助做测试的筛选和统计就好了，通过代码覆盖率判断产品是否能够达到上线标准。
有时候开发给出的回归范围太大，导致测试回归测试成本很高。时间上和人员上都需要大量的资源投入，还是希望能够通过代码覆盖率工具做到精准测试，从而降低不必要资源的投入，提高工作的效率。
测试和开发在后期交流中因人为交际因素往往产生各种不可预计的状况
如：
友好：
开发修改完代码后，测试人员直接询问开发是否测试过，如果开发自己测试过一遍，测试就认为已经测试完毕。
矛盾：
出现重大问题后，开发和测试相互推卸责任，导致团队开发和测试关系僵化。
下图为 2015 年某明星互联网产品公司线上事故的范围：
我们可以看到，在整个事故中一大半都是因为开发与测试沟通或测试对业务不了解，遗漏而产生的故障。要避免这样的事故，首先需要把占比高的问题解决，就可以从很大程度上提升产品的质量。
那我们该如何去解决这些问题，我们从下面的九点钟项目案例中讲解对于提高测试的覆盖率，测试开发的沟通，测试的遗漏，测试范围评估错误等如何有效的利用现有资源进行解决。
九点钟酒店控项目是一款酒店垂直细分领域的钟点房预定 APP，它可以让用户通过手机端的应用预定上海的合作酒店，方便快捷，通过自动定位选择附近的可预订酒店，以及按照价格和距离等选择合适的酒店进行预定，经济实惠，提前预定，解决外出住宿问题。未来，它还会跟更多的旅游频道合作，发展空间很大。
本文描述九点钟项目的安卓 APP，在精准化测试平台（星云测试）通过测试得到测试报告以及相关的测试数据分析，通过手工黑盒测试和程序内部的逻辑测试对整个应用的质量把控，降低产品上线后存在的问题。
采用常规的边界值分析法，正交分析，因果图，以及等价类划分等多种方法进行测试用例的设计，例如：
1、 对于输入框字符长度有限制的采用限制字符数的边界值进行测试用例设计
2、 对于搜索项进行因果图方法设计测试用例
3、 对于酒店列表筛选进行正交分析法进行测试用例的设计
4、 根据用户的体验习惯进行探索性测试等
1、 本地环境（云测试版本，主需要配置本地的客户端使用环境，服务在云端不需配置）
2、 PC 端测试网络需要能够连通星云测试服务端的地址即可
3、 手机端的可以使用 WIFI，或使用 USB 连接测试
测试方法：
采用黑盒手工测试的方法，进行测试
测试工具：
采用星云测试Android 云测试版客户端 2.1.4 版本进行测试，该工具通过手动的黑盒测试驱动，检测和记录程序内部的执行逻辑，快速定位 BUG，并且自动捕捉程序崩溃点，测试回归筛选，测试数据整合展示云测试精准报表，对于测试人员、设备以及测试任务执行时间按照天为单位进行统计用图表形式展示整个过程的趋势。并且对整个项目的代码质量重复度，复杂度，可维护性等进行了指标分析和展示。
注意事项：
下面的分析均有代码表述，如测试人员无查看代码权限，可只使用测试数据和开发人员进行交互分析，开发人员通过星云平台测试数据在本地关联代码进行配合分析。
很多项目到了后期都会出现较难维护的情况，主要是因为代码量的增加以及开发人员的变动或代码的编写规范导致对其后续人员对内部逻辑理解困难。
通过静态监测分析我们可以看出九点钟项目在代码中缺少了大量的注释，并引用了大量的重复代码以及违规的代码，重复代码会造成重复部分容易出现缺陷重复等问题，违规代码会造成代码的易读性和维护变得困难，并且还会存在潜藏的代码逻辑 BUG 以及资源关闭等等代码中容易出现错误的地方，因此要根据一个特定的规则集进行代码的规范，这些虽然在项目生成以及使用上不存在问题，但是考虑到开发人员的交替以及后期的维护缺存在了大量的风险。
通过静态指标可是化查看违规以及重复的代码位置，用此数据报告和开发进行交互并可要求对代码进行改善
测试用例总数：136
执行测试用例：129
缺陷数目：60
测试用例通过率：67%
根据测试用例的执行来了解测试人员工作量和工作效率，以及整个测试的最终大概结果，通过率以及完成度，管理人员能够随时根据实际情况做出进度和工作上的安排调整，更好的管理团队和监督整个产品的测试进度。
根据 BUG 分类和严重程度的数据课判断该版本的整体质量，若是严重的 BUG 占比太高，则可能根据项目需要是否打回开发重新测试后再交于测试进行测试，保证不会有太多的流程上的缺陷，导致测试工作停滞不前，影响版本发布的实际时间。
通过星云测试测试过程监控趋势图，我们分析清晰地看到，项目九点钟在这几天的测试中的 BUG 发现情况，并通过测试用例执行得日期与 BUG 提交日期以及描述判断出，具有大量 BUG 的模块。如 9 点钟在 2015-12-7 号的时候做了很多测试用例以及提交了不少的 BUG。
通过直观的曲线绘制图能够看到一周内或截至目前为止整个测试工作期间 BUG 的发现率和测试用例的执行情况，测试人员的参与人数，根据实际要求进行管理和调整。
我们查看详细信息的描述
BUG 的详细列表显示的是所有发现的 BUG 以及每个 BUG 对应的提交人员和出现的测试环境以及对应的测试用例，都有利于我们判断 BUG 出现的主要因素和修复的方法，便于开发去修复并且也会考虑到同类环境下的兼容情况。
如：可以看出 2015-15-7 我们测试的重点主要在优惠卷、订单、支付等领域模块，在这个模块中出现不少的友好度或者操作上的问题，测试人员就可以拿此数据和开发进行交互，要求对这些模块进行总计修改。
按需求文档以及功能说明书设计并进行测试运行，通过星云测试查看出每日覆盖率增长趋势
在这几天的测试中，测试人员虽然遍历了完整的流程，但是覆盖率一直不高，段覆盖率才 41.1 针对这种情况，我们通过漏洞分析进行查找原因。
首先我们通过星云报表找出复杂度高密度以及覆盖率 0，这些都是测试漏洞，风险较高的遗漏点，若不逐一解决，后期上线后产生的问题造成的影响可能是相对比较严重地，为了避免这一现象的产生，我们必须把这些毒素攻克掉。这时，如果测试人员不懂代码可以邀请开发进行协助查看，通过可视化界面查看该函数的代码。
如 1：函数 ID 1465 handleMessage 通过代码可视化和开发交流得知，此模块为处理列表的上拉下拉的事件，但是在最新的九点钟项目中已经不在使用，这就造成了测试人员无法遍历到该模块的原因，对于这些废代码，测试人员有义务要求开发对其注释掉，或者进行删除处理，这样使得后期对代码的维护有了保障。
如 2：函数 ID 1880 isrefreshview scroll 通过代码可视化和开发交流得知，此模块为优惠卷拉升加载功能，但是此功能需要优惠卷超过一定量后才会出现，但是实际测试中，测试人员只得到了一张优惠卷的账号，在遍历中自然无法覆盖到该功能。
如 3：函数 ID 1530 zoom 通过代码可视化和开发交流得知，此模块为主界面地图功能，覆盖率不高的原因是：
该函数主要针对地图的比例进行不同的比例值选择，地图调节的情况，但是在九点钟中的地图是调用百度地图，如果要全部覆盖，需要后台对其代码进行相应的改动模拟。此状况主要针对核心功能的测试，测试人员需要预判该模块是否需要各种后台状态的处理测试，并和开发交互后进行配合性覆盖率提升。
如 4：函数 ID 1449 onClick 通过代码可视化和开发交流得知，此模块为酒店评论功能， 根据可视化分析
查到因为没有测试到酒店评论中评的情况，所以没有覆盖到，执行次数是 0，需要设计用例，酒店评论中评的情况，提高测试的覆盖率，保证没有严重的测试漏洞
Eg: BUG ID : 1
BUG 描述：无网络情况下，列表和菜单无法点击，需要优化，友好一些
通过 BUG 代码级追溯得到原因：双向追溯页面根据 BUG 用例追踪到代码，显示无网络情况下点击菜单后，没有任何提示，也不能够正常调用和执行，因此需要优化，建议开发人员添加相关提示。
测试不但是从功能上进行测试，还要以用户的身份去用户交互测试，体验测试，这些是直接影响到用户直接使用的，要想用户对产品有粘性，必须要做到用户体验更好，所以一些建议是很有必要的，这也是测试职责内需要做到的。
在以往的测试中，评价一个功能测试团队和测试人员，主要看他的寻找 BUG 的能力，但是在实际中，因测试项目的质量以及测试人员对业务的理解和测试人员的工作年限，不光只能靠 BUG 来进行评定。
星云报告通过对测试人员运行的测试用例、测试用例的覆盖率、测试用例 BUG 等关联，直接反映测试人员的测试状况，避免前言第 4 条测试与开发关系沟通问题，以及有针对性的对测试人员进行指导。
如：某个测试人员设计的测试用例很全面，运行遍历后，星云测试的报表覆盖率也很高，但是却始终发现不了 BUG，这时我们可以判定为 2 种情况：第一种，该测试人员测试的项目确实没有很大的问题，第二种，测试人员对业务的理解有可能存在偏差，虽然运行了大部分的功能，但是 BUG 也包括友好度、逻辑输出等，这些都是业务理解层面的，针对这种情况，可以对该测试人员进行业务上的指导。
在很多测试场景中，测试人员在测试过程中没有发现任何问题，但是客户在使用过程中缺平凡出错，这些问题有不少是因为兼容性导致。如九点钟项目，开发在 15/11/23 发的最新版中，测试人员出现主界面点击功能无效和闪退等现象，但是开发那边缺没有任何问题，进排查开发使用的是 android5.0 以上手机，而测试人员使用的是 android4.2-4.4 手机。
针对上述问题，一般公司或者甲方都会要求测试团队配备主流的机型以及常用分辨率的手机，避免该事故。
星云测试报告会在测试人员在测试过程中记录该测试人员使用的测试设备，并和测试用例、BUG 等进行关联，可以有效地管理整个测试设备的使用以及对应情况。
开发人员的变更时导致项目维护困难的重大原因之一，在九点钟项目中，我们通过运行平台进行测试，把测试用例与其运行的函数进行关联，这使得后续开发人员或测试人员对起功能的理解可以通过测试用例与代码的关联进行，大大降低了开发人员通过开发文档、交接文档、自己阅读别人写的代码所消耗的时间。
在前言中提到：考虑不全，开发修改，测试范围评估错误，在传统的测试中，开发人员改动某个功能后，因开发人员不知道该功能会影响多少其它的调用功能，导致在和测试交代改动功能时候，往往会出现遗漏，以至于测试范围评估错误，通过星云测试用例、代码、模块的追溯关联，开发人员很明确的能看出某条代码对应的测试用例，以至于在修改过程中更多的考虑一致性修改。
在回归中因开发回归范围大或避免测试遗漏回归范围，往往在回归过程中要求测试进行全部回归，但是又因时间紧等因素导致测试不全，上线后测试心理没底。
在 9 点钟项目中，星云平台通过回归测试用例的自动选取，提取需要回归的版本的测试用例以及该版本之前所有版本的测试用例进行查询，获取每条测试用例最后运行的版本进行数据提取，并通过测试用例、代码、模块的追溯关联技术，与要回归的版本进行比对。分析出开发改动所影响最大的回归测试用例。
在测试时间不充足的情况，可以通过该功能和开发人员一起对其测试用例进行评估，圈定测试用例回归的范围，从而降低测试回归的成本。
以上的分析和讲解是星云测试平台对九点钟 app 进行测试后的真实数据，并且所有的案例都是我们的测试人员和开发人员相互沟通协同完成的，让开发和测试互动沟通，能够提高整个团队的工作效率，并且从该工作过程中也锻炼了测试发现问题的能力和判断问题的源头的分析能力，对产品内部程序的逻辑有更深刻的接触和了解，达到精准测试，减少不必要的工作量，保证产品质量，无高风险测试漏洞，上线更稳定。
