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

一个不会测试的产品不是好开发

在初创公司，大部分都没有专门的QA（质量保证）人员，此时测试的活儿基本上就是产品做了。

实际上这活儿也挺适合产品做的，毕竟没有谁能比写PRD的那个人更了解产品细节了。

这半个月经历了两次较大的网站架构更新。时间紧，资源少，没时间系统的搞沙盘测试，依然像往常一样，全员大帮哄，做了一夜黑盒就完事儿了。

结果上线之后各种Bug，用户反馈压爆客服。还好技术团队比较牛掰，严重的缺陷当天基本都解决掉，才没造成过大的损失。

之前一直没系统的去思考过测试方面的事情，亲身经历才感觉到后果的严重性。

于是重新看了下项目管理的书，找了些测试方面的文章，在这儿小结一下分享，希望大家在留言一起多交流碰撞。

先聊聊项目管理

从项目管理的角度，测试严格来说属于项目质量管理中的质量计划，质量保证，质量控制三个环节中的一环，是验收整个项目质量的关键环节。

而现在的创业团队大都是敏捷型开发团队，也就是一些文章里经常说的“小作坊”~没有繁重的工作流程和复杂的层级关系，沟通和执行的效率都很高。

所以传统的项目管理理论中大部分是不适用于初创阶段的，这时候就得结合自身情况，用合适的方法具体分析了。

就测试而言，系统的软件测试方法非常多，单元测试，集成测试，系统测试，α测试，β测试，回归测试，模糊测试等等......

最常见的三种是

黑盒测试——不考虑程序的内部结构，直接在程序接口上进行测试。通俗的讲就是把产品拿过来直接用找Bug。 白盒测试——把测试的对象看成一个透明的盒子，对程序的所有逻辑路径进行测试。常用的有语句覆盖，条件覆盖，判断覆盖，条件组合覆盖，路径覆盖这几种。（这个都是开发的活儿，产品们了解下就好 沙盘测试——模拟用户在实际环境中的测试，也就是把一个个用户场景都走通一遍。这样就把粒度较大，也十分重要的逻辑漏洞过滤掉了。

而实际操作中，测试要如何规划呢？

狼蚁网站SEO优化分别再从8个维度重新归纳一下。

，测试人员的核心能力在于提出具有价值的问题。这需要结合技术和产品的角度来思考。

了解已有信息

测试开始之前，我们要先知道从哪开始测试

目前已经有哪些可供参考的信息产品规格？需求文档？用户文档？已有的Bug记录等等。（理想情况下，测试人员应该掌握产品应有的所有细节资料。事实上这些文档很有限，多问多积累吧…） 产品支持在什么系统、平台和设备上运行？ 产品都处理哪些数据类型？（如聊天信息，消费信息等） 产品有接入外部产品吗？（如其它API或数据） 多少时间用来测试？ 测试的优先级如何排列？ 测试的风险如何判断？ 发布和更新的流程如何？

基本上，了解好上面的信息就可以开始制定相应的测试计划了。在时间允许的情况下，一定要记得（这次就是没写吃了大亏）

写测试用例！

写测试用例！

写测试用例！

从用户场景测试

自己做的产品，我们一定有自己的理解，而用户实际上是如何使用的？在什么样的情景下使用？都是我们需要慢慢的通过与用户的交流，产品的数据积累，用户研究得来的，测试的时候也不能漏掉。

用户的使用经验

毫无经验 有些经验 很有经验 技术狂 竞争对手 黑客

……

，角色要多少有多少，具体看我们产品有什么需要了。

用户的操作行为

在不该返回的时候返回 不耐心多次点击按钮 输入错误数据 不理解如何使用 没按照产品规则进行设置 随便乱点

……

意料之外的Bug常常就会在这里出现，不过一般都是小Bug，但更深入的想想，其实会有更多产品本身的问题。

产品性能问题

开发时是否完全按照产品设计交付？ 是否按照计划完成了既定要开发的功能？ 超负荷使用的情况下，产品状况会怎么样？加载速度会变慢吗？会崩溃闪退吗？出错有给用户反馈吗？ 闪退后数据是否会丢失？ 用户数据的安全如何？ 运行过程中程序中断会发生什么情况？ 是否需要调用的硬件服务？（如GPS，Wifi）打开会如何？没打开会如何？ 用户是否按照既定的产品路径完成了我们期望的引导？ 跳转到网页，浏览器，或其它App时会出现Bug吗？ 是否整合了第三方登陆？（如狼蚁营销、狼蚁网络推广登陆） 用户反馈是都符合我们的产品定位？

……

从数据发现问题

数据对于产品的意义咱们就不多提了，往往经得住考验的功能点都是基于数据做出的。

，数据多了也同样愁人，不管是用户还是我们自己开发，数据一多，出现错误的概率也随之增加。

跨平台的数据同步问题 数据存储的极限 数据被移除时会发生的情况 删除App或卸载软件时，数据如何处理？ 删除并重新安装时，数据如何处理？ 是否会因过多或过少的数据需求导致布局和UI的改变？ 在不段和时区时使用会如何？ 数据同步时被打断 数据或网站数据架构更新时会造成的影响 如何快速处理大量数据？ 无效的数据如何处理？

根据不同的用户类型和用户场景，出现极限数据时的测试也不可忽视

测试用户可输入的极限值 用重复数据反复测试 在无任何数据的手机上测试 在老旧手机上测试 预装多种不同类型的数据 使用超出预期的数据测试，看程序如何处理 分析数据是如何影响UE的

写一些小的脚本让测试自动化也是非常高效的~

出错时的提醒和消息

这时就完全从用户和测试者本身的角度来思考问题了，错误提醒和消息是经常出现问题的地方。

错误提醒的UI是否易于接受？ 错误信息内容是否易于理解？ 错误信息格式是否一致？ 错误提醒有没有用？ 信息内容是否合适？ 错误是否符合惯例和标准？ 错误信息本身是否正确？ 产品是否能获得错误和崩溃信息？ 是否所有的错误都测试过？ 用户处理完错误信息后，将处于什么状态？ 是否在用户应该接受错误信息时，却没有错误信息弹出？

错误信息的确会影响用户体验。，错误始终是不可避免的，就像我们永远写不出没有任何Bug的程序一样。

虽然最理想的状态是避免用户遇见错误信息，但这几乎不可能。

对于出错情况的设计、实现和确认很可能与预期相反，但只要测试时善于发现这些意料外的Bug，改进它们就更有头绪了。

特定平台的注意事项