敏捷测试中的Web测试优秀实践

点击上方“CSDN”关注我们

说到Web测试的优秀实践，不得不提到敏捷开发流程。不同于瀑布流程，测试在敏捷开发流程中，涵盖了从项目启动到产品上线的各个环节。所以我们对于Web测试的优秀实践也是基于敏捷开发流程的。

下面我们就从项目全局、迭代和故事卡三个角度出发，向大家介绍Web测试的优秀实践。

1. 项目全局角度看测试实践

从整个项目全局的角度来说，测试人员一般会介入如图A-1所示的两个阶段：

图A-1  项目全局角度中测试人员的实践

在项目启动（Inception）阶段，不仅是业务方、业务分析人员、网站设计人员和开发人员需要参加，测试人员也是需要参加项目启动或者初始会议的。在这一活动中，测试人员从测试的角度出发，分析测试的可行性，以及了解业务需求。通常测试人员会使用行为驱动开发（BDD）和实例化需求（SBE）的方式来理清需求，避免需求歧义或者遗漏需求的情况发生。测试人员还会挖掘除了功能需求外，项目开发过程中需要添加的各项非功能性需求，例如性能指标和产品安全性等。

在项目初始阶段，测试人员通过分析产品的架构和开发团队的技术栈，通过技术选型，选择适合项目的自动化测试框架及编程语言，以及其他适用于项目并能提高测试效率的工具。同时测试人员还需要根据敏捷测试四象限（如图A-2）来制定测试策略和计划，用于下一阶段迭代开发中的测试。

图A-2  敏捷测试四象

2. 迭代角度看测试实践

从每个迭代的角度来看，测试工作会涉及到图A-3中所示内容：

图A-3  迭代角度中测试人员的实践

在迭代开始时，测试人员汇同业务分析人员和开发人员一起举行迭代启动会议（Iteration Plan Meeting）。在会议上制定详细的迭代开发计划，并对每张故事卡（Story Card）进行工作量的估算（Estimation）。故事卡的估算是基于点数的，而点数是相对于基准故事卡点数的度量，这个值不仅要包含开发这张故事卡所付出的开发人员的工作量，还需要包含测试人员进行测试的工作量，因为没有测试的故事卡也是不能交付客户的，也就是没有客户价值的。

在每个迭代的后期，测试人员通常还需要准备好类生产环境，设定好涵盖在上一次演示后新增的所有功能的演示脚本，并给业务团队进行产品演示（Showcase），以获取反馈和进一步改进的建议。

在每个迭代结束前，甚至在缺陷达到一定数量的时候，测试人员还需要对新增的缺陷进行分析，找出它们出现的根本原因，召开缺陷改进会议，探讨改进措施，避免缺陷的再一次出现。缺陷改进会议通常和新一期的迭代启动会议一起举行，因为当分析了缺陷产生的原因之后，才能在新的迭代进行修正和避免。

除此之外，测试人员还会不定期地组织缺陷大扫除（Bug Bash）和线上问题回顾（Post Incident Review）这样的团队活动。缺陷大扫除（http://insights.thoughtworkers.org/bug-bash/）不仅能让团队其他人员协助测试人员从新的角度发现产品的问题，还可以培养真个团队的质量意识。而线上问题回顾同样可以让团队了解问题的根本原因，从而更好地构建产品。

测试人员还需要参与代码评审（Code Review）。在这一过程中，测试人员不仅需要评审和学习开发人员编写的产品代码，也需要演示自己编写的自动化测试代码供开发人员评审。这样测试人员也更容易学习到开发人员的开发技巧，提高编程水平。

3. 故事卡角度看测试实践

在介绍迭代中的优秀测试实践时，我们并没有涉及故事卡开发中的测试，那我们现在来看看这一阶段中有哪些优秀实践。

图A-4  故事卡角度中测试人员的实践

首先，在业务分析人员完成故事卡的拆分以及分析后，测试人员需要评审故事卡的验收条件（Acceptance Criteria）并撰写对应的测试用例／场景。这比测试人员根据业务分析人员发送给开发人员和测试人员的需求文档来测试使测试前移了很多，而且这个工作也保证了后续活动能顺利执行。

其次，测试人员需要和业务分析人员以及开发人员一起参与故事卡的启动（Kick off）会议。虽然说是会议，可是经常是三方人员聚在卡墙（Story Wall）前进行简短的讨论。通常都会由开发人员来描述故事卡的业务需求、涵盖的内容以及验收标准，而测试人员和业务分析人员则进行补充和提问，以便所有人对于故事卡的内容的理解都能达成一致。同时所有人也会对测试人员编写的测试用例进行评审。 

之后在进行故事卡开发时，测试人员会按照测试金字塔（Test Pyramid）的分层原则，和开发人员讨论如何把测试用例尽量用更底层的测试来实现，以达到提高测试效率，并同时保证测试覆盖率的目标。对于可以完全被单元测试和集成测试覆盖的测试用例，测试人员会交由开发人员实现；对于部分未被覆盖的测试用例，测试人员会通过手动测试或者端到端自动化测试的方式覆盖。

在开发人员开发故事卡的同时，测试人员会按照自动化测试的框架以及页面对象（Page Object）模式编写故事卡对应的端到端自动化功能测试、集成测试和其他诸如性能测试等非功能性测试。这一工作也可能适合与开发人员进行结对编程（Pair Programming）完成的。在结对编程中，开发人员能学习到测试人员的思维方式，减少自己代码的出错几率；测试人员也能学习到更多的开发技巧。自动化测试编写完成后，也会提交到代码库中，在每次开发人员提交代码时，都在持续集成环境中不断运行。团队所有人员都需要保证每次代码提交都能通过所有的测试。

当开发人员结束故事卡的开发时，测试人员和业务分析人员会在开发人员的开发机器上验证代码是否满足了故事卡的业务需求，也就是进行故事卡检查（Desk Check）并且对开发人员编写的各种测试进行评审，确保测试覆盖率和测试的准确性。

当故事卡检查通过之后，测试人员就可以进行探索性测试和系统测试了。这时测试人员可以通过各种探索性测试的技巧，例如快速测试（Rapid Testing）以及基于测程（Session Based）的探索性测试等，进行系统测试。

在测试结束后，测试人员根据和业务团队的约定，马上或者定期给业务团队进行故事卡的演示（Showcase）。如果业务团队有更新的需求，也是通过测试人员反馈并创建新的故事卡的。只有业务团队接受故事卡的完成情况时，一张故事卡才算正式的完成了。

在开发机器验证和正式的测试阶段，一旦发现了缺陷，一般来说会直接把故事卡推回开发阶段中，从而使的缺陷得到快速修复。但是当测试完成后如果发现任何缺陷，都需要创建新的缺陷卡来记录和跟踪缺陷的修复情况。因为此时故事卡的开发已经结束，需要更多时间来修复相应的缺陷。

从这些优秀测试实践的介绍中可以发现测试人员全面而深入地参与到项目开发的每一个环节，成为项目中不可或缺的重要角色。

细心的读者会发现我们介绍Web测试的优秀实践，并不包含除了测试本身之外别的工作职责，例如开发流程改进和迭代发布计划管理等，其实这些职责也是测试人员可以承担并且发挥巨大作用的。

相关书籍阅读：

书名：《Web测试囧事》

ThoughtWorks测试专家联合撰写，以73个源自实战的场景化故事，揭示Bug定位、解决思路与规律，轻松、潜移默化地掌握测试技巧与原理，触类旁通。

ISBN：978-7-111-56940-4

作者：黄勇 徐潇 杨雪敏

定价：59.00元

出版时间：2017年7月