主题：如何书写测试报告 领导们通常是很关注测试的，因为通常只有测试团队才能够提供项目所处的真正位置。这种位置感来源于模块的成熟度、稳定度和主要问题列表。这种信息，我们叫它项目的可视性信息。可视性信息可以分为两类：
1）对内的信息汇总，以测试日志为典型，记录每个测试工程师一天的进度、发现和困难，上报给测试经理；
2）对外的信息发布，以测试报告为典型。测试经理汇总测试的数据和信息，作为项目进度和状态的重要标识上报给项目管理者。
一、测试日志（Test Log）
测试日志是帮助测试经理获取测试信息的重要途径，它的发布者是测试团队中的每一个成员，测试日志的读者是测试经理，而在规模大一些的测试团队中，可能是测试小组的组长。测试日志的使命是让测试经理了解自己团队的状况。
二、测试报告（Test Report）——言简意赅、图文并茂
测试报告写作的七大原则：
（1）字数要够少够精炼
用最少的篇幅和最简单的结构同时传达出所有的关键信息，这才是测试报告应该做的事。
1、首先要减少说废话套话，和测试无关的语言越少越好；
2、其次要避免过于细节，在报告后面可以尽情地添加附件来提供详细的信息，给求知欲强的人留有进一步专研的空间；
3、最后，信息要分层派送，比如封面上三句话说出你最想说的心里话，中间的内容把这三点展开来说，最后的封底处作出你作为测试人员对待测软件的评价和结论。
（2）图表要够多够通俗
1、饼图比大小（软件遗留问题模块分布）
2、柱图比高矮（各测试组发现问题个数）
3、曲线图上蹿下跳（软件稳定度的变化，问题解决率的变化，测试用例通过率的变化）
4、面积图比胖瘦（遗留问题的解决趋势）
5、图表要用的正确才有效
项目管理者关注的大部分东西都有合适的图表来表示：
1、总体成熟度和子模块的成熟度：成熟度的计算方式有很多，其中最简单的是统计测试用例的通过率，我们在上面讲曲线图的时候有例子。
2、缺陷分布：各种模块内遗留的问题数目及其比例，能帮助读者大略了解各个模块的稳定程度，饼图就是个很好的例子。
3、缺陷趋势：成熟度的变化趋势，从中可以看出软件质量的走向，也是那个曲线图的例子。
4、问题解决趋势，这是个很有用的关注点，从中可以看出问题解决的速度和趋势。当问题解决的速度下降的时候，能够及时向管理层报警提起重视，面积图的例子讲的就是这方面的东西。
图表能够标出各测试组或测试工程师的效率和进度，以便及时发现暗藏的问题，避免进度受影响；图表还能显示出各模块问题数和测试用例通过率的关系。
（3）颜色鲜艳，通俗易懂
绿色代表一切正常，红色代表糟糕，黄色代表不好说。在测试报告中用绿色表示稳定的模块，红色表示有问题的模块。
（4）既报喜又报忧，汇总出最严重的问题
在测试报告中列出未解决的TOP10严重故障。评审的对象之一就是剩余的严重问题都有哪些，以及产品带着这些问题上市的风险有多大，测试人员公正和客观的评价将是一个重要的参考。
（5）报告时间要及时
测试报告是为了让项目的管理者在第一时间了解项目的状态，因此报告的时间不能拖拖拉拉，新闻变成了旧闻就不值钱了。根据报告的重要程度和所做测试量的大小，测试报告准备的时间也应当不一样。
（6）罗列的数据准确有力
测试关注质量，但如果测试本身的质量无法保证，那测试还不如不做。测试内部需要建立抽查机制：
1、抽查应该成为一种持续的压力，不能搞献礼工程；
2、抽查的比例要事先约定，根据是抽查的工作量和可投入的人力等；
3、执行抽查的人必须有经验或者够权威，否则抽查出问题以后必将导致无休止的争论。
4、参考以往的趋势（比如：测试用例通过率变化明显部分抽查）
（7）逻辑要经得起推敲
测试报告中要做出很多结论，要注意结论的逻辑必须经得起推敲，做出的结论要有说服力。
版权声明：本文出自 hellorenwei 的51Testing软件测试博客：http://www.51testing.com/?578951
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
《笑傲测试》笔记（前言+第一式：庐山面目）
《笑傲测试》笔记（第二式：蓬门始开）
《笑傲测试》笔记（第四式：矫如龙翔）
《笑傲测试》笔记（第五式：浮云遮日）
《笑傲测试》笔记（第六式：伯仲伊吕）
单元测试是高效的开发过程质量控制机制，帮助企业保证产品质量、降低成本、提高生产率、缩短开发周期、赢得市场先机，提升竞争力。
1、保证代码质量
仅依靠系统测试会 存在大量未覆盖的“死角”，单元测试可以对各个代码单元彻底测试，保证代码质量。针对一个函数，单元测试可以覆盖输入数据的所有分类，做到不管输入什么数 据，函数本身的处理都符合设计，从而全面检测其功能逻辑，消灭可能隐藏的大量细小错误，这种测试效果是其他测试难于做到的。输入数据的“分类”，称为“等 价类”，即测试效果上的等价，同类数据中只需要测试一个，就相当于测试了同类中的所有数据。这种设计用例的方法就叫做“等价类法”。
2、降低排错成本
排错包括“验证是否有错”、“找出错在哪里”、“修正错误”三个工作。单元测试的目标最小，涉及代码最少，发现错误后排错最容易。Bug发 现得越晚，修改所需费用就越高，因此应该尽早查找和修改Bug，单元测试提供了尽早抓住Bug的最好机会。相比后续阶段的测试，单元测试的创建更简单，维 护更容易，并且可以更方便地进行重复。从全程费用来考虑，相比复杂且旷日持久的集成测试、系统测试，单元测试所需的费用是很低的。下图摘 自<<实用软件度量>>（Capers Jones， McGraw-Hill 1991），它列出了准备测试、执行测试、和修改缺陷所花费的时间（以一个功能点为基准），这些数据显示单元测试的成本效率大约是集成测试的两倍，系统测 试的三倍。
3、自动回归
自动回归测试可以避免小量修改导致大量系统级调试与测试。“回归”是指代码修改后回复到原来的正确状态。例如，一个函数本来工作正常，后来发现少了个功 能点，修改代码后，原有功能可能被破坏，回归测试就是检验原来的功能是否仍然正常。代码之间具有复杂的依赖关系，一个函数的修改，可能引起其他代码产生错 误，回归测试不仅针对被修改的代码单元，也针对其他相关代码。单元测试目标最小、结果明确、执行快捷，最容易实现自动化回归测试。
单元测试将代码功能“定格”，代码修改后可以自动检查是否引入新的错误，避免陷入“系统测试->修改->引入新的错误->新一轮系统测试->修改->引入新的错误”的怪圈。自动回归也使开发过程适应频繁变更的需求，使开发过程趋于“敏捷”。
4、促进开发
如果边开发边测试，那么，单元测试的结果可以完整地描述程序的行为，如下图。程序行为就是在什么输入下，会执行哪些代码，会产生什么输出。写代码时能随 时察看程序行为，就比较容易想明白思路对不对，接下来应该怎么写。刚写的代码有没有错误也随时可以发现，不但效率高得多，也没那么累。
只要做了单元测试，反映程序行为的数据就一定会存在，只要使用工具将这些数据捕获并显示出来，就可以一边编程一边察看程序行为。
编程时，程序员一定需要考虑清楚代码的功能，包括会有哪些输入，如何处理，应该产生什么结果，列出来就是测试数据了，因此，并不需要多少额外的时间来设 计测试数据，同时编写效率会显著提高，并且基本上不需要调试。调试是最花时间的。如果结合自动化的测试工具，让设计测试数据以外的工作（如编写测试代码、 隔离测试任务、底层模拟、统计覆盖率等等）由工具完成，那么，在开发的过程中进行单元测试，开发和测试同步完成，所用的时间一般比传统方式更短，代码单元 功能越复杂，节约的时间越多。
我们初学C语言时，通常会编写一些小算法，并通过控制台输出结果进行测试。这 是一种高效的编程方式，因为第一时间可以了解代码是否工作正常，随时调整思路。但在实际项目中，这种方式不再现实，正在编写的代码单元很难单独运行并观察 其行为。单元测试可以帮助我们重返“小算法编程”，让代码单元随时独立运行，减少麻烦的调试，缩短编码周期。
随着信息化的全面实施，软件业正迅速发展，软件的应用已渗透到各行各业，软件质量也越来越受到关注，本文将结合全面
质量管理思想，谈谈软件质量保障交付阶段的安全锁—软件
验收测试。
如同任何产品离不开质量检验一样，软件验收测试是在软件投入运行前，对软件需求分析、设计规格说明和编码实现的最终审定，在软件生存期中占据着非常突出的重要位置。正如山东省软件评测中心韩庆良主任所说：“验收测试，让软件隐形质量可视化。”
软件验收测试概念：软件验收测试，让系统用户决定是否接收系统，是一项确定产品是否能够满足合同或用户所规定需求的测试，这是管理性和防御性控制的重要步骤。
软件验收测试前提：已通过了系统测试的软件系统。
软件验收测试完成标准：无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面（例 如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。 软件验收测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目 进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。 具体标准如下：
1、完全执行了软件验收测试计划中的每个测试用例。
2、在软件验收测试中发现的错误已经得到修改并且通过了测试，或者经过评估留待下一版本中修改。
3、完成软件验收测试报告。
注意事项：
1、必须编写正式的、单独的验收测试报告；
2、验收测试必须在实际用户运行环境中进行；
3、由用户和测试部门共同执行。如公司自开发产品，应由测试人员，产品设计部门，市场部门等共同进行。
版权声明：本文出自山东省软件评测中心 张凯丽，51Testing软件测试网原创出品，未经明确的书面许可，任何人或单位不得对本文进行复制、转载或镜像，否则将追究法律责任。
http://www.51testing.com
主题：如何制定测试计划 在测试阶段，测试经理要综合考虑以下影响测试的因素并完美地协调其中各个要素的关系，只有这样做才能避免在测试过程中出现种种意外并影响测试的质量：
测试组建立、测试范围的选择、测试组的培训、测试平台的选择和配置、测试技术和工具的选择、测试执行的日程和进度、测试用例的设计、维护和更新、测试环境的设计和搭建、测试文档的格式和提交时间、测试入口/出口的checklist、测试组成员的管理和激励机制、测试过程的流程和定义、测试过程的质量监控。
一、测试团队的建立和组织
测试团队按照职能可分为四类组织：
1）测试设计和执行组，这类组织奖占有大部分的测试人力资源，负责测试的设计和执行。
2）技术支持组，测试中有两种时候会用到特别的技术支持，一是测试工作平台，包括测试用的各类数据库，其维护和支持需要有专门技能的人负责；二是测试环境，测试环境随测试对象的不同而大相近庭。
3）问题管理组，这些人的职责是处理和跟踪测试中发现的问题，以保证所有发现的问题，在正确的时间，由正确的人，在正确的软件基线上做正确的解决，最后由测试人员在正确的版本上做正确的验证。
4）质量监控组，负责监控测试本身的质量，以保证测试能够有效和有序的执行。
二、测试范围的选择
三、测试团队的培训
培训分两类，技术类和流程类。
技术类培训专注于测试中将遇到的技术问题，比如待测产品的技术、设计和方案的培训，测试工具的使用培训等（QA在每次培训前都宣布要针对培训的内容进行考核，有力减少培训中缺席、早退、打瞌睡等现象）；
流程类培训是告诉大家如何按照事先约定的方式去工作（每一个测试活动都有相应的流程指导书，里面会对具体的行为做具体的规定）。
四、测试平台的选择和配置
测试团队不借助任何平台的结果：
1）成千上万的测试用例无法有效管理，测试开始之初无从知道哪些测试用例对此项目是有用的，这将在很大程度上增加测试准备期的工作量。而且对于不同的软件版本进行不同的测试覆盖选择时也会极不方便。
2）测试人员在测试过程中需要为每个测试用例填写测试结果，但通常测试经理的苦恼在于：如果没有工具有效管理这种行为，那么对于测试的进度无法有效地了解，测试当时的状况，如测试用例的通过率，可执行率等数据都很难实时地得到。
3）测试中必然会发现问题，问题管理也是一大繁琐的问题，这涉及一个工作流程的问题。
测试计划阶段需要明确我们即将采用何种测试平台工具来实施测试，在此之后还有一系列的安装、配置、培训和维护等诸多方面的问题需要关注。
测试平台主要包括：测试用例数据库、测试计划数据库、测试报告数据库、问题跟踪数据库。
五、测试技术和工具的选择
测试从技术角度上有多种分类，其实如何分类并不重要，重要的是在某一测试项目中如何筛选适合本项目的技术手段才是最实际的问题。测试中并不是最有技术含量、最有吸引力的手段就一定是最适合的。
测试计划阶段中需要做的是：了解自己的项目需要什么测试。了解每种测试技术适合的范围。之后得出结论：在本测试项目中，哪种测试技术是最有效的，以及针对这种测试技术需要做出哪些资源和人力方面的准备。
六、测试执行的日程和进度 测试经理需要明确清楚地回答这几个问题：什么时间，在什么版本上，出于什么目的，做哪些和测试相关的活动。
通常的经验，对于软件测试项目来讲，测试要进行至少四轮才有意义。
1）第一轮，验证功能，提交发现的问题；
2）第二轮，验证提交的问题是否被修改，同时看是否在修改后引入了新问题；
3）第三轮，验证性能，假定前两轮测试后那些低级的功能性的错误已经被消灭的差不多了，这时需要创造一些恶劣的环境，来验证软件是否足够强壮；
4）第四轮，全面验证软件的全部待测点，并根据本次测试的结果评估产品上市的风险。
并不是所有的问题都是在测试开始第一轮就可以被全部发现，原因有几个方面：
1）测试人员在第一轮可能尚未进入状态，对待测产品的熟悉还有待提高；
2）测试进行中，可能有一些问题阻碍了其他问题的发现；
3）依靠执行测试用例不可能发现100%的错误，软件的功能好比是面，靠孤立的点来覆盖面试完全不可能的。因此测试的主观因素就永远不可避免。测试人员的灵机一动可能会发现很多重要的问题，而这种问题的发现一定要依靠一定的时间和工作量的积累。
M0（软件项目启动，需求定义阶段）—M1（分布式开发阶段）—M2（总体联调阶段）—M3（产品上市）
Mo—M1阶段：测试的人才储备期，主要从人力及其培训方面做准备，保证在将来的测试阶段有足够熟练新技术新功能的测试人员；
M1—M2阶段：测试的技术流程准备期，依据项目明确下来的需求，分别从计划、技术、工具、环境、团队、流程等方面做准备。包括制定测试计划，设计测试用例，搭建测试环境，组建测试团队，明确测试流程等；
M2—M3阶段：测试的全速实施期，整个测试团队按照之前的准备全速执行测试，力求在最短的时间内发现最多的问题；
M3后：对测试仍旧极为重要，测试团队需要根据市场的反馈了解产品在市场上发生了哪些情况，协助开发人员复现这些问题，以使这些问题得到最快的定位和修改，而减少在市场上的负面影响。
测试日程的制定需要根据两个文档，第一是总体的项目时间表，第二是项目的软件版本发布计划。
制定测试日程需遵循以下原则：
1）每个软件版本一定要有一个版本基本测试，目的是在最短的时间里判断软件是否值得一测；
2）在所有功能都集成起来之前不需要进行系统测试，但应该按照集成模块的次序，进行各个子系统的测试；
3）现场测试盒互操作性测试要在系统测试进行至少两轮之后才开始，以保证最基本的功能性问题已经被发现并解决；
4）压力测试发生在上市之前的一两个版本上，主要目的是试图复现那些影响较大但复现概率极低的问题。
七、测试用例的设计、维护和更新 测试用例是所有测试活动的技术基础，实在是非常值得把时间和人力投在它上面。
关于用例问题测试部与开发部之间的沟通：
1）每天开发工程师抽出半小时时间来回答测试人员的疑问
2）开发的任何一点变化都要在需求变更库中存档，数据库的权限要同时开放给相关的测试人员，测试人员每天都需要在需求变更库中检查这些变更，同时同步地更新测试用例。
对于测试用例开发，在第一个软件版本发布之前，基本测试用例集必须完成，针对新模块的测试用例必须在该模块第一次发布之前完成。
测试用例在以下三种情况下必须得到更新：
1）需求变更库中显示需求方出现了变动，相应的测试用例必须修改；
2）测试组内部评审时发现测试用例覆盖不够全面时，需要添加新的测试用例；
3）自由测试中发现了问题，相应的测试用例必须被添加。
八、测试环境的设计和搭建
九、测试文档的格式和提交时间
测试团队对外的输出文档有二：一是问题报告，二是测试报告。测试计划中要清楚地写明对这些报告内容上和时间上的要求。
测试报告是在测试的某一阶段后，对测试过程的总结和待测短剑/版本的成熟度和风险的评估。
十、测试入口/出口的checklist
每一个测试项目的每一个环节都要有清楚的入口和出口的准则，也就是清楚的定义什么情况下测试可以开始和什么情况下测试应该结束。
软件在提交系统测试之前应该按照事先约定的标准（checklist）进行一定的审查，以避免仓促提交测试再被一脚踢回来。
测试循环开始的Checklist：
1）版本的发布是否遵循了《项目软件版本发布计划》？
2）随着版本的发布，是否一起提交了版本发布说明？
3）版本发布说明中是否详细描述了此版本与上一版本的区别？
4）改动部分是否执行了单元测试和集成测试，是否有测试报告？
5）版本发布前是否对简单功能进行了基本验证？
6）版本发布说明中是否包含解决问题的列表和未解决问题的列表？
测试团队自身也要有Checklist，即测试循环结束的Checklist：
1）该版本的测试报告是否已提交？
2）测试报告中是否对软件的状态下出了结论？
3）各子模块测试的报告是否已提交？
4）是否100%完成了更改问题的验证工作，是否有验证结果的汇总？
5）该版本上新发现问题的列表是否已提交？
6）所有遗留问题的列表是否已提交？
7）所有遗留问题中最严重的TOP10是否已提交？
8）以上所有输出物是否都按照标准化文档模板书写的？
十一、测试组成员的管理和激励机制 我们已经充分地了解了测试的特殊性，它要求测试人员随时保持旺盛的斗志，在强调职业道德的同时，一定的物质激励措施绝对是有必要的。
十二、测试过程的流程和定义
测试并不是技术驱动的工作，更多的是管理和流程驱动的活动。
测试计划中要描述两大部分的流程，第一部分是测试管理流程，可以简单的概括为计划、实施和报告三部曲；第二部分是问题管理流程，规定如何管理、维护和跟踪测试中发现的问题。
测试团队方面常见的问题有：
1）有时候问题单输入的质量不高，需要的信息提供不准或者不全，开发人员无法理解问题的全貌，往往需要经过多次沟通才能解决；对于异地开发甚至跨国开发的项目，这种沟通成本是很高而且低效的；
2）多个测试人员在填写问题单时沟通不够，经常同一个问题多个人多次上报，导致问题单的数目大于实际问题的数目，会给开发人员和问题管理员增加很多重复劳动；
3）测试人员对于功能的理解不够深入，往往报告一些实际上不是问题的伪问题，这样会增加其他团队的工作量；
4）验证问题的效率和准确性有待提高，有时候测试人员更喜欢追逐新问题，对旧问题的验证兴趣不高，但是对于项目来说，旧问题的验证却更有价值。
针对四大问题对测试流程进行修正：
1）QA需要抽查问题单的输入质量；
2）测试人员在填写问题单前需要在数据库中按关键字搜索相关问题，只有确信以前没有人提交过时才上报；
3）增强培训，最大限度减少误报；
4）在流程上保证验证问题的优先级，规定在一个版本测试中，最先做的就是旧问题的验证。
十三、测试过程的质量监控
测试过程的监控应该针对六大关键点：
1）测试计划的风险评估；
2）测试文档的质量；
3）计划实施的质量；
4）测试报告的质量
5）问题管理的质量
6）测试范围与覆盖率的完备性。
版权声明：本文出自 hellorenwei 的51Testing软件测试博客：http://www.51testing.com/?578951
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
《笑傲测试》笔记（前言+第一式：庐山面目）
《笑傲测试》笔记（第二式：蓬门始开）
《笑傲测试》笔记（第四式：矫如龙翔）
《笑傲测试》笔记（第五式：浮云遮日）
接口测试这个词语，相信大家都不陌生了吧。目前我个人的理解，接口测试应该属于白盒测试的范畴，也是很多测试工程师很想从事和向往的一个测试手段。大家都觉得白盒测试深不可测，但实际上是怎么样的呢。
接口测试的实施优先级
对于 Web 应用来说，接口测试就是对某一个接口进行测试代码的编写和执行。一般情况下，实施接口测试的优先级是：对暴露在外面的接口（该接口会给第三方调用）进行接口测试；内部的核心功能接口也会做接口测试；内部非核心功能接口的接口测试（很多时候就是单元测试）。当然这个实施的具体细节，还需要根据项目的情景和人员的能力来确定如何实施接口测试、在哪里做接口测试、为什么要做接口测试、做到什么程度等。
接口测试的实施条件
接下来说下，接口测试实施需要的一些条件。第一个就是测试人员的能力，代码的熟悉能力、接口测试框架的使用能力、接口测试环境的搭建能力、接口测试设计的能力、基础代码的编写能力、基础 Debug 能力等。第二个就是接口测试框架，框架是否定制化一些功能（比如自动加载 java bean、方便初始化数据、方便校验数据库数据等）。第三个就是测试团队和测试流程的支持，测试团队需要支持测试人员对核心接口进行接口测试（包括时间上、精力上、技术上等支持）；测试流程上需要保证接口测试的效率和项目接入性（在项目当中实施接口测试，充分考虑开发团队和功能测试团队合作等）。
接口测试的实例
接下来会通过一个案例来说明接口测试的一些基本考虑点，这里不涉及到详细的接口测试流程和注意点，只会把接口测试的一些想象展示给大家。
public interface IdleItemService {
Result<ExtraItem> publish (ExtraItem extraItem);
/**
* taobao.idlesell.item.update
* 编辑闲置宝贝
*/
Result<ExtraItem> update (ExtraItem extraItem);
/**
* taobao.idlesell.item.get
* 查询闲置宝贝
*/
Result<ExtraItem> query (Long itemId,Boolean hasDesc,Boolean hasPic,String appKey);
} 上面的代码是淘宝的提供出去的某个 Top 接口代码，测试人员需要针对这个 Top 接口做最严格的接口测试，那他该怎么做呢，需要持续关注什么呢。
接口测试之前，需要充分的了解接口的实现功能的业务逻辑、接口参数、接口返回值。功能业务逻辑：外部可以通过该接口发布一个闲置二手的宝贝，具体细节不做说明。
接口参数: 一个宝贝的所有信息参数。见图：
接口返回值：Result<IdleItemResult>，其中包含一些 errorcode 等基本属性。
接口的测试设计主要关注点
- 接口中所有的入参都要写测试用例。
- 每个入参的每个错误类型都要准备一个异常用例。如必须参数缺省、参数类型错误、参数范围错误、参数超过最大位数、参数没有达到最小指定位数、参数的无效值（有效状态外）、参数的小数点超过规定长度、参数含有非法字、参数含有违禁字、参数的关联性检查（如所在省、市，所在地不匹配）等等。
- 对于正常系的用例，要把所有入参的各种合法的有效值都执行到。所有入参的最大位可以用一个测试用例执行掉。所有可缺省的参数不要（只输入必须参数）的测试用例也要做一个。
- 对于搜索接口，应该把每个参数单独作为搜索条件来确认搜索结果是否正确，然后再确认多条件输入后的结果。
如下是部分参数的接口测试设计的截图：
接口的测试代码的编写
大家应该发现了对于所有的参数，我们都需要校验一下参数的基本特征，如前面讲到的异常用例一样。那么接口测试代码又是什么样的呢。
- step1: 编写测试基类（加载资源、初始化环境）（可选）。
- step2: 编写测试类。
- step3: 在该测试类中编写测试方法。
- step4: 在测试方法中调用被测方法。
- step5: 验证预期结果与返回的结果是否一致。
- step6: 执行测试查看测试结果。
那么针对所有的接口测试用例写接口测试代码，可以看到的是，我们的接口测试代码主要是入参的不同，校验结果的不同，其他区域的测试代码都是一样的。我们要做的是不断的 copy 前一个测试用例代码，然后修改某个参数、修改某个验证点就搞定了。
接口测试自动化生成框架
对于这些比较重复的测试代码编写工作，大家肯定想到是否可以自动生成这些脚本，还会想到自动生成的脚本是否可以和测试数据一起自动运行测试代码呢。这里可没想象那么简单，需要考虑业务逻辑、接口环境、测试数据、接口测试框架等一系列的组合。
我们来简单点吧，我们的目的，在一定的测试范围内，充分利用工具来自动化生成测试用例，保证测试用例的覆盖率。 两种程度的复用该测试套件，一种是测试用例的生成和复用，一种是测试代码的生成和复用。 请看下面的自动化生成框架的架构图：
模板引擎架构图如下：
相关术语解释：
- All Pairs：利用参数来定制化生成测试用例的攻击，入口是 Excel 准备的参数文件；出口是 txt 文件的测试用例。这个工具是开源的，可以自己定制化开发，具体请见：http://www.infoq.com/cn/news/2011/08/combination-test
- 业务 API 库：由于需要生成测试代码，需要知道业务逻辑所涉及到的接口和类，比如 IC 中的发布宝贝的发布接口。
- 模板：根据业务逻辑规则制定的逻辑描述，可以利用因果图分析法中的“或与非”来描述接口业务功能逻辑（需要抽象出相应的关键因子，也就是部分的接口入参）
- 测试用例分析器：将 txt 文件格式的测试用例进行分析，分析每个用例的参数和参数值和业务逻辑。
- 测试数据分析器：将 xml 文件格式的测试数据进行分析，与生成的每个测试用例代码进行组合和处理，生成带数据的测试代码。
那么接下来我们需要做什么呢。迭代去开发我们需要的组件就行，第一步考虑自动生成接口测试框架代码，定制化的选择接口来自动生成框架代码（包括集成了现成的接口测试框架）；接下来考虑如何让我们的用户（测试人员）来输入我们的测试数据，并考虑与框架代码生成进行集成融合；另外一块就是测试环境的 API 的调用了，如何能自动运行自动生成的测试代码并反馈结果给测试人员等一系列的问题需要进一步深入挖掘。
这里还需要说明的是，我们不期望这个框架能解决所有接口功能接口测试代码的自动生成（有些接口实现业务逻辑较复杂），我们能解决掉一部分重复工作（某个接口的 60% 的测试代码），且能告诉大家我们可以做一些事情更智能化和简单化。
关于作者
高翔(花名季哥) 淘宝软件有限公司资深测试工程师，曾任职于华为南京研究所和群硕软件有限公司。有着通讯、ERP、互联网等多种行业的测试经验，对需求分析、测试流程、测试设计方法、风险分析有较深的理解，擅长于测试模型的建立、用例架构的设计、公共组件功能的抽象和应用、探索式测试流程和方法实践。
一直以来没有做过接口测试，了解下如何对接口进行测试，可以从哪些方面考虑。下面从各个地方载录了些，以被以后用。接口测试的英文是interface testing，接口测试测试系统组件间接口的一种测试。
在集成测试中首先是确定需要测试模块，集成是将多个模块集合在一起工作，模块与模块之间肯定有工作的接口，你就需要研究一个模块输入输出，研究多个模块的输入输出，构造你如何测试这多个模块输入输出的关系。-------查找各模块的输入输出及关系，编写用例
接口测试主要考虑的问题:
1.各个模块连接集成起来的时候,穿越模块接口的数据会不会丢失; -----确定数据完整
2.各个子功能组合起来,能否达到预期要求的父功能; ------集合后，达到需求目标
3.一个模块的功能是否对另一个模块的功能产生不利影响; ------集成后，不影响相关模块功能
4.全局数据结构是否有问题; ------集成后，保证系统数据的正确性
5.单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。 -------集成后，确保误差不影响系统功能及性能
Service层接口测试，大致有三种测试类型：接口逻辑测试、出错测试、路径测试
接口逻辑测试，对开发人员输写的JavaDoc进行测试，后根据JavaDoc来编写测试用例（一般情况下JavaDoc需要包含前提条件，业务逻辑，输入参数，输出值的描述），在接口逻辑测试中主要是根据所描述的业务逻辑，进行用例的设计，主要目标是测试在正常输入的情况下能得出正确的结果，测试用例的设计方法跟黑盒测试差不多，主要运用等价类，边界值两种方法。
出错测试，做了接口逻辑测试后，可以正常使用了。为了保证数据的安全，及程序在异常情况的逻辑正确性，因此需要测试出错测试。出错测试主要考虑：空值输入（如当传入一个对象参数时，需进行NULL值的参数）、参数属性的测试（如输入一个未赋值参数）、异常的测试（制造一些异常的测试场景，测试的异常描述是否清晰）
路径测试，经过了上述处理后，单个的接口服务已经得到了保证，但是在业务流中是否满足了业务需求其实还是没有得到保证，路径测试的目的就是设计尽可能少的用例，来保证各种业务场景下数据是安全可操作的
java 中的instanceof 运算符是用来在运行时指出对象是否是特定类的一个实例。instanceof通过返回一个布尔值来指出，这个对象是否是这个特定类或者是它的子类的一个实例。
用法：
result = object instanceof class
参数：
Result：布尔类型。
Object：必选项。任意对象表达式。
Class：必选项。任意已定义的对象类。
说明：
如果 object 是 class 的一个实例，则 instanceof 运算符返回 true。如果 object 不是指定类的一个实例，或者 object 是 null，则返回 false。
例子如下：
package com.instanceoftest;
interface A{}
class B implements A{
}
class C extends B {
}
class instanceoftest {
public static void main(String[] args){
A a=null;
B b=null;
boolean res;
System.out.println("instanceoftest test case 1: ------------------");
res = a instanceof A;
System.out.println("a instanceof A: " + res);
res = b instanceof B;
System.out.println("b instanceof B: " + res);
System.out.println("\ninstanceoftest test case 2: ------------------");
a=new B();
b=new B();
res = a instanceof A;
System.out.println("a instanceof A: " + res);
res = a instanceof B;
System.out.println("a instanceof B: " + res);
res = b instanceof A;
System.out.println("b instanceof A: " + res);
res = b instanceof B;
System.out.println("b instanceof B: " + res);
System.out.println("\ninstanceoftest test case 3: ------------------");
B b2=(C)new C();
res = b2 instanceof A;
System.out.println("b2 instanceof A: " + res);
res = b2 instanceof B;
System.out.println("b2 instanceof B: " + res);
res = b2 instanceof C;
System.out.println("b2 instanceof C: " + res);
}
}
/*
result:
instanceoftest test case 1: ------------------
a instanceof A: false
b instanceof B: false
instanceoftest test case 2: ------------------
a instanceof A: true
a instanceof B: true
b instanceof A: true
b instanceof B: true
instanceoftest test case 3: ------------------
b2 instanceof A: true
b2 instanceof B: true
b2 instanceof C: true
想来想去，这个文章的名字还是叫理性看待性能测试更为妥当。今天在微博上看到有人@到我提到一个关于性能测试的问题，我在回复了之后，感觉意犹未尽。由于微博上打字太费劲了，想说的话还没说完就不让输入了。只能回来自己写一个文章以平复一下想说未说完的憋闷。
我们总是会听到这样的话：性能测试工程师应该会操作系统、数据库、网络、应用、代码等等。这样的话，大部分是从有经验的性能测试所谓的前辈的嘴里说出来，让一些人觉得说这样的话的人牛B而且非常值得膜拜。可气的是没有说明白这个程度到底是什么样的，其实从我个人从业这么多年的角度来看，没有哪一个人可以把这些东西，全都精通到不可一世的程度。要是说完全不知道，那也不太可能，哪个IT行业的人一生不得总是接触这些东西呢。接触并不代表可以掌握和控制它，这种完全不同的视角会在含糊其词之间被无视。所以，我觉得对性能测试工程师，没有必要这么苛刻。要求可以，但是要理智的要求。要求懂操作系统、数据库、网络、应用？没有关系，正常的操作是可以做的，和性能有关的常用的判断手段是可以做的，和性能有关的常用的参数配置是可以知道的。（其他亦如此）。我觉得这样的要求对中级性能测试工程师就可以了。至少可以做大部分的工作了。也许会有人接着问了，高级性能测试工程师又要求什么呢？我觉得：性能测试的思维是高级性能测试工程师必须修炼的内功心法。面对一个未做过的系统，如果出现性能问题，从自己的经验教训中去判断寻找一些蛛丝马迹，配合整体的团队寻找解决问题的方法，这才是要体现出来的价值。
同时，我们还会听到另一种声音：性能测试不就是拿着工具录个脚本，加些用户跑一下就行了吗？于是乎，经常会有一些人提出一些比较苛刻的性能测试需求：很短的时间内出一个性能测试的结果，并且要说出性能瓶颈在哪里。这种性能需求大部分来自于一些对性能测试并不十分了解的人群，但是这部分人群又有足够的能量影响着性能测试的方向。比如说，客户方的某个领导。在这样的情形之下，做为性能测试的行内人，就有引导客户需求、说服客户的职责了。当然，在现在这种利益驱动的市场模式之下，花个大价钱做个完整的性能测试，可能还没有给某些关键人物来点贿赂更为有效。毕竟系统上线就死的也不是很多嘛，哪有那么多的系统都像某订票网站那么悲摧呢。只有实际的损失才能有切肤之痛。
说到性能测试产生的实际的损失，我记得我在一次测试沙龙上说过一句话：在某些感受不到性能测试价值的企业里，性能测试是在谩骂和鄙视中被从踏得满是灰尘的地上捡起来的。在一些实际的利益损失之后，那些各相关部门才会捡起这个大海中救命的木头。可惜的是，这个时候各种动作都是亡羊补牢，损失的再也不会回来。那些被终端用户的嘲笑也被记录在企业的发展历史中。话说，前一阵子，一个金融行业巨头的某系统由于参数配置的问题一上线就死了，幸好产生的社会影响并不大；还有某证券公司的渠道总线因为性能不达标导致停了半个小时，损失了1个亿；还有某互联网公司的系统上线之后，因为数据库承受不了压力而出现了大量的用户失败的现象，等等。这样的情况举不胜举，我都不用众所周知的某订票网站做例子。
不管是在什么样的行业中，我觉得都要正视行业的处境，也需要明白自己的能力在行业中的位置。在自己的岗位上，就要明白自己的职责。我们不应该给性能测试相关的岗位太多的压力，也不应该报有过高的期望。同时，我们也要知道性能测试的岗位能做到什么样的事情。做为一个性能测试工程师，本身就要明白性能测试的工作职责。我看到很多个招聘性能测试职位的要求，有些要求招的不是人，而是神。由于神不多，所以只能抱怨现在这个行业真是整体能力太差了。性能测试的整个过程中确实应该包括完整的性能分析、优化工作，也需要给足够的时间、资源和支持。
一个性能项目，如果想做到完整的性能分析，必须要有其他团队的支持。我们可以定位到一个具体的函数，但是如果我们也把函数改了，是不是更能体现我们强大呢？显然这不符合逻辑。这不是我们该干的事情，除非把开发的工资也发给我们。所以，我的观点是：性能分析是性能测试过程中的一个必然的环节；性能分析需要各个相关团队的支持。当然有些团队可能因为时间比较紧，最后留给系统性能测试的只有一点点可怜的时间。在这样的情况之下，就不要再指望性能测试能带来多大的强心剂了，最多也就是安慰安慰领导或者客户罢了。
还是总结一下：认清楚性能测试职位能做到的事情，明确性能测试工作中需要的支持。不要有无谓的天马行空的论调和不切实际的需求。真正的理性的看待性能测试，才能让性能测试发挥它本应该发挥的也可以发挥的最大的价值。
后记：希望行内人和行外人都给性能测试一个合理的判断。
版权声明：本文出自 Zee 的51Testing软件测试博客：http://www.51testing.com/?17369
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
Twist是一个基于Eclipse开发的自动化测试平台，它是ThoughtWorks公司的一款商业软件。Sahi是一个Web自动化工具，有Tyto公司创建，具有免费版和专业版两个版本。作者将在本文中简单介绍一下这两个工具，以及基于它们搭建的轻量级Web自动化测试框架，最后重点跟读者分享一些个人使用的经验和技巧。
在介绍Sahi之前，首先简单描述一下作者参与的项目。这个项目是为一家公司做商业应用的实施。由于时间紧迫，测试人员较少，大部分时间都是在针对主要功能做手工测试。为了减少一些重复的手工劳动，我们决定搭建一套Web自动化框架。这个框架需要符合以下条件：1、搭建迅速，易于维护；2、使用简单，易学易用，降低测试人员的学习成本。3、由于业务流程比较复杂，希望在测试用例失败的时候能够方便测试人员快速准确的定位并重现问题。考虑到以上几点，再加上这个项目只需要对一些常用重复的流程进行自动化，我们放弃了以前搭建过的一套比较成熟的测试框架，转而决定使用Sahi和Twist来搭建一个轻量级的Web自动化框架。
Sahi是一个比较成熟的Web自动化工具，使用它可以轻松的对Web页面操作进行录制和回放。作者曾经使用过一段时间的Selenium，就个人经验而言，Sahi在元素定位，页面等待上更有优势一些。Twist是一个可协作的功能测试平台，之所以称为平台，是因为它提供了很多有用的功能来帮助测试人员编写和管理测试用例。Twist有个很好的特性是同时支持用户手工和自动化运行测试用例。这点可以让我们在得到功能需求后，先在Twist里建好测试场景，并根据业务逻辑写下测试步骤，等到被测功能比较稳定后，再决定自动化哪些测试用例，而那些业务逻辑和自动化脚本可以很好的在Twist中被关联起来，如图1所示。
图1 Twist中的测试场景
在结合Twist的一些特性和Sahi的录制回放功能后，我们将测试框架设计如下图所示：
图2 基于Sahi和Twist的Web自动化测试框架
这个框架并没有什么特别复杂的地方，基本就是将Sahi中的Java API进行封装，然后使用Twist中的已有功能来对系统进行自动化测试。下载两个工具后，就可以进行测试场景的编写和自动化。下面是作者在这个项目中总结的一些经验和技巧：
1、把握好测试场景描述的粒度。在Twist的场景中，应尽量使用业务语言来描述测试步骤，而避免使用操作性的语言。在Twist帮助文档中有一章高级指导（Advanced Tutorial），其中专门提到在不牺牲可读性的前提下，应最大限度的用抽象概念来描述步骤。这里的抽象概念就是指的具体业务逻辑。但就个人经验而言，抽象还是有度的，太抽象的描述复用性就不够好了。读者可通过多尝试多思考来把握这个描述的粒度。
2、为测试场景加标签并按顺序为其命名。可能大家比较习惯于为一个待测功能单独建立一个文件夹，并将测试场景都放在里边，但由于在Twist视图下，只对Scenario目录下的场景可见，如果在其目录下建立子目录，将无法使用Filter的功能。所以建议为每一个场景加上标签，可以是功能的编号或名称，这样就可以分类查看和运行了。另外，在Twist视图中，所有的场景是按名称的字母序来排列的，故建议在场景名称前加01，02，......。（eg.01Login,02SearchBook.加0是因为根据字母序11是在1和2之间的）这样便于查找以及管理场景执行的先后顺序。
3、当用Sahi定位动态生成的页面元素时，应使用in，near等方法配合别的页面元素来进行定位。比如测试步骤为点击一个数据列表中某一行里的图片链接，如果使用Sahi录制，生成出来的元素ID可能跟HTML里的元素ID一样，也可能是一串很长的数字，可读性较差，测试代码也较难维护，这时可以先根据序列号或者标题字符串等定位到该行的某一个位置，再结合Sahi中in和near方法，定位到这行上的图片链接。
4、需要用多组数据来测试同一场景时，尽量使用Twist中提供的Data Table功能。在Twist里，可以将来自不同数据源的数据导入到测试中，并且支持选择每次需执行的几组数据。
5、完善错误处理机制。在场景运行失败的时候，可加入一段代码，截屏保存当时的出错页面，同时，将被测系统的日志文件截取部分放到指定文件夹，这样就能更加方便地分析定位问题。（在Sahi专业版中可直接使用takeSnapShot(）方法进行截屏，如果使用免费版，可使用其它方法实现，例如类java.aw.Robot中的createCapture()方法）
6、导出build.xml文件，整合其它工具。在Twist中，我们可以导出ant文件，并且编写我们需要的task，例如在不同浏览器上运行，或者是运行某一标签的测试场景等，这样就可以在不打开Twist的情况下，通过运行命令行的方式来执行测试。这些命令还可以放到其它工具中进行整合，例如持续集成工具Hudson，可在build完成后自动运行一些基础测试。
总的来说，Twist和Sahi是比较适合一个小型测试团队进行自动化测试的。Twist能够有效地减少搭建自动化测试框架的时间，让测试人员更多的关注在业务逻辑上面，有兴趣的读者可以下载Twist的试用版进行尝试。
主题：如何定义测试流程 好的测试流程必须满足一柔一刚两种要求。其柔性的要求是：测试的所有活动能够被组织和定义的平滑高效，实施起来没有阻滞和混乱。而其刚性的要求是：组织中的每个人能够充分了解自己的工作输入条件和输出准则，大家既有检查上一步工作是否到位的权利，又有按时保质保量地完成工作的义务。
所谓开发过程中的正规化，核心就是科学的定义流程和严格的执行流程。一个测试项目成功的关键是各个环节能够环环相扣和紧密配合，这就要求测试流程必须定义的清晰科学。
一、柔性要求：流畅的测试流程
测试的所有活动能够被组织和定义的平滑高效，实施起来没有阻滞和混乱。
一个普通的版本测试过程中，会经历的一些活动：
新版本发布说明（Release Notes）
测试任务书（Task Description）
升级测试版本（Release Update）
问题验证（Error Verification）
基本功能测试（Release Test）
新功能测试（New Feature Test）
压力测试（Stress Test）
自由测试（Free Test）
问题报告（Error Report）
进度报告（Progress Report）
二、刚性要求：严格的测试规程
组织中的每个人能够充分了解自己工作的输入条件和输出准则，大家既有检查上一步工作是否到位的权利，又有按时保质保量地完成工作的义务。
输入条件：
（1）输入之一：测试用例（case）
测试用例必须简明扼要，分布均匀，不能有太多重复的用例，又不能有明显的疏漏。这些都需要在测试项目开始之前得到保证，指望测试执行阶段的自我修复是靠 不住的。所以需要根据需求跟踪矩阵来设计测试用例，同时建立定期评审的机制来弥补被忽略的功能点和根据实践中遇到的各种情况来更新补充测试用例。
（2）输入之二：测试分工
测试分工是为了让每个测试的执行者清楚地了解自己在何时应该做什么，有哪些具体的要求。测试经理在每轮测试之前进行详尽的任务细化并通过有效的沟通机制传达给团队中的每个成员，最正规的途径是下达书面的测试任务书（测试计划）给团队的每一个成员。
（3）输入之三：测试工具
对于测试工具的要求有两个。
第一是好用，在选择测试工具的时候要慎重和广泛的比较，要保证我们即将使用的工具确实能够帮助我们——可以制定一个规范的测试工具评审表，按照测试的需求把测试工具的表现做定量的评估。
第二是大家都会用，每个测试人员都必须了解自己需要用到的测试工具及其使用方法。——要制定完备的培训计划，让每位项目成员通过培训来学到工具的使用方 法和各种规则，同时测试的管理者应该能够一目了然的看到培训的组织和参加情况（签到表），避免因新加入的成员培训不及时而影响工作的质量。
（4）输入之四：提交物的模板（BUG提交工具）
模块化是让工作步调一致的捷径，它能让一个即使经验不够丰富的项目成员也能够在很短的时间内提交出质量不错的输出物。所以模板必须要简单清晰，尽量避免给使用者过多的自我发挥的空间，用形式来约束内容。
输出准则：
（1）输出之一：测试结果（用例执行结果）
测试结果的意义并不在于有没有人看，它的意义主要体现在，当测试的粒度均匀的情况下，能够定量地描述出当前软件的稳定程度。而且多轮测试的力度相同，那么可以从测试结果的通过率上可以看出软件功能实现的变化趋势。
要降低用例的“不可测率”，测试团队需要制定有针对性的工作流程来监控“不可测”的测试用例；对于长期“不可测”的测试用例即使封杀，使之不再占用测试人员的时间；对于短期“不可测”的测试用例，要及时快速的创造测试的条件，把测试的黑洞及时修补上。
（2）输出之二：问题报告（提交BUG的描述信息）
问题报告是测试工作最主要的输出物，必须做到清晰、详尽，提供尽可能多的信息。包括问题出现的软件版本、日期、测试人员的姓名和联系方式、问题的概要描述、重现概率、重现步骤、和先决条件、期望的输出和实际的输出等。
（3）输出之三：调试信息（Log日志）
调试信息是必不可少的，它能够帮助开发人员了解问题发生的时候系统在做些什么事情。在测试开始之前要对测试团队进行深入的培训，需要每个人都明确哪一类问题需要提交哪一类调试信息，获取调试信息的手段、工具、配置等。
（4）输出之四：模块测试报告
模块测试报告是很有价值的开发文档之一。第一条就是，报告的完成要及时，不能等新闻成了旧闻才看到事后诸葛亮似的报告。另外内容要既粗且细，粗 是为了迎合层次比较高的管理者；细是为了当读者有兴趣的时候，能够从报告中了解到足够详细的内容。此外模块测试报告中应当尽量提供：模块的稳定程度 （case通过率）、模块的稳定趋势（与上一个版本的case通过率做比较）、严重问题的列表。
（5）输出之五：修改验证（BUG修改验证）
对一般的开发团队来讲，衡量其绩效的一个重要指标就是改BUG的反应速度，而一个BUG的终结一定是以通过测试人员验证的时间为准。修改验证的 优先级永远都应该是测试人员案头优先级最高的任务。因为迟早对于此BUG的修改一定是会进入到产品基线中的，所以与其晚验证不如早验证，这样我们可以有更 多的时间测试那些可能由此修改带来的风险。
及早对修改进行验证，这一方面是对开发人员的支持，另一方面如果此修改不解决问题甚至带来了其他问题，及早验证能给开发人员更多的时间做进一步检查。
三、自我约束：测试过程评估
在测试过程中要对测试的过程有定期严格的评估，以便及时发现并纠正测试过程中出现的问题。
组织一个兼职的监督小组，成员包括测试项目组长，若干测试工程师和独立的软件QA，由他们按照事先约定的项目和内容定期评估测试过程。对测试质量的评估不仅仅要停留在一两个测试用例执行的结果上，更高层次的评估重点是评估测试过程的合理性和效率。
三张图表：测试工作流程图、宏观测试流程、项目评估方法
版权声明：本文出自 hellorenwei 的51Testing软件测试博客：http://www.51testing.com/?578951
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
《笑傲测试》笔记（前言+第一式：庐山面目）
《笑傲测试》笔记（第二式：蓬门始开）
《笑傲测试》笔记（第四式：矫如龙翔）