这是该系列四部分中的第一部分,第二部分将会在StickyMinds.com中发表。
大多数和软件相关的性能测试项目都会失败,当我谈到失败的时候,并不是说测试异常结束了,我所谈论的是没有给测试的人员提供一点有用资料的情况。
失败的产生有很多的原因。在本系列的文章中,我将会描述基本的问题和如何避免它们,所以如果你正在执行一个软件性能测试的任务,你将会理解一系列的问题,并理解哪些是你能够完成的和哪些是你不能完成的。这些将不能解决所有的问题,也不是提供给软件性能测试专家测试,他们中的大多数人可能已经通过反复试验了解到这些想法。
该系列中的很多想法都是基于Ross Collard of Collard & Associates的一个课程开发的,我在那里教SQE培训。在这里,我无法因为这些概念和想法而得到好评。
下面的将是我们通过这一系列的文章将会研究的大体范围:
第一部分
- 测试人员在过程中的角色
- 确定性能和业务目标
- 如何让性能测试和开发过程相适应
第二部分
- 系统架构和基础构件
- 选择准备运行的测试类别
第三部分
- 了解工作量(业务简介)
- 量化和定义度量单位
第四部分
- 了解工具
- 执行测试和报告结果
这些问题在很多不用的领域得到不同序列的解决,我将会按照自己认为最适合的方法进行。这个方法已适用于所有类型的平台:大型机、客户机/服务器、嵌入式、Web网络等。其中第一部分说明了测试者所扮演的角色,了解性能目标以及何种性能测试是适用于开发进程的。
测试者所扮演的角色
在软件性能测试中,性能测试者的角色更多的时候更像是一个顾问——你指导、指挥并协助技术人员识别和纠正问题。性能测试者测试:他们没有按照基调、不调试或者不纠正识别的问题。一个良好的性能测试是一个团队努力的结果,所有主要角色和利益相关者都必须是性能测试计划进程中的一部分,其利益相关者包括可能去调整、纠正、调试或者为调整系统、应用程序组件以及涉及决策性能目标和目的的人员。
……………………
查看全文请点击下载:http://www.51testing.com/html/17/n-172317.html
性能测试如何适应于开发过程
很多人看待软件性能测试是你将产品展现给用户的在运输前的最后一道工序,这样的看法是不正确的和危险的。图2说明了性能测试的传统方法,这是基于一种观点,即一个完整地系统或应用程序为了性能测试必须存在。
图2 传统性能测试方法
这种方法主要的问题是,后期发现问题的过程中可能需要修改应用程序或系统,这将需要重新测试被影响的功能——其次是回归测试——需要在性能测试再运行前执行。必须指出的是,一次更改多于一个的功能是非常难协调的,多个技术小组将会参与以及需要去协调,它也可能使一次多种变化可以掩盖了解决问题的方法,同时调整数据库和应用程序的代码可能会使得他们互相抵消。因此,很多团队使用一次更改一个因素(OFAT)的方法。
不幸的是,OFAT方法不能取得好的效果,在以下几种情况下:
- OFAT假定的因素是互相独立的。
- 有太多复杂的、难以理解的和隐藏的互相影响的因素。
- OFAT时间太长。
- 其他的方法(典型的一次调整很多因素的)更难应用的很好。
例如,一旦该数据库是“固定的”,并且重新运行测试,我们可能会发现新的问题,网络或应用程序的,这些问题必须是固定的,反过来这些固定的问题在数据库中又创造了更多的问题。这是有可能终止在一个连续循环中,从一个因素到下一个因素然后重复。
显然,性能测试需要一个稳定的环境和软件,尽管如此,这并不意味着所有的功能都要实现。通过结合预防性思维(静态测试)和增量或迭代式开发,有可能在有一个或两个稳定功能时就启动性能测试。
……………………
查看全文请点击下载:http://www.51testing.com/html/17/n-172317.html
版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。