开始自动化测试

Question

我很惭愧承认,但我从来没有对我的代码进行任何自动化测试.通常我会写一个函数或方法,然后做一些手动测试并继续.我意识到这是非常糟糕的做法所以我试图改变我的方式.问题是,我对如何开始有点迷茫.我正在使用连接到数据库的Flask编写一个小的Python Web应用程序,我想用这个机会强迫自己进入更好的开发实践.

我猜我需要用一些测试数据填充我的数据库(可能只是编写脚本来生成它),然后继续为我的程序中的每个函数编写测试.

例如:我有一个函数可以从系统中提取所有用户注释.我是否必须为特定用户编写测试,然后检查以确保返回的注释ID列表与我从手动数据库查询创建的数组匹配？这个单元测试了吗？

只是很难理解这一切.甚至指向一些新的友好文档将非常感激.

Answer 1

所以,首先,我想提一下自动化测试的目的.目的不是为了发现错误,而是为了捕捉回归.它确实有时会捕获错误,但一般而言,编写和维护自动化测试套件需要做大量的工作.如果您只是想找到错误,那么手动测试要便宜得多.自动化测试的优势在于,您可以在进行实质性更改时运行套件,并且更加自信您没有打破世界.这种回归测试是编写自动化测试的关键所在.

我将描述测试方法,然后描述一般测试策略.我也只是要解释一切,如果你已经知道我所说的一半,请不要被冒犯.

话虽如此,有三个广泛的测试级别:

单元测试

单元测试是在最小规模上进行测试.它测试各个功能和/或类.有许多库可用于各种不同语言的单元测试.python的一个例子是PyUnit.

您通常通过编写大量的小范围测试来完成单元测试.例如,如果你已经编写了自己的容器类(不太可能在python中,但这是一个简单的例子),你可以进行单元测试,用于添加项目,删除项目,查找项目等.

组件测试

组件测试将您的程序作为单独组件进行测试.这通常通过创建其他组件的模拟来完成.它通常也是通过使用单元测试库来完成的,只需要进行更大的测试.如果每个类可能有10个或数百个单元测试(很大程度上取决于类的大小),那么您将对系统的每个组件进行一些组件测试.

例如,您提到了一个数据库.您可以通过编写返回固定数据的模拟数据库进行组件测试,并使用模拟测试与数据库连接的部件.单元测试更加困难,因为可测试性开始成为设计中的一个问题.如果将数据库硬编码到您的程序中,那么您将如何模拟数据库.尽管如此,它仍然相对容易,只需要一些预见和计划.

系统测试

系统测试是最难编写测试的,因为你必须有集成点来驱动你的系统.在个人项目中,您可以跳过系统测试,特别是如果您已经完成了单元和组件测试的全面工作.

系统测试涉及在整个系统上完成场景.难度大大增加,尤其是对于UI应用程序,因为您必须有一种模拟用户输入的方法.使用基于文本的系统(如编译器),您只需生成文本,但使用UI时,您必须驱动输入或将测试挂钩放入输入回调中.没有一种尺寸适合所有解决方案,就像单元测试一样.

测试建议

实际测试与我进入该行业之前的测试完全不同.当我在学校的时候,我浪费了很多时间去做非生产性的事情,当我"测试"时,我觉得这些事情很有成效.话虽如此,这是我的建议:

1. 捣蛋,并在桶中分散你的努力.查看各种方面,例如压力,性能,边界情况,常规输入,本地化,UI以及您可以为其提供的任何其他内容.然后决定什么是值得追求的,什么不是.本地化可能不会成为业余爱好项目的优先事项.
2. 不要仅仅为了测试而测试东西.在您决定编写测试之前,请确定是否值得编写.例如,如果您发现如果您输入500,000个字符串作为输入,您的网站会崩溃,那么您能解决这个问题吗？我知道我不会,除非这是一个微不足道的修复.所以测试用例不值得写.
3. 请将被测程序视为一段代码.很多人订阅黑盒子视图,你不应该对实现细节做任何假设,但我认为这是没有效果的.编写对实现有意义的测试,这对于将来的任何实现都是有意义的.这可以追溯到自动化测试的目的,不是为了发现错误,而是为了在以后捕获回归.
4. 想想边境案件.如果你正在写一个像我之前提到的容器类,你应该考虑空容器,最大尺寸的容器(或者如果有最大尺寸),带有一个元素的容器等.应该有一些正常的测试案件和边境案件的一些案件.尽管如此务实,请牢记第2点.

进一步阅读:

• PyUnit教程
• 可能是现存最好的测试书