python调试程序BUG的心得技巧分享

【导读】相信各位Python工程师们在写Python代码的时候，免不了经常会出现bug满天飞这种情况，这个时候我们可能就得一个标点一个标点的去排查，费时又费力，但是，我们又很难发现到底是其中的哪一个步骤，导致了这些问题的出现。导致这些问题的其中一个原因，就是我们没有养成良好的编程习惯。编程习惯就好比是电影中的特效。电影特效越好，呈现出来的观影效果也自然越好。同样，如果我们能够养成好的编程习惯，在查找错误的时候，自己的思路就会更加清晰。下面是小编整理的解决Python项目bug的心得技巧分享，包含六小点，希望对大家有所帮助。

方法一：使用项目管理工具

无论Python项目简单与否，我们都应该使用Git进行版本控制。大部分支持Python的IDE(集成开发环境)都内置了对Git这一类项目管理工具的支持。

我们在修改代码时，常常会出现改着改着程序就崩了的情况，改出的最新版本有时候还不如上一个版本。而Git，恰好能够及时帮我们保存之前的版本。使用了它以后，我们也不需要不停地用“ctrl+z”来撤回代码了。

方法二：使用Python的内置函数

Python的内置函数和标准库都可以处理常见的用例，而不需要自己重新定义函数。

但是，刚刚入门的Python开发人员们对其中的函数并不熟悉。所以他们经常会遇到这样一个问题——在不需要记住内容的情况下，如何才能知道标准库中的内容是否涵盖了自己的用例?最简单的方法是将标准库索引和内置函数概述页添加为书签，并且在遇到“日常编程”类问题的时候立即浏览一下。我们使用这些函数的频率高了，自然也就能记住这些函数了。

方法三：使用正确的模块

与内置函数和标准库一样，Python中大量的第三方模块集合，也可以帮助我们节省大量的人力。通过PyPI的Web前端，可以针对我们的问题触发搜索词，我们很容易就能找到适合自己的解决方案。

方法四：使用OOP

面向对象编程(OOP)将数据结构与用于 *** 作它们的方法捆绑在一起，从而使编写高级代码更加容易。OOP非常适合用于Python这一类高级语言，尤其是项目非常复杂的时候。熟悉Python的开发人员都知道，使用OOP可以减少代码量，从而节省大量的时间。

但是，也不是所有的项目都需要使用OOP。如果项目没有特别要求，一些小型的项目就可以不用OOP。

方法五：编写测试代码并不断测试

一个好的程序员一定知道测试之于项目的重要性。编写测试代码的确是一个很枯燥的过程，但是不进行测试，我们就无法发现程序的问题所在。

如果一个项目非常复杂的话，我们就必须要做到及时测试。越早测试，就能越早发现问题。而不是说等代码全部写完了，才开始进行测试，这样反而会导致更多的错误和更大的工作量。

当然，我们也可以寻找专业的软件测试人员，来帮助我们进行测试。这样我们也可以把更多的精力投入到项目程序本身。

方法六：选择正确的Python版本

部分人仍然在使用Python2，但Python官方的开发团队早已经不对这一版本进行维护了。聪明的开发人员都已经将Python2里的项目迁移到Python3中了。

Python目前的最新版本是Python3.8.5，但也不是说你一定要使用最新版本。专业的软件开发人员都知道，任何软件的最新版本都不一定是最好的，因为它仍需要开发团队不断地去改良。程序员一般都会使用在最新版本之前的一个版本，旧版本相对而言是比较成熟的。

无论是运用哪一种语言编写代码，优秀的程序员都具备良好的编程习惯。这些习惯不仅能够让我们思路更加清晰，也可以帮助我们减轻工作量，从而节省大量的时间。所以，可能你离优秀的程序员，只差一个好习惯了哦~

以上就是小编今天给大家整理发送的关于“解决Python项目BUG的心得技巧分享”的相关内容，希望对大家有所帮助。小编认为要想在大数据行业有所建树，需要考取部分含金量高的数据分析师证书，这样更有核心竞争力与竞争资本。

测试向开发反馈软件存在的问题，一般是以bug表的形式进行，不可否认，每一位开发人员手头都有很多代码，所以开发人员希望收到错误信息定位明确的bug表，而不是诸如“软件不好用”这样的无用信息。同样，作为测试人员，我们的工作也是尽量的定位问题，向技术支持方向靠拢。

一份拙劣的bug报告也许是:

在报告中说“不好用”

所报告内容毫无意义

在报告中用户没有提供足够的信息

在报告中提供了错误信息

所报告的问题是由于用户的过失而产生的

所报告的问题是由于其他程序的错误而产生的

所报告的问题是由于网络错误而产生的

所报告的问题是由于相应的环境没有配置好而产生的。

报告Bug的目的是为了让开发人员看到程序的错误，当然您可以亲自给开发人员示范，当面交流，也可以在bug中给出导致程序出错的、详尽的 *** 作步骤。这里我建议尽量用bug管理工具提出，这样做回归测试的时候，就能够有迹可循有据可依，同时也能够规范bug管理的过程。

在一个bug表中，我们希望能够包含尽量完整的信息:

1、提供测试环境及版本信息，最好包括软硬件，也许您遇到的问题并不是软件本身的问题，而是测试环境配置的问题，是开发人员在自测的时候用的环境与您使用的环境不同导致的，所以，请给他们提供详尽的信息，帮助他们定位问题所在。

2、提供能让问题重现的详尽的 *** 作步骤，最好附上 *** 作截图，让开发人员知道问题是怎么产生的，您的 *** 作与他们的 *** 作有什么不一样。

软件测试工作流程：

1、需求分析、需求评审需求分析和评审就是分析客户的需求可不可行，需要怎么进行测试。

2、编写测试计划编写测试计划通俗一点讲就是什么人在什么时间做什么事，最后产出什么东西。那也就是测试人员要测试哪些模块、在什么期限内，提交哪些文档。

3、编写测试用例、用例评审测试用例就是指导测试的文档，比如我们要测试商城登录、买东西等功能，通过测试方法和策略设计测试用例。评审就是评价审查，不能想当然该怎么测。不能只是输入正确的用户名和密码，能登录进去就完事了。

作为软测工程师需要有破坏性，比如密码输错时怎么办，会不会有相应的报错等等。

4、执行测试、提交bug、回归测试Bug就是缺陷，发现bug之后，要提交给开发人员让他们去修改，然后进行回归测试，验证开发人员有没有改好。

5、编写测试总结报告Bug都改好了之后，要编写测试总结报告，这款软件的质量如何。

Bug的标题和详细描述:

标题主要是对你所提交的Bug进行简明扼要的描述；

详细描述是对Bug进行进一步详细的描述，例如在什么情况下发生等；也可以直接将标题作为描述部分。

两者都是为了让查看Bug的人员很清楚的知道你所表达的意思。

Bug测试环境：

在什么环境中发现的这个bug，例如：什么系统，哪个版本等。对于bug环境的描述可以通过简单的罗列即可（精简为主）

扩展资料：

软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。

对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。

参考资料：百度百科-软件测试

---