全程软件测试实践：从需求到运营

　　1 全程软件测试图解

　　传统的软件测试，可以简单描述为下图所示：

　　图-1-传统交付测试

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

　　那什么是全程软件测试，如下图所示：

　　(点击图像放大)

　　图-2-全程软件测试图

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

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

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

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

　　图-3-全程软件测试概述

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

　　(点击图像放大)

　　图-4-全程软件测试概述

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

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

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

　　2 需求阶段测试

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

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

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

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

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

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

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

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

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

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

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

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

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

　　3 开发阶段测试

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

原文转自：http://www.infoq.com/cn/articles/whole-software-testing-practice-requirements-to-operational