1、全程软件测试图解
传统的软件测试，可以简单描述为下图所示：
图-1-传统交付测试
开发人员完成任务之后，最后交付给测试人员，这种模式下，测试人员不能及早发现需求阶段的缺陷，同时测试工作的开展也滞后了，产品质量得不到有效的过程控制和分析，总体进度可能会由于返工问题造成拖延。
那什么是全程软件测试，如下图所示：
图-2-全程软件测试图
在整个SDLC中，三条角色主线和四个阶段。
三条角色主线：开发、QA、测试，文中主要讲解测试。
四个阶段：需求、开发、发布、日常运营。
简单来说可以归纳为下图所示：
图-3-全程软件测试概述
测试人员贯穿这四个阶段，开展测试活动，试实践活动简单描述如下图所示：
图-4-全程软件测试概述
每个阶段也有开发人员对应的活动，以及QA人员对应的活动。
对于产品而言，每次版本迭代，都会经历：需求、开发、发布，最后推向日常运营，发布阶段虚线指向的需求阶段和日常运营阶段，并不是一个终止阶段，而是不断迭代的过程。
那测试人员是如何开展全程软件测试活动的呢？
2、需求阶段测试
在需求阶段，开发人员、测试人员、QA人员主要做的事情，如下表所示：
作为测试人员的主要实践如下：
参与用户故事分析、挖掘故事含混性
在sprint会议上，对用户故事进行分析，检查功能性需求和非功能性需求是否描述清晰，其中可以将非功能性需求作为验收要点，例如一个用户故事：
“客户希望提高响应时间”
测试人员应当协助开发人员消除故事的含混性：提高什么的响应时间和响应时间为多少？可以建议修改为：
“客户信息普通查询返回结果的响应时间为5s内”
说明在“客户信息”模块，进行“普通查询”操作，返回结果的时间在5s内，这个陈述句已经清晰表达了，也达到了消除含混性的效果。同样，测试人员可以编写提高查询效率的用户故事：
“客户在信息查询模块，进行普通查询，能够在5s内返回结果”
“备注：5s为非功能性需求，也是验收要点”
参考经验库质疑开发的时间估算
在sprint会议上，开发人员根据经验出牌（团队自己定义的规则，用扑克牌）估算时间，当给出最终结果的时候，测试人员应当对其进行质疑。测试人员借鉴历史经验库：开发人员在某方面的技能如何、该模块曾经产生过何种程度的缺陷、修复缺陷的消耗时间是多少等等，综合考虑，提出疑问，让开发估算最终的时间，尽可能考虑这些因素。当然，测试人员能够质疑的其中一个前提是：测试人员具备相关开发经验。
小结：在需求阶段，测试人员要发挥作用，减少含混性需求引入到开发阶段、同时协助开发做好时间估算。
3、开发阶段测试
在开发阶段，开发人员、测试人员、QA人员主要做的事情，如下表所示：
作为测试人员的主要实践如下：
功能要点确认
Xmind是一个非常好用的脑图工具，通常在开发人员进行编码前，测试人员会针对需求处理的用户故事，与开发人员进行确认，修正理解偏差，确保需求理解一致。
图-5-脑图用例模板
测试用例设计
测试人员主要设计测试故事点，使用DSL(Domain Specific language)，infoq文章（敏捷测试之借力DSL），对测试用例进行描述，包括三个基本要素：
Feature、Scenario、Example，补充要素：xmind、Requirement。
Feature：把测试分类到某个模块，并对这个特性本身的业务目的进行相关描述，带进业 务目标，传递业务知识。
Scenario：标明这个Feature的测试场景，可以使用文字描述步骤，或者使用xmind脑图
描述，场景中的数据使用Examples中列出的。
Example：引出具体的数据表格把用到的数据都展示出来，避免相同步骤因为测试数据 的变化而重复若干遍造成冗余。
Xmind：脑图文件，展示测试故事点
Requirement：关联需求管理系统的需求id。
用例评审
主要是坚持同行评审的原则，主要在测试组内进行，负责该任务的开发人员也会参与，简单来说就是对测试用例进行查漏补缺的工作。
测试探索
进行了“功能要点确认”和“用例评审”后，为了保证测试场景的覆盖率，需要再进行测试探索。在开发人员完成雏形之后，使用探索式测试的策略，对功能基本流程进行有目的的快速走查，挖掘功能不确定的地方和补充测试场景，避免不确定的因素拖延到开发阶段后期，造成返工。
燃尽图发布
另外，测试人员还有一项重要工作，每日发布燃尽图，让团队了解当前进度情况，总结问题
所在，寻求耗时超过预期时间任务的解决办法。
图-6-燃尽图
图形特点：
1）剩余工时在计划基准上方，代表进度有所延迟，应抓紧进度；
发现此类问题，需要分析总结，原则是保证交付时间，对相应任务进行调整，拥抱变化，发现任务粒度太大，该拆分的继续拆分；对于重构需要慎重，不要过度深入重构，给测试带来额外工作量，影响整个进度，对于整个版本而言，只有开发、测试在承诺的时间内完成任务，才是真正完成，仅仅开发完成交付算不上成功。
2）剩余工时在计划基准接近，代表进展良好，继续保持；
此时也需要查看在这种进度下，优先级高的任务是否得到时间保证，而不是因为处理完简单任务才使得燃尽图长的好看。往往有些开发人员，喜欢挑着任务来做，把简单易做、优先级的任务先完成了，因为这些总在预期内能够完成，所以前期燃尽图的趋势看起来没有问题。
缺陷经验库
每个团队都存在开发/测试新人和开发/测试老人，当测试人员与开发新人进行需求确认的时候，还需要进行缺陷经验教训的提醒，避免多走弯路。
图-7-缺陷总结
提升开发自测质量
测试人员可以提供相关checklist（大家可以根据原作者提供的修改为符合团队的）帮助开发人员在编码过程中关注开发自测的要点，从而提升质量。
图-8-web软件测试checklist
