前言：目前所在的公司对于测试环节产生的 Bug 数量要求比较严格，经历了几个版本迭代之后，也逐渐有了一些经验，记录整理下来，希望能帮助到大家。
1. 需求评审环节
需求开发之前，肯定是需要进行需求评审的。这一步很关键，除了要了解本次要做的新需求之外，也需要确定对其他需求的影响范围，避免因为本次需求的开发，影响到了已经上线的其他业务需求。
另外，对于UI 的展现形式，和用户的交互方面也需要尽量细化，这一步做的越细致，后期开发起来才会更加省心，否则在开发中遇到没有确定的问题还得拉上产品、测试、RD 一起开会讨论。
2. 技术方案确定
正式开发需求之前，需要做到心中有数。先确定整体的技术方案，对于比较复杂的业务场景，最好能绘制一个流程图，简单明了，开发时不会因为头脑一时发懵导致代码出错，也算是给未来接手这块代码的小伙伴一个惊喜。
3. 开发时要扩散思维
开发时遇到的问题就很多了，因为我是移动端开发，此环节接触到的问题主要还是以数据、UI 显示问题居多。
此环节尤其要注意 Android 和 iOS 两端在数据处理和 UI 展示上的统一，做到内部一致，对外统一，要错都错。这点非常重要！！！
3.1 数据的错误
数据的错误导致的 Bug 还是挺严重的，首先是数据返回有 null 值的问题：
比如后端同学有一个String 类型的字段返回的值是 null，如果我们调用了[string length] 方法，那就会因为 NSNull 类中没有 length 方法，导致崩溃。其实这个解决方法还是挺简单的，AFN 中有对 null 值过滤的处理。
另一个是数据返回格式的问题，比如我想要个字典，后端却在某些情况下返回的是数组，这也有可能会导致崩溃。虽然这个锅是后端同学的，但是如果上线的情况下，APP 发生崩溃之后，第一责任人肯定还是移动端的同学呀。
3.2 UI 问题
我们写的 UI 多种多样，每个需求的实现效果完全是由我们开发者来决定的。如果Android、iOS、小程序、H5 在同一个页面对用户的展现形式不同的话，你猜测试会不会给你提 Bug ?
所以写 UI，最终要的一点还是上面所提到的，要保持各端统一。尽可能的在开发之前就沟通好UI 的实现效果，避免之后再返工。
其次就是需要考虑到临界值情况：
- 页面无网络、无数据的显示处理
- 返回数据为空或者数据量过大
此时就需要我们扩散思维，尽可能的把临界情况考虑周全，因为我们不确定后端的数据在线上会以一个什么样的形式提供。这就是马老师提过的假设性原则，我们开发时也假设这个数据没有，或者假设这个数据过大，通过 mock 测试数据来让我们写的代码有更好的兼容性。
4. 端内互测
提测前这一步是很重要的，主要是让各端的同学互相测试，做到在各个方面的统一！！！
5. 测试 case 自查
这一步的重要性不言而喻，测试case 不通过，就会被打回来呀，到时候再有个邮件通报，彻底出名了。
6. 总结
开发前：细化需求点，确定影响范围，产出详细的技术方案。
开发中：考虑临界情况，和各端同学多沟通，统一实现效果。
提测前：端内互测，case 自查，对自己写的代码要负责任。
如果之后还是有 Bug，那就让测试提吧！
网友评论