发布新日志

  • 用五个安全测试步骤来保护应用程序(转)

    2008-12-08 11:41:09

    步骤一:端口扫描你需要做的第一件事是在客户端和服务器端进行一次端口扫描,找出那些打开但并不需要的通讯端口。各种服务如FTP、NetBIOS、echo、gotd等使用的端口是引起安全问题的典型因素。对于TCP和UDP端口来说,根据经验通常的做法是:关掉任何程序运行所不需要的服务或监听器。
     
      端口扫描被用来检测目标系统上哪些TCP和UDP端口正在监听,即等待连接。大多数的计算机默认地打开了许多这样的端口,黑客和破解者经常花很多时间对它们的目标进行端口扫描来定位监听器,这是他们开始攻击的前奏。一旦这些端口都被鉴别出来,要使用它们也就不困难了。
     
      端口扫描工具,通常叫端口扫描器,很容易在Internet上找到。其中很多是基于Linux的。例如Namp、Strobe、Netcat是比较好的一类。我最喜欢的基于Linux的端口扫描器是Nump.也有许多基于Microsoft Windows的端口扫描器,其中我最喜欢的是Ipswitch的WS Ping ProPack.WS Ping ProPack是一个低开销、多用途的网络问题定位工具,它将许多功能包装成简单易用的形式。
     
      有了端口扫描器后,对全部TCP和UDP端口进行一次完整的检查来确定哪些端口是打开的。将监测到的打开的端口与系统运行所需要用到的端口进行比较,关闭所有没有用到的端口。在Microsoft操作系统中关闭端口经常需要重新配置操作系统的服务或者修改注册表设置。UNIX和Linux系统就简单一些:通常只是将配置文件中的某一行注释掉。
     
      步骤二:检查用户帐户接下来,需要将目光转移,看看操作系统、任何数据库以及程序自身,特别注意guest用户帐户、默认账户或者简单密码账户以及不需要的用户ID.之所以需要这样做是因为大多数的默认设置留下了许多漏洞,创建了多余的账户,它们可能会被用来危及系统的安全。这种情况在使用数据库系统如Oracle或Web服务器如Microsoft Internet Information Services (IIS)时特别突出。
     
      我曾经通过使用本不该存在或应被禁止的用户ID和密码登陆进入过许多路由其、数据库和应用程序中。例如,若干年前,在测试一个简单的Web应用程序时,我尝试用Guest 账户ID和空密码登陆进系统。很出乎我的意料,程序很爽快地将Guest作为合法用户并允许我登陆。然后我又试了几个其它的账户,如输入用户ID和密码为空/空或管理员/管理员,结果都成功了。
     
      有了这次经验,我总是在软件安装手册的每一章寻找默认的账号和密码。我建立了一份这些默认账号和密码的列表,以确保能够把找到过的都试试。对于程序本身我也这样做,建立一份由程序员创建的测试用户帐户,也把它们试试。
     
      测试这些东西能够帮助发现危害系统的途径,禁用和删除不必须的账户是一种消除找到的缺陷的一种方法。对于通讯端口也有一个相似的方法:禁用任何系统运行所不需要的用户ID.如果某个用户ID不能被禁用,那么至少改变它的默认密码,使其不易被破解。
     
      你会问,怎样才算一个好的密码?它地长度至少为六到八个字符,并含有一个特殊字符。密码必须足够长,以使其不易被破解,但是必须能够容易记住——这是难以两全的。我喜欢使用缩写词或者容易记忆的设备。千万别用任何易猜的单词或习语,这是一个常见的密码失误。同样的,不要使用字典中的单个词语。我记忆最深刻的差密码之一是ROLLTIDE,这是我在阿拉巴马州大学一台被丢弃的机器上发现的(这所大学运动队的昵称是Crimson Tide)。

    步骤三:检查目录许可在关闭了无用端口并禁用了多余的账号后,仔细检查一下程序所用到的数据库和服务器目录的权限设置。很多攻击利用了配置失误的权限,这种方法经常被用来攻击Web服务器。
     
      例如,使用CGI脚本的Web站点有时允许写访问。通过它,一个恶意的供给者可以很简单地在CGI二进制目录下放置一个文件。然后他就能够调用这个脚本文件,Web服务器会运行它,典型地在管理员权限下。能够写并执行脚本是非常危险的,要开放这些权限应该格外小心。
     
      另一个例子,几年前,我给一个安全实验室里的一个非常重要的系统作测试。通过配置失误的权限,我可以在很短的时间内破坏整个实验室以及所有17个被认为是安全的机器。在端口扫描之后,我发现每个服务器都运行了一个FTP监听器,而且每个都允许匿名访问,使得我可以访问每个服务器系统。
     
      FTP监听器给了我对每台机器上真正存放密码文件的访问权限,真是一个巨大的配置失误。由于权限如此设置,我不仅可以下载存放密码的文件,而且可以通过把密码文件中的密码修改后再上传给服务器覆盖源文件而使这些用户“中毒”。当然我将自己授予了root访问权,从而取得了机器的管理员权限。
     
      如果正确地设置了目录权限,我就不能访问被指定给匿名用户使用的FTP目录以外的任何东西。因此,我本不能够得到真正存放密码的文件,更别提将其替换了。当然,如果他们曾经做过任何自己的端口扫描,就像我在步骤一里提到的,那么用这种方法我将哪里也到不了。
     
      步骤四:对数据库也进行和上面同样的设置文件系统不是唯一因权限设置不当而会受到攻击的对象。大多数的数据库系统有很多安全漏洞。它们的默认权限设置通常不正确,如打开了不必要的端口、创建了很多演示用户。一个著名的例子是Oracle的演示用户Scott,密码为Tiger.加强数据库安全的措施与操作系统一样:关闭任何不需要的端口、删除或禁用多余的用户,并只给一个用户完成其任务所必需的权限。
     
      步骤五:关上后门你对必须经过几个步骤来测试被应用程序包装得很深的功能感到厌倦了吗?能够建立一个直观的快捷方式吗?其实大家都这么想。问题在于这些快捷方式——也被叫做后门,经常被忽略或遗忘,而有时它们又会不经意地连同应用程序一起被发布。任何严格的安全测试程序都因该包括检查程序代码中不经意留下的后门。
     
      另一个真实的因后门而引发安全问题的例子是Solaris操作系统的早期版本的[Ctrl]K错误。上世纪90年代早期的Solaris用户只需以一般用户身份登陆并按两次[Ctrl]K就可以获得root权限。
     
      为了寻找后门,必须完整地检查源代码,查找基于非预期参数的条件跳转语句。例如,如果某个程序是通过双击图标而被调用的,那么要确保代码不会因为从命令行用特殊参数调用而跳转到某个管理或特权模式。

  • ASP.NET中如何防范SQL注入式攻击(转贴)

    2008-11-27 10:14:27

    一、什么是SQL注入式攻击?

    所谓SQL注入式攻击,就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串,欺骗服务器执行恶意的SQL命令。在某些表单中,用户输入的内容直接用来构造(或者影响)动态SQL命令,或作为存储过程的输入参数,这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如:

    ⑴ 某个ASP.NET Web应用有一个登录页面,这个登录页面控制着用户是否有权访问应用,它要求用户输入一个名称和密码。

    ⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令,或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子:站长资讯网:http://www.net118.com

    System.Text.StringBuilder query = new System.Text.StringBuilder(
    )`'E$j0x!K$p-f'Z7pb0N230007
    m+apbo e230007"SELECT * from Users WHERE login = '")51Testing软件测试网T'Rs.{-H,QX)M
    51Testing软件测试网*nN:j6D^Xz [
    .Append(txtLogin.Text).Append("' AND password='")51Testing软件测试网LuE!l9{b/|+UI-X
    51Testing软件测试网!f'Our5cH+`0Q)I!v
    .Append(txtPassword.Text).Append("'");

    ⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。

    ⑷ 用户输入的内容提交给服务器之后,服务器运行上面的ASP.NET代码构造出查询用户的SQL命令,但由于攻击者输入的内容非常特殊,所以最后得到的SQL命令变成:SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。

    ⑸ 服务器执行查询或存储过程,将用户输入的身份信息和服务器中保存的身份信息进行对比。

    ⑹ 由于SQL命令实际上已被注入式攻击修改,已经不能真正验证用户身份,所以系统会错误地授权给攻击者。

    如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询,他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能,欺骗系统授予访问权限。

    系统环境不同,攻击者可能造成的损害也不同,这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限,攻击者就可能对数据库的表执行各种他想要做的操作,包括添加、删除或更新数据,甚至可能直接删除表。

    二、如何防范?

    好在要防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情,只要在利用表单输入的内容构造SQL命令之前,把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。

    ⑴ 对于动态构造SQL查询的场合,可以使用下面的技术:

    第一:替换单引号,即把所有单独出现的单引号改成两个单引号,防止攻击者修改SQL命令的含义。再来看前面的例子,“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。

    第二:删除用户输入内容中的所有连字符,防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询,因为这类查询的后半部分已经被注释掉,不再有效,攻击者只要知道一个合法的用户登录名称,根本不需要知道用户的密码就可以顺利获得访问权限。

    第三:对于用来执行查询的数据库帐户,限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作,因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。

    ⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外,它还使得数据库权限可以限制到只允许特定的存储过程执行,所有的用户输入必须遵从被调用的存储过程的安全上下文,这样就很难再发生注入式攻击了。

    ⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符,那么不要认可表单中输入的10个以上的字符,这将大大增加攻击者在SQL命令中插入有害代码的难度。

    ⑷ 检查用户输入的合法性,确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证,是为了弥补客户端验证机制脆弱的安全性。

    在客户端,攻击者完全有可能获得网页的源代码,修改验证合法性的脚本(或者直接删除脚本),然后将非法内容通过修改后的表单提交给服务器。因此,要保证验证操作确实已经执行,唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象,例如RegularExpressionValidator,它们能够自动生成验证用的客户端脚本,当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象,你可以通过CustomValidator自己创建一个。

    ⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据,然后再将它与数据库中保存的数据比较,这相当于对用户输入的数据进行了“消毒”处理,用户输入的数据不再对数据库有任何特殊的意义,从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile,非常适合于对输入数据进行消毒处理。

    ⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录,但实际返回的记录却超过一行,那就当作出错处理

  • cookie test

    2008-11-25 16:21:20

    Website Cookie Testing, Test cases for testing web application cookies?

    We will first focus on what exactly cookies are and how they work. It would be easy for you to understand the test cases for testing cookies when you have clear understanding of how cookies work? How cookies stored on hard drive? And how can we edit cookie settings?

    What is Cookie?
    Cookie is small information stored in text file on user’s hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages.

    Why Cookies are used?
    Cookies are nothing but the user’s identity and used to track where the user navigated throughout the web site pages. The communication between web browser and web server is stateless.

    For example if you are accessing domain http://www.example.com/1.html then web browser will simply query to example.com web server for the page 1.html. Next time if you type page as http://www.example.com/2.html then new request is send to example.com web server for sending 2.html page and web server don’t know anything about to whom the previous page 1.html served.

    What if you want the previous history of this user communication with the web server? You need to maintain the user state and interaction between web browser and web server somewhere. This is where cookie comes into picture. Cookies serve the purpose of maintaining the user interactions with web server.

    How cookies work?
    The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep any record of previously accessed web page history. While Stateful HTTP protocol do keep some history of previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions.

    Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to some language scrīpt to write the cookie like cookies in JAVAscrīpt, PHP, Perl) writes a text file on users machine called cookie.
    Here is one example of the code that is used to write cookie and can be placed inside any HTML page:

    Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;

    When user visits the same page or domain later time this cookie is read from disk and used to identify the second visit of the same user on that domain. Expiration time is set while writing the cookie. This time is decided by the application that is going to use the cookie.

    Generally two types of cookies are written on user machine.

    1) Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. Some time session of say 20 minutes can be set to expire the cookie.
    2) Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.

    Where cookies are stored?
    When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer store cookies on path “C:\Documents and Settings\Default User\Cookies”
    Here the “Default User” can be replaced by the current user you logged in as. Like “Administrator”, or user name like “Vijay” etc.
    The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then “Show cookies” button.

    How cookies are stored?
    Lets take example of cookie written by rediff.com on Mozilla Firefox browser:
    On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on “Show cookies” button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names.

    Site: Rediff.com Cookie name: RMID
    Name: RMID (Name of the cookie)
    Content: 1d11c8ec44bf49e0… (Encrypted content)
    Domain: .rediff.com
    Path: / (Any path after the domain name)
    Send For: Any type of connection
    Expires: Thursday, December 31, 2020 11:59:59 PM

    Applications where cookies can be used:

    1) To implement shopping cart:
    Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if user adds some products in their shopping cart and if due to some reason user don’t want to buy those products this time and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cart in his last visit.

    2) Personalized sites:
    When user visits certain pages they are asked which pages they don’t want to visit or display. User options are get stored in cookie and till the user is online, those pages are not shown to him.

    3) User tracking:
    To track number of unique visitors online at particular time.

    4) Marketing:
    Some companies use cookies to display advertisements on user machines. Cookies control these advertisements. When and which advertisement should be shown? What is the interest of the user? Which keywords he searches on the site? All these things can be maintained using cookies.

    5) User sessions:
    Cookies can track user sessions to particular domain using user ID and password.

    Drawbacks of cookies:

    1) Even writing Cookie is a great way to maintain user interaction, if user has set browser options to warn before writing any cookie or disabled the cookies completely then site containing cookie will be completely disabled and can not perform. any operation resulting in loss of site traffic.

    2) Too many Cookies:
    If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie, this could turn away user from your site.

    3) Security issues:
    Some times users personal information is stored in cookies and if someone hack the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by different domains and lead to security issues.

    4) Sensitive information:
    Some sites may write and store your sensitive information in cookies, which should not be allowed due to privacy concerns.

    This should be enough to know what cookies are. If you want more cookie info see Cookie Central page.

    Some Major Test cases for web application cookie testing:

    The first obvious test case is to test if your application is writing cookies properly on disk. You can use the Cookie Tester application also if you don’t have any web application to test but you want to understand the cookie concept for testing.

    Test cases: 

    1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.

    2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.

    3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.

    4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)

    5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.

    6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavīor of the pages.

    7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.

    8 ) Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user.

    9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.

    10) If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.

    These are some Major test cases to be considered while testing website cookies. You can write multiple test cases from these test cases by performing various combinations. If you have some different application scenario, you can mention your test cases in comments below.

    http://www.softwaretestinghelp.com/website-cookie-testing-test-cases/#more-107

  • 软件产品的可用性测试(转)

    2008-11-05 17:12:46

    关于可用性的测试和评估,在国外现在已经形成一个新的专业,称为可用性工程(Usability Engineering)。由于是一个专业,因此就有专门的人员来从事这项工作,并发展出一整套的方法和技术来进行可用性的测试和评估。根据我们给软件可用性所下的定义,一个软件可用性的测试和评估应该遵循以下原则:
    1O%dhs @vu15441451Testing软件测试网 q5A c(w+e"u3sJ2iv
    (1)最具有权威性的可用性测试和评估不应该是专业技术人员,而应该是产品的用户。因为无论这些专业技术人员的水平有多高,无论他们使用的方法和技术有多先进,最后起决定作用还是用户对产品的满意程度。因此,对软件可用性的测试和评估,主要应由用户来完成。 51Testing软件测试网m%j)EVW;t RYV W
    51Testing软件测试网5U h)q5j7fC+uP*x
    (2)软件的可用性测试和评估是一个过程,这个过程早在产品的初样阶段就开始了。因此一个软件在设计时反复征求用户意见的过程应与可用性测试和评估过程结合起来进行。当然,在设计阶段反复征求意见的过程是后来可用性测试的基础,不能取代真正的可用性测试。但是如果没有设计阶段反复征求意见的过程,仅靠用户最后对产品的一两次评估,是不能全面反映出软件的可用性。51Testing软件测试网 I(l m"q/E0Y

    VBz L%|b d154414(3)软件的可用性测试必须是在用户的实际工作任务和操作环境下进行。可用性测试和评估不能靠发几张调查表,让用户填写完后,经过简单的统计分析就下结论。可用性测试必须是用户在实际操作以后,根据其完成任务的结果,进行客观的分析和评估。51Testing软件测试网n4V1fK{(D h

    +^'Fe{v@.f&q7T154414(4)要选择有广泛代表性的用户。因为对软件可用性的一条重要要求就是系统应该适合绝大多数人使用,并让绝大多数人都感到满意。因此参加测试的人必须具有代表性,应能代表最广大的用户。51Testing软件测试网@/I#]1Va pf/Jm
    51Testing软件测试网r K1d.u5^&l
    软件是高新技术,人们对软件的认识通常是从技术上来考虑,似乎技术越先进,水平越高,系统就越好。所谓人们的认识,不仅包括设计人员和管理人员,而且包括普通用户。因此提出软件的可用性问题,不仅是设计人员思想上的一场革命,也是普通人认识上的一场革命。
    9av/\X9i&j154414
    /HPW$s2z;~B ^%m{'E154414在软件产品开发过程中,软件可用性的测试是必不可少的一环。可用性是从人的角度来看软件系统是否易用,高效,使人满意。作为一种特殊的IT产品,它的可用性显得格外重要:
    7Yz@{] h154414
    ty)E&|x M,hT)QS Cs'[&B154414考察软件系统的可用性一般来讲就是测试软件的可用性是否达到了用户的要求。目前的方法大致可以分为四类,用户模型法,用户调查法,专家评审法和用户测试法。
    (u S8pJ.o4t*d8}0K(V8d j154414
    2l*mIU'b1c154414用户模型法是用数学模型来模拟人机交互的过程。这种方法把人机交互的过程看作是解决问题的过程。它认为人使用软件系统是有目的的。而一个大的目的可以被细分为许多小的目的。这了完成每个小的目的,又有不同的动作和方法可供选择,每一个细小的过程都可以计算完成的时间。这个模型就可以用来预测用户完成任务的时间了。这个方法特别适合于无法进行用户测试的情形。在人机交互领域中最著名的预测模型是GOMS(Goals, Operators, Methods, Selections)模型。51Testing软件测试网:e?P`#WrE

    d9Qs.O0o)?E |154414用户调查法包括问卷调查法和访谈法。这两种方法是社会科学研究,市场研究和人机交互学中沿用已久的技术,适用于快速评估,可用性测试和实地研究,以了解事实,行为,信仰和看法。51Testing软件测试网0V7M2y@|oL jujo5N

    4n$T'|:V n)xA:c;e{|L154414访谈与普通对话的相似程度取决于待了解的问题和访谈和类型。访谈有4种主要类型:开放开(或非结构化)访谈,结构化访谈,半结构化采谈和集体访谈.具体就采用何种访谈技术取决于评估目标,待解决的问题和选用的评估范型。例如,如果目标是大致了解用户对新设计构思(如交互设计)的反映,那么非正式的开放式访谈通常是最好的选择。但如果目标是搜集关于特定特征(如新型WEB浏览器的布局)的反馈,那么,结构化的访谈调查通常更为适合,因为,它的目标和问题更为具体。
    [.G uh c,]Y F154414
    htI(h(g^154414调查问卷是用于收集统计数据和用户意见的常用方法,它与访谈有些相似,也是用来了解用户的满意度和遇到的问题。问卷需要认真的设计。可以是开放式的问题,也可以是封闭的问题,但必须措辞明确,避免可能的误导问题,保证所收集的数据有高的可信度。在学术论文中常见的可用性问卷包括:用户交互满意度问卷(questionnaire for user interaction satisfaction, QUIS),软件可用性测量目录(software usability measurement inventory, SUMI)计算机系统可用性问卷(computer system usability questionnaire, CSUQ).
    r D'vl3\7eE7g154414
    `*m,Ep\G_e&XF154414专家评审法分为启发式评估和走查法。启发式评估是由Jakob Nielsen和他的同事们开发的非正式可用性检查技术,使用一套相对简单,通用,有启发性的可用性原则来进行可用性评估。具体方法是,专家使用一组称为“启发式原则”的可用性规则作为指导,评定用户界面元素(如对话框,菜单,在线帮助等)是否符合这些原则。在进行启发式评估时,专家采取“角色扮演”的方法,模拟典型用户使用产品的情形,从中找出潜在的问题。参与评估的专家数目可以不同。由于启发式评估不需要用户参与,也不需要特殊设备,所以它的成本相对较低,而且较为快捷,因此也称为“经济评估法”。51Testing软件测试网:k1| y-B0rx
    51Testing软件测试网q'iq;r&m*~ SH f
    走查法包括认知走查和协作走查,是从用户
    学习使用系统的角度来评估系统的可用性的。这种方法主要用来发现新用户使用系统时可能遇到的问题,尤其适用于没有任何用户培训和系统。走查就是逐步检查使用系统执行的过程,从中找出可用性问题。走查的重点非常明确,适合于评估系统的一小部分。
    M)E!oG7uO154414
    c(@;nhvM154414用户测试法:可用性既然是评价软件质量的标准,而且是从用户的角度出发,评价起来当然少不了用户的参与,在所有的可用性评估法中,最有效的就是用户测试法了。该方法是在测试中,让真正的用户使用软件系统,而测试人员在旁边观察,记录,测量。因此,用户测试法最能反映用户的要求和需要的。根据测试的地点不同,用户测试可分为实验室测试和现场测试。实验室测试是在可用性实验室里进行的,而现场测试则是由可用性测试人员到用户的实际使用现场进行观察和测试。根据试验设计的方法不同,用户测试以可分为有控制条件的统计试验和非正式的可用性观察测试。这两种试验方法在某些情况下也可以混合使用,所以经常被笼统的称为可用性试验。可用性的实验就是在产品实际应用的环境之外,就特定的环境、条件、使用者进行测试,藉以记录系统的表现,更能对特定的因果关系进行验证,得到量化的数据。
    {*mKeP.i O \15441451Testing软件测试网P2}(hJ6N!zN ?6H-D
    用户测试常用的方法包括实验室的实验、焦点团体讨论(Focus Group Discussion)及发声思考(Thinking Aloud)。焦点团体讨论是一般市场营销研究常用的手段。邀请一群使用者,一般五至八人一起就几个焦点问题进行讨论,由一位主持人掌控讨论的方向,围绕着预定的题目进行,让参与者都能畅所欲言并热烈讨论。不过若针对软件进行讨论,必须要考虑系统的规模与使用的体验,对企业的软件来说,一次的讨论绝对不够,必须要进行一系列的讨论与评价。 51Testing软件测试网7c |#| FB5XQ6V
    51Testing软件测试网;P-H8FaeK
    发声思考法是心理学研究所用的研究方法,在国外被人机交互或可用性的研究者用来评估软件的使用。发声思考法要求受测者使用指定的系统,边用边说话,说出使用之时心中想的一切,包括困难、问题、感觉等。这个方法能从每位受测者的评价过程中收集到相当大的信息,而所需邀请的受测者也不多,在国外的相关业界可说是标准的软件使用质量评价方法。
    .nN^/ui0QM,{15441451Testing软件测试网n+_*o P&uh;d
    小结一下,以上介绍的可用性工程方法都是多年工业实践证明切实有效的。在各个方法的实际运用中,可以根据具体情况对方法执行上的某些细节灵活掌握。在特定的产品开发项目中,如何选择所使用的可用性工程方法直接关系到可用性工程的运用效果。在这里一定要综合考虑开发过程当时所处的阶段、各种方法所能提供的信息以及它们所需要的技能、人员、时间、设备等方面的资源,在此基础上,选择一组适合具体情况、能够互补和相互衔接的方法,使得以用户为中心的设计理念得到尽可能的充分体现。
  • 容错性测试

    2008-11-05 17:08:34

     容错性测试包括两个方面的测试:
    1. 输入异常数据或进行异常操作,以检验系统的保护性。如果系统的容错性好,系统只给出提示或内部消化掉,而不会导致系统出错甚至崩溃。
    2. 灾难恢复性测试。通过各种手段,让软件强制性地发生故障,然后验证系统已保存的用户数据是否丢失、系统和数据是否能很快恢复。
    关于自动恢复测试的概念可以看出,容错测试是一种对抗性的测试过程。当测试软件出现故障时,如何进行故障的转移与恢复有用的数据。故障转移(failover)是确保测试对象在出现故障时,能成功地将运行的系统或系统某一关键部分转移到其他设备上继续运行,即备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务,不影响用户的使用。要进行故障转移的全面测试,一个好的方法是将测试系统全部的对象用一张系统结构图描绘出来,以图中所有可能发生的故障点设计测试用例。在系统结构图中存在单点失效的关键对象,就是设计的缺陷。

  • 数据库测试(转)

    2008-11-05 09:50:57

     

     随着软件业的迅猛发展,我们的开发也从以前的单层结构进入了三层架构甚至现在多层架构的设计,而数据库从以前一个默默无闻的后台仓库,逐渐成为了数据库系统,而数据库开发设计人员成为了炙手可热的核心人员。以前我们往往把数据库操作写在应用层,从而提高各个模块的独立性和易用性,而现在越来越多的数据库操作被作为存储过程直接放在数据库上进行执行来提高执行效率和提高安全性。

      数据库开发既然在软件开发的比重逐步提高,随之而来的问题也突出。我们以前往往重视对代码的测试工作,随着流程技术的日益完善,软件质量得到了大幅度的提高,但数据库方面的测试仍然处于空白。我们从来没有真正将数据库作为一个独立的系统进行测试,而是通过对代码的测试工作间接对数据库进行一定的测试。随着数据库开发的日益升温,数据库测试也需要独立出来进行符合自身特点的测试工作。数据库开发和应用开发并没有实质上的区别,所以软件测试的方法同样适用于数据库测试。

      从测试过程的角度来说我们也可以把数据库测试分为:

      系统测试

      传统软件系统测试的测试重点是需求覆盖,而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例如存储过程,视图,触发器,约束,规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相同,当设计文档变化时我们同样要验证改修改是否落实到数据库上。

      这个阶段我们的测试主要通过数据库设计评审来实现。

      集成测试

      集成测试是主要针对接口进行的测试工作,从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说,需要考虑的是:

      数据项的修改操作;
      数据项的增加操作;
      数据项的删除操作;
      数据表增加满;
      数据表删除空;
      删除空表中的记录;
      数据表的并发操作;
      针对存储过程的接口测试;
      结合业务逻辑做关联表的接口测试;
      同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试。

      单元测试

      单元测试侧重于逻辑覆盖,相对对于复杂的代码来说,数据库开发的单元测试相对简单些,可以通过语句覆盖和走读的方式完成系统测试相对来说比较困难,这要求有很高的数据库设计能力和丰富的数据库测试经验。而集成测试和单元测试就相对简单了。

      而我们也可以从测试关注点的角度对数据库进行分类:

      功能测试
      对数据库功能的测试我们可以依赖与工具进行。

      DBunit
      一款开源的数据库功能测试框架,可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试,对输入输出进行校验。

      QTP
      大名鼎鼎的自动测试工具,通过对对象的捕捉识别,我们可以通过QTP来模拟用户的操作流程,通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒。

      DataFactory
      一款优秀的数据库数据自动生成工具,通过它你可以轻松的生成任意结构数据库,对数据库进行填充,帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试

      数据库性能

      虽然我们的硬件最近几年进步很快,但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的,如此庞大的数据量在大量并发连接操作时,我们不能像以前一样随意的使用查询,连接查询,嵌套查询,视图,这些操作如果不当会给系统带来非常巨大的压力,严重影响系统性能。

      性能优化分4部分:

      1.物理存储方面
      2.逻辑设计方面
      3.数据库的参数调整
      4.SQL语句优化

      我们如何对性能方面进行测试呢,业界也提供了很多工具。

      通过数据库系统的SQL语句分析工具,我们可以分析得到数据库语句执行的瓶颈,从而优化SQL语句。

      Loadrunner
      这个不用多说,我们可以通过对协议的编程来对数据库做压力测试。

      Swingbench(这是一个重量级别的feature,类似LR,而且非常强大,只不过专门针对oracle而已)

      数据库厂商也意识到这点,例如:

      oracle11g已经提供了real application test,提供数据库性能测试,分析系统的应用瓶颈。

      还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。

      安全测试

      软件日益复杂,而数据又成为了系统中重中之重的核心,从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端。自从SQL 注入攻击被发现,冒失万无一失的数据库一下从后台变为了前台,而一旦数据库被攻破,整个系统也会暴露在黑客的手下,通过数据库强大的存储过程,黑客可以轻松的获得整个系统的权限。而SQL的注入看似简单缺很难防范,对于安全测试来说,如何防范系统被注入是测试的难点。业界也有相关的数据库注入检测工具,来帮助用户对自身系统进行安全检测。

      对于这点来说业界也有标准,例如ISO IEC 21827,也叫做SSE CMM 3.0,是CMM和ISO的集成的产物,专门针对系统安全领域的另外一方面,数据库的健壮性,容错性和恢复能力也是我们测试的要点,我们也可以发现功能测试,性能测试,安全测试,是一个由简到繁的过程,也是数据库测试人员需要逐步掌握的技能,这也是以后公司对数据库测试人员的要求。

  • 网站安全性测试(转)

    2008-11-05 09:49:00

    一个完整的Web安全体系测试可以从部署与基础结构,输入验证,身份验证,授权,配置管理,敏感数据,会话管理,加密,参数操作,异常管理,审核和日志记录等几个方面入手

      数据加密:某些数据需要进行信息加密和过滤后才能进行数据传输,例如用户信用卡信  息、用户登陆密码信息等。此时需要进行相应的其他操作,如存储到数据库、解密发送要用户电子邮箱或者客户浏览器。目前的加密算法越来越多,越来越复杂,但一般数据加密的过程时可逆的,也就是说能进行加密,同时需要能进行解密!

      登录: 一般的应用站点都会使用登录或者注册后使用的方式,因此,必须对用户名和匹配的密码进行校验,以阻止非法用户登录。在进行登陆测试的时候,需要考虑输入的密码是否对大小写敏感、是否有长度和条件限制,最多可以尝试多少次登录,哪些页面或者文件需要登录后才能访问/下载等。

      超时限制:WEB应用系统需要有是否超时的限制,当用户长时间不作任何操作的时候, 需要重新登录才能使用其功能。

      SSL:越来越多的站点使用SSL安全协议进行传送。SSL是Security Socket Lauer(安全套接字协议层)的缩写,是由Netscape首先发表的网络数据安全传输协议。SSL是利用公开密钥/私有密钥的加密技术。(RSA),在位于HTTP层和TCP层之间,建立用户与服务器之间的加密通信,确保所传递信息的安全性。SSL是工作在公共密钥和私人密钥基础上的,任何用户都可以获得公共密钥来加密数据,但解密数据必须要通过相应的私人密钥。进入一个SSL站点后,可以看到浏览器出现警告信息,然后地址栏的http变成 https,在做SSL测试的时候,需要确认这些特点,以及是否有时间链接限制等一系列相关的安全保护。

      服务器脚本语言:脚本语言是常见的安全隐患。每种语言的细节有所不同。有些   脚本允许访问根目录。其他只允许访问邮件服务器,但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言,并研究该语言的缺陷。还要需要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。

      注:黑客利用脚本允许访问根目录的这个安全隐患特性攻击网站。这个网站包含了脚本代码(有允许访问根目录的特性)就可能有这个安全隐患。

      日志文件:在服务器上,要验证服务器的日志是否正常工作,例如CPU的占用率是否很高,是否有例外的进程占用,所有的事务处理是否被记录等。

      目录:WEB的目录安全是不容忽视的一个因素。如果WEB程序或WEB服务器的处理不适当,通过简单的URL替换和推测,会将整个WEB目录完全暴露给用户,这样会造成很大的风险和安全性隐患。我们可以使用一定的解决方式,如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限,将这种隐患降低到最小程度。

  • 一个安全测试的checklist(转)

    2008-11-05 09:47:41

     

       1. 不登录系统,直接输入登录后的页面的url是否可以访问

      2. 不登录系统,直接输入下载文件的url是否可以下载,如输入http://url/download?name=file是否可以下载文件file

      3. 退出登录后按后退按钮能否访问之前的页面

      4. ID/密码验证方式中能否使用简单密码。如密码标准为6位以上,字母和数字混合,不能包含ID,连续的字母或数字不能超过n位

      5. 重要信息(如密码,身份证号码,信用卡号等)在输入或查询时是否用明文显示;在浏览器地址栏里输入命令javascrīpt:alert(doucument.cookie)时是否有重要信息;在html源码中能否看到重要信息

      6. 手动更改URL中的参数值能否访问没有权限访问的页面。如普通用户对应的url中的参数为l=e,高级用户对应的url中的参数为l=s,以普通用户的身份登录系统后将url中的参数e改为s来访问本没有权限访问的页面

      7. url里不可修改的参数是否可以被修改

      8. 上传与服务器端语言(jsp、asp、php)一样扩展名的文件或exe等可执行文件后,确认在服务器端是否可直接运行

      9. 注册用户时是否可以以'--,' or 1=1 --等做为用户名

      10. 传送给服务器的参数(如查询关键字、url中的参数等)中包含特殊字符(','and 1=1 --,' and 1=0 --,'or 1=0 --)时是否可以正常处理

      11. 执行新增操作时,在所有的输入框中输入脚本标签(<scrīpt>alert("")</scrīpt>)后能否保存

      12. 在url中输入下面的地址是否可以下载:http://url/download.jsp?file=C:\windows\system32\drivers\etc\hosts,http://url/download.jsp?file=/etc/passwd

      13. 是否对session的有效期进行处理

      14. 错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等

      15. ID/密码验证方式中,同一个账号在不同的机器上不能同时登录

      16. ID/密码验证方式中,连续数次输入错误密码后该账户是否被锁定

      17. 新增或修改重要信息(密码、身份证号码、信用卡号等)时是否有自动完成功能(在form标签中使用autocomplete=off来关闭自动完成功能

Open Toolbar