软件测试原书第二版（佩腾著）-学习笔记（二）
第三部分 运用测试技术
2019.05.23-2019.05.24
第8章 配置测试
1.配置测试（Configuration testing）
使用各种硬件来测试软件运行的过程。
2.分离配置缺陷
判断缺陷是配置问题而不仅仅是普通缺陷，最可靠的方法是：在另一台有完全不同配置的计算机上一步步执行导致问题的相同操作。如果缺陷没有产生，就极有可能是特定的配置问题。
3.执行任务
- 确定所需的硬件类型
注意：当软件有联机注册功能时，调制解调器和网络通信也需要考虑在配置测试中。 - 确定有哪些厂商的硬件、型号和驱动程序可用
——某些设备仅包装和标签有外在差异，属于同一个等价划分类。 - 确定可能的硬件特性、模式和选项
——软件没有必要支持所有硬件配置（如：某些游戏会要求最低显示分辨率）。 - 将确定后的硬件设备缩减为可控制的范围
——可以根据流行程度、类型、年份等信息挑选重点测试对象。 - 明确与硬件配置有关的软件唯一特性
——仅需测试与硬件交互相关的特性即可，不需要测试整个软件。 - 设计在每一种配置中执行的测试用例
- 在每种配置中执行测试
——发现软件缺陷时，需要与程序员和白盒测试员紧密合作，分离问题原因，判断所发现的缺陷是软件原因还是硬件原因。 - 反复测试直至满意
第9章 兼容性测试
1.为什么要测试兼容性？
现在大多数程序需要向其他程序导入和导出数据，在各种操作系统和Web浏览器上运行，与同时运行在同一种硬件上的其他软件交叉操作。
2.软件兼容性测试（software compatibility testing）
检查软件之间能否能够正确地交互和共享信息。
3.平台和应用程序版本
- 平台
对所有软件进行等价划分，划分原则可以是流行程度、年份、类型或生产厂商。 - 应用程序
- 向后兼容（backward compatible）&向前兼容（forward compatible）
向后兼容：可以使用软件的以前版本。
向前兼容：可以使用软件的未来版本。 - 对平台的兼容
兼容不同平台，以及多个其他应用程序。
4.标准和规范
- 高级标准
是否符合运行平台自身的标准和规范（如：外观和感觉、支持的特性等）。 - 低级标准
是否符合行业公开的标注和规范（如：文件格式和网络通信协议等）。
5.数据共享兼容性
- 文件保存和读取
- 文件导出和软件导入
——导入不同格式的数据，测试能否成功导出成新格式。 - 剪切、复制和粘贴
——除了简单的文本操作，还有对象连接和嵌入（如：复制图表时，当源数据产生了变化，图表也会相应改变）。
第10章 外国语言测试
1.本地化测试
除了测试语言翻译，还需要考虑到地域——用户的国家和地理位置。测试软件是否能适应特定的地域特征，照顾到语言、方言、地区习俗和文化。
2.文本扩展（text expansion）
翻译为其他语言可能会增加单词长度，这些扩展现象可能会导致没有正确换行、截断、连字符位置不对等问题；或者由于没有分配足够的内存空间，直接导致系统崩溃。
3.文本与代码脱离
所有文本字符串、错误提示信息和其他可以翻译的内容都应该存放在与源代码独立的资源文件（resource file）中，杜绝print “Hello World”；并且在动态生成文本信息时，避免用代码连接字符串（每个国家文字顺序不相同）。
第11章 易用性测试
1.易用性（usability）
交互的适应性、功能性和有效性的集中体现。
2.优秀UI的7个要素
符合标准和规范
——遵守运行平台的标准和规范。
- 直观
——用户界面是否干净？UI组织布局是否合理？功能冗余吗？帮助有效吗？ - 一致
——用户希望将其他程序的使用习惯沿用到新程序中（快捷键和菜单选项、命名、按钮位置）。 - 灵活
——可选择，但不要过多（灵活跳转、状态终止和跳过、数据输入输出）。 - 舒适
——定义模糊，讲究感觉。
如：Undo/Redo；如果操作缓慢，应该向用户反馈操作持续时间和进度。 - 正确
——测试UI是否做了该做的事。
如：显示是否与实际含义相同。 - 实用
——某些特性是否具有实际价值？是有助于用户执行软件功能的吗？
第12章 测试文档
1.文档测试的重要性
- 提高易用性
- 提高可靠性
——软件是否按照用户预期的方式和时间工作。 - 降低支持费用
——客户发现问题比早在产品开发期修复问题的成本高出10倍。
2.审查文档的内容
- 非代码部分
——技术编辑或技术校对，当做文档测试。
第4章 检查产品说明书
第6章 检查代码 - 文档和代码紧密结合
——使用超链接的联机手册或提供帮助的智能助手，当做软件功能测试。
第5章 带上眼罩测试软件
第7章 带上X光眼镜测试软件
第13章 软件安全性测试
1.软件安全是一项功能，软件漏洞是一种缺陷；测试安全缺陷属于失效性测试行为。
2.缓冲区溢出
字符串不正确处理（复制时目标串长度不够）硬气的缓冲区溢出，会导致覆盖后续数据或验证安全性的代码，从而导致安全漏洞。
3.计算机取证
潜在数据——用户变更时未被删除的保留数据。
- 最近访问过的站点
- 浏览器自动填充功能
4.潜在不安全数据
- RAM损耗
此部分数据信息是文件被创建时曾经驻留在内存中的，可能是空，也可能是管理员口令或信用卡账号，后来连同内存中的其他内容一起被写到了磁盘上。 - 磁盘损耗
此部分的数据是原本就存在磁盘上的无用数据（但可能包含保密信息），后来被其他数据覆盖，但由于新数据的长度不够，未能完全覆盖整个扇区的旧数据，而遗留下来的旧数据的一个部分。
第14章 网站测试
1.黑盒测试
- 建立状态表
——把每个网页当做不同的状态，超级链接当做状态之间的连接线。 - 文本
——当做文档对待。
不要依赖拼写检查，图片、表单、滚动块中的文字会遗漏；
通过大幅缩放浏览器窗口来检查文字布局问题。 - 超级链接
——确保链接跳转到正确的目的地，并在正确的窗口中打开。
链接要明显；
避免遗漏孤页（不能通过任何超链接到达的页面）。 - 图片
——确保载入、位置正确，文字环绕在图片周围。
网页载入的性能很大程度上和图片的数量有关，过多图片，会导致加载缓慢。 - 表单
——确保表单显示正确，数据校验有效。
页面缩放时，表单是否适当调整位置；
输入的数据是否有校验（长度限制、字符限制）；
可选域是否应该设置默认值。 - 对象和其他各种简单的功能
——把每一个特性按照常规程序的功能对待。
状态？数据处理？数据范围或边界？
2.灰盒测试
黑盒和白盒结合，仍然把软件当做黑盒来测试，但是通过简单的查看软件内部工作机制作为补充（因为HTML代码容易理解，并且不需要运行）。
3.白盒测试
- 动态内容
——根据当前条件可能发生变化的文字和图片（如：日期时间、用户自定义内容）。 - 数据库驱动的网页
——网页上的图片、文字说明、价格信息来源于服务器数据库。 - 用编程方法创建的网页
——通过某种工具自动生成的HTML网页。
着重测试产生的HTML网页是否与设计想法一致。 - 服务器性能和加载
——测试系统的性能和负载能力。
模拟数百万个连接和下载。 - 安全性
4.配置和兼容性测试
- 硬件平台
——不同设备会影响网站在屏幕上的显示效果。 - 浏览器软件和版本
- 浏览器插件
——浏览器的附加功能（如：播放音频或视频）。 - 浏览器选项
——浏览器的自定义设置会对网站运行有潜在影响。
- 视频分辨率和色彩
- 文字大小
- 调制解调速率
测试站点以不同的调制解调速率连接时工作是否顺利。
5.易用性测试
- 避免显示过期信息
- 避免滚动文字、不停运行的动画
- 避免滚动显示的长页面
- 避免非标准的链接颜色
第四部分 测试的补充
2019.05.27
第15章 自动测试和测试工具
1.工具和自动化的主要属性
速度，效率，准确度和精确度，节省资源，仿真和模拟，坚持不懈。
注意：软件测试工具不能替代软件测试员，它们只能帮助软件测试员更好地工作。
2.测试工具
- 查看器（viewer）或监视器（monitor）
——能够看到正常情况下看不到的软件运行细节。- 代码覆盖率分析器
——查看哪些代码行得以执行，什么函数正在运行、执行测试时所运行的代码分支等。
入侵式工具，需要编译并连接到源程序中才能获得所需的信息。 - 通信分析器
——查看通过网络或者其他通信电缆传输的原始协议。
非入侵式工具，只是监听线路，提取数据。
任何能够洞察系统，看到一般用户看不到的数据的工具都可以归类为查看测试工具。
- 代码覆盖率分析器
- 驱动程序
——控制和操作被测试软件的工具。- 用另一台计算机模拟键盘和鼠标的大量输入
- 为什么不能直接运行一个模拟击键的程序？
1）软件或操作系统可能不是多任务的；
2）从外部计算机发送击键信息时，被测试系统处于非入侵状态。
- 桩
——接收或响应软件发送的数据（与驱动程序本质上相反）。 - 仿真器
——实际使用中用计算机模拟真正的设备。 - 压力和负载工具
——可以将机器的可用资源设置为小值，测试代码在资源不足时的运行情况。
理想情况：软件运行不发生崩溃或数据丢失。他可能运行得很缓慢，或者宣布在内存不足情况下运行，但最终会正确运行或正常的降级运行。 - 干扰注入器和噪声发生器
——类似于压力和负载工具，但行为上更具有随机性。- 压力测试中不断改变内存
- 监听通信数据时模拟数据中断、噪声等通信问题
3.软件测试自动化
——可以执行测试用例、查找软件缺陷、分析看到的信息、记录结果。
- 宏录制和回放
——录制第一次执行用例时的键盘和鼠标操作，在需要重新执行这些测试时回放一次。- 优势：宏可以进行一些自动测试，使重新执行测试更加容易和迅速。
- 缺点：测试结果的正确性不能得到验证；
当软件执行速度发生变化时，很有可能会误点击。
- 可编程的宏
——在宏的基础上编写回放系统遵循的简单指令- 优势：可暂停执行，向测试员提示预期结果，并询问测试通过还是失败；
不依靠绝对时延，而是等待待定条件成立才接续执行。 - 不足：不能使用变量或决策语句来控制宏；
没有自动检查测试结果的能力。
- 优势：可暂停执行，向测试员提示预期结果，并询问测试通过还是失败；
- 完全可编程的自动测试工具
——具有成熟的编程语言能力，可驱动被测试软件的宏命令，以及进行验证的能力。- 验证测试结果的方式
- 屏幕捕获
——比较当前测试结果屏幕与正确屏幕截图是否一致。
缺点：需要进行大量维护，因为像素稍有变动就会导致屏幕比较失败。 - 控件值
——检查软件窗口中各种空间的值。 - 文件和其他输出
——将软件数据保存在文件中，再与已知正确文件进行比较。
缺点：与屏幕捕获一样，日期、计数器或其他无关值的变化都会导致文件比较失败（解决：可以修改自动测试工具，忽略这些差别）。
4.随机测试
——模拟用户可能的操作，来补充测试用例。
- 笨拙的猴子
——随机地单机鼠标或敲击键盘。
特点：- 不停重复的操作可能会暴露内存泄漏等软件缺陷；
- 绝对不会验证；
- 如果被测试软件崩溃，笨拙的猴子仍然会继续操作。
- 半聪明的猴子
——会辨认崩溃。当软件崩溃后，重启计算机，重新开始测试。 - 聪明的猴子
——有目的的敲击键盘，会阅读软件的状态转换图（知道下一步应该点击哪里才会改变状态）；
——并且不限于查找缺陷，还能同时查看数据，检查操作结果，找出其余预期结果的差别。
5.自动化测试需要考虑的问题
- 软件变更：所有宏录制可能失败；
——需要编写灵活的自动化程序，在需要时做出方便快捷的改变。 - 人眼和直觉是不可替代的；
——聪明的猴子的聪明是有限的，他不会发现一些有趣的现象而自动对其做更多的测试。 - 验证难以实现；
- 不要过分依赖自动化；
——杀虫剂怪象。 - 不要花费过多的时间使用达不到测试目的的测试工具上；
- 某些工具是入侵式的，发现的软件缺陷有可能是工具导致的。
——使用工具发现了一个缺陷时，要设法在不使用工具的情况下重现这个软件缺陷。
第16章 缺陷轰炸和Beta测试
1.缺陷轰炸
在一段时间（一般为几个小时）内整个测试小组停下置顶的常规测试任务，参加轰炸，即对软件中某一区域，所有测试员集中测试这个区域或者这组特性。
2.为什么要让别人测试你的软件？
- 有助于打破杀虫剂怪象；
- 不同的人观察角度不同，测试方法也不同；
- 有助于消除重复带来的疲劳感；
- 可以学习别人解决问题的方式。
3.Beta测试
——将软件分发给潜在客户群，然他们在实际环境中使用软件。
- 优势：是寻找配置和兼容性缺陷的好方法；
可以依据测试结果改善测试用例，是软件缺陷将来能够在内部发现。 - 注意：不能依靠Beta测试来代替实际测试！Beta测试会耗费大量的时间，导致可能没有足够的测试时间留给测试员。
第五部分 使用测试文档
2019.05.28-2019.05.30
第17章 计划测试工作
1.软件测试文档
——是软件测试员与产品开发小组交流意图的主要方式。
目的：规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险。
重点：是计划的过程，最终目的是交流软件测试小组的意图、期望，以及对将要执行的测试任务的理解。
2.测试计划主题
- 高级期望
——测试计划过程的结果必须是清晰的、简洁的、在产品质量和可靠性目标上一致通过的定义，以免说不清是否达到目标。 - 人、地点和事
——测试计划应该包括项目中所有主要人员的姓名、职务、地址、电话号码、电子邮件地址和职责范围； - 定义
——明确软件缺陷和术语的定义，并保证小组全部成员理解和同意该定义。 - 团队之间的责任
——可以借助表格来明确团队之间的责任，标注某任务谁是主导，谁是参与。 - 哪些要测试，哪些不要测试
——验明每一部分是否需要测试，是否已经测试过。 - 测试的阶段
——每一个阶段都必须有客观定义的规则，明确地声明本阶段结束，下一阶段开始。 - 测试策略
——决定每个阶段的测试方法。黑盒白盒？手工自动化？哪个部分用什么方法？ - 资源需求
——人员、设备、软件、外包测试公司等。 - 测试员的任务分配
- 测试进度
- 给测试任务按照阶段定义的进入和退出规则采用相对日期，可以有效摆脱定死日期导致的进度破坏，并且单个任务需要多少时间也更明显。
- 测试用例
——决定用什么方法编写测试用例，在哪里保存测试用例，如何使用和维护测试用例（见18章）。 - 软件缺陷报告
——用于记录和跟踪所发现的软件缺陷，保证每个软件缺陷从发现到修复的过程中都被跟踪（见19章）。 - 度量和统计
——跟踪项目发展、成效和测试的手段（见20章）。 - 风险和问题
——明确指出项目的潜在问题或者风险区域。
第18章 编写和跟踪测试报告
1. 计划测试用例的目的
- 组织
——正确的计划需要一些测试员花一段时间组织好用例，以便全体测试员和其他项目小组成员有效地审查和使用。 - 重复性
——在项目期间有必要多次执行同样的测试，以寻找新的软件缺陷，保证老的软件缺陷得以修复，计划可以帮助我们明确用例的执行情况。 - 跟踪
——计划执行多少用例？在种种发行版本上执行多少用例？多少通过，多少失败？有被忽略的用例吗？ - 测试证实
——在高风险行业中，测试小组必须证实执行了计划的测试，正确的测试加护和跟踪提供了一种证明测试内容的手段。
2.测试文档的等级
测试计划–>测试设计说明–>测试用例说明–>测试过程说明
离最高级的测试计划越远，侧重点就越倾向于产生书面文档，而不是创建过程。
- 测试设计
——把软件拆分为具体特性和测试项，并将其分派给各个测试员，但是不指明这些特性如何测试（可能会提到使用自动化测试或黑盒测试或白盒测试，但不会涉及他们在哪里和如何使用的具体细节）。 - 测试设计说明
——提炼测试方法，明确指出涉及包含的特性及其相关测试，指出测试用例和测试的程序，指定特性通过/失败的规则。- 特性：软件特性描述，主要特性牵涉到的间接特性，不被测试的特性；
- 方法：描述测试软件特性的通用方法（使用的技术），解释结果如何验证；
- 测试用例确认：列出等价划分。
- 测试用例说明
——清楚的解释要想软件发送说明值或条件，以及预期结果。 - 测试过程说明
——详细定义执行测试用例的每一步操作。
3.测试用例组织和跟踪
回答这些问题：
- 计划执行哪些测试用例？
- 计划执行多少个测试用例？执行需要多少时间？
- 能否挑选出测试集测试某些特性或者软件部分？
- 在执行测试用例时，能否记录哪一个通过、哪一个失败？
- 在失败的测试用例中，哪些在最近的一次执行也失败了？
- 最近一次执行测试用例时通过的百分比是多少？
第19章 报告发现的问题
1.为什么不可能修复所有的软件缺陷？
- 没有足够的时间
- 不算真正的软件缺陷
- 修复的风险太大
- 不值得修复
- 无效的软件缺陷修复报告
——测试员没有建立足够强大的用例来使特定软件缺陷得以修复。
2.有效的缺陷描述
- 短小
——只解释事实和演示、描述软件缺陷必需的细节；
但要给出说明问题的一系列明确步骤或引用一些例子。 - 单一
——每个报告只恨对一个软件缺陷。 - 明显且通用
——用容易看懂的、简单易行步骤描述得软件缺陷的一个特例，得到修复的机会较大。
- 分离软件缺陷：找出真正导致软件缺陷的步骤，而不是提交自动化工具运行的整个过程。
- 可再现
——按照预定步骤可以使同样的软件缺陷再次出现。
3.分离和再现软件缺陷
——设法找出收缩问题的具体步骤，并验明和建立完全相同的输入和完全相同的环境条件。
- 不要想当然地接收任何假设
——利用按键和鼠标记录程序准确记录和回放执行步骤，确保导致软件缺陷所需的全部细节可见。 - 查找时间依赖和竞争条件问题
——软件缺陷仅在特定时刻出现吗（取决于输入数据的速度？网络忙？） - 边界条件、内存泄漏和数据溢出等白盒问题可能会自己慢慢显露出来
——仅在执行某些测试之后出现的软件缺陷，重启计算后消失。 - 状态缺陷仅在特定的软件状态中显露出来
——当程序按照某种执行次序经过特定状态时才会出现缺陷。 - 考虑资源依赖性和内存、网络、硬件共享的相互作用
- 不要忽视硬件
——设法在不同硬件上再现软件缺陷。
4.缺陷的等级
并非所有的缺陷都是平等的，在报告软件缺陷时，一般要讲明它们将产生什么后果。一般用严重性（severity）和优先级（priority）划分软件缺陷。
- 严重性
- 系统奔溃、数据丢失、数据损坏、安全性破坏。
- 操作性错误、结果错误、功能遗漏
- 小问题、拼写错误、UI布局、罕见故障。
- 建议。
- 优先级
- 立即修复，组织了进一步测试，立竿见影。
- 在产品发布前必须修复。
- 如果时间允许应该修复。
- 可能会修复，但是即使有这个缺陷，产品也能发布。
软件缺陷的优先级在项目期间会发生变化。作为发现改软件缺陷的测试员，需要继续监视缺陷的状态，确保自己能够同意对其所做的变动，并进一步提供测试数据或说服别人修复缺陷。
5.软件缺陷的生命周期
打开（测试员发现缺陷）–>解决（程序员修复代码）–>关闭（测试员确认缺陷得以修复）
附加状态：审查（项目经理决定软件缺陷是否修复）、推迟（审查可能认定软件缺陷应该在将来的某一时间考虑修复）
6.跟踪软件缺陷
使用自动化缺陷报告和跟踪系统，每个软件缺陷信息包括缺陷的ID号、标题、状态、优先级、严重性和解决方案。
编辑软件缺陷时允许将其与认为类似的另一个软件缺陷关联起来。
虚度哟软件缺陷数据库不仅跟踪修复的备注，而且跟踪程序员修复软件缺陷时做了什么。代码行、模块、甚至错误类型也会记录，这些能够给白盒测试员提供有用的信息。
第20章 成效评价
1.使用软件缺陷数据库作为度量的依据是评测项目状态和软件测试员自身进展的极其有效的方式。
通过从软件缺陷数据库中提取信息，可以构造任何想要的度量。
- 度量：用于描述软件项目特定属性评价的术语（例：每天每个测试员发现缺陷的平均数、从软件的每个区域发现的缺陷数目、严重性1的缺陷和严重性4的缺陷的比率）。
2.常用项目级度量
- 某个测试员发现的缺陷时如何解决的（修复、不可重现、可重现、不是问题、推迟）；
- 已发现的软件缺陷在主要功能中的分布情况；
——可以了解缺陷来自何处，项目中有哪些区域需要增加或减少注意。 - 随时间推移所打开的软件缺陷数量；
——在软件缺陷数目出现明朗的下降趋势前，不能认为软件已经准备就绪。