【编者按】软件测试是软件产品开发过程中质量控制的重要一环。本文作者刘丽晶，系未名信息技术公司的软件测试主管，曾在中软件国际、招商局国际等大公司担任软件测试工作有五年之久，积累了丰富的专业知识与技能，现将多年从事软件测试工作的实践与体会，陆续汇总出《刘丽晶谈软件测试》的系列文章。

今天发表了第三篇文章《测试总结之我知（流程篇）--“刘丽晶谈软件测试”系列文章之三》，邓宗煌总经理说：“原本写给测试新人学习的基础知识。但是，小刘总结的实战内容（特别是其中的一些实际案例）对于开发人员和需求人员来时，也会有所启发的。”

 

测试总结之我知（流程篇）

刘丽晶

 

在产品研发的项目管理中，成本、进度、质量是项目控制非常重要的三个因素，而其中的质量控制包括测试、评审、质量保证（QA）等若干环节。产品测试是国内众多软件公司研发部门很头疼的环节，如何通过测试保证产品质量，是许多项目负责人（或研发总监）面临的困惑。

华为轮值CEO徐直军如是说：“7万多人的研发队伍，还能有序地开展工作，这是我们1998年跟IBM开始的产品开发变革的贡献，我们叫IPD(集成产品开发)。我们从1998年开始到现在不断在优化研发流程，不断在优化组织，不断在提升研发能力，从来没有停过。……  从一个创意到走向产品，整个的管理体系、流程、工具、能力提升，这个过程华为没有停止过。现在不管有多少人，别说7万人，再加7万人，我们管理也没有问题，能够有序地运作，确保把产品做出来，而且做出来的产品是稳定的、达到质量要求，这是我们这么多年管理体系和研发流程优化的结果。”测试是产品开发过程中必不可少的环节，据说在华为的研发人员中，有近三分之一的人员是测试人员。在整个研发流程中，测试的重要性可想而知。

从测试的角度看，现阶段由于我们的项目管理不严谨或一些流程缺失，导致在产品研发过程中会时不时出现一些不可预知、不可控的情景。比如，由于没有制定详细的测试计划，就不晓得开发什么时候会有新版本发布到测试，同时也不明确需要用多久的时间才能完成测试任务，有时只能凭感觉做事。

接下来，以我做过的某个项目的敏捷测试流程为参照，对目前我们正在执行的测试流程中可能缺少的步骤和存在的问题做简单的探讨。

项目前期

在项目前期（即迭代开始之前）由需求人员调研、整理出初步的需求文档，项目主要负责人参与讨论，输出产品功能需求文档。项目的测试负责人需要参与制定整体的测试策略与测试计划。测试计划制定的输入，主要依据项目开发计划与整体的测试策略。在此阶段，项目经理需要输出项目开发计划，明确迭代开发过程、开发周期等信息。

迭代阶段

在此阶段，需求人员（或产品经理）需要集合开发人员与测试人员进行每个迭代周期的需求讲解，有必要时可先进行需求评审。当项目组成员对需求特性均了解清楚后，测试负责人开始制定详细的测试计划、特性验收标准设计、测试用例设计。待迭代版本转测试后，测试人员开始执行测试、提交缺陷。在当前迭代测试结束后、下一个迭代开始之前，由测试人员对当前迭代发现的问题进行缺陷分析，及时补充测试策略，并落实到下一个迭代中。每个迭代结束后，进行迭代总结回顾。上述过程一直持续到所有迭代结束。

SDV阶段（System Design Verify）

即为系统设计验证阶段。测试主要完成功能用例全覆盖，即详细的功能测试。同样的，在此阶段，也要开展缺陷分析等持续性过程改进活动。根据项目进展情况，此阶段一般需要进行至少两轮测试。在该阶段结束时，由测试负责人输出SDV测试报告，并开展阶段性总结回顾。

SIT阶段（System Integration Test）

即为系统集成测试阶段。测试主要完成非功能性方面的测试工作。比如，兼容性、安全性、可靠性、性能等。同样的，在此阶段，也要开展缺陷分析等持续性过程改进活动。在该阶段结束时，由性能测试负责人输出SIT测试报告，并开展阶段性总结回顾。

SVT阶段（System Verification Test）

即为维护阶段。在产品发布上线后，主要针对上线后反馈回来的问题，开展漏测分析、专项测试及补充测试（针对前期测试不足的部分）。最后，由测试负责人输出SVT测试报告。

至此，完成整个软件产品的生命周期测试工作。

针对公司目前的发展阶段，如果实施上述的完整、严谨的测试流程，可能会存在以下问题：

1.        目前测试人手不足，在新的人员到位之前，我自己都要亲自参与物流管家、金鹏物流交易大厅、高速物流信息系统三个项目的所有测试，在三个项目中来回跳转测试，基本没有多余的时间做详细的测试计划、用例设计等。目前我采取的临时应急办法是，一个版本测试完成后，利用空余的时间，才会尽量补充测试计划或测试用例等。当开发版本转测试后，测试人员都是直接根据需求文档与测试经验来主观测试，测试的质量完全依赖测试人员的个人水平，漏测风险极大。

建议：正常情况下，测试负责人在需求确认后就应介入，做好前期的测试准备，根据项目的开发计划，做好整体的测试计划，开展用例设计、用例评审工作。测试人员需要适时提升自身的测试技能，善于分析bug，总结经常出现问题的模块和类型，投入更多时间测试。

2.        缺少需求评审，对每个需求点，项目组成员可能没有做到心里都有数。在需求文档确认后，上传到SVN上，项目组成员基本没有提前去熟悉文档，测试人员只有在测试的过程中，发现当前的系统实现与需求有出入时才会去作确认，有时可能就会出现整个功能模块返工的情况。如金鹏物流交易大厅项目，产品经理告知我，司机模块已开发完成、可以测试，结果当我拿到那个版本时，已经是半个月后的事了。查找一下原因，原来是开发人员没有详细阅读需求文档，基本根据自己的想法进行开发，当产品经理进行初步验证时，发现实际实现的功能与需求描述的不一样时，只能整体返工了。

3.        需求人员自身摇摆不定，当测试时发现需求文档描述与系统实现有出入时，找需求人员确认，需求人员权衡后很多时候会确认就按现在的开发去实现。如果测试前期已准备了测试用例，那么一部分测试用例瞬间就变成无效了。如金鹏物流交易大厅项目，系统管理模块，关于角色的实现，需求描述角色隶属部门。但开发实现为角色不归属部门，可自由分配，于是我当时正在设计的一些用例就没有任何参考价值了，感觉之前做了无用功，此项任务就搁置下来了。

建议：如果现阶段需求还处于摸索状态，没法完全定版，简单功能就不设计测试用例，测试用例的颗粒度可大一些，重点放在设计业务逻辑部分功能的测试用例。

4.        现阶段研发部门对开发计划的整体进度把控不严，开发进度拖延时有发生。一旦出现稍微不可控的现象，开发的模块就基本没法在预定的时间发布，导致即使已制定了测试计划，其实际的参考意义也不大。如金鹏物流交易大厅，原定开发计划中，席位管理模块完成时间是9月18日，而实际上这个模块转测试的时间为9月28日，严重影响了测试人员介入测试的时间。如果整个项目的进度计划保持不变，实际上就要压缩测试时间，导致的后果会是大大提升了项目的质量风险。

建议：可制定一个合理的项目管控流程，项目负责人应实时监控项目的进度。当项目的进度出现滞后时，应及时分析原因，适时做出调整，避免拖延过多，确保后续工作尽可能的不受影响。

5.        多个项目的测试时间重叠在一起，如金鹏物流交易大厅项目计划要求十月底完成测试，发布第一个版本；高速物流信息系统项目计划同样是要求十月底完成测试。两个都是新项目，目前都在开发阶段，如何合理分配两个项目的测试时间，就需要有个可行的测试计划。

6.        缺少相关的专项测试，如兼容性、安全性、可靠性等。要开展这些专项测试，则需要投入更多的时间、人力，测试人员配备必须适当增加。

以上为我加入公司几个月来所看到的测试环节的一些问题及改进建议。公司还在处在创业阶段，像大公司那样实施完整、严谨的测试流程目前条件还不成熟，但至少经过这几个月，我们产品研发的项目管理的基本流程正在一步步改进之中，以最初参与的物流管家为例，我们已逐步建立了SVN库、缺陷管理系统、版本发布计划等等，项目管理的主流程已较为清晰明确、也更加规范，虽任重道远，但进步是明显的。

 

2014年9月30日