发布新日志

  • 网站安全性测试(转)

    静澜 发布于 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服务器的目录访问权限,将这种隐患降低到最小程度。

  • 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

  • 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,非常适合于对输入数据进行消毒处理。

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

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

    静澜 发布于 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权限。
     
      为了寻找后门,必须完整地检查源代码,查找基于非预期参数的条件跳转语句。例如,如果某个程序是通过双击图标而被调用的,那么要确保代码不会因为从命令行用特殊参数调用而跳转到某个管理或特权模式。

  • 一个性能测试的案例(转自51)

    静澜 发布于 2008-12-08 17:32:31

    利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误,但是错误总是存在的,如果开发者找不到错误,那么,客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一,很多软件开发组织将30%—40%甚至更多的项目资源用在测试上,软件测试技术和软件测试策略受到了高度的重视和广泛的应用。

      本文不想就软件测试技术和软件测试策略作深入的理论分析,而是列举一个在软件系统测试阶段进行的压力测试实例,希望能通过这个实例与从事软件测试相关工作的朋友进行交流。

      首先介绍一下实例中软件的项目背景,该软件是一个典型的三层C/S架构的MIS系统(客户端/应用服务器/数据库管),中间层是业务逻辑层,应用服务器处理所有的业务逻辑,但应用服务器本身不提供负载均衡的能力,而是利用开发工具提供的ORB(对象请求代理)软件保证多个应用服务器间的负载均衡。本次测试的目的是:进行单个应用服务器的压力测试,找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是:假定在实际环中,用户只启用一个应用服务器进行所有的业务处理。方法是:按照正常业务压力估算值的1~10倍进行测试,考察应用服务器的运行情况。

      压力测试的详细计划如下:

      压力测试计划

      1、测试计划名称

      XXX系统压力测试计划。

      2、测试内容

      2.1 背景

      本次测试中的压力测试是指模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时 间运行测试软件来测试被测系统的可靠性,同时还要测试被测系统的响应时间。

      用户的实际使用环境:

      ◇由两台IBM XSeries250 PC Server组成的Microsoft Cluster;

      ◇数据库管理系统采用Oracle8.1.6;

      ◇应用服务器程序和数据库管理系统同时运行在Microsoft Cluster上。

      ◇有200个用户使用客户端软件进行业务处理,每年通过软件进行处理的总业务量为:150万笔业务/年。

      2.2 测试项

      应用服务器的压力测试;

      2.3 不被测试的特性

      ◇系统的客户端应用程序的内部功能;

      ◇数据库中的数据量对程序性能的影响。

      3、测试计划

      3.1 测试强度估算

      测试压力估算时采用如下原则:

      ◇全年的业务量集中在8个月完成,每个月20个工作日,每个工作日8个小时;

      ◇采用80—20原理,每个工作日中80%的业务在20%的时间内完成,即每天80%的业务在1.6小时内完成;

      测试压力的估算结果:

      去年全年处理业务约100万笔,其中15%的业务处理每笔业务需对应用服务器提交7次请求;

      70%的业务处理每笔业务需对应用服务器提交5次请求;其余15%的业务每笔业务向应用服务器提交3次请求。根据以往统计结果,每年的业务增量为15%,考虑到今后三年业务发展的需 要,测试需按现有业务量的2倍进行。

      每年总的请求数量为:(100*15%*7+100*70%*5+100*15%*3)*2=300万次/年。

      每天的请求数量为:300/160=1.875万次/天。

      每秒的请求数量为:(18750*80%)/(8*20%*3600)=2.60次/秒。

      正常情况下,应用服务器处理请求的能力应达到:3次/秒。

      3.2 测试环境准备

      3.2.1 基本硬件及软件环境的准备

      1) 网络环境:公司内部的以太网,与服务器的连接速率为100M,与客户端的连接速率为10/100M自适应。

      2)使用两台IBM XSeries250(1G内存)PC Server作Microsoft Cluster,安装系统软件 Windows 2000 Advance Server及Microsoft Cluster Server(MSCS)。

      3) 数据库管理系统的安装及配置:在测试用的IBM XSeries服务器上安装Oracle8.1.6,数据 库采用Oracle Fail Safe(ofs)的Active/Passive配置。 安装数据库管理系统及支撑软件(包括VisiBroker和BDE Administrator)。

      4) 安装被测的应用服务器程序。

      5) 客户端的PC机:10台(PⅢ600/128M RAM)。

      3.2.2 系统客户端测试程序的编写系统客户端测试程序使用Delphi编写,要求测试程序实现如下功能:

      1) 模拟一个主要的向应用服务器发送请求并接收响应信息的功能。要求交替模拟两种情况:第一种,发送的请求至少包括10个参数,参数类型涵盖字符、日期、数字种类型;接收的响应信息不少于1个参数;第二种,发送的请求不少于1个参数;接收的响应信息至少包括10个参数,参数类型涵盖字符、日期、数字种类型。

      2) 必须能够通过参数设定在每台PC机上运行的客户端测试程序个数、请求的时间间隔(单位:毫秒)、运行时间(单位:小时)。

      3) 在数据库中建立测试记录表,生成测试记录,向数据库写入测试记录的功能不通过被测的应用服务器实现。日志内容包括:发送测试请求的机器名、客户端测试程序序号、发出请求时间、收到响应时间、处理是否成功。表名:TEST_LOG,字段名:MACHINE、ID、START_TIME、 END_TIME、FLAG。

      3.2.3 系统本底数据的准备

      为考察系统运行一段时间后系统的响应性能,参照实际运行情况及发展进行系统的本底数据准备。业务处理中涉及到的业务表中都要求按设计规模进行本底数据的准备。要求准备的数据记录的有效性符合系统要求,数据有效性的具体要求参见数据库设计及系统设计文档。

     3.3 破坏性测试

      按照设计连接的客户端连接数量进行测试,把应用服务器处理请求的设计频度增加1-10倍,分别测试出现错误的状态和和出现错误的比率,考察是否出现不可恢复错误,系统设计要考 虑出现严重错误情况下负荷减轻错误自动恢复的实现方法。

      计划时间:2天;这个时间包括破坏性的修复和自动恢复的实现需要的时间。

      在测试过程中每10分钟记录一次IBM Xseries PC Server的内存及CPU使用情况,包括被测程序的内存占用百分比、数据库管理系统的内存占用百分比、操作系统的内存占用百分比。

      3.4 强度稳定性测试

      选择一种负荷比设计负荷重的情况(应用服务器处理请求的频度为应用服务器处理请求的设计频度的1.5倍),进行24小时稳定性测试。

      3.5 测试方法和工具

      黑盒测试

      测试工具:无外购的测试工具,自己编制的测试工具。

      3.6 测试时间计划

      3.6.1 环境准备:2天。

      其中:基本硬件、软件环境及系统本底数据的准备:1天,

      系统客户端测试程序的编写及测试:1天。

      3.6.2 破环性测试:2天。

      3.6.3 强度稳定性测试:1天。

      3.7 测试中的问题及处理

      3.7.1 暂停标准和再启动要求

      暂停标准:被测试软件在强度稳定性测试中频繁出现异常(每小时出现1次以上)时。用户或公司要求暂停测试时。

      再启动要求:通过调试后,预计被测试软件的可靠性有所提高时,可再次启动测试。

      3.7.2 不可预见问题

      不可预见问题包括:

      ◇测试环境被破坏而导致测试无法进行;

      ◇当出现上述不可预见问题时,测试终止,就已完成的测试内容编制测试总结报告,并在报告中说明测试终止的原因。

      3.8 测试报告 2002.06.21

      测试总结报告提交日期:2002.06.21。

      3.8.1 应生成的测试文件

      测试记录(测试负责人和参与测试的人员签字);

      测试总结报告。

      3.8.2 测试总结报告中必须包含的内容

      被测试软件名称、测试项、测试环境;

      被测试软件的压力测试结论:响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间,并发数与失败的关系。

      4、人员和职责

      4.1 职责

      测试工程师:负责编写测试计划,组织测试,对测试过程进行记录,收集、整理测试记录数据,对测试结果进行分析,编写测试总结报告。

      软件工程师:负责编写、调试客户端测试软件;数据库管理系统的安装、ofs配置及系统的本底数据准备。

      系统工程师:负责测试用的硬件维护及操作系统安装、MSCS配置。

      总工程师:负责对测试计划及测试总结报告进行批准。

      用户:必要时可参加测试,并提出具体的测试要求;可要求暂停测试。

      4.2 人员和训练要求

      本次测试无特别的人员及培训要求。

      5、批准

      本测试计划必须经过总工程师批准后才能开始实施。

  • 根据性能需求设计性能测试用例

    静澜 发布于 2008-11-28 13:23:10

    本文出自huruihai的51Testing软件测试博客:http://www.51testing.com/?41972

    某网站提供会员模板下载、上传、购买、支付等功能,目前进入性能测试阶段,通过性能需求可以了解到主要有以下几个性能指标需要进行测试:51Testing软件测试网ED3RW:Nw gN
    产品页面刷新性能
    x n?j+f+t FJ0产品上传性能
    .\C4Uk;q m0D%{(}0产品下载性能51Testing软件测试网FJ^-}tnUo m
    搜索性能51Testing软件测试网L\ c5_qr K4i
    目前给出的指标为:51Testing软件测试网8Ug7P#m8I)~d o4w2Y
    延迟:51Testing软件测试网dM5E c6@F?'S
    测试项          响应时间      抖动 备注    51Testing软件测试网 UjP,x{Fp9R
    产品页面刷新     <5秒         <2秒     51Testing软件测试网 p(j-[K9VU.O |
    产品下载相应时间  <4秒        <2秒  

    51Testing软件测试网l&p8T/Q blf)?
    吞吐量:51Testing软件测试网8F-v2kNi*HG@j q }+g']
    编号      项                       吞吐量    51Testing软件测试网j}T| N Y0p-k!m!Tu a
    Perf.T.1 所有登录用户在线状态更改频率 每10分钟1次    51Testing软件测试网 taA&|J B(f
    Perf.T.2 每日页面平均访问量          60000次   
    $xp0{c^0Perf.T.3 每日下载量                 50000   
    U9d1d%Jz&m0Perf.T.4 平均每日新增会员数量         500   
    3R|"ttq,| J F0Perf.T.5 高峰同一模板下载量           100用户并发下载   
    8Ee"l-i/Fc}"G:}0Perf.T.6 高峰不同模板下载量           150用户并发下载 


    1AYC"I~qPn^0容量:
    [+~YetI0编号      项             容量    51Testing软件测试网)BR/x-vKU.M
    Perf.C.1 用户数          <=100万   
    | c7Z v4sp2@0Perf.C.2 活动用户数       10000    51Testing软件测试网Q4KA!nx W;QO7[
    Perf.C.3 模板中心总用户数  <=25万 

    51Testing软件测试网wktv6D}gl i-`
    根据如上性能需求及数据我们该如何设计性能测试用例及场景呢?(可以说给出的性能需求很垃圾,没有丝毫价值,但没办法还是点做啊)
    |.L}|u9mS0首先,我不去在乎它要求的性能是什么,我只需要去做在一定的测试环境下对系统进行压力测试,找到各个性能指标的临界点就好了,至于是否达到性能指标,在和性能需求对照编写测试报告即可。

    51Testing软件测试网2JmZ3d(?GYN|m"|
    所以,针对这几个需要进行性能测试的页面,我们做一下分析,如何设计场景才能尽可能准确地体现出系统的性能:
    c6z$G6S+X2{3`0先说一下搜索页面
    *a;A c^F YA~"p0搜 索页面根据对项目的了解,搜索后,将所有符合条件的结果遍历出来,显示在前台,每页的显示数量是一定的,超出的部分分页显示。根据上面的描述我们可以看出 搜索结果是在将符合条件的所有结果集均发送到前台页面,对于页面显示对性能的消耗我们可以忽略不计,主要的压力来自数据的传输、sql的执行及应用服务器 的处理过程,所以我可以从两个方面设计场景:

    w7m0z7Dz??*U8x0a、虚拟用户一定,不同数据库数量级的情况下,搜索的性能
    W,NtbLT&g%}0如 何确定虚拟用户的数量成为一个关键,我们可以让客户提供一个常规情况下每天访问用户数(如果没有实际数据可参考,可以根据产品方案中期望的用户数来代 替),我们就用这个用户数来进行测试;再来分析一下不同的数据库数量级,如果系统运营1年的产品数据量是5万条,那么我们就根据这个值分别取1W条、3W 条、5W条、10W条、20W条数据量来进行测试(具体的分法可以根据实际情况而定),所以对于这个测试目标,我们可以设计5个场景进行:51Testing软件测试网,}b u%b h1P
     51Testing软件测试网x8?0i@ i
    虚拟用户数 数据库数量级 录制页面 并发用户数 执行时间 思考时间    51Testing软件测试网H.A"p:{@i0v
    100      10000       搜索页面 随机产生   30分钟   加入思考时间    51Testing软件测试网 q4j)F6s$h7HL
    100      30000       搜索页面 随机产生   30分钟   加入思考时间   
    z.z![A O_ X9p%Q0100      50000       搜索页面 随机产生   30分钟   加入思考时间   
    yC gj/B-rV0100      100000      搜索页面 随机产生   30分钟   加入思考时间   
    Y$i#@9Jnsr0100      200000      搜索页面 随机产生   30分钟   加入思考时间  51Testing软件测试网I2W[PA%k
    b、一定数据库数量级,不同量虚拟用户的情况下,搜索的性能
    MNx ?#w _X0我们定下来一个常规的数据库数据量,在数据量不变的情况下逐步增加虚拟用户数,测试一下不同虚拟用户压力下系统的性能
    9Ru*L&p*_$P9_0 
    6E w9jJe'Vh1oh Y;Z0虚拟用户数 数据库数量级 录制页面 并发用户数 执行时间 思考时间    51Testing软件测试网`9b6X'qa3^ gX
    50        50000      搜索页面 随机产生   30分钟   加入思考时间    51Testing软件测试网hv6T}y:z9^.b!g
    80        50000      搜索页面 随机产生   30分钟   加入思考时间   
    F9b izn0100       50000      搜索页面 随机产生   30分钟   加入思考时间    51Testing软件测试网V2FZ%tIo {4l#v
    120       50000      搜索页面 随机产生   30分钟   加入思考时间   
    rD/xf8D]0[2l6^(b0150       50000      搜索页面 随机产生   30分钟   加入思考时间 

    产品上传51Testing软件测试网l)M jtJ"e0K]
       影响上传性能的主要因素有上传文件的大小和上传的请求数,所以我们就从这两个方面设计用例。51Testing软件测试网0y4r _pRA;F9qn3b-X(Z
       a、虚拟用户数一定,上传不同大小的文件
    p!xMe$N,p0 
    v w;\.n-o4B\|0虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间   
    k|*`h&M050        100k       上传页面 随机产生   30分钟   取消思考时间   
    GduW$Zo1L050        300k       上传页面 随机产生   30分钟   取消思考时间    51Testing软件测试网uC2~!ji8z[
    50        500k       上传页面 随机产生   30分钟   取消思考时间   
    GH2US.e G050        800k       上传页面 随机产生   30分钟   取消思考时间   
    }HY@ Vd{)L G u,^050        1M         上传页面 随机产生   30分钟   取消思考时间 

       b、上传文件大小一定,不同量的虚拟用户51Testing软件测试网 O*z3L*v|
     
    8rG Mnn5X!Ii0虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间   
    qCO?4x me%DI020       300k        上传页面 随机产生 30分钟     取消思考时间   
    t;zq6v8zHyA\050       300k        上传页面 随机产生 30分钟     取消思考时间   
    -G(ec.Z+P:u`)Z080       300k        上传页面 随机产生 30分钟     取消思考时间   
    *dvO Q&\x6@&aq0100      300k        上传页面 随机产生 30分钟     取消思考时间 

    产品下载51Testing软件测试网x)k+TkUph]W
    影响下载性能的主要因素有下载文件的大小和下载的请求数,所以我们就从这两个方面设计用例

    @~ VP{|L5u'J6Ri0   a、虚拟用户数一定,下载不同大小的文件
    n-H(TF:X*h8@i6C0 
    ;o v ],R5z%dsK5A5W0虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间   
    R2U+[l r Y@?|;z050        100k       下载页面 随机产生 30分钟 取消思考时间   
    $JeuZ8kH5|050        300k       下载页面 随机产生 30分钟 取消思考时间   
    iC]nSB/Gs1gtn050        500k       下载页面 随机产生 30分钟 取消思考时间   
    f r Mh)m*g L050        800k       下载页面 随机产生 30分钟 取消思考时间    51Testing软件测试网9@$F5nx!eT5dr,A{/N
    50        1M         下载页面 随机产生 30分钟 取消思考时间 

       b、下载文件大小一定,不同量的虚拟用户51Testing软件测试网2~)W T"hc H Q)w
     
    2F^(i.O Cn2Q3@m#m7t[6mx0虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间    51Testing软件测试网1i*` eqLXqu"`
    20         300k      下载页面 随机产生  30分钟    取消思考时间   
    v7~E3~5rv ?,~3l050         300k      下载页面 随机产生  30分钟    取消思考时间    51Testing软件测试网3T[0i"[9L3d2oPK.U
    80         300k      下载页面 随机产生  30分钟    取消思考时间    51Testing软件测试网@6?&G-J"Nm-T
    100        300k      下载页面 随机产生  30分钟    取消思考时间 
  • 性能测试—并发用户数的估算(转)

    静澜 发布于 2008-11-05 09:52:18

     

    在实际的性能测试工作中,测试人员常常会关心到并发用户数,也就是从业务角度关注究竟应该设置多少个并发数比较合理,以下是一个估算并发用户数的方法:

      (1) 计算平均的并发用户数: C = nL/T

      (2) 并发用户数峰值: C’ ≈ C+3根号C

      公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。

      公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

      实例:

      假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。

      则根据公式(1)和公式(2),可以得到:

      C = 400*4/8 = 200

      C’≈200+3*根号200 = 242

  • 测试用例评审检查单(转,有空修改)

    静澜 发布于 2008-12-09 17:00:27

    1       《需求规格说明书》是否评审并建立了基线?
    2       是否按照测试计划时间完成用例编写?
    3       需求新增和变更是否进行了对应的调整?
    4       用例是否按照公司定义的模板进行编写?
    5       测试用例是否覆盖了《需求规格说明书》?
    6       用例编号是否和需求进行对应?  
    7       非功能测试需求或不可测试需求是否在用例中列出并说明?
    8       用例设计是否包含了正面、反面的用例?
    9       每个测试用例是否清楚的填写了测试特性、步骤、预期结果?
    10    步骤/输入数据部分是否清晰,是否具备可操作性?
    11    测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述?
    12    测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法?是否针对需求不同部分设计使用不同设计方法?
    13    重点需求用例设计至少要有三种设计方法?
    14    每个测试用例是否都阐述预期结果和评估该结果的方法?
    15    需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置;表格和数据格式是否有说明或附件?
    16    用例覆盖率是否达到相应质量指标?
    17    用例预期缺陷率是否达到相应质量指标?
  • 快速划分测试用例的优先级(转自51)

    静澜 发布于 2008-12-09 16:19:55

    从未有足够的时间做所有我们需要做的事情,这是在软件项目,尤其在测试中的一个普通的话题。假使你在可用的有限时间内,你如何知道你的测试工作做的最好?你知道当应用程序发布时,总会有些遗漏的缺陷没有被发现。对于测试而言,目标是通过改进产品质量使风险减到最小,并且这可以部分的通过建造一套具体的测试用例来将应用程序按照它的速度完成等方法实现。

    IEEE Standard 610 (1990) 中定义测试用例为:

    1. 为一个为特定目标而开发一组测试输入,执行条件和的期望结果,例如测试某个程序路径或核实是否满足某个特定的需求。

    2.指定输入,预期结果和一组测试项的执行条件的文档 (IEEE Std 829-1983)

     当然,你将发现在项目的生命周期里的每一个应用程序的版本上执行你全部的测试用例是很困难的。但是你将如何知道哪个测试用例必须在每一个版本中执行,什么应该被执行,同时如果你有时间的话,什么又可以被执行?

     给你的测试用例划分优先级别

    你的应用程序不需要十全十美,但它必须迎合你目标用户的需求和期望。为了了解你项目的期望,你需要确定什么是应用程序中最重要的,目标和风险又是什么。

    Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中详细的讨论了这个问题,她在文中注解到:“当我们在详细的计划,设计或编码之前沟通质量目标时,我们有一个更好的机会来避免在最后时刻的质量不匹配,那意味着迎合计划,弥补花费并且赢利将有一个更好的成功的机会。”

    为了测试计划的目的,在你项目版本的进度下,测试执行的组织和安排你的测试用例将帮助达到这些目标。作为这种组织的一部分,我们要考虑每一个测试用例的优先级别。根据优先级别分组你的测试用例将帮助你决定不同类型的版本需要什么样的测试用例,因此计算需要的时间。如果你只有有限的时间,你可以查看什么是最合适。

    Ross Collard"Use Case Testing"一文中说:“测试用例的前10%15%可以发现75%90%的重要缺陷”。

    测试用例的优先级划分将帮助确定找出了这前10%15%的测试用例。

    如何划分测试用例的优先级别

    你曾查看过多少次你的测试用例并且能够很容易的挑选出最重要的一个小的子集?这个答案可能是不经常。停止思考“所有的测试用例都是同等重要”这个问题是非常困难的。当设计测试用例时,分配优先级别是不容易,并且在项目期间里不一定是静止的。然而,我们可以通过构造一个划分优先级别流程的例子来开始处理划分测试用例优先级别的第一步。让我们假设你刚刚根据功能说明书, 用例和其他一些关于你应用程序的目标行为和能力的信息源完成了建立测试用例。现在是时候来为每个测试用例分配一个优先级别了。

    测试用例的优先级别

    首先,你必须确定什么是你优先级别的类型和其暗示着什么。就我们的目的来说, 我们将用一个假设开始,那就是我们可能发现的缺陷的严重程度和那些相应测试用例的优先级别之间是平行的。

    1 –小版本确认测试(Build Verification Tests (BVTs):也叫做“冒烟测试”,一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作,那么在执行这个优先的测试用例之前,试图做其他任何的测试都是没有意义的,因为他们大多数肯定要失败。

    2 – 高(Highs):最常执行以保证功能性是稳定的,目标的行为和能力可以正常的工作,和重要的错误和边界被测试的测试用例的集合。

    3 – 中(Mediums):这是使给出的功能区域或功能变得更详细,检查功能的多数方面包括边界,错误和配置测试的测试用例

    4 – 低(Lows):这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要,只是说他们在项目的生命期间里不是常常被运行,例如GUI,错误信息,可用性,压力和性能测试

    我们将测试用例分成4类:BVTs,高,中和低。现在的问题是将测试用例分到不同的优先级别里。毕竟,优先级别将指出哪些测试用例被认为是需要更频繁的执行的,哪些又不是。

    怎样着手分配优先级别

    1) 随意地分配:

    基于如果你没有足够的时间测试却又至少要保证所有的产品需求已经被确认可以在设想的良好状况下象它们被期望的那样工作的想法,前面这3 步将让你任意的分组测试用例,如果你也停下来思考每个测试用例的测试的内容,它们都将变的很重要。因此只需要:

    I)                     把你所有功能性验证(或基本路径(Happy Path))的测试标注为高优先级别

    II)                   把你所有错误和边界值或确认测试标注为中优先级别

    III)                  把你所有非功能性的测试(例如性能和可用性)标注为低优先级别.

    2) 提升和降级:

    并非所有的功能性测试都一样的重要,并且和边界和非功能性测试一样的重要。思考一下测试的重要性及相对于其他同等优先级别的测试,你想要检查这个功能的频率-考虑质量目标和你项目的需求。

    I)                     把功能性验证测试分为两组:重要和不是十分重要。

    II)                   将“不是十分重要”的能性验证测试降级为中优先级别

    III)                  把错误和边界测试分成两组:重要和不是十分重要

    IV)                将“重要”的错误和边界测试升级为高优先级别

    V)                  把非功能性测试分成两组:重要和不是十分重要

    VI)                把“重要”的非功能性测试升级为中优先级别

    VII)               针对每组高,中和低优先级别的测试用例,重复划分和升级/降级流程直到你达到一个点,可以在不同优先级别之间移动的测试用例的数量到最小。

    3) 识别小版本验证测试用例(Build Verification Tests):

    现在,为了确保小版本是可以测试的并准备好给小组其他成员开始测试,哪些测试用例是必须在每个小版本中都检查呢?

    I)                     将好优先级别的测试用例分成两组:严重和重要的

    II)                   将“严重”的高优先级的测试用例升级为BVT优先级

    注意:不要先识别BVT测试用例!BVT只是高优先级别测试用例的精选,它们已经被确定为对系统和测试是非常重要的。

    在这个流程的最后,就是要检查优先级别的百分比分布情况是:BVT10-15%,高为20-30%,,中为40-60%,低为10-15%

    在升级和降级测试用例时,需要考虑的方面是用户将要求这个功能或功能性的频率是怎样。同样的,对于用户日常的或月尾的活动而言,这种行为的严重性是如何。Robyn Brilliant在测试进度报告中提供了一个清单,你可以在考虑降级或升级测试用例的时候使用

    使用从一到五的一个刻度,从最严重到最少的严重程度,量化可靠性风险如下:

    I)               这个功能的失败将影响用户。

    II)             这个功能的失败将给公司造成重大的影响

    III)            这个功能的失败将引起一个潜在的延期给客户

    IV)          这个功能的失败对公司将有较小的影响

    V)            这个功能的失败没有任何影响

    这个和其相似的刻度可以帮助你达到你测试用例优先级别划分的最后一步。

    总结

    这是一个简化的划分测试用例优先级别过程的例子。然而,在快速组织测试用例和安排测试进度和工作量,及制订项目计划时需要完成哪些测试用例等方面,它可以给你很多帮助。

    记住,你怎样给你的测试任务划分优先级和如何执行测试用例将取决于你在你的项目周期的位置。当你朝发布前进并通过调查和观察确定危险和缺陷出现的地方时,你可能会重新给你的测试用例划分优先级别。向上为每个阶段建立你的测试目标并保证他们在你的测试用例的优先级别上被反映,当它在解释并执行你的计划时,将使你的生活变得容易得多。

    最后,拥有划分了优先级别的测试用例也为你潜在的,待定的自动化项目给出了一个好的起点。比如,自动化BVT中的测试用例,度量收益,改进测试自动化,自动化高优先级的测试用例等方面。

  • 如何有效的对测试人员进行业绩考核?(转载)

    静澜 发布于 2008-11-05 17:29:52

    测试人员主要是三个方面。
            第一,整体
    工作效率。第二,工作结果。第三,过程控制。(针对测试主管或组长)
            1.整体工作效率
            1.1有效工作时间
            主要check指标是每日实际工作时间,按照Ms的标准,一个测试工程师的每天的有效工作时间应该在70%以上。如果只有50%或以下的有效工作时间,那么不能成为好的测试工程师,因为他有能力做得更好。
            1.2是否在制定时间内完成工作任务
            主要check指标是进度偏离度。主要是和测试计划相比,有多少的延期。这个指标计算是:计划时间/实际需用时间。
            当然,本指标未考虑
    其他因素,如开发人员窝工导致的delay。
            2.工作结果
            2.1测试用例的数量和质量
            a,测试用例的数量
            主要
    考核指标是用例编写速度,考核办法是测试用例的个数/写用例所用时间。
            b,测试用例的质量
            主要考核指标是用例编写质量,用于考察文档是由有效的指导了测试工作。考核办法是来自用例的
    bug数目/总bug数目,应该是70%以上才算是质量比较好的用例。
            2.2bug的数量和质量
            a,bug提交的数量
            主要考核指标是提交bug的数量,这个指标根据项目不同而定,不好给出固定经验值。
            b,bug的质量
            主要考核指标是提交bug的质量,即提交的bug,严重程度和,发现路径的复杂程度
            c,发现bug的阶段
            主要考核指标是提交bug的时间段,具体执行是统计在测试的每个阶段,发现bug的比例,特别是严重的bug发现的早晚
            2.3是否及时验证关闭bug
            主要考核指标是验证关闭bug的及时度
            2.4测试自动化程度及收效
            主要考核指标是,测试中自动化运用的含量,也就是
    测试技术含量,成果如何?
            2.5所负责模块的产品总体质量以及用户反馈
            这个总体质量是产品发布之后一段时间才能得出结论,主要是市场,用户对产品的质量、稳定性、性能的反馈。
    考核的主要指标是两个。
            a,根据市场反馈(由经理定性考核)
            b,根据测试人员提交的bug和用户反馈的bug之间的比例,比例越大,说明测试质量相对越高。当然前提是必须划清楚客户的新需求,或者对spec设计方面的抱怨。
            3.过程改进
            考核点,是纵向对比,相比上一个项目,在质量控制上和测试进度进程上有否进步。包括测试方法,提升质量的手段,测试数据记录,用例更新等等有没有改进。
            该项具体考核方法也是经理来根据测试组在过程中具体表现,来定性打分。
            还包括测试人员在测试过程中的
    学习能力。这个也是定性。
            4.考核注意事项
            4.1统计bug的注意事项
            5.其它注意事项
            作为考核者要注意以下比例,也许有些没有列入考核内容,但是如下这些点可以指导测试。
            a,测试团队发现的bug和所有bug之间的比例
            b,spec设计造成的bug
            c,重复或者误提交的bug所占的比例
            d,每周发现的bug的趋势图
            e,Bug严重等级的构成比例
            f,Bug从提交到解决的平均需要时间
            g,Bug从解决到关闭的平均需要时间
  • 51testing,真正成为我的家了

    静澜 发布于 2008-11-05 09:42:30

    做测试已是一年有余,逛逛51也成了工作闲余之时的事情之一,在我的测试能力成长过程中,它给了我不少的帮助。这里的空间开通也有好些日子了,可是却是一直闲置,昨天,放了第一篇文章进去,虽是转载,但总算不是空无一物了。我想,以后我会好好把它利用起来,让它成为我测试生涯中永远的良师和益友。
  • web易漏测地方

    静澜 发布于 2008-12-01 10:33:01

    1.浏览器的后退按钮 

      提交表单一条已经成功提交的记录,back后再提交,看系统会如何处理。检查多次使用back健的情况在有back的地方,back,回到原来的页面,再back,重复几次,看是否会报错。

      2.通过修改URL中的参数,向服务器发起请求,看看会有什么样的结果

      利用一些工具,如http watch,可以记录和捕获向服务器发起的URL请求,然后修改其中的参数向服务器发起请求.该功能点可以和安全测试结合起来.

      3.对表单多次提交

      对提交按钮快速多次点击提交,看看会不会在数据库中形成多条记录.网速或响应快时,这点容易被遗漏,但用户的网络可能慢,很容易多次点击提交.如果前端做了处理,试试捕获在提交时生成的URL,绕过页面,再次对服务器发起请求,会有什么结果

      4.光标的跳转

      执行操作后,光标是否停留在合适的位置.如邮箱登录,输完用户名回车后,光标应该跳转到密码框内.细节问题,但是影响用户感受

      5.tab键是否功能正确

      和光标的跳转类似,特别是在有输入项时,查看tab键的焦点顺序是否正确

      6.对全角/半角符号的输入测试

      有输入项时,要考虑全/半角字条的输入,及GBK字符

332/2<12
Open Toolbar