针对添加购物车这个测试点说一下你要怎么测试“添加购物车”?
参考答案(从增删改查角度思考)
- 购物车的初始状态(即GUI)。
- 能否加入购物车,同一件商品能否再次添加到购物车。
- 购物车商品件数的上限限制。
- 购物车是否可以正常移除商品,移除商品后,能否再添加回来。
- 添加的每种商品是否可以正常增减数量,数量大于0。
- 退出购物车,再去查询购物车,商品是否正常。
- 购物车的商品可以全选,取消全选,可以复选,选中的商品和数量可以正常下单。
- 商品添加到购物车以后,已下架,购物车是否会提示此宝贝已失效。
- 商品添加到购物车以后,库存不足了,是否会有提示。
您认为做好测试用例设计工作的关键是什么?
参考答案:测试用例应百分百覆盖需求。
- 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。
- 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。
- 不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题。
您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
- 等价类划分法——等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类。主要应用于有数据输入的地方,如注册登录界面;
- 边界值——边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误.。使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。也应用于数据输入的地方,通常与等价类配合使用,形成更为完善的测试用例设计方案;
- 因果图/判定表法——主要应用于控件之间有组合和约束关系的地方,如自动售货机 ;
- 正交排列法——主要应用于有组合关系的地方,且组合情况一般多余20种,如打印功能测试;
- 大纲法——主要应用于页面之间存在跳转关系的测试,如软件安装测试 ;
- 场景法——主要应用于包含业务流程或业务逻辑的测试,如自助取款机的功能测试!
- 错误推测法——主要根据自己以往的工作经验去推测的。基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法,错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例,例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况,输入表格为空格或输入表格只有一行,这些都是容易发生错误的情况,可选择这些情况下的例子作为测试用例。
我现在有个程序,发现在Windows上运行得很慢,怎么判别是程序存在问题还是软硬件系统存在问题?
参考答案:
- 检查系统是否有中毒的特征;
- 检查软件/硬件的配置是否符合软件的推荐标准;
- 确认当前的系统是否是独立,即没有对外提供什么消耗CPU资源的服务;
- 如果是C/S或者B/S结构的软件,需要检查是不是因为与服务器的连接有问题,或者访问有问题造成的;
- 在系统没有任何负载的情况下,查看性能监视器,确认应用程序对CPU/内存的访问情况。
什么是并发?在lordrunner中,如何进行并发的测试?集合点失败了会怎么样?
参考答案:
- 在同一时间点,支持多个不同的操作。
- LoadRunner中提供IP伪装,集合点,配合虚拟用户的设计,以及在多台电脑上设置,可以比较好的模拟真实的并发。
- 集合点,即是多个用户在某个时刻,某个特定的环境下同时进行虚拟用户的操作的。
- 集合点失败,则集合点的才操作就会取消,测试就不能进行。
写出bug报告当中一些必备的内容。
参考答案: 硬件平台和操作系统 。测试应用的硬件平台(Platform),通常选择“PC”。 测试应用的操作系统平台(OS)。
- 版本 提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本。
- Bug报告优先级
- Bug状态
- Bug的编号
- 发现人
- 提交人
- 指定处理人
- 概述
- 从属关系
- 详细描述
- 严重程度
- 所属模块
- 附件
- 提交日期
简述一下缺陷的生命周期?
参考答案:发现->提交->确认->分配->修复->验证->关闭
判断题(每题2分,正确的“√”,错误的“╳”)
(1)发现错误是软件测试的目的(╳)
(2)白盒测试可以找出软件遗漏功能和代码错误功能。(╳)
(3)在设计测试用例时,应包括合理的应用条件和不合理的应用条件。 (√)
(4)软件缺陷一定是由编码引起的错误。 (╳)
(5)文档测试是对系统提交给用户的文档进行验证,并不是一般性的审查活动。(√)
如何编写提交给用户的测试报告?
参考答案:随着测试工作越来越受重视,开发团队向客户提供测试文档是不可避免的事情。很多人会问:“我们可以把工作中的测试报告提供给客户吗?”答案是否定的。因为提供内部测试报告,可能会让客户失去信心,甚至否定项目。 测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档,反映了测试工作的实施情况,这里不过多讨论,读者可以参考相关教材。这里主要讨论一下外部测试报告的写法,一般外部测试报告要满足下面几个要求: -根据内部测试报告进行编写,一般可以摘录; -不可以向客户报告严重缺陷,即使是已经修改的缺陷,开发中的缺陷也没有必要让客户知道; -报告上可以列出一些缺陷,但必须是中级的缺陷,而且这些缺陷必须是修复的; -报告上面的内容尽量要真实可靠; -整个测试报告要仔细审阅,力争不给项目带来负面作用,尤其是性能测试报告。 总之,外部测试报告要小心谨慎的编写。
测试产品与测试项目的区别是什么?
参考答案: 习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品,也就是可以买“卖拷贝”的软件,例如Windows2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件项目,软件项目是一种个性化的产品,可以是按照用户要求全部重新开发,也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点,决定我们测试产品和测试项目仍然会有很多不同的地方: -质量要求不同。通常产品的质量要高一些,修复发布后产品的缺陷成本较高,甚至会带来很多负面的影响。而做项目通常面向某一用户,虽然质量越高越好,但是一般只要满足用户要求就可以了。 -测试资源投入多少不同。做软件产品通常是研发中心来开发,进度压力要小些。同时由于质量要求高,因此会投入较多的人力、物力资源。 -项目最后要和用户共同验收测试,这是产品测试不具有的特点。 此外,测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同,测试管理者应该结合具体的环境,恰如其分的完成工作。
没有产品说明书和需求文档的情况下能够进行黑盒测试吗?
参考答案:这个问题是国内测试工程师经常遇到的问题,根源就是国内软件开发文档管理不规范,对变更的管理方法就更不合理了。实际上没有任何文档的时候,测试人员是能够进行黑盒测试的,这种测试方式我们可以称之为探索测试,具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能,进而发现缺陷。 在这种做法基本上把软件当成了产品说明书,测试过程中要和开发人员不断的进行交流。尤其在作项目的时候,进度压力比较大,可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。
测试用例综合设计策略1
参考答案:Myers提出了使用各种测试方法的综合策略:
- 在任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。
- 必要时用等价类划分方法补充一些测试用例。
- 用错误推测法再追加一些测试用例。
- 对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例。
- 如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。
测试用例综合设计策略2
- 测试用例的设计步骤 1)构造根据设计规格得出的基本功能测试用例; 2)边界值测试用例; 3)状态转换测试用例; 4)错误猜测测试用例; 5)异常测试用例; 6)性能测试用例; 7)压力测试用例。
- 优化测试用例的方法 1)利用设计测试用例的8种方法不断的对测试用例进行分解与合并; 2)采用遗传算法理论进化测试用例; 3)在测试时利用发散思维构造测试用例;