之前一篇文章《思考功能测试》说了功能测试基本功，今天聊下功能测试做深时的横向扩展，也是对自己测试能力的进一步提升，从我个人经验总结选出以下三个大方面探讨下：
一： 对产品的把控
二： 对开发质量的把控
三： 对环境配置相关的把控
我们常开玩笑说，测试对于开发来说，是会产品的测试；测试对产品来说，是会开发的测试，所以在项目进行过程中，测试常常扮演者推动整个流程的角色
对产品的把控
这里说的对“产品”的把控，一方面是产品背景的项目知识的掌握，另一方面是产品出的需求文档的了解与掌握；
做一个项目测试，必须要了解你所测行业的背景以及相关知识，了解功能所面对的用户，知道用户真正想要的能接受的东西，这样你才能更好的理解业务，更好的理解产品需求文档，更好的从用户的角度去做测试，例如，你测商业广告，那你得了解下商业广告的这种知识背景，否则你连CPTCPC是啥都不知道你如何测试？
另一方面，产品注重的功能以及页面设计，但是需求的设计于开发的实现是否合理、是否完整，是否有更优的实现方案；举例说，现实中有没有开发看不懂需求的情况，因为写的实在太简洁了，简直不多浪费一个字；再举例说，现实中你肯定遇到过这种情况，需求测一多半了，突然发现现有的开发设计实现不能满足功能的需求甚至某个bug成为死结，用目前的方案根本无法解决，全部推翻重来，遇到这种坑~的情况也是醉醉的了，所以测试要通过功能结合开发实现，提前告知设计中的不合理情况。
对开发质量的把控
第一：拿到开发的代码权限，有能力的情况下尽量做到可以diff查看；另外一点，一定要了解下开发的版本控制，如果不合理一定要推动开发更换版本控制方法；现实中你有没有遇到过：之前测试明明可以的功能，怎么换个分支咋就不行了？这就是代码版本控制没做好。
对于SVN的版本控制:
TAG、主干、分支：迭代开发在主干，主干上完线打TAG；如果有临时上线或者紧急需求，从TAG拉分支进行开发上线，上线后打TAG，并合并代码入主干，并进行主干相关功能测试，避免代码合并问题；
这种方式是我用过比较舒服的一种版本控制，之前的版本控制是有测试把控的，所有的分支、TAG均由测试来控制，比较清晰明了；有不同意见的欢迎联系我们指正哈~
对于Git，我们目前在用的版本控制：
使用的是阉割版的gitflow，不使用它的hotfix和release分支，仅仅使用master,develop,feature三个分支：从devlop上拉取feature分支进行功能开发与提测，测试完成后合并入develop进行回归测试并上线，上线完成后合并入master分支，如下图
附上gitflow详细介绍: http://nvie.com/posts/a-successful-git-branching-model/
第二：我是坚持要求写用例要融入开发的设计文档的（有兴趣可以看下我之前写的用例设计篇），开发的提测要求：数据库、配置文件、代码实现逻辑（设计图或者不想写面对面对）；如果你不了解开发的实现逻辑，你的用例只能依赖于需求页面点点点，很多时候底层的实现问题发现不了，也就是说你的用例设计很容易出现遗漏（代码分支覆盖）；
另外对数据库，建表是否合理，比如：目前我在测物联网，云对接时设备信息下沉在后，用户信息在前，突然有一天对接把cookie信息放入设备表中，我当时觉得不合理，但是开发没有反馈，没人care这件事，目前的结果是修复用户绑定相关bug更困难，设备中融入了用户信息不合理得到开发确认，但目前开发需要修改方案就是大面积改动接口代码，代价是比较大。
配置文件测试一定要了解，原因是：如果对项目的配置文件不了解，想把控好测试环境那是不可能的了，后面我会讲配置管理-环境部署。对我来说，配置文件通常意义包括数据库（mysql、redis等）、qbus（360web平台部自研的消息队列）、qconf（360web平台部自研的分布式配置管理）、定义的常量数据、第三方调用使用参数等，尽量避免这些项的硬编码；如果开发把这些项直接写在代码中，测试环境与线上环境使用地址或者参数不同，你怎么办？
另外一个很重要，但是被很多人忽略的点：日志；一定要知道项目日志在哪里，项目是如何输出日志的，日志的分类（DEBUG/ERROR等），这非常有助于你快速了解功能实现，并且帮助你进行bug定位；我的习惯是，如果有bug我会看下日志，如果通过现有日志就可以定位问题，那最好不过；如果不能通过现有的日志数据直接定位问题，我会通过在代码中多输出一些日志信息帮助我定位bug（现在测试的PHP项目无需编译，我可以直接在测试服务器上这么干，如果是java或GO这种需要编译的，那你就让开发帮忙多打点日志，反正他自己也会这么干）
对环境配置相关的把控
(三)由于篇幅原因，环境配置相关的把控下次再说，有不同想法的同学欢迎联系指正哈~
