软件测试新手问题解答
今天在测试时代的网站上，一个网友提出了一些问题，这些问题有比较强的普遍性，我将我回答的内容全部摘录如下，希望对大家有帮助。
原文的链接：http://bbs.ltesting.net/thread-47784-1-1.html
本人是初学者，并且目前没有在具体工作中做软件测试，不少概念还比较模糊，所以问题也可能问的不甚清楚，或者较比业余，但我想其他初学者也可能都会遇到，所以还请高手，高高手，不吝赐教！！！
1.按正常的测试流程而言，当tester开始写测试用例的时候，是不是根本还没看到程序是什么样子？或者仅仅看到过简单的GUI界面，在这种情况写step by step的测试用例，是不是完全按照需求书的功能描述来写的？我的问题是需求书会提供那么细致的细节吗？（当然肯定有的会），比如我要写一个关于登录的用例，密码长度不够，返回什么错误信息，用户名不对，返回什么错误信息，如果需求书没有这么详尽的信息，测试员如何写测试用例？而且在开发人员正在开发的同时，测试人员所写的测试用例是不是都是针对手工测试的？这是不是也就是为什么说自动测试更多是用在回归测试阶段的原因？在测试初期的功能测试实际中上不上自动化测试？
答：理论上确实是这样的，测试人员依据需求写测试用例，在需求阶段就介入，但是就像你说的，实际中，很少有企业能达到这样的能力，所以测试人员就从系统测试阶段开始介入。而依据也不是需求本身，而是已经编写好的软件和建议测试要点了。
测试用例的书写是测试人员的基本功，相关的信息你可以看看测试时代测试用例的频道
https://www.ltesting.net/html/94/category-catid-94.html
2.测试用例是不是只针对功能测试而言的？个人感觉好像应该不是，类似像压力测试，冒烟测试，兼容性测试也都可以有相应的测试用例吧？
答：所有测试工作的依据都可以认为是测试用例，就像你说的所有专项测试都应该有测试用例，如单元、系统、集成、压力、易用性、安全等等。
3.需求文档有BRD, business requirement document，有时候也包括设计文档，个别时候包括use case文档，我的问题是，这个USE CASE文档是由谁负责来编写？tester？还是business analyst？
答：user case通常由需求人员编写，用来明确业务逻辑和角色之间的关系的
需求获取的技术也是门特别的技术，一般由资深的需求人员完成，他们的技能也体现了这个公司的技术水平，相关的需求获取技能，测试时代也有相应的频道：https://www.ltesting.net/html/62/category-catid-162.html
4.在使用qc学习mercury订票实例的时候，在testplan部分里有很多单独的测试用例（当然它们也被组织在一定目录之下，但基本是按照功能模块的划分进行组织的），但在测试实验室里它们似乎是按照不同的测试类型给组织在一起，比如一些最基本的功能测试的用例（不包括那些边界值测试，等价类划分的功能测试）组织在一起构成了一个mercury tours sanity的类似冒烟测试的测试组，或者一些关于性能测试，压力测试的测试用例，组成了一个performance and load的测试组。我的问题是，类似冒烟测试，压力测试，或者集成测试，系统测试，是不是都可以通过从testplan里的具体测试用例的不同组合来实现？
答：都可以，你可以认为测试用例都是一个个的个体，然后通过plan将这些用例按照你的测试意图进行组合，完成不同的测试目标。这也是MI推荐的一种使用TD/QC的方式，相关的细节你可以参考TD的说明书：https://www.ltesting.net/html/11/category-catid-111.html
文章来源于领测软件测试网 https://www.ltesting.net/