软件测试新手问题解答
今天在测试时代的网站上,一个网友提出了一些问题,这些问题有比较强的普遍性,我将我回答的内容全部摘录如下,希望对大家有帮助。
原文的链接:http://bbs.ltesting.net/thread-47784-1-1.html
本人是初学者,并且目前没有在具体工作中做软件测试,不少概念还比较模糊,所以问题也可能问的不甚清楚,或者较比业余,但我想其他初学者也可能都会遇到,所以还请高手,高高手,不吝赐教!!!
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