2.6.7 控制流测试
控制流测试经常用在嵌入式软件系统。
案例2-21:控制流测试。
如图2-18所示。
图2-18 控制流软件测试的例子
首先:
- 对经过A点的线进行排序:{1,2}、{1,3}、{1,4}、{6,2}、{6,3}、{6,4}。
- 对经过B点的线进行排序:{2,6}、{3,6}、{4,6}、{2,5}、{3,5}、{4,5}。
然后进行总体排序
{1,2}、{1,3}、{1,4}、{2,5}、{2,6}、{3,5}、{3,6}、{4,5}、{4,6}、{6,2}、{6,3}、{6,4}。
最后依次进行如下操作:
从1开始,5结束的连续序列,一直到把所有序列都输出完毕,见表2-27。
表2-27 d 控制流覆盖过程
操作 |
输出 |
挑选:{1,2} 、{2,5} {1,2}、{1,3}、{1,4}、{2,5}、{2,6} 、{3,5}、{3,6}、{4,5}、{4,6} 、{6,2}、{6,3}、{6,4} |
{1,2,5} |
挑选:{1,3} {3,5} {1,2}、{1,3}、{1,4}、{2,5}、{2,6} 、{3,5}、{3,6}、{4,5}、{4,6} 、{6,2}、{6,3}、{6,4} |
{1,3,5} |
挑选:{1,4} {4,5} {1,2}、{1,3}、{1,4}、{2,5}、{2,6} 、{3,5}、{3,6}、{4,5}、{4,6} 、{6,2}、{6,3}、{6,4} |
{1,4,5} |
续表[J1]
操作 |
输出 |
排选:{1,2} {2,6} {6,2} {2,5} {1,2}、{1,3}、{1,4}、{2,5}、{2,6} 、{3,5}、{3,6}、{4,5}、{4,6} 、{6,2}、{6,3}、{6,4} |
{1,2,6,2,5} |
排选:{1,3} {3,6} {6,4} {4,6} {6,3} {3,5} {1,2}、{1,3}、{1,4}、{2,5}、{2,6} 、{3,5}、{3,6}、{4,5}、{4,6} 、{6,2}、{6,3}、{6,4} |
{1,3,6,4,6,3,5} |
最后得到5个测试用例。
(1){1,2,5}。
(2){1,3,5}。
(3){1,4,5}。
(4){1,2,6,2,5}。
(5){1,3,6,4,6,3,5}。
第3章探索式软件测试设计方法
“探索式软件测试”是软件测试专家CemKaner博士于1983年提出的,并受到语境驱动软件测试学派(ContextDriven Testing School)的支持。由于符合快速提交的理论,且随着近年来敏捷开发的出现,探索式软件测试被重新提出,并且受到广泛重视。探索式软件测试(ExploratoryTesting):是一种自由的软件测试风格,强调软件测试工程师展开软件测试学习、软件测试设计、软件测试执行和软件测试结果评估等活动,以持续优化软件测试工作。
在参考文献【6】中,第一节有句话“太让人失望了,不管我们写多少测试(用例),也不管我们执行多少测试用例,都没有用,最严重的缺陷只有在偏离脚本执行时,才能够找到”。对于这里的描述,笔者相信大部分读者可能都有同样的经历,这也体现了探索式测试的重要性所在。上海同济大学朱少明老师在讲座中曾经说过:“脚本测试是发现已知的缺陷,探索式测试是发现未知的缺陷”。在某种意义上这也有一定道理。
本章主要介绍目前基于经验测试法中流行的方法:探索式软件测试法。其中包括:
- 探索式软件测试中用到的一些方法。
- 基于场景的测试。
3.1 探索式软件测试中用到的一些方法
笔者在本节中不涉及探索式软件测试的理论、思想以及一些相关的模型。关于这些理论、思想和模型,请参看参考文献【6】、【8】和【9】。笔者仅将本人在多年软件测试工作中用到的一些探索式软件测试方法介绍给大家,希望能对从事软件测试的同行有所帮助。
注:本节描述的软件测试产品对象大多以基于B/S结构的产品为主,少部分会考虑其他类型的产品。
3.1.1 表单输入的测试探索
表单输入在产品中是经常出现的,如要成为某个网站的会员,就要注册一些个人信息,然后通过表单页面上的【提交】按钮,存储到数据库中。对表单元素输入的测试探索中经常需要考虑以下两个方面:
- 对超长字符或不符合格式的字符(如:电话号码、Email)输入的探索。
- 对保留字符的输入探索。
1.超长或不符合格式的字符输入的测试探索
由于表单输入的数据最终一般都存入到数据库中,所以对于输入的数据,一定要对其的长度或者类型进行限制,一个正常的操作方法为:输入一个超长或不符合格式的字符串,一般有以下4种处理方式:
(1)超长或不符合格式的字符在输入界面中被锁定:如表单要求输入的字符串最长长度为40,当输入第41个字符时,页面是不允许输入的;再如,表单只允许输入阿拉伯数字,如果输入了一个字符“A”,页面也是不允许的。
(2)当在表单内输入超长或不符合格式的字符,[J1] 在鼠标失去焦点后,利用Ajax和JavaScript技术立即给出错误提示。
(3)超长或不符合格式的字符在输入界面中被输入,[J2] 但在提交表单时,输入界面会提示表单中有超长或不符合格式的字符,并且表单不允许被提交。
(4)超长或不符合格式的字符在输入界面中被输入,[J3] 但在提交表单后,会在另外的页面中提示表单中有超长字符或不符合格式的字符被输入,并且表单不允许被提交。
如果在表单输入了超过长度或不符合格式的字符串,提交后界面没有任何提示信息,甚至出现系统崩溃,或者出现数据库发生异常的英文日志显示在页面上,那么这显然是一个Bug。另外,如果输入了一个超长或特殊字符串,符合上述4种处理方法,这时可以通过开发工程师查看对应的代码,尤其是数据存储到数据库之前,程序是否对输入字符的长度或类型进行再一次校验,这是从安全性角度考虑的。举个例子:输入页面的文件名为table.html,后台存入数据库操作的文件名为insert.jsp。一个黑客为了破坏这套系统,它用其他软件制造了一个表单页面代替table.html。在他的页面中输入超过长度或者不符合格式的数据,然后通过insert.jsp提交到数据库中,由于insert.jsp没有对输入字符进行校验,从而造成系统瘫痪。这种案例经常会遇到。
案例3-1:文本框的输入。
某文本框只允许输入长度为5~20的字符串。超长或不符合格式的文本框的测试用例见表3-1。
表3-1 超长或不符合格式的文本框的测试用例
输入数据 |
期望结果 |
4个‘a’ |
测试不通过 |
5个‘a’ |
测试通过 |
20个‘a’ |
测试通过 |
21个‘a’ |
测试不通过 |
4个‘我’ |
测试不通过 |
5个‘我’ |
测试通过 |
19个‘我’ |
测试通过 |
20个‘我’ |
测试通过 |
1个空格+4个‘a’ |
测试不通过 |
1个空格+5个‘a’ |
测试通过 |
1个空格+4个‘我’ |
测试不通过 |
1个空格+5个‘我’ |
测试通过 |
1个空格+20个‘a’ |
测试通过 |
1个空格+21个‘a’ |
测试不通过 |
1个空格+20个‘我’ |
测试通过 |
1个空格+21个‘我’ |
测试不通过 |
1个空格在4个‘a’中间 |
测试通过 |
1个空格在3个‘我’中间 |
测试不通过 |
1个空格在19个‘a’中间 |
测试通过 |
1个空格在20个‘我’中间 |
测试不通过 |
2.保留字符输入的软件测试探索
表单输入的数据,除了存储到数据库中,还会显示在界面上。例如在修改个人信息的案例中,系统会把以前输入到数据库中的数据显示到界面上,这样便于用户对信息中不合适的地方进行修改。要对这种类型的软件测试进行探索,首先要搞清楚这套产品对表单输入数据使用的是何种方式进行输出?这种输出方式中存在哪些保留字符?输出的方法是用HTML语言显示的,HTML保留字符有:<、>、“、‘、&、空格、回车等(参见附录A)。HTML显示这些字符时可以用其他字符进行替换。一个正常的操作是从数据库中输出保留字符以后,程序对这些保留字符通过正则替换转码为HTML中对应的可以显示的字符串,如‘<’转为<;,空格转为 …….如果在表单中输入了这些字符,或者输入一段含有这些字符的HTML代码或者JavaScript代码,如http://www.sina.cm.cn”>进入新浪,然后在显示页面中查看输出的格式是否正确,如果不正确,或者出现显示页面错乱,甚至执行了JavaScript语句,这属于XSS注入,肯定是一个Bug。
案例仍旧为案例3-1,增加测试用例,见表3-2。
表3-2 保留字符的测试用例
输入数据 |
期望结果 |
<script>alert(document.cookies)</script> |
显示‘<script>alert(document.cookies)</script>’,不执行javascript语句alert(document.cookies) |
顾翔凡言:
敏捷具有适用性,即使用了敏捷,也不要做成假敏捷,掌握敏捷的真谛。