赞
踩
最近要做功能测试和性能测试,临时抱佛脚,学习点可用的概念和术语,有个大概的认知。
一个质量过硬的软件系统,除了显式功能性需求以外,其他的非功能性需求即隐式功能性需求也是极其关键的。
显式功能性需求(Functional requirement)的含义从字面上就可以很好地理解,指的是软件本身需要实现的具体功能。
从软件测试的维度来看,非功能性需求主要涉及安全性、性能以及兼容性三大方面。
“好的”测试用例一定是一个完备的集合,它能够覆盖所有等价类以及各种边界值,而跟能否发现缺陷无关。
“好的”测试用例必须具备哪些特征?
对大多数的软件测试而言,综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。
等价类中任意一个输入数据对于揭露程序中潜在错误都具有同等效果。只要从每个等价类中任意选取一个值进行测试,就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
等价类划分方法的另一个关键点是要找出所有“无效等价类”。
案例:
学生信息系统中有一个“考试成绩”的输入项,成绩的取值范围是0~100之间的整数,考试成绩及格的分数线是60。
在考虑了无效等价类后,最终设计的测试用例为:
大量的错误发生在输入输出的边界值上,所以需要对边界值进行重点测试,通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
eg. “考试成绩”的例子,选取的边界值数据应该包括:-1,0,1,59,60,61,99,100,101。
错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉,推测出软件可能存在的缺陷,从而有针对性地设计测试用例的方法。
比如,Web界面的GUI功能测试,需要考虑浏览器在有缓存和没有缓存下的表现;Web Service的API测试,需要考虑被测API所依赖的第三方API出错下的处理逻辑;对于代码级的单元测试,需要考虑被测函数的输入参数为空情况下的内部处理逻辑等等。
建立常见缺陷知识库,在测试设计的过程中,会使用缺陷知识库作为检查点列表(checklist),去帮助优化补充测试用例的设计。
建立一个简单的wiki页面,让测试工程师完成测试用例的最初设计后对应这个wiki页面先做一轮自检,如果在后续测试中发现了新的点,就会继续完善这个wiki页面。
在具体的用例设计时,首先需要搞清楚每一个业务需求所对应的多个软件功能需求点,然后分析出每个软件功能需求点对应的多个测试需求点,最后再针对每个测试需求点设计测试用例。
以用户登录为例:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。