首页 > 技术文章 > 测试:测试理论

han0911 2020-11-20 16:49 原文

1、测试的定义:

    在软件中存在的BUG

2、出现BUG的地方以及找到BUG的方式有:

    ① 肉眼看到——界面、UI

    ② 系统资源使用率——  CPU内存、网络、电量······

    ③ 服务器端

    ④访问的方式/数据库的查询

    ······

3、判定BUG的依据

    ① 需求文档——原型图

    ② 不相符的错误类型

    ③ 难以理解,不易使用,运行缓慢

4、BUG出现的原因

    20%来源于代码

    80%需求不明确,产品需求经常变更

5、产生BUG的原因归纳

    ① 需求解释有误

    ② 用户需求定义错误

    ③ 需求记录错误

    ④ 设计说明有误

    ⑤ 编码说明有误

    ⑥ 程序代码有误

    ⑦ 数据输入有误

    ⑧ 测试错误

    ⑨ 问题修改不正确

6、测试流程:*****(面试题)

    我们一般在项目进行开立项会【产品经理 项目经理 开发人员 测试人员】的时候进行参与,讨论需求并提出建议,在立项会中制定需求文档,由 UI 设计原型图,开发根据需求文档进行编码,我们测试会根据需求文档进行编写测试计划,根据模块的(颗粒度)划分并编写测试用例的评审,开发结束后测试对主要功能进行冒烟测试,执行测试用例,提交 BUG 开发进行修改,修改成功后,关闭 BUG ,进行回归测试,在上线前进行测试总结。

    《需求文档》/《规格说明书》

    《测试计划》——  一般由测试组长或测试经理编写(参与)

    《测试用例》——  根据模块划分 / 根据测试功能 / 性能 / 自动化划分

    用例评审会:

        A:组内评审:【测试人员、测试组长 / 项目经理、产品经理】

        B:组外评审:【测试人员、测试组长 / 项目经理、产品经理 / 客户】

    冒烟测试:

      对软件的主要功能进行测试

    回归测试:

      开发人员修改过后在此测试

    测试总结:

      一般由测试组长或者测试经理编写(参与)

    日常工作:(其中几个,并不是所有)

      ① 参与需求讨论,制定测试计划,确保测试能顺利完成

      ② 负责项目的功能性测试,用户体验测试,兼容性以及性能测试

      ③ 负责测试用例的编写:编写测试报告和对测试结果分析

      ④ 与开发人员、产品经理沟通和协作,推动整个项目顺利进行

      ⑤ 负责软件开发团队项目进度管理工作

      ⑥ 熟悉 Linux 常用命令,熟悉常用数据库,熟练使用基本的 SQL 语句

      ⑦ 熟练使用 Loadrunner , Jmeter 等至少一种性能测试工具

      ⑧ 熟练掌握 Java / Python / sheel 等编程语言的一种

      ⑨ 熟练使用 Python + selenium / appnium ,pytest , untest , innerlttml

      ⑩ 持续性能监控

    测试环境的搭建:

      windos

      Linux:tomcat , jdk , MySQL , 禅道,jenkins ······

7、测试分类:按阶段分、代码是否执行、运行程序划分、其他

  阶段划分:

    单元测试:单个功能的测试(增删改查、分页、上传、下载)

    集成测试:功能模块的测试(多个功能点进行总结在一起)

    系统测试:多个模块合成测试(整个软件的整体测试)

    验收测试:客户以及产品经理进行(交付前的测试)

  程序是否执行:

    静态测试: UI 界面,业务逻辑

    动态测试:连接数据之后

  代码是否执行:

    黑:纯功能测试(手动测试,点点点)

      功能测试:

        安装 / 卸载测试

        界面测试

        易用测试

        兼容性测试

        逻辑功能测试

      性能测试:

        稳定性能测试,monkey命令

        压力测试

        负载测试

        一般性能测试,系统资源使用率

    白:使用编辑脚本进行测试,实现自动化

    灰:介于黑和白之间

  其他测试:

    冒烟测试

    回归测试

    随机测试

    暴力测试

8、测试原则:(笔试题)

    ① 应当把 “ 尽早和不断的测试 ” 作为开发者的座右铭

    ② 设计测试用例时,应该考虑到合法的输入和不合法的输入,以及各自边界条件,特殊情况下要制造极端状态和意外状态,比如网络异常中断,电源断电等情况

    ③ 一定要注意测试中的错误集中发生现象,这和程序员的编程水平和习惯有很大的关系

    ④ 对测试错误结果一定要有一个确认的过程。一般由 A 测出来的错误,一定要由 B 来确认,严重的错误可以召开评审会进行讨论分析

    ⑤ 制定严格的测试计划,并把测试时间安排的尽量宽松。不要希望在短时间内完成一个高水平测试

    ⑥ 回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多的错误出现的现象并不少见

    ⑦ 妥善保存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档

9、测试发现 BUG 而开发不认为是 BUG 怎么办?

    ① 找到需求文档或者是原型图进行匹对

    ② 尝试多种测试环境和多种测试方式来确认是否为 BUG

    ③ 整理 BUG 的复现的步骤和出现的频率

    ④ 开发坚持不认为是 BUG 的时候找项目经理,测试经理进行沟通来确认是否为 BUG

    ⑤ 将客户经理,测试人员,测试经理和项目经理进行开确认会来判定是否为 BUG

    ⑥ 测试人员需要将 BUG 整理并写入测试总结中

10、开发流程

    瀑布形:

      

    螺旋形:

      

    V形:(笔试题:画图)

      

    W形:

      

测试归测试组:测试组长、测试经理

测试归项目组:项目经理

项目所属成员有那些和比例划分:

  UI      1人

  前端     1人

  后端     5人

  移动端:ISO / Android    2人

  测试     1人

软件测试工具:

    excel , word:测试用例,缺陷报告,测试计划,测试总结

    xmid:对项目的认知( web 项目,oa ,办公自动化 ,cem ,客户管理系统,erp 进销存系统,电力,医疗类)

      金融保险类,医疗,物流,电商,电力······需求文档

BUG 管理工具:禅道、Tira

测试环境:Linux(虚拟机的方式,云平台)

抓包工具:charles,Fiddler(MAC无法使用)

性能工具:jmeter,Loadrunner(试用版)

编程语言:shell,python

自动化: UI 自动化,接口自动化,单元自动化

移动端的专项测试

监控 K8S 的使用

数据库MySQL

推荐阅读