目录
在讨论这个问题之前,我先来介绍一下软件是如何诞生的:各种各样的软件之所以能做出来,不是说突发奇想就做了,而是真正的有需求(这个需求包括市场需求,用户需求,已经甲方有需求),然后公司才会把这个需求细化,将其细节整理成文档,然后开发人员根据这个文档去开发,开发之后经过了测试人员的一系列测试,通过了才会真正的上线去使用!!!
这也就是软件的诞生,接下来再来探讨一下什么是需求:需求其实就是满足用户的期望或者规定的文档(合同,标准,规范)所需要的条件或者权限,这其中包括了用户需求和软件需求,而用户需求是比较简略的(由用户提出),但是公司会把用户需求转化成软件需求,软件需求就是把用户需求细化,将其具体的细节实现成文档,后面才方便公司去真正的开发!!另外需求(功能,安全,性能,兼容性,界面,易用性,可靠性,容错性,可移植性 这些都可以作为需求的点)也是软件测试人员开展软件测试的重要依据!!
说到软件测试,那么测试用例是必要要懂得的,测试用例是向被测试系统发起的一组集合,这组集合包括测试环境,测试数据,测试步骤,预期结果,标题......
举个例子:假设现在要在网页上面登录一个邮箱,那其具体的测试用例到底是什么呢?
●标题:正确的用户名和密码登录邮箱,登录成功
●测试环境:具体使用的什么浏览器登录,应具体到哪个版本
●测试数据:正确的用户名和密码
●测试步骤:1.打开选择的浏览器,输入网页地址 2.输入正确的用户名和密码(如果有验证码,夜莺正确填写) 3.点击登录按键触发登录
●预期结果:登录成功页面跳转
这就是一个简单的测试用例,记录了整个登录的测试集合!!!
天天都在说BUGBUG的,那么BUG到底是什么呢?我来解释一下:当且仅当软件需求文档存在并且合理的时候,但软件的功能并不符合需求这个文档,这其实就可以称为软件错误(也就是BUG),而如果软件需求文档并不存在的话,用户的需求存在且合理,软件的需求和用户的需求不相符合这其实也是软件错误(BUG)!!!
1.软件开发生命周期
需求分析 → 计划 → 设计 → 编码实现 → 功能测试 → 运行维护
2.软件开发的五大模型
2.1 瀑布模型
●特点:很明显的可以看出来每一个阶段比较独立,是串行执行的,主要注重前期需求分析,后期再系统测试
●缺点:测试介入的太晚了,导致软件前期的问题后期测试才能发现,失去了及时修正错误的机会,只能推翻整个过程重新开始,而且串行的过程是不能相应需求的实时变化的
2.2螺旋模型
这个模型适合项目比较庞大,复杂且风险很高的项目
●特点:注重每个开发阶段的质量,每一个迭代都会进行风险的分析
●缺点:由于风险分析投入的人力,资源,管理成本比较多,因此整个的成本是非常高的
2.3增量模型, 迭代模型
这两个模型一般会混合在一起使用
●特点:抗风险能力比较强
●缺点:在这种开发模式下每一次迭代都有可能产生需求的更改,因此测试要紧密进行,不能放松!
2.4 敏捷模型
这里的模型就是一种开发流程,而提到敏捷模型就需要了解一下"敏捷宣言":轻文档,轻流程,重目标,重产出,响应变化,这也就是敏捷模型的特点
经典的敏捷流程:scrum流程
这其中有几个重要的角色:
PO,product owner:产品经理,产品负责人,负责收集需求,转化成userstory
SM,scrum master:负责保证整个敏捷流程的实施
ST:就是团队,由各种技能的研发人员组成,包括测试人员,研发人员,UI......
●发布计划会议:PO会把整理好的user story进行讲解,排出优先级,找出优先级高的组成本次迭代的内容,形成sprint backlog(代办事项列表)
●迭代计划会议:SM和ST一起把本次要迭代的需求进行分析,进行任务分配和时间估算
●每日站会:昨天做了什么,遇到了什么问题,以及今天的计划
●产品演示:给客户演示产品,讲解把不足的地方和客户提出的修改意见整理成user story放到下一期的迭代
●最后回顾会议(迭代回顾):回顾本次敏捷流程有什么不足的地方,洗一次迭代改进,优化敏捷流程
3.软件测试的两大模型
3.1 V模型
●特点:左右两边的阶段都是一一对应的,而且左边的阶段是右边测试阶段的依据,而且可以看出来这个一个串行的过程,因此这个也被称为瀑布模型的变种
●缺点:测试是在编码之后介入的,因此和瀑布模型是一样的问题,就是测试介入的太晚,前期的问题后期才发现,导致前期问题不能及时解决
3.2 W模型
也被称为双V模型
●特点:开发是一个V,测试也是一个V,而且软件开发的过程和软件测试的过程是同步进行的,因此这个就可以保证项目前期的问题能够及时被发现并解决
●缺点:这也是一个串行的,因此是不支持需求随时更改的变化的,因此是不支持敏捷开发的!
ok到这里基础的测试概念就介绍完毕了,希望以后大家以后都是BUG少少,福利多多!!!