好的测试应该具有以下的品质:

• 自动化
• 彻底性
• 可重复性
• 独立性
• 专业性

　　第一、自动化

　　自动化的含义：调用自动化和检查结果自动化

　　调用自动化，因为单元测试是一个重复的过程，经常需要进行，因此尽量做到在IDE中经行，通过点击一个按钮就可以实现测试。对于测试的条件（如数据库，网络连接，窗体等）都应该让他成为单元测试的一部分。

　　检查自动化，测试必须自己能够检查测试是通过了还是失败了。不需要认为看输出结果来判断。

　　第二、彻底性

　　好的单元测试是彻底的，它们测试了所有可能会出问题的情况。

　　两个极端的例子：1>对于行代码，每个分支和每个可能抛出的异常。2>仅仅测试了最有可能的地方如边界条件，残缺和畸形的数据等。

　　第三、可重复

　　每个测试都应该独立于其他所有的测试，而且还必须独立于周围的环境，目标是测试能够一次又一次的执行，产生同样的结果。

　　第四、独立性

　　测试应该具有较强的针对性，确保你一次只测试一样东西。这并不意味一次测试只能使用一个测试函数，而是说一次测试应该专注于产品中的一个测试函数，或者实现一个功能的一组测试函数。

　　独立性还意味着测试没有依赖于任何其他的测试，不希望当前测试依赖于前面的测试。

　　第五、专业性

　　测试代码必须使用和产品代码相同的专业水准来编写。也应该采用封装，降低耦合。测试代码也需要封装成类和函数。如果积累了相关的测试方法就可以封装成函数。

　　测试代码需要有侧重点，不是对代码的什么地方都测试，如类的简单属性就可以不测。

　　正常情况下，测试代码会和产品代码量相差不大。

　　最后对测试进行测试

　　对代码经行单元测试从而确信软件能够正常运行是目前最好的方案，但是如果编写的测试有bug，那往往为带来很大的麻烦。以下两件事可以帮助你确定测试代码是正确的。

• 修正bug的时候，同时改进测试。
• 通过引入bug来证明测试。

“圈外人”青睐软件测试

软件测试行业的巨大缺口吸引了众多求职者的目光，除了从业者外，“圈外人”对软件测试也表示了相当的认同度和满意度。这主要是由软件测试行业的特性决定的。首先，从目前市场需求来看，严重的供需失衡局面促使我国软件测试工程师基本上处于一个地位高、待遇高的“双高”地位；其次，质量是产品的灵魂，软件测试工作的重要作用，在软件产业中任何时候都是不可替代的，因而职业生涯更长久；再次，软件测试工作包含了技术及管理的各个方面，对年龄的要求也没有一定限制。因此，在竞争越来越激烈的IT职场中，软件测试工程师的工作相对来说更稳定、更有发展前景。

 

尽管期望加入软件测试行业者数量众多，然而能够达到企业需求的求职者数量寥寥。无论是有经验者还是无经验者，由于对软件测试缺乏系统的了解和足够的职业技能，均成为阻碍他们顺利进入的门槛。

软件测试工程师就业班

 

机构选择要仔细

推荐课程：新科海学校软件测试工程师就业班————9月7日开班

Web界面设计好之后，需要做详细的测试。下面我和大家分享自己在做Web界面测试的测试点以及应该注意的一些问题。

　　我们通过用户界面测试来核实用户与软件的交互来进行界面测试，必须明确UI测试的目的——确保用户界面向用户提供了适当的访问和浏览对象功能的操作，除此之外，UI测试还确保UI功能内部的对象符号预期的要求，并遵循公司和行业的标准。

　　接下来，我们具体的分析一下界面测试的依据从哪些方面着手。

　　测试目标：
　　1、窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法(tab键、鼠标移动和快捷键)的使用
　　2、窗口的对象和特征(例如、菜单、大小、位置、状态和中心)都符号标准

　　测试方法：
　　为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确的进行浏览，并处于正常的对象状态。

　　我们在实际工作当中，针对web应用程序，也就是经常所说的B/S系统，可以从如下方面来进行用户界面测试、

　　1、导航测试

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等;

　　不同的链接页面之间，通过考虑下列问题，可以决定一个web应用系统是否易于导航;导航是否直观？web系统的主要部分是否可通过主页存取？web系统是否需要站点地图、搜索引擎或其他的导航帮助

　　当然，这些同美工以及客户需求有关。我们是根据已经确认的页面进行测试即可。

　　2、图形测试

　　图形包括图片、动画、边框、颜色、字体、背景、按钮等。

　　(1) 要确保图形有明确的用途，图片或动画不要胡乱的堆在一起，以免浪费传输时间，web应用系统的图片尺寸要尽量地小，并且要能清楚的说明某件事情。一般都链接到某个具体的页面

　　(2)验证所有页面字体的风格是否一致

　　(3)背景颜色与字体颜色和背景色相搭配

　　(4)图片的大小和质量，一般采用jpg或gif压缩，最好能使用图片的大小减小到30k以下

　　(5)演示文字回绕是否正确，如果说明文字指向右边的图片，应该确保该图片出现在右边，不要因为使用图片而使窗口和段落排列古怪或者出现骨性。

　　3、内容测试

　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"

　　4、表格测试

　　需要验证表格是否设置正确，用户是否需要向右滚动页面才能看见产品的价格？

　　把价格放在左边，产品细节放在右边是否更有效？

　　每一栏的宽度是否足够宽，表格里的文字是否都有折行？

　　是否因为某一格的内容太多，而将整行的内容拉长？

　　5、整体界面测试

　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如、当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？

　　对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　对所有的用户界面测试来说，都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与，最好是最终用户的参与。

　　Web界面测试中需要注意的细节问题：

　　1、界面的线条是否一致，每个界面中线条是否对齐，是否一致。(静态页面没有确认的情况下)

　　2、整个系统的界面是否保持一致

　　3、界面中是否存在错别字

　　4、界面所有的按钮样式是否一致

　　5、每个界面是否同原静态页面设计一致(静态页面确认的情况下)

　　6、操作是否友好

　　7、界面所有的按钮、下拉框是否有响应

　　8、界面所有的链接是否正常

　　9、界面所有的输入框是否都进行校验(例如、搜索框、字段输入框)

　　10、界面所有的列表页标题字是否会折行，标题字是否统一居中等，当然也可以居左，这需要同客户沟通(折行的话影响美观)

　　11、界面所有的展示图片是否样式一致

　　12、浏览器的兼容性问题，检查页面在不同浏览器下是否会发生异常

　　13、每个页面的提示字体的颜色、格式是否统一准确

　　14、界面中所有字段后面是否都存在冒号，有冒号，查看是否冒号为统一的中文冒号还是英文冒号。

　　15、界面中的提示说明叙述是否太啰嗦，有时候需要能简化尽量简化，并且字体显示格式一致，颜色统一。

　　16、在web网站，一般经常是后台控制前台的显示，因此在对后台进行数据添加时，查看前台是否有变化，并且查看界面的数据是否溢出框外。

                                                                                                      来源：天极网

虽然Windows Mobile 6.5才刚刚推向市场，但是据一些摩托罗拉雇员意外泄露的资料显示，Windows Mobile 7已经开发了一年之久，并已经进入到Beta测试阶段。 　　Windows Mobile 7的最主要特色在于手写识别功能，而且将加入NVIDIA Tegra平台（APX 2500）的支持，该操作系统平台还将原生支持MEMS传感器，例如加速度传感器和方向传感器。 　　另外，Windows Mobile 7还将具备一种匿名缓存功能，但是运作机制现在还是未知。其他功能包括Windows Live ID可以被用于Exchange Mobile客户端，这意味着用户能够通过手机访问他们的Windows服务。而且所有的Windows Mobile 7手机都将具备WiFi功能，或至少操作系统具备原生WiFi硬件驱动。 　　其他功能包括，Windows Mobile 7还有视频共享用户界面、Live视频搜索功能、以及丰富的视频电话和会话控制功能。ActiveSync将会在新操作系统中集成。不过，纵使我们知道 Windows Mobile 7的众多新功能，这款系统也要等到2010年底才会公布。

　　UAT(user acceptance Test) 户接受度测试

以下是它的一些一般步骤；仅供参考

一步:用户培训手册准备（就是针对要进行UAT测试的对象，及要进行培训的用户，准备一些培训资料：一般是测试对象使用/功能手册及要培训的用户的个人资料等等：就跟教师上课进行备课差不多）

二步：测试脚本发放（如果你公司采用自动化测试，那么每一个功能或一个模块等都有对应的测试脚本，可以把这些测试脚本分发给特点的人员；如果采用手工测试，就要把详细描述一个功能或模块的文档分给相关人员（当然自动化测试也要分发））

三步：用户补充业务测试场景和测试数据（就是：请有代表性的一些最终用户根据实际应用环境及一些常用处理的数据，来给一些补充与建议，越贴近实际应用越好）

四步：顾问补充测试步骤（你可以请项目专家，测试经理，或专门的测试，开发等顾问对测试步骤进行补充）

五步：培训资料及测试脚本文档的确定与最终输出(一般到此，各种资料都基本确定，这时可以将它们进行打印，或形成特别的电子文档）

六步：测试策略的制定（如嵌入测试策略等，http://bbs.51testing.com/thread-3000-1-1.html）

七步：测试用户的确定（大体上从培训人员中选取，因为不能每个接受培训的人员都是资格去测试的，这里你可以通过一些考核来实现人员的筛选等等）

八步：由专门的测试组织机构确定测试地点，并发出通知

九步：测试网络环境的搭建和保障（包括网络，系统，硬软件，包括一些case工具等

十步：组织进行测试

十一步：评审分析提交的问题（这就进入了一般bug处理过程，形成了一个循环）

UAT测试的重点,我想主要体现在以下几个方面

一是：培训的资料表述要准确全面，易懂等（这是理论基础）

二是：人员选择，要典型有代表性（用户基础）

三是：测试流程步骤（要周密）

四是：测试策略制定（确定一个适合测试对象及测试人员的测试策略）

五是：问题的表达与处理(因为测试者不是专业开发测试人员，对于问题的表达可能不能到位，或根本就不是那种问题，这就存在如何复现与转化问题等）

　　在信息技术日新月异的今天，顺应世界经济一体化的潮流，中国软件行业加强了与世界同行的沟通与交流，基于本身提高软件质量的迫切需要，在国外优秀的软件企业中被证明为提高软件质量行之有效的途径，软件测试开始越来

越受国内软件行业重视。各种各样的测试工具和测试理论，也都逐渐被我们所熟知。软件测试也开始成为人们平时谈论和网上探讨的热点话题。

在软件测试倍受注目的情况下，身为一名软件测试人员，如何高质量的完成公司交给的测试任务，无疑是我们应该考虑首要问题。从事软件测试已近两年，从刚开始的一脸茫然，到如今的手到擒来，期间也经历了很多曲折，总结这两年来的经念教训，我认为有必要就软件性能测试这个话题和大家展开探讨，与大家共同分享软件测试的得失，为提高我们的测试水平尽一分薄力。

引言

作为评价产品性能的重要手段，性能测试在软件测试工作中占的比重一直很大，要最终提供一份准确，权威的测试报告，测试人员的努力工作自然不可或缺，但更重要的是测试人员清晰的工作思路，简洁的测试流程和良好的测 试方法。

目前性能测试存在的问题

总结以往进行的性能测试，虽然测试人员自始至终对测试工作都做到了认真负责，但测试报告出炉后，大家总觉得美中不足，对测试结果都心存疑虑，尤其在那些时间跨度较长、针对不同的测试对象的性能对比测试中，或多或少

都存在以下几个方面的问题：

1. 测试准备不充分，测试目标不明确，测试计划不详细；

2. 缺乏测试以及针对测试对象的技术储备；

3. 测试环境的稳定性及前后一致性不足；

4. 测试数据精确性和代表性不足；

5. 测试描述不精练；

下面，我们就剖析以上问题的同时，探讨一下如何解决这些问题。

性能测试准备

这是一个经常被测试人员忽略的环节，在接到测压任务后，基于种种其它因素的考虑，测试人员往往急于进度，立即投入到具体的测试工作去了，测试、记录、分析，忙的不亦乐乎，工作进行了一半才发现，或是硬件配置不符 合要求，或是网络环境不理想，甚至软件版本不对，一时弄得骑虎难下，这都是没有做好测试准备惹的祸。

那么我们应该如何做好性能测试的准备工作呢？

做软件项目有需求调查、需要分析，我们做测试也一样。在拿到测试任务后，我们首要的任务就是分析测试任务，在开始测试前，我们至少要弄清以下几个问题：

a) 要测试什么或测试的对象是谁？

b) 要测试什么问题或我们想要弄清楚或是论证的问题？

c) 哪些因素会影响测试结果？

d) 需要怎样的测试环境？

e) 应该怎样测试？

只有在认真调查测试需求和仔细分析测试任务后，才有可能弄清以上一系例的问题，只有对测试任务非常清楚，测试目标极其明确的前提下，我们才可能制定出切实可行的测试计划。

明确测试目标，详尽测试计划

在对测试需求充分了解的基础上，制定尽可能详细的测试计划，对测试的实施是大有裨益的。测试计划的制定，大多专业的测试书籍多有详述，故本文不再鏊述。

测试技术准备

在目前的大环境下，要求测试人员在短时间撑握所有的软、硬件知识是不太现实的，但平时测试人员应抓紧对测试工具和测试理论的研究，在测试计划中，应给研究测试对象和测试工具分配充足的学习时间，只有在充分撑握测试工具，完全了解测试对象的前提下，我们才能够实施测试。建力在错误的认识上的测试，既使你再努力，结果也是背道而驰，也很难证明问题，更不用说用这样的测试报告去说服用户。

配置测试环境

只有在充分认识测试测试对象的基础上，我们才知道每一种测试对象，需要什么样的配置，才有可能配置一种相对公平、合理的测试环境（这在性能对比测压中尤其重要）。

考虑到其它因素，如网络锁、网速、显示分辩率，数据库权限、容量等对测试结果的影响。如条件允许，我们最好能配置几组不同的测试环境。

测试数据的获取和处理

在所有的测试中，测试数据的收集工作都是较为困难的，Gis软件更是如此，每一种软件都有它的文件格式，有的软件还有几种格式。在这种情况下，我们只能把第三方格式的数据转换成每一种被测试软件自已的格式。同时，还应对数据作一定的处理，如处理数据冗余，处理显示风格等。如在测试时会更新数据，操作前一定要备份数据。

其外，还应评估数据格式和数据量对测试的影响，如有必要，应准备多组数据。

最后，一定要检查测试数据的有效性，避免损坏数据对测试结果的影响。

如何开展性能测试

测试前期的准备工作纷繁复杂，做好测试准备工作，已是完成了测试工作的一大半，但要产生一份具有说服力的测试报告，还应正确把握测试的强度，保持测试的一致性，提高测试的精度。

判断软件的好坏，要看软件解决实际应用的能力，只有在一定的测试强度下，才能测试出各种软件资源的消耗率，软件运行的速度，软件的稳定性。通过对比在不同的测试强度下，不同软件每一个功能模块解决实际问题的能力和软件运行的效率，我们才可能判断出不同软件的每一个模块的强弱，甚至于整个软件的优劣。

性能测试开始后，所有参数的输入都应遵循统一的标准，无论是哪一个环节，哪怕是一点点偏差，都应立即纠正，觉不能心存侥幸。要特别注意外部环境对测试结果的影响，如果在整个测试过程中，外部境不一致，如网速、机器内存使用率不一样，就有可能导制测试结果与实际情况有出入。

如何总结性能测试

对测试的终结，实际就是对测试数据的分析和处理。我们测试工作做的再好，如最终到用户手中的是一堆杂乱无章的数据，那也是美中不足。

首先，我们最好从所有的测试数据中，筛选出具有代表意义的数据，做出统计图，然后和开发人员一起，认真分析数据，找出软件存在的问题，得出测试结论。大多数用户，真正需要的就是科学、客观的测试结论。

结论

各种软件性能测试，范围大小不同，强度高底有别，但只要本着认真、客观，科学的工作态度，遵循本文论述的方法，做好测试工作是不难的。

本篇文章主要谈的是软件性能测试方面的问题，相信对其它方面的软件测试也有一定的借鉴作用。

按照产出的文档，介绍项目开发过程中的工作步骤

　　1. 测试计划：这个计划，我个人觉得应该在详细设计确定后，代码开始编写的时候进行制定，因为我是提早开始测试工作思路的忠实fans，虽然现在项目里都只有我一个人在这么早开始工作……

　　测试计划，主要是给后面的测试工作一些指南，不能写成领导看的计划，而是要写成由做事的人看的计划

　　包含的内容可能有：

　　i. 测试团队人员及分工(要确定当测试时出现缺陷界定、测试环境准备等问题时能找到指定的人员)

　　ii. 测试开始结束时间(理想情况下，不要安排的太紧，赶工肯定会造成延期或测试不完整，可惜理想和现实的差距被规定为很大)

　　iii. 测试环境配置(什么样的硬件条件，是否网络、设备等，系统在什么地址访问，访问权限、使用的测试数据等方面的预计和准备)

　　iv. 测试哪些东西要说清楚，这里我建议把简单的测试大纲纳入测试计划中，一方面领导可以看到你的计划写的多详细，另一方面大纲可以很好的成为编写用例的依据

　 　v. 怎么测试要说明白，如只做系统测试，那就要写清楚不做集成测试，如果需要集成测试，就需要写明白集成顺序。另外如果需要进行性能、文档、等其他的测试也要 在这个计划中写明，虽然一般这个计划都是针对功能测试，但是如果有其他测试，也要写出来并安排时间，相应测试的相关计划等也需要指明

　　vi. 测试结束标志(要说明测试达到什么程度可以结束测试，不能等到把所有缺陷都找出来以后才结束，因为那将是一万年)，允许缺陷存留在系统里，我们只需要找到留多少这个度就够了

　 　2. 测试用例：这个文档，主要描述具体的测试步骤，但实际应用中，至少目前我的项目里，由于时间的原因，很少有写的，就算写了的，也基本没有用到测试里，在这边的很多项目大都是直接来测，全凭我个人的经验来检查。但是我想说其实他很重要，也许你不需要写的很详细，但是绝对需要通过这样的步骤来理顺思路，这个文档的好坏和实用程度，直接可以决定你是否能用最少的工作(量和时间)，尽早的发现尽可能多的缺陷， 写这个文档需要用到一些测试方法理论，如等价类划分、边界值、这个表那个表。

　　3. 缺陷记录：是功能测试过程中使用频率最高的文档，用于在测试过程中记录发现的缺陷，并由开发人员作为修改缺陷的依据，以及修改后测试人员进行回测的主要依据

　　a) 该文当也有助于分析开发人员存在的错误集群现象，总结易出错的地方，对缺陷多的部分做更深入的测试，并提醒开发人员避免缺陷

　　b) 缺陷记录填写指南：

　　i. 缺陷级别(即严重程度)，一般由公司统一定义，为发现的缺陷进行分类，以便决定修改的缓急

　　ii. bug分类：区分发生的位置，是功能的，还是性能的，是有效性问题 还是其他问题等，与bug级别一起，用于决定bug的修改要求度|

　　iii. bug状态：是标志bug的当前情况，标识是否被处置(关闭状态)，

　　iv. 上述这些指标一般由公司统一定义(一般标准都大同小异)，也会用于项目的度量

　　c) 缺陷记录使用时的注意点：

　　i. 描述bug要有三要素：在哪里，什么情况(前提)下，发生了什么样的问题

　　ii. 可以借助截图、引用位置、模块等方式来描述bug，目的是让开发人员能够通过您的描述立刻马上能够重现bug，即使不能重现，也能让开发人员了解到错误的所在

　　iii. 缺陷报告要由开发人员和测试人员共同完成，测试人员要督促开发人员填写该表以便测试后续的回测工作

　　iv. 如果是在执行用例的同时填写bug报告，用例的最后一列一般可以填写用例的执行结果，如果用例发生了非期望的结果，那么就要把问题记录在缺陷记录中，此时可以在缺陷记录中引用该用例的编号

　　4. 测试总结报告：用于报告和总结项目测试工作的执行结果，列举和统计相关测试数据，对比分析数据即工作中存在的问题为后续工作做出提示，并记录遗留的问题等

　　a) 总结报告的还有一个功能就是告诉项目组成员该系统已经按照测试计划的要求进行了测试，并已经达到测试计划中说明的测试结束条件，可以证明系统已经达到测试计划所期望的质量

　　这份测试总结需要记录项目所有测试的结果情况，除了功能测试外，性能测试也会被包含在内。