我们这样“吃狗粮”：

　　1、版本已较稳定

　　我们选择在回归测试之 后，产品上线之前这个阶段进行“吃狗粮”活动。此时，我们认为我们开发的软件基本满足用户的需求，缺陷已经不多了。我们想试试此刻看起来已经比较可口的狗 粮，吃起来到底是什么滋味。活动时间为45分钟（也许太短了，但因为是第一次，我们不想整个团队耗费太多的时间在一件还没有证明其价值的事情上，所以限定 了一个较短的时间）。

　　2、参与范围

　　项目组所有成员（除去休假成员）全体参加，包括了项目经理、需求分析人员、开发人员、测试人员等各个角色。测试人员也参与该活动，因为在这个阶段他们发现新缺陷的概率与其他成员相比没有太大的绝对优势。更何况，从体验的角度，测试人员对于用户的代表不容忽视，不是么？

　　3、缺陷报告

　　因为是体验，所以我们提倡除了缺陷，也欢迎提出任何疑问和建议。这三类问题都被提交到缺陷管理系统中。

　　因为参与人员较多，为了避免对大家自由体验时的干扰，所以我们对于可能重复报告的缺陷采用“先报告，再取消”的方式。即活动中每个人自由记录自己发现的问题（即使会和别人重复），活动后由测试人员阅读每个缺陷报告，取消掉重复的问题。

　　“吃狗粮”背后的事：

　 　45分钟的“吃狗粮”活动结束后，经过统计，23人一共报告了98个缺陷、疑问、建议！这个数字的确出乎很多人的意料！我该高兴么？为这次活动如此大量 的“收获”？我该担忧么？为在这个阶段还有这么多的问题？也许，数字背后的分析才能给我一个答案，也给大家一个合理的解答。

　　在对结果进行分析前，我想到了近期刚刚看过James Bach在Rapid Software Testing中提到的数据分析方法：假设推理（Abductive inference）。通过这个方法可以为数据找到最佳的解释。该方法的步骤为：

　　1、收集数据

　　2、为该数据找到几种解释

　　3、针对每种解释，寻找更多或者与解释一致或者不一致的其它数据

　　4、为重要的数据选择最佳的解释，或者继续寻找

　 　这个方法提醒我需要重视第2和第3步。而以前，我往往是从第1步直接跳到第4步的。好的，让我按照这个方法来进行分析。首先，我通读一遍所有的缺陷/问 题报告，确保我能够理解它们，并将它们归类到合理的（valid）和无效的（invalid）两大类。在通读的过程中，我感到有些缺陷是有共性的，如有几 个似乎都提到了快速切换页面，有几个都提到了系统响应速度太慢等等。因此，我再一次逐个阅读所有的报告，将它们放到我有印象的几个聚集的分类区，因而逐步 形成了一个分类视图。

　　对于每组分类数据，我问自己：这个数字符合我的预期么？很快，我发现了两组数据与我的预期相差甚远。它们分别是误报缺陷数（3）和与数据多样性相关的缺陷数（2）。

　　1、误报缺陷数

　　根据平时测试团队的平均误报率约7%，我预计此次活动的误报数应该要接近甚至超过这个数字。而实际只占了约3%。这说明什么问题呢？假设推理法提醒我要“为该数据找到几种解释”。

　　1）项目组成员对于被测试的功能非常了解，

　　（1.a）所以很少误报

　　（1.b）所以对于某些存在的小问题已经形成共识，即使看到也不认为是问题了，因而没有报告

　　测试负责人在软件项目的需求阶段开始介入，逐步深入了解该项目的需求、设计过程，从而有针对性的编制测试计划和测试大纲（测试方案、测试用例）。

　　对测试人员进行业务培训，了解该项目的大体流程及各项功能。

　　2、测试计划的制定

　　测试计划的制定要与项目开发的总体计划相吻合；测试计划中要充分考虑资源计划（人员安排，设备分配、与其它部门的协调配合以及其它不确定的因素）等；测试计划的制定还要考虑测试版本计划，与开发协调，按照版本生成计划（多长时间出一个版本），制定测试计划。

　　3、时间节点的控制（与开发部门的协调控制）

　　保证测试计划中的全部测试用例跑一遍，如果未按预计的时间将所有计划中的测试用例走一遍，则需分析原因。

　　4、测试用例（TASE CASE）的编制与优先级的控制

　　以软件项目的层次图或模块分解图，按模块根据模块功能清单设计编写测试用例（TEST CASE），将测试用例按对系统的影响程度分成优先级。

　　测试原则：按照优先级的顺序从高到低完成测试用例的测试；测试用例的编制要充分考虑模块间的接口关系，对集成测试的流程要清楚。

　　5、测试过程控制

　　合理的进行测试人员的组织与分配，按功能模块并结合测试人员的实际情况（人员素质、测试业务水平、工作态度）进行测试工作的安排（界面测试（风格、字体、提示信息、布局等）可安排一般测试人员）、功能和性能测试需有较深资历的人员进行测试）。

　　将测试的BUG 的状态进行分类(Active（激活），resolved（解决），postponed（推迟解决，external，fixed（修复），won’t fixed，（无法修复）by design（设计引起），not repro（不重现），closed（关闭）），并且一定要进行确认和跟踪。

　　要求测试人员详细的记录测试过程，特别是错误描述要清楚（特别是错误情况出现的操作步骤）。

　　对测试人员的工作进行检查，并结合测试记录和测试过程对每个测试人员的工作进行考核与评价。

　　6、测试反馈

　　将测试中发现的BUG反馈给该项目（模块）的负责人，由负责人对该BUG进行定位，并由相应的设计人员进行修改，如果测试人员发送的BUG并非该测试模块的BUG，则由该负责人转发给相应的负责人，由其定位，并指派设计人员修改。

　　7、测试问题处理

　　测试结束后，测试过程中发现的所有BUG，都应将其统计汇总，标识出当前的状态，其中经再次测试已经关闭的不再说明，其它所有未关闭的均应说明理由，并与开发部门讨论，由技术负责人给出结论（是否解决或延期解决），并要经过技术副总审批。

　　8、测试分析

　　测试完毕，整理测试文档，测试负责人并编制〈测试过程说明〉、〈测试总结报告〉；每个测试人员提交在该测试项目的〈测试体会〉给质量管理部经理，作为部门人员评价的依据。测试负责人将每个测试人员的测试记录（所发现的BUG）汇总并分析，得出该软件项目的BUG分布表，作为评价该软件项目的依据。

　　9、总体评价

　　根据测试的全部过程及测试记录以及测试分析，对该项目得出综合的评价，确认软件系统的可用性，并提出对该项目的意见与建议，决定是否发版，进入发版控制流程。

　　10、质量目标

　　通过测试管理工作的加强，力求在测试阶段尽可能多的发现软件错误与缺陷，尽可能少的将问题带给用户，确保软件的质量及其可靠性，提高用户满意程度，使作为质量管理中心的质量管理部真正的把好产品的质量关，尽量在测试阶段发现软件错误和软件缺陷。

1. 测试环境重要性及意义
        1、稳定、可控的测试环境，可使测试人员花费较少时间完成测试用例的执行；

        2、 可保证每一个被提交的缺陷被准确的重现；

        3、经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。

2. 测试环境搭建原则
        测试环境搭建之前，需要明确以下问题：

        1、所需计算机数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度等；

        2、部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

        3、用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

        4、是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；

        5、测试中所需要使用的网络环境；

        6、执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议；

        7、测试数据的备份与恢复是否需要；

        8、模拟实际生产环境或用户环境搭建。

3. 测试环境管理
一、设置专门的测试环境管理员

        每条业务线或测试小组应配备一名专门的测试环境管理员，其职责包括：

ü 测试环境搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册编写；

ü 记录组成测试环境的各台机器硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；

ü 完成被测应用的部署，并做好发布文档的编写；

ü 测试环境各项变更的执行及记录；

ü 测试环境的备份及恢复；

ü 操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理；

ü 当测试组内多名成员需要占用服务器并且相互之间存在冲突时（例如在执行性能测试时，在同一时刻应当只有一个场景在运行），负责对服务器时间进行分配和管理。

二、测试环境文档管理

        需要维护如下文档是最新版本：

ü 组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况；

ü 组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置（CPU/内存/硬盘/网卡）、IP地址、具体用途以及历次的变更情况；

ü 被测软件或产品的发布手册，记录被测软件或产品的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。另外，还需要记录历次被测软件或产品的发布情况，对版本差异进行描述；

ü 测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因（与上次备份相比发生的变化）以及所形成的备份文件的文件名和获取方式；

ü 用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。

三、测试环境访问权限管理

        按照如下要求维护测试环境权限：

ü 访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品等所需的各种用户名、密码、权限，由测试环境管理员统一管理；

ü 测试环境管理员拥有全部的权限；

ü 除对被测软件或产品的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。如的确有必要（例如查看系统日志），则只授予只读权限（user权限）；

ü 除测试环境管理员外，其他测试组成员不授予删除权限；

ü 用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。

四、测试环境变更管理

        确保每次变更是可追溯和可控：

ü 测试环境的变更申请由测试人员提出邮件申请，由测试环境管理员负责执行。测试环境管理员不接受非正式的变更申请（例如口头申请）；

ü 对测试环境的任何变更，测试负责人均应记入相应的文档；

ü 每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理；

ü 对于被测软件或产品的发布，开发人员负责打包、测试人员核对发布包。

五、测试环境备份与恢复

        1、确保测试环境程序版本、数据是可恢复；

        2、对于功能或性能测试，测试数据需定期进行备份或从生产环境导入测试数据；

        3、通过备份软件工具备份数据，同时保障备份数据可快速恢复。

4. 测试环境维护执行流程附件
1、测试机器申请流程

2、测试机器维护列表格式

3、测试环境部署文档维护列表格式

4、发布手册维护列表格

　　第一，测试人员职业认同感低。硬件开发工作可以把设计出来的电路板做为输出成果，软件开发可以把具体程序的实现作为输出，而测试只有结果报告和BUG数量，测试工作的成果不好体现。并且，国内很多公司往往不重视测试，每当项目结束论功行赏时，测试团队总是被忽视。另外，测试工作既辛苦又无聊，往往没什么人愿意做测试，而暂时做着测试工作的人员也是隔山望水，盼着早日脱离测试苦海。

　　第二，测试人员对测试技术的认识存在误区。测试团队一般会安排刚进入公司的新人进行测试工作以了解产品。这就给大家带来了一个错觉：测试都是没啥技术含量的活，是人都会干的事。设想一下，一个人每天干着自认为没意义的事，他会有提高、会有进步的动力吗?

　　第三，测试团队成员不知道如何学习，找不到正确的学习方法。测试人员一般都比较敏感，具有很强的发现缺陷的能力，他们能找出应用系统缺陷的能力，也能找出自身在工作中的不足。这些不足包括基础知识的不全面，也有测试技术的欠缺。面对这么多需要学习的方面，感到困惑，不知道先从哪里入手，也分不清学习的重点和难点。遇到问题，可能就直接找其他人员求助，失去了锻炼自己思考学习能力的机会。

　　从以上几个问题，我们可以看到测试团队管理的核心其实是人，只要抓住了这个关键点，就能很顺利的将整个团队调动起来。抛开团队建设中同样重要的制度和流程建设不提，下面将结合本人多年的实践做法谈谈如何建设一支高效的测试团队。

　　首先，要确立测试团队成员在这个组织中的职业规划图，也是就是个人Roadmap。基于这个Roadmap 再确立各个角色的职责以及各角色之间的相互联系和发展顺序。这样各测试团队成员的发展目标也随之确立。下图的Roadmap就是我所在测试团队实际使用的团队成员Roadmap方案。

　　我们把整个测试团队分为五个等级，每个等级都对应测试团队中的相关角色，每个等级都有详细定义的能力要求。整个团队职位的发展顺序同时随着能力的要求逐步理清。通过这个图，基本可以避免优秀测试人员在某个职位停滞不前的问题，目的就是实现团队成员达到哪个能力等级就做哪个能力要求职位的事。比如，第二等级的能力要求定义是完全知道怎样测试并能够根据测试用例独立执行测试工作，第三等级的能力要求定义是能分析问题的原因所在、能监控和管理其他测试工程师的工作。因此，当某成员的技术和经验达到第三等级的能力要求时，就可以安排他作为测试项目的核心组成员或测试负责人(Test Lead)。

　　在这个职业路标规划的指导下，我们可以要求每个团队成员制定自己的短期和长期目标，目标的制定可以是以一个项目时间为周期，也可以季度或年为周期。每个目标的实现就是团队的一个进步。目标就是团队成长的根本。

　　其次，构造团队的学习和交流的氛围。有目标也就有了压力，压力就会产生学习的动力，团队成员针对自己的规划，也会希望自己能够在团队中学习到更多的知识和技能。另外，高效的团队也要求每个团队成员的良好技能来达到高效的目的。因此，学习的氛围是高效的测试团队必不可少的。如何建立这种氛围可以尝试以下几个方法：

　　1. 组织资深测试人员定期在测试团队内部进行经常性的培训和测试经验交流，通过该渠道帮助资历浅的测试人员大幅提升业务技能，做到新老员工之间的知识传播和继承。可以建立部门的讲师制度，鼓励资深测试人员担任讲师，定期(每月或每季度)安排培训，并奖励优秀的讲师。

　　2. 在项目的间歇空闲期，安排测试团队成员进行技术专题研究，这个研究可以是某方面相关的新技术，新测试方法，也可以是其他技术基础知识的收集和积累。每个人都把收集或研究的结果做成演示文稿，在整个团队的培训中介绍自己的研究成功，一方面巩固了学习知识，更重要的是让整个团队成员拓展了知识面，达到了知识团队分享的目的。

　　3. 适度培训开发部门的基本知识，这样能减少与开发团队协同工作时的领域障碍。这里就需要团队负责人和开发部门建立交流机制，邀请其他部门经验丰富人员对测试人员进行知识的拓展。

　　再次，培养测试团队成员养成总结的习惯。弄清楚产生问题的原因，以便下次避免发生类似的问题，这不仅是一次学习，同时，及时对自己的工作进行总结是也一个非常良好的提升个人和组织能力的机会。在团队中建立 “总结”的氛围非常重要，测试发现的很多问题都是不经意间产生的，很多独特的测试方法也是在测试深入过程中灵感突发的产物，而记录并传承这些好的方法就需要有总结意识。总结也需要团队的分享，这样成员的经验才能提升为组织的经验。

　　管理是一门艺术，团队建设则是这门艺术的难点。有关测试团队的建设仍然还有诸如测试人员的考核等等诸多课题值得我们探讨和改进，但只要我们在团队建设中真正做到“以人为本”，再建立适合自己的流程和制度，相信您的团队一定离成功高效的团队不远了。