一个好的开发者,不仅要懂技术也要懂业务,更要明白你的程序的稳定性,而如何确定稳定性就是为了将业务很好的实现。此时就需要一个模块单独去测试代码。这个就是程序的测试
市面上的软件测试的岗位有很多。
最简单的软件测试组织形式就是没有任何组织的测试,几个人就把所有软件测试工作做完,这样做没有任何分工、没有任何层次结构。
按照测试人员的职责明确程度,可以划分成兼职测试和专职测试两大类。目前在很多软件企业,尤其是小规模的软件企业,往往没有专职的测试人员。在做测试工作的同时还要兼顾软件幵发、配置管理、技术文档编写、用户教育、系统部署实施等工作。
项目型的测试组织是指测试人员作为项目组成员之一紧密地结合到项目中,与项目组其他人员紧密协作,一般是从头到尾跟着项目走。而职能型的测试组织是指测试人员参与到项目中是以独立的测试部门委派的方式进入的。
而这各有缺点,
前者(项目性):因为亲密关系的情况,会有网开一面的情况。当然,作为项目的成员他能深入问题本质测试。
后者(职能型):不存在亲密关系,也就不存在网开一面的情况,但是对于项目不够深入。
尽管独立的测试部门会有一些不可避免的问题,例如参与项目的深入程度,容易导致“扔过墙”的测试。但是很多软件企业还是倾向于建立一个相对独立的软件测试组织。一个理想的软件测试组织可以是综合和兼容了几种结构方式的组织。
用户需求:
可以简单理解为甲方提出的需求,如果没有甲方,那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略
软件需求:
或者叫功能需求,该需求会详细描述开发人员必须实现的软件功能,大多数公司在进行软件开发的时候会把用户需求转化为软件需求,开发人员和测试人员工作的直接依据就是软件需求
业务需求—>软件功能需求点—>测试需求点—>测试用例
专业来说:当且仅当规格说明(软件需求)存在且正确,程序与规格说明之间的不匹配才是错误。
俗语:运行结果与预期结果不符。
主要经历: 需求分析,计划,设计,编码,测试,维护。
特点:线性的
优点:每个阶段做什么,产出什么非常清晰。
缺点:风险往往,到后期测试阶段才能显露,因而失去了及时纠正的机会
适用的项目:小型的项目
1.需求计划–2.风险分析–3.软件需求–4.确认需求–5.开发计划–6.风险分析–7.软件产品设计–8.设计确认与验证–9.组装与测试–10.风险风险–11.详细设计(编码-》测试(单元测试,组装与测试,验收测试),实现)
优点:每个阶段都会进行风险缝隙,避免一些线上问题发生
缺点:开发周期长,风险分析可能会出错,需要人力财力的投入(比如聘请风险分析师)
适用项目:适用比较大的项目。
增量:一个功能开发完成后再去开发一部分(促使开发小组以一种循环的、可预测的方式驱动产品
的开发)
迭代:一个功能开发一个部分,然后再去开发另一个功能的一部分。
敏捷宣言:
scrum由product owner(产品经理)(PO)、scrum master(项目经理)(SM)和team(研发团队)组成。
team(后端开发,前端开发,UI设计师,测试)
三大角色:
项目流程:
产品经理收集用户需求–》项目经理(优先级安排)—(每日例会-----》演示会议—》总结)----》研发团队
(以下是开发人员)
用户需求:产品经理收集用户需求形成软件需求
需求分析:验证需求是否正确
系统设计:确定编程语言,确定框架
概要设计:项目结构如何设计
详细设计:每个接口,涉及哪些库表,设计哪些任务
(以下是测试人员)
编码:写代码
单元测试:java中测试每个一个方法,类C语言中函数
集成测试:将许多的方法集成到一起测试
系统测试:模块和模块之间没有影响
验收测试:产品和运营
特点:左边开发,右边测试(类似于瀑布模型)
优点:测试被划分成许多类型
缺点:测试人员介入太晚,发现问题时机太晚
特点:开发一个V,测试一个V
优点:测试人员尽早,介入需求
缺点:测试人员和开发人员在一定程度上是串行的。测试中遇到问题,要层层变化(不能变化,不适用敏捷开发)