测试规划篇-001测试工作目录
上一篇 /
下一篇 2014-11-21 12:53:23 / 天气: 晴朗
/ 心情: 平静
/ 精华(3)
/ 置顶(3)
/ 个人分类：职业感悟
最近
测试管理比较混乱，一方面也来了新人，所以要进行统一的安排，针对之前的混乱
流程，重新进行了梳理，规划了测试的目录结构（相当于测试的执行流程）请大家参考，并进行拍砖。虽然目前迭代持续集成比较火，但是干活还是要靠人一步步来，一个流程固然重要，一个团队才是重中之重。如下所示：欢迎提供宝贵建议：
| 一级测试目录 | 二级测试目录 | 流程规约 |
| 需求管理 | 需求规格说明书 | 需求是最重要的部分需要确定各个细节，根据80/20原则,高校沟通，责任人 |
| 概要设计说明书 |
| 详细设计说明书 |
| 参考文档 |
| 测试方案 | 测试方案 | 明确责任人，并与需求，开发进行方案评审，坚守80/20原则 |
| 测试计划 | 测试计划 | 明确责任人，并与需求，开发进行评审，坚守80/20原则,合理规划工时，系统环境的冗余，异常情况梳理 |
| 测试用例 | 测试用例（需求树，测试用例，用例覆盖率分析报告，用例评审记录单） | 明确责任人，并与需求，开发进行评审，建立一条主线，保证用例的覆盖率和可测试性 |
| 测试dashboard | dashboard | 保证测试的高效，保证测试人员明确测试目标 |
| 测试环境list |
| 持续集成CI | 持续集成环境+每日构建报告 | 保证代码质量，降低测试返工率 |
| 测试执行 | 冒烟测试 | 保证测试的迭代性，使用工具简化和保证质量 |
| 自动化测试 |
| 功能测试 |
| 性能测试 |
| 回归测试 |
| 测试报告 | 测试报告 | 真实有效 |
| 测试分析 |
| bug报告 |
| 测试总结 | 测试总结 | 保证交付 |
| 后期维护 | 维护手册 | 明确交付物 |
--------hello----act as the delimiter--------
| 解释说明 | 方案 |
| 需求评审、需求理解（其中需求要设定严格的版本控制，严格的sign-off，类似redhat的vault，需求，开发，测试都需要sign-off，但是不可增加不必要的沟通成本。 | 如何保证需求理解？明确客户需求，sign-off，《需求考试》，《需求反馈记录单》，需求成为反馈环的一环，并且快速书写用例大纲 |
|
|
|
描述需要测试的特性（性能，安全，冒烟等）、测试的方法、测试环境的规划、
测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案 | 如何保证测试方案质量？《方案实施反馈单》，成为反馈环的一环 |
| 对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理 | 如何保证测试计划质量？《人员+环境评估文档》 |
首先在用例之前产生需求树或者有相应的azxure，根据这两项设计测试用例，其次编写对应的测试用例，编写完成后要进行阶段性评审。
需求树
测试用例
用例覆盖率分析报告
用例评审记录单 | 如何保证测试用例覆盖率？《工具反向检测》从需求树到测试用例plan |
| 测试过程中需要用到的一些list，比如我测试的当前项目，测试的版本，地址的工程路径，测试的日志路径，测试的环境，测试dashboard，测试环境list，测试常用工具分析链接，测试需求参考连接 | 如何保证测试快速：不断更新dashboard |
|
针对工程特点，接入持续集成，从开发提交代码就进行检测测试，到完成一个版本后进行开发的集成测试，再到测试的数据库初始化，到自动打包，部署，最后到测试的冒烟测试，自动化测试性能，安全等测试的持续集成反馈
每日构建报告
持续集成环境 | 保证ci环境的完善，并记录开发的db，配置变更 |
进行一系列的测试工作
冒烟测试，功能测试，自动化测试，性能测试，安全测试，易用性测试，回归测试
测试覆盖率分析
测试问题反馈分析
测试bug分布分析
持续集成报告分析
燃尽图分析
等 | 快速生成分析测试覆盖报告，测试结果报告，反馈环的一环 |
|
|
|
|
里程碑或者交付时产生的完整报告
1.bug报告
2.用例执行报告
3.测试分析报告
4.功能测试，性能测试，安全，易用性等报告
等
| 根据报告，进行改进 |
|
|
总结工作：测试了哪些功能，执行了多少用例；
评价软件质量：提出多少bug，修复了多少；
项目总结：是否通过； | 总结测试整体情况 |
根据项目不同的产出
1.用户手册
2.回归功能点
3.部署报告 | 明确客户的要求 |
收藏
举报
TAG:
流程
测试
管理
