干货 ｜ 产品测试规划必看的8个维度.pdf

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