接移动端App测试实用指南（上）
特定平台上的注意事项
对于任何项目团队成员来说，了解相关平台的业务、技术和设计上的限制，都是至关重要的。
那么，移动端App的测试人员应该找出哪些平台相关的问题呢？
· 是否遵照了这个特定平台的设计规范？
· 与竞争对手以及行业内的设计相比如何？
· 是否适应外围设备？
· 触摸屏支持手势吗，如：轻拍、双击、长按、拖动、摇动、夹捏、轻拂、滑动？
· 这个App可以被理解吗？
· 当转动设备的方向时，有什么变化？
· 可以使用地图和GPS吗？
· 有用户指南吗？
· 电子邮件的工作流程友好吗？
· 通过网络分享时，它运行得流畅吗？是否整合了其他社交应用或网站？
· 当用户正在进行多任务工作，并在不同App间切换的时候，它还运行正常吗？
· 当用户更新它时，它是否会显示时间进度？
· 默认设置如何？有经过调整吗？
· 使用音效会有不同吗？
案例：ChimpStats
ChimpStats是iPad上一个查看邮件广告详情的应用。我第一次使用这个应用是处于横屏模式。当我需要输入API密码的时候，我被困住了。我根本不能在水平模式中输入API密码，直到切换成竖屏模式，才输入成功。
连接和中断的问题当连接断断续续或是意外中断时，很多有趣的事情就可能发生了。
你是否尝试过在以下场景中使用App：
· 走动环境下？
· Wi-Fi连接下？
· 没有Wi-Fi的情况下？
· 3G模式下？
· 间歇性地连接？
· 设置为飞行模式？
· 一个电话打进来时？
· 接收到一条信息时？
· 接收到一个提醒通知时？
· 在电量很低甚至自动关机时？
· 被强制更新时？
· 收到一条语音留言时？
这类测试最容易发现错误和Bug。我强烈建议你在这些情况下进行测试（不仅仅只是开机、确认它可以正常工作，还要尝试用户使用的整个流程，并在特定的时间间歇内强制连接和中断）。
· 这个App提供了足够多的反馈吗？
· 数据传输为用户所知吗？
· 它会慢慢停止，然后崩溃吗？
· 开启时会发生什么？
· 任务完成中会发生什么？
· 是否可能丢失未保存的操作？
· 你可以忽视通知提醒吗？忽视后会发生什么？
· 你可以对通知提醒做出响应吗？响应后会发生什么？
· 对某些问题，使用错误信息是否恰当？
· 当登录过期或超时会发生什么？
App的维护
想要加快整个测试的过程很简单，只需测试一次就一劳永逸了，对吗？请三思。
此刻我遇到的一个问题是： iPad上的一些App在更新后，再也不能下载了。对于一个用户来说，这是非常令人沮丧的。
可能，这也是开发者控制不了的。谁知道呢？我只知道它对于用户来讲是不能用的。我也尝试卸载App，然后重装，但这个问题始终未能解决。我在网上大量的搜索，除了找到一些关于更新操作系统的建议外，没有任何其他解决方式。可能，下次有空时候，我还会再试试看。
关键问题在于：如果一个应用只被测试过一次，且只有一次（或仅在很短的一段时间内测试过），很多问题你都发现不了。一个App自身可能不会发现变化，但外界条件却可以让这些问题发生。
当外界环境持续变化时，App又会受到哪些影响呢？让我们问问自己：
· 我可以下载这个App吗？
· 我可以下载并安装更新吗？
· 更新之后还能使用吗？
· 当很多App处于等待更新状态时，我能更新它吗？
· 系统更新后，它会发生什么？
· 系统未更新，它又会发生什么？
· 它会通过iTunes自动同步下载到其他设备吗？
· 它自动执行任务或测试有意义吗？
· 它会连接到网络服务吗？这会带来什么不同？
移动端的App每一个版本发布后，最好都去测试一下。每次发布新版本时，先定义最高优先级测试，确保其能在各种条件下进行（主要是在主流的平台上）。随着时间的推移，测试可以变得自动化。但请记住，自动化不是灵丹妙药，发现问题，只能通过人的眼睛。
案例：iPhone上的Analytics应用
我使用这个App已经两年了，之前它一直没有什么问题。但是现在，它却显示出我某些网站数据为零（但实际上，不止一个人一个月内访问过我的网站！）。从App Store的评论来看，我不是唯一一个遇到这个问题的人。
另外一个案例是iPhone上的Twitter。更新并启动这个App后，我瞬间看到了如下这个提示语：“你的时间线数据显示为空，你至今没有关注任何人” (但我是拥有5年经验的活跃用户)。我担心了一会儿，庆幸的是，这个消息很快就消失，然后加载出历史数据。
测试不是对错判断
我们讨论了移动测试的一些方面，但这些前提是：带着问题，才能发现问题。
通常，测试被认为是完全合乎逻辑的、可计划的和可预测的，过程包括：测试脚本和测试计划、通过和失败、正确和错误的反馈。走完这些测试流程就离真相不远了。
当然，如果必要，我们可以用上述方法进行测试，但这并不是测试的目的。我们不仅是为了创建测试用例、发现Bug，更重要的是找到关键的问题，为项目组决定什么时候发布App提供有价值的信息。而找到那些关键问题的最好方法就是：提问！
相关链接：
移动端App测试实用指南（上）
现在很多软件应用，都设计成2部分：应用程序Application + 数据库DB。要对这种类型的应用软件进行测试，“测试数据”这个概念就非常的关键。测试用例中的“前置条件”，基本就是围绕测试数据来设计的。以淘宝网的测试为例，验证每个功能点时，最重要的就是准备好各种类型的数据对象，比如：不通信用级别的卖家，不同类目属性的商品等等。
熟练的测试工程师手里都会保存一批测试数据（比如账号、商品），并且分类管理，不同场景的测试用例，都会有专门的测试数据来支持。在ta的心里，存在着一套完整的测试设计方案，在工作中也会显得游刃有余。要达到这种状态，需要经过一段时间的积累，需要“磨合”。对测试数据的控制力，也是测试工程师的重要能力之一，可惜这种能力很难被识别，被比较。
最近2年，软件测试工作在逐渐向开发团队转移，由以前的测试团队“全包”，变成了现在的“半包”。很多观点也认为，开发团队来做测试工作，有着得天独厚的优势，因为开发对应用程序的结构最熟悉，哪里容易出现问题也最清楚。当然也有很多开发表示反对，原因大概有下面几个：
● 没时间，能把代码写完就不错了
● 开发工程师没有测试工程师的那种思维方式
● 测试数据准备起来比较困难
这里的“测试数据问题”是客观存在的，但不仅仅是这么简单的一句话可以概括，需要深入分析。我们观察开发工程师在做测试工作的时候，在测试数据方面会遇到下面几个问题：
1、对于一些比较复杂的测试场景，搞不清应该构造哪些测试数据对象，最后只好随便抓一个来测试，只要没抛异常，就算pass；
2、就算搞清了测试数据的需求，去哪找这些数据，仍然是一个大问题，最后还是随便抓一个来测试；
3、就算把所有的测试数据都做好，如何根据测试场景随机应变的使用，如何维护这些数据始终有效，也非常不容易；
分析到这里我们发现，测试工程师对测试数据的控制能力，真的不简单，开发工程师在工作中一般没有接受过类似的训练，所以很容易陷入“测试数据”的泥潭。而且，这个问题跟人的能力有关，不是单纯依靠工具能解决的。
关于“测试数据建模”，主要是解决上面的第一个问题：当我们要测试一个功能点，或者一系列场景的时候，需要设计出怎样的测试数据组合。
我们先假设一个最简单的场景，这个场景只需要用到1个数据对象：USER，那么这里的测试数据，就是USER的每个属性的枚举值：性别、年龄、状态、等 级，我们用一句话就可以概括一个数据对象，比如：女性user、20岁的user、状态是已认证的user。测试用例可以这样写，但是实际测试时，熟练的 测试工程师并不会分别测试，而是把多种情况组合在一起，比如：20岁的已经认证的女性user。每个人的组合方式都不一样。有一种算法叫做 “Pairwise Testing”，可以比较科学的组合多个属性的枚举值。但是有经验的测试工程师发现，年龄和性别的逻辑关系很密切，这里的组合需要特别的设计，依靠 Pairwise的基础设计还远远不够，需要引入业务逻辑的分析。
所以同样的测试用例，不同的工程师在测试时，花费的时间，得出的结 果，会有很大的不同。仅仅一个数据对象，就会产生这么复杂的情况，那么请设想一下，如果一个场景需要用到5个数据对象，并且它们之间存在复杂的逻辑关系 时，测试工程师需要面临怎样的困难局面，我们已经无法用一句话来概括测试数据的具体值。这里“测试数据建模”的概念就自然的引出了，建模的目的，就是我们 可以很容易的描述清楚，复杂场景下的测试数据是怎样的。
很多工程师习惯用思维导图来进行测试数据的设计，比如上文那个例子，大家会看到这样的设计图：
但是在真实的测试场景中，我们使用的是matrix来组织测试数据，如下：
灰色的cell代表在这个场景下，该属性随便取什么值。在这个案例里，我们发现性别和年龄关系密切，而状态和等级关系密切，所以测试数据需要分开设计，我们建立A、B两个模型：
A模型是：
● user.性别 : {"男" , "女" , "不知道"}
● user.年龄 : {"10" , "20" , "30" , "40"}
B模型是：
● user.状态 : {"未认证" , "认证" , "删除" }
● user.等级 : {"新人" , "熟练手" , "砖家" }
每个模型都必须有一个唯一的名称，目的是为了方便测试设计和交流。比如这个Test Suite（一组Test Case的集合）需要使用A模型，那个Test Suite需要B模型。这里的A、B只是一个代号，真实工作中可以根据产品特点重新定义命名规则。
测试数据模型的真正内涵是：把业务逻辑关联最强的数据对象属性聚在一起建立group，并列举出需要的属性值，方便测试用例的设计，更为重要的 是，模型让开发和测试在围绕“测试数据问题”进行讨论的时候，有一个标准。由于模型里面已经封装了很多信息，只要指明模型的名称，交流就变得更加简单了。
当然文章里这个案例的逻辑非常简单，实际工作中并不需要测试数据建模，不过当数据对象比较多时，价值就能体现出来了。比如淘宝的下单，可能就会出现这样的数据模型：
● 商品.价格 : {"",""}
● 卖家.状态 : {"",""}
● 买家.所在地 : {"",""}
● 类目.XXX : {"",""}
复杂的数据模型，可能会有10个以上的数据对象属性。不过我们不能把所有对象属性，都堆在一个模型里，那样没有任何意义，我们需要根据业务逻辑 对属性进行分类，建立不同的模型，比如优惠、运费计算是不同的业务逻辑，因此需要建不同的模型。而围绕优惠这个概念，还会根据不同属性组合关系，建立多个 模型。
我想每个测试场景，需要建立的数据模型并不会很多，2、3个左右。数据模型必须是常用的，这样才有实际意义。时间久了，研发团队每个成员的脑海 里，对于测试数据模型的概念，会越来越深刻，甚至对于模型里的某个Test Case，如果被执行的次数够多的话，也会被大家记住。到时候Test Case也会需要名称，为了方便大家记忆交流。
在实际工作中，开发工程师经常反映，要执行某个Test Case，只修改某个数据对象（比如user）的属性，根本不够，必须要把多个数据对象（比如user、order、item）同时修改，才能完成。这其 实就是一个典型的需求：这个Case需要一个复杂的测试数据模型。
当测试数据模型被大家接受以后，我们就可以围绕模型做一些工具开发，来简化准备测试数据的工作。如果工具只能分别修改某个对象的属性，那么可用 性就不会太好，需要人为进行组合操作。如果工具能以测试数据模型为单元，就可以很快生成数据模型里的某个Test Case，这样会大大简化测试准备工作。
需要说明的是，本文是基于工作现状的推理，这种建模方式仅仅是“原型”，还缺少一些最佳实践。如果本文的论述能引起你的共鸣，欢迎你在自己的产品测试中试一试。
在客户端的功能测试过程中，常常需要验证URL请求是否发送，参数是否正确。市场上有不少的网络数据分析工具，smsniffer、wireshark、fiddler......他们可以很好的辅助我们完成验证的工作。但是，在自动化测试的过程中，无法再依靠肉眼检查来完成相关的验证。通常的做法，可以在本地Mock一个服务器，再又服务器将请求的数据返回给客户端来进行验证，这在接口测试中比较有效。但是在功能测试的过程中，需要额外的编写一个工具，完成相关的代理转发工作，本身是一件略有难度的事。因此，团队在测试的过程中考虑通过另外的方法去捕获客户端程序发出的请求和响应。
设想的方案的是利用现有的工具，生成网络监听数据后，再通过 TCP/IP + HTTP 协议反向解析出请求数据和响应数据。通过调研选定了Windows平 台下的网络监听工具WinDump（该工具是Window平台下一款出色的开源的轻量级网络监听工具）。通过实验及对WinDump文档的研究，确定了抓 包时使用的参数：WinDump.exe -i N -s 0 -w file_name -a host host_name其中：
-i 表示监听的网络端口编号
-s 0 表示捕获完整的数据包
-w file_name 输出到文件file_name中
-a 使用Ascii编码输出数据包
host host_name 只捕获与host_name间的通信数据包。
通过这些参数，WinDump生成的数据文件格式是稳定的，包含完整的MAC、IP、TCP层的完整数据，是可以反向解析的。根据相关协议的文档和生成 文件的数据比对，确定生成的文件格式为：24字节未知数据 + 16或者22字节的未知数据 + MAC帧 + IP帧 + TCP帧 + 数据帧，第2、3、4、5、6部分每个数据包都会重复出现。此外，通过比对，工具会生成完整的三次握手数据。
在分析完数据文件的格式 后，就可以通过编码去分拆数据包了，去除未知数据后，把有用的数据包提取出来，并解析出其中的数据帧。并通过请求发送的端口和目标端口，对并发数据做完整 的对应关系(Request的端口是动态的，服务器会根据请求的端口将相应的Response返回给请求端口)。最后提取出关键的请求和响应的数据帧存储 起来。这里是一份基于Ruby语言的捕获http数据包和正则验证数据请求存在的辅助类实现代码。在辅助类中通过正则表达式去拆分Http请求及相应中的相关参数，并进行存储。通过对外的接口获取相关的请求和相应，后面想做什么，就随心所愿了....
最后有一些需要改进的地方：1、如果能在请求时能过滤一些不Care的数据(例如未知数据、三次握手的数据)，这样最好了。2、需要根据数据分包标志完 成数据包的拼接(TCP协议中对数据包的大小做了一些限制，因此在数据包超过协议长度时会分为多个数据包传输，需要通过偏移量完成完整数据包的还原工 作)。
第一级 初始级
TMM初始级软件测试过程的特点是测试过程无序，有时甚至是混乱的，几乎没有妥善定义的。初始级中软件的测试与调试常常被混为一谈，软件开发过程中缺乏测试资源，工具以及训练有素的测试人员。初始级的软件测试过程没有定义成熟度目标。
第二级 定义级
TMM的定义级中，测试己具备基本的测试技术和方法，软件的测试与调试己经明确地被区分开。这时，测试被定义为软件生命周期中的一个阶段，它紧随在编码阶段之后。但在定义级中，测试计划往往在编码之后才得以制订，这显然有背于软件工程的要求。
第三级 集成级
在集成级，测试不仅仅是跟随在编码阶段之后的一个阶段，它已被扩展成与软件生命周期融为一体的一组已定义的活动。测试活动遵循软件生命周期的V字模型。测试人员在需求分析阶段便开始着手制订测试计划，并根据用户或客户需求建立测试目标，同时设计测试用例并 制订测试通过准则。在集成级上，应成立软件测试组织，提供测试技术培训，关键的测试活动应有相应的测试工具予以支持。在该测试成熟度等级上，没有正式的评 审程序，没有建立质量过程和产品属性的测试度量。集成级要实现4个成熟度目标，它们分别是：建立软件测试组织，制订技术培训计划，软件全寿命周期测试，控 制和监视测试过程。
（I）建立软件测试组织
软件测试的过程及质量对软件产品质量有直接影响。由于测试往往是在时间 紧，压力大的情况下所完成的一系列复杂的活动，因此应由训练有素的专业人员组成测试组。测试组要完成与测试有关的多种活动，包括负责制订测试计划，实施测 试执行，记录测试结果，制订与测试有关的标准和测试度量，建立测试数据库，测试重用，测试跟踪以及测试评价等。建立软件测试组织要实现4个子目标：
1）建立全组织范围内的测试组，并得到上级管理层的领导和各方面的支持，包括经费支持。
2）定义测试组的作用和职责。
3）由训练有素的人员组成测试组。
4）建立与用户或客户的联系，收集他们对测试的需求和建议。
（II）制订技术培训计划
为高效率地完成好测试工作，测试人员必须经过适当的培训。制订技术培训规划有3个子目标：
1）制订组织的培训计划，并在管理上提供包括经费在内的支持。
2）制订培训目标和具体的培训计划。
3）成立培训组，配备相应的工具，设备和教材
（III）软件全生命周期测试
提高测试成熟度和改善软件产品质量都要求将测试工作与软件生命周期中的各个阶段联系起来。该目标有4个子目标：
1）将测试阶段划分为子阶段，并与软件生命周期的各阶段相联系。
2）基于已定义的测试子阶段，采用软件生命周期V字模型。
3）制订与渊试相关的工作产品的标准。
4）建立测试人员与开发人员共同工作的机制。这种机制有利于促进将测试活动集成于软件生命周期中
（IV）控制和监视测试过程
为控制和监视测试过程，软件组织需采取相应措施，如：制订测试产品的标准，制订与测试相关的偶发事件的处理预案，确定测试里程碑，确定评估测试效率的度量，建立测试日志等。控制和监视测试过程有3个子目标：
1）制订控制和监视测试过程的机制和政策。
2）定义，记录并分配一组与测试过程相关的基本测量。
3）开发，记录并文档化一组纠偏措施和偶发事件处理预案，以备实际测试严重偏离计划时使用。
在TMM的定义级，测试过程中引入计划能力，在TMM的集成级，测试过程引入控制和监视活动。两者均为测试过程提供了可见性，为测试过程持续进行提供保证。
第四级 管理和测量级
在管理和测量级，测试活动除测试被测程序外，还包括软件生命周期中各个阶段的评审，审查和追查，使测试活动涵盖了软件验证和软件确认活动。根据
管理和测量级的要求，软件工作产品以及与测试相关的工作产品，如测试计划，测试设计和测试步骤都要经过评审。因为测试是一个可以量化并度量的过程。为了测
量测试过程，测试人员应建立测试数据库。收集和记录各软件工程项目中使用的测试用例，记录缺陷并按缺陷的严重程度划分等级。此外，所建立的测试规程应能够
支持软件组终对测试过程的控制和测量。管理和测量级有3个要实现的成熟度目标：建立组织范围内的评审程序，建立测试过程的测量程序和软件质量评价。
（I）建立组织范围内的评审程序
软件组织应在软件生命周期的各阶段实施评审，以便尽早有效地识别，分类和消除软件中的缺陷。建立评审程序有4个子目标：
1）管理层要制订评审政策支持评审过程。
2）测试组和软件质量保证组要确定并文档化整个软件生命周期中的评审目标，评审计划，评审步骤以及评审记录机制。
3）评审项由上层组织指定。通过培训参加评审的人员，使他们理解和遵循相牢的评审政策，评审步骤。
（II）建立测试过程的测量程序
测试过程的侧量程序是评价测试过程质量，改进测试过程的基础，对监视和控制测试过程至关重要。测量包括测试进展，测试费用，软件错误和缺陷数据以及产品渊量等。建立渊试测量程序有3个子目标：
1）定义组织范围内的测试过程测量政策和目标。
2）制订测试过程测量计划。测量计划中应给出收集，分析和应用测量数据的方法。
3）应用测量结果制订测试过程改进计划。
（III）软件质量评价
软件质量评价内容包括定义可测量的软件质量属性，定义评价软件工作产品的质量目标等项工作。软件质量评价有2个子目标：
1）管理层，测试组和软件质量保证组要制订与质量有关的政策，质量目标和软件产品质量属性。
2）测试过程应是结构化，己测量和己评价的，以保证达到质量目标。
第五级 优化，预防缺陷和质量控制级
由于本级的测试过程是可重复，已定义，已管理和己测量的，因此软件组织能够优化调整和持续改进测试过程。测试过程的管理为持续改进产品质量和过程质量提供指导，并提供必要的基础设施。优化，预防缺陷和质量控制级有3个要实现的成熟度目标：
（I）应用过程数据预防缺陷。这时的软件组织能够记录软件缺陷，分析缺陷模式，识别错误根源，制订防止缺陷再次发生的计划，提供跟踪这种括动的办法，并将这些活动贯穿于全组织的各个项目中。应用过程数据预防缺陷有礴个成熟度子目标：
1）成立缺陷预防组。
2）识别和记录在软件生命周期各阶段引入的软件缺陷和消除的缺陷。
3）建立缺陷原因分析机制，确定缺陷原因。
4）管理，开发和测试人员互相配合制订缺陷预防计划，防止已识别的缺陷再次发生。缺陷预防计划要具有可跟踪性。
（II）质量控制在本级，软件组织通过采用统计采样技术，测量组织的自信度，测量用户对组织的信赖度以及设定软件可靠性目标来推进测试过程。为
了加强软件质量控制，测试组和质量保证组要有负责质量的人员参加，他们应掌握能减少软件缺陷和改进软件质量的技术和工具。支持统计质量控制的子目标有：
1）软件测试组和软件质量保证组建立软件产品的质量目标，如：产品的缺陷密度，组织的自信度以及可信赖度等。
2）测试管理者要将这些质量目标纳入测试计划中。
3）培训测试组学习和使用统计学方法。
4）收集用户需求以建立使用模型
（III）优化测试过程在测试成熟度的最高级，己能够量化测试过程。这样就可以依据量化结果来调整测试过程，不断提高测试过程能力，并且软件组织具有支持这种能力持续增长的基础设施。基础设施包括政策，标准，培训，设备，工具以及组织结构等。优化测试过程包含：
1）识别需要改进的测试括动
2）实施改进。
3）跟踪改进进程。
4）不断评估所采用的与测试相关的新工具和新方法。
5）支持技术更新。
（IV）测试过程优化所需子成熟度目标包括：
1）建立测试过程改进组，监视测试过程并识别其需要改进的部分。
2）建立适当的机制以评估改进测试过程能力和测试成熟度的新工具和新技术。
3）持续评估测试过程的有效性，确定测试终止准则。终止测试的准则要与质盘目标相联系。
版权声明：本文出自 zhuang920 的51Testing软件测试博客：http://www.51testing.com/?613
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
简介： 许多敏捷软件开发团队都面临的一个挑战是，确保其单元测试包含大部分代码。这在确保他们创建尽可能少的缺陷并且代码可重构时非常重要。因此，重要的度量指标（除了通过的所有测试之外）之一是已包含的代码数量。从 Rational Application Developer 8.0.3 开始，您可以配置 IBM® Rational® Application Developer 并将它与 IBM® Rational Team Concert™ 集成，以便在交付代码之前运行测试并检查代码覆盖率。本文将介绍如何设置此先决条件（名为 Code Coverage Advisor），还将介绍如何使用它来增加项目中测试的代码的覆盖率。
在许多类型的开发项目中，无论您使用的是敏捷开发方法、Rational Unified Process （RUP），还是瀑布式开发方法，在开发期间，测量已执行代码的数量是一个主要度量指标。这对开发人员和测试人员都很重要，因为当开发人员生成具有高代码 覆盖率的代码时，测试团队可以关注代码是否满足业务目标，而不是陷入大量低级代码缺陷中。
当代码覆盖率非常重要时
下列是代码覆盖率非常重要时的一些场景的常见示例：
● 任何想要响应业务并以低风险方式进行更改的团队
● 正在开发代码、想要提供工作质量可见性或需要满足约定的 SLA 的第三方
● 当某个项目定义了开发和测试之间的协议，以便通过开发测试获得代码覆盖率时，这意味着测试团队在捕捉代码错误上花费的时间更少
● 敏捷团队可能想要在每个 sprint（冲刺阶段）结束时制定发布代码决策，因为这会提高交付物的质量，在将代码用于生产之前很少需要转换代码
● 一些想要减少技术债务的团队，这些团队可以逐渐增加单元测试的数量并重构代码，从而减少错误并减低复杂性
● 想要通过构建度量程序来衡量质量和技术债务的组织，这样做可及早发现发展趋势并进行相应的改进
许多敏捷团队都面临的一个具体挑战是，确保他们的单元测试包含大部分代码。这在确保他们创建尽可能少的缺陷并且代码可重构时非常重要。（考虑到团队发展 的趋势是涉及很少的设计或没有设计，则具有良好的单元测试非常重要。）一个主要度量指标（除了通过的所有测试）是已包含的代码数量，这是新 IBM？ Rational？ Application Developer 版本发挥作用的地方。
今年早些时候，我编写了一个原型扩展，用该扩展来集成 IBM？ Rational Team Concert？ 和 Rational Application Developer。如果没有足够的代码覆盖率，就会阻止交付给 Rational Team Concert 的代码，正如在 Rational Application Developer 中测量的那样。此扩展（现在名为 Code Coverage Advisor）已正式纳入 Rational Application Developer 中，在版本 8.0.3 之后都可以找到它。这意味着您现在可以配置 Rational Application Developer 和 IBM Rational Team Concert，在交付代码之前检查代码覆盖率。本文将介绍如何设置它，以及在项目开发期间如何使用它来提高代码覆盖率。
提示：
您需要了解一些 Rational Application Developer 知识才能理解本文。
后面的内容包含了三个主题：
1、何时适合使用 Code Coverage Advisor
2、当使用在 Rational Application Developer 中配置的此额外过程交付代码时会发生什么事
3、如何配置 Rational Team Concert 以使用 Advisor
最适合使用 Code Coverage Advisor 的情况
如何使用 advisor？以下是两个主要场景：
● 第一个场景针对的是新项目，出现在您想要确保单元测试提供足够的代码覆盖率时。在这种场景下，可使用 Advisor 帮助开发团队维护高标准的单元测试和代码覆盖率。
● 第二个场景针对的是您想要改进的具有糟糕的单元测试或不存在单元测试的项目。通过打开 Advisor，要求开发人员为他们修改的代码提供单元测试，这样这些团队可以一种简单、递增且可管理的方式进行改进。此外，这种方法意味着正在编写的单 元测试将包含正在修改的代码；因此，开发人员很可能会发现缺陷。
在这两种场景中，Code Coverage Advisor 可提供大量价值，通过帮助团队维护单元测试的高代码覆盖率来改进其代码质量。下一部分将介绍开发人员在已经配置了代码覆盖率功能时如何使用 Rational Application Developer 交付代码。
使用 Rational Application Developer 中的新流程交付代码
您需要做的第一件事是（如果还没有做）配置项目，以收集代码覆盖率信息。
配置项目的流程
1、在 Project Explorer 中右键单击项目，选择 Properties。
2、然后从菜单中选择 Code Coverage ，采用与设置团队相同的方式设置项目的代码覆盖率信息（参见图 1）。
图 1.项目代码覆盖率配置
使用启动的流程交付代码时会发生什么事
在配置了代码覆盖率后，Code Coverage Advisor 会检查文件的覆盖率，以确定是否交付了代码。Coverage Advisor 在下列情况下不支持交付代码：
● 覆盖率低于目标水平。
● 覆盖率过期了（例如，您已修改了其中一个文件，但没有重新运行测试）。
● 项目未启用代码覆盖率。
在这些情况下，需要开发人员在交付代码前提高覆盖率。但是，如果已大致配置了流程，并且人员具有必备的权限，那么开发人员可选择忽略警告并交付代码覆盖率不足的代码。
让我们看一个示例。在如图 2 所示的项目中，您可以看到，HelloWorld.java 类并不满足覆盖率要求。
图 2. Project Explorer 显示了失败的代码覆盖率
如果您尝试交付代码，交付将失败，您将得到如图 3 所示的流程建议：重写“Prohibit Unsatisfactory Code Coverage”先决条件。
图 3. 代码覆盖率交付失败
在 Rational Team Concert 中设置流程
在流程中存储信息意味着集中存储所必需的代码百分比阈值，并在团队中平等应用它们（尽管您可要针对不同组件配置不同的代码覆盖率要求，如后面所见）。您可以在本地客户端设置不同的覆盖率设置，但是当交付代码时将使用基于服务器的设置。
配置流程
提示：
在开始前，您需要具有修改 Project Area 的流程的相应角色。
1、从 Eclipse shell，导航到 Work Item 视图，打开 Team Artifacts 视图。
2、在想要配置的项目区域右键单击，并选择 Open。
3、然后单击 Process Configuration 选项卡打开流程编辑器（图 4）。
图 4. 流程配置编辑器
1、打开 Team Configuration 视图，选择 Deliver (client) 操作，然后选择 Everyone (default) 列下面的单元格，如图 5 所示。
图 5. 交付选项
将足够的代码覆盖率配置为先决条件
现在您准备好配置规则，然后可以检查每次有人交付代码时代码覆盖率是否足够。
1、添加一个先决条件来检查代码覆盖率：
a）在 Preconditions 部分单击 Add，选择 Prohibit Unsatisfactory Code Coverage（参见图 6）。
b）配置所需的各种代码覆盖率级别。
您可以在源代码的不同级别指定所需的覆盖率。例如，每个文件可能需要 70% 的行覆盖率；但是，开发人员对每种类型必须具有 100% 的覆盖率。您还可以正则表达式以将文件从覆盖率统计信息中排除，这在您具有一些自动生成的不在意覆盖率的代码时很有用。最后，不同的组件可以具有不同的规 则，方法是指定这些覆盖率设置应用的组件。
图 6. Prohibit Unsatisfactory Code Coverage 配置
2、现在保存流程，这些新规则会在您下次交付代码时生效。
前面有曰：测试结果的准确性取决于测试用例的设计，故测试用例设计显得尤为重要。今天就好好梳理下，测试用例的相关内容.
重要性：Test Case贯穿整个测试执行过程，分两大类：数值计算类和数据处理类
概述：编写一组前提条件，输入，执行条件，预期结果的组合方案。完成对某个特定需求或目标的测试，体现测试方案，方法，技术和策略的文档。
1、什么是测试用例，为什么要编写？
测试用例就是编写一组条件，输入，执行条件，预期结果的并完成对特定需求或目标的测试，体现测试方案，方法，技术和策略的文档。
由于测试用例是把整个测试的执行过程分解为若干测试步骤，并仔细的检查，验证所编写程序的正确性。它是软件测试的核心部件，是测试环节执行的基本依据。
2、主要包含哪些内容？需要哪些资料？
通常如下内容：
测试用例的编号
测试日期
测试设计人员和测试人员
测试用例的优先级
测试标题
测试目标的描述（描述它需要实现的功能，包括性能等）
测试环境的描述（eg：硬件条件，软件条件，网络条件等）
输入数据/动作的编写（具体的执行过程）
测试的步骤（测试数据具体的执行过程）
测试的预期结果
测试审查人员
资料：
软件需求说明书
软件设计说明书
软件测试需求说明书
成熟的测试用例（案例库或财富库）
3、有什么作用？
投入小，易积累，回报大。如何在最短时间内以最少的人和资源投入发现软件自身的缺陷，完成高效率测试并交出优质产品，是每个软件公司探求的目标。因此每 个项目都需要有一套完整，高效，优质的测试方案和测试方法，如果有了测试用例和测试用例库则可以预防部分或减少潜在风险的发生，另外，若公司事先要求编写 测试用例和建立相关测试用例库，测试人员发生流动时，对测试和项目进度的影响就会降到最低程度。
（1）实施测试指导的作用
在实施测试时一定要严格按照测试用例规定的用例项目和测试步骤逐一测试，并把测试中的各种情况记录下来（最好用测试管理软件）。以便书写测试结果文档（建议用测试管理软件自动生成）
注意：测试用例是指导测试人员进行测试，通过用例发现更多的缺陷，而不是限定测试人员的思维。
（2）指导测试数据规划的作用
测试用例数据一般都保存在数据库中， 只有进行测试用例设计时才从数据库中调出一组或若干组测试用例的数据和标准测试结果。eg：报表等一些对数据的正确性要求较高的测试，要事先对测试的数据 进行规划，报表横向，纵向多少内容。表输出的格式要求等，进行规划设计要做到事先有准备，测试操作时有案可查。除了这些标准数据，有时候还需要根据测试用 例设计大量边界值&越界值。
（3）指导脚本编写的作用
软件测试逐步走向人工测试和自动化测试并行发展。而自动化测试的核心就是测试脚本，自动化测试脚本编写的依据就是测试用例。
（4）作为评判基准的作用
测试工作完成后需要评估并进行定论，判断软件是否合格，然后出报告。以测试用例为依据进行评审。总结如下：
测试中检测到Bug数目
有效的Bug数目
无效的Bug数目
有争议的Bug数目等
（5）作为分析缺陷的基准的作用
测试目的就是发现Bug，测试结束后对得到的Bug进行复查，并对测试用例不断的补充，完善，最终交付给用户一个高质量的软件产品。
4、测试用例的设计流程，白盒测试用例的设计和目的？
一般流程包括：制定测试计划，编写测试用例，执行测试，跟踪测试缺陷，编写测试报告。
需注意：用例应该从系统最高级向最低级逐一展开，每个用例单独放在文档中，所有功能都应该对应到用例中，需依据需求进行设计。最好是有丰富经验的测试人员来设计。用例是多样化，复杂中简单化。
白盒测试设计方法：
逻辑覆盖：①判定覆盖②条件覆盖③判定/条件覆盖和多条件覆盖，逻辑值必须测试真，假两个分支，需要在边界值内和可操作范围内至少循环一次，并检查数据的内部结构，保证其有效的实现预定功能。
基本路径测试每个模块中的独立路径至少被执行一次
5、黑盒测试用例的设计和目的？
设计-等价类划分，边界值分析，错误推测，因果图
目的-检查功能是否实现或遗漏，交互界面是否出错，数据库读取，更新操作是否出错，性能和特性是否得到满足。
6、综合设计方法
实际操作设计测试用例一般“先黑后白”，即先采用黑盒技术设计测试用例，再用白盒技术做一些补充。
步骤：如果规格说明书中包含输入条件，则用因果图法设计；如果源码中遇到输入输出边界，则用边界值分析法；同时为输入和输出识别有效和无效等价类；使用错误推测法增加测试用例。
5点原则和注意项：
①测试用例的正确性
②测试用例的代表性
③测试结果的可判定性和可重现性
④足够详细，准确，清晰的步骤
⑤不能把测用例设计等同测试输入数据的设计
①务追求测试用例设计一步到位。
②勿将多个测试用例混在一个。
③用例中，最好不是无经验的人员设计测试用例。
7、测试用例设计需关注7大要点
（1）单元测试用例需注意
在一组单元模块设计完成后就开始的测试，单元测试以程序设计说明书为指导。测试模块范围内的主要控制路径，以揭露错误。重心放在代码审查，测试用例，测试特性，用例描述，测试总结上。后期我会对单元测试进行补充说明。
被测单元模块声明初始状态时，即此模块单元测试的开始。
正面测试：依据设计说明书设计用例，用等价划分设计用例
负面测试：错误猜测和边界值分析
覆盖率：分支覆盖/条件覆盖
（2）功能测试用例设计要点
首先考虑等价划分类，边界值共用，并用错误推测法补充；如果业务流程清晰可采用场景法设计；若程序有详细的因果关系，应该一开始就采用因果图法；如果是文件配置类型的测试，考虑功能图法
（3）集成测试用例设计要点
按详细设计说明书来设计，测试用例数据来源于UC，内部逻辑结构分析按单元测试进行。
（4）性能测试用例，需要不断的迭代完善的过程，一个完整的性能测试通常包括：预期指标性能测试，独立业务性能测试，组合业务性能测试，疲劳强度性能测试，大数据量性能测试，网络性能测试，服务器（操作系统，Web服务器，数据库服务器）性能测试，一些特殊的测试。
预期性能测试用例依据需求和设计文档明确的性能要求进行设计；
独立业务性能从单个模块功能和性能要求出发设计；
组合业务性能从需求，设计文档，现场调查，系统采集数据方面进行用例设计；
疲劳强度性能测试需要编写不同参数或者负载条件下设计测试用例；
大量数据性能需考虑数据处理能力，用边界值分析法设计用例；
网络性能测试使用工具调整网络设置；
服务器测试一定要和前面的测试结合起来进行。
（5）系统测试用例根据需求分析来检验软件是否满足功能，行为，性能，系统协调性等方面的要求。
使用的数据应具有代表性，并与真实数据的大小和复杂性相当
（6）验收测试用例设计
应该在研发阶段测试用例基础上重新编写，而不能直接拿来使用；需与客户需求相对应，面向客户；把握客户的关注点并适当展示软件的独特性。
（7）回归测试用例设计要点
不需要重复设计，只需选择以前的测试用例，针对最重要或最频繁使用的功能测试用例。
综上描述需要结合实际工作运用实践，精益求精。赶快行动吧~
测试人员不是在开发人员代码实现后才开始介入一个项目的，而是在一个项目开始立项后就开始介入，这个已经是个不争的问题了。那么，测试在项目的早期可以做哪些工作呢？测试前移是个很大的话题，本文只讨论一下需求阶段测试人员如何介入？以下所讨论的测试可以做的具体事情，无论是在V模型下还是在敏捷模式下都适用，只不过在不同的上下文中，这些事情做的程度和方式有所不同。
首先，需求阶段如何定义？比较完整的需求阶段至少包括两个部分：一是初始包需求（OR－Offered Requirement）确定阶段，这个阶段的参与人员会直接和市场、用服、客户沟通交流、调研，确定产品开发的初始需求；二是初始需求交给研发团队，系统工程师进一步分析，结合产品原有基础、收集内外部需求，得出产品要实现的包需求，并采用系统分析的工程方法开展对包需求的深入分析，得出更细化的需求描述，输出可以被实现的设计需求，交给软件实现人员。如果按照CMM流程，前面一个阶段CMM貌似涉及 不多，对应Charter之前的工作；后面一个阶段对应TR2之前的工作。
一般而言测试的前期介入大多指介入后面一个阶段，其实前面一个阶段测试也应该参与，当然，参与前面一个更早的需求分析阶段，对测试人员的要求会更高一些，需要对系统层面有较好的把握。
（1）测试参与早期需求分析
这个阶段收集到的需求都是比较粗的，测试更多的可以从系统验证的角度考虑问题，即这些粗的需求如果实现后，后期交给客户时，是否可验收，有哪些验收场景、验收的思路是什么、具体的商用使用场景、需求验收是否需要特殊的验证平台、有哪些验收难点等等。可以输出《需求验收分析报告》。这样做的好处，一是测试人员通过早期参与，更清楚需求的来源和目的，有利于后期更好的从用户的角度开展测试活动；二是可以为后期设计验收测试用例提供很好的分析依据。
如果您在这个阶段的测试介入有很多实践经验的话，欢迎回复本文分享！
（2）测试参与TR2之前的需求分析
这个阶段的需求仍然比较粗，至少开发人员拿到这些OR直接去实现难度还是很大的。系统工程师会从全系统的层面开展稍微细一些的需求分析，得到具体的设计需求，其主要的思路主要是针对每个OR开展场景分析，测试介入的主要工作就是重点参与场景分析工作，因为开发的SE和测试的TSE分析问题的思路是不同的，可以做到很好的互补，所以理想的方式是SE和TSE一起完成场景分析工作：SE偏向从功能、实现的角度分析，TSE更多的考虑非功能属性方面，比如可靠性、可测试性等，还会考虑用户分类、异常场景、组网的不同等，这样二者合作的结果，使得设计需求更易于实现，也一定程度消弱了需求由于分析不充分导致后期的频繁变更的问题。在敏捷项目中，测试参与的结果经常以“验收条件（Acceptance Test Conditions）”的形式体现在需求文档中，每一条需求都对应其验收条件。
另外，这个阶段测试还应该发挥测试的优势，提出产品的可测试性需求，以便开发在实现阶段就考虑进去。
当然，除了上面提到的以外，测试在早期的任何时候都可以针对开发的各种分析输出件给予很好的评审检视，缺陷越早暴露成本越低。测试在需求阶段参与的更大的意义在于实施preventive testing，这与简单的文档review是不一样的，preventive testing强调的是测试人员用他的测试知识/领域知识去challenge需求和设计，去提前验证他的idea，去explore需求，可见，探索性测试的思想完全可以在需求阶段应用。
此外，Richard Bender所提的基于需求的测试（ReqBT）也是一套可行的方案，在需求写作初稿阶段，ReqBT人员与需求分析人员并行交错开展工作，一点点地完成需求的模糊度分析、需求的业务逻辑分析、需求的建模以及测试条件生成等工作。
测试在需求阶段还可以做哪些，欢迎各位补充！
为了更好地服务于客户和规避操作风险，软件测试工作近年来越来越受到重视。尽管软件测试的作用与传统工业的产品质量检验目标一致，但软件测试理论自上世纪60年代以来，在整个IT技术中发展相对缓慢，软件测试工具尽管在管理能力、易用性方面有了很大提高，在实际应用中仍旧不能从根本上提高软件测试生产率。
在对软件测试的要求和期望越来越高，而软件测试的方法和工具没有长足发展的情况下，全面提升测试团队和测试人员的能力，就成为了进行有效测试并尽可能提高测试效率的重要基础。
一、 关于能力的浅析
测试团队的能力由个人能力和团队能力两个方面构成，两者相辅相成。为了有效提高能力，首先对个人能力和团队能力进行一些浅显的分析。
（一） 个人能力
1、个人能力的概念
中国大百科全书《心理学分册》说能力是“作为掌握和运用知识技能的条件并决定活动效率的一种个性心理特征”，通俗地说，我们可以认为个人能力是达到优异绩效所需的知识、技能和素质的组合，这里的素质包含了大百科全书所说的个性心理特征，是比较难以量化衡量的。
2、个人能力的培养现状浅析
（1）对知识的培训
对软件测试工作来说，所需专业知识可分为基础工作知识和专门工作知识两类。基础工作知识包括软件测试的基本技术和方法，软件测试的文档规范等在专业内通用的知识，一般可使用专门教材进行培训。这些培训可以由内部专家完成，也可以由外部专家完成；相对来说，也比较好客观地衡量学习的成果。
专门工作知识是在更小的范围内适用、在特定的时间适用的知识，很多知识往往是处于经验的积累阶段，且具有时效性。例如对于开发中的应用系统的认识和了解，在目前业界文档编制、评审和版本管理的状况下，一般只能通过“师傅带进门，修行在个人”的方法进行培训。在这样的情况下，如果测试人员有比较深厚的IT和业务经验，将缩短专门工作知识培训的周期，提高培训的效率。如果测试人员是新学生，则培训的难度较大。
（2）对技能的培训
技能在很多场合也被称为“动手能力”，对于软件测试来说，技能的培训也很复杂。对于原来具有业务背景和软件开发、维护背景的人员来说，在软件测试工作中，肯定会优先使用已经掌握的技能，这样能够使得测试工作比较快地上手。了解业务、了解技术实际上是对被测对象不同角度的了解，是软件测试技能的重要组成部分，只有结合了专业的软件测试技能，才能够实现全面、协调、可持续的软件测试效果。仅仅从技术和业务角度进行测试，则往往在测试的彻底性、测试的效率和回归测试等等方面难以达到银行业软件测试发展的要求。
根据目前我国IT人员和金融财会人员学历教育情况，本科生的技能与银行业软件测试的实际需要相比较薄弱，研究生在学历教育期间会有不同程度的培训，但是由于我国银行IT系统及其使用状况的复杂与庞大，学生较少有机会在类似的环境中接受相应技能的培训。
以往对技能的培训，往往与专业工作知识培训采取相同的做法，在很多情况下，专业工作知识与技能的培训是交织在一起的。实际上，很多人是通过自己的领悟了解到了工作的方法，但也形成了对于技能只能意会、不能言传的状况。
（3）对素质的培训
素质可以通过多个方面来展现，例如演绎思维、归纳思维、进取精神、人才培养意识和能力、灵活性、主动性、人际理解能力、人际影响能力、合作能力等，归根到底，就是一个人的世界观、价值观和处事哲学、基本习惯在各个方面的展现。实际上，素质对于高质量地完成软件测试工作，往往比知识和技能占据了更重要的位置。
素质的培训不是一朝一夕的事情，但是针对素质进行培训却是十分重要的事情。目前从中学开始，就开设有素质教育方面的课程，但基本属于知识传授的范畴。一个人素质的发展，与其成长环境的文化和个人经历有着很大的关系。鉴于软件测试工作往往是在不确定标准的情况下进行检验，而软件产品又有着艺术与技术结合的特点，所以，要作好软件测试工作，不论是新员工还是老员工，不论是测试的操作人员还是管理人员，都有必要不断地提升自己的素质。
（二） 团队的能力
团队能力有多种描述方法，一种通俗的说法是，团队能力是指团队所有员工的能力整合所形成的能力。团队能力的构成来自于三方面，员工能不能做；员工想不想做；以及这个团队的整体架构、流程、规划，让他们是不是容易做到。
团队能力不是个人能力的简单叠加，而是与个人能力互相影响，相辅相成。团队在知识、技能和素质导向方面的积累，会对团队能力产生巨大的影响。这种积累是必然发生的，而且是不断持续的。对这种积累的过程进行正确地引导和有计划地部署与实施，将对打造学习型组织，快速提高团队能力有着十分积极的作用。团队能力应与个人能力相互强化，即个人能力的一个方面就是对团队能力的高效应用，而团队能力的一个方面就是使得个人能力得到高效发挥。
对于银行业的软件测试团队来说，目前各行都在快速发展的初期，是团队能力正在快速地形成和升华的过程。建立优秀的企业文化，建立软件测试资产库，都将对团队能力形成发挥产生巨大的影响。
二、提高能力的几点浅见
能力的提高过程既是人才培养的过程，也是团队不断成长的过程。尽管在不专门关注的情况下，个人能力和团队能力也会不断地成长和提高，但是有可能出现弯路，也有可能出现与使命、目标不符的情况。为此，建议应该从如下几个方面注重能力的提高。
（一）各级经理人以身作则
不论软件测试团队分为几级管理架构，处于管理架构不同层面的管理人员，不仅都要高度重视能力的培训，更要以身作则，引导培训的方向。任何一级经理人不重视能力培训，都会导致能力培训不能落到实处。
能力培训要得到各级经理人的重视，首先要解决两个方面的问题，一是理念问题，破除“教会了徒弟，饿死了师傅”的陈旧观念，代之以德鲁克提出的“没有任何一个能干的下属会伤害上司”的观念，使得对能力培训的安排由被动变为主动；二是资源问题，能力培训不仅仅是理论教学，更重要的是真正的实践。在这些学习和实践过程中，既需要人力、环境、知识等资源，也更需要时间。如果各级经理人在制定工作计划时未能考虑到培训所需要的资源因素，则会形成即使有培训的意愿也难以实施的格局。
因为团队能力在其建设和发展的过程中，需要投入资源更大，且会对各级经理人的工作模式产生影响，所以更需要引起各级、尤其是高级经理人的关注。要使团队能力与个人能力能够结合产生增益效应，就要在团队能力的建设过程和个人能力的培养过程中，妥善处理好相互的关系，使得团队能力成为个人能力依托的基础，而个人能力的一个方面就是发挥团队能力。
（二）进行学习能力分析
按照德鲁克的分析，人在学习方面分为四种类型，即听、说、读、写型。这四种类型并不是绝对的，往往是四种方式兼用，但是在不同的方式下获取的信息权重和信息量不一样。例如阅读型学习的人，也可能会以倾听作为第二信息获取的手段，以写（例如学习笔记）作为第三学习手段；而比较特别的写作型，则只有在写作的过程中，才能对以前通过阅读或者倾听获得的信息产生真正的理解，进而产生了深入了解相关信息的欲望。
另一方面，每个人能够集中精力专注于某项事情的时间是不一样的，对于超过专注时间的内容，则往往表现为听不进，即走神；是否容易造成走神，与需要专注的内容、表达方式等还有很大的关系。对于知识的记忆，尽管一般来说符合艾宾浩斯曲线，但每个人也有着相当的差异。
要在个人能力培训方面获得较好的收益，应进行学习能力培训的试点。投入适当的人力资源，确定可能实现的工作目标，进行学习能力的分析指标、分析方法、工作目标、培训方法等等方面的研究和探索，并通过对知识和技能的考核来确定培训的成果。
（三）建立测试资产库
测试团队能力应具有全面、协调和可持续发展的特征，要做到这一点，建立测试资产库，逐步实现测试人员工作过程利用资产库，工作成果丰富资产库，是十分有效的一种方法。
测试资产库具有指导工作如何进行和可复用两大特点。资深员工的一项重要工作，就是对资产库的更新、维护和推广；即使需要他们进行一线测试工作，他们也应考虑到所进行的工作入库的可能性和价值。这其实也是衡量一个员工是否具有资深资格的重要方面。
很多标准化、规范化的工作，都可以与资产库的建设、维护过程结合起来进行。在资产库的建设上，以结构化的内容为主，以非结构化的内容为辅。这样，标准化的规范化的工作也易于落到实处。
建立资产库是一个复杂的、持续的、不断调整的过程，对资产库的内容来源、资产库的组织方法、资产库的实现工具、资产库可能发挥的作用和应用资产库的培训，不同的测试团队应结合自身的情况进行积极的探索。
（四）注重素质的培训
素质的决定性因素，其实是一个人的世界观和价值观。树立和改造世界观、价值观不是一件容易的事情，但是在积极的思想引导下，逐步地改变习惯却是可能的，并且会对素质的提升带来显著的影响。史蒂芬.柯维所著的《高效能人士的七个习惯》就是在这方面的一部影响十分广泛的著作。柯维讲述的“积极心态、目标明确、要事第一、双赢思维、知彼解己、统合增效、不断更新”七个习惯，既包括了对自己的高效工作、生活的习惯，也包括了妥善处理人际关系的习惯，并被中国软件评测中心列为了软件测试人员应具有的素质。对于测试的各级管理者，应加强对将科学发展观以及党的思想路线落实到工作中的学习，并应学习德鲁克等现代管理理论，针对知识工作者的特点，进行有效管理。
（五）细分测试岗位所需的个人知识与技能
根据被测对象的不同，软件测试人员所需要的知识和技能也不同。在前面的分析的基础上，应针对不同的测试对象、考虑到实际的测试流程，将测试人员分为不同的知识技能组，对测试人员所需的知识和技能进行分级分类，以便能够更好地深入了解被测对象支撑的业务和所采用的技术，确定测试人员使用资产库的最低阈值，使得个人能力和团队能力真正实现相得益彰。
如果问100个软件公司的CEO，问他们是否愿意发布含有bug的软件。他们会说什么？50个根本不愿意回答，会说一些软件bug是这个行业中一个需要解决的大问题等不着边的话；40个会说“当然不会！”，并立即给他们的投资者打电话说这是诬陷，会追究法律责任。9位会低着头说“无能为力”。而这最后一位会直盯着你的眼睛说“当然会。”
我不知道这最后一位是如何领导一个软件公司的，因为他明显学过经济学。
软件不可能没有bug，如果你希望发布一个完美的软件，你必须解决藏在代码里的所有bug。（想把它们挡在门外？不可能，单元测试，敏捷方法，scrum，以及任何当今你能想到的方法论，都不能防止bug进入你的代码库。如果我错了，我相信你会在评论里告诉我。）
正如你期望的，你在修补bug中投入越多的时间和资金，你就能解决越多的bug。但是，不幸的是，我们的来自经济学的死对头，受益递减法则，同样适用于这个过程。专业的讲，这个法则指在投入生产要素后，每单位生产要素所能提供的产量增加发生递减的现象。用通俗的话讲，这就是说，你能从这个过程中得到的并不等同于你所有投入的。相反，你的产出会随着投入到增加形成一条迅速下降的曲线，曲线的末端、投入到轴线上，最终成为一条长尾。
举个例子，假如一个程序有100个bug，我们知道这需要投入100分的努力来找到并修复这所有100个bug。受益递减法则告诉我们，头40分努力将会找到70个bug，而接下来的30分努力能找到20个bug，剩下的30分努力能找到最后的10个bug。这就是说，头70个bug（很简单的bug）很便宜，容易找到，算起来每个bug只消耗40/70=0.571分努力。接下来的20个bug（藏的较深的bug）要昂贵的多，每个消耗30/20=1.5分努力，而最后的10个bug（真正难发现的bug）惊人的昂贵，每个消耗30/10=3分努力。消灭这最后的10个bug要比消灭起初的70个bug，每个bug需要投入的时间或资金要多出5倍。从付出的努力看，消灭大多数bug（70%-90%）和消灭所有bug，它们的成本有巨大差别，从数字上看相差两倍之多。
而在现实中，实际情况比这更糟糕。因为你不知道何时能干掉这最后一个bug---没有一个像上面例子那样的倒计数——你不得不不断的去寻找更多的bug，即使是它们已经全部被干掉了，你也要去证明它们确是全部被干掉了。如果你想消灭所有的bug，你还要计算你的成本。
所以，消灭一个程序中所有的bug是一件代价很大的事。不妨让我们花一分钟这样思考一下：一个软件公司最终决定要这么做。软件公司并没有设定像“发布没有bug的软件”的目标——他们设定的目标是“11月19号发布”——于是，这个目标改变了公司的测试计划和开发计划（不论有没有计划），这必然意味着的预算的增加。现在，你想象一下，谁会为这多出的预算买单？公司？（嗨！）如果你没有在软件公司工作过，让我来给你一点提示：非也。软件公司会把成本转嫁到客户身上。因此可以得出，你喜欢的软件都是你支付的起的软件。我得到的消息是：你喜欢有bug的软件。（开源软件也是如此。除非你愿意花更多的钱或等更长的时间。很有可能你会接受去忍受次等的软件事实。）
现在澄清一下，我并不是说软件公司应该发布有大量严重bug的软件。我是说他们的软件里可以有少量的小bug。
如何知道一个bug是大还是小？你应该思考谁会遇到它，当遇到时会发生什么样的坏情况。如果一个用户，进入第三层菜单，打开一个高级配置窗口，选中三个复选框，在敲击“A”键时得到了一个奇怪的错误信息，这是小bug。它埋的很深，当碰到它时人们会说“靠”，然后改为点击按钮，然后就会愉快的做其它事情去了。如果在使用你的程序中一个常用的操作时崩溃，那这就是个大bug。大部分人遇到这样的bug时都会愤怒不已。
所以，我要提出一个判断你的软件何时满足发布条件的黄金法则。这个黄金法则内容是，你应该不断的测试并修复软件中的bug，直到发现这些bug是：
不会让你的公司蒙羞。
不会激怒你的客户。
相比起让一些用户遇到这些并不在于的bug的代价，你的要找出程序中所有bug并确保全部纠正的做法代价实在太高。前提条件是，不要让用户做你的测试员——如果你这样做，必定会跟黄金法则冲突——宁愿相信所有的bug并非生来平等，有些能影响一个产品的发布，而另一些则不然。不要害怕发布的产品中有bug。如果你开发的是人们想要的好软件，一些bug的存在并不会打搅他们，尤其是当软件升级操作简便时，比如通过SaaS或Web应用。
如果你的软件测试符合黄金法则，那么，你的客户最迫切得到的是你的软件，而不是希望你去修改那些小bug。所以，准备发布吧！
哦，别忘了去问那最后一个CEO关于炒股的技巧。经济学家的公文包里总有最好的数据。
性能测试种类的划分与定义这里就不说了，各有各的说法，比如性能测试、负载测试、压力测试这三个词，在网上能找到N个版本的定义，大体理解就行了，没必要在文字层面上较这个真。以下的内容也只是我个人的理解，一些名词的定义可能和其他资料有所不同，但在我的工作中，这样是比较形象和容易理解的。
性能测试的目的，简单说其实就是为了获取待测系统的响应时间、吞吐量、稳定性、容量等信息。而发现一些具体的性能相关的缺陷（如内存溢出、并发处理等问题），我认为只是一种附加结果。从更高的层次来说，性能测试最想发现的，是瓶颈。
在实际工作，一般的应用系统会从这么几个方面进行性能测试。
1、基准测试
Benchmark或者Baseline测试。一般为单用户测试，或者是零数据量环境下的测试。目的在于建立一个可度量的参考标准，为其他测试场景或者调优过程提供对比参考。也可认为是最基础的性能测试，如果基准测试的结果都不能达到预期要求，那么后续场景也就没必要测试了。
2、日常压力测试
在基准测试通过后，应该先进行较小压力下的测试，首先对系统在日常压力下的表现进行测试。此压力需要根据系统使用相关数据得出，如系统平均每天访问量、平均在线人数、每日完成事务数等。通过此测试，发现一些较表面的性能问题并进行处理。
3、峰值压力测试
在日常压力测试通过后，需要进行更大压力的测试。此处压力同样需要相关数据的支持，一般为未来几年后的预期压力。可根据历史日均压力、日最高压力等信息，估算出未来几年的日均以及日最高压力。再通过一些通用估算方法、如二八原则（80%的工作在20%时间内完成，相当于2小时完成一天8小时的工作量），将日压力转换成峰值压力。
峰值压力为可预期到的最大负载压力，通过了此测试，则认为系统有能力满足未来增长的压力。
4、容量测试
验证了系统是否可满足预期的压力后，还需要知道系统能够承受的最大压力，也就是容量。一般通过“拐点法”进行测试，逐步增大系统的压力，直到性能指标不可接受或者出现了明显的拐点。如图：
5、稳定性测试
验证系统是否可长期稳定的运行，是否存在一些短时间内可能无法发现的缺陷（如内存溢出、数据库连接不释放等）。为了缩短测试工期，一般可将预期一天的压力集中在2小时内完成（二八原则），这样持续加压10小时，便相当于系统运行5天。注意监控各种性能指标是否平稳，有无下降。
以上几种类型的测试，是性能测试过程中最多用到的。当然也也其他一些比较常用的类型，如绝对并发测试，测试多用户对某一功能的瞬时请求，主要用于验证系统是否存在并发逻辑上的处理问题。此测试也可划分到不同的压力测试场景中去，根据不同的用户压力，测试相应的绝对并发，一般取在线用户数的10%进行测试；突发压力测试，对一些不在预期内的突然压力进行测试（其实既然想到了，就应该是在预期内了）。以银行门户网站为例，可能会由于发布了一条重要消息（政策调整）而导致访问量激增，这种压力是否会导致系统宕机或者暂时无法提供服务，就是突发压力测试需要考虑的了。也有人将此压力定义为峰值压力，这就无所谓了，只要考虑到会有这么一个问题就够了。