一.背景介绍
在日常中，我们码代码都是按照需求来的，为了验证我们的工作成果是否符合项目的需求，那么验证程序是否完成、测试以及修复bug就成了我们工作中非常重要的流程。
二.知识剖析
什么样的程序是完成的程序
- 从需求的角度看：满足用户的全部需求
- 从程序的角度看：代码不存在明显bug，结构明晰，逻辑通顺，有一定的优化
- 从UI图的角度看：较为完美的还原了UI图的设计
- 从后期版本维护迭代的角度看：注释完备，稳定性好，不加班的代码就是好代码
软件测试的方法
测试：测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。
- 按照测试范围，可以分为模块测试和整体联调
- 按照测试条件，可以分为正常操作情况测试和异常情况测试
- 按照测试的输入范围，可以分为全覆盖测试和抽样测试
-
按照测试方式
模块测试：针对设计中的一个一个模块来进行测试的，目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又被称为单元测试。在这个测试步骤中所发现的往往是编码和详细设计的错误。 整体联调：测试模块间接口的正确性、各模块间的数据流和控制流是否按照设计实现其功能、以及集成后整体功能的正确性。 正常操作情况测试：根据正确的操作流程对单独的模块或整体进行测试，确定被测对象可以良好运行 异常情况测试：异常情况，可能会包括数据库异常，系统异常，用户异常操作等情况
一些测试的概念
成熟性：软件产品要避免由软件中错误而导致失效的能力
容错性：在软件失效或者违反规定的接口的情况下，软件产品维持规定的性能级别的能力
易恢复性：在发生故障的情况下，软件重建规定的性能级别并恢复受直接影响的数据的能力
可靠性依从性：软件产品依附于同可靠性相关的标准、约定或规定的能力
全覆盖测试：对于被测对象全面，整体，多维度的测试，受限于时间和人力成本，除非被测对象级别很高，不然不会采用这种测试方式
抽样测试：针对功能及模块随机抽取被测对象
三.常见问题
如何debug？
四.解决方案
知乎上的回答：
- 确认Bug是否在本地可以重现。
- 确认Bug在哪一段代码中。
- 去除掉所有无关代码，只去调试和Bug相关的代码。
- 和之前正常运行的版本对比，尝试恢复到之前可以正常运行的代码。
- 重新写一个小Demo，确认是否可以正常运行，可以的话，移动代码到原有的代码中。
- 如果本地无法重现，打日志，观察线上行为。
- 重启服务，重启IDE，重启笔记本，重启服务器。
- 跟产品经理说这个Bug解决不了，花费的代价很大，不值得。
知乎上的回答：
解决问题的流程：了解问题→定位问题→分析问题→解决问题→验证问题
解决问题的方法(排名分先后)
- 借助搜索引擎：遇到有明显的异常信息，且自己并不熟悉为什么异常时，最高效的解决方法是借助搜索引擎，这里的搜索引擎一定是谷歌，不是百度；借助搜索引擎能解决工作中的大部分bug，你要相信，全世界这么多开发人员，你遇到过的大多数问题其他人也遇到过；
- 打印调试法：这是最笨但最有效的办法，人会说谎、断点调试可能会说谎，但日志一定不会说谎；
- 二分排除法：当你遇到随机问题、帮助他人解bug或者遇到自己不熟悉的代码时，通过屏蔽一部分代码，运行观察问题仍然存在，如果存在则进一步分析屏蔽一部分代码，直到定位到有问题的具体位置为止，这种方法能解决工作中的很大一部分疑难杂症；
- 小黄鸭调试法：当你向某个对象陈述你的思路时，往往会有意想不到的结果，哪怕对方并不是一个生物；
- 断点调试法：受限于效率不高以及在多线程环境下断点调试并不灵，有必要时才考虑用这种方法；通常可以使用打印调试法来代替；
- 线上求助：包括论坛提问、RTX和微信群提问等；不到万不得已不要用这种办法，在有限的圈子里面，你遇到的一个具体技术问题很有可能其他人并没有遇到过，多数时候问了也是白问，但有时候也可能是一种有效的方法。
五.编码实战
六.拓展思考
什么是小黄鸭调试法?
小黄鸭调试法，又称橡皮鸭调试法、黄鸭除虫法（Rubber Duck Debugging）是可在软件工程中使用的一种调试代码的方法。方法就是在程序的调试、除错或测试过程中，操作人耐心地向小黄鸭解释每一行程序的作用，以此来激发灵感与发现矛盾。
此概念是参照于一个故事。故事中程序大师随身携带一只小黄鸭，在调试代码的时候会在桌上放上这只小黄鸭，然后详细地向鸭子解释每行代码。许多程序员都有向别人提问及解释编程问题的经历，而目标甚至可能是完全不懂编程的人。而就在解释的过程中，程序员可能就发觉了问题的解决方案。一边阐述代码的意图，一边观察它实际上的意图并做调试，两者间的任何不协调都会变得更明显，使人更容易发现错误所在。如果没有玩具小鸭，操作人也可以向其他任何东西倾诉，比如桌上的盆栽、键盘/鼠标等。
七.参考资料
软件开发流程
如何提高测试覆盖率
测试分析中对异常情况考虑
软件异常测试
断点调试
老程序员解bug有那些通用套路？
八.更多讨论
bug的优先级有哪几种？
- critical(危险的)：是说项目中某一块功能因为这个bug而导致测试无法进行下去，此critical级别，该等级问题出现在不影响其他功能测试的情况下可以继续该版本试block是说项目中有闪退情况，崩溃情况。此为block级别，出现这种级别的问题此本停止测试
- major(重要的)：是说一些功能没有实现，但是不影响使用，功能菜单缺失，但不会影响系统稳定。此为major，这种问题应该合理安排时间进行修改
- normal(普通的)：是说界面等UI问题显示错误，比如字体大小，颜色，间距等问题。此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
- minor(次要的)：是说界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
日志和断点的优劣？
对于少量数据的检测，断点操作比较麻烦，日志很直接。但是对于比较复杂的代码，打断点能更好的理清逻辑和检查数据。
如何避免写出bug？
改动代码时要考虑到对其他模块的影响；思考问题要全面，考虑到可能发生的各种情况；从其他地方找到的代码要弄清楚原理，了解这个知识点，再用到自己的项目中。
