软件测试流程

1;需求分析阶段：根据需求规格说明书，分析需求点。
2，测试计划阶段，测试组长根据项目整体计划制定“测试计划”，其中包括测试对象，范围，目标，进度计划，人员计划，软硬件资源，测试指标和风险识别等内容。
3，测试计划评审：由项目经理，测试经理，同级别测试，开发工程师等组成评审组对测试计划进行评审。
 4.测试设计阶段：一般由测试工程师根据需求分析，整理出测试大纲、再由测试大纲编写具体测试用例。用例按业务、功能、UI等不同类型编写。用例包括：用例编号，场景、模块、前置条件、用例描述、操作步骤和预期结果
5.测试用例评审：由测试负责人、同级别测试、相关业务开发工程师等组成评审组对测试用例进行评审。
6.测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报、周报等描述测试执行情况的相关文档。一般为迭代执行。
7.测试总结：系统测试完成后，根据测试计划、及完成情况，统计用例、bug及其修改情况，对系统及测试情况进行总结。

测试计划编写规范
1.测试范围
2.测试目标
3.测试策略
4.测试估计
5.风险管理

软件测试风险识别

软件测试的风险识别
风险	可行性	潜在的影响	严重程度	预防/处理措施
对需求的理解偏差太大、原因是缺乏原型、与客户沟通不足，需求评审不到位	中	对Bug、设计的合理性等确认困难	严重	与用户、产品经理多沟通、并借助一些原型和演示版本来改进
测试工程师对业务不熟悉，主要原因是业务领域新、测试人员是新人或介入项目太迟	低	测试数据准备不足、不充分 测不到关键点，同时测试效率难以提高		测试人员及早介入项目，与产品经理，  市场、设计等各类开发人员沟通，加强 培训，建立伙伴、师傅带徒弟的关系
由于项目提交日期的变更导致测试周期变更，一般是由客户提出的	低	系统测试总时间缩短，难以保证测试的质量	非常严重	严格控制项目的时间变更，多与客户 沟通并得到客户的理解。调整测试 策略、测试资源及计划
软件需求不清楚、变更导致测试需求及范围发生了变化	高	导致测试计划、工作量等发生变化	较严重	和用户充分沟通、做好调研、需求获取和分析，调整测试策略和计划
开发进度延长，包括项目计划的变更、各个环节的进度拖延	中	推迟系统测试执行	严重	设定更多的子里程碑，控制整体进度，做好沟通和协调
由于设计时间不足、代码互审和单元测试不够，导致开发代码质量低	中	BUG太多、严重，反复测试的次数和工作量大	严重	做好软件设计、提高编码人员的编码水平、进行单元测试。严格控制提交测试的版本、调整整体测试策略和计划

测试大纲设计原则
明确需求（这也是整个测试工作的原则）；
测试设计的框架与灵魂；
测试人员真正理解待测功能与业务，并能体现出测试人员的测试思路；
结果层次清晰；
覆盖面全；
用于功能测试设计

测试大纲设计方法：
按模块划分大纲；
按功能点划分大纲；
按菜单划分大纲；
按业务逻辑划分大纲；

 

测试大纲设计的常见问题
没有按照需求进行设计；
照搬客户需求，缺少测试人员的理解分析；
测试大纲节点命名含糊；
混用多种大纲划分方法；
大纲中出现多种测试类型；
大纲级别划分过粗或过细；

转载于：http://blog.sina.com.cn/s/blog_5e1d032e0102vx5o.html