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

在初创公司，大部分都没有专门的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个维度，肯定不是面面俱到，但多少提醒我们：

带着问题，才能发现问题

测试往往大家被认为是完全按照逻辑的、可计划和预测的，然而只有在真正编写测试脚本，实施测试计划，在通过和失败，正确和错误的反馈中不断总结，我们才能越来越接近上线后的真实状态。

Stay hungry，stay foolish