就像任何其他软件开发生命周期，测试也需要一些重要因素发展和维护来持续改进过程。其中一个因素就是建设团队。同时建立一个好的团队，应注重以下关键元素
角色和责任
对应团队成员来说这是非常重要的，可以是他们明白他们需要做些什么。这些通常不需要在团队里进行交流和讨论。在一个项目开始之前，团队成员会被告知他在 自己专属的任务中要扮演怎样的角色。无论是测试人员还是测试领导，设定期望和解释什么是期望，即在没有不必要的延迟和错误下，他们给出正确的结果。
几个在团队里需要被澄清的观点
项目的范围 每个人期望得到的角色和责任 重点关注可交付成果，时间点等
关于策略和计划的说明
最重要的是，团队成员的主要责任要记住他们的职业理想、成长、学习等，这些将是关键的激励因素，来执行自己当前的角色并且做到杰出。
知识转移
掌握领域知识对应测试人员来说是非常重要，就像和对应用程序的功能进行彻底的AUT测试一样。KT会话是非常必要的，可以帮助他们理解核心功能和逻辑，它将用于在测试过程中。头脑风暴会议来分享关于至关重要的应用程序和领域的共同理解。
项目初始讨论应该包含测试人员，但是它基本上由业务人员、架构师、开发人员、数据库专家等组成。在其中包含测试人员，可以在这些早期的软件开发提供良好的知识和对应用程序的理解，更利于以后的开发和测试。
领域知识
理解应用程序的领域（如医疗、保险等。）是非常重要的，将有利于测试人员来验证功能与一个不同的角度来看， 模拟最终使用客户就像行业专家一样。这需要时间，只有在此期间的工作在一个特定的领域，资源将能够熟悉的领域工作。有时，一个测试人员将有机会测试属于相同的领域的不同的应用程序，所以测试变得更加有意义， 如果他对整个领域的知识有足够的了解。
技术和领域认证
拥有一个有才华的测试人员对应一个项目来说绝对是一笔巨大的财富。重点应该是培训团队， 让他们在各自的区域得到内部认证。还有许多外部认证，也可以选择让团队参加。 认证肯定会给一个团队精神上的支持，和增强执行测试成熟度与信心。领域认证资源也将利用获取的知识，会对潜在客户用于新的业务机进行展示。
职业规划
创建一个团队，让测试人员学习到所有技能是不足够的，而提供机会，让他们了解他们的职业规划也很重要。创建或提名程序来塑造他们符合他们的下一个级别的 角色，显然他们在需要时会履行对资源的识别。团队会议可以有效地利用强调在他们的下一个级别的角色和职责。教育他们需要执行的各种技能在他们的下一个角色 是一个很好的优势，也是一个连续的流程改进。当他们希望升职时，每个经理有责任解释关于责任。这将确保不只是特定的一些人会被提拔，而是一些全心工作负责 和熟练的人也会被提拔。
团队激励和集体郊游
确保一个团队激励的制定是有很明显作 用的，其后的是团队进行有效的组织工作，达到共同的目标，完成苛刻的目标和按时达到目的。让他们明白，“项目”是共同的目标对于所有的项目和完成客户要的 内容是“优先”的。要做到这一点，每个人都应该一起作为一个“团队”离开所有差异背后，完成计划的任务是唯一的“目标”。在每周的团队会议，团队成员应该 接收信息的任务，重点为下一个阶段， 要清晰而响亮的共同的了解要执行的工作。 团队建设练习和郊游真的很有必要，在一个完全不同的环境，可以消除压力和自我恢复，这也将帮助更好地理解项目以外的工作。小小的感谢认可可以被宣布在团队 会议中，用来肯定能力，用来鼓励团队人员和激励其他人。
原文出处：http://www.softwaretestinghelp.com/team-building-in-software-testing/
写这篇文章我希望所有的测试人员都能阅读这些软件测试良好的实用内容，仔细阅读所有条目并尝试将他们运用到每天的测试工作中。如果不能理解某个条目，可以到我们论坛里留言询问更多的解释。当然你也可以通过亲身经历学习到所有这些测试的实用内容，但为什么不在犯错之前就来学习这些呢？ 以下就是我在经历中学到的最好的一些测试实用技巧：
1）学会彻底的分析测试结果。不要忽视了测试结果，最终的测试结果或许是“pass”或“fail”，但诊断导致“fail”的原因会引导你发现这个问题的解决方案。一个不仅仅记录了bugs而且提供了解决方案的测试人员是难能可贵的。
2）学会在每次测试任何应用时将测试覆盖最大化。虽然100%的覆盖或许是不可能的但你应该试着去接近它。
3）为保证最大化的测试覆盖需要将应用分割成更小的功能模块。在这样的单元模块上编写用例，如果可能的话讲这些模块分割成更小的部分。 举个例子：我们假设你将你的网站应用分割成了许多模块，“接收用户信息”是其中之一。你可以将用户信息填写页面分割成更小的部分来编写测试用例：比如叫界面测试、安全测试、用户表单的功能测试等等。在输入框里测试所有的字符类型、字符长度、无效性测试和有效性测试。写出所有这样的测试用例以增大测试覆盖率。
4）当写用例的时候，首先要考虑怎么实现目标功能也就是寻找需求上的有效条件，然后再为无效条件编写用例。这样就能覆盖在应用测试过程中出现的常规和非常规操作。
5）积极思考。要抱着找缺陷的目的去测试，不能一开始就想着应用中没有任何问题。如果你测试的目的就是在找缺陷你就会很自然的发现一些微妙的缺陷。
6）在需求分析和设计阶段编写用例，这样你就能保证所有的需求都是可以进行测试的。
7）让开发在编码之前就能看到你的用例。不要想着等程序发布时测试可以去提报很多缺陷而让你的用例一直在你自己手里。要让开发完整的分析你的用例去开发有质量的程序。这样就能节省返工的时间。
8）如果可能话要明确和组织你用来做回归测试的用例，这会保障手工回归测试能够快速有效的进行。
9）对临界应答时间有要求的应用需要对其进行完全地性能测试。性能测试是许多应用测试的重要组成部分。由于缺乏测试所需的大量数据，性能测试在人工测试中多半会被测试人员忽略掉，所以需要找到测试应用性能方法。如果不能手工添加测试数据，最好写一些基本的脚本来添加性能测试所需的数据，或让开发人员帮你写出来。
10）程序员不应测试他们自己的代码。像我们之前讨论过的，开发人员应该对应用做了充分的基本的单元测试后才能给测试人员发布应用新版本。测试人员不能为了进行测试去催促开发人员快点发布新版。要让他们支配好自己的时间。从领导到项目经理都会知道模块什么时候发布以及能够预估处相应的测试时间。这是敏捷项目的一个典型情形。
11）进行超出需求范围的测试。对应用进行超出需求要求的测试。
12）做回归测试时要运用之前的缺陷概览图（缺陷概览图---不同模块缺陷发现数目与时间的关系图）。这种明了的图表可以很好的预测应用哪些部分最容易出问题。
13）记录下测试过程遇到的术语和概念。在测试应用时也一直开着一个文档，在里面记录测试进度和测试状况。在准备最后的测试报告时就可以利用文档里记录的这些内容。这个好习惯会能帮助你提供完整明了的测试报告和应用发布细节。
14）测试人员或开发人员会对应用代码进行多次修改来适应测试。这是开发或测试过程中必要的一步来避免事务有效执行，比如在银行项目中。要记录下来为适应测试而修改了代码的地方，并且在最终发布的时候确保已经将这些修改的地方从最终客户端的源文件里都改正了。
15）让开发人员远离测试环境。这是在发布或部署文件中检查配置修改是否遗漏的必要步骤。有时开发人员做了一些系统或应用的配置修改，但是却忘了部署。如果开发人员没有权限访问测试环境，他们就不会不小心修改了测试环境，而且那些遗漏的地方可以在相应的地方找到。
16）让测试人员在软件需求分析和设计阶段参与进来是很有用的。这样测试人员可以对软件有可靠的认识来保障较好的测试覆盖率。如果没有让你参与这个研发周期，你要请求你的领导或经理允许你的测试团队参与所有的决策议程。
17）测试团队应该与其他团队及他们所在组织机构分享最佳测试实践、经验。
18）增加与开发人员的交流来知道更多关于产品的知识。只要有可能就进行面对面沟通来迅速解决问题和避免误解。并且把你对需求的理解或解决了某些问题，确保同样也通过书面形式如电子邮件进行沟通。不要任何事都靠语言交流。
19）不要把时间全放在高优先级的任务上。分析所有任务相关的风险，把你的测试任务按优先级先后排好然后做出相应的计划。
20）编写清晰、描述性强、明了的缺陷报告。不要只提供缺陷现象，也要提供缺陷带来的影响以及所有可能的解决方法。
不要忘了测试是一份有创造性和挑战性的工作。它最终取决于你的技能和经验，你会如何应对这个挑战。
希望大家做的： 分享你自己的测试经验、技巧或测试秘诀，这样肯定能让本文更加有趣、实用。
原文出处：http://www.softwaretestinghelp.com/practical-software-testing-tips-to-test-any-application/
序言：一般而言，刚开始
自动化测试时， 很多时候，很多人都不知道如何入手或者还有一部分人都信心满满，决心要建设出一份大的平台，可是事实在于自动化测试面临的问题一在于技术，二在于环境形 势。每个公司有不同的需求、有不同的环境、不同的人员支持，所以做自动化测试所需要涉及的外界因素太多，就如黑天鹅效应中的说法，你所自认为的白天鹅中也 许就隐藏着一只黑天鹅，它的出现会导致你的整体计划崩盘。所以，做自动化测试也一样，所依赖的东西太多，就能引起的整体变化太多，所以我觉得我们的基本策 略就是：不断预测、不断总结，然后是拥抱变化
总结的从开始到一定阶段的建设自动化测试的策略如下（麻烦有不同想法或者别的策略的朋友帮忙补充）：
1、分析需求并且细化需求，自动化测试是急不来的事情，不能指望用他来解决所有问题，所以必须明确需求，将需求一步一步写下来，然后从简单到容易开始击破。
2、评估资源，围绕人力支持、部门测试流程情况以及产品业务来决定自动化测试要先从哪一步开始走，并哪一步为阶段。自动化测试必须最终与整体的测试流程相结合，才能发挥作用，否则只会越走越远。
3、从最小的需求开始入手，也许是一个工具或者是一个线性脚本。总之，先解决一点需求，然后从点到面。获得一个面后，将其授权，然后再做点，这样一步一步进行铺张，其实说白了，也是一个自动化测试信心和价值建立的问题。
4、记：简单。要将一个东西发扬出去，那么它必须简单，技术人员的思维有时候总是把东西做的很复杂，因为有时候会觉得很炫，但需要做好一个东西得到发扬 的话，则需要将一个复杂的东西让人看起来很简单。一个工具或者一个框架，最好只有一个修改入口和一些API拓展机制。让测试人员用起来和拓展起来都很简 单。
5、CBB：CBB在软件开发中俗称“软件模块共享”。而在自动化测试中也是一样，要建立自己的开发库，不仅提供给以后的测试开发使用，更是给测试人员使用，能够在其基础进行很快速的共享和拓展。
6、覆盖率分析：单纯的用例自动化很难突显自动化测试后，其到底覆盖了多少点，通过了哪些点，一个用例的拓展也不是很好拓展。因此需要划分为点的方式， 即可以每个脚本对应一个测试点，每次测试，可以统计覆盖了多少个点，通过率如何，即产用产品—模块—测试点统计覆盖率的方法。
7、 ROI分析：在自动化测试一定阶段后，做好自动化测试ROI分析，绝对不打没有目标性的仗，我们到底为了什么做自动化测试，很多人会说是为了保证质量，首 先，大家都明白，自动化测试不是用来发现问题的，这个说法没有错，但是问题在于，好不容易做起来的自动化测试，结果没有好的ROI分析机制，乱做了一通， 该做的测试用例没有自动化，不该做的做了一堆，结果导致自动化测试的开发和维护成本很高，收效成本很少，所以，到中期阶段，需要有一个ROI分析机制帮助评估自动化测试脚本的建设。
8、成熟度模型：现在业界有一些人已经提出了自己的自动化测试阶段，这些阶段在一定基础上是值得参考的，但是上面也说了，每个公司、每个部门的情况和需 求是不一样的，其依赖的因素很多，所以在自动化测试发展过程中，可以从一个试点产品或者一个项目中不断分析抽象，建立一套自己的成熟度模型，然后进行推 广。在每个阶段评估不同项目、不同产品的自动化测试成熟度。
总结：做自动化测试不是一件容易的事情，但也不是一件值得怀疑的事情，它有它的价值，正所谓存在即合理，也许我们做的是要找到正视它的价值，不浮夸它，也不贬低它，踏踏实实做它应该带来的效果。
版权声明：本文出自 散步的SUN 的51Testing软件测试博客：http://www.51testing.com/?382641
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
常被人问到各种探索测试的问题， 我总是不断在重复。因此借一次回答10个问题的机会，把自己的答复都固化下来， 积累在自己的技术博客中， 希望能减少重复回答的次数。
1、探索性测试能解决什么样的问题？不能解决什么类型的问题？
——解决快速发现功能级bug的问题；不能系统的解决性能测试、稳定性测试的问题。
2、一个产品线如何确定是否适合这种方法？如何将探索性测试方法与具体的产品结合起来？
――所有产品都适合应用，只是ET所在投入比例不同（我在硬件驱动软件测试、Linux文件系统测试、windows客户端、web应用都应用过）；
――方法与产品结合的办法是：关注我的ET TOPN方法，这是测试界的数据分析与数据挖掘
3、探索性测试方法的落实？如何培训并运用到项目中？如何让测试人员在项目中将这些方法运行起来，或者说将方法与具体的case（涉及到业务及功能点）对应起来？
――借助脑图工具把此次测试任务的测试对象画于中心位置，然后把ET的方法作为第一层节点，在每个ET方法后面延伸第二层节点（由ET方法启发出来的测试场景）
4、case是怎样的管理粒度？如何维护？
――探索测试的用例大多不适合回归（成本很大），只有部分最有价值的用例适合抽取回归。
――探索测试用例继承性的问题通过脑图积累，每次探索测试都是在前一次脑图的基础上叠加增长（所有测试场景的维护管理：最高层是测试对象、然后是测试方法、最后是测试场景）
5、怎样衡量探索性测试方法的成果？包括阶段性的结果？
――初期学习衡量的方式就是：单位时间内投入测试人时发现的bug数（提升测试效率）；在测试用例设计阶段用探索测试方法补充的测试用例发现的bug数占总用例发现bug（提升用例数）； 在用例执行后补充进行探索测试发现的bug数（提升测试质量）
――后期熟练后：达到代码覆盖率目标的测试时间（测试效率）；用户发现bug数（测试质量）；支持项目的测试周期（测试设计时间＋测试执行时间）缩短。
6、探索性测试有哪些工具支持？有没有可能自动化回归？
――大部分探索测试场景不需要回归。探索测试更多是测试设计的武器。
――脑图工具是目前最好的工具。
7、探索性测试的测试方法是否必需通过bug分析选取，这些方法一般多久更新一次，更新的变化很大怎么办？有通过的或者好用的必选方法吗？
―――必须要通过bug分析选取；如果没有bug，可以参考我所推荐的测试方法分类；
――变化很大没有影响，说明要么产品形态和实现发生很大变化、要么团队的人员资源发生了变化。这正是探索测试可以快速适配变化的优势所在。
8、做ET测试时如何做到覆盖所有的用户场景？通过方法来到达的吗？那选择方法是否很关键？
――所有的用户场景无法做到，这是共产主义社会。但能先做到尽可能先覆盖到大部分的用户行为模式（很多ET方法就是用户行为模式的抽象与集成）。
―――选择方法非常关键，决定影响你ET的效率和质量（能否覆盖到你产品当前的主要风险方向）。
9、流程上的问题：补充性探索性测试是否可以不做漫游测试，补充性探索性测试测试设计是否不是必需用脑图，那还是否能达到ET的目标？
――漫游测试 是ET在预测试和功能基本测试时的方法。
――所有探索测试 都必须事先进行计划（探索测试设计脑图就是计划），没有计划就可能倒退回自由测试，无法积累、无法技术管理、方向错误、降低效率。
10、探索性测试一般占项目测试人力的多少比例？如何平衡投入产出比？
――初期部分同事掌握和实施探索测试、熟练后成为团队内部教练、然后逐步全民掌握和应用探索测试。
版权声明：本文出自 架构师Jack 的51Testing软件测试博客：http://www.51testing.com/?293557
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
1、top
top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器
内容解释：
PID：进程的ID
USER：进程所有者
PR：进程的优先级别，越小越优先被执行
NInice：值
VIRT：进程占用的虚拟内存
RES：进程占用的物理内存
SHR：进程使用的共享内存
S：进程的状态。S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值为负数
%CPU：进程占用CPU的使用率
%MEM：进程使用的物理内存和总内存的百分比
TIME+：该进程启动后占用的总的CPU时间，即占用CPU使用时间的累加值。
COMMAND：进程启动命令名称
常用的命令：
P：按%CPU使用率排行
T：按MITE+排行
M：按%MEM排行
2、/proc/pid
测量一个进程占用了多少内存，linux为我们提供了一个很方便的方法，/proc目录为我们提供了所有的信息
说明：
/proc/N pid为N的进程信息
/proc/N/cmdline 进程启动命令
/proc/N/cwd 链接到进程当前工作目录
/proc/N/environ 进程环境变量列表
/proc/N/exe 链接到进程的执行命令文件
/proc/N/fd 包含进程相关的所有的文件描述符
/proc/N/maps 与进程相关的内存映射信息
/proc/N/mem 指代进程持有的内存,不可读
/proc/N/root 链接到进程的根目录
/proc/N/stat 进程的状态
/proc/N/statm 进程使用的内存的状态
/proc/N/status 进程状态信息,比stat/statm更具可读性
/proc/self 链接到当前正在运行的进程
3、pmap
pmap命令可以显示一个或多个进程所使用的内存数量。你可以使用这个工具来了解服务器上的某个进程分配了多少内存，并以此来判断这是否是导致内存瓶颈的原因。要得到更加详细的信息，使用pmap -d选项。
学习一种新的编程语言总是一种挑战，因为简单的失误就可以产生错误，对于门外汉来说都是神秘和充满困惑的。如果你不是足够幸运有一个有经验的程序员在旁边看着你并提供指导，排除你代码的故障将是非常令人沮丧的。
如果你正学习Java语言，你在编译和执行代码的时候遇到问题，一般来说问题将分为2类：无论你遇到的是编译时错误，这说明你的程序编译失败，还是你遇 到运行时错误，这是指错误发生在你成功地编译了程序但不能运行并且没有产生错误。当然，在你遇到一个运行时错误之前，你的代码必须首先能够编译，所以在这 里我们将研究最常见的开发者可能遇到的编译时错误的原因。
最常见的编译时错误
我们将使用下面的代码作为一个Java示例类作为讨论：
public class Game {
public static void main（String args[]） {
System.out.println（“If I choose Paper,”）；
System.out.println（“And you choose Scissors,”）；
System.out.println（“Then I win, and you lose!”）；
}
} |
Java文件错误的命名方式--Java文件的名称必须和代码中相关的公共类完全匹配。因此，如果你的代码包含一个公共类“Game”，Java文件必 须命名为“Game.Java”，而不能命名为“game.Java”，或者是“GAME.Java”，再或者是“MyGame.Java”.该文件的名 称和公共类的名称在拼写和大小写上都必须完全匹配。
代码错误的大小写--Java对大小写敏感，因此“public”与 “Public”或“puBliC”都是不相同的。Java新手往往利用首字母大写，反之亦然，由于大小写错误导致他们编写的代码编译失败。为了进一步复 杂化这个问题，编译时错误信息由于大写问题往往是隐蔽和没有帮助的。例如，如果你把主方法中的声明“public static and void”第一个字母大写，你会得到以下错误消息，说需要一个分号，这真的不是问题的根本：
C:\_jdk1.7\bin>Javac Game.Java
Game.Java:3: error: ';' expected
Public Static Void main （String args[]） {
1 error |
错误匹配的括号--你可以看到你的代码中的每一个开着的括弧，它可能是一个方括号，大括弧或圆括号，你需要一个与之匹配的关闭的括弧。有时，一个程序员 会忘记关闭方法的括弧，或者他们会记得关闭一个方法的括弧，但是忘记关闭类的括弧。不管它是如何发生的，如果括号不匹配，你将会一直得到一个编译时错误。
例如，一个Java类的最后一个大括弧不关闭，试图编译代码将产生下列编译时错误：
C:\_jdk1.7\bin>Javac Game.Java Game.Java:11: error: reached end of file while parsing } 1 error |
就我个人而言，每当我创建一个新的方法或类时，在敲入开始的括弧之后，我总是敲一些回车，然后添加一个结束的封闭括号。我只有在括号匹配的情况下我才会 开始类主体或方法的代码编码。这样，你的括号会总是匹配状态，你样就可以在编写类或者方法代码时，不用担心将来的某个时刻需要关闭括号。
漏掉分号--人们越来越熟悉的Java另一个常见编码错误是漏掉需要的分号。作为一项规则，每一个语句必须以分号结束。不幸的是，这个规则有时可能会像它的作用一样另人费解，尤其是当你有一个很难弄清楚它到底是不是一个语句的时候。
例如，在一个方法的主体里面，所有的“system.out.print”调用都以分号结束。如果我们在一个方法体中忘记给“system.out”加上分号，我们将会得到一个编译时错误消息，就像下面一样：
C:\_jdk1.7\bin>Javac Game.Java
Game.Java:7: error: ';' expected
System.out.println（“Then I win and you lose!”）
1 error |
容易混淆的部分是由于在Java中并不是每一行你写的代码就是一个语句。例如，类声明是不被视为一个语句，所以它不跟分号。同样，一个方法声明是不被视 为一个语句的，所以它也不跟分号。要想容易识别哪个是一个语句哪个不是一个语句需要一定的练习，这也需要一定的时间，但请放心，如果你确实有一个语句，它 就必须跟着一个分号，否则编译器会开始报错。
随着时间的推移，任何编程语言的细微差别最终都会成为司空见惯的事，而Java众所周知的 请求和市场上其他编程语言没什么区别。如果你是Java新手，记住这四个小提示，如果你碰到一个编译时错误，看看是不是Java文件的命名方式产生的问 题，代码中单词和字母的大小写情况，不匹配的括号和或漏掉分号。保持这四个问题点在你的脑海里将帮助你解决Java代码故障排除问题，并希望减轻一些学习 Java程序语言的挫折。
Java异常机制可以保证程序更安全和更健壮。虽说Java类库已经提供很多可以直接处理异常的类，但是有时候为了更加精准地捕获和处理异常以呈现更好的用户体验，需要开发者自定义异常。本文就是探讨如何自定义异常以及使用自定义的异常。
在进行程序开发的过程中，自定义异常遵循以下四个步骤：
1）首先创建自定义异常类，语法格式：自定义异常类名 extends Exception。
2）在方法中通过关键字throw抛出异常对象。
3）若是在当前抛出异常的方法中处理异常，可以用try-catch语句捕获并处理；若不是，在方法的声明处通过关键字throws指明要抛出给方法调用的异常。
4）在出现异常方法的调用中捕获并处理异常。
接下来，通过一个简单的程序来说明自定义异常和使用自定义异常。
首先创建自定义异常类，代码如下：
/**
*<p>Titlt:自定义异常类NumeratorIsZeroException</p>
*<p>Description:分子为零的异常</p>
*<p>Copyright:copyright(c) 2012</p>
*<p>Filename:NumeratorIsZeroException.java</p>
*@authorWang Luqing
*@version1.0
*/
class NumeratorIsZeroException extends Exception
{
public NumeratorIsZeroException(String msg)
{
super(msg);
}
} |
接下来，使用自定义异常类，代码如下：
/**
*<p>Titlt:设计类Number/p>
*<p>Description:类中有除法计算方法</p>
*<p>Copyright:copyright(c) 2012</p>
*<p>Filename:Number.java</p>
*@authorWang Luqing
*@version1.0
*/
public class Number
{
public int divition(int iNum1,int iNum2) throws NumeratorIsZeroException
{
if(0 == iNum2)
{
throw new NumeratorIsZeroException("分子不能为零。");
}
return (iNum1/iNum2);
}
} |
/**
*<p>Titlt:设计类Test</p>
*<p>Description:测试自定义的异常类</p>
*<p>Copyright:copyright(c) 2012</p>
*<p>Filename:Test.java</p>
*@authorWang Luqing
*@version1.0
*/
public class Test
{
public static void main(String[] args)
{
Number num = new Number();
try
{
System.out.println("商：" + num.divition(12,0));
}
catch(NumeratorIsZeroException e)
{
System.out.println(e.getMessage());
e.printStackTrace();
}
catch(Exception e)
{
System.out.println(e.getMessage());
e.printStackTrace();
}
}
} |
运行结果如下所示：
分子不能为零。
NumeratorIsZeroException：分子不能为零。
at Number.divition(Number.java:15)
at Test.main(Test.java:17)
总结：
1）根据上述代码关键点归纳，自定义异常类，标识可能抛出的异常，捕获和处理异常。
2）getMessage()：输出异常的信息；printStackTrace()：输出导致异常的详细信息。
3）设计和利用好自定义异常，使得异常的处理更灵活和精准。
1、背景介绍
1.1 接口
web ui接口是服务器与客户端交互的方式，即浏览器或者其他客户端工具与web服务UI层交互的协议.常见的有两大类，一是浏览器与服务器交互的 HTTP，HTTPS协议的接口，另一类web service接口如soap，rmi，rpc等协议。这些接口的共通特征都是作为Server对外的UI提供通信服务。
1.2 接口测试
web ui接口测试即站在web服务程序UI层之上自动化测试的一种手段，是站在用户的角度上测试web服务程序业务逻辑的正确性。测试的重点是围绕web服务 暴露的接口检查接口数据的正确性，这个过程是将web服务程序当做黑盒，通过自动化测试技术提高测试执行效率降低人工回归的成本。
1.3 可测性分析
1.3.1 为什么做接口测试
在业务模块的分层测试中，各种测试方式的比重如下图所示，实践中我们从系统级测试发现的bug数目最多，所以系统级测试占比比较大；除此之外，由于现在敏 捷的尝试以及普遍开展的项目迭代，面向模块提前介入测试的方式也越来越频繁，而此时并不具备系统级可测性，因此模块的接口就成为测试自动化的最好入口。
在业务系统常用测试方案中，有以下说明：
（1）单测在不同的团队和模块有不同的作法，如果QA太多的介入，则对QA coding能力要求较高，case的传承性也受到挑战
（2）业务模块接口测试主要关注接口请求参数与返回数据的正确性，以参数覆盖为测试等价类
（3）系统级case对web业务模块来说都是基于浏览器用户行为的，目前有selenium自动化，大部分是手工测试。
从分层测试的特征，业务系统的结构出发，我们认为，接口测试的必要性包括：
（1）迭代开发模式中，接口测试可先于系统级测试提前进行，属于测试前置
（2）相比于基于浏览器客户端的系统级测试，接口测试更专注接口数据正确性，稳定性与可靠性的性价比高
1.3.2 接口可测性
接口在业务模块中的类型为典型的HTTP接口（Ajax，Dwr，Action…），也有Java类型的一些接口（RPC，RMI，SOAP），在可测性上具有一些共通特征：
（1）可自动化率高：接口总能通过相应的client来发送请求
（2）脱离RD代码依赖，只针对接口：属于黑盒测试范畴，难度较白盒低
（3）执行速度介于系统级与单测之间：对于业务模块来讲，脱离浏览器后的接口测试稳定性与效率都是大幅提升
（4）容易实现数据分离与数据驱动，容易抽取公共的框架性内容，降低case编写维护人员对coding的依赖
2、轻量级测试框架itest
itest是interface test接口测试框架的简称：支持基于网络通信的WEB UI接口自动化测试，支持HTTP，SOAP，RPC等几种常见协议，支持多种验证结果的模式，支持数据分离，最主要的特征还是通过数据文件驱动测试执行，不需要编码实现测试用例。
2.1 架构设计
itest功能组成与基本处理流程如下图，以主要协议HTTP为例：
基本设计思想：
（1）itest框架支持case文件与执行的分离，case并非coding模式，而是通过各类文件描述case信息（请求文件，数据准备清理文件，验证结果文件…），itest解析case信息后转化为接口请求
（2）登录是针对uc，uuap等测试环境下，模拟请求并获得sessionid，HTTP请求的case需要带着sessionid
（3）参数化：itest作为执行框架，执行接口的部分逻辑比较薄，是基于数据驱动的方式，把case数据转为Junit4的参数化数组，循环执行
（4）setup与teardown：以不同文件后缀代表不同的行为，itest内部可扩展实现对不同后缀名文件的操作逻辑，如后缀为.sql，则当做sql语句直接执行
（5）验证：也是以文件后缀名做有区别的验证，如后缀.response是直接判断expected.equals(actual)？而后缀是.csv的则拼装为sql后查询db是否结果匹配
基础结构：
Junit4+HTTPunit+Ant
2.2 数据驱动
为降低自动化过程中case编写人员的编程成本，采用的模式是itest作为核心的执行与验证框架，傻瓜式的执行外部case目录内的各类文件，每一个 case都不需要coding。如下图所示：case的存在形式为文件目录，1个case是1个目录，itest顺序读取case，以相同流程执行每一个case。
2.3 结果验证
结果验证按照业务系统的特征，现在支持以下几种：对接口返回的内容直接做对比验证；对数据库update后的内容做验证；将接口返回的json做处理后做验证。
2.4 测试数据
对业务系统自动化测试来说，业务测试数据非常关键，因为它需要符合一定的业务规则；如何构造数据有几个争议的地方：
（1）数据（包括DB，server文件，桩文件）一次性构造好放那不动，无法保证数据不被污染，且移植性受限；
（2）如果能做整个环境的备份还原则不怕污染，但是case与case之间可能会互相干扰数据
（3）自动化case是否严格要求数据的隔离，如果要求，则每个case都自己负责生命周期内的数据准备和清理；如果不要求，则需要case设计时刻意避免数据的使用混乱
不同业务系统在设计上各有千秋，哪一种数据准备的方案都是有不同的代价，结合笔者所处产品线的特征，认为自动化case自己负责生命周期内的数据准备与清理，是综合效果比较好的模式：1个独立的case，能有自己生命周期内的数据准备和清理，则最大程度上保证了case运行的稳定性和可靠性，避免case之间互相因为数据发生干扰！
2.5 扩展性
itest在扩展性方面，通过“以文件后缀作为识别标签，新的功能需求，约定一种新的文件后缀”，itest维护人员在框架内开发相应的分支逻辑，而case编写人员则只需按照文件约定格式设计文件即可。如下为目前支持的不同文件，以及相应的不同逻辑功能：
2.2 测试用例执行结果分析
测试用例执行结果可以从覆盖率、执行率、通过率等几个方面进行分析和考察。测试用例覆盖率是指测试用例覆盖的功能与测试需求功能的比值；测试用例执行率是指已执行的测试用例数与测试用例总数的比值；测试用例通过率是指成功执行的测试用例数与测试用例总数的比值。
测试用例的覆盖率需要达到100%，也就是说，测试用例必须覆盖全部的测试需求，否则测试用例的设计则是不全面的，无法保证测试质量，需要补充或者重新设计相应测试用例。测试用例执行率是衡量测试效率的因素，一般说来，在测试完成时测试用例的执行率也需要达到100%，也可能因为某些特殊原因导致测试中断而没有全部执行测试用例，可针对具体的情况进行分析。测试用例通过率是衡量用例本身设计质量和被测软件质量的因素，对于未能成功执行的测试用例，要分析是用例设计错误还是被测软件错误，导致用例无法顺利执行。
3、测试用例维护
软件产品的版本是随着软件的升级而不断变化的，而每一次版本的变化都会对测试用例集产生影响，所以测试用例集也需要不断地变更和维护，使之与产品的变化保持一致。以下原因可能导致测试用例变更：
1）软件需求变更：软件需求变更可能导致软件功能的增加、删除、修改等变化，应遵循需求变更控制管理方法，同样变更的测试用例也需要执行变更管理流程。
2）测试需求的遗漏和误解：由于测试需求分析不到位，可能导致测试需求遗漏或者误解，相应的测试用力也要进行变更。特别是对于软件隐性需求，在测试需求分析阶段容易遗漏，而在测试执行过程中被发现，这时需要补充测试用例。
3）测试用例遗漏：在测试过程中，发现测试用例未覆盖全部需求，需要补充相应的测试用例。
4）软件发布后，用户反馈的缺陷：表明测试不全面，存在尚未发现的缺陷，需要补充或者修改测试用例。
对于提供软件服务的产品，其多个版本常常共存，而对应的测试用例也是共存的，而且测试用例需要专人定期维护，并遵循以下原则：
（1）及时删除过时的测试用例
需求变更可能导致原有部分测试用例不再适合新的需求要求。例如，删除了某个功能，那么针对该功能的测试用例也不再需要。所以随着需求的每一次变更，都要删除那些不再使用的测试用例。
（2）及时删除冗余的测试用例
在设计测试用例时，可能存在两个或者多个用例测试相同内容，降低回归测试效率，所以要定期整理测试用例集，及时删除冗余的测试用例。
（3）增加新的测试用例
由于需求变更、用例遗漏或者版本发布后发现缺陷等原因，原有的测试用例集没有完全覆盖软件需求，需要增加新的测试用例。
（4）改进测试用例
随着开发工作进行，测试用例不断增加，可能会出现一些对输入或者运行状态比较敏感的测试用例。这些用例难以重用，影响回归测试的效率，需要进行改进，使之可重用可控制。
总之，测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程。
4、总结
测试用例管理是软件测试过程中的重要内容，测试用例的好坏对软件测试质量有着重要的影响。本文介绍了测试用例的开发、执行及维护等管理过程，为测试过程中的用例设计提出相关建议，同时也希望从测试用例设计的角度为软件开发提供参考。摘要：开发和维护测试用例是软件测试过程中的重要步骤之一，也是衡量软件测试质量的核心影响因素。本文从开发、执行和维护几方面对测试用例管理过程进行分析，提出了测试用例开发、维护的相关原则。
关键字：软件测试；测试用例
1、测试用例开发
1.1 测试用例编写依据
一般说来，测试需求就是为了达到测试目标，项目中需要测试什么。测试过程中所有活动都可以追溯到测试需求。例如，制定测试计划时，需要明确以下基本要素：首先需要明确测试需求，也就是测试的目标内容；然后才能决定怎么测，即采用什么测试方法；再评估需要多少测试时间，需要多少测试人员，也就是测试的进度安排；最后明确测试的环境是什么。此外，还包括其他因素，例如测试中需要的技能、工具以及相应的专业背景知识，测试中可能遇到的风险等，以上所有的内容结合起来就构成了测试计划的基本要素。制定测试计划的重要依据就是测试需求，而测试计划中的所有内容都可以追溯到测试需求，所以说测试需求是测试计划的基础与重点。同样的，测试方案、用例、内容都要以测试需求为基础。
测试需求是从软件需求映射而来，所以其详细程度与软件需求的详细程度有密切关系。在编写时，在保证与软件需求一致的前提下，力求表达准确详细，避免测试的遗漏与误解。
测试用例的编写应该覆盖所有的测试需求，而测试需求是由软件需求转换而来，因此所有测试用例的执行结果最终都会追溯到软件需求，因此测试用例的编写依据主要是软件需求。此外，还应遵守相关的编写规则、规范等。
1.2 测试用例开发原则
测试用例的设计原则包括：
1）依据原则：测试用例编写的主要依据为项目提供的需求说明书和相关技术规范文档；
2）全覆盖原则：对于需求说明书和相关技术规范中要求的主要功能点进行全覆盖测试，要求所有功能均能正常实现；
3）规范原则：所有测试案例的编写要求规范，对于所有被测的功能点，应用程序均应该按照需求说明书和相关技术规范中的给定形式，在规定的边界值范围内使用相应的工具、资源和数据执行其功能；
4）全面原则：测试不仅仅针对系统功能特性进行测试，对系统的其他质量特性也进行全面的测试与评估。
测试用例编写应该满足的具体量化要求包括如下几点：
（1）用户经常使用、关系到系统核心功能、优先级别较高的功能点，测试用例应该达到100%覆盖率；
（2）针对各个系统端到端的功能以及与其它系统的接口的测试应该达到100%覆盖率；
（3）测试用例包括正常输入和正常业务流程测试，也包括对非法数据输入和异常处理的测试，且对系统非正常操作的测试用例应占到总数的20%-30%；
（4）测试用例中包括中文特性及系统本地化测试，如中文信息的显示、录入、查询、打印和报表显示测试等。
2、测试用例执行
2.1 测试用例对测试需求的覆盖
首先看一下什么是测试需求覆盖。测试需求来源于软件需求，与软件需求的关系是一对一，或者是多对一。如果一个软件需求可以转换为一个或者多个测试需求，那么测试需求已经覆盖了全部的软件需求，可以说测试需求的覆盖率为100%。但是这不能说明测试需求的覆盖程度达到了100%。因为一般的软件需求只明确了显性的功能与特性，而隐性的功能与特性（没有被明确指出但是却应该具有的功能和特性）并没有在需求中直接体现。这部分需求也应该成为测试需求，因此在进行测试需求分析时，要同时分析软件的显性和隐性需求，或者根据实际测试中发现的缺陷，对测试需求进行补充或优化，并更新测试用例，以此来提高测试需求的覆盖程度。
好的测试用例集应该覆盖全部的测试需求。以系统功能举例说来，测试用例包括功能点和业务流程。对于功能点，设计的测试用例需要覆盖全部需求中的功能点，除了正常情况的测试用例，还应设计异常情况的测试用例，且异常情况测试用例占整个测试用例集的20%~30%。同样的，业务流程的测试用例也包含正常流程和异常流程。
配置基线分配
在客户端计算机可以评估其与 Configuration Manager 中的配置基线的符合性之前，必须通过计算机集合向其分配配置基线。
分配包含下列属性：
● 配置基线本身
● 哪个集合是符合性评估的目标，以及它是否包括任何定义的子集合
● 最初使用默认符合性评估计划进行配置、但是可以针对每个分配进行更改的符合性评估计划。
配置基线分配是配置基线的可选属性。可以通过定义多个配置基线分配，将一个配置基线分配到多个集合。
从属配置基线
其中一个配置基线规则要包括另一个配置基线。此嵌套功能提供了一种分层式方法来为大量计算机定义基础配置基线，然后使用附加配置基线（针对角色相同的计算机具有更特定的配置）来改进此基础配置。
当您希望将自己的业务要求与已经导入但不能直接进行编辑的配置基线（例如来自配置包的最佳方案）组合使用时，也可以使用从属基线。当修改了原始配置基线，有新版本可用时，您可以导入最新的版本，无需创建新的配置基线。
从属配置基线在 Configuration Manager 控制台中作为配置基线的属性显示。
重复的配置基线
在 Configuration Manager 中，重复的配置基线是与现有配置基线完全相同的副本，不保留与原始基线的任何关系。
如果您希望创建许多类似但是无关的配置基线，并且具有一个用作模板的配置基线，则可以创建重复的配置基线。另一种情况是如果您需要重新定义配置基线规则或导入的配置基线中的配置项目。
另请参阅
任务
与在 Configuration Manager 控制台中编辑配置数据有关的问题
概念
确定是否需要为所需的配置管理创建重复的配置基线或重复的配置项目
确定是否需要为所需的配置管理导入配置数据
其他资源 基线用于定义在特定时间点通过捕获结构和详细信息建立的产品或系统的配置。Configuration Manager 2007 中的配置基线包含要作为一个组评估其符合性的一组已定义的必需配置。
配置基线包含一个或多个具有关联规则的配置项目，它们通过集合与符合性评估计划一起分配到计算机。
注意
尽管您可以将配置基线分配到包含用户的集合，但是仅由集合中的计算机评估配置基线，而不是集合中的用户。
您可以使用 Configuration Manager 控制台创建自己的配置基线，并可以从下列来源导入配置基线：
● 来自 Microsoft 或其他供应商的定义最佳方案的配置包
● Internet 上通过社区提供的配置数据
● 来自您自己的组织，但对 Configuration Manager 而言是外部的创作的自定义配置基线
● 其他 Configuration Manager 站点
在导入配置基线时，除非它们最初创建于同一 Configuration Manager 站点，否则不能直接在 Configuration Manager 控制台中进行修改。如果需要改进配置项目以满足您的业务要求，请遵循下列推荐路径：
1、使用自定义值创建子配置项目。
2、复制配置基线。
3、编辑复制的基线，并使用编辑后的子配置项目代替原来的配置项目。
配置基线规则
配置基线规则用于指定包括在配置基线中的配置项目如何在客户端计算机上评估符合性。它们用于定义您需要的符合性。
在 Configuration Manager 中有固定类型的配置基线规则，不能更改。配置项目可以添加到下列配置基线规则中：
● 下列操作系统配置项目中必须有一个存在并且正确地配置。
● 这些应用程序和常规配置项目是必需的，必须正确地配置。
● 如果检测到这些可选应用程序配置项目，则必须正确配置它们。
● 这些软件更新必须存在。
● 不能存在这些应用程序配置项目。
● 这些配置基线还必须经过验证。