zoukankan      html  css  js  c++  java
  • 自动化测试

    • 什么是自动化测试?

    1. 把自己手动执行过程中的一些重复的流程操作抽象出来,固化成框架,让自动化代码沿着固定的路线执行。
    2. 除了固化的框架,还有些用例需要特殊的配置,即支持用例的个性化定制,在创建任务时带入需要操作的参数,去调用对应的已编写好的python方法,即可实现用例的前置条件环境配置,即用例中的前置条件准备。
    3. 每次执行都会恢复环境,不干扰下一个用例的执行。
    • 持续集成CI(Continuous Integration)

    1. 理解:在编码过程中,要不断的提交代码,提交后可以通过构建、测试等方式对代码进行验证,从而可以尽早的发现问题。其实,持续集成不仅仅是-编码,还可以应用于更多的范围,如文档的编写等等。
    2. 扩展:持续集成可以理解成一种工作方式。多人共同完成工作,每个人不断阶段性的提交工作成果,阶段性成果被不断的验证,这样可以尽早的在验证阶段,发现工作中的问题。
    3. 每个阶段性成果,可以理解为一个‘版本’。代码可以版本化,那么扩展下就成了-一切可版本化。
    4. 敏捷与集成:敏捷与集成是分不开的内容,敏捷如果要能够有效的进行,必然不能缺少持续集成。

    为什么自动化无法满足持续集成的需求:

    • 稳定性
    1. 自动化的质量欠佳,在没有bug的情况下,很难达到100%的成功率
    2. 在异常处理方面不足
    3. 所依赖的外界环境的不稳定,增加了自动化的不稳定性
    4. 与其他测试共享资源增加资源冲突概率
    5. 自动化没有分支功能,针对新版本修改后,无法继续运行老版本
    • 快速验证
    1. 测试内容本身耗时
    2. 依赖外部环境,而外部环境未自动化
    3. 测试技术手段不足导致测试方式耗时
    4. 功能可测试性不好导致测试难度大
    5. 为屏蔽不稳定因素,简单的sleep
    6. 自动化不稳定导致执行结果的分析时间长
    7. 无法并发测试
    • 为什么无法做到并发测试?
    1. 被测试环境有限
    2. 测试用例无法并发
    3. 测试用例的相关名称固定,导致并发测试会冲突
    4. 执行引擎无法并发/分布式测试
    • 规范:

    1. 新增编写的测试用例提交标准:需要在自己的分支将整体用例连续跑5遍,且5遍的成功率均为100%。
    2. 整体用例执行必须在30min内完成(不包含被测试环境部署的时间)
    3. bug阻塞持续集成的必须1天内解决
    4. 持续集成中自动化的成功率在95%以上,才算通过,才能给其他人升级。
    5. 如果一定要sleep,而无条件检查的timeout机制,必须要在代码中备注Note(xxx),并写明为什么无法条件检查
    • coding_guide

    • 对于测试数据/配置:

    1. -假定没有现在的测试数据
    2. -测试用例是独立的(自己准备测试数据)
    3. -每个测试结束后,需要清理测试数据
    4. -随着环境变化而变化的值应该在配置文件中配置
    • 异常处理:

    1. -每个测试用例中,需要通过异常或者日志来详细的说明异常情况
    2. -通常情况下,第一个错误是最重要的信息
    3. -在测试用例中,尽量避免使用try/except以及finally,这样当额外的操作导致了其他异常时会导致原有的异常被替换
    4. -在测试用例中,直接让异常抛出就可以了。总的来说,这样是一种好的解决办法
    5. -尽量避免使用会掩盖原始数据的异常处理结构,如果确实需要使用try,至少需要保证原有的异常被记录在日志里。当异常被记录了,通常需要raise一个相同的或者不同的异常
    6. -使用unittest框架提供的self.assert方法,从而可以尽早的显示失败
    7. -避免单独使用 `self.fail`,因为它的堆栈会将`self.fail`那一行作为原始错误。
    8. -在断言时避免使用复杂的布尔表达式。
    9. 没有`msg`参数的`self.assertTrue`或者`self.assertFalse`只会说明布尔值是多少,并不会知道表达式的值代表什么,`msg`参数可以包含更多的信息。
    10. -大部分断言方法可以默认包含额外信息。例如,`self.assertIn`可以包含整个集合。
    • 测试用例是独立的

    1. 每个test_method必须是可以独立调用,不能依赖于其他的test_method或者依赖于test_method的顺序
    2. 测试用例可以依赖于公共的资源初始化、工具,比如测试资源等等。如果仅选择一个test_method,这些工具也必须能够正常
    • 反面测试

    1. 新增加的negative test应该使用negative test框架。
    2. jsonschema中定义了请求的属性。测试类必须自动生成不符合给定的接口描述的测试场景。
    3. 所有的反面测试应该增加在一个单独的反面测试文件中。如果被测试的特定资源的文件不存在,那么应该增加1个新的测试文件。
    • 对于自动化测试

    • 环境相关:

    1. 不能依赖外部环境、第三方环境,例如icsci服务器、ftp服务器等。此类用例不进行自动化实现
    • 测试点/内容:

    1. 单个测试用例的测试点必须单一,并且执行完成后清理环境
  • 相关阅读:
    flex布局兼容写法
    Mastering-Spark-SQL学习笔记02 SparkSession
    Mastering-Spark-SQL学习笔记01 SparkSQL
    HBase1.2官方文档——Apache HBase Performance Tuning
    HBase1.2官方文档——Apache HBase Coprocessors
    HBase1.2官方文档——Architecture
    HBase1.2官方文档——HBase and MapReduce
    HBase1.2官方文档——RegionServer Sizing Rules of Thumb
    HBase1.2官方文档——ACID
    HBase1.2官方文档——HBase and Schema Design
  • 原文地址:https://www.cnblogs.com/sunshine-blog/p/9518254.html
Copyright © 2011-2022 走看看