全程软件测试(八):永不收尾《全程软件测试》读书笔记

软件产品在完成了单元测试、集成测试和系统测试之后，验收测试（User Acceptance Testing，UAT）就要“粉墨登场”了，它是部署软件之前的最后一个测试操作，也是技术测试的最后一个阶段。其目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。值得指出的是，验收测试并不是以发现缺陷为主要目的，而是为了发现“未实现的需求”，验证软件的功能和性能符合用户期待，评估软件是否适合使用。

验收测试的主要分类有：

又称非正式验收测试，一般是员工在公司内部环境下进行的测试。主要目的是评价软件产品的FLURPS（功能、局域化、可用性、可靠性、性能和支持）。

β测试是模拟真实的使用环境从而发现缺陷的一种测试，是内测后的公测，完全交给最终用户测试，开发者通常不在测试现场，由用户记录下遇到的所有问题，定期向开发者报告。

验收测试须编写用户手册，要使用非专门术语来编制（PS：不要给“上帝”们炫技），语句要通顺、简洁，语义明确。能充分、详细地描述实现的功能，正确地指导用户使用。

注：以上五条其中之一不满足要求，视为不合格。

互联网时代，软件逐渐成为一种服务——软件即服务(Software as a Service，SaaS)，即通过网络提供软件服务。SaaS平台供应商将应用软件统一部署在自己的服务器上，客户可以根据工作实际需求，通过互联网向厂商定购所需的应用软件服务（注意是服务而不是产品），并通过互联网获得SaaS平台供应商提供的服务。而作为这种服务的提供者，我们必须要在客户端上进行安装测试。

安装前需要提前考虑不同的测试环境：已安装了先前版本的环境、从未安装待测软件的机器。如果已存在多个旧版本，可能要准备更多的测试环境——安装了不同版本的环境，相当于有不同的升级方案的验证。举个例子：

著名游戏公司（知名Bug工厂）育碧于去年11月发布了《刺客信条》系列的最新作，且目前已经更新到了1.05版本，正常来说，开发团队自己肯定是从1.04升级到1.05，但是问题来了，谁能确保玩家代代都更新过？万一某个玩家一直单机模式，某天得知最新版本修复了一个烦人的bug，心血来潮连上网准备更新，此时已经更新到很多代之后了，你如果不支持从初代版本直接升级到最新版本，难道要玩家卸了重装？用户肯定要砸桌子了：“我的存档怎么办！？”或者，让玩家从1.01先升1.02，再一点点升到最新版本吗？用户一定这想法：

为了避免类似上面这种麻烦。就要测试:

1.01直接升级到1.05版本;

1.02直接升级到1.05版本;

1.03直接升级到1.05版本;

1.04直接升级到1.05版本;

......

除此之外，还要考虑“先卸载再安装”和“直接在原版本上安装”这些情况，但无论是哪一种方式，都一定要保证数据的完整。（玩家：删我存档你试试？）

在安装测试过程中，除了要严格按照安装说明书或相关文档进行之外，还要注意安装的容错性、灵活性、易安装性等等，朱老师的书中写的很详细，在这里笔者就不再赘述。

在线测试（Test in Production, TiP）的核心思想是通过在用户的使用环境里面测试，定向地、小范围地发布产品给有限用户使用（灰度发布），可以快速获得反馈，从而减少缺陷可能带来的负面影响，这些反馈来自于真实的用户，而不是少量的测试人员和有限的测试用例。

可能有人要问了，软件在测试环境下都已经没问题了，有必要再费劲搞一个在生产环境中的测试吗？当然有！我们都知道，软件的正式运行环境和测试环境并不一致，我们无法确定某些特殊数据在正式环境当中是否还能正常运作。有些大数据的场景在测试环境里是无法构造的，这样一来，一些生产环境中出现的bug可能在测试环境中无法复现，问题也就无从解决。

另外，一旦我们发现新版本有严重的缺陷，通过在线测试，我们可以快速修复这些缺陷，还可以发布新版本或者回滚（roll back）到老版本，高效率解决问题。

TiP能够更好地满足用户，确保软件在实际环境中能保持稳定，其可说是传统测试的一个积极的补充，有效提高了测试覆盖率，找到一些平时无法测试到的场景，对软件的质量又是一次良好的巩固。

日志分析（log analysis）可以帮助发现未知安全事件、溯源分析已知的安全事件，以及控制风险、运营推广等。健全的日志记录和分析系统，是系统正常运营、优化以及安全事故响应的基础。

整个日志分析的过程可以概括为三个流程：收集、存储、分析。而常见的收集场景想必大家也见到过，比方说我们运行某个App的时候系统突然卡死或者闪退，过了一会弹出来个对话框问我们是否报告错误，这里说的就是日志的收集了。

笔者的PS4宕机之后......

常见的日志有：Linux的登录日志、移动App日志、Web服务器Access Log等，而随着大数据和云计算的发展，企业采用分布式架构也已成为常态，日志的处理可以借助Hadoop、Storm、Spark大数据处理的框架。而具体的日志分析工具则有许多的开源软件可供选择，比如：Elastic系列、Splunk、ArcSight等。

日志数据用得好，就是有价值的信息宝库；用得不好，就变成毫无价值的数据泥潭。想要为用户提供良好的体验，就需要我们充分发掘日志内容，了解用户使用过程中遇到了什么样的问题，从而有的放矢，不断地优化，为下次的成功积累经验。

产品上线之后我们还需要继续维护，“售后服务”不能少，因为程序中还可能存在安全漏洞以及兼容性等问题。因此，后期还会发布“补丁”，以修补安全漏洞、修复软件错误、增强系统兼容性、提升系统的可用性和性能等。

补丁测试，顾名思义，就是对补丁包进行的测试，该测试类型可以看作是一个简单的产品的测试，与产品测试相关的所有内容基本都需要涵盖，其基本流程包括：确定补丁的内容→补丁需求分析→制定补丁测试计划→设计补丁测试用例→补丁测试准备→补丁测试执行→补丁回归测试→提交测试报告。

补丁测试细分为以下四个部分：

另外，补丁分析结果包含以下内容中的任何一个，为不适合安装：

质量是一个产品的生命，我们需要借助补丁来持续地对产品的易用性、性能、可靠性进行增强，这有助于我们在客户群体中建立良好的产品口碑，并培养客户忠诚度，因此，我们也需要对补丁测试给予足够的重视。

无论是哪种测试，单元测试也好，在线测试等等也好，都需要对测试的过程进行评审，了解这个过程中是否存在问题，是否达到预期目标等，以决定是否要追加相应的测试，或补充测试用例，或调整测试策略与测试计划等等。要持续对测试过程进行评审，定期进行回顾，检查过去所进行的测试，及时发现测试过程中的问题，并及时纠正，这期间也是反思与学习的过程。也可以通过对遗漏的缺陷进行分析，找出自己的问题，积极反省，并持续地反思、学习与改进，从而提升自己的能力，为软件质量的不断提升提供保证。

要达到这样的目标，需要做到以下这些：

尽管保证软件质量主要靠的是测试，但质量高低的判定者应该是用户，而不是我们做测试的人。因此，我们要时刻将用户放在心上。努力走近用户，认真倾听、收集用户反馈，更好地理解客户的需求，以更好地评估产品质量。

找到问题的根本原因，消除根本原因，才能彻底解决问题。每当彻底解决了一个问题，我们就前进了一步。有时候尽管解决了一些问题，但治标不治本，我们还是无法获得进步。根因分析可以分为以下3个步骤:

• 识别问题

• 找出根本原因

• 找到解决措施

鱼骨图是根因分析常用工具之一

数字时代，一切通过数据来说话。过程改进需要用数据来度量，有了数据，就能清楚问题在哪里；有了数据，就能清楚是否有进步。这其中包括:

• 收集和测试、质量相关的数据

• 进行数据的抽取与分析

• 数据的可视化呈现

• 数据的进一步丰富

• 更深入地挖掘数据，找出更有价值的数据

PDCA（戴明环）是一个用于持续改进的简单但有效的模型，代表由计划(Plan)、执行(Do)、检查(Check)和处理(Act)构成的一个循环过程。

PDCA环（中间黄球代表目标）

计划(P)，分析测试现状，发现主要问题，找出主因，制订改进目标，形成改进计划。

执行(D)，根据已知的信息，设计具体的方法、方案和计划布局；再根据设计和布局，进行具体运作，实现计划中的内容。

检查(C)，总结执行计划的结果，分清哪些对了，哪些错了，明确效果，找出问题。

处理(A)，对总结检查的结果进行处理，对成功的经验加以肯定，并予以标准化；对于失败的教训也要总结，引起重视。对于没有解决的问题，应提交给下一个PDCA循环中去解决。

END