测试开发1
基本概念
- 一. 测试开发基本概念
-
- 1. 什么是软件测试？
- 2. 软件测试和软件开发的区别？
- 3.你为什么选择软件测试？
- 4. 什么是需求？
- 二. 测试开发基础
-
- 1. 需求是软件测试的依据
- 2. 用户名和密码登陆测试用例
-
- 2.1 功能角度：
- 2.2 非功能需求维度：
- 2.3 性能：
- 2.4 兼容性：
- 3. 测试用例
- 4. 什么是BUG（软件错误）？
- 5. 开发模型 （5个模型）
- 软件开发的生命周期
-
- 5.1 瀑布模型
- 5.2 螺旋模型
- 5.3 增量模型、迭代模型
- 5.4 敏捷模型（重要！！！）
-
- 5.4.1 scrum模型
- 6. 测试模型
-
- 6.1 v 模型
- 6.2 w 模型
一. 测试开发基本概念
1. 什么是软件测试？
软件测试就是软件测试工程师验证软件是否满足用户的需求
2. 软件测试和软件开发的区别？
（1）开发：广度小，专业度高
测试：所需技能广泛，但是专业度低
（2）软件测试和软件调试
目的不同
–测试的任务是发现程序中的缺陷；调试的任务是定位并且解决程序中的问题。
参与角色不同
–测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。调试由开发人员完成。
执行的阶段不同
–测试贯穿整个软件开发生命周期，调试一般在开发阶段。
3.你为什么选择软件测试？
综合能力：沟通能力，学习能力，开发能力，文字能力，自动化测试技术，编写测试用例的能力，探索性思维
感兴趣
承受压力，承担责任
4. 什么是需求？
用户的期望和满足合同（文档，规则，标准)规定所需要的条件和权限
用户需求和软件需求
软件需求是用户需求转化而来的，它是用户需求的细化
用户需求比较粗略，直接实现会有困难，因为没有细节，所有需要软件需求把用户需求细节实现和规范，把用户需求变成一个具体的可实现的过程文档。
二. 测试开发基础
1. 需求是软件测试的依据
验证需求，保证需求正确可实现。细化需求，从需求中提炼出一个个测试项。
问题：软件测试人员如何深入了解需求？
从需求分析阶段就开始介入了解需求，站在用户需求的角度
2. 用户名和密码登陆测试用例
2.1 功能角度：
- 用户名和密码是否大小写敏感
- 页面上的密码框是否加密显示
- 后台系统创建的用户第一次登陆成功时，是否提示修改初始密码。
- 忘记用户名和忘记密码的功能是否可用。
- 前端页面是否根据设计要求限制用户名和密码的长度
- 如果登陆成功需要验证码，点击验证码图片是否可以更换（更新）验证码，更新后的验证码是否可用。
- 刷新页面是否会刷新验证码
- 如果验证码具有时效性，需要验证时效内和时效外的验证码是否有效。
- 用户登录成功，但是回话超时后，继续操作，是否会重新定向到用户登录页面。
- 不同级别的用户，登陆系统后权限是否正确。
- 页面登陆的焦点是否定位在用户名输入框中（易用性)
- 快捷键Tab和Enter键是否可以正常使用。
2.2 非功能需求维度：
- 用户密码后台（数据库）存储是否加密。
- 用户密码在网络上传输中是否加密
- 密码是否具有有效期，密码有效期到期之后，是否提示需要修改密码。
- 不登陆的情况下，在浏览器中直接输入登陆后才可以访问的URL地址，验证是否会重新定向到用户登录界面。
- 密码输入框是否不支持复制和粘贴。
- 密码输入框内输入的密码是否在页面源码模式下别查看。
- 用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的行为是否被篡改。
- 用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统的行为是否被篡改。
- 连续多次登录失败的情况下系统是否会阻止后续的尝试以应对暴力破解。
- 同一用户在同一终端的多种浏览器上登录，验证登陆功能的互斥性是否符合设计预期。
- 同一用户先后在多台终端浏览器上登录，验证登录是否具有互斥性。
2.3 性能：
- 单用户登录的响应时间是否小于3s
- 高并发场景下用户登陆的响应时间是否小于5s.
- 高并发场景下服务端的监控指标是否符合预期。
- 高并发场景下，是否出现死锁和不合理的等待。
- 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
2.4 兼容性：
1.不同浏览器下，验证登陆页面的显示以及功能的正确性。
2. 相同浏览器的不同版本，验证登陆页面的显示以及功能的正确性
3. 不同移动设备终端的不同浏览器下，验证登陆页面的显示以及功能的正确性。
4. 不同分辨率的界面下，验证登陆页面的显示以及功能的正确性。
3. 测试用例
测试用例就是向被测试系统发起的一组集合，包含测试环境，测试数据，测试步骤，预期结果，（重要性、优先级、操作方式、标题等）
优点：衡量需求的覆盖率；复用性，借鉴意义；可以用于回归测试；防止遗漏测试需求
4. 什么是BUG（软件错误）？
当且仅当，规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
5. 开发模型 （5个模型）
软件开发的生命周期
需求分析——计划——设计——开发——测试——运行维护
5.1 瀑布模型
特点: 阶段性强，每一个阶段比较独立；看重前期的分析需求和后期的测试。
缺点：测试在编码后才开始介入，导致前期的问题后期才发现，失去及早纠正的机会。
5.2 螺旋模型
适合于项目庞大，风险大，复杂度高。
特点：强调每一个迭代的测试质量和风险分析，抗风险能力强
缺点：风险管控人力物力投入很多，成本比较大。
5.3 增量模型、迭代模型
增量通常和迭代混为一谈，但是其实两者是有区别的。
增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
特点：抗风险能力强
5.4 敏捷模型（重要！！！）
《敏捷宣言》：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
特点：轻文档，轻流程、重目标、重产出、拥抱变化。
5.4.1 scrum模型
基本流程：
scrum里面的角色：
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
scrum master 负责召开各种会议，协调项目，为研发团队服务。
研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
（1） 产品负责人负责整理user story，形成左侧的product backlog。
（2） 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
（3） 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
（4） 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
（5）演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
（6）回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改
进的效果。
6. 测试模型
6.1 v 模型
特点： 每一个阶段独立性强
左边每一个阶段是右边测试阶段的依据，和右边每一个测试阶段一 一 对应。
瀑布模型变种（缺点）：测试在编码后才开始介入，导致前期的问题后期才发现，失去及早纠正的机会。
6.2 w 模型
W模型特点：每一阶段独立性强，测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。
局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临困惑。