软件测试_抻透

基础知识

1、软件测试

为了发现错误而执行的程序过程。具体：根据软件开发各阶段的规格说明和内部结构设计测试用例，并使用测试用例去运行程序，发现错误。

2、软件测试目的

• 少花钱
• 发现软件潜在问题
• 提高软件质量
• 回避潜在风险

3、需求文档测试

• 测试需求是否存在逻辑矛盾
• 需求在技术上能否实现

4、设计文档测试

• 设计是否全部符合要求
• 设计是否合理

5、α测试

• 实际用户来测试，现场立即反馈给开发人员
• 开发环境下（公司内部）
• 不能由程序员或测试员完成
• 着重于产品功能、可使用性、可靠性、性能等

6、β测试

• 实际用户来测试，记录问题，定期向开发者报告
• 实际环境下
• 不能由程序员或测试员完成
• 着重于产品支持性
• 在α测试达到一定的可靠度后才进行

7、驱动模块和桩模块

驱动模块：又称主程序，它接收测试数据并将数据传递到被测模块。
桩模块：集成测试前要为被测模块编制一些模拟下级功能的“替身”模块，代替被测模块的接口，接受或传递被测模块的数据。

8、白盒测试与黑盒

1）白盒：又称逻辑驱动测试，结构测试。主要方法有：逻辑驱动，基路测试、边界值分析、循环测试、覆盖测试、数据流测试、变异测试。

• 知道产品内部工作过程
• 检测内部动作是否按照说明书进行
• 不管功能
• 白盒测试工具是对源代码进行测试

2）黑盒：又称功能测试或数据驱动测试。主要方法有：基于用户需求的测试，边界值测试，等价类划分，错误推测方法，因果图方法，判定表驱动分析。

• 在软件接口处进行
• 不考虑内部逻辑结构和内部特性
• 检查功能是否符合要求

9、动态、静态测试

• 动态：运行程序
• 静态：评审文档，阅读代码（例如：查找不匹配的参数，不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针等）

10、回归测试

在程序员修改后，保证功能被修复且不能带来新的bug。一般是在软件维护阶段进行。

11、软件缺陷分级

• 严重性分级：基于对客户的打分的影响程度。
  1）致命：相关模块功能异常，死机
  2）严重：本模块失常
  3）一般：模块功能部分有问题
  4）建议：不怎么好用
• 优先级分级：基于缺陷被修复的紧急程度。
  1）立即：软件几乎不能用
  2）紧急：比较严重
  3）高优：缺陷严重，影响测试
  4）正常：部分异常，不影响其他
  5）低级：先不忙

12、软件测试阶段及各阶段要点

1）测试阶段

• 单元测试
• 集成测试
• 系统测试
• 验收测试

2）每个测试阶段分为以下步骤

• 测试计划
• 测试设计
• 用例设计
• 执行测试
• 测试文档

13、单元测试、集成测试、系统测试的侧重点

• 单元测试：测试其功能的正确性
• 集成测试：测试模块间的衔接及参数传递
• 系统测试：测试整个系统的运行及与其他软件的兼容

14、bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程

15、集成测试和系统测试的区别及应用场景

测试类型	区别	应用场景
集成测试	概要设计阶段制定集成测试计划和用例（后）；先执行集成测试；测试用例详细，重点在于接口部分；对测试人员编写脚本能力要求较高；测试方法为黑白结合	单元测试结束后，主要测试各模块接口是否一致，数据流和控制流是否按要求实现，结果的正确性
系统测试	需求阶段要制定系统测试计划和用例（先）；后执行系统测试；一般使用黑盒测试	针对整个产品成品之后，包含性能测试、功能测试、健壮性、安全性测试等

16、测试开发知识及能力

1）知识

• 软件基础测试理论知识
• 基本编程语言
• 自动化测试工具
• 计算机基础知识

2）能力

• 业务分析能力
• 缺陷洞察能力
• 团队协作能力
• 专业技能
• 逻辑思维
• 问题解决
• 沟通表达
• 宏观把控

17、手动测试与自动化测试优缺点

测试方法	优点	缺点
手工测试	测试员有经验，能够对一些错误进行猜测；测试员有审美和心理体验；测试员有是非判断和逻辑推理能力	重复的手工回归测试，代价昂贵，容易出错；过于依赖测试员的能力
自动化测试	回归测试方便，极易应付频繁修改程序的情况，且测试具有一致性和可重复性；可以运行繁琐的测试；能够执行手工测试困难或不可能进行的测试；更好地利用资源；增加软件信任度	工具本身无想象力；发现缺陷固定且较少；对测试质量地依赖性较大；不能提高有效性

18、软件测试的潜力和挑战

• 快速发展，充满挑战
• 自动化测试软件替代传统手工测试
• 自动化测试工具开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项仍需要大量具有专业技能和素养的测试人员
• 随着新技术的发展，传统测试技术还需要不断调整

19、软件测试的核心竞争力

测试人员的核心竞争力在于提早发现问题，尤其是别人无法发现的问题

• 如果需求未实现的时候发现漏洞，价值特别高
• 别人无法发现问题，而测试人员可以发现，说明了测试人员的不可替代性

20、测试和开发怎样结合才能使软件质量得到更好的保障

V模型：将测试过程加在开发过程的后半段，具体如图。缺点：忽略了测试对需求分析、系统设计的验证，需求阶段的缺陷可能到后期的验收才会发现，此时弥补将耗费大量的资源。

W模型：测试伴随软件开发周期，且测试对象不仅仅是程序，还有需求、设计等。测试与开发过程分别如两个V所示，具体如图。优点：尽早发现软件缺陷，降低软件开发成本；容易把握项目难度及风险，及早制定措施；减少总体测试时间，加快项目进度。

21、测试流程

1. 需求测试
2. 概要设计测试
3. 详细设计测试
4. 单元测试
5. 集成测试
6. 系统测试
7. 验收测试

22、写测试用例注意事项

• 理解需求（基础）
• 参考类似需求的测试用例
• 了解输入、输出及其关系，理解需求的执行逻辑，通过等价类、边界值、判定表等找出大部分用例
• 找到需求相关特性，补充测试用例
• 根据经验分析遗漏测试场景
• 多加总结，书写清晰规范

23、测试具体工作

• 搭建测试环境
• 撰写测试用例
• 执行测试用例
• 撰写测试计划、测试报告
• 实施测试、提交报告
• 跟踪bug修改情况
• 执行自动化测试，编写脚本，执行，分析，报告
• 进行性能测试、压力测试等其他测试，执行，分析，报告

24、软件质量六个特征

• 功能特征
• 可靠性特征
• 易用特征
• 效率特征
• 可维护性特征
• 可移植性特征

25、bug周期及类型

1）周期

• 新的
• 已指派的（责任已经到人）
• 打开的（正在处理）
• 已修复的
• 待测试的
• 正在测试
• 关闭（已经解决）
• 再次打开
• 拒绝中（开发人员）
• 被拒绝的（项目组长根据产品要求和说明）
• 延期的
  2）类型
• 代码错误
• 界面优化
• 设计缺陷
• 配置相关
• 安装部署
• 安全相关
• 性能问题
• 标准规范
• 测试脚本
• 其他

26、web测试和app测试

测试方法	系统架构方面	性能方法	兼容方面	专项测试
web测试	b/s架构，基于浏览器；web更新服务器端，客户端同步更新	web主要关注响应时间	web重点在于浏览器和电脑硬件、系统的兼容；不考虑卸载和安装
app测试	c/s架构，必须有客户端；需要同时更新客户端和服务器端	app关注流量、电量、CPU、GPU、Memory等	app看分辨率、屏幕尺寸，还有设备系统；必须考虑安装、更新、卸载；还有异常场景中断、弱网、安装后删除文件等	网络、适配性

27、测试分类

测试分类	包含
功能测试	功能测试
非功能测试	性能、压力、容量、安全性、易用性、健壮性、恢复性、备份、协议、兼容性、GUI

实例部分

1、用户登录测试

测试类型	测试内容
功能测试	正常登陆 输入错误的提示 登陆成功的跳转 用户名太短或太长 特殊字符 记住用户名 登陆失败，不能记住密码 密码是否明文显示 验证码扭曲，色盲模式 界面注册、忘记密码、登出用户等是否好用 输入密码键盘大写提示 不输入提交之后的提示信息
界面测试	布局是否合理，对齐，大小一致 界面设计风格与UI设计风格一致 界面简洁，没有错别字
性能测试	登陆时间 跳转时间 大量用户同时登陆
安全性测试	登陆成功后的Cookie是否安全 用户名和密码加密发送给web服务器 用户名和密码验证应该在服务器端。不单单是在客户端使用的javascript 输入框屏蔽SQL注入攻击、禁止输入脚本 防止暴力破解，是否有登陆次数限制 是否支持多用户在同一机器登陆 同一用户能否再多台机器登陆
可用性测试	是否可以全部使用键盘操作，是否有快捷键 回车能否登陆 tab键切换
兼容性测试	不同浏览器 浏览器不同版本 不同平台：Windows和Mac 移动设备 不同分辨率

2、杯子测试

测试类型	测试内容
功能测试	水倒水杯容量的一半 水倒规定的刻度线 水杯刻度与其他水杯一致 盖子拧紧水倒不出来 烫手
界面测试	外观美观、完整 大小、材质、图案与设计一致 图案遇水溶解
性能测试	使用最大次数 掉地上不易损坏 保温，耐热，耐寒 长时间放置不漏水
安全性测试	杯子材质毒或细菌验证 高温材质释放毒性 低温材质释放毒性
易用性测试	倒水、喝水、携带方便 使用简单，容易操作 防滑措施
震动测试	杯子加包装，六面震动，能否应对铁路/公路/航空运输