测试指的是对我们生产出来的产品特性进行一些校验,例如对传感器、手机等的测试,而软件测试是对我们开发出的软件进行校验是否存在问题,测试软件特性是否符合用户需求。
软件测试的基本概念包括需求、测试用例、bug。
分为两大类,分别是用户需求和软件需求。
用户需求:由用户提出的需求,比如用户要求制作一个点餐小程序等。该需求一般比较简略。自研产品的话,一般由产品经理提出需求。
例如:用户对点餐小程序提出需求
软件需求/功能需求:将用户需求转化为软件需求,详细描述开发人员需要实现的功能。
注意:用户需求不等于软件需求。用户需求不一定合理、需要对用户需求进行提取和分析。
软件需求是我们测试人员进行测试工作的基本依据,而用户需求不能。
测试人员在执行测试前需要编写测试用例,测试用例的质量与产品的质量具有很大的关联关系,一份好的测试用例可以降低软件在线上环境出现问题的概率。但是任何测试样例都不能不能保证是完美的。
例如:对搜索框编写测试用例。
测试用例主要解决两个问题:测试什么、怎么进行测试。
测试用例的要素:测试环境、测试步骤、测试数据、预期结果等要素。
bug的由来:格蕾丝·赫柏1945年9月9日,格蕾丝使用的Mark Ⅱ出现故障,导致工作无法进行。经过了近一天的检查,格蕾丝找到了故障的原因:继电器中有一只死掉的蛾子。蛾子被夹了出来。后来,”bug” (小虫) 和”debug” (除虫) 这两个本来普普通通的词汇成了计算机领域中特指莫明其妙的“错误”和“排除错误”的专用词汇而流传至今,而格蕾丝·赫柏也因此成了第一个发现“bug”的人。
软件缺陷的概念和界定:
当且仅当存在规格说明且正确时,程序与规格说明之间不匹配就是错误的,可以提出bug。
例如:登录页面,规格说明要求昵称为4-12个字符,而测试时发现2个字符也能注册成功,可以认定为bug。
当规格说明没有提到的功能,判断标准以用户体验为准,当程序没有实现用户合理预期的功能,也可以认为是软件错误,可以提出bug。
例如:选择框供选项的元素非常多,几十甚至几百个,影响用户体验,也能提出bug。
开发模型:可以理解为开发流程/项目推进流程。软件从没有到上线的过程(软件的生命周期)。
软件的生命周期:需求分析->计划->设计->编码->测试->运行维护
需求分析:对用户需求进行分析、市场分析、技术分析。
计划:什么时候开始动工,什么时候结束,不同模块需要的时间等。
设计:将软件需求进行拆分,每个模块有谁来管理,设计哪些接口,采用哪些技术,使用什么框架等待。
编码:由开发人员参考需求文档和技术文档来进行编码。
执行测试:测试人员参考测试案例执行测试。
运行维护:
瀑布模型是其他模型的基础框架,一个阶段结束才能开始下一个阶段,线性顺序进行的软件开发模式,
缺点:
使用场景:需求固定的小型项目
采用渐进式的开发模型,在瀑布模型的基础上添加了风险分析,然后生成新的原型。增加了风险分析阶段,团队需要耗费更多的时间和资金。
适用场景:初期阶段需求不确定,变化概率大的大型项目。
计划:制定一个详细的项目计划,包括项目目标、时间表等等。
风险分析:对潜在的风险进行评估、识别和管理,可能包含技术风险、需求风险等等。可以制定相应的风险应对策略。
原型阶段:根据计划阶段确定的需求和目标,构建一个可交互的软件原型,能够展示系统关键功能以及交互流程。通过原型,尽早的发现潜在的设计问题,验证技术可行性。
产品实施阶段:开发团队将原型转为实际的软件产品,并进行全面的测试。保证软件的质量。
增量模型:将项目进行模块化,使其每一个功能都能够独立开发和上线。
迭代模型:先完成功能的基础版本,在经历一次次的迭代优化,直到功能完善。
软件开发敏捷宣言特点:
敏捷开发有很多种方式scrum是比较流行的一种。
scrum中的角色:
迭代开发:scrum将产品的开发分解成若干个小的迭代,周期不等,一般不超过四周,每周要完成的需求是固定的。每一次迭代产生一定的交付。
scrum的基本流程:
软件测试的什么周期:需求分析->测试任务->测试设计于开发>-执行测试->测试评估
明确了测试有不同类型,而且每个类型和前期的开发工作相对应。
缺陷:测试后置
测试从最开始就介入,有利于尽早的发现问题。但是开发和测试虽然是同步的,但是仍然存在着前后的线性关系。