1、按正常的测试流程而言，当tester开始写测试用例的时候，是不是根本还没看到程序是什么样子？或者仅仅看到过简单的GUI界面，在这种情况写step by step的测试用例，是不是完全按照需求书的功能描述来写的？我的问题是需求书会提供那么细致的细节吗？（当然肯定有的会），比如我要写一个关于登录的用例，密码长度不够，返回什么错误信息，用户名不对，返回什么错误信息，如果需求书没有这么详尽的信息，测试员如何写测试用例？而且在开发人员正在开发的同时，测试人员所写的测试用例是不是都是针对手工测试的？这是不是也就是为什么说自动测试更多是用在回归测试阶段的原因？在测试初期的功能测试实际中上不上自动化测试？

　　答：理论上确实是这样的，测试人员依据需求写测试用例，在需求阶段就介入，但是就像你说的，实际中，很少有企业能达到这样的能力，所以测试人员就从系统测试阶段开始介入。而依据也不是需求本身，而是已经编写好的软件和建议测试要点了。

　　如果需求规格说明书写的不够细致，作为测试员而言可以根据用户需求规格说明书、测试计划、程序概要设计文档来编写测试用例。程序开发期间，测试员所写的用例不都是针对手工方面的，既包括功能方面的，安全方面的，也包括性能方面等。功能测试介于集成测试和系统测试之间，在功能测试的回归测试阶段应用自动化测试，可以提高测试的效率。除了在功能测试阶段采用自动化测试以外，在单元测试、集成测试、性能测试、可靠性测试和稳定性测试阶段也适合采用自动化测试。

　　测试用例的书写是测试人员的基本功，相关的信息你可以看看51Testing软件测试网测试技术→测试用例的频道。

　　2、测试用例是不是只针对功能测试而言的？个人感觉好像应该不是，类似像压力测试，冒烟测试，兼容性测试也都可以有相应的测试用例吧？

　　答：测试用例当然不只是针对功能测试而言的。所有测试工作的依据都可以认为是测试用例，就像你说的所有专项测试都应该有测试用例，如单元、系统、集成、压力、易用性、安全等等。

　　3、需求文档有BRD， business requirement document，有时候也包括设计文档，个别时候包括use case文档，我的问题是，这个USE CASE文档是由谁负责来编写？tester？还是business  analyst？

　　答：user case通常由需求人员编写，用来明确业务逻辑和角色之间的关系的。

　　需求获取的技术也是门特别的技术，一般由资深的需求人员完成，他们的技能也体现了这个公司的技术水平，相关的需求获取技能，51Testing软件测试网也有相应的频道：http：//www.51testing.com/html/10/category-catid-110.html

　　4、在使用qc学习mercury订票实例的时候，在testplan部分里有很多单独的测试用例（当然它们也被组织在一定目录之下，但基本是按照功能模块的划分进行组织的），但在测试实验室里它们似乎是按照不同的测试类型给组织在一起，比如一些最基本的功能测试的用例（不包括那些边界值测试，等价类划分的功能测试）组织在一起构成了一个mercury tours sanity的类似冒烟测试的测试组，或者一些关于性能测试，压力测试的测试用例，组成了一个performance and load的测试组。我的问题是，类似冒烟测试，压力测试，或者集成测试，系统测试，是不是都可以通过从testplan里的具体测试用例的不同组合来实现？

　　答：都可以，你可以认为测试用例都是一个个的个体，然后通过plan将这些用例按照你的测试意图进行组合，完成不同的测试目标，这也是MI推荐的一种使用TD/QC的方式。