思考题

1. 你怎样组建一支新的测试团队，包含一些什么岗位，如果要去招聘，开出什么条件？

参考：
首先，测试团队包含的成员（即工作岗位）

  • 测试经理
    测试部门的负责人。
    主要职责：

    • 对外：
      1. 公司内团队之间的沟通
      2. 向上沟通、汇报、日常作业
      3. 人才招募
      4. 外部影响力（公司内外）
    • 对内
      1. 团队管理与建设
      2. 项目管理
      3. 人才培养
      4. 目标拆解、执行、调整、跟进

  • 测试架构师
    测试技术的负责人，主要承担教练职责，是测试部门的技术核心，涵盖产品测试技术、自动化测试技术、专项测试技术、交付测试技术等方向。
    主要负责：测试技术管理、测试技术调研、测试技术应用、测试人员的技术培养等。

  • 核心测试人员
    测试任务的主要执行者，主要负责核心测试任务的落地执行、重要测试技术的落地实践、测试管理要求的有效实施。
    中等职级、业务专家或擅长某一方向技术。

  • 一般测试人员
    测试任务的主要辅助执行者，主要负责一般测试任务的落地执行、一般测试技术的落地实践、测试管理要求的有效实施。
    中低等职级。

  • 测试项目负责人
    类似于项目经理。工作重点在于沟通和协调。

  • 外包测试人员
    视为人力，作为一些特殊项目的补充。

  • 测试实习生
    除了做一些特殊时期的补充外，是选择和提前培养优秀应届生的途径之一。

其次，招聘条件（仅供参考）
任职要求：

  1. 计算机相关专业，本科及以上学历，3年及以上测试经验，有互联网、SaaS平台产品测试经验者优先；
  2. 具备一定的编程能力，熟练掌握Java/C/C++或各类脚本语言中一种，熟悉MySQL等数据库；
  3. 熟悉Linux操作系统，有自动化测试经验，能独立设计用例并编写代码实现自动化测试；
  4. 熟练测试理论与方法，对互联网质量保证领域有强烈的兴趣；
  5. 具有较强的业务分析能力，较好的沟通表达和综合协调能力，对质量保证有深刻理解；
  6. 具备撰写自动化测试工具以及搭建自动化测试平台的实战经验者优先。

参考链接：

2. 如果你作为测试项目负责人，你为什么要对软件测试过程进行管理？测试过程管理的原则，测试过程管理的目标
参考：
对软件测试过程进行管理的原因：

  • 能够使规定时间内完成所需完成的测试任务。

测试过程管理原则：
①有关测试需求；②测试计划先行；③建立任务优先级；④建立客观的评估标准；⑤尽早测试；⑥全面测试；⑦全过程测试；⑧独立的、迭代的测试。

测试过程管理目标：尽可能早地找出软件缺陷，并保证其得以修复。

参考链接：

3. 白盒测试策略
定义：
白盒测试也称结构测试或逻辑驱动测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。（测试用例由测试输入数据以及与之对应的输出结果组成。）

白盒测试使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。

策略：

  • 桌前检查
  • 模块测试
  • 代码评审
  • 同行评审
  • 代码走查
  • 静态分析

其他参考：

4. 掌握功能测试需求分析确定测试优先级
参考：

5. 掌握性能测试需求分析会用80-20原理计算负载量
书本例题：

  • 测试强度估算
    80-20原理：每个工作日中80%的业务在20%的时间内完成。
    举例：
    每年业务量集中在8个月，每个月20个工作日，每个工作日8个小时即每天80%的业务在1.6小时完成
    去年全年处理业务约100万笔，其中15%的业务处理中每笔业务需对应用服务器提交7次请求；其中70%的业务处理中每笔业务需对应用服务器提交5次请求；其余15%的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。

每年总的请求数：
（100x15%x7+100x70%x5+100x15%x3）x2=1000万次/年

每天请求数：
1000/160=6.25万次/天

每秒请求数：
（62500x80%）/(8x20%x3600)=8.68次/秒
即服务器处理请求的能力应达到9次/秒。

6. 设计功能测试用例
测试用例模板（仅供参考）

项目/软件 XXX 程序版本 XXX
功能模块名 Login 编制人 XXXX
用例编号 XXXX 编制时间 XXXX
相关的用例 无
功能特性 用户身份验证
测试目的 验证是否输入合法的信息，允许合法登录，阻止非法登录
预置条件 无 特殊规格说明 如数据库访问权限
参考信息 需求说明中关于“登录”的说明
测试数据 用户名=yiii密码=1
操作步骤 操作描述 数据 期望结果 预期结果 实际结果 测试状态
1 输入用户名称按“登录”按钮 用户名=yiyh密码为空 显示警告信息，请输入用户名和密码
2 输入密码，按“登录”按钮 用户名为空密码=1 显示警告信息请输入用户名和密码
测试人员 开发人员 项目负责人

操作步骤需要写出所有情况

7. I/O接口测试，局部数据结构测试
检查模块接口是否正确
CheckList:

  • 输入的实际参数与形式参数是否一致
    • 个数、属性、量纲
  • 调用其他模块的实际参数与被调模块的形参是否一致
    • 个数、属性、量纲
  • 全程变量的定义在各模块是否一致
  • 外部输入、输出
    • 文件、缓冲区、错误处理
  • 其他

当一个模块执行外部I/O操作时，必须进行附加的接口测试

  • 文件属性是否正确
  • OPEN/CLOSE语句是否正确？
  • 格式规约是否和I/O语句匹配？
  • 缓冲区大小是否和记录大小匹配？
  • 文件是否在打开之前被使用？
  • 是否处理了文件结束条件？
  • 是否处理了I/O错误？
  • 在输出信息里时候有文本错误？

模块的局部数据结构是经常出现的错误源。应当设计测试用例以发现下列类型的错误

  • 不正确或不一致的类型描述
  • 错误的初始化或缺省值
  • 不正确的（拼写错误的或被截断的）变量名字
  • 不一致的数据类型
  • 下溢、上溢和地址错误
    除了局部数据结构，全局数据对模块的影响在单元测试过程中应当进行审查。

检查局部数据结构完整性
Checklist:

  • 不适合或不相容的类型说明
  • 变量无初值
  • 变量初始化或默认值有错
  • 不正确的变量名或从来未被使用过
  • 出现上溢或下溢和地址异常
  • 其他

8. 怎样对一段Java代码进行测试，找出代码错误
参考：
单元测试的步骤：

  • 理解需求和设计
  • 概览源代码
  • 精读源代码
  • 设计测试用例
  • 搭建单元测试环境
  • 执行测试
  • 补充和完善测试用例
  • 分析结果，给出评价

参考链接：

9. 进行项目测试计划时间安排的时候，怎样才算是合理的时间安排？
参考：
测试计划时间安排上遵守：趋势收敛的原则，越到后面，周期越短，问题应该越少。那么测试执行的原则就是：尽可能的把问题都暴露在前面，这样才能保证测试时间上呈收敛趋势。

做测试计划时，测试轮次的安排，一般根据不同的项目来定，小项目2+1或者1+1，大项目3+1或者2+1。
举例说明：假如现有一项目，测试总时间为10天，需要分3轮进行测试。
那么测试时间的安排我们采取4、3、2的原则。
第一轮（4天）：全面覆盖所有用例；
第二轮（3天）：基本上是基本功能全覆盖（故要刷筛选好一级用例），回归问题单，缺陷比较多的模块功能全覆盖；
第三轮（2天）：基本上是回归问题单+基本功能全覆盖（执行一级用例）。
还有1天留着备用，若第3轮测试有未关闭的bug，需要再加一轮，用于回归问题。

以上就是常见测试计划安排模式：3+1模式。

参考链接：

10. 如果时间紧迫了，测试范围怎样裁剪？
参考：

  • 网上资料

    • 部分不重要的需求可以裁剪，不进行测试
    • 对测试范围按照重要性和风险进行优先级评定，优先测试重要的和风险大的

  • 课本

    • 优先级最高的需求功能（优先级如何确定）
    • 新功能和编码改动较大（提高性能表现）的旧功能
    • 经常容易出现问题部分的功能
    • 一些经常被用户使用的功能和配置

11. QTP自动化测试的时候，怎样提高测试脚本执行效率？
参考：

  • 使用VBS文件来启动QTP
  • 把变量和函数定义放到外部VBS文件，而不要放在Action中
  • 通过AOM控制QTP重启来解决QTP内存泄露问题
  • 尽量不要使用wait，而使用.sync或exist语句
  • 使用with语句可以让代码更清晰，而且效率更好
  • 使用OR要比DP快点
  • 不要保存image和movie到测试结果中
  • 把运行模式设置为fast
  • 通过AOM控制QTP
  • 在调用Action时使用相对路径

参考链接：

12. 理解性能测试的指标和性能测试给出的结果曲线
参考：
性能测试的指标

  • bs结构程序一般会关注的通用指标如下：
    • Web服务器指标指标：
      • Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数；
      • Avg time to last byte per terstion （mstes）：平均每秒业务脚本的迭代次数，有人会把这两者混淆；
      • Successful Rounds：成功的请求；
      • Failed Rounds ：失败的请求；
      • Successful Hits ：成功的点击次数；
      • Failed Hits ：失败的点击次数；
      • Hits Per Second ：每秒点击次数；
      • Successful Hits Per Second ：每秒成功的点击次数；
      • Failed Hits Per Second ：每秒失败的点击次数；
      • Attempted Connections ：尝试链接数；
  • cs结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：
    • User 0 Connections ：用户连接数，也就是数据库的连接数量；
    • Number of deadlocks：数据库死锁；
    • Buffer Cache hit ：数据库Cache的命中情况

性能测试给出的结果曲线
参考LoadRunner性能测试工具—（三）测试结果样例分析

13. 如果让你负责性能测试，你会按照什么思路开展工作？
参考：
性能测试的方法是通过模拟生产运行的业务压力量和使用场最组合,测试系统的性能是否满足生产的性能要求。即在特定的运行条件下验证系统的能力状况。主要强调在特定的软硬件环境、特定的测试业务场景下,获得系统的各个性能指标。
而身为一个软件测试工程师应根据以下步骤开展工作：

  1. 制定目标和分析系统
  2. 选择测试度量的方法
  3. 学习的相关技术和工具
  4. 制定评估标准
  5. 设计测试用例
  6. 运行测试用例
  7. 分析测试结果

课本补充

有关软件测试的作用

  • 产品质量的保证
  • 控制成本的关键
  • 软件可靠性确认
  • 让企业具备国际竞争的实力

QA、QC、QM

  • QA 质量保证
  • QC 质量控制
  • QM 质量管理

软件测试人才需求快速增长的体现

  • 中国软件产业正在快速增长，需要大量软件相关人才。
  • 软件企业的发展要求测试人才达到一个合适的比例
  • 软件企业开始认识到软件测试对于提高软件质量的重要性，开始重视软件测试。

软件测试技术的内容
软件测试包括：

  • 测试计划、测试流程、测试策略、设计测试用例、执行测试、撰写测试报告
  • 单元测试、集成测试、系统测试、确认测试
  • 手工测试、自动化测试
  • 测试工具、缺陷管理和维护工具
  • 编写操作手册、功能手册、系统管理手册、培训手册
  • 维护文档、维护测试环境、分析问题、归纳推理能力

测试用例的组成

  • 用例标识
  • 用例名称
  • 被测功能
  • 用例目的
  • 数据准备
  • 测试步骤
  • 预期结果
  • 实际结果
  • 测试人员
  • 测试日期

编写测试用例的注意事项
要解决4W问题

  • why
  • when
  • who
  • what

测试用例说明包含的要素

  • 标识符
  • 测试项
  • 输入说明
  • 输出说明
  • 环境要求
  • 特殊要求
  • 用例依赖性

测试的三大原则
1. 尽早测试
2. 连续测试
3. 自动化测试

软件测试职业素质

  • 软件测试员的目标：
    ——发现潜在的软件缺陷
  • 软件测试员应具备的素质：
  1. 具有探索精神
  2. 具有创造性
  3. 坚持不懈的精神
  4. 故障排除专家
  5. 判断准确
  6. 追求完美
  7. 沟通能力

软件危机内在的原因

  • 在软件开发过程中，软件缺陷的积累和放大效应是导致软件危机的主要原因
  • 人员和其他资源的投入导致开发成本急剧增加，带有缺陷的开发成果导致开发质量大幅下降，反复无常的修改导致开发效率严重底下
  • 因此，迫切地需要规范化地过程来制约软件开发的无序性，便产生了软件工程。

怎样写测试计划

  • 确定内容
    • 总的测试计划
    • 分阶段的测试计划
    • 参考测试模板
  • 考虑以下问题
    • 测试问题
    • 测试策略
    • 测试技术
    • 测试组织
    • 测试准备

测试计划的用途

  • 为测试中的管理工作和技术工作提供指导
  • 确定达到测试目标和测试目的的必要的测试类型和范围
  • 概述有效使用资源的时间和活动的时间顺序安排
  • 通过建立需求跟踪矩阵，为可能的、最高水平的测试覆盖提供保证
  • 概述测试程序脚本的详细内容，描述如何执行测试程序脚本
  • 概述测试所需的人员、财力、设备和工具资源

测试计划的作用

  • 避免测试的“事件驱动”
  • 使测试工作和整个开发工作融合起来
  • 资源和变更事先作为一个可控制的风险

测试需求分析

  • 什么时候进行测试需求分析
    在开始测试设计之前确定测试需求
  • 测试需求分析做什么？
    清晰地定义测试需求并形成文档，使所有工作人员理解测试工作的基础
  • 测试需求分析的目的是什么？
    识别验证系统所需的不同类型的测试，在哪个测试阶段完成。

白盒测试能做什么？

  • 保证模块内的所有独立路径至少执行一次
  • 执行所有逻辑判定为真和为假的情况
  • 在循环可操作范围内，执行所有边界循环
  • 运用内部数据结构以保证其有效性

单元测试方法
在对每个模块进行单元测试时，需要考虑它和周围模块之间的相互联系。为模拟这一联系，在进行单元测试时，必须设置若干个辅助测试模块，这些辅助模块分为两种：

  • 驱动模块。相当于被测模块的主程序，用以模拟被测模块的上级模块，用于接收测试数据，并把这些数据传送给被测模块，启动被测模块，最后输出实测结果。

  • 桩模块。相当于被测模块调用的子模块，用以模拟被测模块的下级模块。

测试评估

  • 软件测试的主要评测方法包括覆盖评测和质量评测。
    • 覆盖评测是对测试完全程度的评测，它建立在测试覆盖基础上
      测试覆盖是由
      • 测试需求和
      • 测试用例的覆盖或
      • 已执行代码的覆盖表示的
  • 质量评测是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的缺陷及缺陷修复的分析的基础上。

功能测试一般什么时候执行

  • 白盒测试可以在编码的早期进行
  • 功能测试主要在后期执行

功能测试的两种策略

  • 顺序测试每个程序特性的功能
  • 一个模块一个模块的测试，即每个功能在其最先调用的地方测试

功能测试的特点

  • 优点

    • 对于较大的代码单元来说（子系统甚至系统级），黑盒测试效率高
    • 测试人员不需要了解实现的细节，包括特定的编程语言
    • 测试人员和编码人员是彼此独立的
    • 从用户的视角进行测试，很容易被理解和接受
    • 有助于暴露任何规格不一致或有歧义的问题
    • 测试用例设计可以在规格完成之后马上进行

  • 缺点

    • 覆盖率较低，大概只能达到总代码量的30%
    • 自动化测试的复用性较低
    • 没有清晰的和简明的规格，测试用例是很难设计的

测试需求和用户需求的区别

  • 测试范围变化
  • 实现方式变化
  • 用测试策略去过滤用户需求

标准手工功能测试和实用手工功能测试的比较

  • 标准软件开发生命周期
  • 实际软件开发生命周期
  • 标准手工功能测试的过程
  • 实用手工功能测试的过程
  • 实用手工功能测试的关注重点

良好的测试用例的特征

  • 可以最大程度地找出软件隐藏的缺陷
  • 可以最高效率地找出软件缺陷
  • 可以最大程度地满足测试覆盖要求
  • 既不过分复杂，也不能过分简单
  • 使软件缺陷的表现可以清楚的判定
  • 不包含重复的测试用例
  • 测试用例的内容清晰、格式一致、分类组织管理

为什么设计良好的（最佳）的测试用例

  • 输入量太大
  • 输出结果太多
  • 软件实现途径太多
  • 软件缺陷的标准不同
  • 完全测试是不可能的

性能测试的类型

  • 并发（竞争）测试
  • 负载测试
  • 压力测试
  • 大数据量测试
  • 疲劳测试
  • 可靠性测试
  • 基准测试
  • 配置测试

性能测试的目标（问题：为了实现目标怎么选择性能测试类型）

  • 评价系统当前性能
  • 寻找瓶颈，优化性能
  • 预测系统未来性能，可扩展性
  • 系统的参数配置
  • 发现一些软件算法方面的缺陷
  • 产品评估/选型

性能测试关注的内容

  • 是否满足需求
  • 并发用户数/吞吐量
  • 平均响应时间
  • 服务器资源占用情况
  • 故障恢复时间

负载量分析的步骤

  • 识别性能测试的目标
    • 与最终客户一起定义
    • 文档化以确保一致
  • 定义负载量
    • 识别关键业务功能
    • 定义场景如何被执行
    • 近似的数据访问模式
    • 识别用户类型和特性
  • 选择测量点
  • 编写负载量分析文档
    • 用来创建有效的测试场景
  • 与最终客户一起复审（获得负载量模型的认可）

软件安全性测试的方法

  • 功能测试（专门设计的安全功能）
  • 漏洞扫描
  • 模拟攻击实验
  • 侦听技术