1.       验收测试是一项非常复杂和费力的被用来确保软件质量的环节。它的目的就是使软件能得到充分运行并且能使其符合原始需求。

2.       测试的目的无非就是满足了两个结果：测试通过或测试不通过。为了能实现每个测试结果，必须要明确每个测试用例。并且对于整个系统而言在合同中必须定义测试用例的失败标准，而且这个失败标准数必须是可接受的。

3.       测试用例的通过条件必须有一个清晰的标准，标准可以被定义为一个测试值或一个测试值集，并且将他们显示或保存到数据库中。一些测试结果比较容易形象的看到(例如：网站上的图片是否被有效的加载)，而另一些测试结果却需要通过脚本将测试结果输出(例如：对数据库中的数据进行测试)。

4.       为了能使所有的测试用例能被精确的执行，一般都建立一些基础测试数据。也许这些测试数据可以从计算机中转换得到。无论测试数据被保存在什么地方，都必须被操作系统能熟练控制。这些测试能更方便的被系统使用。事实上就是要确定每个测试步骤要成为整个测试过程的一部分。

5.       在整个测试序列中，为了确保正确的测试步骤被执行，说明测试过程是非常重要的。例如：如何描述测试”动作次序”.

6.       测试脚本的运行必须能被系统运行执行，输出结果必须能被系统识别。通常情况下，输出结果都以文本形式或者以图表的形式输出。有些时间也可以以各种报表的形式打印输出。

 

 

规范的脚本需要注意的几个问题：

*测试数据应该预先存在，并且测试脚本应该依赖与这些测试数据。-这些测试数据可以依赖以某一测试步骤或整个测试过程。测试结果数据也可以保存在计算机的内存、文件或数据集的形式保存在数据库中。

*每一个测试步骤都能够被独立运行.

*有必要的话，在运行每个测试用例之前，先检查测试数据的正确性。在实际案例中，这步是放在每步测试过程之前，另外也可以通过一些软件检查工具进行检查。

*测试用例的通过标准要是合适的。

*对于测试脚本最重要的标准就是它能够重复使用的。如果建立了正确的测试环境，测试脚本在每次执行后都应该产生相同的结果。但请记住，脚本对测试环境依赖很大，所以测试脚本被另外的一些潜在因素所制约，如计算机系统或网络环境。

*测试脚本还会产生”假错误”的危险性。当执行完测试脚本后，测试脚本会报一些错误，但这些错误却不是Bug。举个例子，测试脚本产生了错误，但在用例中却无法找到(数据类型错误或无法找到数据，这些错误虽然简单但是确是很明显的)。应该将测试脚本本身的通过标准加入到测试用例中来。

*一定要查明测试脚本在执行过程中失败的原因。由于测试脚本的复杂性，也难免会有许多假错误。所以一定要找出根本原因，是测试脚本能被正确的回放执行。但有时候同样的两段测试脚本执行会产生不同的结果，一段能测试通过，而另一段却测试失败。同时也有可能会产生不同的测试结果。我想这有可能是有测试环境的错误而引起的。如果项目时间不允许的话，应该将这部分自动化测试脚本删除，改而人工测试执行。

看到几段文字，我贴上来。

国内企业好像还没有PM 这个角色，而测
试人员又往往成为开发人员的附庸，一个Bug 是否要被解决全由开发人员说了算，这很糟
糕，就像政治上一个权力没有被有效的制衡一样，一定会产生各种问题。

做完一个版本后，还会让所有员工匿名投票，找出这次研发过程中出
现的各种问题以便在下个版本中解决(此过程称为Postmortem，挺吓人的一个词)。

微软的Bug 处理过程，非常类似于“击鼓传花”的游戏。鼓点响起，你的任务
就是尽快把自己手中的“花”（Bug）传给下一个人，不要让它在自己手里耽误很长时间。
从表面上看，在微软工作从不打卡、上班时间也很自由、上午很晚到办公室也没人管你，但
是有Email 跟着、有Bug 催着，你永远不可能偷懒。没有人盯着你，只是事情如影随形，
而且所有和你相关的事情都是公开的，相关的人都知道，就像处于非常开放的舆论监督之中，
除了把事情办漂亮你还能有别的选择吗？

想办法，把对某个人的依赖尽量降低，并使产品可持续发展。

但是测试这一块大家还是不够重视，对测试人员的素质要求也不是很高、人员比例也较
低，测试人员往往依附于开发人员的直接管理，人微言轻.

1.确定问题
可以从几个方面入手：

应用程序代码：通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。

数据库配置：数据库配置经常会引起整个系统运行缓慢，一些诸如Oracle的大型数据库都是需要DBA进行正确的参数调整才能投产的。

操作系统配置：操作系统配置不合理也可能会引起系统瓶颈。

硬件设置：磁盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。

网络：网络负载过重会导致网络冲突和网络延迟。

系统性能问题不是显而易见的，要进行仔细的查找才能够进行正确的定位。

2.确定原因(主要取决于你的经验)

问题的影响是什么：响应时间还是吞吐量，或者其他问题？

是大多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其他用户的操作有什么不同？

系统资源监控的结果是否正常：cpu的使用是否到了极限？I/O情况如何？

3.确定调整目标和解决方案

确定调整目标的主要作用是明确何时停止调整系统，否则工作将永无止尽。

提高系统吞吐量

缩短响应时间

更好的支持并发

设计解决方案的主要依据就是这些调整目标，有了明确的方案和目标，就可以进行后面的工作。

4.测试解决方案

5.分析调整结果

主要考虑以下的问题：

系统调整是否达到或者超出了预定的目标？
系统是整体性能得到了改善，还是以牺牲某部分性能来解决问题的？
调整是否可以结束了？

1.掌握常见自动化测试工具的使用

2.具备一定的编程能力

3.掌握基础的数据库知识

4.掌握常见的操作系统知识

5.掌握一些web应用服务器例如Weblogic和Websphere等的使用

6.具有综合分析问题的能力，例如通过综合分析测试结果来确定系统瓶颈。

1.测试需求分析

2.测试计划制定与评审

3.测试用例设计与开发

4.测试执行与监控

5.分析测试结果

6.编写性能测试报告

7.测试经验总结

最重要的应该是1、4、5

测试需求分析是整个性能测试的基础，在这一阶段，测试负责人要和项目干系人要进行沟通，同时收集各种项目资料，尤其要搞清楚用户对待性能测试的态度。

测试需求分析阶段的主要任务是确定测试策略和测试范围。策略主要根据软件类型以及用户对待性能测试的态度来确定，测试范围则根据测试策略和需求分析的结果来确定！

测试执行与监控。本阶段主要包含性能测试实施与过程监控。测试实施主要指通过测试工具或者真实的用户来执行测试用例，具体工作主要有创建测试场景、执行测试场景、监视测试场景等。监控测试项目是测试经理的主要职责，在执行过程中，通常会根据项目具体情况进行测试内容的调整，例如修改测试用例、调整测试反问等。

分析测试结果。本阶段主要根据前面的测试数据来分析测试结果，为优化和调整系统提供依据。测试分析的对象是应用程序、web服务器、数据库服务器、操作系统、硬件资源等。通过对测试结构的综合分析，准确定位系统的性能问题。

      花了几个晚上，在看James Bach上的一篇最新的博文。可直到现在还没有看完。先暂时贴一部分译文吧。

      这篇博文主要是讨论在工作中如何处理"争论"的，如何使同事之间"争论"后，能达到解决实际问题的目的。达到这场争论的最大效能。大家有兴趣就看看吧。如有错误或不足，请与我联系，及时支持。

     

                         方法学争论:陷阱和转化

      作为一个黑盒测试方法者，我需要用我使用的方法去思考。有时意味着要和那些有不同意见人争论那些应该被做的事。随着时间的推移，我在争论中获得了一些经验。我学到一个好的概念，很少有人知道怎么去争论问题。这不太好，因为一个成功的争论能使团队更健壮。让我们看一下如何消除使争论失败的陷阱，并且如何意见不统一转换为统一。

      有时候，一个争论就像一场战争。在通常情况下，你不会得到建设性的建议。这个建议更多只是为了建立或者维持与你意见相左的同事工作关系情形而提出的-例如当你和一个家伙工作的时候。

      陷阱

     不一致的学术:警惕你正在使用的技术数据。一个普通的术语像”bug”对于不同的人有不同的含义。如果有人说“单元测试是好的软件质量的本质”首先应该被关注到几个问题之一”他所说的’单元测试’,’本质’,’质量’是什么意思”。小心，有时一个关于定义争论能带来重要的结果，但是也能成为另外一个陷阱。

      范例冲突:一个范例是一个包括一切的解释世界的方法，跟据实践和语境,把常规的东西 演变成术语和假设。两个不同范例可以完全使用不同的方法解释同样现象。当两个人从不同的范例角度出发时，每个人对于另外一个人看上去都是愚蠢的。只要你觉得你的对手是愚蠢的，也许那时你应该停止并且考虑该试着划出一个界线。对于那个方面，你应该首先展开讨论。

      不明确的度量:不要被数据诱惑。他们能解释一切。问题是要知道他们实际意义是什么。当有人问我这些数据，我对如何收集度量感到惊讶，并且影响着收集这些数据的人们。我很惊讶这些数据以任何方式被删除。举个例子，当有些人告诉我他执行了1000个测试用例。我想知道是否他说的是微不足道的测试用例，还是那些重要的测试用例。除非他自己亲自回顾了那些用例，否则大家绝不知道，或者会见那些测试用例的作者。

      错觉和合理性：小心理性的沟通感情用事。警惕将强烈的感情关系到你要呈现的观点上。许多争论似乎可以真正地能表现出忠臣，信赖，尊敬和一些基本的观点。总的来说像C++是这个世界上最好的语言。”所有的垃圾语言是垃圾”其实际意义是”C++是我仅仅知道的语言”.我满意我所知道的。我不想关心我自己不知道的语言，因为那样会再次让我感觉象初学者。有句老话说得好，你不能使用逻辑来反驳一个无法通过逻辑来描述的结论。这可能不是严格意义上真的。但这是一个很有价值的指导思想。所以，如果你感觉在争论中非常不习惯。你最好的期望就是也许能停止探讨想法，并且开始整理一下情绪。(未完待续)...

 

原文出自:http://www.satisfice.com/blog/archives/111