一、对开发人员的建议：
- 控制版本/补丁发布频率（重要）
a) 版本交付间隔保证在2个工作日以上，尽量避免出现版本/补丁频繁交付导致的测试不充分。
b) 控制版本补丁数量，原则上除紧急补丁外，多个补丁合并发送。这样可以让测试人员对交付版本提供一个更准确的质量状况。
- 版本能按计划交付（重要）
a) 根据青铜器上填写的版本交付计划或者约定的交付日期进行版本交付。
- 明确每个版本的送测内容（重要）
a) 含故障单、缺陷编号、具体功能修改等，避免出现模糊描述：如修改了用户管理模块--应描述修改的具体内容。
b) 补丁包也要有送测说明
c) SVN上注释要标清楚，如改动的模块
- 研发必须进行单元测试（重要）
a) 确保交付版本冒烟通过，冒烟测试用例由测试人员提供。
b) 配合必要的代码漏洞扫描工具，APPScan，findbugs
c) 在项目特别紧张的情况下，我个人看法是开发和测试坐到一起，发现问题立刻修改，不需要录入青铜器，开发人员若没有时间可以不用自测，减少中间环节。
- 填写版本发布文档和安装部署说明（一般）
a) 安装部署手册由开发（还是测试？）人员编写。安装部署说明也列入测试检查范围，避免工程部后续部署工作不顺畅。
- 缺陷处理要求
a) 根据bug紧急重要程度优先解决
b) 缺陷是否修改存在争议时，先跟测试沟通，若无法达成一致，再由指定的仲裁人（）决定。
c) 共通类和影响范围比较大的bug，建议跟测试人员一起沟通，减少修改不全面的情况。
d) 版本发布时，确保本次修改的bug在青铜器上已修改状态，这样测试人员可以根据提交回归的时间和状态来迅速定位交付版本需要回归的缺陷。
e) 测试人员定期汇报项目bug状态，原则上每周五汇报，模板如下：
| 项目名称XXX |
创建审核 |
修改中 |
回归测试中 |
关闭 |
| 致命 |
|
|
|
|
| 严重 |
|
|
|
|
| 一般 |
|
|
|
|
| 轻微 |
|
|
|
|
| 合计 |
|
|
|
- 数据库变更
a) 进入系统测试阶段，数据库结构更改用sql脚本
- 版本上线标准：
- 需求→设计→代码能够一致。
a) 以便于测试能够在测试的同时识别可能存在的功能遗漏。
- 业务需求（变更）传递要基于文字
a) 不接受单个人口头的业务传递，所有业务必须有相应的文字作为支撑。
b) 针对需求变更和互联网缴费这类项目：开发跟测试员梳理完需求后，测试人员把自己的理解和测试点（风险）进行整理，发送项目团队确认。
二、对测试人员的要求：
- 测试人员定期（如每个月)统计开发人员工作表现、发送项目经理
- Bug描述：
a) 提交BUG要描述清楚。注明操作步骤、测试环境、描述清楚正常现象和BUG现象的差异。
b) 某个问题若在多个页面发现，提交到一个问题里，并在问题描述中把对应页面描述清楚；
c) 尽量避免提出重复BUG，两个不同页面的相同问题应归为一个BUG的两次出现。更深层面的相同BUG原因，可以多和工程师沟通了解；
d) BUG级别严格按照最新标准执行；
e) 尝试对bu*生的根源作分析；
f) 如果出现了某个bug修改不完整的情况，不要急于驳回，先沟通！
g) 程序员比较忌讳时间碎片化，尊重程序员的工作方式，不要一发现问题就找程序员，编码过程中思路被打断对程序员来说是很痛苦的事情。可以收集多个问题后统一找程序员处理，或是在即时通讯工具上留言，看程序员的时间安排，给他几分钟时间缓冲，在其方便的时候沟通；
h) 程序员很怕“一般BUG”和“重开”。设“一般”和设置“重开”时慎重一些，不确定的可以先和程序员沟通过再提。
i) 多和程序员沟通，了解开发思路。了解开发思路能够帮助测试人员找到测试步骤的盲点，更容易测出真正的问题。这样的沟通，也会帮助开发人员检验开发思路的正确性，更好的提高项目团队的效率。
- 系统测试日报：
j) 测试报告包括《每日测试报告》、《阶段性测试报告》和《版本测试报告》
k) 原则上有测试任务时，每天汇报《每日测试报告》，汇报bug状态；
l) 原则上每个大版本出具《版本测试报告》，短期内连续发布多个小版本的情况可以出具《阶段性测试报告》， 这个报告侧重于多个版本的质量趋势。
(0 0)
+------oOO---(_)------------+
| |
| 『欢迎关注』 |
| 张老师的小黑屋 |
+--------------------oOO-----+
|__|__|
|| ||
ooO Ooo