3，传统软件开发流程中的测试流程
终于开始说到测试，在面试的时候面试官经常的第一个问题是做自我介绍，第二个问题就是说下你的工作流程。这时候面试官想要了解的就是面试人自身对测试流程的理解。
你曾经做过什么项目，在项目中你是什么角色，使用过哪些工具，掌握哪些技能等等。
做过几个项目的都会有个大概的认识，但是系统的将流程说的明白说的清楚，说的让人接受，还是需要重新梳理一下的。
今天我们就简单的梳理一下软件测试流程。
按照之前我们说的软件开发流程，传统和互联网之分，我们这里也分别对传统和互联网中的测试流程进行描述。
先从传统软件开发流程来说。
1，需求讨论：测试的介入点大都是在需求分析之后，产出了需求文档，这个时候会有SA或者开发负责人来组织相关的开发和测试做需求讨论。
测试人员的标榜依据就是这个需求文档，所以这个讨论会是测试人员必须参加而且有问题必须确认的环境。
如果会议上有流程问题没有确认，测试人员也需要对问题进行跟踪和督促确认。
大部分的系统都不是孤立存在的，一个大的项目会牵涉到很多同等级的系统。就用最简单的银行借记卡之前的转账操作来说。
个人网银是前台页面，个人网银先要有查询接口，接口要调用公共的接口平台，然后去后端的核心系统调用，查询出当前账户的信息展示，
发起转账之后，前台的个人网银页面走接口平台，在去核心系统，核心系统进行判断是否内部交易，内部交易走核心处理，如果是外部交易再调用银联接口。
看到没，最简单的一个转账，后端不下于五六个系统在工作，这个例子里面的核心系统当然不是一个系统，是一个系统群。
你所负责的系统在整个流程中处于一个什么样的位置，你的前端需要什么操作，后端有什么要求，都是必须要了解的。
需求讨论会可以说了解你的系统，你也了解整个关联系统。
在多说一句，需求讨论不是SA将需求讲一遍就结束，必须要多想，多问，不懂的及时沟通。
2：测试计划：需求讨论后，一般是由测试负责人来编写测试计划。
如果是一个牵扯了多个系统的项目的话，会有一个项目的测试负责人，出一个总的测试计划，测试计划会对背景，依据，资源，策略，日程等等坐安排，
其中总的项目测试计划中时间安排是项目的时间安排，可以部分系统有差别。在保证整体项目顺畅运行的前提下是允许部分系统的时间安排与总体时间不一致的。
其实做项目的时候由于各个系统的人力安排或者时间安排不一致都会有这样的问题出现。有些是可以妥协的，有的是无法妥协的，根本的准备是保证项目的质量，在项目规定的时间内顺利的完成测试工作。
3：测试设计：测试设计主要包括测试用例编写和测试场景设计两方面。
再次的明确下，测试的依据是需求文档，而不是开发人员提供的设计文档，设计文档只是参考而已。
对于设计文档，我们在做场景设计的时候是需要参考的，设计哪些场景才能实现最大的代码覆盖，异常场景设置等。
4：环境准备和测试执行：不同的产品对环境的要求是不一样的，bs架构和cs架构，Windows，linux，更有手机软件，嵌入式软件等等。
不管测试环境是有专门的人来搭建部署，但是有一个准则，测试环境的维护是测试人员的工作。
切记不要发生了问题就去找开发，自己要尝试着去找问题，确认问题。
对于测试的执行，传统流程先是冒烟测试，然后系统测试，性能测试，最后是uat验收测试。
5：缺陷：每个公司的缺陷管理工具都是不一样的，但是缺陷流转的各环节都是相似的。
6：测试报告：我们都知道要发送系统测试完成报告，但是有一个报告是经常被忽略的，测试进度报告。
我们在测试计划中都是有设置关键时间点的，在关键时间点有没有完成计划中的工作，有没有问题对整个项目有阻碍，或者在某一个环境出现的问题较多，预估后期的问题也仍然会很多。
等等，进度报告都需要反馈出来。
我们反馈出来的主要目的是什么？
是对测试工作的反馈，是对整个项目进度的反馈，是对版本质量的反馈。
丑话说在前面，有问题需要今早的暴漏出来，不能等到测试时间结束了再来说问题。
7：上线总结：进行了一轮一轮的测试之后，已经无重要问题或者问题很少，需要进行评估上线工作。
评估时测试人员需提供测试报告，有的需要缺陷分布图，遗留缺陷等。
一般项目结束之后，需要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。
再多说一句：产品的质量并不是测试能决定的，而是整个项目构建过程中，通过一次次的优化过程，不断的总结成长，是整个项目团队决定的。
页:
[1]
