一个不会测试的产品不是好开发
　　在初创公司，大部分都没有专门的QA（质量保证）人员，此时测试的活儿基本上是产品做了。
　　实际上这活儿也挺适合产品做的，毕竟没有谁能比写PRD的那个人更了解产品细节了。
　　这半个月经历了两次较大的网站架构更新。时间紧，资源少，没时间系统的搞沙盘测试，依然像往常一样，全员大帮哄，做了一夜黑盒完事儿了。
　　结果上线之后各种Bug，用户反馈压爆客服。还好技术团队比较牛掰，严重的缺陷当天基本都解决掉，才没造成过大的损失。
　　之前一直没系统的去思考过测试方面的事情，亲身经历才感觉到后果的严重性。
　　于是重新看了下项目管理的书，找了些测试方面的文章，在这儿小结一下分享，希望大家在留言一起多交流碰撞。
　　先聊聊项目管理：
　　从项目管理的角度，测试严格来说属于项目质量管理中的质量计划，质量保证，质量控制三个环节中的后一环，是验收整个项目质量的关键环节。
　　而现在的创业团队大都是敏捷型开发团队，也是一些文章里经常说的“小作坊”~没有繁重的工作流程和复杂的层级关系，沟通和执行的效率都很高。
　　所以传统的项目管理理论中大部分是不适用于初创阶段的，这时候得结合自身情况，用合适的方法具体分析了。
　　测试而言，系统的软件测试方法非常多，单元测试，集成测试，系统测试，α测试，β测试，回归测试，模糊测试等等......
　　常见的三种是：
　　黑盒测试——不考虑程序的内部结构，直接在程序接口上进行测试。通俗的讲是把产品拿过来直接用找Bug。
　　白盒测试——把测试的对象看成一个透明的盒子，对程序的所有逻辑路径进行测试。常用的有语句覆盖，条件覆盖，判断覆盖，条件组合覆盖，路径覆盖这几种。（这个都是开发的活儿，产品们了解下好
　　沙盘测试——模拟用户在实际环境中的测试，也是把一个个用户场景都走通一遍。这样把粒度较大，也十分重要的逻辑漏洞过滤掉了。
　　而实际操作中，测试要如何规划呢？
　　下面分别再从8个维度重新归纳一下。
　　首先，测试人员的核心能力在于提出具有价值的问题。这需要结合技术和产品的角度来思考。
　　了解已有信息
　　测试开始之前，我们要先知道从哪开始测试：
　　目前已经有哪些可供参考的信息：产品规格？需求文档？用户文档？已有的Bug记录等等。（理想情况下，测试人员应该掌握产品应有的所有细节资料。然而事实上这些文档很有限，多问多积累吧…）
　　产品支持在什么系统、平台和设备上运行？
　　产品都处理哪些数据类型？（如聊天信息，消费信息等）
　　产品有接入外部产品吗？（如其它API或数据）
　　多少时间用来测试？
　　测试的优先级如何排列？
　　测试的风险如何判断？
　　发布和更新的流程如何？
　　基本上，了解好上面的信息可以开始制定相应的测试计划了。在时间允许的情况下，一定要记得：（这次是没写吃了大亏）
　　写测试用例！
　　写测试用例！
　　写测试用例！
　　从用户场景测试：
　　自己做的产品，我们一定有自己的理解，而用户实际上是如何使用的？在什么样的情景下使用？都是我们需要慢慢的通过与用户的交流，产品的数据积累，用户研究得来的，测试的时候当然也不能漏掉。
　　用户的使用经验：
　　毫无经验
　　有些经验
　　很有经验
　　技术狂
　　竞争对手
　　黑客
　　……
　　当然，角色要多少有多少，具体看我们产品有什么需要了。
　　用户的操作行为：
　　在不该返回的时候返回
　　不耐心多次点击按钮
　　输入错误数据
　　不理解如何使用
　　没按照产品规则进行设置
　　随便乱点
　　……
　　意料之外的Bug常常会在这里出现，不过一般都是小Bug，但更深入的想想，其实会有更多产品本身的问题。