Q1： 请问，
测试用例该如何进行推广，现在很多的项目都能走正常的测试流程比如说，计划，方案，测试用例编写和审 ...
这属于测试用例管理的通病，问题不在于使用什么工具，而是测试用例是如何被定位的。只是单纯的走流程，测试用例往往就变成了一个临时的过程文档。 想要把测试用例使用的更加有效，如下几个建议：
1. 测试用例的编写必须基于有效的需求文档，并且是强耦合。也就是说，需求变化时，测试用例必须及时更新。
2. 测试用例的审核，必须需求，开发，测试共同参与。审核的目标是测试用例的覆盖度。
3. 测试用例的编写必须基于统一的标准，包括格式，深度，广度。
4. 测试用例必须和task结合，也就是说在制定测试计划时，要根据不同task来设置不同的测试用例集合。
5. 测试用例必须和bug强耦合。bug和测试用例的priority和severity是相辅相成的。
6. 测试用例必须是测试报告的基础，日报，周报，月报，项目阶段报告，里程碑报告等报告的三大支柱就是：测试用例状态，bug状态和schedule状态。
7. 测试用例必须根据测试实际情况选取，priority和severity是选取测试用例集的重要指标。
8. 测试用例集要分多个层次，所有的测试过程所用的测试用例都是主测试用例集的子集。
Q2：请问嘉宾，面对需求不明确，工期短的项目：
1.怎样做好测试需求分析；
把use case和user story弄好，一旦所有参与人员都on same page了，需求就明确了。
2.面对团队参差不齐的水平成员怎样 ...
任何团队都是由各个不同背景的人组成的，只有一时的最短板，没有永远的最短板。team leader的作用就是根据每个team member的个人能力安排task。
q3:在
敏捷开发中，测试如何找做好高效率迭代测试的
工作？
1. 敏捷测试是质量驱动，传统测试是质量保障
2. 敏捷测试是发起者，传统测试是验收者
3. 敏捷测试追求的是最快反应用户的真实需求，传统测试是保证已有需求的完整性。
4. 敏捷测试的测试对象是user story，传统测试的测试对象是单一功能
5. 敏捷测试的过程是反复迭代累加的动态过程，传统测试的过程是预先设定的静态过程。
所以，在敏捷测试中，一定要把传统测试中那种保证功能有效的想法抛弃，真正的敏捷，不在于功能是否正确，而在于是否真实的反应需求。所以一定要把use case和user story两者搞清楚。学会如何基于user story来完成迭代测试，如何使用user story来拼接use case来保证回归的质量。
q4：请教现在想到的几个问题：
1、如何做好测试需求分析？
2、在根本就没有文档的情况，甚至连原型都没得看，上来直接就丢给你一个东西，要测试的情况下，如何保证测试质量？
3、实际工作中，设计测试用例时真的会按那些设计方法去一步一步设计吗？
测试需求分析其实很简单，就是从几个方面来考虑：
１. 从功能方面。该需求实现的功能是什么。
２. 从权限方面。该需求的用户组是什么。
３. 从流程方面。该需求的上下文和驱动方式，以及流程方向。
４. 从影响方面。该需求的对已有功能的依赖性。
５. 从过程方面。该需求产生的各个过程结果，以及导向。
问题２其实很常见，尤其你中途加入一个新的产品测试过程时。其实个上面的一样，你根据已有的资料先逐步分析问题１中各项。将clear的标识出来，试着写出user story，画出use case和各种流程图，然后大家做到一起进行确认，同时将unclear的作为question list在讨论过程中逐一提出。
测试用例的设计其实无所谓使用哪种方法，那些都是一些工具而已，一旦你熟练的掌握了那些技巧，在你实际设计时都会自然而然的使用上，无剑胜有剑。
q5问题：
1. 针对测试执行过程中，如何让测试进度以及质量更加透明（针对开发和测试），有没有什么注意点（ps：不要太官方的回答，如及时反馈等等，呵呵）
2. 针对老年化的测试测试团队，如何提高大家的测试积极性和测试热情？
测试进度和质量更透明? 呃，如果是敏捷开发团队的话，一般都会有个例会，每个QA都会将自己测试的进度，发现的问题，以及问题的分析在例会上讲出来。相关的Dev和关联的QA都会得到反馈。
如果不是的话，那就每周发一个周报，给所有的开发和测试，包含以下几个方面就好了：
1. 测试的进度。各个task测试进度，然后可以放几个对比图，比如速度啊，failed率啊啥的。
2. bug的分析。 各种图，对应task也好，功能也好， 反应该块的质量。
3. 综合分析，针对以上进行分析，列出low efficiency的原因也好，弄个risk list也好，总之让大家知道我们team的风险状态
然后，让dev也回发一个，针对QA的分析从开发角度进行回答，例如代码的重构引起什么样的问题过多出现，提醒QA多做某种类型的回归测试等等。
我不知道啥叫老年化，不过你说的应该是混日子的老资格太多了吧。一般这个出现很正常，惰性嘛，都有。 无非就是从几个方面激励一下：
1. 精神上。比如，让老QA们搞一些training文档给新人。
2. 物质上。该涨工资的涨，该升level的生，做不到的话，给个title也行啊，人很容易满足的。
3. 技术上。引入一些新技术，新的测试方法。
4. 团队上。没事组织大家多活动，交流，工作是同事，
生活是朋友。
5. 影响上。有些实在混的厉害的，就该罚就罚，开除个太混的至少顶半年用。
