软件测试新手问题解答

巴黎的灯光下

软件测试新手问题解答  今天在测试时代的网站上，一个网友提出了一些问题，这些问题有比较强的普遍性，我将我回答的内容全部摘录如下，希望对大家有帮助。



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



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



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

       测试用例的书写是测试人员的基本功，相关的信息你可以看看测试时代测试用例的频道

       http://www.ltesting.net/html/94/category-catid-94.html



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



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





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



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

       需求获取的技术也是门特别的技术，一般由资深的需求人员完成，他们的技能也体现了这个公司的技术水平，相关的需求获取技能，测试时代也有相应的频道：http://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的说明书：http://www.ltesting.net/html/11/category-catid-111.html





5. Alpha，beta测试算UAT测试吗？alpha,beta是不是完全针对类似游戏，工具软件这类面向大众用户的一类软件的一种测试？商业软件有alpha,beta测试吗 ？ 反过来，这些游戏、工具软件是不是也没有所谓的UAT测试？



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





6. UAT测试是不是一个严格按照用户需求书来执行的测试？



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





7.是否基本上所有的测试类型都可以统一通过QC这样的软件来管理？包括兼容性测试，backend 测试，集成测试，压力测试等等？还有，类似UAT测试，alpha，beta测试可能有用户来完成，这些测试的测试情况也可以用QC统一管理起来吗 ？



答：理论上都可以，关键在于操作者对测试的理解，工具只是工具，关键是使用工具人的思想。你可以看看测试时代的TD专栏，了解一下TD关于软件测试过程的控制方法：

http://www.ltesting.net/html/11/category-catid-111.html





8.如何大致判断一个软件，大致可能要写多少测试用例？（不妨认为是在一个相对统一的普遍的测试覆盖率的前提下），举个例子来说，就好比mercury自带的订票程序（无论是client/server版的，还是web版本的），或者更实际些的，像MSN、emule这样的软件，类似这些规模大小的软件，要写测试用例的话，大致会有多少呢？还有相对应的测试团队的人员组成如何？向上面提到的这样的程序，一般需要多少测试人员？



答：没有任何一种方法可以准确的评估出需要多少测试用例，很遗憾是吧？因为测试用例的多少完全和组织本身的情况相关，比如如果你的测试人员技能都很高，完全没有必要写详细的测试用例，测试大纲就完全可以胜任了。如果你的人员都是新手，为了控制质量，当然就需要详细的用例了，两种情况的测试用例数量显然相差很大，但是测试效果那？很有可能数量少的质量更高，因为人员质量更高。

所以，测试用例数量和测试质量并没有直接的关联。但是如果你的组织和人员相对稳定，测试手段固定，那用例的数量就是个很有意义的指标了。

通常情况下，对于测试人力的估算是通过开发人力的估算折算出来的，但是不同的项目，折算的方法也不一样，也没有一个都认可的数据。





9.集成测试到底是测什么的？有点糊涂，能不能给个这方面的具体测试用例的例子？



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





10. backend 测试，主要测前台GUI界面的数据是否与后台的数据一致？能举个具体例子吗？详实一些的。



答：后台测试方法还是要看你的实现逻辑是什么样子的，是否一致还是要看你的编码方式是什么样的，如果只是从数据库中直接取，大可不必这么复杂，如果还做了加工，那就需要仔细核对了，核对的方式需要直接从数据库中取相应的数据，并且看看和界面中显示的一致，当然用工具实现是最方便的。



11.测试环境与开发环境一定要用一样的数据库，webserver，应用服务器，简单说需要一样的环境吗？（只是说软件环境）。



答：测试环境要和用户真实使用的一致，而不是和开发一样，因为开发环境还装了些调试的软件，这些软件在客户处是不会有的。而且测试库和开发库必须分离，避免相互影响。





12.做开发的一般可能都有这个经验，那就是随便见到一个软件，大致能判断这个软件是用什么语言编的？用C，用JAVA, 等等，这里面有什么经验可谈吗？是不是一方面可能是从不同的编程语言的所擅长的领域来判断，另一个是从这个软件界面风格也能获得一些线索？



答：主要是从界面风格，每种语言都不一致