一、软件测试:
使用人工操作或软件自动运行的方式来检验它是否满足规定的需求,弄清预期结果与实际结果之间差别的过程。
预期结果——用户的预期结果(需求,产品经理与客户沟通)
实际结果——软件的实际运行结果
软件缺陷——bug
二、正确理解软件测试
测试是为了发现程序中的错误
没有完美的软件 成功的测试是发现迄今为止都没有发现的错误
三、软件测试的目的:
把尽可能多的问题在产品交给用户之前发现并改正
确保最终交给用户的产品功能符合用户的需求
确保产品完成了所承诺或公布的功能
确保产品满足性能和效率的要求
确保产品健壮和适应用户环境
建立软件质量的信心,度量和提高被测软件的质量。
四、软件测试原则:
原则1:测试能显示缺陷的存在
原则2:穷尽测试是不可能的
原则3:测试尽早介入
原则4:缺陷的集群性(一个项目涉及到多个人开发,前后端开发个人能力,2/8原则,)
原则5:杀虫剂悖论(第一次测试能测试出来,第二次不能,个人思维固化,可相互交叉测试)
原则6:测试活动依赖于测试内容
原则7:没有失效不代表系统是可用的(功能没有问题,但是系统不符合客户标准)
原则8:测试的标准是用户的需求
原则9:测试贯穿软件整个生命周期(软件从生到死的过程,软件本身没问题但不适用现在)
原则10:独立的测试团队
五、测试的阶段:
SIT(开发阶段)——内部的测试人员
UAT(验证阶段)——用户验收产品/第三方的测试人员
六、测试过程:
需求分析——测试计划(方案)——测试用例——执行测试——测试 告
七、前端基础语言:
HTML(搭架子)+CSS(进行一些修饰—颜色字体等)+JAVASCRIPT(JS)(逻辑性)
八、B/S架构——C/S架构:
(1)、B/S架构(浏览器/服务器模式)
Web端通过Web服器向数据库提取数据
(2)、C/S架构(客户端/服务器体系结构)
客户端经过简单处理后直接向数据库提取数据
(3)、B/S与C/S对比:
①、客户端要求
C/S客户端的计算机电脑配置要求较高。
B/S客户端的计算机电脑配置要求较低。
②、软件安装
C/S每一个客户端都必须安装和配置专用的软件。
B/S最大的优点就是不用安装任何专门的软件,只要有一个浏览器就可以。
③、软件升级和维护
C/S每一个客户端都要进行升级和维护。
B/S客户端不必安装及维护。
④、安全性
C/S一般面向相对固定的用户群,它可以对权限进行多层次校验,提供了更安全的存取模式,对信息安全的控制能力很强。一般高度机密的信息系统应采用C/S结构。
九、软件测试分类:
黑盒测试:
(1)界面测试:测试用户界面的功能(布局是否合理,界面中文字是否正确)
(2)业务逻辑测试:业务层的测试,主要是对照需求测试,测试需求中的功能点是否都实现,且实现的功能与需求描述相符合。
(3)兼容性测试:同一软件在不同平台上是否能够正常运行并显示的测试
(4)易用性测试:用户使用软件时是否感觉方便
(5)回归测试:整体功能进行多次验证测试,每一轮测试测完之后再次从头跑
(6)功能测试:对产品的各功能进行验证,测指标的
(7)性能测试:通过自动化的测试工具模拟多种负载条件来对系统的各项性能指标进行测试
(8)负载测试:各种工作负载下系统的性能指标变化情况
(9)压力测试:通过确定一个系统的瓶颈或不能接受的性能点,来获得系统能提供的最大服务级别的测试。
(10)并发测试:负载测试+压力测试,确定系统并发性能的过程
(11)配置测试:了解各种不同因素对系统性能的影响程度,从而判断出最值得进行的调优操作。
(12)容量测试:通过测试预先分析出反映软件系统应用特征的某项指标的极限值,系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。
(13)可靠性测试:在给系统加载一定业务压力的情况下,使系统运行一段时间,以此检测系统是否稳定,这种测试的关注点是稳定,不需要给系统太大的压力,只要系统能够长期处于一个稳定的状态即可
十、软件测试流程:
测试需求:需求分析
测试计划:计划的编写(比如计划哪个电脑/手机去测试,计划哪个范围的测试内容)
测试设计:测试用例(有计划-有安排 有方案)
测试执行:测试每一条用例,然后开发去跑,会出现再次测试一轮又一轮
测试记录:写 告
分析:执行过程中的反馈,风险的分析
缺陷追踪:平台里面跟踪
完毕:结束可以从头再次跑一编
测试总结:提交测试 告(需要有根据-测试过程中提的bug)
十一、开发方式:
结构化开发:传统化方式,阶梯性——慢速,三个月-六个月
迭代开发:速度快,可快速运行单独模块,重复做一件事
十二、开发模型:
(1)瀑布模型:
类似结构化开发,像瀑布一样自上而下的理想化模型(适用于项目周期长-半年以上)
完成上个阶段再来做这个阶段
可行性研究 告:研究市场,估市值等
里程碑式文档:系统测试用例写出来,他人签字确认,或者写的需求已经通过确认
(2)快速原型模型:
原型:产品经理设计需求文档,做出原型(一幅图,页面,具体有哪些按钮 写什么字)
项目需求—需求分析—原型demo
(3)螺旋模型:
瀑布模型+快速模型
适用于大型系统,此模型注重风险分析
软件开发增量模型:每次版本发布增加一点内容,再次重新测试
十三、测试模型:
(1)V模型:
类似瀑布模型,增加测试环节
(2)W模型:
测试与开发是同步进行的
(3)H模型:
适用于敏捷测试
十四、敏捷开发模型:
以用户的需求进化为核心、迭代、循序渐进
软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试 具备集成和可运行的特征
专有名词:
Produck Owner——PO——产品经理
Product Backlog——PB——产品待办事项
Scrum Master——SM——敏捷开发/专家
Quality Assurance——QA——质量保障
敏捷测试:
基本素质要求:代码编写——测试——分析
DevOPS:
解决运维和开发之间矛盾
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!