您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 业务知识 > 正文

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

发表于:2017-01-09 作者:网络转载 来源:

  一个不会测试的产品不是好开发
  在初创公司,大部分都没有专门的QA(质量保证)人员,此时测试的活儿基本上就是产品做了。
  实际上这活儿也挺适合产品做的,毕竟没有谁能比写PRD的那个人更了解产品细节了。
  这半个月经历了两次较大的网站架构更新。时间紧,资源少,没时间系统的搞沙盘测试,依然像往常一样,全员大帮哄,做了一夜黑盒就完事儿了。
  结果上线之后各种Bug,用户反馈压爆客服。还好技术团队比较牛掰,严重的缺陷当天基本都解决掉,才没造成过大的损失。
  之前一直没系统的去思考过测试方面的事情,亲身经历才感觉到后果的严重性。
  于是重新看了下项目管理的书,找了些测试方面的文章,在这儿小结一下分享,希望大家在留言一起多交流碰撞。
  先聊聊项目管理:
  从项目管理的角度,测试严格来说属于项目质量管理中的质量计划,质量保证,质量控制三个环节中的最后一环,是验收整个项目质量的关键环节。
  而现在的创业团队大都是敏捷型开发团队,也就是一些文章里经常说的“小作坊”~没有繁重的工作流程和复杂的层级关系,沟通和执行的效率都很高。
  所以传统的项目管理理论中大部分是不适用于初创阶段的,这时候就得结合自身情况,用合适的方法具体分析了。
  就测试而言,系统的软件测试方法非常多,单元测试,集成测试,系统测试,α测试,β测试,回归测试,模糊测试等等......
  最常见的三种是:
  黑盒测试——不考虑程序的内部结构,直接在程序接口上进行测试。通俗的讲就是把产品拿过来直接用找Bug。
  白盒测试——把测试的对象看成一个透明的盒子,对程序的所有逻辑路径进行测试。常用的有语句覆盖,条件覆盖,判断覆盖,条件组合覆盖,路径覆盖这几种。(这个都是开发的活儿,产品们了解下就好
  沙盘测试——模拟用户在实际环境中的测试,也就是把一个个用户场景都走通一遍。这样就把粒度较大,也十分重要的逻辑漏洞过滤掉了。
  而实际操作中,测试要如何规划呢?
  下面分别再从8个维度重新归纳一下。
  首先,测试人员的核心能力在于提出具有价值的问题。这需要结合技术和产品的角度来思考。
  了解已有信息
  测试开始之前,我们要先知道从哪开始测试:
  目前已经有哪些可供参考的信息:产品规格?需求文档?用户文档?已有的Bug记录等等。(理想情况下,测试人员应该掌握产品应有的所有细节资料。然而事实上这些文档很有限,多问多积累吧…)
  产品支持在什么系统、平台和设备上运行?
  产品都处理哪些数据类型?(如聊天信息,消费信息等)
  产品有接入外部产品吗?(如其它API或数据)
  多少时间用来测试?
  测试的优先级如何排列?
  测试的风险如何判断?
  发布和更新的流程如何?
  基本上,了解好上面的信息就可以开始制定相应的测试计划了。在时间允许的情况下,一定要记得:(这次就是没写吃了大亏)
  写测试用例!
  写测试用例!
  写测试用例!
  从用户场景测试:
  自己做的产品,我们一定有自己的理解,而用户实际上是如何使用的?在什么样的情景下使用?都是我们需要慢慢的通过与用户的交流,产品的数据积累,用户研究得来的,测试的时候当然也不能漏掉。
  用户的使用经验:
  毫无经验
  有些经验
  很有经验
  技术狂
  竞争对手
  黑客
  ……
  当然,角色要多少有多少,具体看我们产品有什么需要了。
  用户的操作行为:
  在不该返回的时候返回
  不耐心多次点击按钮
  输入错误数据
  不理解如何使用
  没按照产品规则进行设置
  随便乱点
  ……
  意料之外的Bug常常就会在这里出现,不过一般都是小Bug,但更深入的想想,其实会有更多产品本身的问题。
        产品性能问题:
  开发时是否完全按照产品设计交付?
  是否按照计划完成了既定要开发的功能?
  超负荷使用的情况下,产品状况会怎么样?加载速度会变慢吗?会崩溃闪退吗?出错有给用户反馈吗?
  闪退后数据是否会丢失?
  用户数据的安全如何?
  运行过程中程序中断会发生什么情况?
  是否需要调用的硬件服务?(如GPS,Wifi)打开会如何?没打开会如何?
  用户是否按照既定的产品路径完成了我们期望的引导?
  跳转到网页,浏览器,或其它App时会出现Bug吗?
  是否整合了第三方登陆?(如QQ、微信登陆)
  用户反馈是都符合我们的产品定位?
  ……
  从数据发现问题:
  数据对于产品的意义咱们就不多提了,往往经得住考验的功能点都是基于数据做出的。
  然而,数据多了也同样愁人,不管是用户还是我们自己开发,数据一多,出现错误的概率也随之增加。
  跨平台的数据同步问题
  数据存储的极限
  数据被移除时会发生的情况
  删除App或卸载软件时,数据如何处理?
  删除并重新安装时,数据如何处理?
  是否会因过多或过少的数据需求导致布局和UI的改变?
  在不同时段和时区时使用会如何?
  数据同步时被打断
  数据或网站数据架构更新时会造成的影响
  如何快速处理大量数据?
  无效的数据如何处理?
  根据不同的用户类型和用户场景,出现极限数据时的测试也不可忽视
  测试用户可输入的极限值
  用重复数据反复测试
  在无任何数据的手机上测试
  在老旧手机上测试
  预装多种不同类型的数据
  使用超出预期的数据测试,看程序如何处理
  分析数据是如何影响UE的
  写一些小的脚本让测试自动化也是非常高效的~
  出错时的提醒和消息
  这时就完全从用户和测试者本身的角度来思考问题了,错误提醒和消息是经常出现问题的地方。
  错误提醒的UI是否易于接受?
  错误信息内容是否易于理解?
  错误信息格式是否一致?
  错误提醒有没有用?
  信息内容是否合适?
  错误是否符合惯例和标准?
  错误信息本身是否正确?
  产品是否能获得错误和崩溃信息?
  是否所有的错误都测试过?
  用户处理完错误信息后,将处于什么状态?
  是否在用户应该接受错误信息时,却没有错误信息弹出?
  错误信息的确会影响用户体验。然而,错误始终是不可避免的,就像我们永远写不出没有任何Bug的程序一样。
  虽然最理想的状态是避免用户遇见错误信息,但这几乎不可能。
  对于出错情况的设计、实现和确认很可能与预期相反,但只要测试时善于发现这些意料外的Bug,改进它们就更有头绪了。
  特定平台的注意事项
  每个平台上的技术标准和设计规范都有很大差异,考虑产品在不同平台上的限制都是至关重要的。我们可以从一下一些方面入手:
  是否遵循该平台的设计规范?
  转动设备的方向时,有什么变化?
  平台支持哪种设备?
  触摸屏在不同情况下支持何种手势,如:双击、长按、拖动、摇晃、左右滑动等
  是否需要调用GPS?
  分享或转发邮件时是否足够流畅?是否接入其它社交产品?
  用户进行多个任务,并在不同App间切换时,产品是否正常运行?
  用户进行更新或上传操作时,是否会显示进度?
  默认设置如何?是否可调整?
  网络中断或其它原因打断时的情况
  当连接断断续续或意外中断时,很多场景我们都要重新考虑:
  用户运动,走动环境下
  WiFi连接下
  无WiFi连接时
  3、4G模式下
  手机和WiFi网络切换时
  飞行模式时
  有电话打来时
  收到信息时
  收到消息提醒时
  电量过低,甚至自动关机时
  ……
  这类测试最容易发现错误和Bug。不仅是开关机,确认设备是否正常工作,尝试用户使用的整个流程也至关重要。
  测试远非对与错的判断
  以上是重新归纳后的8个维度,肯定不是面面俱到,但多少提醒我们:
  带着问题,才能发现问题
  测试往往大家被认为是完全按照逻辑的、可计划和预测的,然而只有在真正编写测试脚本,实施测试计划,在通过和失败,正确和错误的反馈中不断总结,我们才能越来越接近上线后的真实状态。