学编程前博主是做测试的，当初在测试部作为一个小官还写了不少流程呢，今天突然翻到来跟大家分享一下测试流程（之测试内部流程）

··· 这个测试内部流程写于2010年6月，那个时候刚从大公司出来进了一个小公司。待惯大公司的人再去小公司真的不习惯，大公司分工分明，流程清晰；小公司就不一样了，什么都不明确，逮着什么干什么，逮着着谁就干什么，实在是没法忍。后来我就给老板提议，咱们老板顺手就把这个工作交给我了。

内容比较多哦，包含：测试流程、bug提交及验证流程、测试报告格式、测试用例完善流程等，都是博主当初一个字一个字码出来的。当然这个流程和制度只是针对当时那个公司哈，有需要的可以借鉴。
（备注：里面的TD是bug管理工具）

测试内部流程和制度

1. 关于测试流程大家要注意的:
   (1) 测试部门要参加需求的讨论,了解需求并提出自己不懂的地方和改善意见.
   (2) 拿到正式的需求后, 测试相关人员会和产品经理讨论需求.了解需求以后,测试部门会开内部会议讨论需求,并制定测试计划.测试计划包括:确定测试范围和各个功能点,以及容易忽略和遗漏的地方;测试资源的分配,团队的成员各自承担什么任务;测试策略,需要用到哪些测试类型,测试方法和工具;测试周期的排配;风险评估.
   (3) 对必要的测试用例,测试环境和测试物料要提前做好准备.测试用例编写完成后至少要进行内部评审.在测试2-3个软件版本后对测试用例进行再次评审和修订.测试人员在测试过程中遇到漏掉的测试项可以随时提交给测试经理来补充测试用例.
   (4) 正式测试版本是从产品经理或者测试经理这边拿到的,不能直接通过开发人员拿到. 测试人员不要帮开发做一些他们需要内部测试的版本.且正式发布的版本如果没有邮件通知过开发经理,产品经理和测试经理的,请测试部门的人员不要进行测试.
   (5) 在测试周期内,发现bug,直接提交到TD.你可知会开发人员你提交了某某bug,让他能及时修正. 在测试过程中若出现以下2种情况任意一种的,请停止测试:
   A.发现3个或者3个以上的high类bug,提交bug同时停止测试.让开发那边重新调试.
   B.发现5个或者5个以上的medium类bug,提交bug同时停止测试.让开发那边重新调试,出新版本.
   如没有以上情况按照我们正常的周期跑.测试完了提交测试报告.
   (6) 拿到一版新软件,测试先后顺序:
   A.验证软件新增加功能模块和优化功能
   B.验证开发反馈已经fix了的bug
   C.跑测试用例(一边跑,可以一边更新TD上处于Open/Reopen/New状态的bug)
   D.更新TD上剩余的处于Open/Reopen/New状态的bug(1.包括一些没有做修改的模块的bug;2.对于需求性问题,没有fix的可以不用更新)
   (7) 在测试周期内,若测试由于某种原因要停止(如以上提到的(5)里的2种情况的任意一种,或者是测试机型出故障,测试环境不到位的), 请及时通知测试经理,好让测试经理这边了解测试状况及时做出应对.
   (8) 测试周期结束当天的下班前提交测试报告, 先提交给测试经理, 测试经理会做一些检查,然后转发给产品经理和开发人员.
   (9) 测试报告的格式:
   A. 测试结果的总结: 总共多少个测试项,pass的有多少,fail的有多少各占的比例.
   在每个模块出现的bug有多少. 在发最后的总结性报告时附上测试项的整体统计表.
   B. 分细项分别列出: 每个bug请带上相应的TD号和严重等级.
   a. 开发确认fix且在TD上已close了的 bug
   b. Reopen的bug
   c. 新发现的bug
   d. 做测试总结(对严重程度是High和Medium的bug进行分析和说明)
   e. 附件附上测试报告(Excel文档的报告)
   C. 附上bug的收敛率的图表(直接可以从TD上导出)
   (10) 测试这边发测试报告时,写邮件要注意的: (测试报告包括每天的测试报告和最后总结性的测试报告)
   A.不要在开发人员发布版本时的邮件上直接回复,需要另外重新写一份新的邮件.(这个主要是为了避免重复回复,主标题已经不是目前我们测试报告所要表达的主题,这样不能引起相关部门的注意)这个是针对测试报告,其他邮件需要直接回复的,可以不用重新写一份新的邮件.
   B.测试报告发送的人员,测试人员直接发送给测试经理,不用发送或抄送给其他人.经过测试经理确认后,测试经理会把测试报告发送给相关的开发人员和产品经理,抄送给开发经理和测试人员.
   C.邮件主题的描述: 每天的测试报告主题—拿柳丁来电4.6.0来说.”柳丁来电4.6.0for Symbian+(开发给的小版本号)测试报告-----2011xxxx(当天发报告的日期)”; 最后总结性的测试报告主题—拿柳丁来电4.6.0来说.”柳丁来电4.6.0for Symbian+(开发给的小版本号)总结性测试报告”

2. 关于Bug的提交和更新要注意的:
   (1) 提交bug时, 以下几项都必须填写清楚, 以便做bug分析. Detected in Version, Project,Priority,Reproducible,Type,Severity,Module,feedback times.( Priority和Severity,请参考bug判断标准; Reproducible有3个选项:Y能复现,N不能复现,U是我们这边没有的机型)
   (2) 在提交和更新bug时, 都必须把现有的状况叙述清楚, 有的测试情况不是一句话就能描述清楚的. 有的bug能用图来表达更清楚的,请截图.测试环境描述清楚.测试环境包括: 测试所用手机机型,手机的系统,安装路径,安装方式(覆盖安装/卸载安装),测试的版本号.
   (3) 开发反馈已经fix了的bug且在TD上的状态也变为Fix, 经测试这个bug也确实不存在了.这个Bug可以close,但是不能直接选一下Status->closed. 必须说明在哪一版上这个bug被fix了. 测试环境描述清楚.
   (4) 开发反馈没有fix的bug且在TD上的状态为Open/Reopen/New,经测试这个bug已不存在.遇到这种问题时:
   A. 咨询开发人员此bug所存在的模块是否有改动,开发确认有改动且已修改此bug只是忘记修改TD上的状态,那此bug可以close.若开发有改动但是不确认可以修复此bug,请保持此bug在Open/Reopen/New状态,并更新现有的结果下版再验证.
   B. 开发人员对此bug存在的模块没有改动,不管你恢复到上版软件可重现与否,这个bug请保持在Open/Reopen/New状态,并更新现有的结果下版再验证.
   (5) 对于难以重现的问题,若开发那边反馈回来的信息说会忽略这个问题,让开发那边在TD上更新忽略该bug的理由,提交给产品经理/直接发邮件给产品经理,由产品经理来判断这个bug要不要忽略.
   (6) 难重现的问题,以及没有规律性的bug,请不要含糊其辞,要具体记录测了多少次,测试结果如何?不能这样用"偶尔,有时"等等这些模棱两可的词来代替
   (7) 对于在TD上已经确认了不是bug的bug,描述清楚不是bug的原因,不可一句话带过(这不是个bug).详情参考TD2814。然后提交到我这边做最后的判断.
   (8) 开发人员或者测试人员本人认为可以Reject的bug,请慎之又慎的考虑此bug能被Reject掉吗? 然后提交到测试经理这边做最后的判断.( 可以reject的bug,如果说我们这边已经判断出这个问题不是一个bug可以被reject掉了,那就不需要产品经理进行2次确认.需要产品经理确认的问题是,开发认为不是bug可以reject,但是我们这边认为他就是一个bug,这样的情况才需要产品经理确认)
   (9) 需求性的问题, 开发人员或者测试人员本人认为可以Reject的bug(由于都是建议性的问题,测试这边会给出测试结果和自己的意见,但是最后判断的还是由产品经理来确认)
   (10) 对于出现过的bug,但是后续重新验证的过程中又没能重现的bug,请先不要登到TD上.在下一版软件发布时再着重测试一下这类bug,看能否复现,能重现再登到TD上.

3. 对于客户反馈回来的Bug:
   (1) 我们这边验证客户反馈回来bug时,若是在我们这边不能重现,再重新提交给客服让客服那边去联系用户,了解更多的情况.如果3个或3个以上的用户提出相同的bug,若我们这边还是不能重现, 问题不能close,还是保持new状态. 能重现,把状态由new改为open,提交给开发. (这个需要客服那边配合)
   (2) 对于我们这边没有的机型,可以在相关机型上验证,并把测试结果更新到TD上去.如客户肯帮忙,可发修正版本给客户,让客户帮忙测试. (这个需要客服那边配合)
   (3) 若在相关机型上测出有相同bug,机型不同,在原有TD上更新这个结果.
   (4) 关于客户反馈回来的High类bug,我们的响应时间是当天做出回应;Medium类和Low 类bug的响应时间是次日做出回应.
   (5) 需要客服联调的bug,测试这边需要发邮件通知到相关人员.

4. 对于测试用例的完善:
   出现以下情况时,请对测试用例进行修改以后,做出特殊标记反馈给测试经理,在测试经理这边做统一的二次确认和修改.
   (1) 在测试过程中发现测试用例有表达不明确或错误的地方
   (2) 发现某些测试漏掉了或者容易被忽略的,在测试用例上也没有
   (3) 对用户反馈回来的问题,有些测试方法可能是我们没有想到,要进行总结