接口测试脚本重构之感想
软件测试流程包括：需求分析、需求评审、设计评审、制定测试计划、测试用例设计、测试用例评审、测试脚本编写、执行测试、提交测试报告。各个阶段都是重要的，无论哪个阶段处理的不到位，都会影响到测试的进度、效率、成本，直接影响到产品的质量。
需求分析、需求评审、设计评审这三个阶段是关键，影响到所实现的功能是不是客户想要的功能，实现此功能的方案是不是可行的。这三个阶段要做好，需要运营、开发、测试三方有效的沟通，测试人员在做任何评审之前好尽可能多的了解需求，了解设计方案，这样评审时可以带着问题去讨论，去把可能出现的问题暴露出来。由于是做底层系统的接口测试，很多需求的直接来源并不是运营，而是上层应用的开发，之前底层开发人员直接把上层应用开发的需求告诉我们，有时根本不没在需求评审和设计评审，从而测试了解到的需求是单方面的，并不是完整的，因此会影响到测试用例的设计以及由于需求有问题导致测试成本的浪费。作为一名测试人员在测试时需要严谨的态度和负责的心之外，我觉得测试流程也要学习和灵活的去运用它，有效地主动地沟通尽可能的避免由于需求有偏差导致后期的重新测试。
制定测试计划包括各个阶段所要测试的功能点、开始测试时间、完成测试时间、测试方法、以及预估的风险。制定合理的测试计划，不仅可以让测试人员明确在哪个阶段用什么样的测试方法完成哪些功能的测试，而且可以让开发人员和测试PTM清楚整个测试周期以及把控开发提交代码和测试的进度。在测试过程中要根据测试的情况，不断的优化测试计划，以满足功能点在某个时间范围内能测试完成，同时把风险早点抛出来有利于团队一起尽早解决问题。
我一直在思考接口测试如何提高测试用例质量的问题，通过对xx系统接口测试脚本的重构，从而意识到业务是根本，而且业务学习要从面到线，线到点。首先要明确客户是如何使用这块业务，其次要知道底层相关业务的接口是被哪些应用调用的，再次底层接口又是如何实现这个业务功能。我在对某个业务的测试脚本重构时，会按以下的步骤进行：
1. 站在客户的角度去使用该业务相关的功能，凭借自已对这个业务的了解画出mm图，只画出该业务的一级业务点。
2. 因为接口测试是对暴露给上层应用的接口进行测试，所以接下来是了解业务相关暴露出去的接口有哪些，接口测试的切入点是从这些接口进行测试的，从而在mm图业务点上标明所对应的接口。
3. 设计测试用例，第一，站在业务的角度把子业务点整理出来，写出业务测试用例；第二，查看第2步整理出来的接口从而了解该业务功能是如何实现的，看是否有业务用例要补充的；第三，根据接口参数去设计异常流的测试用例，如果代码中处理了某种异常则也要设计接口测试用例；第四，事务相关的接口要设计事务相关的测试用例。
4. 测试用例评审，因为是重构工作，业务需求是确定下来的，除了页面展现层或者上层应用控制的测试用例之外，基本上接口测试的用例应该是多于功能测试用例的，所以我会查看qc中对应的功能测试用例与我设计的接口测试用例进行比较，保证测试用例是完全的。有疑问的测试用例及时找功能测试人员和开发一起评审。接口测试用例名称尽可能的同俗易懂。
5. 编写测试脚本有一定的规范，脚本的健状影响到后期持续集成阶段的维护成本。能公用的变量和方法尽量灵活的抽取出来，适当的建些不同业务的测试基类。在测试脚本中准备的测试数据、调用被测接口、验证结果这三点尽可能表达的清楚点，让大家都能看明白。
6. 通过在eclipse中安装clover插件，同时跑这个业务包下的测试类，可以帮助我们查找开发中哪些代码我们测试用例没有覆盖到，从而补充测试用例，提高业务和代码覆盖率。在eclipse安装clover插件的方法如下所示：
Help->software updates->Add Site中输入http://update. eclemma .org/ ->点击Install进行安装 ->重启eclipse
7. 提交bug也是一门技术，接口测试的bug描述和功能测试的bug描述差不多，表达哪个业务场景下会出什么样的问题。如果知道缺陷原因则把具体的出错接口标明出来，方便开发修复问题 提交测试报告，测试报告中包括各个业务功能点测试的情况、bug的修复情况、风险评估，代码覆盖率情况。
