wbskevin

一个测试新手遇到的若干基础概念问题请教

本人是初学者，并且目前没有在具体工作中做软件测试，不少概念还比较模糊，所以问题也可能问的不甚清楚，或者较比业余，但我想其他初学者也可能都会遇到，所以还请高手，高高手，不吝赐教！！！


1.        按正常的测试流程而言，当tester开始写测试用例的时候，是不是根本还没看到程序是什么样子？或者仅仅看到过简单的GUI界面，在这种情况写step by step的测试用例，是不是完全按照需求书的功能描述来写的？我的问题是需求书会提供那么细致的细节吗？（当然肯定有的会），比如我要写一个关于登录的用例，密码长度不够，返回什么错误信息，用户名不对，返回什么错误信息，如果需求书没有这么详尽的信息，测试员如何写测试用例？而且在开发人员正在开发的同时，测试人员所写的测试用例是不是都是针对手工测试的？这是不是也就是为什么说自动测试更多是用在回归测试阶段的原因？在测试初期的功能测试实际中上不上自动化测试？
2.        测试用例是不是只针对功能测试而言的？个人感觉好像应该不是，类似像压力测试，冒烟测试，兼容性测试也都可以有相应的测试用例吧？
3.        需求文档有BRD, business requirement document，有时候也包括设计文档，个别时候包括use case文档，我的问题是，这个USE CASE文档是由谁负责来编写？tester？还是business  analyst？
4.        在使用qc学习mercury订票实例的时候，在testplan部分里有很多单独的测试用例（当然它们也被组织在一定目录之下，但基本是按照功能模块的划分进行组织的），但在测试实验室里它们似乎是按照不同的测试类型给组织在一起，比如一些最基本的功能测试的用例（不包括那些边界值测试，等价类划分的功能测试）组织在一起构成了一个mercury tours sanity的类似冒烟测试的测试组，或者一些关于性能测试，压力测试的测试用例，组成了一个performance and load的测试组。我的问题是，类似冒烟测试，压力测试，或者集成测试，系统测试，是不是都可以通过从testplan里的具体测试用例的不同组合来实现？
5.        Alpha，beta测试算UAT测试吗？alpha,beta是不是完全针对类似游戏，工具软件这类面向大众用户的一类软件的一种测试？商业软件有alpha,beta测试吗 ？ 反过来，这些游戏、工具软件是不是也没有所谓的UAT测试？
6.        UAT测试是不是一个严格按照用户需求书来执行的测试？
7.        是否基本上所有的测试类型都可以统一通过QC这样的软件来管理？包括兼容性测试，backend 测试，集成测试，压力测试等等？还有，类似UAT测试，alpha，beta测试可能有用户来完成，这些测试的测试情况也可以用QC统一管理起来吗 ？
8.        如何大致判断一个软件，大致可能要写多少测试用例？（不妨认为是在一个相对统一的普遍的测试覆盖率的前提下），举个例子来说，就好比mercury自带的订票程序（无论是client/server版的，还是web版本的），或者更实际些的，像MSN、emule这样的软件，类似这些规模大小的软件，要写测试用例的话，大致会有多少呢？还有相对应的测试团队的人员组成如何？向上面提到的这样的程序，一般需要多少测试人员？
9.        集成测试到底是测什么的？有点糊涂，能不能给个这方面的具体测试用例的例子？
10.        backend 测试，主要测前台GUI界面的数据是否与后台的数据一致？能举个具体例子吗？详实一些的。
11.        测试环境与开发环境一定要用一样的数据库，webserver，应用服务器，简单说需要一样的环境吗？（只是说软件环境）。
12.        做开发的一般可能都有这个经验，那就是随便见到一个软件，大致能判断这个软件是用什么语言编的？用C，用JAVA, 等等，这里面有什么经验可谈吗？是不是一方面可能是从不同的编程语言的所擅长的领域来判断，另一个是从这个软件界面风格也能获得一些线索？

seanhe

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

2.所有测试工作的依据都可以认为是测试用例，就像你说的所有专项测试都应该有测试用例，如单元、系统、集成、压力、易用性、安全等等。

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

4.都可以，你可以认为测试用例都是一个个的个体，然后通过plan将这些用例按照你的测试意图进行组合，完成不同的测试目标。

5. Alpha，beta测试针对的是产品类，而不是项目类，主要用来在正式上市前进行的用户测试， Alpha测试范围更小，局限在公司内部， beta测试是相对大范围的目标用户的测试。

6.其实在真正的开发环节中，没有一定之规，也就是没有什么是严格执行的。但是流程的建立者需要明确最终的目标是什么。在能力成熟度高的企业中，流程的可伸缩性就小些，不高的企业中就很大，所以才需要过程改进啊。建议你可以看看测试时代的CMMI专栏，看看流程上的问题：http://www.testage.net/html/70/category-catid-170.html

7.理论上都可以，关键在于操作者对测试的理解，工具只是工具，关键是使用工具人的思想。你可以看看测试时代的TD专栏，了解一下TD关于软件测试过程的控制方法：
http://www.testage.net/html/11/category-catid-111.html

8.没有任何一种方法可以准确的评估出需要多少测试用例，很遗憾是吧？因为测试用例的多少完全和组织本身的情况相关，比如如果你的测试人员技能都很高，完全没有必要写详细的测试用例，测试大纲就完全可以胜任了。如果你的人员都是新手，为了控制质量，当然就需要详细的用例了，两种情况的测试用例数量显然相差很大，但是测试效果那？很有可能数量少的质量更高，因为人员质量更高。
所以，测试用例数量和测试质量并没有直接的关联。但是如果你的组织和人员相对稳定，测试手段固定，那用例的数量就是个很有意义的指标了。
通常情况下，对于测试人力的估算是通过开发人力的估算折算出来的，但是不同的项目，折算的方法也不一样，也没有一个都认可的数据。

9.集成测试针对的对象是，系统架构、模块之间的接口，和主要业务功能是否实现，所以用例也会包括验证这几块的方法，具体用例可写不出来，因为你必须给个业务。

10.不太清楚你的backend的概念是什么，是否一致还是要看你的编码方式是什么样的，如果只是从数据库中直接取，大可不必这么复杂，如果还做了加工，那就需要仔细核对了。

11.测试环境要和用户真实使用的一致，而不是和开发一样。而且测试库和开发库必须分离，避免相互影响。

12.主要是从界面风格，每种语言都不一致。

bjolimpic

楼主的问题回复如下：
1、如果需求规格说明书写的不够细致，作为测试员而言可以根据用户需求规格说明书、测试计划、程序概要设计文档来编写测试用例。程序开发期间，测试员所写的用例不都是针对手工方面的，既包括功能方面的，安全方面的，也包括性能方面等。功能测试介于集成测试和系统测试之间，在功能测试的回归测试阶段应用自动化测试，可以提高测试的效率。除了在功能测试阶段采用自动化测试以外，在单元测试、集成测试、性能测试、可靠性测试和稳定性测试阶段也适合采用自动化测试。
2、测试用例当然不只是针对功能测试而言的。压力测试、兼容性测试、可靠性测试等方面也应该有相应的测试用例。
3、Use Case文档可以由测试主管/测试员负责编写。
4、个人建议是可以按照测试类型来编写和组织测试用例。在不同的测试阶段，比如集成测试阶段、功能测试阶段、系统测试阶段、验收测试阶段分别选择不同类型的用例，并封装在测试套件里，完成相应阶段的测试任务。
5、UAT测试有三种类型验收测试、Alpha和beta测试。α测试和β测试主要是针对产品型的测试系统，包括你提到的游戏软件和商业软件。目的主要是，评价软件产品功能、可用性、可靠性、性能等等方面，是可控制的。
6、前面提到UAT测试的三种测试类型。其中验收测试需要依据用户规格说明书来执行测试，另外两种不需要。
7、是的，可以。
8、测试用例是要不断补充和优化的。不好统计测试一个类似MSN的IM软件需要多大规模的测试用例，但是测试用例的规模一定要保证测试覆盖率和用例的质量也要有所保证。测试人员与开发人员人数的比例建议1：1
9、集成测试主要测试软件模块之间的接口是不是有问题。比如你提到的MSN软件，在集成完音频模块后，软件功能正常，但是在集成了视频模块后，音频通信出现了异常。这就说明接口存在问题。
10、BACK-END 测试就是后台的测试，包括database和server等方面的测试。比如IBM大型机系统中部分子系统会有前台，后台两套系统。
11、应该这样理解，测试环境要按照用户的需求进行设计，要接近于软件运行的真实环境。而不是取决于软件开发的环境。
12、这个问题你可以请教有丰富开发经验的朋友来解答了，呵呵！

wbskevin

真心感谢。

applejuzi

文章很长啊，还算耐着性子看完了。看的出来楼主是经过认真思考的。对于你的疑问我也只知道其中几点，很抱歉。我就说说我的看法吧，不对的地方请各位多多指教。

第一点，我不是特别清楚，因为我是做手机测试的，现在的用例是前人写的，据说是按照需求说明写的，但我听同学说多数公司在做项目时客户会给公司一个单，上面列举了软件需要实现的功能点，我想用例应该是围绕主功能来写的。当然测试如果不清楚可以和开发交流，test case写好了还需要审评的，项目经理，测试，有可能还有市场的需要讨论，是否通过的。

我想测试用例不单单是针对手工的，像你说的自动化不一定是在回归测试中，比如压力测试，性能测试，例如要测一个门户网站服务器的平均负载量，比如yahoo，比如10万每天，测试时不可能找到10万人，这时就需要用到工具了。说到这已经回答了你的第二点

第三点，各个公司不一样吧，小公司估计都没有business  analyst

第五点，我认为Alpha，beta测试算UAT测试，它们不是完全针对类似游戏，工具软件这类面向大众用户的一类软件的一种测试，商业软件也有alpha,beta测试

第六点，虽然我没有做过UAT测试，但我认为不完全是，有时候用户需求书可能没有写的那么详细，比如说网页上的某个可输入域，以价格为例，说明书可能会说只允许输入数字，但隐含意思就是不能输入汉字等字符。

第八点，不同的软件，不一样的公司开发，不一样的测试员，测试用例条数都不一样。我的感受就是用例要写的详细可以很多的，比如现在我做的手机测试就一个camera就有400多条，那还是写的不太详细的。有时候输入条件太多，实现的路径太多，输出结果太多，不可能一一覆盖，只能挑常用的，主要的。再比如测试手机的通话效果，中国这么多省，市，县，乡。。。不可能一一测试，再说如果一一测试，所需的人力物力财力太多，所以测的时候只挑一些有代表性的，比如挑东边，南边，北边，西边的一些城市

第九点，继承测试主要测接口的。现在软件复杂不可能由一个人开发，都是好几个或者更多，开发时把软件分成各个小模块，然后每个人做其中的一个或几个，然后其它人可能需要你那块的数据或函数等。像接力赛似的，后一个人需要前一个的棒。再以网上购物为例。假如a人做了用户管理模块（登陆，注册。。。），b人做买东西这块，这时b就需要a这块的数据,谁买了什么东西啊？a留个接口，一般是cookies或session或自己写的程序。我这样描述，你应该清楚些了吧？

第十点，backend 测试简单的理解可以算是。比如用户管理后台，管理员添加了用户a，并让它在前台显示，这时就要测试是否添加成功了，这个可以通过查询数据库来实现，假如添加成功了还要看在前台是否正确的显示了。但也不能完全理解为就是前台测试，比如管理员在后台又添加了个账户来登陆后台，并和他具有一样的权限，这时测仅仅是用后来添加的账户来验证是否可以登陆后台系统，并不会在前台显示。

第十一点，我想为了测试的准确性，用一样的最好了，否则测试时出现问题了一开始还不知道是程序有问题还是环境有问题

第十二点，不同的语言可以作不同的系统，比如c一般作底层的，像嵌入式的就是用c/c++,如果是网页方面的，就有很多了，大家熟悉的有asp.net,asp,jsp,php,这个主要看网页网址的后缀了，asp.net的是.aspx,asp是.asp,jsp是.jsp,php是.php.如果遇到自己不熟悉的可以用google搜素。要了解这些需要学些开发语言方面的知识

由于时间有限，就写到这了，希望能够给你一些帮助，我也只是个菜鸟，以后共同进步。

lfcyglfcyg_xuan

学习中……