软件测试实习笔记1

PAGEPAGE11***************************学习性能测试，掌握课程内容性能测试知识点总结：--典型性能指标虚拟并发用户数（TotalVirtualUsers）单位:个交易响应时间（ResponseTime）单位:second/millisecond并发用户/响应时间图负载图每分钟交易数（TransRate）吞吐量图（ThroughOut）--服务器负载压力指标操作系统CPU内存硬盘数据库*UserConnections：用户连接数，也就是数据库的连接数量；

*Numberofdeadlocks：数据库死锁；

*ButterCachehit：数据库Cache的命中情况--应用系统的指标应用系统根据自身功能性能要求确定的指标:比如支持的画面数量TAG点的数量一幅画面中支持的最多控件数量检控更新周期能够管理的IP数量--性能测试系统的性能是一个很大的概念，覆盖面非常广泛，对一个软件系统而言包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等，我们这里重点讨论的负载压力是系统性能的一个重要方面。性能测试用来保证产品发布后系统的性能满足用户需求。性能测试在软件质量保证中起重要作用。--负载测试负载测试是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等如何决定系统的性能，

例如稳定性和响应等。负载测试通常描述一种特定类型的压力测试，即增加用户数量以对应用程序进行压力测试。--压力测试压力测试通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大的服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。--负载压力测试负载压力测试是性能测试的重要组成部分，负载压力测试包括：并发性能测试（重点）疲劳强度测试大数据量测试--并发性能测试

考察客户端应用的性能，测试的入口是客户端并发性能测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发虚拟用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。--疲劳强度测试通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。--大数据量测试大数据量测试的两种类型独立的数据量测试针对某些系统存储、传输、统计、查询等业务进行大数据量测试综合数据量测试和压力性能测试、负载性能测试、疲劳性能测试相结合的综合测试方案--考察系统配置连接到系统的用户数应用程序客户端计算机的配置情况（硬件、内存、操作系统、软件、开发工具等）使用的数据库和Web服务器的类型（硬件、数据库类型、操作系统、文件服务器等）服务器与应用程序客户端之间的通信方式前端客户端与后端服务器之间的中间件配置和应用程序服务器可能影响响应时间的其他网络组件（调制解调器等）--分析使用模型考虑哪些用户使用系统每种类型用户的数量每个用户的典型任务确定活动峰值期的发生时间负载峰值期间的典型活动--并发用户估算结合某类软件高峰期，范围，做一个推论形的方案，比如30:1,前指在线用户，后指并发用户。用得频繁，比率就变为如15:1最大200:1最小15:1--选择测试工具的策略自动负载测试开放资源（OpenSource）测试自主开发代码测试--开放资源（OpenSource）测试开放系统测试体系－OpenSTA/）TestMaker（/）ApacheJMeter(/jmeter/)--性能测试成功标志系统运行正常重复三次，每次结果在误差允许之内。如目标值的上下20%之内。资源监控指标能够获取有效值。--WEB测试注意点***************************掌握用户验收测试课程内容--定义用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题

。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软

件配置评审、功能测试、性能测试等多方面检测。--用户验收测试的准入条件在真正进行用户验收测试之前一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）：

软件开发已经完成，并全部解决了已知的软件缺陷。

验收测试计划已经过评审并批准，并且置于文档控制之下。

对软件需求说明书的审查已经完成。

对概要设计、详细设计的审查已经完成。

对所有关键模块的代码审查已经完成。

对单元、集成、系统测试计划和报告的审查已经完成。

所有的测试脚本已完成，并至少执行过一次，且通过评审。

使用配置管理工具且代码置于配置控制之下。

软件问题处理流程已经就绪。

已经制定、评审并批准验收测试完成标准。--用户验收测试（UAT）的目的：从最终用户的角度，验证软件系统符合需求定义的各种功能和技术需求，验证各业务流程执行情况，为用户是否接受软件系统提供决策依据。***************************了解测试自动化，JUnit，TDDJunitJUnit是由ErichGamma和KentBeck编写的一个回归测试框架（regressiontestingframework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。JUnit是一个开放源代码的Java测试框架，用于编写和运行可重复的测试。他是用于单元测试框架体系xUnit的一个实例（用于java语言）。它包括以下特性：1、用于测试期望结果的断言（Assertion）2、用于共享共同测试数据的测试工具3、用于方便的组织和运行测试的测试套件4、图形和文本的测试运行器另外junit是在xp编程和重构（refactor）中被极力推荐使用的工具，因为在实现自动单元测试的情况下可以大大的提高开发的效率，但是实际上编写测试代码也是需要耗费很多的时间和精力的，那么使用这个东东好处到底在哪里呢？笔者认为是这样的：1、对于xp编程而言，要求在编写代码之前先写测试，这样可以强制你在写代码之前好好的思考代码（方法）的功能和逻辑，否则编写的代码很不稳定，那么你需要同时维护测试代码和实际代码，这个工作量就会大大增加。因此在xp编程中，基本过程是这样的：构思－》编写测试代码－》编写代码－》测试，而且编写测试和编写代码都是增量式的，写一点测一点，在编写以后的代码中如果发现问题可以较块的追踪到问题的原因，减小回归错误的纠错难度。2、对于重构而言，其好处和xp编程中是类似的，因为重构也是要求改一点测一点，减少回归错误造成的时间消耗。3、对于非以上两种情况，我们在开发的时候使用junit写一些适当的测试也是有必要的，因为一般我们也是需要编写测试的代码的，可能原来不是使用的junit，如果使用junit，而且针对接口（方法）编写测试代码会减少以后的维护工作，例如以后对方法内部的修改（这个就是相当于重构的工作了）。另外就是因为junit有断言功能，如果测试结果不通过会告诉我们那个测试不通过，为什么，而如果是想以前的一般做法是写一些测试代码看其输出结果，然后再由自己来判断结果使用正确，使用junit的好处就是这个结果是否正确的判断是它来完成的，我们只需要看看它告诉我们结果是否正确就可以了，在一般情况下会大大提高效率。安装JUnit安装很简单，先到以下地址下载一个最新的zip包：/junit/下载完以后解压缩到你喜欢的目录下，假设是JUNIT_HOME，然后将JUNIT_HOME下的junit.jar包加到你的系统的CLASSPATH环境变量中，对于IDE环境，对于需要用到的junit的项目增加到lib中，其设置不同的IDE有不同的设置，这里不多讲。如何使用JUnit写测试？最简单的范例如下：1、创建一个TestCase的子类packagejunitfaq;importjava.util.*;importjunit.framework.*;publicclassSimpleTestextendsTestCase{publicSimpleTest(Stringname){super(name);}2、写一个测试方法断言期望的结果publicvoidtestEmptyCollection(){Collectioncollection=newArrayList();assertTrue(collection.isEmpty());}注意：JUnit推荐的做法是以test作为待测试的方法的开头，这样这些方法可以被自动找到并被测试。3、写一个suite()方法，它会使用反射动态的创建一个包含所有的testXxxx方法的测试套件publicstaticTestsuite(){returnnewTestSuite(SimpleTest.class);}4、写一个main()方法以文本运行器的方式方便的运行测试publicstaticvoidmain(Stringargs[]){junit.textui.TestRunner.run(suite());}}5、运行测试以文本方式运行：javajunitfaq.SimpleTest通过的测试结果是：.Time:0OK(1tests)Time上的小点表示测试个数，如果测试通过则显示OK。否则在小点的后边标上F，表示该测试失败。每次的测试结果都应该是OK的，这样才能说明测试是成功的，如果不成功就要马上根据提示信息进行修正了。如果JUnit报告了测试没有成功，它会区分失败（failures）和错误（errors）。失败是你的代码中的assert方法失败引起的；而错误则是代码异常引起的，例如ArrayIndexOutOfBoundsException。以图形方式运行：javajunit.swingui.TestRunnerjunitfaq.SimpleTest通过的测试结果在图形界面的绿色条部分。以上是最简单的测试样例，在实际的测试中我们测试某个类的功能是常常需要执行一些共同的操作，完成以后需要销毁所占用的资源（例如网络连接、数据库连接，关闭打开的文件等），TestCase类给我们提供了setUp方法和tearDown方法，setUp方法的内容在测试你编写的TestCase子类的每个testXxxx方法之前都会运行，而tearDown方法的内容在每个testXxxx方法结束以后都会执行。这个既共享了初始化代码，又消除了各个测试代码之间可能产生的相互影响。JUnit最佳实践MartinFowler说过：“当你试图打印输出一些信息或调试一个表达式时，写一些测试代码来替代那些传统的方法。”一开始，你会发现你总是要创建一些新的Fixture，而且测试似乎使你的编程速度慢了下来。然而不久之后，你会发现你重复使用相同的Fixture，而且新的测试通常只涉及添加一个新的测试方法。你可能会写许多测试代码，但你很快就会发现你设想出的测试只有一小部分是真正有用的。你所需要的测试是那些会失败的测试，即那些你认为不会失败的测试，或你认为应该失败却成功的测试。我们前面提到过测试是一个不会中断的过程。一旦你有了一个测试，你就要一直确保其正常工作，以检验你所加入的新的工作代码。不要每隔几天或最后才运行测试，每天你都应该运行一下测试代码。这种投资很小，但可以确保你得到可以信赖的工作代码。你的返工率降低了，你会有更多的时间编写工作代码。不要认为压力大，就不写测试代码。相反编写测试代码会使你的压力逐渐减轻，应为通过编写测试代码，你对类的行为有了确切的认识。你会更快地编写出有效率地工作代码。下面是一些具体的编写测试代码的技巧或较好的实践方法：1.不要用TestCase的构造函数初始化Fixture，而要用setUp()和tearDown()方法。2.不要依赖或假定测试运行的顺序，因为JUnit利用Vector保存测试方法。所以不同的平台会按不同的顺序从Vector中取出测试方法。3.避免编写有副作用的TestCase。例如：如果随后的测试依赖于某些特定的交易数据，就不要提交交易数据。简单的会滚就可以了。4.当继承一个测试类时，记得调用父类的setUp()和tearDown()方法。5.将测试代码和工作代码放在一起，一边同步编译和更新。（使用Ant中有支持junit的task.）6.测试类和测试方法应该有一致的命名方案。如在工作类名前加上test从而形成测试类名。7.确保测试与时间无关，不要依赖使用过期的数据进行测试。导致在随后的维护过程中很难重现测试。8.如果你编写的软件面向国际市场，编写测试时要考虑国际化的因素。不要仅用母语的Locale进行测试。9.尽可能地利用JUnit提供地assert/fail方法以及异常处理的方法，可以使代码更为简洁。10.测试要尽可能地小，执行速度快。JUnit和ant结合ant提供了两个target：junit和junitreport运行所有测试用例，并生成html格式的报表具体操作如下：1.将junit.jar放在ANT_HOMElib目录下2.修改build.xml，加入如下内容：Oneormoretestsfailed,checkthereportfordetail...运行这个target，ant会运行每个TestCase，在report目录下就有了很多TEST*.xml和一些网页打开report目录下的index.html就可以看到很直观的测试运行报告，一目了然。在Eclipse中开发、运行JUnit测试相当简单。因为Eclipse本身集成了JUnit相关组件，并对JUnit的运行提成了无缝的支持。TDD(Test-DrivenDevelopment)测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（ExtremeProgramming），同样可以适用于其他开发方法和过程。TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。优点：在任意一个开发节点都可以拿出一个可以使用，含少量bug并具一定功能的产品。缺点：增加代码量。测试代码是系统代码的两倍或更多。TDD=TFD+Refactoring(TFD--TestFirstDevelopment)计算机领域：TestDrivedDevelop测试驱动开发是一种开发方法，是开发人员参与的活动。其效果是以可执行的形式文档化需求，迫使你分清职责隔离依赖以驱动你的设计，编织安全网以便将Bug扼杀在在摇篮状态，防止其逃逸。可传统测试人员的活动是试图找到已经逃逸的Bug。这两种活动都是必要的，而且毫不冲突，互为补充。那么测试人员在新的特性还没开发完成之前做什么呢?除了提前写测试用例，无论是自动化的还是非自动化的，而需要测试人员参加的一项重要活动，就是参与特性验收条件的制定。之前经常发生开发人员按照自己的理解去编码，测试人员按照自己的理解去测试，直到开发完成，测试过程中才发现理解的不一致，开始产生争执并阻塞等待业务分析人员(如果幸运的话)或者行政主管(如果开发过程混乱的话)的仲裁。解决办法就是，在开始开发新特性前的一刹那，由业务分析人员，测试人员，开发人员进行一次讨论，就验收条件达成一致并形成记录，然后测试人员和开发人员分头去写测试和实现。***************************测试规范与细则培训软件测试简介从软件工程的角度出发，软件生命周期过程包括需求分析，分析设计，代码实现，测试，及应用。然而仅测试阶段就又一次完全体现了软件生命周期的全过程，这里涉及测试需求的定制，各类测试计划、测试过程的建立，测试的开发，测试的执行和测试结果的评估。综合的说软件测试就是根据软件开发各阶段的规则说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。目的：通过测试来发现软件中的存在的各类错误验证软件是否满足软件设计和任务书所规定的技术和要求。为软件可靠性和安全性评估提供依据有效定义和实现软件成分由低层到高层的组装过程现阶段软件质量的主要手段原则：所有的测试都应追溯到用户需求；在测试工作真正开始前的较长时间就进行测试计划测试应以“小规模”开始逐步转向“大规模”想要做到穷举测试不可能测试用例应由测试输入数据及与之对应的预期输出这两个部分组成程序员避免检查自己的程序在设计测试用例