发布新日志

  • 第二个项目测试总结

    2008-12-19 14:40:53

    项目背景：

        加入公司，时运不济。第一个项目由于诸多外因内故，延时不少，弄得项目成员个个身心尽疲。我就盼着早早结束后，能接手一个新项目，重新开始。可是，刚闲下一周，金融危机的爪牙就已伸到了我们公司，大约是因为做欧美外包的缘故，我们比同城的其他企业也许更敏感一点，特别是当我们公司的一个项目组被那英国客户裁员一半，真是令我们不得不正视这个问题了。在这种情况下，我又接手了一个项目的测试，这也是我在公司的第二个项目。

        很遗憾的是，这是一个二期项目，一期功能已早在我来公司之前就已完成，另外，项目就是用于统计病房、护士、病人人数信息以及进行相应的分析的医院系统，真的很小。以致于我一天之类就熟悉了一期及二期的需求，弄清楚一些问题后，就开始准备测试数据了。其实二期功能也不多，就只是增加了N多的report，另外，根据用户的需求，要给系统加一个navigate bar。

        其实，因为做二期工作的已全部换了一批人（其实也就两个开发人员，一个测试人员），所以做了好些有价值但是客户不一定明白的工作，比如我做测试期间的前两周，基本都是在测试一期产品，并且发现了不少的bug；而据开发人员说，他们也改良了程序的结构，之前所有的硬编码以及一些高内聚的东西都被处理了。不过，由于项目实在是小，虽然做了好些额外工作，我们仍然超前完成了。

        话题扯远了，本意是进行测试总结，却啰嗦了这么大一堆。

    测试情况：

    1.测试类型

    （1）功能测试

        根据项目的具体情况，我人为地将其分为了两个部分，一是一期完成的所有功能，二是这期需要完成的报表测试。

    （2）UI测试

        其实更严格地说来是可用性测试，因为主要是测试了新增的Navigate bar，还有就是我在测试时，提出了一些方便操作的建议。

    （3）安全性测试

        一些比较肤浅的安全性测试，比如登录框的SQL注入问题，绕过登录，直接在地址栏粘贴网站内部地址等。虽然进行得简单，也确实发现了一些问题，比如，我将report部分的一个地址Copy下来，然后，在用户登录前输入此地址，然后，让一个没有report权限的用户登录，当登录成功后，转到了目标页面。而实际上，此用户是没有权限进这个页面的。

    （4）兼容性测试

        浏览器用了IE6，IE7，Firefox做测试；操作系统用了Windows XP，Window Server 2003。

    （5）其他

        由于项目本身就小，而客户也说没有大数据量的情况并且都是内部使用系统，因此，没有特别的性能要求，也就没有进行专门的性能测试。同时，为WEB系统，没有安装测试等。

    2.测试方法

        很惭愧，自始至终都是用的手动测试（其实真正测试时间，不足三周）。最初想过，将一期功能的回归测试用QTP来做，但后来考虑到代价与回报的平衡，放弃了。

    3.测试数据与用例组织

        一期，没有测试用例留下来，由于我是快速上手测试，再者又因为要同时熟悉一期二期需求，包括还得准备二期测试数据，所以，我同样没有为一期写任何test case，遇上比较复杂一点的流程，我也只会拟一个draft的东西。不过，也许是因为，我的测试基本上只是为一期功能锦上添花，所以基本上没有影响到测试效果。

        二期较之于其他测试也比较特殊，因为都是report，并且，这些report都是柱状或线状图，而数据则从前面流程的多处取出，因此会涉及多张表的数据，并且还有一些不算很难的算法在里面。另外，还值一提的是，一期留下了一个很奇怪的现象（用户首肯的），就是一个流程（项目中叫period）后，这些数据就在项目中看不到了，除非去查数据库，这对于测试来说，有点麻烦。因为，如果不想很麻烦地老是去翻数据库中的若干table，最好的办法就是，组织完备的测试数据。

        鉴于这些情况，我们用于管理requirement及test case的test link是用不上，为了照顾流程的流畅性，数据的完备性，我打算回归原始——用Excel来组织测试数据和测试用例。而后来测试时，我感受到，我当初的决定是英明的，好处在于几个方面：

    （1）Excel提供了函数等功能，这对于测试report这种，经常需要计算的情况是很方便的，如果用Test Link，我估计，我只会想到用calc命令了。

    （2）根据用户的需求，在系统中，report根据具体情况，需要显示柱形图或曲线图，而Excel则正好对在了点上，我可以把数据做出来后，生成相应格式的图，以后测试时，直接对比两处的图形就搞定了，形象生动得多。

    （3）Excel的多个sheet的功能，正好方便report与sheet的一一对应。

    （4）一个Excel文件就可以把测试数据及测试用例囊括了，既实现了数据数据与测试用例分离（在不同sheet）中，又查阅方便。

    4. 测试过程

        这一点没什么可说的，还是那原因，项目小、周期短，没有正式的测试计划、测试策略，但这些我心里都有谱，需求了解、一期功能回归测试、测试数据组织、测试二期功能等大概多少时间都有个计划，并且由于开发人员也很尽责，所以没有出现一点拖延情况。

    5.测试效果

        谢谢开发人员的全力配合，测试进行得很顺利。最初在测试一期产品时，还担心提出的bug会不被接受，毕竟，一期都已交付这么久了。但他们还是抽出时间全改了。经测试后，客户反馈回来的问题很少。但有一点，我觉得自己以后要注意，就是当时我始终无法重现客户提出的一个bug，后来在开发人员的帮助下，才知道症结在于分页功能上。我这里的测试数据不足以分页，所以无法重现。提醒自己，以后做测试时，应尽量考虑全面，不要因为测试数据的原因而漏测。

    总结：

        项目来得快也去得快，但在这个短短的测试期间，我还是有一些收获，最重要的一点就是，流程是死的，方法是活的，最适合项目的才是最好的。另外，测试确实是无穷尽的，客户本已接受的一期产品，却还是在第二期改进了那么多。最后……俄的神啊~~快来新项目吧，我写这篇总结时，还是闲人一个呢

    查看(823) 评论(4) 收藏 分享 管理

  • 第一个项目经验教训总结

    2008-12-11 14:30:55

    项目背景：

        此项目的客户是一个英国的软件公司，他们主要做设备管理系统、地产管理系统等，这一次是为Hertfordshire政府做一个软件用于各服务点（service point）的数据收集、整理、评估，以前他们是用Excel来处理这些数据的，现在需要将其自动化。后来客户决定将这个软件项目外包，我们公司就争取到了这个项目。

    情况介绍：

    　　这个项目主要包括两个部分：前台的Web端，主要用于数据收集处理；后台管理端，用于管理用户、制定数据计算标准、导入数据等。

    　　我们公司是将其作为一个加班项目来处理的，所谓加班项目也即也是说在每工作日规定的８小时内，不得做此项目，需要自己安排晚上或周末时间来完成任务。若有问题需要与项目成员沟通，则一般采用邮件形式，或者是在中午以及临近下班的时间开小会。在来这个公司前，对此我是闻所未闻的，后来了解到，大约这在外包公司比较常见，项目多任务紧时，为了压缩成本（大概也为了日后考虑），并不会立即招人，而是将部分小项目以加班项目的形式分配下来，当然，项目奖金也是很可观的。然而加班项目无论在成员沟通、时间进度把握以及项目成员的心理认知都会存在一定的问题，所以，这也就为项目后来的进展埋藏了不少的隐患。

    　　还值得一提的是，公司的很多项目都是以ODC报价，可是这个项目却采用的是固定报价形式，不管你花多久的时间做，最终成功交付了，才能得到所有钱。这种形式本身没多少不对，可是，有时在一种心理的影响下，可能就会令项目进入一个恶性循环。

    　　我是今年６月中旬应聘进入公司的，从另一个测试人员手上接手了这个项目的测试任务。当时了解到，按照最初的计划，还有一个月的时间就该交付系统了，而此前交付某一部分时，因为延期，使得客户很不满意，而原因就是最初低估了工作难度而致实际使用时间大大超过预算。我进入项目组时，成员是这样的，有一个项目经理，一个测试人员，五个开发人员，不过，几天后我明白了，实际只有三个。当时之所以有五个，是因为其中两个才开始介入，为另两个的退出作准备。后来，基本上就是一个负责Win Form，一个负责Web，另一个技术比较牛、负责的项目多，只有当Web有难题时，就会找他出山。在我加入前，包括测试人员的所有项目成员都是把它当作加班项目做的，我因为没有其他项目，所有就当作正常项目来处理了。

    在正式介入测试之前，我大概花了三天的时间理解需求，毕竟产品已基本成形，可以一边用一边读需求，直观容易多了。但即使在这种情况下，我在后来的测试中还是渐渐发现当初对很多数据处理的细节方面是没有理解透彻的。那时，摆在我面前的难题有三个：一是所有项目文档都是英文，报告bug也要用英文，尽管我自诩英文读写能力不错，可还是花了好些时间才适应；二是尽管项目已进入中后期，除了mantis上的bug，没有任何测试方面的文档产出，包括测试计划、测试用例等；三，内部成员之间的沟通不及时，因为加班项目的特殊规定，有问题只能等到中午或下午下班后才能沟通，这种情况下，不可避免地会影响测试及至项目进度。

    但是后来渐渐发现，问题远不止这三个。由于是外包，我们的直接客户却并非最终客户，这就有两个问题，一是我们提交版本后，他们要测试，然后还要交给最终客户测试，这就使得每次反馈的时间拖长，由于没有新需求做，所以这边就只能处理等待状态；另一方面，最终客户反馈回来的bug，好些都是颠覆了原来的需求，更有甚者，有的还会改过来又改回去如此这般地往返几次，虽然客户不乏真诚地道歉，但是打击项目成员的积极性是不可避免的，同时，以后对于客户再提出的bug，不免报怀疑态度，大大降低了我们对客户的信任度。而对于用户的需求，又只包括了功能方面，对性能等方面的需求，没有在前期沟通确定，导致项目待结束时，客户突然提出，这种性能是不可接受的，我们不得不对Web部分大刀阔斧地进行修改。而后导致的一系列问题的处理，大大延迟了项目的进度。

    上面都只说的是一些比较客观的原因，有些主观原因也是不可规避的。

    首先检讨我自己，由于介入项目匆忙再加上自己测试能力有限，没有及早地发现某些bug；另外，自己在某些方面的认识上，也有待加强，以web的性能为例，一直以来，我都觉得速度不理想，尤其是数据大的情况下，但当时考虑到页面处理的特殊性（每个页面似一个excel的sheet，每个cell里都包含有控件，并且cell与cell之间还有大量的数据关联处理，而客户又要求不分页处理）以及客户没提这方面的需求，我也就没有这认为应该作为一个bug报告出来，而待项目接近尾声时，客户却要求我们改进性能。在采用了诸多方法，均达不到用户理想的速度时，最终通过与客户沟通，采用了分页形式。如果我能够不把眼光局限于浅显的bug，而多从整体或是用户角度去考虑，这个问题或许就可以早日提出解决，也不会引起那么多的后续问题。最后，作为一句测试人员，我不应该放弃原则。前面已经说过，这个项目是固定报价，项目拖得越久于我们而言是越不利的，可在这种因素的影响下，我们项目时间大大逾期，大家尤其是开发人员就不免急躁。同时，由于客户多次报一些与起初需求不符的bug，也令开发人员莫名窝火。在这种情况下，bug就分为两类对待了，客户报的都是高优先级，测试人员报的都是低优先级，并且总是认为只要不是太严重，且客户没报不修改也罢。后果可想而知，一方面，bug总归是bug，始终还是要被客户发现的；另一方面，对于测试人员而言，这是一种比较尴尬的境遇，很容易产生消极心理。

    对于整个项目而言，除去因是加班项目而引起的一些沟通不及时的问题而外，也还存在一些问题。比如，需求方面不完整，这又得提到性能问题了，如果在最初沟通需求时，在此问题上能与客户达到一致，在设计过程中，必不会漏考虑这块儿。还有，文档不完善，即至项目完成，除需求文档、bug报告而外，仍没有其他文档产品，这于一个项目而言是危险的。另外，责任心问题，在项目中出现过多次这种情况，对于一个bug，开发人员始终认为无法处理，而在客户一直强调要解决的时候，最后还是想办法fix了，当然很多时候是那位比较牛的开发人员露面了。如果遇上这种问题后，多沟通或者是有更强的责任心，也不会令客户光火。最后，在项目管理上，或许还是有些疲软，尤其是后期阶段，在所有项目成员心思都比较涣散时，项目管理人员应该更坚持原则。

    说了这么多，全是问题，其实闪光点也是不缺的。比如，虽然沟通不便，大家也会抽出时间定期开小会，介绍自己的情况及问题；还如，当项目组遇上了难题时，大家能够齐心协力地想办法解决掉；另外于我而言，才进公司时，项目经理给了我很大的帮助和信心，而在最初阶段，有时报的bug不正确或是难以理解，开发人员也没有责难；等等。作为我进入公司后的第一个合作团体，他们之中的每一个人我都是很感激的。

    总结：

    此项目终于在计划的deadline之后几月的11月中旬成功交付，在拖了如此之久后，大家心里已没多少成功的喜悦。前事不忘，后事之师，于我而言，在忘掉这个项目之前，做做总结也许是很重要的。当然，有了前面这一大篇幅的铺垫，总结将是十分简洁的：

    1.   需求沟通阶段，一定要尽可能地考虑全面，不只是功能、界面，还包括可接受的性能标准等方面。

    2.  在项目启动之初，就应该确定合理的内部沟通方式，确保不会因为沟通障碍影响项目成员及至整个项目组的进度。

    3.  无论时间多紧迫，必要的文档还是要有的，哪怕只是一个大纲也好。

    4.  无论是测试人员还是开发人员，遇上问题要尽早抛出，即使不一定得修改，拿出来讨论后大家有了这样一个意识，总错不了。

    5.  遇上解决有难度的问题，应该只有两种方法：一是想尽一切办法（如请教高手）解决；二是让客户了解解决的成本，希望他能妥协放弃，而不应该有第三种：拖延。

    6.  无论是对于bug，还是对于客户，任何时候，我们都不应该抱有侥幸心理。作为项目成员，每一个都应该对质量负责，而不应该只是测试人员，更不应该是客户。

    7.  项目管理上，强硬也许比疲软更有效。即使强硬会让项目成员一时难受，但最终会另整个项目组受益的。

    大约因为自己是公司项目规范检查小组的成员之一，不禁就会考虑到这诸多方面。而自己加入公司不久，所处的项目又有如此多的问题，所以当我检查其他人时，总会有些心虚。不过，意识到了就是一个好现象，待等到机会加入一个新项目，我希望自己能做得更好。

    　　

     

     

    查看(2830) 评论(10) 收藏 分享 管理

  • Writing Effective E-Mail: Top 10 Tips

    2008-12-10 14:46:28

    From: http://jerz.setonhill.edu/writing/e-text/e-mail.htm

    1. Write a meaningful subject line.

    Recipients scan the subject line in order to decide whether to open, forward, file, or trash a message. Remember -- your message is not the only one in your recipient's mailbox.

    No Subject: "Important! Read Immediately!!"
      What is important to you may not be important to your reader. Rather than brashly announcing that the secret contents of your message are important, write an informative headline that actually communicates at least the core of what you feel is so important: "Emergency: All Cars in the Lower Lot Will Be Towed in 1 Hour."
    [I have my e-mail filter set to trash e-mail messages with more than one exclamation mark in the subject line. Anyone who shouts at me is being abusive, trying to sell me something, or both. --DGJ]
    No Subject: "Meeting"
      The purpose of this e-mail might be a routine request for a meeting, an announcement of a last-minute rescheduling, or a summary of something that has already happened. There's no way to know without opening the message, so this subject line is hardly useful.
    Maybe Subject: "Follow-up about Meeting"
      Fractionally better -- provided that the recipient recognizes your name and remembers why a follow-up was necessary.
    Yes Subject: "Do we need a larger room for meeting next Fri?"
      Upon reading this revised, informative subject line, the recipient immediately starts thinking about the size of the room, not about whether it will be worth it to open the e-mail.

    My e-mail accounts get dozens of virus-bearing junk mails each day, often bearing a vague title such as "That file you requested," or no title at all. You'll get a faster response if your recipient can tell from the subject line that it's a real message from a real person.

    2. Keep the message focused and readable. 

    Often recipients only read partway through a long message, hit "reply" as soon as they have something to contribute, and forget to keep reading. This is part of human nature.

    If your e-mail contains multiple messages that are only loosely related, in order to avoid the risk that your reader will reply only to the first item that grabs his or her fancy, you could number your points to ensure they are all read (adding an introductory line that states how many parts there are to the message). If the points are substantial enough, split them up into separate messages so your recipient can delete, respond, file, or forward each item individually.

    Keep your message readable.

    • Use standard capitalization and spelling, especially when your message asks your recipient to do work for you. If you are a teenager, writing a quick gushing "thx 4 ur help 2day ur gr8" may make a busy professional smile at your gratitude... but there comes a time when the sweetness of the gesture isn't enough. i dont think u want ur prof r ur boss 2 think u cant typ LOL ;-)
    • Skip lines between paragraphs.
    • Avoid fancy typefaces. Don't depend upon bold font or large size to add nuances -- many people's e-mail readers only display plain text. In a pinch, use asterisks to show *emphasis*.
    • Don't type in all-caps. Online, all-caps means shouting. Regardless of your intention, people will react as if you meant to be aggressive.

    3. Avoid attachments. 

    Put your information the the body of your e-mail whenever possible. Attachments

    • are increasingly dangerous carriers of viruses
    • take time to download
    • take up needless space on your recipient's computer, and 
    • don't always translate correctly (especially for people who might read their e-mail on portable devices).

    Instead of sending a whole word processor file, just copy and paste the relevant text into the e-mail (unless of course your recipient actually needs to view file in order to edit or archive it).

    [I'm annoyed when people send bulk e-mails with attached pdf or Word documents that contain nothing more than a few paragraphs of ordinary text. I'd much rather get a plain text message, with a link to where I can download the full version if I want to enjoy all the colors and typefaces. Sending a 1MB attachment to hundreds or thousands of employees is a huge waste of digital resources. -- DGJ]

    4. Identify yourself clearly. 

    When contacting someone cold, always include your name, occupation, and any other important identification information in the first few sentences.

    If you are following up on a face-to-face contact, you might appear too timid if you assume your recipient doesn't remember you; but you can drop casual hints to jog their memory: "I enjoyed talking with you about PDAs in the elevator the other day."

    5. Be kind. Don't flame.

    To "flame" someone is to write an abusive personal attack. If you find yourself writing in anger, take a break. Take some time to cool off before you hit "send." Don't "flame" without weighing the consequences.

    The "flame" is a long-established Internet tradition. 

    When groups of people gather, they signal status by who gets the comfy chairs, who can talk and who must listen, etc.  Online communities don't provide these physical signals, so the words you use become even more important.

    Flaming anyone who (intentionally or otherwise) threatens the cohesion of the group helps online communities uphold hierarchy, define membership, and forge allegiances.

    But the relationship between boss and employee (or professor and student) is not primarily social. Because the power differential complicates the situation, the rules of etiquette are stricter. 

    No If you flame your boss or your professor, that message will probably surface someday when you're up for promotion or you want a letter of recommendation. 
    No If you flame an underling or student (especially in public), then you damage that person's trust in your leadership, and you probably won't get that person's best work in the future.

    Praise in public, criticize in private. If you want to complain about someone, do it in person or by telephone, so there won't be a permanent record.

    -- DGJ

    6. Proofread. 

    If you are asking someone else to do work for you, take the time to make your message look professional.

    While your spell checker won't catch every mistake, at the very least it will catch a few typos. If you are sending a message that will be read by someone higher up on the chain of command (a superior or professor, for instance), or if you're about to mass-mail dozens or thousands of people, take an extra minute or two before you hit "send". Show a draft to a close associate, in order to see whether it actually makes sense.

    7. Don't assume privacy.

    Unless you are Donald Trump, praise in public, and criticize in private. Don't send anything over e-mail that you wouldn't want posted -- with your name attached -- in the break room. 

    E-mail is not secure. Just as random pedestrians could easily reach into your mailbox and intercept the envelopes that you send and receive through the post office, a curious hacker, a malicious criminal, or the FBI can easily intercept your e-mail. In some companies, the e-mail administrator has the ability to read any and all e-mail messages (and may fire you if you write anything inappropriate).

    8. Distinguish between formal and informal situations. 

    When you are writing to a friend or a close colleague, it is OK to use "smilies" :-) , abbreviations (IIRC for "if I recall correctly", LOL for "laughing out loud," etc.) and nonstandard punctuation and spelling (like that found in instant messaging or chat rooms). These linguistic shortcuts are generally signs of friendly intimacy, like sharing cold pizza with a family friend. If you tried to share that same cold pizza with a first date, or a visiting dignitary, you would give off the impression that you did not really care about the meeting. By the same token, don't use informal language when your reader expects a more formal approach. Always know the situation, and write accordingly.

    9. Respond Promptly. 

    If you want to appear professional and courteous, make yourself available to your online correspondents. Even if your reply is, "Sorry, I'm too busy to help you now," at least your correspondent won't be waiting in vain for your reply.

    10. Show Respect and Restraint

    Many a flame war has been started by someone who hit "reply all" instead of "reply."

    While most people know that e-mail is not private, it is good form to ask the sender before forwarding a personal message. If someone e-mails you a request, it is perfectly acceptable to forward the request to a person who can help -- but forwarding a message in order to ridicule the sender is tacky.

    Use BCC instead of CC when sending sensitive information to large groups. (For example, a professor sending a bulk message to students who are in danger of failing, or an employer telling unsuccessful applicants that a position is no longer open.) The name of everyone in the CC list goes out with the message, but the names of people on the BCC list ("blind carbon copy") are hidden. Put your own name in the "To" box if your mail editor doesn't like the blank space.

    Be tolerant of other people's etiquette blunders. If you think you've been insulted, quote the line back to your sender and add a neutral comment such as, "I'm not sure how to interpret this... could you elaborate?"

    Sometimes E-Mail is Too Fast!

    A colleague once asked me for help, and then almost immediately sent a follow-up informing me she had solved the problem on her own.

    But before reading her second message, I replied at length to the first. Once I learned that there was no need for any reply, I worried that my response would seem pompous, so I followed up with a quick apology:

    "Should have paid closer attention to my e-mail."

    What I meant to say was "[I] should have looked more carefully at my [list of incoming] e-mail [before replying]," but I could tell from my colleague's terse reply that she had interpreted it as if I was criticizing her.

    If I hadn't responded so quickly to the first message, I would have saved myself the time I spent writing a long answer to an obsolete question. If I hadn't responded so quickly to the second message, I might not have alienated the person I had been so eager to help.

     

    查看(560) 评论(0) 收藏 分享 管理

  • 测试用例评审检查单（转，有空修改）

    2008-12-09 17:00:27

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

    查看(415) 评论(0) 收藏 分享 管理

  • 快速划分测试用例的优先级（转自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只是高优先级别测试用例的精选，它们已经被确定为对系统和测试是非常重要的。

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

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

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

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

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

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

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

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

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

    总结

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

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

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

    查看(506) 评论(0) 收藏 分享 管理

  • 测试管理工作检查表

    2008-12-09 16:08:22

    1. 检查每轮测试开始时测试环境是否准备好（包括软件硬件、测试基本数据等）；

    2. 确保测试环境（数据和程序）与开发分离，除了测试组之外其他人不能更新测试环境的数据和程序；

    3. 每轮测试根据上一轮的情况和总体测试计划做分工调整；

    4. 检查case库的填报情况，抽查执行过的case；

    5. 检查BUG提交情况，抽查提交的BUG是否规范；

    6. 每天晚上统计BUG情况，填写每天的BUG报告；

    7. 根据每天的测试情况，决定是否开发组要发布新的BUILD；

    8. 每轮测试结束后填写测试总结。

    查看(569) 评论(0) 收藏 分享 管理

  • Use Case

    2008-12-09 15:30:07

    　　用例

    　　Use Case（用例）是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

    　　那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。（唔？Use Case也没什么特别的嘛！怎么这玩意儿会在开发中处于一个中心地位呢？）在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！好了，Use Case就吹到这儿，具体的使用还要在实践中去体会，“运用之妙，存乎一心” 也！

    　　对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要 对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

    　　Use Case可以用很多方式来描述，我们可以用自然语言（英语，汉语，随您的便），可以用形式化语言（哇！太酷了吧！），也可以用各种图示。在UML中，通常用两种图来描述Use Case，它们就是顺序图（Sequence Diagram）和协作图（Collaboration Diagram）

    　　Use Case 由以下元素组成：

    　　名称

    　　简单描述

    　　事件流

    　　关系

    　　活动图和状态图

    　　Use Case 图

    　　特殊需求

    　　前条件

    　　后条件

    　　一、谈谈对use case有关术语翻译的看法。

    　　笔者认为“用例”是目前较好的译法，这个词可能来源于大家熟知的“测试用例”。有人认为把use case翻译成“用例”是错误的，理由是：“‘例’是被列举出来以说明某种情况的个别事物，use case是对一项系统功能使用情况的普遍适应的描述，而不是对个别actor或者在个别条件下使用这项功能才适应，它也不是通过举例的方式来描述的”，所以不能叫作“用例”。此种说法不尽全面,而且有些牵强（先不管它正确与否），其实use case到底是个别的，还是群体的（普遍适应），取决于我们的视点。虽然对于单个的scenario来说，use case是多个情节的叠加，是一个整体的复合概念，但是我们知道，一个系统的功能必定是可数的、有限的，而每一个功能都可以表示为一个use case，所以在观察系统提供的所有功能需求的集合这个层面上，use case又是一个一个可数的个体（“椭圆”），每一个都代表了不同的用户目标，适用于个别的actor和个别特定的前置条件。同一个事物既是个体的又是整体的，这种现象并不足怪，例如在UML对象-类-类元关系中，通常对象是类的实例，而类又是类元的实例，对类元来说，类、接口、子系统、use case等等就是一个个个体的概念，类既是其对象实例的集合又是其类元集合的个别元素。可见，把use case的“case”译成“例”并没有错。

    　　有的地方把use case翻译成“用况”，即“使用的情况”之意，意思的确不错（use case的另一种说法是“使用的方式”）！可我总感觉这个词比较突兀、拗口，类似的还有“用案”，把scenario叫作“案况”，大概这些词读起来不太符合大家的习惯（类似地，既然可以叫“用况”，为什么不能叫“用情”呢？），所以现在“用例”的叫法还是越来越多了。

    　　其实“用例”这个译法还有个附带的好处，通过它我们很容易把原本就存在紧密联系的use case和test case（test case来自于对scenario的分析，而scenario是用例的一次执行）从中文名称上也方便地统一起来。不过，这里我们需要做一个小小的改进。中文的“测试用例”到底是指test case（带定语的名词词组）呢，还是指对用例进行测试（testing the use cases，动宾词组）呢？显然这两者不易分辨，而且若“用例”和“测试用例”两个词同时出现在一啰个句子或一段话中，常常会让人感觉嗦和便扭。为了消除歧义，干脆以后把test case都叫做“测例”，这样不但比以前的叫法更加简洁明了，而且无论字面上还是语义上都很贴切。当然，用例和测例是不同层面的“例”。

    　　现在市面上Actor也有多种译法，常见的包括“参与者、执行者、主角”等等。“参与者、执行者”的问题主要是不准确。首先，“参与者” 通常让大家马上想到的词是participant，而且请注意，一个用例的真正参与者决不是只有外部的Actor，它们必然还包括系统本身及其内部的各种元素。“执行者”的问题与此类似：一个用例的真正执行者应该是系统本身！因此严格地讲这样译是错误的，兴许叫作“外部参与者”、“外部执行者”才更为恰当。“主角”的译法同样存在着矛盾。如果把Actor叫作“主角”，那么Primary Actor就应该叫作“主主角”了。看来Actor的译法中是不能含有“主”的，那么就剩下“角”了，而UML已经有了一个专门术语role（角色），我们又不能把Actor直接叫作“角色”。

    　　目前看来，把Actor意译成“使用者”是比较妥当的。在大多数情况下Actor的的确确就是用户（确切地说是系统用户所扮演的一种角色），所以我们可以用“使用者”这个词从字面上与“用户”（user）进行区分，但同时又保持两者语义上的联系。我们还可以把为系统服务的Supporting/Secondary Actor（见下文）叫做“被使用者”（为了简化可以省略“被”字）或“辅使用者”。除了指系统的用户之外，“使用者”还有另一层含义，即Actor是use case的使用者（或被使用者），这种关系在UML用例图上应该可视化地表示为它们之间的连线（关联）。这样解释不但说的通，而且更便于不熟悉软件技术的业务人员理解。

    　　当然，我们也不排除将来会找到“use case”、“actor”等术语更好的译法。

    　　二、USE CASE的来历

    　　Ivar Jacobson在1967年定义爱立信AXE系统的够架时开始书写使用场境usage scenarios。

    　　二十世纪八十年代中期Jacobson花了很多精力来思考过去十多年的工作方法。他造了一个术语anvendningsfall，大意是“使用情况”（situation of usage）或用况（usage case）。但当用英文出版的时候，他发现“useage case”在英语里说不通，所以写作用例“use case”

    　　三、创建USE CASE的原则

    　　用例是短文

    　　用例可以是一个场景，包括动作和互交。

    　　用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。

    　　用例里不要有系统设计

    　　用例里不要有界面设计

    　　用例里不要有特性列表

    　　用例里不要有测试

    　　用例应该描述行为需求

    　　用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。

    　　用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。

    　　四、Use Case 事件流

    　　Use Case具有一个基本事件流（可称为"理想路径"）、多个例外流，包括：

    　　基本变化

    　　特殊情况

    　　处理错误情况的异常事件流

    　　五、Use Case 说明书

    　　Use Case 说明书应包括以下内容：

    　　功能描述

    　　可用性

    　　可靠性

    　　性能

    　　可支持性

    　　设计约束

    　　六、Use Cases将做成多大？

    　　试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为Business Use Case，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的场景不允许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。

    　　对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。

    　　Use Cases的另一范围是设计子系统和系统内部组件的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。

    　　给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。帮助系统设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。

    　　七、Use Cases的说明

    　　Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。

    　　不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。

    　　下面是客户对Use Case“下定单”的粗略概略：

    　　“确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用”

    　　结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对顺序的叙述。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例：

    　　Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。

    　　八、Use Cases使需求有利于回顾

    　　Use Cases已经得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于：

    　　1 　Use Cases把系统当作一个黑盒

    　　2 　Use Case 使在需求中看到实现的决定变得更加容易

    　　最后一点源于第一点的补充，一个Use Case没有指定任何这些需求相关的系统的内部结构，所以说，如果这个Use Case中陈述了"提交改变到定单数据库"、"显示结果到Web页面"等的话，那么内部结构是显而易见的，并造成对设计的潜在约束。

    　　为什么这些需求不指定内部结构的原因是，说明的内部结构给设计者带来了额外的约束，没有这些约束设计者们能更自由地建立一个正确实现客观可见行为的系统，并存在出现突破方案的可能性。

    　　九、Use Cases的图形符号

    　　这里是Use Cases的图形符号描述，UML中一个单一的"Stick-Man"符号标示角色（Actor），用椭圆标示Use Cases，如

    　　（图一）所示。这些图对于你想看到Use Cases之间如何关联的"大图"和获得系统上下文的大体描述来说是非常重要的。

    　　Use Cases图没有显示不同的场景，它们的意图是显示角色和Use Cases之间的关系。所以Use Cases图需求用结构化叙述文本来补充。UML提供一些可供选择的图来显示不同的场景，这些常规的图形有交互图、活动图、顺序图、状态图等（本文暂不讨论这些图）。使用这些图的主要缺点是它们不象文本一样是紧密的，但它们能用于给出Use Case的整体感觉。

    　　十、Use Case 的评价标准

    　　是否每个Use Case 都包括至少一个actor？

    　　是否每个Use Case 都独立于其他Use Case？

    　　是否每个Use Case 都有一个简单的行为或事件流？

    　　是否每个Use Case 都有一个唯一的、直观的、可扩展的名称，使它不至于在后期被混淆。

    　　用户是否容易理解Use Case 的名称和描述。

    　　十一、Use Case 模型的评价标准

    　　Use Case模型显示系统中的Use Case与Actor 及其相互关系。其评价标准有：

    　　Use Case 模型是可理解的吗？

    　　通过对Use Case 模型的研究是否能对系统功能有一个清晰的概念。

    　　所有的actor都定义了吗？所有的功能需求都满足了吗？

    　　Use Case 模型是否存在多余的行为。

    　　从模型到Use Case包的划分是否是恰当的。

    　　十二、使用Use Case 的误区

    　　由于具有简单的图形符号、易理解的自然语言说明书，Use Case在文档系统和软件需求领域成为一 项越来越受欢迎的技术。Use Case对开发小组极具吸引力，即使小组成员对正式的需求文档没有经验，但这些简单性却具有欺?


    查看(1143) 评论(3) 收藏 分享 管理

  • 测试用例设计步骤（转）

    2008-12-09 14:41:51

    设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：

    1、测试需求分析

    从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。

    测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。

    2、业务流程分析

    软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。

    从业务流程上，应得到以下信息：

    A、                   主流程是什么

    B、                   条件备选流程是什么

    C、                   数据流向是什么

    D、                   关键的判断条件是什么

    3、测试用例设计

    完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。

    黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：

    功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。

    适合的技术：由业务需求和设计说明导出的功能测试、等价类划分

    边界测试：对某个功能的边界情况进行测试。

              适合的技术：边界值划分

    异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的，类似这样的情况需要书写相关的异常测试。

              适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、

    性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。

             适合的技术：业务需求和设计说明导出的测试

    压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。

             

    4、测试用例评审

    测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。

    测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。

     

    5、测试用例更新完善

    测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。

    查看(747) 评论(0) 收藏 分享 管理

  • 从测试用例看测试的问题及变化（转）

    2008-12-09 14:23:58

    对于一个测试人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。

    一、问题：

    许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。

    当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

    l         从此几乎很少被执行

    l         已经与程序的实现发生了冲突（界面变动，功能变动）

    l         执行用例发现的bug很少

    l         根本没有时间为新的功能需求增补用例

    l         有时间补充，但用例结构越来越乱，

    l         特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）

    l         知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起）

    通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。

    但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展吧。

    二、原因：

    事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

    1、没有适合的规范

    “适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么？

    每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？

    在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往·的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。

    我们有太多经验，但却没有形成适合的规范。

    2、功能与业务的分离

    我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

    边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

    复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体）。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。

    用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

    3、测试未能跟上变化

    变化！想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢？当地区特性，软件版本越来越多的时候，测试是否在积极响应呢？变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

    对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

    疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法很快发现。

    永远是变化决定我们的下一步工作，这也是混乱的开始。

    三、可能的解决办法：

    在这里我希望以探讨的方式提出一些可能的解决办法，因为上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式，最适合的就是最好的。

    1、测试驱动开发，用例指导结果，数据记录变化

    “测试驱动开发”（TDD）是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效（Work）更洁净（Clean），“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

    首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80％以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。

    如何在黑盒测试中做到测试驱动开发？我认为可以从用例级别做起，以业务用例指导过程和结果。

    开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很明确的指出应该实现怎样的结果，这使得从业务到功能出现一个“阅读上的障碍”，如果最后程序错误了还需返工，这样耗费的人力物力就非常大了。使用业务用例驱动开发，就是一个比较好的方法，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。

    业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

    我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段（业务段与程序中以窗体或页面的划分是不一样的），使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。

    再进一步的话“数据库”就开始涉及到程序内部的接口了，这需要开发人员的配合。

    2、为用例标明时间（版本）和优先级

    为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

    为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

    3、功能用例与业务用例分开组织

    将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理？）。

    4、审核用例，结对编写

    测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。

    测试用例不是一个人编写一个人执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理，提高组员的参与积极性。

    四、发展

    上面的这些解决方法只是一种建议，具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的，传统的黑盒测试并不是毫无新意，测试工作怎样适合我们而发展，将给予我们更多的思考。

    查看(576) 评论(0) 收藏 分享 管理

  • 测试用例设计（全面，转自51）

    2008-12-09 14:10:28

    测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。51Testing软件测试网.q}y3{/?M8QVP

    $jcre }5p @154414测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试    脚本等，并形成文档。51Testing软件测试网.i([)khe E'ZNF
    51Testing软件测试网 x+R8p8T(a(NBd
    不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
    Y/vM)MCEexy|Z15441451Testing软件测试网s2m-g2PDl%cXi%@zN
    随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。51Testing软件测试网!J xiA/Of
    51Testing软件测试网0[%tM^9~L|7q.i6g
    要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。51Testing软件测试网gk?"o(M U5A-x'k
    51Testing软件测试网Xod(tY
    既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
    )zqm;h B;O0R.?pX/|15441451Testing软件测试网1mF.\pl6Fk`;J
    确定测试用例之所以很重要，原因有以下几方面。51Testing软件测试网l.hNEy"S#H*g

    O].t4@ |*M;Vl%r t154414测试用例构成了设计和制定测试过程的基础。51Testing软件测试网EQfO n
    测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。
    "[GSb$HseE154414判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。51Testing软件测试网b!sCeA9xE
    测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。51Testing软件测试网5@ `_F(c:Fj2?"F%@f
    测试设计和开发的类型以及所需的资源主要都受控于测试用例。
    QlGXQq4s A$ip154414测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：51Testing软件测试网R~4]3Kr7Z'MW

    :D,pC(J_ ra }/}(D154414·一个测试用例用于证明该需求已经满足，通常称作正面测试用例；51Testing软件测试网m@S4{.I!g
    ·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。51Testing软件测试网 i_ua ZHa3yJjN i
    51Testing软件测试网@p:Ee5ka4~
    51Testing软件测试网9m-Z'] ?zd2\Y+d {8m X
    一、测试用例是软件测试的核心51Testing软件测试网V:Myq#h ^

    5`/``9Vm ju6MXE154414软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
    .j&g%|.j[Z#D$O\o154414
    Bo VE-MN5T Tw E`154414影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。51Testing软件测试网8v*PG ~ | ~7x+P?"s-eN

    LN,tZC4}ZrU154414因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。51Testing软件测试网B"Xz&X]LW A _4uT

    U%xCw(t'[154414二、编制测试用例
    Ul*Sdn(I15441451Testing软件测试网qTIG6[:SBIpn$}
    着重介绍一些编制测试用例的具体做法。
    pq)E,z,K4M t15441451Testing软件测试网S2@N)D,d FjM
    1、测试用例文档51Testing软件测试网8Uv1f0Koh~} {d*r

    2wH7R5K3d} o154414编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
    :{6wLzRQ r-qqX154414软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。
    7d0k8} Zacg15441451Testing软件测试网pIP,M\Rvc[
    测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。51Testing软件测试网j~zs6T

    $i4F v9a)A[F1544142、测试用例的设置
    (]G~!vf;i9nQs154414
    zm(]:h$S[hjUQg154414我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。
    *@c Y:``u3t y15441451Testing软件测试网"q/T)taL6X
    按功能测试是最简捷的，按用例规约遍历测试每一功能。
    e*fNJ I4XUli%L154414
    8a"@NfB F.k:^154414对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。51Testing软件测试网rDO ew#G"k$f
    51Testing软件测试网G+}/i&G3x*Bs f
    但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。
    6Bs Q r(H154414
    {qO.p&hO&a&I1544143、设计测试用例
    _1_*DD V(e6rJ;h154414
    f1Xk(GyMxPQ?154414测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。51Testing软件测试网\(o7mwm?

    p] ~2`*l4z:Q_154414设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。
    ,q7i9s u KQ/z154414
    RJ8A8R$^ `154414可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。51Testing软件测试网 d'D B[f,sw,G2h

    $b F t}5Do)_154414三、测试用例在软件测试中的作用51Testing软件测试网D0Zw%y#nkh

    b"[ OvWv"O1544141、指导测试的实施
    l}4T[1ce@:D15441451Testing软件测试网wk,IA2q,]
    测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。
    ~d5HAcJGg*M15441451Testing软件测试网:ND9bmg1S |tMQ
    根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。
    yJ5o(NH3iv154414
    #yN-a%H V2D*s _\H1544142、规划测试数据的准备51Testing软件测试网oXJR$N)_#J

    /bo"Ea&m*{7y0KY154414在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
    i!V(F ]y[QDF154414除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。51Testing软件测试网*I@ u&nkn-H Z&y

    uqDus#P+F{3a T1544143、编写测试脚本的"设计规格说明书"51Testing软件测试网Q[4Ai ~
    51Testing软件测试网j&D m$}b6WX
    为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。
    3x)N]H&k}lm15441451Testing软件测试网u/v-JI!O!A r V
    4、评估测试结果的度量基准51Testing软件测试网co(K2]n6y g*{ y$^p"u
    51Testing软件测试网%q u8y1b t]
    完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。51Testing软件测试网!p4uxUj2rv

    ?jD d3vsF!_]oj1544145、分析缺陷的标准51Testing软件测试网@Z W q]3}

    5ID9f;c2fv'D154414通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。51Testing软件测试网 j/I ha._b"f3YG

    ~7Zi,OUt!iv154414四、相关问题
    |T USGz@154414
    D-ylK`s:xF1544141、测试用例的评审
    3t xzOk-_bL15441451Testing软件测试网t.f%q j:f)R$VO2M
    测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。51Testing软件测试网%Xc*EhP agvI

    \7n4W|3giM_0L1544142、测试用例的修改更新
    #q WMl;H!cu o154414
    F\ K|~154414测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
    )_ aoXh^D^15441451Testing软件测试网y o+u'A5S K @2x!i
    一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。51Testing软件测试网@0EC8EyF)|i
    51Testing软件测试网7AXw Eta:i,Ylb
    3、测试用例的管理软件51Testing软件测试网,O-p/hMO|!U
    51Testing软件测试网 _+w/A @&oA
    运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。51Testing软件测试网#gR4W8rF1@ C
    51Testing软件测试网;f5w#m2X&h0w1X4mY
    有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。51Testing软件测试网 } Q&a u mR[
    51Testing软件测试网$u A2Nh._B%i;ZKu
    五、测试用例的设计51Testing软件测试网[)`+z!w9I

    $fxB w"b%d)J154414（一）白盒技术51Testing软件测试网@\u6l)Nj"z
    51Testing软件测试网u*{ vo4t K [
    白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。
    m2J`(fm q"?j1544141、逻辑覆盖
    uZ4V9gu`E154414程序内部的逻辑覆盖程度，当程序中有循环时，覆盖每条路径是不可能的，要设计使覆盖程度较高的或覆盖最有代表性的路径的测试用例。下面根据图7-1所示的程序，分别讨论几种常用的覆盖技术。51Testing软件测试网`*l9wT+@
    (1)语句覆盖。51Testing软件测试网 tV%P.C:l(j2Rwl
    为了个提高发现错误的可能性，在测试时应该执行到程序中的每一个语句。语句覆盖是指设计足够的测试用例，使被测试程序中每个语句至少执行一次。51Testing软件测试网#B9EM~1c
    如图7-1是一个被测试程序流程图：
    FmW$JEh!f.w!s`n15441451Testing软件测试网;LPGUj3p9U @Dl H!u&R

    :E,d"Z!xf Z9_154414(2)判定覆盖。
    P@3K? m3^Wzx154414判定覆盖指设计足够的测试用例，使得被测程序中每个判定表达式至少获得一次“真”值和“假”值，从而使程序的每一个分支至少都通过一次，因此判定覆盖也称分支覆盖。51Testing软件测试网%k9Ukh0al7G
    (3)条件覆盖。
    f8?VR1V q154414条件覆盖是指设计足够的测试用例，使得判定表达式中每个条件的各种可能的值至少出现一次。51Testing软件测试网+y&DEFg9iz
    (4)判定/条件测试。
    P)|M$?HDb bj154414该覆盖标准指设计足够的测试用例，使得判定表达式的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。
    r8_X*GB:}3Y%U154414(5)条件组合覆盖。51Testing软件测试网 K,~d6I]i^9~5Y E"s
    条件组合覆盖是比较强的覆盖标准，它是指设计足够的测试用例，使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。51Testing软件测试网T[HD#p5ID,P5ko
    (6)路径覆盖。
    3jD k[E154414路径覆盖是指设计足够的测试用例，覆盖被测程序中所有可能的路径。
    8J!v&MmL@k154414在实际的逻辑覆盖测试中，一般以条件组合覆盖为主设计测试用例，然后再补充部分用例，以达到路径覆盖测试标准。51Testing软件测试网/pa4CiU1e
    2.循环覆盖
    LKNl/w(o3e\%M1544143.基本路径测试51Testing软件测试网"buIF} p F/IK6J
    51Testing软件测试网a(|D d5G s"Ny'l
    51Testing软件测试网 r2V3DNw(E
    （二）黑盒技术51Testing软件测试网e @{Bt
    51Testing软件测试网-[ Y-Wc5r7|+\r`Sg
    1.等价类划分
    nz3V6U_154414(1)划分等价类。
    4p%p$aLbvp\154414①如果某个输入条件规定了取值范围或值的个数。则可确定一个合理的等价类(输入值或数在此范围内)和两个不合理等价类(输入值或个数小于这个范围的最小值或大于这个范围的最大值)。
    lz`h$k7L^154414②如果规定了输入数据的一组值，而且程序对不同的输入值做不同的处理，则每个允许输入值是一个合理等价类，此处还有一个不合理等价类(任何一个不允许的输入值)。51Testing软件测试网i"h2|5|z"V'|+| g}
    ③如果规定了输入数据必须遵循的规则，可确定一个合理等价类(符合规则)和若干个不合理等价类(从各种不同角度违反规则)。
    b%`X(V4a Ms q154414④如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类。51Testing软件测试网|5js8^6}
    (2)确定测试用例。
    /U&Ixz_7g"S8}154414①为每一个等价类编号。51Testing软件测试网 aK QI-w5ZcI
    ②设计一个测试用例，使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步，直到所有合理等价类被测试用例覆盖。
    q&IU$znE$P1HZ154414③设计一个测试用例，使其只覆盖一个不合理等价类。51Testing软件测试网LDN s7NLe
    2.边界值分析
    Ck:D S }4C| w%U V7V154414使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。51Testing软件测试网p'y,_7pr Q+ye
    (1)如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的范围是[1，100]，可取0，1，100，101等值作为测试数据。51Testing软件测试网J!iN r*HZep
    (2)如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如，一个输入文件可包括1--255个记录，则分别设计有1个记录、255个记录，以及0个记录的输入文件的测试用例。51Testing软件测试网o{6z3Zb0Vz$h
    (3) 对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。如，一个学生成绩管理系统规定，只能查询95--98级大学生的各科成绩，可以设计测试用例，使得查询范围内的某一届或四届学生的学生成绩，还需设计查询94级、99级学生成绩的测试用例(不合理输出等价类)。
    #e*k~kfvp154414由于输出值的边界不与输入值的边界相对应，所以要检查输出值的边界不一定可能，要产生超出输出值之外的结果也不一定能做到，但必要时还需试一试。
    8OO#qJI%IG qkC154414(4)如果程序的规格说明给出的输入或输出域是个有序集合(如顺序文件、线形表、链表等)，则应选取集合的第一个元素和最后一个元素作为测试用例。
    @y c?/t"P)A1544143.错误推测51Testing软件测试网 {;c0Rc*o PT
    在测试程序时，人们可能根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例，这就是错误推测法。51Testing软件测试网)e3f:enPcL7o
    4.因果图51Testing软件测试网o.dp4H&y,`z*J
    等价类划分和边界值方法分析方法都只是孤立地考虑各个输入数据的测试功能，而没有考虑多个输入数据的组合引起的错误。51Testing软件测试网WV(rns$S'Z+[Z
    5.综合策略
    K/uu*{-?cT/K154414每种方法都能设计出一组有用例子，用这组例子容易发现某种类型的错误，但可能不易发现另一类型的错误。因此在实际测试中，联合使用各种测试方法，形成综合策略，通常先用黑盒法设计基本的测试用例，再用白盒法补充一些必要的测试用例。51Testing软件测试网q5@2[Ui3XnN

    i%I q wl{.B154414六、测试用例设计的误区51Testing软件测试网!Q;~/i7d PMN4vC0b
    （来源：关河测试网）51Testing软件测试网bT TRA+{jhb0|(I

    'JSP_;`:^i154414·能发现到目前为止没有发现的缺陷的用例是好的用例；51Testing软件测试网;P;W U-IQ$O
    51Testing软件测试网| UP u|a
    首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试 需要保证以下两点：51Testing软件测试网9J0Ai_hP_

    D Y t*?Z*o W154414程序做了它应该做的事情51Testing软件测试网 {/h/h4[!D J
    程序没有做它不该做的事情51Testing软件测试网J([|v'yF&L
    因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。
    }4o+p+~ K(Pg?15441451Testing软件测试网0HO*GZn F9q0x7b
    ·测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；
    1{0xv6ZM.R154414
    3jb.Enj \ h154414不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。
    fL~x!h0O*B154414
    r7mFQ&x8aS154414在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。
    (^:N%KT~U'F15441451Testing软件测试网q%J;k_6Nq \q
    除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。
    "xDg(Y2~;F0SN15441451Testing软件测试网.W^\1h:nU-N'z(E(l
    ·测试用例设计是一劳永逸的事情；51Testing软件测试网C#npHLP

    a6|$XPa E154414这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例 却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰 后，对测试人员不屑一顾。51Testing软件测试网W)y-b|o6L
    51Testing软件测试网Yw%NTn$]~5T
    这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。51Testing软件测试网)C,f Nb3i7`-A:d
    51Testing软件测试网#j%["v q5O-wXJ"cb
    ·测试用例不应该包含实际的数据；51Testing软件测试网6AR\R&F$DO{
    51Testing软件测试网8t-k ` K{s
    测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。51Testing软件测试网#C7Z[VT6s

    +xT/f?F:[,K m f"A3r^154414·测试用例中不需要明显的验证手段；51Testing软件测试网$J5_!j @'BV^
    51Testing软件测试网de/@7RCq+n;NA
    我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。51Testing软件测试网$O6I N(qv
    51Testing软件测试网7\4LYv8H(qU
    七、从用例中生成测试用例
    ^v j-vw y15441451Testing软件测试网3~]u-Cw_

    %w.ZiV$]#\p9ks154414用于功能性测试的测试用例来源于测试目标的用例。应该为每个用例场景编制测试用例。用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
    s&|/C @l qKH154414
    7l/^0VZ:og154414例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）。
    )oG(\3VIm154414
    7a6` [-vo`4`%d_15441451Testing软件测试网%M p4@s^_1C[
    用例的事件流示例51Testing软件测试网 h u L l q(XV

    ;S+f^_6Mr154414遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：51Testing软件测试网:X2Dy cge3}-TQ|
    51Testing软件测试网&G"l:?7_XZ
    场景 1     基本流             51Testing软件测试网*w!|W A1dz
    场景 2     基本流     备选流 1         
    &_O ~fJ|.~ p#@~154414场景 3     基本流     备选流 1     备选流 2     
    H2O v2o*g9~!_:M154414场景 4     基本流     备选流 3         51Testing软件测试网/N Ni(m0ic-Ugn%g0M
    场景 5     基本流     备选流 3     备选流 1     51Testing软件测试网V&^&c6z2@~
    场景 6     基本流     备选流 3     备选流 1     备选流 2
    4A:aNE;C154414场景 7     基本流     备选流 4         51Testing软件测试网O7sf Z?+|&S
    场景 8     基本流     备选流 3     备选流 4
    O5JOM S/NA154414
    !c7F)x5C)My"c J"G154414注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。51Testing软件测试网Y5?!@$^Zj*H
    51Testing软件测试网@xV[UWU
    生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。51Testing软件测试网2Hj:P+_ClH

    F!t1\0gYd0@W FhZ#p154414例如，假定上图描述的用例对备选流 3 规定如下：51Testing软件测试网%Y'IkN8L!q7d*i
    51Testing软件测试网x Y.Q \o!@4Mvp/\i6u
    “如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤 2‘输入提款金额’，此时银行客户可以输入新的提款金额。”51Testing软件测试网ZO2`Bv)R Z v

    e \`9D x,H154414据此，可以开始确定需要用来执行备选流 3 的测试用例：51Testing软件测试网DG PnqQ5|
    51Testing软件测试网/L8{ I,s5{!U
    测试用例 ID     场景     条件     预期结果
    5_]4HxMP6i a b154414TC x     场景 4     步骤 2 - 提款金额 > 帐户余额     在步骤 2 处重新加入基本流
    P${v w0T{6X'z154414TC y     场景 4     步骤 2 - 提款金额 < 帐户余额     不执行备选流 3，执行基本流51Testing软件测试网M){;@8Jq [V+KG$R
    TC z     场景 4     步骤 2 - 提款金额 = 帐户余额     不执行备选流 3，执行基本流51Testing软件测试网;?E{q"@!^@9W

    SQkzo4{154414注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。
    ;JH5x?TF@:stz7W154414
    3dH x1f#Ou}n1\|"r154414下面是一个由用例生成测试用例的更符合实际情况的示例。
    -n QI/z+}h d15441451Testing软件测试网r;Lgn)vF2n

    H3h/g-c2_b8r154414示例：51Testing软件测试网 I{ H#HJY
    51Testing软件测试网k!QwB!l Iut0i{
    一台 ATM 机器的主角和用例。51Testing软件测试网-`D;u+\ bM
    51Testing软件测试网j8a8y$A9fA'r4ZH6hx3UI
    下表包含了上图中提款用例的基本流和某些备用流：51Testing软件测试网6pg*e x$\8d;S BOe

    6e0_)[mGi154414    本用例的开端是 ATM 处于准备就绪状态。
    J:}8vL'{B-|15441451Testing软件测试网b/ybuO
       1. 准备提款 - 客户将银行卡插入 ATM 机的读卡机。
    ;_9N/IbE(X7k2^8^154414      　51Testing软件测试网O O5X&f)m ~W
       2. 验证银行卡 - ATM 机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。
    3]6Lv"dvvLx.dj154414      　
    s#E/xR*W'k154414   3. 输入 PIN - ATM 要求客户输入 PIN 码（4 位）51Testing软件测试网7Wx.@!S"n1r z+c
          　
    q3`"w8Or(Q c154414   4. 验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN 对该帐户来说是否正确。对于此事件流，帐户是有效的而且 PIN 对此帐户来说正确无误。51Testing软件测试网.wW*NNc4MP:d
          　51Testing软件测试网oM/}!D9f!HL
       5. ATM 选项 - ATM 显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。
    4[ R~7kp.r154414      　51Testing软件测试网3gVXm\H
       6. 输入金额 - 要从 ATM 中提取的金额。对于此事件流，客户需选择预设的金额（10 美元、20 美元、50 美元或 100 美元）。51Testing软件测试网K b)wH0N-\R,_ {
          　51Testing软件测试网*BC6U5oc[N'CTs$_
       7. 授权 - ATM 通过将卡 ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。51Testing软件测试网vf0gr AG
          　
    %P3Kb#Z-V&S+j O&j154414   8. 出钞 - 提供现金。51Testing软件测试网L!dI4tT z%J yy6Z
          　51Testing软件测试网MoJJ&PM$|
       9. 返回银行卡 - 银行卡被返还。
    8`I7["gW;q5i9t154414      　
    %{ P/@6O*kUh;[~154414  10. 收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。
    2p9i zLz:C/Tc15441451Testing软件测试网Z3R"coW R'g`%E A*}c
    用例结束时 ATM 又回到准备就绪状态。
    m*| \&JUWZ,X"`H ft154414　51Testing软件测试网$XHo'sF\+dU
    备选流 1 - 银行卡无效     在基本流步骤 2 中 - 验证银行卡，如果卡是无效的，则卡被退回，同时会通知相关消息。
    $yuB0x@,A154414备选流 2 - ATM 内没有现金     在基本流步骤 5 中 - ATM 选项，如果 ATM 内没有现金，则“提款”选项将无法使用。51Testing软件测试网%\:E4G3@&r(E
    备选流 3 - ATM 内现金不足     在基本流步骤 6 中- 输入金额，如果 ATM 机内金额少于请求提取的金额，则将显示一则适当的消息，并且在步骤 6 - 输入金额处重新加入基本流。
    t*l;lpq.w ~154414备选流 4 - PIN 有误     在基本流步骤 4 中- 验证帐户和 PIN，客户有三次机会输入 PIN。
    {5OxC4{ E0}154414
    9O`.[Mzgt,@154414如果 PIN 输入有误，ATM 将显示适当的消息；如果还存在输入机会，则此事件流在步骤 3 - 输入 PIN 处重新加入基本流。
    u7rF3f] i?u7m A154414
    a.F~UkL5v:T154414如果最后一次尝试输入的 PIN 码仍然错误，则该卡将被 ATM 机保留，同时 ATM 返回到准备就绪状态，本用例终止。
    {*\Y y2c,d;G D154414备选流 5 - 帐户不存在     在基本流步骤 4 中 - 验证帐户和 PIN，如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款，则 ATM 显示适当的消息并且在步骤 9 - 返回银行卡处重新加入基本流。51Testing软件测试网0}+Mo~2D
    备选流 6 - 帐面金额不足     在基本流步骤 7 - 授权中，银行系统返回代码表明帐户余额少于在基本流步骤 6 - 输入金额内输入的金额，则 ATM 显示适当的消息并且在步骤 6 - 输入金额处重新加入基本流。
    ] h x j|k`h@154414备选流 7 - 达到每日最大的提款金额     在基本流步骤 7 - 授权中，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在 24 小时内允许提取的最多金额，则 ATM 显示适当的消息并在步骤 6 - 输入金额上重新加入基本流。
    )s } R Q*An:Q154414备选流 x - 记录错误     如果在基本流步骤 10 - 收据中，记录无法更新，则 ATM 进入“安全模式”，在此模式下所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明 ATM 已经暂停工作。51Testing软件测试网$w} nSx/s Q~
    备选流 y - 退出     客户可随时决定终止交易（退出）。交易终止，银行卡随之退出。
    8aAV*@"I V:fC154414备选流 z - “翘起”     ATM 包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。在任一时刻，如果某个传感器被激活，则警报信号将发送给警方而且 ATM 进入“安全模式”，在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。
    &~MJaad/tN J15441451Testing软件测试网s|3h$_e,bC
    51Testing软件测试网:K4o E!?&K8?Vu
    在第一次迭代中，根据迭代计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：51Testing软件测试网^dyG2`9Ns `ZXP

    O L2z0M0Z$x.n154414        * 基本流 - 提取预设金额（10 美元、20 美元、50 美元、100 美元）
    XG{V4jTSfRM)N154414        * 备选流 2 - ATM 内没有现金51Testing软件测试网-g(i"x,h R:fqI
            * 备选流 3 - ATM 内现金不足
    e9I;~y2cb I,x154414        * 备选流 4 - PIN 有误51Testing软件测试网 `e+{Vc;ZA:s
            * 备选流 5 - 帐户不存在/帐户类型有误
    ,`%h u5h7}6Q2O_154414        * 备选流 6 - 帐面金额不足 51Testing软件测试网+F7`7Yj;XkGu:A

    *wL:g8g@154414可以从这个用例生成下列场景
    Y/^"jTG9?6o154414场景 1 - 成功的提款     基本流     
    :D,O8u?*`-V154414场景 2 - ATM 内没有现金     基本流     备选流 251Testing软件测试网 A7JU:dumF'gi
    场景 3 - ATM 内现金不足     基本流     备选流 351Testing软件测试网g~8K&o5v F
    场景 4 - PIN 有误（还有输入机会）     基本流     备选流 4
    )})?n;bU]154414场景 5 - PIN 有误（不再有输入机会）     基本流     备选流 4
    7QI-_ I ~s154414场景 6 - 帐户不存在/帐户类型有误     基本流     备选流 5
    #Se |8l2ab d"zI0bQ154414场景 7 - 帐户余额不足     基本流     备选流 6
    ;n DMKv-z)}.G/z1nz15441451Testing软件测试网w n SDG,q,\
    注：为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入上表。
    'j%s*cLku)F~$M154414
    0P)`-C;V*n0S-e+^154414对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例 ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
    \I/SoCW G1qFLjn154414
    fB%]*`9sM(f5l4Z2DY154414通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。51Testing软件测试网ldyid9iU
    TC（测试用例）ID 号     场景/条件     PIN51Testing软件测试网*d!R8qBH-k
    51Testing软件测试网#`"U c|!gu)h'y]4K#t
     51Testing软件测试网q'ZNu"f,@(lXR
        帐号51Testing软件测试网-I Ms%T(sa8d

    8`:nv3]5JB5qX154414 
    D&Iq gx;J154414    输入的金额
    C b`Y*T+AG ]154414
    !j8M0] ps0d+d154414（或选择的金额）51Testing软件测试网,]n4m v[/W

    w?)j\tIXe GQ154414 
    .rQ/t ^h154414    帐面金额
    8j%y)l)Uf15441451Testing软件测试网#\F.Y _,TY
     
    g'L!V%k2D9`qC#S154414    ATM 内的金额51Testing软件测试网B[,Q*PK0E-jD Q9r

    ,iA8I5cl154414 51Testing软件测试网aA@B9g|T N1pb
        预期结果51Testing软件测试网RX0toM?+o0r(r
    CW1.     场景 1 - 成功的提款     V     V     V     V     V     成功的提款。51Testing软件测试网ai z-J$ep&i7v.QM8r
    CW2.     场景 2 - ATM 内没有现金     V     V     V     V     I     提款选项不可用，用例结束51Testing软件测试网Ef7ejEr\| h
    CW3.     场景 3 - ATM 内现金不足     V     V     V     V     I     警告消息，返回基本流步骤 6 - 输入金额
    kJx7aUt154414CW4.     场景 4 - PIN 有误（还有不止一次输入机会）     I 51Testing软件测试网,`'}%R`s
    51Testing软件测试网+b-P7E y(c Z2}
     
    $`t] wzm/A7h154414    V     n/a     V     V     警告消息，返回基本流步骤 4，输入 PIN51Testing软件测试网9Tq%C G#dJWD
    CW5.     场景 4 - PIN 有误（还有一次输入机会）     I 51Testing软件测试网#W"H8\:_vq-W0^$q
    51Testing软件测试网(B9nW Q(\O8DR_b.r w
     
    .P7\m9A`'}Y d7G&{154414    V     n/a     V     V     警告消息，返回基本流步骤 4，输入 PIN
    ^%~5k!Cm154414CW6.     场景 4 - PIN 有误（不再有输入机会）     I 51Testing软件测试网 h)x k5| | A

    MG2k.m9C2F+l:b154414 
    I Tf@rhO154414    V     n/a     V     V     警告消息，卡予保留，用例结束51Testing软件测试网 uK@j8{ ~ EK1G?i

    ([S&Cn~:m154414在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由 CW2 至 6 表示（阴影单元格表明这种条件下需要执行备选流）。虽然 CW2 至 6 对于基本流而言都是负面测试用例，但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 - 基本流）。  
    g ^&h9Z uO/|4L"`.g1MV154414
    7A/FE_7M154414每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误，至少需要三个正面测试用例（以激活场景 4）：51Testing软件测试网(nZ.S!L4kU CS~&I

    Z%O;fC|[154414    * 输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。51Testing软件测试网2nm8pW%vg
        * 输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。
    _5?[1} C`_9e1M154414    * 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。
    J@#G#O}D]15441451Testing软件测试网 S;MeEt z$p K
    注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式    创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。
    F)C5\2S_ W154414
    8w+R#`[sq dUo h154414一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。51Testing软件测试网!Rc;Vn%U`5b8Gt?1v _

    ny~ U:?154414测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据51Testing软件测试网9RZU f ]H U/g
    TC（测试用例）ID 号     场景/条件     PIN51Testing软件测试网(IC2I'zL'a'a l

    8` J G,t'k"P O-D} d$m154414 51Testing软件测试网v'dN&p*rd
        帐号
    ngN1V7Fi f154414
    _M.G%F|ID154414 
    5e$qL-}D&W.oGm{154414    输入的金额
    +cS$Q5zEj154414
    l%Gk&P'`!v]w154414（或选择的金额）51Testing软件测试网Sow^M!d9}

    vh'BrWL154414 
    6d`M]I154414    帐面金额51Testing软件测试网;FM$C2l sn
    51Testing软件测试网"V6OE2tz
     
    4R9n0~)^ @&L\154414    ATM 内的金额51Testing软件测试网 B8Y ]U9{vRu

    KYUl4}mR154414 51Testing软件测试网`5yq;^1w4^&F'\f
        预期结果
    e} Y-J@ \3g'X154414CW1.     场景 1 - 成功的提款     4987     809 - 498     50.00     500.00     2,000     成功的提款。帐户余额被更新为 450.00
    :yb-d Z7k S-IYpi"w#j154414CW2.     场景 2 - ATM 内没有现金     4987     809 - 498     100.00     500.00     0.00     提款选项不可用，用例结束
    "E,rA1z%kB? f;@,Y154414CW3.     场景 3 - ATM 内现金不足     4987     809 - 498     100.00     500.00     70.00     警告消息，返回基本流步骤 6 - 输入金额51Testing软件测试网CS zY,P
    CW4.     场景 4 - PIN 有误（还有不止一次输入机会）     4978 51Testing软件测试网 Rcj0t-L}F.`

    #\'Ik7Y)DkzG$g154414 51Testing软件测试网yTCf[eV bv5N
        809 - 498     n/a     500.00     2,000     警告消息，返回基本流步骤 4，输入 PIN
    3L @,Q)M O d154414CW5.     场景 4 - PIN 有误（还有一次输入机会）     497851Testing软件测试网OH&FB(hv

    ,D)Ws"q@u154414 
    S m5O _!~ l*pGh-g154414    809 - 498     n/a     500.00     2,000     警告消息，返回基本流步骤 4，输入 PIN
    }9QZ3MT154414CW6.     场景 4 - PIN 有误（不再有输入机会）     4978
    N"W0X7XC)Jv15441451Testing软件测试网i,x*m!C3P1B
     
    /PI+\U m.Z(lV154414    809 - 498     n/a     500.00     2,000     警告消息，卡予保留，用例结束51Testing软件测试网tu&X(CY
    51Testing软件测试网6g1yuG5lrMy!_
    以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：51Testing软件测试网^~0_m9Wl` CH

    ;UOY/L+NH1L154414    * 场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用
    ]h {1`1P!T154414    * 场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款51Testing软件测试网"P#H2X2ww7V/{S
        * 场景 7 - 帐户余额不足：请求的金额超出帐面金额
    f#b$F]TzA K \-s154414
    %{QJ)N8WmI154414在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：
    8[.Qz9|:\ |v J;u154414
    [%e/N,m%sQ154414    * 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）
    *D NGY`xG-sQ154414    * 无法读卡（读卡机堵塞、脱机或出现故障）
    -Q2N}'aC.H R5l154414    * 帐户已消户、冻结或由于其他方面原因而无法使用51Testing软件测试网%~%}g;B/WweDTt
        * ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）51Testing软件测试网v0g*fuT:@&b
        * 无法联系银行系统以获得认可
    bKr`~&x;RG154414    * 银行网络离线或交易过程中断电
    :DEIb d15441451Testing软件测试网C,G/j\ Ed
    在确定功能性测试用例时，确保满足下列条件：51Testing软件测试网 _4jS.k ]yc

    hz]w3l'Z@0QH0B8e154414    * 已经为每个用例场景确定了充足的正面和负面测试用例。
    AL9\_:C'K-n;r]154414    * 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边界条件/值上都存在测试用例。
    $vUM~-P/v154414    * 测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还应能处理用户界面对象状态或条件。51Testing软件测试网,j6KU3P:o0SEZ
        * 测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。 51Testing软件测试网gc8x L*| TfU6O
    51Testing软件测试网Z4Y+SZ1Z? E
    八、从补充规约中生成测试用例
    AjrkN$XBK o154414
    PY#[Cy8rJl r154414并不是所有的测试目标需求都将在用例中有所反映。非功能性需求（如性能、安全性和访问控制）以及配置要求等将会说明测试目标的其他行为或特征。补充规约是为其他行为生成测试用例的主要来源。51Testing软件测试网&B uT!YUF
    51Testing软件测试网 C`&k#f'{QbcG-a'~m
    关于如何生成这些其他测试用例的指南说明如下：
    %c9x1Yt#lyo15441451Testing软件测试网`lo,i2@;CY
        * 为    性能测试生成测试用例
    };b$OE%exf154414    * 为安全性/访问控制测试生成测试用例51Testing软件测试网r3j&|E0aW7E
        * 为配置测试生成测试用例51Testing软件测试网0Y/X-o.A:H:dAF'h
        * 为安装测试生成测试用例
    T~vk)x(w"?$Y%h154414    * 为其他非功能性测试生成测试用例
    {w[0? o[15441451Testing软件测试网_5g&o!T9z0R7a
    为性能测试生成测试用例51Testing软件测试网SF)k,e4`7kR
    51Testing软件测试网.[({Yj+S Z&Wb)FR1N*D%^
    性能测试用例的主要输入是补充规约，补充规约中包含了非功能性需求（请参见工件：补充规约）。为性能测试生成测试用例时，请使用下列指南：
    F1xT5EZq`154414
    .M.kV7Y1ZE2N*ww O154414    * 对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例。性能标准通常表示为时间/事务、事务量/用户或百分数的形式。
    0X6a;l!~.d2C@154414    * 对每个关键用例，都应确保至少要确定一个测试用例。关键用例是在上述说明中和/或在工作量分析文档中确定的、必须采用性能评测方法来评估的用例（请参见工件：工作量分析文档）。 51Testing软件测试网9V}m#R#@zb-a
    51Testing软件测试网vIR2?$t$ZR
    与功能性测试的测试用例类似，通常对于每个用例/需求都会存在不止一个测试用例。常见的情况是：存在一个低于性能阈值的测试用例、一个处于阈值上的测试用例，还有一个测试用例高于阈值。51Testing软件测试网c/pun&@yMkQ$x@
    51Testing软件测试网.]|H\%t'p+l
    除了以上性能标准以外，确保已确定影响响应时间的特定条件，包括：
    U8T7n$h'h154414
    -rz%[F u A'z;LY#k154414    * 数据库的大小 - 存在多少个记录？51Testing软件测试网X8DZfk V {
        * 工作量 - 同时执行操作的最终用户的数量和类型，以及要同时执行的事务的数量和类型51Testing软件测试网u6l zz C-~i
        * 环境特征（硬件、网件以及软件配置） 51Testing软件测试网I8N f5nW4n3T)};q Ut
    51Testing软件测试网\)IRN:{
    将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。
    z d NI!M!m}0qR15441451Testing软件测试网3I,H}h+Y*J1a:c
    以下是各种性能测试的一些示例：51Testing软件测试网n)nXq3\$_!g1{
    51Testing软件测试网A Y:a*f8b~_E
    对于    负载测试：51Testing软件测试网'e1G!|c9fOk/}
    TC（测试用例）ID 号     工作量     条件51Testing软件测试网P+lf.r s

    F6k0J/v ?i154414 
    $be G]*z.o1M'Tv"_154414    预期结果51Testing软件测试网 AP'[ u,f4rgm
    PCW1.     51Testing软件测试网7x;N4qh_9Fs jP
    51Testing软件测试网a FhEq] J
    151Testing软件测试网0AF Y]:^.G8x

    \!Mo/r@by+l154414（单个 ATM）51Testing软件测试网1| r O H} F } Y;V w)iA]
       
    7ae Y}~M15441451Testing软件测试网1O-MF,F%?,r
    完成提款交易51Testing软件测试网.K(D-L9m(|:o!CG:Uz
        全部交易（不依赖于主角的时间）在 20 秒之内完成51Testing软件测试网wz-sS'v#Ih;y&n
    PCW2.     51Testing软件测试网`B)]j!RK B

    jW)L b)TQ$XT1544142
    ;A1DvC3c y[154414
    8F;T+w!k x r:R y;{154414（1,000 个同时运行的 ATM）51Testing软件测试网G PcH(@'txI:y
       
    *r8|uC"S'f"\ X15441451Testing软件测试网HWw i]3oY
    完成提款交易
    9Q IS*@;J7ec154414    全部交易（不依赖于主角的时间）在 30 秒之内完成51Testing软件测试网jA-B B'I.E8L[
    PCW3.     51Testing软件测试网rj,AUotk5KZ

    (c,@8JMt~3A r1544143
    M8y3bTT`+S15441451Testing软件测试网5d(f$qQ2?{GD
    （10.000 个同时运行的 ATM）
    8@C y| a$F s-hRV-n154414    51Testing软件测试网O!o Uc H x

    n[yR5o3k'n{*T3R{154414完成提款交易
    %p5]4^Os'b G154414    全部交易（不依赖于主角的时间）在 50 秒之内完成
    ;xZKe!s&zh154414
    {9hg4E!P154414对于强度测试：
    (~ z8Ncxa154414TC（测试用例）ID 号     工作量     条件51Testing软件测试网hHz2O k-n7ZI
    51Testing软件测试网f d%@"e(c:@O c2l/C
     
    gzl0DXB7oU e154414    预期结果
    Cbf0V7X/n154414SCW1.    
    uJ@#[H.fw/?8x154414
    "w;Br1hk*gz f#F154414251Testing软件测试网#V-C:k:Dr4u2kZNr"W
    51Testing软件测试网4q\A2c@ x
    （1,000 个同时运行的 ATM）51Testing软件测试网"kYmHS-e1o%w[s
        51Testing软件测试网9HCF7gSi:u%^Y

    Z#kU2[tJ154414数据库锁定 - 2 个 ATM 请求同一帐户
    ,q DwN@ ZiL#`154414    ATM 请求排成队列
    .R mv,l8bQ@154414SCW2.    
    8|R8R jU4mFRk15441451Testing软件测试网V9H(zq+o OU
    2
    I

    查看(690) 评论(0) 收藏 分享 管理

  • 一个性能测试的案例（转自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、批准

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

    查看(526) 评论(0) 收藏 分享 管理

  • LoadRunner协议选择（转）

    2008-12-08 17:23:08

    正确选择协议，就要熟悉被测试应用的技术架构。以下列出一些LoadRounner支持的协议：

    　　一般应用：C Vuser、VB Vuser、VB scrīpt Vuser、JAVA Vuser、Javascrīpt Vuser

    　　电子商务：WEB（Http/Html)、FTP、LDAP、Palm、Web/WinsocketDual Protocol

    　　客户端/服务器：MS SQL Server、ODBC、Oracle、DB2、Sybase CTlib、Sybase DBlib、Domain Name Resolution(DNS)、Windows Socket

    　　分布式组件：COM/DCOM、Corba-Java、Rmi_Java

    　　EJB：EJB、Rmi_Java

    　　ERP/CRP： Oracle NCA、SAP-Web、SAPGUI、SAPGUI/SAP-Web Dual Protocol、PropleSoft_Tuxedo、Siebel Web、Siebel-DB2 CLI、Sieble-MSSQL、Sieble Oracle

    　　遗留系统：Terminal Emulation (RTE)

    　　Mail 服务：Internet Messaging(IMAP)、MS Exchange(MAPI)、POP3、SMTP

    　　中间件：Jacada、Tuxedo 6、Tuxedo 7

    　　无线系统：i-mode、voiceXML、WAP

    　　应用部署软件：Citrix_ICA流：Media Plays(MMS)、Real

    　　一段对于loadrunner协议选择的经典解答协议是数据在网络中传输的结构模式。协议不同，其数据报文的结构也有所不同。协议是有层次的，一般我们从ip层开始，往上有TCP协议层，UDP协议层，而TCP和UDP协议层上又有http协议层，ftp协议层，smtp协议层等我们在lr中看到的这些应用层的协议。其实这些高层协议都是对底层协议进行的进一步封装。举个简单例子，本来IP协议的数据报文是无序，不是可靠传输的，在其数据报文外面增加了报文序号，报文状态等数据段就构成了TCP协议层。所以我们很多网络应用，没有找到合适的协议，就用winsock来录制，那是肯定没有问题的。因为几乎所有的网络传输中都是基于tcp 协议或udp协议的，而socket正是这一级上的概念。但是由于socket协议级别太低，你录下来的东西是很难理解的，都是 socket，port，data之类的东西。所以，我们尽量用高层协议来录制，我们就能看懂了。

    　　话要再说回来，解决一下具体的问题。我们看到一个软件体系架构，应该怎样选择录制协议呢？说到这里，我要说一下自己对lr录制机理的理解（我没有接触过lr内核，只是凭猜测和推断）。在录制时，lr应该会对你从本机发出去的数据进行截包，并拆包。因为我们知道协议的不同就是体现在数据包的结构不同，lr应该通过对包结构的分析，判断是不是它支持的协议，对包数据的分析，来获取用户发送的东西。比如你用ftp的协议去录制一个访问网页的IE操作，那肯定是无所收获的。因为lr没有在网络截获到 ftp协议格式的包，都是http协议格式的包，它不认，当然就是一个录制为空的结果了。现在我们弄懂了这个事情，就知道该如何选择协议了。看见很多人关心lr是不是支持mysql协议。我认为要寻找的答案的思路是这样的：

    　　1、首先弄清mysql协议和其他数据库协议的关系，看能不能用其它数据库协议录制。但其实oracle的cs协议是oracle独有自己开发的协议，sqlserver也是一样，而mysql又与这几大产品又不是隶属关系，其脚本录制的可能性很小。

    　　2、mysql协议的底层是基于什么协议的，如果直接构建在tcp协议上，lr又不支持mysql协议，那只能考虑用低一点的协议录录看，即socket。如果mysql协议是构建在odbc协议上的，那么就可能用lr的odbc api来写。

    　　很多时候一提到不是基于浏览器的应用，很多人就会想到用 WinSocket协议来录制，仿佛Form窗体都可以用Winsocket 。从道理上讲网络通讯的底层都是基于Socket的，例如TCP、UPD等，似乎所有的程序都可以用Socket协议来录制。但是事实不是这样的，因为选择的协议决定了LoadRunner如何捕获数据包。否则会多捕获很多无用的数据。因此，不是所有的程序都是适合WinSocket协议的。实际上，那些基于Socket开发的应用才真正适合Socket协议来进行录制。其他的，例如基于数据库的应用，就不太时候Socket协议，甚至可能录制不到脚本。很多C/S程序，一定要选择合适的协议。根据作者的经验，C/S的程序多数需要手工开发很多脚本，因为录制的很多回放时候或多或少都会有些问题，但是可以参考录制的结果。所以测试一个程序，一定要搞清楚开发人员用了什么技术、数据流是什么协议封装的。理论上来说我们在对一个系统做性能测试以前，要先和开发人员了解一下他们在开发过程中都用了些什么技术，数据流是用什么协议封装的，还要了解我们要测试的系统的网络结构，服务器的配置等问题；还有就是要知道系统客户端和第一服务器间的协议，这中间就涉及到一个中间件的问题。另外我们要知道协议的选择直接关系到LR会捕获到什么样的数据包。这些是进行性能测试的基础。 下面说几个测试的原则（都是自己遇到过的，呵呵，没遇到过的就不知道了）：

    　　1、一般情况下b/s构架的只要 选择WEB（Http/Html)协议就可以了，如果有中间件的则选择中间件服务器的协议 ；

    　　2、C/S结构，可以根据后端数据库的类型来选择。如SybaseCTLib协议用于测试后台的数据库为Sybase的应用；MS SQL Server协议用与测试后台数据库为 SQL Server的应用；

    　　3、一般不是基于浏览器的，对于一些没有数据库的 Windows应用，我们在测试的过程中都会选择WinSocket协议来录制，理论上来讲我们这样选择是正确的，但我们要知道在录制的时候所选择的协议就决定了LR如何捕获数据包，如果我们选择错误了，将会捕获到一些无用的数据包。cs结构是比较复杂的，在这里我要提醒大家，一定要搞清楚cs是 client-database还是client-server-database结构的，只有这样我们才能够决定是选择WinSocket协议还是 sql协议，或者说选择多个协议；当然协议的选择也是一个探索的过程，只要能够得到我们想要的结果，那就是正确的。还有一点，我们在做性能测试的时候应该是有测试重点的，呵呵。

    　　4、关于单协议和双协议，我只知道IE6内核的浏览器在录制脚本的时候要选择单协议，而IE7内核的浏览器在录制脚本的时候要使用双协议。

    查看(421) 评论(0) 收藏 分享 管理

  • LoadRunner的脚本回放问题解决

    2008-12-08 17:18:09

    在运行脚本回放过程中，有时会出现错误，这在实际测试中是不可避免的，毕竟自动录制生成的脚本难免会有问题，需要运行脚本进行验证，把问题都解决后才加入到场景中进行负载测试。下面结合常用的协议（如Web、Web Services协议）录制的脚本进行回放时出现的问题介绍一下解决的方法。

    　　需要注意的是，回放脚本时出现的错误有时是程序自身的原因导致的，因此在解决脚本回放问题前必须保证程序录制出的脚本是正确的。

    　　1．LoadRunner超时错误：在录制Web协议脚本回放时超时情况经常出现，产生错误的原因也有很多，解决的方法也不同。

    　　错误现象1：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。

    　　错误分析：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。

    　　解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在“Runtime Setting”>“Internet Protocol：Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项，再回放是否成功。

    　　错误现象2：Action.c(81):Continuing after Error -27498: Timed out while processing URL=http://172.18.20.70:7001/workflow/bjtel/leasedline/ querystat/ subOrderQuery.do

    　　错误分析：这种错误常常是因为并发压力过大，服务器端太繁忙，无法及时响应客户端的请求而造成的，所以这个错误是正常现象，是压力过大造成的。

    　　如果压力很小就出现这个问题，可能是脚本某个地方有错误，要仔细查看脚本，提示的错误信息会定位某个具体问题发生的位置。

    　　解决办法：例如上面的错误现象问题定位在某个URL上，需要再次运行一下场景，同时在其他机器上访问此URL。如果不能访问或时间过长，可能是服务器或者此应用不能支撑如此之大的负载。分析一下服务器，最好对其性能进行优化。

    　　如果再次运行场景后还有超时现象，就要在各种图形中分析一下原因，例如可以查看是否服务器、DNS、网络等方面存在问题。

    　　最后，增加一下运行时的超时设置，在“Run-Time Settings”>“Internet Protocol:Preferences”中，单击“options”，增加“HTTP-request connect timeout” 或者“HTTP-request receive”的值。

    　　2．LoadRunner脚本中出现乱码：在录制Web协议脚本时出现中文乱码，在回放脚本时会使回放停止在乱码位置，脚本无法运行。

    　　错误现象：某个链接或者图片名称为中文乱码，脚本运行无法通过。

    　　错误分析：脚本录制可能采用的是URL-based scrīpt方式，如果程序定义的字符集合采用的是国际标准，脚本就会出现乱码现象。

    　　解决办法：重新录制脚本，在录制脚本前，打开录制选项配置对话框进行设置，在“Recording Options”的“Advanced”选项里先将“Surport Charset”选中，然后选中支持“UTF-8”的选项。

    　　3．LoadRunner HTTP服务器状态代码：在录制Web协议脚本回放脚本的过程中，会出现HTTP服务器状态代码，例如常见的页面-404错误提示、-500错误提示。

    　　错误现象1：-404 Not Found服务器没有找到与请求URI相符的资源，但还可以继续运行直到结束。

    　　错误分析：此处与请求URI相符的资源在录制脚本时已经被提交过一次，回放时不可再重复提交同样的资源，而需要更改提交资源的内容，每次回放一次脚本都要改变提交的数据，保证模拟实际环境，造成一定的负载压力。

    　　解决办法：在出现错误的位置进行脚本关联，在必要时插入相应的函数。

    　　错误现象2：-500 Internal Server Error服务器内部错误，脚本运行停止。

    　　错误分析：服务器碰到了意外情况，使其无法继续回应请求。

    　　解决办法：出现此错误是致命的，说明问题很严重，需要从问题的出现位置进行检查，此时需要此程序的开发人员配合来解决，而且产生的原因根据实际情况来定，测试人员无法单独解决问题，而且应该尽快解决，以便于后面的测试。

    　　4．LoadRunner请求无法找到：在录制Web协议脚本回放脚本的过程中，会出现请求无法找到的现象，而导致脚本运行停止。

    　　错误现象：Action.c(41): Error -27979: Requested form. not found [MsgId: MERR-27979]

    　　Action.c(41): web_submit_form. highest severity level was "ERROR",0 body bytes, 0 header bytes [MsgId: MMSG-27178]"

    　　这时在tree view中看不到此组件的相关URL。

    　　错误分析：所选择的录制脚本模式不正确，通常情况下，基于浏览器的Web应用会使用“HTML-based scrīpt”模式来录制脚本；而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的Javascrīpt/VBscrīpt代码、基于浏览器的应用中使用HTTPS安全协议，这时则使用“URL-based scrīpt”模式进行录制。

    　　解决办法：打开录制选项配置对话框进行设置，在“Recording Options”的“Internet Protocol”选项里的“Recording”中选择“Recording Level”为“HTML-based scrīpt”，单击“HTML Advanced”，选择“scrīpt Type”为“A scrīpt containing explicit”。然后再选择使用“URL-based scrīpt”模式来录制脚本。

    　　5．LoadRunner不执行检查方法：在录制Web协议脚本中添加了检查方法Web_find，但是在脚本回放的过程中并没有执行。

    　　错误现象：在脚本中插入函数Web_find，在脚本中设置文本以及图像的检查点，但是在回放过程中并没有对设置的检查点进行检查，即Web_find失效。

    　　错误分析：由于检查功能会消耗一定的资源，因此LoadRunner默认关闭了对文本以及图像的检查，所以在设置检查点后，需要开启检查功能。

    　　解决办法：打开运行环境设置对话框进行设置，在“Run-time Settings”的“Internet Protocol”选项里的“Perference”中勾选“Check”下的“Enable Image and text check”选项。

    　　6．LoadRunner回放Web Services协议脚本错误：LoadRunner 8.0版本在录制Web Services协议的脚本时正常，但在回放时会出现错误，提示停止脚本运行。

    　　错误现象：利用LoadRunner 8.0版本来录制Web Services协议的脚本没有任何错误提示，回放脚本时会出现如下错误提示“Error：server returned an incorrectly formatted SOAP response”。

    　　错误分析：出现此错误的原因是LoadRunner8.0在录制Web Services协议的脚本时存在一个缺陷：如果服务器的操作系统是中文的，VuGen会自动将WSDL文件的头改为<?xml version="1.0"encoding="zh_cn" ?>，所以才会有此错误提示。

    　　解决办法：下载两个补丁，分别为“LR80WebServicesFPI_setup.exe”和“lrunner_web_ services_patch_1.exe”安装上即可。

    查看(2219) 评论(0) 收藏 分享 管理

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

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

    查看(477) 评论(0) 收藏 分享 管理

  • web测试经典总结（转）

    2008-12-01 10:37:58

    　网络转载　　作者不详
    "q]%k4@t KM154414　　基于Web的系统测试在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

    　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。 一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。

    　　Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

    　　一、 功能测试
    Ogl5d ~9qY154414　　1、链接测试 链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。 链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

    　　2、表单测试 当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

    　　3、Cookies测试 Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

    　　4、设计语言测试 Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

    　　5、数据库测试 在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。 在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

    　　二、 性能测试

    　　1、连接速度测试

    　　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。 另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

    　　2、负载测试

    　　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？

    　　3、压力测试

    　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。 进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。 压力测试的区域包括表单、登陆和其他信息传输页面等。

    　　三、 可用性测试

    　　1、导航测试 导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？ 在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。 导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。 Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。 
    \3uxtY$Qfxj3L154414
    /z5jj$W;W-~154414    2、图形测试 在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。

    　　图形测试的内容有：
    ?Z`c)f9qv;I154414　　（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。 51Testing软件测试网#E,FEh U'LB
    　　（2）验证所有页面字体的风格是否一致。 51Testing软件测试网"LVS^LXLu^
    　　（3）背景颜色应该与字体颜色和前景颜色相搭配。
    oW$?4lh7w154414　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

    　　3、内容测试

    　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。 信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

    　　4、整体界面测试

    　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？ 对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。 对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

    　　四、 客户端兼容性测试

    　　1、平台测试

    　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

    　　2、浏览器测试

    　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，Javascrīpt是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

    　　五、 安全性测试

    　　Web应用系统的安全性测试区域主要有：

    　　（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

    　　（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

    　　（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

    　　（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

    　　（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

    　　六、总结

    　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。 基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测

    查看(717) 评论(0) 收藏 分享 管理

  • 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字符

    查看(393) 评论(0) 收藏 分享 管理

  • ODC(Orthogonal Defect Classification)简介

    2008-11-28 13:27:34

    转自：http://www.ibm.com/developerworks/cn/java/j-odc/

    Defect分析是软件开发和测试中一个重要的环节，ODC介绍了一种不同于大家常 用的非常有效的defect分类及分析方法。这篇文章简单的向大家介绍了什么是ODC，以及如何在项目和产品开发中使用ODC来改进开发测试流程从而增强 产品质量。希望读者具有基本的软件开发和测试经验，并且了解defect分析的基本方法。

    Defect 分类帮助改进产品质量

    软件开发中都包含有控制软件开发的流程。我们设计模块、开发代码、对产品进行测试、然后发布产品。但是，我们怎样从以前的错误中学习，怎样做得更好 呢？一般情况下，我们会拿一些输出的数据来进行分析，从而知道我们应该怎么样和进行什么样的改进（如图1）。但是如何确定我们做的努力是真正有用的呢？这 就是defect classification (defect分类) 能够帮助我们的地方，如果我们可以正确的使用defect classification，它会对我们有很多的帮助。


    图1
    图1






    几种常见的defect 分类方法

    在软件开发过程中我们会在不同的阶段发现数量不等的defect，如图2所示，对于所发现的defect我们可以逐一的对它们进行分析，例如使用 root causal analysis方法，可是这种分析方法占用了大量的时间和资源，显然我们非常需要有一种方法可以明确地告诉我们应该在哪里改进。


    图2
    图2

    下面我们来看看几种我们常见的defect 分析方法：

    按照defect 严重程度分类

    我们在测试过程中会根据defect的严重程度对defect 进行分类，在这里我们将严重度称为severity, 我们有如下图所示的一个项目不同测试阶段的defect的分布图：


    图3
    图3

    在这个图中defects跟据它们的severity属性进行了分类， severity为1的defect是最严重的defect, 它使系统根本不能运转，需要立即进行改正。那severity为 2的defect 是一般功能性的错误，这些错误是需求中所要求的，必须改正才能实现系统完整的功能。Severity 为3的defect是一些细小的错误，它们不影响功能的实现，但可能引起用户的误解或者使用不当。Severity为4 的 的defect是测试人员建议改进的地方，如果时间允许开发人员可以选择性的改正，或者等到下个版本中再改进。从图3中我们可以看到第一个图是在一个项目 测试前期的时候，这时候1级的defect很多，整个系统还不能够运转，正需要大量的时间和人力进行测试和改正代码错误。第二个图则显示项目测试已经到了 中期，这时候最严重的defect已经很少了，系统已经基本可以运转，然后测试人员发现了大量的功能性的错误和细节上的错误需要改正。第三个图显示了项目 测试已经到了末期，这时的产品需求的功能已经实现，只有部分细节和建议需要改进，产品已经可以发布了。在用severity分类的图表中，我们可以了解到 以下有关项目的几个方面：

    1) 工作的优先级

    2) 项目的进展状态

    3) 产品的质量

    按照component/module分类

    对于不同的component或者module，我们也可以有类似的defect分布图来说明另外一些问题：


    图4
    图4

    图4中，对于第一个图，我们能看出C模块中发现的defect明显的比其他模块的少，那么原因可能是C模块的开发人员技术非常的好。第二个图中我们 可以看出A和C中发现的defect明显比其他两个模块的多，那么可能这两个模块的难度、大小或者是改动的变化比较大，因此而造成了它们中发现的 defect比较多。对于第三个图，C模块的defect明显比其他的多，那么可能是C模块的开发人员太差了，需要管理者的特别关注了。






    Orthogonal Defect Classification简介

    下面我们来介绍ODC，什么是ODC（Orthogonal Defect Classification）呢？简单的说，它是另外一种defect分类的方法，它使你能够快速得到每一个问题的信息来帮助你后面做出正确的决定来解决问题。

    开发中应用ODC

    作为一个开发人员我发现的问题如果按类型（type）分类可能是由如下几种可能：(括号中的英文为缩写图例)

    1) 没有正确的初始化 （Init）

    2) 代码没有正确的check-in （Chk）

    3) 算法问题 （Alg）

    4) 功能性的错误，可能是模块内的功能没有被正确实现，也可能是模块与模块之间相联系的部分没有被正确实现。（Fnct Cls）

    5) 有可能是有关时间的错误 （Time）

    6) 界面相关的错误 （Intf）

    7) 代码之间相关联的错误，例如错误的继承关系 （Rel'n）

    按照type的分类我们有如下的分布图：


    图5
    图5

    图6
    图6

    从图5、图6中，我们可以了解到开发过程中哪个环节的错误比较多，例如图6中算法错误和功能性错误是最多的那么应该在单元测试或者code review中着重注意这两个部分的代码质量。另外从上图中我们也可以知道在哪以及如何来改正错误代码。

    功能测试中应用ODC

    下面我们来看看测试，在FVT（功能测试）中，一个主要的帮助FVT做得更好的指标是trigger, 在ODC中trigger可以简单的理解为是什么样的测试发现了这个defect。在FVT中我们定义了一下4个trigger：Coverage (这里的coverage不是我一般意义上理解的测试覆盖面的意思，它是指normal function, 是任何用户都会用到的功能，基本的、简单的功能)，Variation （对于有些对产品比较熟悉的用户，有可能会愿意用不常用的有创造性方法或者输入来完成同一种动作或者功能，或者单单就是为了挑错，在这些尝试中往往会发现 很多漏掉的defect，例如'边界限制'），Sequencing (用和以前不同的操作流程来完成一种任务功能)，Interaction （当两个或者多个功能模块互相交互时可能会发生一些错误，例如同时启动一些功能时可能会造成系统死机）。

    下面我们举例来看看FVT中按trigger分类的defect分布图：


    图7
    图7

    在图7中我们可以看到，这个产品中在一般的功能Coverage和改变操作顺序Sequencing的测试中发现了比较多的defect, 这说明了代码还需要作更多的单元测试来减少错误，从而我们可以了解到产品的基本质量水平。


    图8
    图8

    在图8中我们可以看到Coverage的错误很少，产品的基本质量是可以保证的；Variation的错误很多（看来测试组做了大量的这方面的测 试），Sequencing 和 Interaction的错误也不少，那么后面的测试中应该加大这两块儿的测试。这里我们可以清楚地知道我们测了什么还有哪块需要加大测试力度。


    图9
    图9

    在图9中我们可以看到Variation的错误很多，那么加大单元测试的力度可以很好的解决这个问题，例如增加更多的边界检查。

    系统测试中应用ODC

    下面再让我们来看看SVT(系统测试)， 在系统测试中，ODC定义了另外一组trigger, 它们是：Blocked （有哪些defect阻止了SVT的执行， 最常见的是FVT的defect），Stress （压力测试的结果很可能是客户最关心的数据），Recovery (对于数据恢复和出错处理)，Restart (x系统的启动和重启)，Hardware configuration (硬件配置)，Software configuration (软件配置)。 下面我们举例来看看SVT中按trigger分类的defect分布图：


    图10
    图10

    在图10中我们看到了Blocked的defect太多了，显然这个时候进行大量的SVT测试是不明智的，那么应该让产品继续的进行功能测试，直到Blocked的问题减少到可以接受为止。


    图11
    图11

    在图11中，我们同样可以了解到SVT中进行了哪些测试，在这里软件配置测试和压力测试是需要加强的。


    图12
    图12

    在图12中，我们可以了解到硬件配置的defect比较多，那么我们应该要求开发人员更关注这部分的代码。

    从上面的分析中我们看到了ODC中trigger告诉了我们哪里发现了问题，应该去做些什么。

    ODC对于客户影响的应用

    那么下面我们再来看看ODC怎么样的来影响客户。软件产品对于客户的影响有哪些方面呢？在ODC中定义了如下方面：

    1. Installability
    2. Security
    3. Performance
    4. Maintenance
    5. Serviceability
    6. Migration
    7. Documentation
    8. Usability
    9. Standards
    10. Reliability
    11. Requirements
    12. Capability


    图13
    图13

    这里图13是一个产品的defect 影响分布图, 我们可以看到这个产品有非常多的问题出在 "capability性能"、"reliability可靠性"、和"usability可用性"上，那么这样的产品如果卖给客户将是可怕的，那么我们 就应该采取相应的动作来完善这几个方面的问题。

    在ODC中，还定义了其他的元素来组合使用以帮助我们更好的了解问题出在哪里，同时帮助我们做出正确的决定。

    在测试人员发现一个问题并且开一个defect时，需要给defect定义下面的属性：

    1) Activity, 它是指在哪种测试中发现的defect, 例如：UT、FVT、SVT 等等。

    2) Trigger, 问题出现的情况

    3) Impact，影响客户的方面

    当开发人员接到一个defect并且开始修改代码时，他需要定义下面的属性：

    1) Target, 将要在哪里改正错误，例如：design、code 等等

    2) Defect Type, defect的类型，例如：算法、初始化 等等

    3) Qualifier: 只有三个，他们是missing、incorrect 和extraneous

    4) Source: defect 的来源，例如：内部代码、outsource的代码等等

    5) Age: defect是新代码还是重写的代码

    具体可以参考下图：


    图14
    图14



    结束语

    在项目和产品开发中，我们经常会想到这样的问题：我们的测试有多有效？单元测试、功能测试、系统测试都做得正确吗？我们怎样在需求、设计、开发阶段 来减少潜在的defect呢？我们的代码已经完成并且准备好了进入到下一个阶段了吗？我们发现的defect有哪些是属于上一个版本的？客户将会感觉我们 的产品质量怎么样呢？这些都是很关键的问题，需要我们改进开发和测试流程，使它们更加有效，从而进一步增强我们产品的质量。那么怎么样改进呢？通过ODC 我们可以知道我们采用的哪种测试方法正在帮助我们找出更多的defect（是基本功能测试，还是边界条件测试或者压力测试），还有defect是由哪种错 误造成的（是初始化的问题或者界面的问题，还是其他的原因），错误是由于代码缺失还是代码错误造成的，defect是在老代码还是新代码中发现的, defect对于客户的影响有哪些有多大。找出了这些问题的答案，我们就可以改进我们开发和测试的有效性，增强产品模块的稳定性，更早的发现那些高风险的 模块，最后使产品的每个版本都比上一个版本质量更好。


    查看(446) 评论(0) 收藏 分享 管理

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

    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%J�z&m0Perf.T.4 平均每日新增会员数量         500   
    3R|"ttq,| J F0Perf.T.5 高峰同一模板下载量           100用户并发下载   
    8Ee"l-i/Fc}"G:}0Perf.T.6 高峰不同模板下载量           150用户并发下载 


    1AYC"I~qPn^0容量：
    [+~Yet�I0编号      项             容量    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%t�Io {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$Z�o1L050        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*` eqLX�qu"`
    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分钟    取消思考时间 

    查看(652) 评论(0) 收藏 分享 管理

  • 软件测试工具汇总（转）

    2008-11-27 10:40:29

    的产品，而MI公司的产品占了主流。

    二、黑盒测试工具

    　　黑盒测试工具适用于黑盒测试的场合，黑盒测试工具包括功能测试工具和性能测试工具。黑盒测试工具的一般原理是利用脚本的录制(Record)/回放(Playback)，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。黑盒测试工具的代表有：Rational公司的TeamTest、Robot；Compuware公司的QACenter。

    Winrunner 简介：

    WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。

    WinRunner的特点在于: 与传统的手工测试相比，它能快速、批量地完成功能点测试; 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差; 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成; 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用; 它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。

    WinRunner的工作流程大致可以分为以下六个步骤:

    1．识别应用程序的GUI

    在WinRunner中，我们可以使用GUI Spy来识别各种GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大区别是后者对每个测试脚本产生一个GUI文件，它能自动建立、存储、加载，推荐初学者选用这种模式。但是，这种模式不易于描述对象的改变，其效率比较低，因此对于一个有经验的测试人员来说前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。

    2．建立测试脚本

    在建立测试脚本时，一般先进行录制，然后在录制形成的脚本中手工加入需要的TSL（与C语言类似的测试脚本语言）。录制脚本有两种模式: Context Sensitive和Analog，选择依据主要在于是否对鼠标轨迹进行模拟，在需要回放时一般选用Analog。在录制过程中这两种模式可以通过F2键相互切换。

    只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

    3．对测试脚本除错(debug)

    在WinRunner中有专门一个Debug Toolbar用于测试脚本除错。可以使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各种变量值。

    4．在新版应用程序执行测试脚本

    当应用程序有新版本发布时，我们会对应用程序的各种功能包括新增功能进行测试，这时当然不可能再来重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工作。可以使用一个call命令来加载各测试脚本。还可在call命令中加各种TSL脚本来增加批量能力。

    5．分析测试结果

    分析测试结果在整个测试过程中最重要，通过分析可以发现应用程序的各种功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中我们能发现应用程序的功能性缺陷，能看到实际结果和期望结果之间的差异，以及在测试过程中产生的各类对话框等。

    6．回报缺陷（defect）

    在分析完测试报告后，按照测试流程要回报应用程序的各种缺陷，然后将这些缺陷发给指定人，以便进行修改和维护。

    三、性能测试工具

    　　专用于性能测试的工具包括有：Radview公司的WebLoad；Microsoft公司的　　WebStress等工具；针对数据库测试的TestBytes；对应用性能进行优化的EcoScope等工具。   Mercury Interactive的LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。

    Loadrunner 简介：

    Mercury LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

    目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。

     LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。

    轻松创建虚拟用户

    使用LoadRunner 的Virtual User Generator，您能很简便地创立起系统负载。该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程(如下订单或机票预定)，然后将其转化为测试脚本。利用虚拟用户，您可以在Windows ，UNIX 或Linux 机器上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的硬件和人力资源。另外，LoadRunner 的TurboLoad 专利技术能。

    提供很高的适应性。TurboLoad 使您可以产生每天几十万名在线用户和数以百万计的点击数的负载。

    用Virtual User Generator 建立测试脚本后，您可以对其进行参数化操作，这一操作能让您利用几套不同的实际发生数据来测试您的应用程序，从而反映出本系统的负载能力。以一个订单输入过程为例，参数化操作可将记录中的固定数据，如订单号和客户名称，由可变值来代替。在这些变量内随意输入可能的订单号和客户名，来匹配多个实际用户的操作行为。

    LoadRunner 通过它的Data Wizard 来自动实现其测试数据的参数化。Data Wizard 直接连于数据库服务器，从中您可以获取所需的数据（如定单号和用户名）并直接将其输入到测试脚本。这样避免了人工处理数据的需要，Data Wizard 为您节省了大量的时间。

        为了进一步确定您的Virtual user 能够模拟真实用户，您可利用LoadRunner 控制某些行为特性。例如，只需要点击一下鼠标，您就能轻易控制交易的数量，交易频率，用户的思考时间和连接速度等。

    创建真实的负载

    Virtual users 建立起后，您需要设定您的负载方案，业务流程组合和虚拟用户数量。用LoadRunner 的Controller，您能很快组织起多用户的测试方案。Controller 的Rendezvous 功能提供一个互动的环境，在其中您既能建立起持续且循环的负载，又能管理和驱动负载测试方案。

    而且，您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样，您就能将测试过程自动化。同样您还可以用Controller 来限定您的负载方案，在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序----来模拟峰值负载的情况。另外，您还能监测系统架构中各个组件的性能---- 包括服务器，数据库，网络设备等----来帮助客户决定系统的配置。

        LoadRunner 通过它的AutoLoad 技术，为您提供更多的测试灵活性。使用AutoLoad ，您可以根据目前的用户人数事先设定测试目标，优化测试流程。例如，您的目标可以是确定您的应用系统承受的每秒点击数或每秒的交易量。

    定位性能问题

        LoadRunner 内含集成的实时监测器，在负载测试过程的任何时候，您都可以观察到应用系统的运行性能。这些性能监测器为您实时显示交易性能数据（如响应时间）和其它系统组件包括application server, web server，网路设备和数据库等的实时性能。这样，您就可以在测试过程中从客户和服务器的双方面评估这些系统组件的运行性能，从而更快地发现问题。

        再者，利用LoadRunner 的ContentCheck TM ，您可以判断负载下的应用程序功能正常与否。ContentCheck 在Virtual users 运行时，检测应用程序的网络数据包内容，从中确定是否有错误内容传送出去。它的实时浏览器帮助您从终端用户角度观察程序性能状况。

    分析结果以精确定位问题所在

        一旦测试完毕后，LoadRunner 收集汇总所有的测试数据，并为您提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。使用LoadRunner 的Web 交易细节监测器，您可以了解到将所有的图象、框架和文本下载到每一网页上所需的时间。例如，这个交易细节分析机制能

        够分析是否因为一个大尺寸的图形文件或是第三方的数据组件造成应用系统运行速度减慢。另外，Web 交易细节监测器分解用于客户端、网络和服务器上端到端的反应时间，便于确认问题，定位查找真正出错的组件。例如，您可以将网络延时进行分解，以判断DNS 解析时间，连接服务器或SSL 认证所花费的时间。通过使用LoadRunner 的分析工具，您能很快地查找到出错的位置和原因并作出相应的调整。

    重复测试保证系统发布的高性能

        负载测试是一个重复过程。每次处理完一个出错情况，您都需要对您的应用程序在相同的方案下，再进行一次负载测试。以此检验您所做的修正是否改善了运行性能。

    Enterprise Java Beans的测试

        LoadRunner 完全支持EJB 的负载测试。这些基于Java 的组件运行在应用服务器上，提供广泛的应用服务。通过测试这些组件，您可以在应用程序开发的早期就确认并解决可能产生的问题。

        利用LoadRunner, 您可以很方便地了解系统的性能。它的Controller 允许您重复执行与出错修改前相同的测试方案。它的基于HTML 的报告为您提供一个比较性能结果所需的基准，以此衡量在一段时间内，有多大程度的改进并确保应用成功。由于这些报告是基于HTML 的文本，您可以将其公布于您公司的内部网上，便于随时查阅。

    最大化投资回报

       所有Mercury Interactive 的产品和服务都是集成设计的, 能完全相容地一起运作。由于它们具有相同的核心技术，来自于LoadRunner和ActiveTest TM 的测试脚本，在Mercury Interactive 的负载测试服务项目中，可以被重复用于性能监测。借助Mercury Interactive的监测功能－－Topaz TM 和ActiveWatch TM ，测试脚本可重复使用从而平衡投资收益。更重要的是，您能为测试的前期布署和生产系统的监测提供一个完整的应用性能管理解决方案。

    支持无线应用协议

        随着无线设备数量和种类的增多，您的测试计划需要同时满足传统的基于浏览器的用户和无线互联网设备，如手机和PDA。LoadRunner 支持2 项最广泛使用的协议：WAP和I-mode。此外，通过负载测试系统整体架构，LoadRunner 能让您只需要通过记录一次脚本，就可完全检测上述这些无线互联网系统。

    支持Media Stream应用

        LoadRunner 还能支持Media Stream应用。为了保证终端用户得到良好的操作体验和高质量Media Stream，您需要检测您的Media Stream应用程序。使用LoadRunner ，您可以记录和重放任何流行的多媒体数据流格式来诊断系统的性能问题，查找原由，分析数据的质量。

    完整的企业应用环境的支持。

        LoadRunner 支持广泛的协议，可以测试各种IT 基础架构。

     

    四、测试管理工具

    　　测试管理工具用于对测试进行管理。一般而言，测试管理工具对测试计划、测试用例、测试实施进行管理，并且，测试管理工具还包括对缺陷的跟踪管理。测试管理工具的代表有：Rational公司的Test Manager；Compureware公司的TrackRecord；Mercury Interactive公司的TestDirector等软件。

    TestDirector 简介：

    TestDirector，它是Mercury Interactive公司推出的基于WEB的测试管理工具，无论是通过Internet还是Intranet，你都可以以基于Web的方式来访问TestDirector。

        应用程序测试是非常复杂的，它需要开发和执行数以千计的测试用例。通常情况下，测试需要多样式的硬件平台、多重的配置（计算机，操作系统，浏览器）和多种的应用程序版本。管理整个测试过程中的各个部分是非常耗时和困难的。

        TestDirector能够让你系统地控制整个测试过程，并创建整个测试工作流的框架和基础，使整个测试管理过程变得更为简单和有组织。

        TestDirector能够帮助你维护一个测试工程数据库，并且能够覆盖你的应用程序功能性的各个方面。在你的工程中的每一个测试点都对应着一个指定的测试需求。To meet the various goals of a project, you organize the tests in your project into unique groups. TestDirector还为你提供了直观和有效的方式来计划和执行测试集、收集测试结果并分析数据。

        TestDirector还专门提供了一个完善的缺陷跟踪系统，它能够让你跟踪缺陷从产生到最终解决的全过程。TestDirector通过与你的邮件系统相关联，缺陷跟踪的相关信息就可以被整个应用开发组，QA , 客户支持，负责信息系统的人员所共享。

        TestDirector提供了与Mercury Interactive公司的（WinRunner, LoadRunner, QuickTest Professional, Astra QuickTest, QuickTest Professional for MySAP.com Windows Client, Astra LoadTest, XRunner, Visual APIand Visual API-XP）、第三方或者自主开发的测试工具、需求和配置管理工具、建模工具的整合功能。TestDirector能够与这些测试工具很好的无缝链接，为你提供的全套解决方案选择来进行全部自动化的应用测试。

        TestDirector会指导你进行需求定义、测试计划、测试执行和缺陷跟踪，即整个测试过程的各个阶段。通过整合所有的任务到应用程序测试中来确保你的客户收到更高质量的产品。

     

     

    五、白盒测试工具

    　　白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具。

    　　静态测试工具：直接对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。静态测试工具的代表有：Telelogic公司的Logiscope软件；PR公司的PRQA软件。

    　　动态测试工具：动态测试工具与静态测试工具不同，动态测试工具的一般采用"插桩"的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。动态测试工具的代表有：Compuware公司的DevPartner软件；Rational公司的Purify系列等。

    查看(555) 评论(0) 收藏 分享 管理

  • 测试用例设计白皮书－－判定表驱动分析方法（转）

    2008-11-27 10:34:41

    一.方法简介

    1.定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

    2.判定表的优点
            能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。
            在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

    3.“阅读指南”判定表

      

     


    		1
    		 2
    		 3
    		 4
    		 5
    		 6
    		 7
    		 8
    问题
    		 觉得疲倦？
    		 Y
    		 Y
    		 Y
    		 Y
    		 N
    		 N
    		 N
    		 N
    感兴趣吗？
    		 Y
    		 Y
    		 N
    		 N
    		 Y
    		 Y
    		 N
    		 N
    糊涂吗？
    		 Y
    		 N
    		 Y
    		 N
    		 Y
    		 N
    		 Y
    		 N
    建议
    		 重读



    		√


    继续




    		√

    跳下一章





    		√
    		 √
    休息
    		 √
    		 √
    		 √
    		 √




     

    4.判定表通常由四个部分组成如下图所示。

       

    1

            1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
            2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
            3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
            4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

    5.规则及规则合并
            1)规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
            2)化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。

    查看(526) 评论(0) 收藏 分享 管理

1003/5<12345>
Open Toolbar