又过了一段时间，一日文字收到一封调查问卷，一看邮件内容是关于测试用例方面的一些问题，脑子里一闪‘怎么突然问这个，又要干嘛呢’，就专注在问题上面的回答上面了。
第1个问题，“我们用的case模版好吗？”，心想这个问题问得有点莫明其妙，什么叫好，什么又叫不好，‘好’的样子应该是怎样的，好像自己没有研究过这些，那就暂时选择‘不清楚’吧。不过，接下来是不是应该认真思考一下这个问题呢。嗯，先记下来，找本书好好学习、分析一下，可以从通用的模式、为什么要有这种模式、这种模式的目的是什么来考虑，只有达到管理者的目的的模式，我想应该就能叫好了吧。
第2个问题，“有必要将测试用例划分为：功能测试用例、界面测试用例、易用性测试用例等几个独立的表格吗？”，这是一种典型的分类处理的方法，拿主要的精力做主要的事情，像界面这些都是通用的检查手段，并不需要每轮测试都进行的，所以这样划分还是很有必要的，选‘有必要’，外加上个建议‘建议整点公共测试检查点，避免重复劳动’，但是测试用例的具体划分项又该是怎样才算合理呢，这个问题还是值得思考的……
第3个问题，“你觉得一个系统多少条case比较合适呢？”，问这个问题的人可能早已设好了问题解决的答案，很显然正确的回答都应该视系统而决定，但明明知道答案是这个，为什么又要问呢。很显然，问题提出者应该是在表达我们目前的用例太多，每次弄的用例没有抓住重点，导致工作的一部分精力浪费在了写无用的测试用例和看文字描述上面了，既然这样这个问题选什么应该都是没有意义的，就选‘视系统大小’。
第4个问题，“你最注重测试用例的哪个特点？”，简洁、易维护、覆盖率高、实用性，这几个选项都是测试用例所必有的，有谁不想文档描述简洁，指导文档能够方便的维护，而做测试工作要求的就是覆盖需求和发现Bug，所有覆盖率和实用肯定是基础要求，而简洁、易维护就是优秀要求了，不过简洁这种东西，还是看作者的语言描述能力了，数学够简洁的，但拿出来表达就只能让数学家看了，如果非要在这之中选择的话，我想实用性可能是最重要的要求，因为做测试工作的核心就是要发现缺陷，所以实用应该是一种态度，但怎样的用你是实用的呢，其实就又回来到了测试用例设计的方法上面，但那些方法在自己实践的工作中就真的起到了很好的指导作用吗，能不能改进一些呢，这也是应该思考并研究的。
第5个问题，“你觉得我们目前的测试用例有哪些问题？”，还好给了一些关键词，凭空想这个问题还真一时半会答不上来，看关键词写到“关键词：与需求脱勾，臃肿，不够深入，重复， 覆盖率不高，case是否完善没有评定标准，交互操作少，未分等级，未分类别，要有针对性，更新困难，执行效率不高”，以前没注意到原来一条测试用例要符合‘好’的标准，看来这里面所说的问题是都要解决，自己的路漫漫长啊，还得不断的探索。感慨是感慨，问题还是得回答啊，仔细看其实还是对上面1、2、3、4个问题现象的具体补充，按上面的再选1次吧。
第6个问题，“如何改进我们的测试用例？”，关键词写到“关键词：设计人员的能力，简单，实用，设计理念，外部交流，描述简洁，减少重复，模块划分更加清晰，维护力度，增加交互操作，分轮测试，逻辑覆盖的case需加入”，暂时没有想到必较全面的方法和思路，如果从上面问题的否定语境的反论角度来说，这里面提到的关键词都是要抓的，但如果从更高层的角度来看的话，我想更重要的是统一思想、制订一个规则、维护这个规则更重要，没有游戏规则的游戏是玩不下去的。
第7个问题，“跑case的过程中，你是怎样跑的？重点关注的是什么”，关键词写到“关键词：前期逐条跑，中后期丢弃，扩展思绪，自己发展关注点;测试重要功能点， 期待结果明确，注重易误操作情况，根据功能相关页面进行测试，关注易用性，友好性.”，其实谁没有都这样做过呢，每个人都有自己的想法和对事物的认知理解，也有惰性，所以大家多多少少都有这样做过，所以最真实的答案应该是‘都有’。从反面的角度来思考这个问题，那么问题应该出在每次测试时的策略是什么，测试的策略与测试用例之间的关系上面如何协调以便能够方便的调动，这个似乎更有难度，哎、哎，自己的脑瓜儿再想些什么呢，不想了、不想了，继续看下一个问题吧。
第8个问题，“如果是你来写测试用例的话，你会怎样来写呢”，关键词写到“关键词：从需求出发，框架，测试方法，简明扼要，覆盖率，可使用性高，基本功能，功能点以及操作的交互与中断，分类分级，总体设计->逐步化分－>分层细化，使用常用方法.”，问题的提出者似乎已经有了方法，但是又在疑虑，想听听群众的声音，所以自己应该静静的等，采用这些方法如果他解决了上面说的问题，那么自己不是学习了宝贵的经验和手段吗！想多了，想多了。还是回答问题吧，‘这些应该都是手段，我想我们应该从手段中提取出理论和指导手册，这才是首先要做的，所以我的答案还是问题6的答案’。
第9个问题，“你有什么好的测试用例方法和大家分享？有什么好的关于测试用例设计的网站或书籍可以参考？”，看到这个问题才发现，自己确实没有深入研究过，也没有看过什么书来描述正确的或者恰当的方式的理论，惭愧、惭愧，自己确实只是‘挖掘机’，只知道干而已。回头看看大家分享的书，不！今晚就应该去图书馆看看，总有些书会提到这些的，应该网络中也有，看看总有些好处的。
第10个问题，“对于目前我们的测试用例你有什么建议？”，这只是对上面的问题的一些补充，提问者真的是一切都不放掉，反反复复要你的意见，看来这次要动真格了，可能要成立什么小组来搞这事儿，这事儿现在看来还是挺有意义的。
文字按自己所想回答了所有问题，顿时觉得自己的理论水平太弱了，前段时间狂疯的找Bug只是低着头在干而已，而什么东西指引着自己却一点不知道，是的，接下来有事可干了。对了，其它人又是怎样回答的呢，要是能拿到其它人的又该多好啊，可遗憾的是也许大家都会跟我一样，填好只发给Leader吧，可惜了！想到这儿，文字就觉得心有不甘，刚才激动的心情一下子又淡了下来。
“那个调查问卷，你填了没？”，打开RTX，文字看见包子发过来的信息。
“填了，都发给Leader了”
“你都填了些啥，发过来瞅瞅”，包子要求到。
文字把调查问卷的内容发了过去，接着问到：“你的呢？”
“也发了，我就是想知道大家都填的啥子”
文字心想，正好，自己还愁看不到呢，看来包子还是比较能够融入圈子中，拿到不少了吧，“都有哪些人的，能发我看看不？”
“稍等。都是我们这届过来的，我这里都有20份了”，说完见RTX传过来一个压缩包，文字便接收了。
正好，也不少了，反正老员工也没有几个，即然大家都是才来没多久的，水平和疑问应该比较多，也比较有典型意义，研究一下做个调查分析什么的，也许不错，集中看看大家观点，兴许是一件有点意思的事情，想到这儿文字就开始看大家填写的问卷，尝试做了一下统计分析。
2个小时候后，文字觉得分析做得差不多了，也许能够说明一些问题和解决的方法，便打开RTX向包子说到，“你给我的20份，我做了一个分析，要不帮我看看？”
“哟，小伙子挺勤快的呀，发来看看呗”
文字只觉得心里一暖，便立刻把分析结果发给了包子，包子接收了文件后，打开看到文字的描述：
“2. 有必要将测试用例划分为：功能测试用例、界面测试用例、易用性测试用例等几个独立的表格吗？
A．有必要 B. 不需要 C. 都行
人数比 8 7 5
简要分析: 从已有数据上看：持不同观点的人基本相等，如果从下面问答题的角度来看，有不少人都谈到测试分级，Case分级的观点。如果这样问，结果也许稍有不同“在执行测试时有必要将测试用例划分为：功能测试用例，兼容性测试用例来进行测试吗？”另外，关于是否按不同测试点划分需要更进一步的考虑（这好像涉及到测试策略的问题） ”
……
过了约10分钟包子说到：“还不错嘛，花了点心思。你发给Leader看看呗”
“不大好吧”，文字心虚了起来。
“有啥不好的，反正这事儿他们还不是要做，即然你做了，省点事情，不挺好的么”
“也有道理”，文字心想做都做了，不要想太多，其实发出去给Leader也挺好的，“好，我马上发”，文字便发了一封邮件。约莫过了1个小左右，文字看到邮件被回复了，点开看到“谢谢，文字同学的分析，分析得很有道理，看来我们问题还是满多的，大家要加油哦！”，皖而一笑，文字只觉得满满的。
隔了2日，文字看到邮件里面有一封叫“Case Design Team团队规划书”的邮件，便打开看见“
团队目前情况
Case Design Team目前由5名测试工程师组成，都具备一定的case设计经验，曾参与web系统，笔记本电脑的case设计，但没有相关的开发经验，对系统结构不了解，工作经验不足。
团队组织结构
由一名组长和四名组员构成。
组长：xxx
组员：xxx，xxx，包子，文字
团队工作职责
主要负责软件测试部三科各项目case的概要设计，指导各项目case的详细设计;并参加各项目的case评审，跟踪case的更新过程（每个组员负责跟进1到2个项目的case更新）
考核办法
用例功能等覆盖情况
用例质量
工作完成效率
工作责任心、工作态度
快速学习能力
创新能力
以上几点是case组重点考核指标，考核结果将在每月的绩效考核表中体现，且直接影响被考核者的加薪、晋升等各项评比。
奖惩方案
奖励：
1.完成情况优秀者
2. 提出合理化建议，经采纳有实际成效者
3.超额完成工作任务者
主要奖励项目：
1.即时奖励：主要在每月的绩效考核等中体现
2.通报表扬：以书面的形式
3.优秀者可以尝试担当leader职位”。
文字看到这里，一方面为自己和包子被选入这个小组感到高兴，毕竟被选入到这里，还是充分说明我们俩的工作是被大家认可的，并且真要是能够进去肯定能够帮助自己去成长，获得更丰富的知识和经验，毕竟对于现阶段来说，成长才是最重要的。另一方面，又觉得非常遗憾，原以为Leader会从理论的高度来解决问卷中的问题，做出统一规划和解决方案，但什么也没有，流于形式，心中的困惑依然没有解决。
“包子，你觉得那个规划书，怎么样啊”，文字忍不住想跟包子吐下糟，于是在RTX中打下了这些字。
“还好啊，怎么了？”
“我觉得一般般，没解决我们提出的疑问，写了跟没写差不多”
“你小子也太目中无人了吧，你有本事你整一个出来呀，搞得自己真觉得牛一样”，看来包子生气了。
“我要是搞出来了怎么办”，文字觉得自己不能认输，确实这规划书写得真一般，不能因为包子担护就认输了，那多没有面子。
“你先搞出来再说”，文字似乎看到了包子轻蔑的笑容，顿时让文字觉得一定要弄出来，认认真真研究大家提出的疑问并解决他。
那自己又该从那方面开始呢，好像又没有头绪，那还不如搜搜索百度呢，于是文字变化着输入关键字“测试用例小组规划书”、“规划书”、“部门规划书”等信息，浏览了一下发现都没有具体描述这方面的，反而有很多关于测试部门建设的规划书，对于自己来说，好像范围又大了一些，连续阅读了好几天，文字反而越来越不知道应该怎么搞，一下子没了注意，但一想到跟包子的打赌，文字又觉得似乎这一次不能输掉，输掉了也许不仅仅是工作上的一个事情，也许包子就真没机会了，所以自己还得另想其它办法，自己去创造这个新东西。
又隔了几日，某一天文字在回宿舍的路上突然想到， 也许自己一开始就把概念杂糅在了一起，对于团队规划书来说，重视的是团队的组建上面、着重在大局观和流程、规范建设上面，它是不带技术细节的，而我们现在要解决的其实是2个问题，即团队组建方面的问题，另1个就是技术层面的问题，技术上面的问题那么我们可以带入比如“测试用例设计培训”上面，所以我们只要参考通用的团队规划书写成就好了。想到这里，文字只觉得豁然开朗，心中满不住激动，转个身就往办公室走去，要赶紧把这个写下来才是。
“测试用例小组的团队规划
一、.团队产生的背景
因目前测试用例的质量低，测试团队整体流程不完善等各方面的原因，故软件测试部三科决定于xxx成立测试用例设计小组。
备注：测试用例的质量低，主要表现在以下几个方面：
1、 测试用例冗余程度较高。
2、 通过测试用例发现Bug的效率不高，实用性不强。
3、 测试用例的设计思路不清晰，造成部分测试点丢失。
4、 测试用例更新与维护不佳。
5、 测试用例的复用率很低。
6、 测试用例对测试项目的指导作用未完全体现。
7、 测试人员对测试用例不满情绪较高，中后期有摒弃测试用例的现象。
——以上信息请参考《测试用例调查表》反馈信息
二、组建团队的目的和作用
提高测试用例的质量，加强测试用例对测试项目的指导作用，并由此加**科流程建设的步伐，为提高本科室整体测试水平做出贡献。
三、团队目前情况
团队成员的状况：
A、测试经验：本团队成员由5名测试工程师组成，曾参与到DTV、DCM、Web等多个项目中开展测试工作，有一定的测试经验，且在项目测试过程中发现Bug的能力较强。
B、测试用例设计经验：本团队成员曾参与Web系统、笔记本电脑的测试用例设计工作，有初步的测试用例设计思想，了解常用测试用例设计方法。
C、性能测试和性能测试用例设计经验：无
D、单元测试和单元测试用例设计经验：无
E、安全性测试和安全性测试用例设计经验：无
F、开发经验：无
团队目前的局限性：
A、仅针对Web系统的测试用例设计工作，DD和GPS暂不介入。
B、目前测试用例小组仅设计系统测试用例。
四、团队的组织结构
五、团队成员的技能要求
略
六、团队的工作流程
七、团队成员的工作职责
前期准备阶段：
A、依据测试组的项目测试用例需求文档以及项目计划文档等，输出测试用例计划表。
B、需求评审阶段
1、了解软件需求文档的内容，分析软件需求文档的正确性，参加软件需求评审。
2、在分析需求文档过程中，将疑问点详细记录，在需求评审过程中提出疑问点或邮件提出，记录答复内容。
3、输出疑问点和答复内容的文档，文档模板如下所示。
|
项目名称： |
|
时间： |
|
提出疑问人： |
|
|
疑问点总计： |
1条 |
疑问点有效率： |
1/7 |
||
|
疑问点 |
答复内容 |
是否有效 |
|||
|
1.XXXX |
1.XXXX |
是 |
|||
C、UI评审阶段
1、检查UI是否满足需求。
2、在检查UI过程中，将疑问点详细记录，在UI评审过程中提出疑问点或邮件提出，记录答复内容。
3、输出疑问点和答复内容的文档，文档模板如上图所示。
D、Case设计阶段
1、Case概要设计阶段
1.1、写出测试用例框架图，输出文档。
1.2、依据测试用例框架图，列出测试点，输出文档。
2、Case详细设计阶段
2.1、依据测试框架图和测试点文档，写出详细测试用例。
2.2、详细测试用例表。
3、Case评审阶段
3.1、概要设计评审阶段和详细设计评审阶段就测试用例设计内容进行讲解。
3.2、分别输出概要设计评审表和详细设计评审表的内容。
3.3、测试用例评审标准参照表。
4、Case更新、维护阶段
4.1、实时更新测试用例。
4.2、输出测试用例更新率、删除率、发现Bug率等内容的文档。
5、Case总结阶段
总结测试用例设计过程与经验，为下一个项目做准备。
八、团队成员的考核
考核层次图
见级织架构文档。
影响考核的因素
A、前期阶段：提出疑问率(个人疑问率/所有疑问)；有效疑问率（有效疑问/所有有效疑问）(10%)。
B、概要设计、详细设计和Case评审阶段：用例覆盖率，用例质量，工作完成效率，测试组满意度(50%)。
C、用例更新、维护和总结阶段：更新效率，沟通配合能力(20%)。
D、其它：工作责任心，工作态度，学习能力，沟通能力，创新能力，细心度，是否受到书面表扬等(20%)。
九、团队成员的奖惩方案
奖惩目的
为鼓励员工的工作积极性，增强员工的个人职业素质，增强团队的整体实力，建立公平竞争的用人机制。
奖励条件
1、用例设计优秀者。
2、提出合理化建议，经采纳有实际成效者。
3、超额完成工作任务者。
4、受到科室内部其它组别书面表扬者。
奖励方案
1、增加绩效点。
2、通报表扬。
3、获得“优秀组员”提名。
4、职位进升，尝试担当测试Leader职位。
处罚条件
1、用例质量低，经改善后无明显进步者。
2、主观抵触工作，工作任务经常未完成者。
3、受到科室内部其它组别书面批评者。
处罚方案
1、降低绩效点。
2、口头警告。
3、通报批评。
4、退出测试用例设计小组。
十、团队培训
培训原因
请参见“团队目前情况_团队成员的状况”的详细分析。
培训目的
增强员工的专业技能，拓展专业知识，增强用例设计质量，增强团队整体素质，为性能测试、安全性测试、单元测试用例的设计做好技术基础。
培训计划
详见培训计划表
培训成果考核的方法
培训后考查其内容，并将其考查结果等情况纳入绩效考核之中。
十一、团队交流与沟通
内部交流和沟通的目的
增强团队的内部沟通，使优秀的设计方法和设计思想以及设计经验得到交流和推广，为团队的成长贡献力量。
实现交流和沟通的方案
1、书面经验、总结分享。
2、以小组形式面对面沟通和分享。
3、在科室内，开展调查问卷调查。
4、与外部其它测试团队进行沟通。
5、其它方式。
十二、团队成员个人发展方向
测试用例设计方面：系统用例设计工程师、性能测试用例设计师、安全性测试用例设计师、单元测试用例设计师、测试用例构架师。
测试技术方面：系统测试师、性能测试师、安全性测试师、单元测试师等。
测试管理：测试小组组长、测试经理。
以及其它。
十三、团队整体发展目标
1、优秀的系统测试用例->涉足性能测试用例->优秀的性能测试用例->涉足安全性测试用例->优秀的安全性测试用例->涉足单元测试用例->优秀的单元测试用例。
2、为测试组输出优秀人才，投入测试小组管理工作之中。
3、条件成熟时，将定期办部门期刊，传播测试思想。
4、锐意打造一流的测试用例设计团队，使测试团队能够基于系统、性能、安全、单元测试而设计出具有 “清晰、简洁、完整、适用性、针对性以及维护性”等特点的测试用例，为测试团队的发展做出贡献。”
大功告成，停笔时文字感受到自己的心崩崩的跳，一种电流刺激全身的兴奋感扑向自己而来，兴奋、喜悦，一切没有什么不是可能的，是的、包子也不是没有可能的。
不过，还不能高兴得太早呢，现在只解决了团队怎样干、流程怎么做，但还没有解决技术上应该怎样做，技术上的思想怎么做，革命尚未成功，还得继续努力才是。不过，自己感觉应该快了，按照这个事情的过程模式，应该是可以解决这个问题，接下来这一周多的时间里还要好好研究、研究，一起把成果放出来吧，包子，到时看你还有什么话说，想到这里，文字不自觉的笑出了声来，嘿嘿……