软件测试流程

笔者的第一家公司，公司的第一个测试。做第一是美好的，同时也是孤独的，公司是创业公司，有自主的Web产品，笔者介入测试时，产品已经上线了，处于持续改进的状态，不定期发布新需求。

下面是新需求的测试流程：

● 需求分析

新需求获取有两方面，一是客服销售，直接从用户方调研；二是公司经理，他具有敏锐的商业洞察力，同时担任产品的角色，新需求抛出后会由大家一起进行评审。

● 功能设计

评审通过后，由技术老大进行架构设计，分解功能清单，并分配相应任务给对应的UI、开发、测试。老大是多年开发的牛人，亲和力强，感觉什么都会。

● 开发

功能的具体实现(php+mysql+apache)，由开发人员编码并调试。笔者此时根据功能清单在禅道中设计测试用例，没有详细的文档，只能大概描述业务逻辑。

● 测试

开发人员调试通过后，SVN提交代码，并部署至测试环境，笔者执行测试，发现的Bug记录在禅道中并通知相应开发人员，修复后再进行回归验证。后来发现缺少规格说明和需求模糊，只能根据实际开发功能测试，也就是说用例的实际意义不大，基本需要重新设计。

● 部署上线

回归测试通过后，提交版本，并由项目经理部署上线。期间用户反馈的问题，再由笔者跟踪修复。

总结分析：

1，可以看出这是很简单的测试流程，重在沟通，往往能很快的修复Bug。

2，整个需求的开发周期要求很短，同时也得负责android和ios端的测试，笔者往往来不及完成系统测试，回归测试也只能选择主要的业务验证，所以每次上线都有很大风险。

3，对应的文档也显得可有可无，没有规范，测试往往显得力不从心。

4，后来笔者分析测试要点并收集典型的测试用例，久了就会有测试思路，测试时也算对产品建立起了一点信心。

---

笔者的第二家公司，有独立的测试部，不是一个人摸索奋斗了，所以看到师兄师姐，总觉得有股亲切感，这与上家单枪匹马不同，在这里有了更清晰的测试流程。测试人员是根据项目分配的，所以流动性很大。

下面是笔者所处项目的测试流程：

● 需求分析

因为是外包项目，所以需求来源就是乙方公司，由产品和业务人员产出。笔者是由项目支撑的角色进入的，但是需求已经确认了，据说因平台较大，需求写了近一年，分几期开发。

● 需求评审

不同于上家公司，需求评审前会发给参会人员，以便有足够时间分析准备，并且需求会进行几次评审，下次评审会解决上次的需求疑问，直到各方对方案无异议。笔者对需求检查主要针对业务逻辑，是否有定义模糊、需求重复、需求冲突的地方等。

● 设计阶段

此阶段在需求评审完后进行的，项目经理进行架构设计、产品完善需求进行原型开发、测试经理编写测试计划等。及时沟通并组织会议，开发根据进行功能模块的程序编码，测试根据原型以及需求负责用例的编写。

● 执行阶段

在开发人员的编码完成后，由乙方项目经理进行代码审查，部分重要的功能模块由测试经理负责单元测试。完成后，进入集成测试阶段 ，测试组长分配测试任务，和详细的计划目标。从功能测试到可用性测试，再到兼容性测试，安全性测试，最后进行初步的性能测试。

● 验收阶段

在正式的验收测试前，经历了三轮系统测试，期间优化测试用例与追踪问题，在测试退出准则下，笔者测试退出。由乙方公司组织开展验收测试，邀请平台用户进行beta测试，同时引入第三方测试团队，主要负责性能测试。笔者此时准备测试报告、操作文档、功能清单等，之外也会追踪他们发现的其他问题，压力很大啊。

● 上线阶段

验收测试通过后，部署到生产环境，因为是新老平台切换，需要进行数据迁移，笔者在时，这块是重点关注的，进行过埋点数据的验证，还做过多次上线演练。生产环境由乙方运营人员熟悉系统后，再对接切换老平台，上线试运行。

总结分析：

1，此测试流程比上一个描述的更清晰，有了明显的计划目标，测试过程更有信心。

2，相关文档详细，便于业务理解，对缺陷的确认，与开发产生分歧时提供了依据。

3，笔者花了很多时间写测试用例，包括后期完善，它能反映一个人的测试思路，也体现了我们测试的工作。

4，开发提供了相关接口进行集成测试，测试数据的准备，对笔者SQL语言有很大的提高。

5，该测试过程本质还是线性模型，对于需求的变化不够灵活。后期因国家政策，部分需求更新，加上团队没有实现自动化，所以测试工作量很大。国内开发模式大多数是基于RUP统一过程的，而更轻量级的敏捷开发过程还有待我们去实践。