全面的软件测试-软件测试图解

1 全过程的软件测试图解

传统的软件测试，开发人员完成任务之后，最后交付给测试人员，这种模式下，测试人员不能及早发现需求阶段的缺陷，同时测试工作的开展也滞后了，产品质量得不到有效的过程控制和分析，总体进度可能会由于返工问题造成拖延。

什么是全程软件测试，也可以说全面的软件测试，如下图所示：

在整个SDLC中，三条角色主线和四个阶段。

三条角色主线：开发、QA、测试，文中主要讲解测试。

四个阶段：需求、开发、发布、日常运营。

简单来说可以归纳为下图所示：

测试人员贯穿这四个阶段，开展测试活动，试实践活动简单描述如下图所示：

每个阶段也有开发人员对应的活动，以及QA人员对应的活动。

对于产品而言，每次版本迭代，都会经历：需求、开发、发布，最后推向日常运营，发布阶段虚线指向的需求阶段和日常运营阶段，并不是一个终止阶段，而是不断迭代的过程。

那测试人员是如何开展全程软件测试活动的呢？

2 需求阶段测试

在需求阶段，开发人员、测试人员、QA人员主要做的事情，如下表所示：

阶段	开发人员	测试人员	QA人员
需求阶段	· 用户故事分析 · 用户故事估时	· 参与用户故事分析、挖掘故事含混性 · 参考经验库质疑开发的时间估算	· 保证确认需求活动符合需求管理过程 · 管理用户故事评审 · 管理需求变更

作为测试人员的主要实践如下：

参与用户故事分析、挖掘故事含混性

在sprint会议上，对用户故事进行分析，检查功能性需求和非功能性需求是否描述清晰，其中可以将非功能性需求作为验收要点，例如一个用户故事：

“客户希望提高响应时间”

测试人员应当协助开发人员消除故事的含混性：提高什么的响应时间和响应时间为多少？可以建议修改为：

“客户信息普通查询返回结果的响应时间为5s内”

说明在“客户信息”模块，进行“普通查询”操作，返回结果的时间在5s内，这个陈述句已经清晰表达了，也达到了消除含混性的效果。同样，测试人员可以编写提高查询效率的用户故事：

“客户在信息查询模块，进行普通查询，能够在5s内返回结果”

“备注：5s为非功能性需求，也是验收要点”

参考经验库质疑开发的时间估算

在sprint会议上，开发人员根据经验出牌（团队自己定义的规则，用扑克牌）估算时间，当给出最终结果的时候，测试人员应当对其进行质疑。测试人员借鉴历史经验库：开发人员在某方面的技能如何、该模块曾经产生过何种程度的缺陷、修复缺陷的消耗时间是多少等等，综合考虑，提出疑问，让开发估算最终的时间，尽可能考虑这些因素。当然，测试人员能够质疑的其中一个前提是：测试人员具备相关开发经验。

小结：在需求阶段，测试人员要发挥作用，减少含混性需求引入到开发阶段、同时协助开发做好时间估算。

3 开发阶段测试

在开发阶段，开发人员、测试人员、QA人员主要做的事情，如下表所示：

阶段	开发人员	测试人员	QA人员
需求阶段	· 用户故事分析 · 用户故事估时	· 参与用户故事分析、挖掘故事含混性 · 参考经验库质疑开发的时间估算	· 保证确认需求活动符合需求管理过程 · 管理用户故事评审 · 管理需求变更

作为测试人员的主要实践如下：

功能要点确认

Xmind是一个非常好用的脑图工具，通常在开发人员进行编码前，测试人员会针对需求处理的用户故事，与开发人员进行确认，修正理解偏差，确保需求理解一致。

图-5-脑图用例模板

测试用例设计

测试人员主要设计测试故事点，使用DSL(Domain Specific language)，对测试用例进行描述，包括三个基本要素：

Feature、Scenario、Example，补充要素：xmind、Requirement。

Feature：把测试分类到某个模块，并对这个特性本身的业务目的进行相关描述，带进业 务目标，传递业务知识。

Scenario：标明这个Feature的测试场景，可以使用文字描述步骤，或者使用xmind脑图

描述，场景中的数据使用Examples中列出的。

Example：引出具体的数据表格把用到的数据都展示出来，避免相同步骤因为测试数据 的变化而重复若干遍造成冗余。

Xmind：脑图文件，展示测试故事点

Requirement：关联需求管理系统的需求id。

随着敏捷越来越广为人知，敏捷测试也更多受到了大家的关注。在这里，我想谈一下我在敏捷项目中遇到的一个自动化测试相关问题以及我们如何借助DSL领域专用语言来解决它。

对敏捷软件开发方法有一定了解的人都知道，敏捷软件开发过程是一个迭代式交付的过程。每个迭代相当于比较小型的交付周期。那么，为了配合频繁的软件交付&#