目录
1.测试需求
2.测试用例的概念
3.bug
4.软件生命周期
4.1需求分析
4.2计划
4.3编码
4.4测试
4.5运行维护
5.测试模型
5.1敏捷开发模型
5.2scrume
5.3测试模型
5.4w模型(双v模型)
6.软件测试的生命周期
7.BUG的描述和定义
8.如何定义bug的级别
9.BUG的生命周期
10 .如何开始第一次测试
11.测试的执行和bug管理
1.测试需求
从测试人员的角度来看待需求.需求是测试人员开展测试工作的依据,在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。
过程如下，业务需求—>软件功能需求点—>测试需求点—>测试用例
为什么需求如此重要?
从软件功能需求出发,无遗漏的识别出测试需求是至关重要的,这将直接关系到用力的测试覆盖率,对于识别出每个测试需求点,需要采用具体的测试用例方法来进行测试用例的设计.
测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好
时机。只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集。
2.测试用例的概念
测试用例是为了实施测试而向被测试系统提供的一组集合,这组集合包含了测试环境,操作步骤,测试数据,预期结果等要素. 测试用例解决了两大问题,测什么,怎么测.
测试过程中可能会遇到以下问题： –不知道是否较全面的测试了所有功能 –测试的覆盖率无法衡量 –对新版本的重复测试很难实施 –存在大量冗余测试影响测试效率测试用例的产生就是为了解决上述的问题
2.1为什么有测试用例呢?
1.测试用例是为了提高测试人员工作效率,降低测试人员工作的重复性问题
2 测试用例的建立自动化测试的基础
举个例子,如何设计一个手机打电话这个功能的测试用例:
我们可以设计为三个步骤分别是:
1.打电话前
2.打电话中
3.打电话后
在打电话前 我们可以有四个方面要测,分别是功能相关(如电话号码准确性,黑名单电话,不同地区的电话号码等),性能相关 打电话可以最远打多远的电话,可以识别出多大的声音,通话过程中会不会受到电磁波的干扰等. 还有兼容性,我们可以打给什么人,座机打给手机用户,移动打给联通或者电信等. 还有安全性,电话会不会被窃听,通话过程会不会被截取等.
一个简单的打电话,就可以设计出如此多测试用例,可见在真实的项目中,测试用例的设计和使用是有一定挑战的,但是也是至关重要的.
3.bug
什么是bug. bug准确的来说就是,当且仅当规格说明书是正确的,程序与规格说明书之间的不匹配就是.当规格说明书没有提到的功能,判断标准以最终用户为准,当程序没有实现其最终用户合理预期的功能要求时,就是软件错误.
4.软件生命周期
生命周期.顾名思义就是一个东西从到死亡的过程,和动物还有人的生命周期类似.软件的生命周期也是这样,但是可以大致分为以下周期:需求分析,计划,设计,编码,测试,运行维护.接下来我们分别对这些来进行说明
4.1需求分析
软件需求分析是由产品经理根据用户的需求来提出来的软件需求,我们要看的是需求分析是否合理,需求是否完整.
4.2计划
谁开发,谁测试,开发多久,测试多久.这些步骤都属于我们的计划中.
4.3编码
有了计划以后,我们就可以根据计划来写代码,把抽象的计划写成具体的代码出来.
4.4测试
该过程就是把开发人员的编码后的结果拿来检测,找出bug并且与开发人员一起修改它,让功能正常使用.需要写测试报告
4.5运行维护
如果西安上有问题,需要测试人员和开发人员一起协助定位问题+解决问题.把这个软件维护好.
5.测试模型
在日常开发中,我们会有各种开发模型,如迭代,增量,螺旋,瀑布等模型.但这些模型或多或少有一些缺陷,在企业中我们着重会使用并且好用的模型被称之为敏捷开发模型.我们着重讲一下这个模型.
5.1敏捷开发模型
我们可以用几句话来描述一下敏捷开发模型的思想:
个体与交互重于过程和工具->个体之间面对面沟通
可用的软件重于完备的文档(文档就是开发文档和需求文档)
客户的写作重于合同谈判
响应变化重于遵循计划
(强调前者,但是并没有否定后者的价值)
5.2scrume
scrum里面的角色.scrum由prod duct owner(产品经理),sucrme master(项目经理)和team(研发团队)组成的,team是由很多人组成的, 有前后端开发,ui设计师,测试等.
其中产品经理负责整理user story(用户故事),定义其商业价值,对其进行排序,指定发布计划,对产品负责
项目监理 负责召开各种会议,协调项目,为研发团队服务.
研发团队由不同技术的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品.
5.3测试模型
v模型:
其中:
用户需求:pm将用户需求收集形成软件需求.
需求分析与系统设计:验证需求是否正确,制定编程语言,确定框架.
概要设计: 项目结构如何设计
详细设计:每个接口都涉及哪些库表,设计哪些任务
编码:写代码过程
单元测试:对每个方法(函数)进行测试
集成测试:将许多方法,集成到一起去测试 单个模块进行测试
系统测试:模块和模块 之间有没有影响
验收测试:验收的人 产品,运营
特点:左边是开发,右边是测试,类似于瀑布模型
优点:测试被划分成许多类型
缺点:测试人员介入太晚,发现问题实际太晚.项目的周期长.试错成本高
5.4w模型(双v模型)
W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分
别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑
6.软件测试的生命周期
软件测试的生命周期和软件测试的生命周期类似.有这些步骤:
需求分析:需求是否完整,需求是否正确
测试计划:确定软件由谁测试,什么时候开始测试,什么时候结束测试.测试哪些模块
测试设计:写测试用例(手工测试用例,自动化测试用例)
测试开发:编写测试工具,写自动化测试用例的代码
测试执行:执行测试用例
测试评估:测试人员产生测试报告
测试报告:
7.BUG的描述和定义
1.发现问题的版本
开发人员需要知道出现问题的版本,才能获取到对应版本的代码来重现故障,并且版本统计和分析每个版本的质量
2.问题出现的环境
环境分为硬件环境和软件环境,如果是web项目,需要描述游览器版本,客户机操作系统等,如果是app项目,需要描述机型,分辨率,操作系统版本等,详细的环境描述有利于故障定位
3.错误重现的步骤
描述问题重现的最短步骤
4.预期行为的描述
让开发人员指导怎么样是正确的,尤其是以用户的角度来描述程序的行为是怎么样的,如果是依据需求提出的故障,能写明需求的来源是最好的
5.描述行为的描述
描述错误的现象crash等可以上传log,ui问题可以有截图.
6 其它
某些公司会有一些其它的要求,例如故障的分类:功能故障,界面故障,兼容性故障等,样些优先级的分类,严重影响测试需要人员优先修改的,可以设置优先级
7.不要把多个bug放在一起
在无法确定是同一段代码造成的故障时,不要将bug放在一起提交
8.如何定义bug的级别
bug的级别有哪些按照严重程度分:1.(Blocker)崩溃 2. (Critical)严重 3.Major(一般) 4.Minor(次要)
1.崩溃 : 阻碍开发和测试工作的问题,类似但不限于 系统崩溃,死机,死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失等问题 如:代码错误,死循环,数据库发生死锁,重要的一级菜单功能不能使用等(该问题在测试中很少出现,一旦出现应该立即终止当前版本测试)
2.严重: 系统的主要功能部分丧失,数据库保存调用错误,数据丢失,一级菜单不能使用但是不影响功能的测试,功能设计和需求严重不符,模块无法启动或调用,程序重启,自动退出,关联程序间调用冲突,安全问题,稳定性等
3.一般: 功能没有完全实现但不影响使用,功能菜单存在缺陷但不会影响系统稳定性,如操作时间长.查询时间长,格式错误,边界条件错误,删除没有确定框,数据库中字段过多.
4.次要
界面,性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等 如:错别字,界面格式
不规范,用户体验不好,可以优化性能的方案等.
! 如果发现崩溃级别的BUG,那么此时就需要停止测试,测试打回.
9.BUG的生命周期
测试人员应该跟踪一个bug的整个生命周期,从Open到closed的所有状态.
bug状态转换图
New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed
缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用
测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同
的问题不再出现，才能关闭缺陷。
对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表
（或代表用户角度的人）的评审。
10 .如何开始第一次测试
作为一个菜鸟在进入测试团队开始第一次测试的时候，我们需要做很多的准备：
1、阅读所有项目有关的文档，包括：需求文档、设计文档、用户手册
2、尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务
专业性较强的项目，例如银行业务，需要了解各种业务知识，如高低柜、一二三类账户等、存款、贷款
等。
3、熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式
4、阅读已有的测试方案和测试案例
5、阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则
6、了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规
范等
在进行了以上的准备工作之后，第一次测试工作到来了，我们需要与测试组长确认具体的工作内容：
1、测试的计划是什么？
2、测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？
3、我要测试的内容开发人员是谁？需求人员是谁？
4、分配给我的测试内容是否需要特殊的测试资源？资源是否满足需要？
在我们确认了以上内容之后，就可以开始测试的执行了
11.测试的执行和bug管理
1. 打开待测试的系统
2. 打开测试管理工具用例模块，开始执行用例
3. 发现bug！进行复现并确认bug的复现步骤
4. 记录bug
5. 沟通bug
6. 验证以前提交的bug
7. 确认本次测试完成
8. 编写测试报告
执行测试时处理要做到测试用例和需求的覆盖外，还要有临时发挥的能力。根据自己的经验、对测试的感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷。
不能拘泥于测试用例或者已经有的测试方法，在测试执行过程中要不断总结测试方法和测试故障模型。
真正优秀的测试人员在执行测试时是想着做，做着想，这样的测试效果才好，尤其是在测试过程中，对程序的处理相当了解的情况下，测试的思路会更加清晰和全面。
如何发现更多bug
1、软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度！
2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度！
3、多进行逆向思维和发散性的思维
4、不要局限于用例和需求文档
5、尽早介入项目, 不要等到开发的差不多了再介入项目
