项目背景：

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

    很遗憾的是，这是一个二期项目，一期功能已早在我来公司之前就已完成，另外，项目就是用于统计病房、护士、病人人数信息以及进行相应的分析的医院系统，真的很小。以致于我一天之类就熟悉了一期及二期的需求，弄清楚一些问题后，就开始准备测试数据了。其实二期功能也不多，就只是增加了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，后来在开发人员的帮助下，才知道症结在于分页功能上。我这里的测试数据不足以分页，所以无法重现。提醒自己，以后做测试时，应尽量考虑全面，不要因为测试数据的原因而漏测。

总结：

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

项目背景：

    此项目的客户是一个英国的软件公司，他们主要做设备管理系统、地产管理系统等，这一次是为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.  项目管理上，强硬也许比疲软更有效。即使强硬会让项目成员一时难受，但最终会另整个项目组受益的。

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

　　

 

 

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.

	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]
	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.
	Subject: "Follow-up about Meeting"
	Fractionally better -- provided that the recipient recognizes your name and remembers why a follow-up was necessary.
	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.  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.  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.

 

RTM版是最终压盘版，Release To Manufacturing，也就是交付给光盘制作厂商，这和最终发布版一样。发布RTM后，厂商若要修改就只有通过发布SP来完成了。

RC版是发布候选版，Release Candidate，一般是RTM版本前的几个预览版，但是这个阶段来说基本功能已经完成，主要是用来捉bug了，所以发布RC后，基本功能不会有大的变化了，只要各种测试能够通过，这也表明最终发布不远了。

CTP是社群技术预览版，Community Technology Preview，这个版本只是用来在社区内发布，验证市场情况和用户认可度，早于RC版，就像Atlas，在发布了多个CTP后，突然剑峰一转，变为了ASP.NET AJAX，让前期投入大量精力在Atlas上，如dflying chen他们就相当郁闷，所以说CTP版本不一定可靠，可能在功能上都会有大的变化。 

　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可

　　第四步：执行测试

10. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

　　是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。

性能测试类型包括负载测试，强度测试，容量测试等

　　负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

　　强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况

　　容量测试：确定系统可处理同时在线的最大用户数  

　　在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

　　Web服务器指标指标：

　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

　　* Successful Rounds：成功的请求；

　　* Failed Rounds ：失败的请求；

　　* Successful Hits ：成功的点击次数；

　　* Failed Hits ：失败的点击次数；

　　* Hits Per Second ：每秒点击次数；

　　* Successful Hits Per Second ：每秒成功的点击次数；

　　* Failed Hits Per Second ：每秒失败的点击次数；

　　* Attempted Connections ：尝试链接数；　　

11. 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

12. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

13. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

14. 您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

15. 您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

16. 在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么？您是如何来对待这些事情的？

17. 在即将完成这次笔试前，您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

18.你对测试最大的兴趣在哪里？为什么？

　　最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了十一二点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1、2点我没有把握，其他点我都很有信心做好它。

　　刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。

　　不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。

　　我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。

　　第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

19. 你的测试职业发展是什么？

　　测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。

20. 你自认为测试的优势在哪里？

　　优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

21. 你以前工作时的测试流程是什么？

　　公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

22. 当开发人员说不是BUG时，你如何应付？

　　开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

23．你为什么想离开目前的职务？

　　因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。

24：你对我们公司了解有多少？

25：你找工作时，最重要的考虑因素为何？

　　工作的性质和内容是否能让我发挥所长，并不断成长。

26：为什么我们应该录取你？

　　您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

27：请谈谈你个人的最大特色。

　　我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

28.白箱测试和黑箱测试是什么?什么是回归测试?

29。单元测试、集成测试、系统测试的侧重点是什么？

30。设计用例的方法、依据有那些？

31。一个测试工程师应具备那些素质和技能？

32.集成测试通常都有那些策略？

33.你用过的测试工具的主要功能、性能及其他？

34.一个缺陷测试报告的组成

35.基于WEB信息管理系统测试时应考虑的因素有哪些？

36.软件测试项目从什么时候开始，？为什么？

37.需求测试注意事项有哪些？

38.简述一下缺陷的生命周期

39.测试分析测试用例注意（事项）？

 什么是重构

　　重构是在编写代码后在不更改代码的外部行为的前提下通过更改代码的内部结构来改进代码的过程。目的是提高其可理解性,降低其修改成本。

　　通俗的说法就是,程序的功能和结果没有任何的变化。重构只是对程序内部结构进行调整,让代码更加容易理解,然后更容易维护。

　　为什么要重构

　　至于为什么要重构，因本人才疏学浅，故特引用软件工程专家的一段话：

　　在不改变系统功能的情况下，改变系统的实现方式。为什么要这么做?投入精力不用来满足客户关心的需求，而是仅仅改变了软件的实现方式，这是否是在浪费客户的投资呢?

　　重构的重要性要从软件的生命周期说起。软件不同与普通的产品，他是一种智力产品，没有具体的物理形态。一个软件不可能发生物理损耗，界面上的按钮永远不会因为按动次数太多而发生接触不良。那么为什么一个软件制造出来以后，却不能永远使用下去呢?

　　对软件的生命造成威胁的因素只有一个：需求的变更。一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。

　　考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。

　　这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越 来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。

　　重构就能够最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。

　　通过重构可以达到以下的目标：

　　·持续偏纠和改进软件设计

　　重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。

　　·使代码更易为人所理解

　　Martin Flower在《重构》中有一句经典的话："任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。"对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢?

　　软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。

　　对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情!

帮助发现隐藏的代码缺陷

　　孔子说过：温故而知新。重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的"感冒"。当你也发生这样的情形时，通过重构代码可以加深对原设计的 理解，发现其中的问题和隐患，构建出更好的代码。

　　·从长远来看，有助于提高编程效率

　　当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。

　　改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。

何时使用重构

　　新官上任三把火，开始一个全新的项目时，程序员往往也会燃起三把火：紧锣密鼓、脚不停蹄、加班加点，一支声势浩大的千军万"码"夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指"黄龙府"。

　　开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐恒公站在山顶上看到管仲训练的 队伍整齐划一地前进时，他感叹说"我有这样一支军队哪里还怕没有胜利呢?"。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大， 所以队伍变形在所难免。当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。

　　Kent Beck提出了"代码坏味道"的说法，和我们所提出的"队伍变形"是同样的意思，队伍变形的信号是什么呢?以下列述的代码症状就是"队伍变形"的强烈信号：

　　·代码中存在重复的代码

　　中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。重复建设只会导致效率的低效和资源的浪费。

　　程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。

　　过大的类和过长的方法

　　过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国， 诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方 法时，需要想办法将其划分为多个小方法，以便于分而治之。

　　牵一毛而需要动全身的修改

　　当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。

　　类之间需要过多的通讯

　　A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。

过度耦合的信息链

　　"计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题"，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。

　　各立山头干革命

　　如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队成员协调不够造成的。笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。

　　不完美的设计

　　在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报 警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系 统接收并响应这个请求。这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。

　　每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。

　　缺少必要的注释虽然许多软件工程的 书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释 往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生"提笔忘字，愈言且止"的情形。

　　曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。

配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。在实际测试中，软件环境又可分为主测试环境和辅测试环境。主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。一般来说，配置主测试环境可遵循下列原则：

　　1. 符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。

　　2. 选用比较普及的操作系统和软件平台。例如，一个软件若声称支持“Windows9X/ME/NT Workstation/2000 professional”和“MS Office 97/2000/XP”，一般我们会采用如“Windows 2000professional+MS Office 2000”的流行环境。

　　3. 营造相对简单、独立的测试环境。除了操作系统，测试机上只安装软件运行和测试必需的软件，以免不相关的软件影响测试实施。

　　4. 无毒的环境。利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。

　　辅测试环境常常用来满足不同的测试需求或特殊测试项目：

　　兼容性测试：在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。 　　

　　模拟真实环境测试：有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。

　　横向对比测试：利用辅测试环境“克隆”出完全一致的测试环境，从而保证各个被测软件平等对比。

 

背景:之前的公司测试过程中,总是由开发人员搭建好环境后,给个链接地址就进行测试了.这样的话测试人员总是处于被动的情况,并且也很不规范.

现状:期望有专门的测试服务器进行测试系统的搭建.

虚拟机在其中扮演的角色:

• 1 由于虚拟机文件是可以进行拷贝的,所以可在本人的机子上先进行环境的搭建,确认没问题后再拷贝文件到测试服务器
• 2 可在虚拟机中实现对每个系统的干净测试环境的搭建.每个虚拟机中都只装一个系统,这样系统的测试环境是很干净的.
• 3 基于测试环境是干净的前提下,若测试通过的系统,在项目经理或者公司销售人员进行外部系统演示时,均可拷贝这一虚拟机文件,就减少了重复搭建系统的情况.

最后: 若有磁盘空间,建议可进行基本操作系统环境的准备,这样在搭建新的测试环境时就可减少不必要的重复工作.

去搭建测试环境是软件测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境

一 确定测试环境的组成：

1．所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等；

2. 部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

3. 用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

4. 用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

5. 是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；

6. 测试中所需要使用的网络环境。例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈；

二、管理测试环境

1. 设置专门的测试环境管理员角色

每个测试项目或测试小组都应当配备一名专门的测试环境管理员，其职责包括：测试环境的搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写；记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；测试环境各项变更的执行及记录；测试环境的备份及恢复；操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理；

2. 记录好测试环境管理所需的各种文档：

测试环境的各台机器的硬件环境文档，测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因以及所形成的备份文件的文件名和获取方式；用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录

3. 测试环境访问权限的管理

为每个访问测试环境的测试人员和开发人员设置单独的用户名和密码。访问操作系统、数据库、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理；测试环境管理员拥有全部的权限，开发人员只有对被测应用的访问权限和查看系统日志（只读），测试组成员不授予删除权限，用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中

4. 测试环境的备份和恢复

测试环境必须是可恢复的，否则将导致原有的测试用例无法执行，或者发现的缺陷无法重现，最终使测试人员已经完成的工作失去价值。因此，应当在测试环境（特别是软件环境）发生重大变动时进行完整的备份，例如使用Ghost对硬盘或某个分区进行镜像备份。

虚拟服务器技术被用在试生产环境，目的是节省资金、时间和人力，然而同样的工具如果未经检查就可能会导致结构复杂，资源浪费并使管理难度加大。

　　行业分析师和IT专业人士说，虚拟化技术解除了物理服务器测试环境的限制，实现了IT员工间的资源共享，这就使得测试工作更容易进行，但却需要进行严格的控制。

　　Forrester调查公司的高级分析师Carey Schwaber说，“在测试环境中采用虚拟化技术的一个缺陷是影像数量的增多，特别是在通过不同操作系统测试多个结构时。环境的控制工作必须认真进行，必须有相关政策来避免环境的过度增长或成为无用的资源。”

　　避免测试服务器的蔓延

　　Bowdoin学院的系统工程师Tim Antonowicz说，虚拟化测试使其团队实现了不需要构建新的操作系统或采用其他软件集成开发商的工作站即实现了软件测试。他虚拟化测试环境中有55个运行中的虚拟机。

　　Antonowicz说，“沙箱是我们测试和评估各种软件的基本虚拟机。如果我们希望尝试一些新的东西，如运行一个测试版本或者仅仅是采用一个新的理念，我们就会采用一个沙箱虚拟机。”

　　用这样一种方式——作为进行测试的一种工具——来利用虚拟化是很平常的。但是大多数IT企业尚未将其在测试中的虚拟化应用在业内标准化。不同的IT组不再运行其虚拟化服务器(通常不能恰当的管理或淘汰)。业内观察家争论在测试实验室中应用虚拟化技术的益处。

　　IDC公司的首席分析师Melinda Ballou说，“在测试时，整合很重要，IT环境需要一个全面的管理方法以确保物理服务器和虚拟资源相协调。”

　　为了帮助IT经理管理其测试资源，虚拟化测试实验室管理软件供应商开始研发新工具。

　　例如Akimbi(Vmware公司收购)、CollabNet、VMLogix和Surgient都在过去的两年中针对采用虚拟服务器工具的企业发布了相关产品，目的是快速建立并拆卸测试环境。产品包括追踪虚拟机和捕捉存放在数据库以备未来使用的结构数据的自动功能。

　　比如，Akimbi公司的Slingshot产品，当前Vmware的Vmware，使得IT经理建立一个软件测试基础设施以自动建立并拆卸多虚拟机环境。Surgient公司的Virtual QA/Test Lab Management System管理系统通过整合测试基础设施加速了测试流程，同时使自动建立和拆卸复杂的测试结构得以实现。

　　当Mercy Healthcare的IT员工意识到为一个工作站更新而升级24000个桌面将消耗人力资源而且不一定能得到期望的结果时，他们转而采用Vmware和Surgient公司的产品。

　　“我们有一个桌面更新循环——包括将企业所有计算机升级到相通的操作系统和相同的锁定程序。客户机工程经理Brian Boresi说，“我们有多个需要提速的IT环境，针对24000台工作站开展这一工作至少会造成人力和时间的紧张，因为我们必须遵循快速配置流程表来进行。”

　　IT团队意识到，对于如此大量的桌面系统发布，虚拟化是唯一现实的选择，Boresi说他知道他们也需要协助管理测试实验室。他们没有采取让一个IT员工实地访问每个桌面用户以确定其应用软件需求的方法，Boresi说Surgient使IT团队可以在测试实验室中将创建多结构的流程自动化，同时基于用户工作站环境来改变结构。

　　Boresi说，“我们当前支持600个应用软件，更新时间很短，发布流程表很紧。除了自动测试和配置这些应用软件，我们没有其他办法。”

一些人说，虚拟化测试实验室管理工具不足以阻止IT环境。IT企业需要明确什么是可以被测试的，然后开展实践，同时在产品发布前确保所有在虚拟机上测试的软件可同样运行于物理机上。

　　Mercy Healthcare采用一个虚拟化环境来进行一到三步的测试，同时在实际使用前在物理服务器上进行测试运行。

　　Neubauer说，“在测试阶段，我们给产品工作站配置了一个应用软件包。用这一方法我们确保了软件可以满足所有需求，并不会在物理服务器上运行时造成阻碍，而按照预期运行。”

　　Cars.com芝加哥公司的技术运行主管Edward Christensen说，他避免在虚拟测试环境下载或实施测试。他说，“我们限制了我们的虚拟化技术应用范围，只将其用于功能性和整合测试。除非你的产品环境也是虚拟化的，否则不该在这一环境对其进行性能测试。”

　　其他专业人士赞同Edward Christensen的说法，认为不该在虚拟测试实验室内开展性能测试，例如应用软件下载和有效性测试。

　　Forrester的Schwaber说，“通过应用软件在假设负载为10,000用户情况下的运行状态，你不能说服可能用户数目远远超出这一负载时的运行情况。虚拟机的确和物理服务器共享了部分资源，无论是多少，这保证了那些类型的性能测试结果准确。”

　　Yankee Group的高级分析师Gary Chen说，他鼓励用户应用虚拟化来进行环境测试，因为如果他们这样做，工作就会简单化，并可以花费更少资金。但是他也警告IT专业人士不要掉入虚拟化承诺的陷阱。

　　Chen说，“没有人可以完全依靠一个虚拟环境来进行测试。物理测试是必须的。”

1. 测试环境重要性及意义

1、稳定、可控的测试环境，可使测试人员花费较少时间完成测试用例的执行；

2、 可保证每一个被提交的缺陷被准确的重现；

3、经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。

2. 测试环境搭建原则

测试环境搭建之前，需要明确以下问题：

1、所需计算机数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度等；

2、部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

3、用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

4、是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；

5、测试中所需要使用的网络环境；

6、执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议；

7、测试数据的备份与恢复是否需要；

8、模拟实际生产环境或用户环境搭建。

3. 测试环境管理

一、设置专门的测试环境管理员

每条业务线或测试小组应配备一名专门的测试环境管理员，其职责包括：

ü 测试环境搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册编写；

ü 记录组成测试环境的各台机器硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；

ü 完成被测应用的部署，并做好发布文档的编写；

ü 测试环境各项变更的执行及记录；

ü 测试环境的备份及恢复；

ü 操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理；

ü 当测试组内多名成员需要占用服务器并且相互之间存在冲突时（例如在执行性能测试时，在同一时刻应当只有一个场景在运行），负责对服务器时间进行分配和管理。

二、测试环境文档管理

需要维护如下文档是最新版本：

ü 组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况；

ü 组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置（CPU/内存/硬盘/网卡）、IP地址、具体用途以及历次的变更情况；

ü 被测软件或产品的发布手册，记录被测软件或产品的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。另外，还需要记录历次被测软件或产品的发布情况，对版本差异进行描述；

ü 测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因（与上次备份相比发生的变化）以及所形成的备份文件的文件名和获取方式；

ü 用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。

三、测试环境访问权限管理

按照如下要求维护测试环境权限：

ü 访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品等所需的各种用户名、密码、权限，由测试环境管理员统一管理；

ü 测试环境管理员拥有全部的权限；

ü 除对被测软件或产品的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。如的确有必要（例如查看系统日志），则只授予只读权限（user权限）；

ü 除测试环境管理员外，其他测试组成员不授予删除权限；

ü 用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。

四、测试环境变更管理

确保每次变更是可追溯和可控：

ü 测试环境的变更申请由测试人员提出邮件申请，由测试环境管理员负责执行。测试环境管理员不接受非正式的变更申请（例如口头申请）；

ü 对测试环境的任何变更，测试负责人均应记入相应的文档；

ü 每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理；

ü 对于被测软件或产品的发布，开发人员负责打包、测试人员核对发布包。

五、测试环境备份与恢复

1、确保测试环境程序版本、数据是可恢复；

2、对于功能或性能测试，测试数据需定期进行备份或从生产环境导入测试数据；

3、通过备份软件工具备份数据，同时保障备份数据可快速恢复。

4. 测试环境维护执行流程附件

1、测试机器申请流程

2、测试机器维护列表格式

3、测试环境部署文档维护列表格式

4、发布手册维护列表格

测试环境 是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。毫无疑问，稳定和可控的测试环境，可以使测试人员花费较少的时间就完成测试用例的执行，也无需为测试用例、测试过程的维护花费额外的时间，并且可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。

简单的说，经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。

 

一、规划测试环境——让环境为你服务

 

对于“金山词霸”这样的软件，大多数测试工作都可以在一台单独的电脑上完成，而对于一套电信系统，为了执行测试用例，你可能会需要搭建一个由多台计算机以及其他网络设备组成，采用集群和负载均衡技术，并且接驳到Internet的计算机网络。

不同的行业应用，不同的质量目标，都可能会影响到测试环境的规划。但从测试工作自身的要求来看，一条应当遵守的原则就是“尽可能的还原软件在用户那里最终实际运行的环境”——虽然在很多时候这是不现实的。^_^

通常来说，我们所需要搭建的环境，主要是用于被测应用的系统测试——单元测试和集成测试由开发人员在开发环境中进行，而验收测试则在用户的最终应用环境中进行，因此都可以暂不考虑。

为了确定测试环境的组成，我们需要明确以下问题：

1.         所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等；

2.         部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

3.         用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

4.         用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

5.         是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；

6.         测试中所需要使用的网络环境。例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈；

7.         执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议；

8.         为了执行测试用例，所需要初始化的各项数据，例如登陆被测应用所需的用户名和访问权限，或其他基础资料、业务资料；对于性能测试，还应当特别考虑执行测试场景前应当满足的历史数据量。当然，还有另外一个非常关键的问题：在测试过程中受到影响的数据如何恢复？

    明确了上面的问题后，明确哪些条件是可以满足的，哪些是需要其他部门协助调配、采购或者支援的。建议在搭建测试环境之前，把上面的问题做成一张CheckList，并为每一项指定一个责任人，完成一项就填写一项，最终形成的文档则作为测试环境的配置说明文档使用。当然，如果时间或其他条件允许，应当做好应急预案，尽量保证在环境失效时不会对正常工作产生太大的影响。

 

二、管理测试环境——把变化掌握在手中

 

    测试环境搭建好以后不太可能永远不发生变化，至少被测应用的每次版本发布都会对测试环境产生或多或少的影响。而应对变化之道，不是禁止变化，而是“把变化掌握在手中”。下面的这些建议可以帮助你尽可能摆脱环境变化所带来的不利影响。

1.         设置专门的测试环境管理员角色

每个测试项目或测试小组都应当配备一名专门的测试环境管理员，其职责包括：

ü         测试环境的搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写；

ü         记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；

ü         完成被测应用的部署，并做好发布文档的编写；

ü         测试环境各项变更的执行及记录；

ü         测试环境的备份及恢复；

ü         操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理；

ü         当测试组内多名成员需要占用服务器并且相互之间存在冲突时（例如在执行性能测试时，在同一时刻应当只有一个场景在运行），负责对服务器时间进行分配和管理。

2.         明确测试环境管理所需的各种文档

一般来说，下面的几个文档是必需的，当然你也可以根据需要增加新的文档。

ü         组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况；

ü         组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置（CPU/内存/硬盘/网卡）、IP地址、具体用途以及历次的变更情况；

ü         被测应用的发布手册，记录被测应用的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。另外，还需要记录历次被测应用的发布情况，对版本差异进行描述；

ü         测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因（与上次备份相比发生的变化）以及所形成的备份文件的文件名和获取方式；

ü         用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。

3.         测试环境访问权限的管理

    应当为每个访问测试环境的测试人员和开发人员设置单独的用户名，并根据不同的工作需要设置不同的访问权限，以避免误操作对测试环境产生不利的影响。下面的要求可以作为建立“测试环境访问权限管理规范”的基础。

ü         访问操作系统、数据库、中间件、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理；

ü         测试环境管理员拥有全部的权限；

ü         除对被测应用的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。如的确有必要（例如查看系统日志），则只授予只读权限；

ü         除测试环境管理员外，其他测试组成员不授予删除权限；

ü         用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。

4.         测试环境的变更管理

    对测试环境的变更应当形成一个标准的流程，并保证每次变更都是可追溯的和可控的。下面的几项要点并不是一个完整的流程，但是可以帮助你实现这个目标。

ü         测试环境的变更申请由开发人员或测试人员提出书面申请，由测试环境管理员负责执行。测试环境管理员不应接受非正式的变更申请（例如口头申请）；

ü         对测试环境的任何变更均应记入相应的文档；

ü         同每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理；

ü         对于被测应用的发布，开发人员应将整个系统（包括数据库、应用层、客户端等）打包为可直接发布的格式，由测试环境管理员负责实施。测试环境管理员不接受不完整的版本发布申请；

ü         对测试环境做出的变更，应该可以通过一个明确的方法返回到之前的状态。

5.         测试环境的备份和恢复

对于测试人员来说，测试环境必须是可恢复的，否则将导致原有的测试用例无法执行，或者发现的缺陷无法重现，最终使测试人员已经完成的工作失去价值。因此，应当在测试环境（特别是软件环境）发生重大变动（例如安装操作系统、中间件或数据库，为操作系统、中间件或数据库打补丁等对系统产生重大影响并难以通过卸载恢复）时进行完整的备份，例如使用Ghost对硬盘或某个分区进行镜像备份。并由测试环境管理员在相应的“备份记录”文档中记录每次备份的时间、备份人以及备份原因（与上次备份相比发生的变化），以便于在需要时将系统重新恢复到安全可用的状态。

另外，每次发布新的被测应用版本时，应当做好当前版本的数据库备份。而在执行测试用例或性能测试场景之前，也应当做好数据备份或准备数据恢复方案，例如通过运行SQL脚本来将数据恢复到测试执行之前的状态，以便于重复的使用原有的数据，减少因数据准备和维护而占用的工作量，并保证测试用例的有效性和缺陷记录的可重现。

在运行脚本回放过程中，有时会出现错误，这在实际测试中是不可避免的，毕竟自动录制生成的脚本难免会有问题，需要运行脚本进行验证，把问题都解决后才加入到场景中进行负载测试。下面结合常用的协议（如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”安装上即可。

 

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

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

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

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

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

 容错性测试包括两个方面的测试：

1. 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
2. 灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能很快恢复。

关于自动恢复测试的概念可以看出，容错测试是一种对抗性的测试过程。当测试软件出现故障时，如何进行故障的转移与恢复有用的数据。故障转移（failover）是确保测试对象在出现故障时，能成功地将运行的系统或系统某一关键部分转移到其他设备上继续运行，即备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务，不影响用户的使用。要进行故障转移的全面测试，一个好的方法是将测试系统全部的对象用一张系统结构图描绘出来，以图中所有可能发生的故障点设计测试用例。在系统结构图中存在单点失效的关键对象，就是设计的缺陷。