- 把自己手动执行过程中的一些重复的流程操作抽象出来,固化成框架,让自动化代码沿着固定的路线执行。
- 除了固化的框架,还有些用例需要特殊的配置,即支持用例的个性化定制,在创建任务时带入需要操作的参数,去调用对应的已编写好的python方法,即可实现用例的前置条件环境配置,即用例中的前置条件准备。
- 每次执行都会恢复环境,不干扰下一个用例的执行。
-
持续集成CI(Continuous Integration)
- 理解:在编码过程中,要不断的提交代码,提交后可以通过构建、测试等方式对代码进行验证,从而可以尽早的发现问题。其实,持续集成不仅仅是-编码,还可以应用于更多的范围,如文档的编写等等。
- 扩展:持续集成可以理解成一种工作方式。多人共同完成工作,每个人不断阶段性的提交工作成果,阶段性成果被不断的验证,这样可以尽早的在验证阶段,发现工作中的问题。
- 每个阶段性成果,可以理解为一个‘版本’。代码可以版本化,那么扩展下就成了-一切可版本化。
- 敏捷与集成:敏捷与集成是分不开的内容,敏捷如果要能够有效的进行,必然不能缺少持续集成。
为什么自动化无法满足持续集成的需求:
- 自动化的质量欠佳,在没有bug的情况下,很难达到100%的成功率
- 在异常处理方面不足
- 所依赖的外界环境的不稳定,增加了自动化的不稳定性
- 与其他测试共享资源增加资源冲突概率
- 自动化没有分支功能,针对新版本修改后,无法继续运行老版本
- 测试内容本身耗时
- 依赖外部环境,而外部环境未自动化
- 测试技术手段不足导致测试方式耗时
- 功能可测试性不好导致测试难度大
- 为屏蔽不稳定因素,简单的sleep
- 自动化不稳定导致执行结果的分析时间长
- 无法并发测试
- 被测试环境有限
- 测试用例无法并发
- 测试用例的相关名称固定,导致并发测试会冲突
- 执行引擎无法并发/分布式测试
- 新增编写的测试用例提交标准:需要在自己的分支将整体用例连续跑5遍,且5遍的成功率均为100%。
- 整体用例执行必须在30min内完成(不包含被测试环境部署的时间)
- bug阻塞持续集成的必须1天内解决
- 持续集成中自动化的成功率在95%以上,才算通过,才能给其他人升级。
- 如果一定要sleep,而无条件检查的timeout机制,必须要在代码中备注Note(xxx),并写明为什么无法条件检查
- -假定没有现在的测试数据
- -测试用例是独立的(自己准备测试数据)
- -每个测试结束后,需要清理测试数据
- -随着环境变化而变化的值应该在配置文件中配置
- -每个测试用例中,需要通过异常或者日志来详细的说明异常情况
- -通常情况下,第一个错误是最重要的信息
- -在测试用例中,尽量避免使用try/except以及finally,这样当额外的操作导致了其他异常时会导致原有的异常被替换
- -在测试用例中,直接让异常抛出就可以了。总的来说,这样是一种好的解决办法
- -尽量避免使用会掩盖原始数据的异常处理结构,如果确实需要使用try,至少需要保证原有的异常被记录在日志里。当异常被记录了,通常需要raise一个相同的或者不同的异常
- -使用unittest框架提供的self.assert方法,从而可以尽早的显示失败
- -避免单独使用 `self.fail`,因为它的堆栈会将`self.fail`那一行作为原始错误。
- -在断言时避免使用复杂的布尔表达式。
- 没有`msg`参数的`self.assertTrue`或者`self.assertFalse`只会说明布尔值是多少,并不会知道表达式的值代表什么,`msg`参数可以包含更多的信息。
- -大部分断言方法可以默认包含额外信息。例如,`self.assertIn`可以包含整个集合。
- 每个test_method必须是可以独立调用,不能依赖于其他的test_method或者依赖于test_method的顺序
- 测试用例可以依赖于公共的资源初始化、工具,比如测试资源等等。如果仅选择一个test_method,这些工具也必须能够正常
- 新增加的negative test应该使用negative test框架。
- jsonschema中定义了请求的属性。测试类必须自动生成不符合给定的接口描述的测试场景。
- 所有的反面测试应该增加在一个单独的反面测试文件中。如果被测试的特定资源的文件不存在,那么应该增加1个新的测试文件。
- 不能依赖外部环境、第三方环境,例如icsci服务器、ftp服务器等。此类用例不进行自动化实现
- 单个测试用例的测试点必须单一,并且执行完成后清理环境
posted @
2018-08-22 15:58
小嘉欣
阅读(
193)
评论()
编辑
收藏
举报