性能测试checklist
- 格式:doc
- 大小:12.50 KB
- 文档页数:3
第 1 部分: 数据输入本文为系列文章"Web 软件测试Checklist 应用系列"中的第一篇。
该系列文章旨在阐述 Checklist(检查清单)在 Web 软件产品测试中的应用,以帮助您了解如何利用 Checklist 这种重要的测试手段,更高效的寻找 Web 产品中的 defect(缺陷)。
Checklist 汇集了有经验的测试人员总结出来的最有效的测试想法,可以直接有效的指导测试工作,开阔测试人员的思路,能够快速的发现产品的缺陷并实现较好的测试覆盖,更重要的是该 Checklist 在不同的项目中具有很强的通用性。
Checklist 在Web 测试中的重要性Checklist(检查清单)从名字字面意思即可理解,是用于检查的一系列条目。
之所以需要Checklist,是因为人们的记忆会有疏忽,可能遗漏一些需要注意的事项,还因为人们的经验和水平有限,能够思考到的程度有差异,借助Checklist 可以帮助我们做必要的检查。
举例,体检的时候,在体检中心登记之后会给每个人打印一个清单,就是当天需要检查的项目,逐项检查并打勾,就可以避免遗漏;再比如,当我们计划一次旅游时,我们会列举我们旅途中需要用到所有物品的清单,以及旅行前需要完成的各项准备工作。
通常,出行前,我们会按照清单逐项检查,比如办签证、订机票、订酒店等,出行前,我们会按照清单逐项打包需要带的东西,比如药品、工具、文件资料、护照签证、机票等等。
Checklist 在类似的工作中具有非常重要的价值。
为什么Checklist 可以应用在软件测试中呢?第一,Checklist 可以帮测试人员节省时间,因为很多有效的方法并不需要每个测试人员重新发现,前人已经有了充分的总结,并做了大量的有效性验证;第二,Checklist 可以帮助测试人员避免遗漏,人的记忆是有局限的,难免会有遗漏的地方,通过Checklist 检查可以有效的防止遗漏。
checklist方法Checklist是一种工具或方法,用于确保任务或项目的执行过程中的每个关键步骤和要求都得到满足。
它经常用于项目管理、质量控制和任务执行等领域。
使用Checklist可以帮助人们提高工作的效率、减少错误发生以及确保工作的准确和完整。
在本文中,我们将探讨Checklist的作用、好处以及如何创建和使用Checklist。
Checklist的作用和好处:1. 确保一致性和准确性:Checklist可以确保任务和项目的关键步骤都得到遵循和执行,从而确保一致性和准确性。
它可以帮助人们避免遗漏关键步骤或要求,以及减少错误发生的可能性。
2. 提高工作效率:通过使用Checklist,人们可以有条不紊地进行任务或项目的执行。
它可以帮助人们记录和跟踪每个步骤的完成情况,从而更好地组织和安排工作,并提高工作效率。
3. 降低错误发生率:通过将任务或项目的关键步骤和要求列入Checklist,人们可以避免疏忽和错误的发生。
通过反复检查Checklist,可以确保任务或项目的执行没有遗漏和错误,并及时发现和纠正问题。
4. 提高沟通和协作:Checklist可以作为沟通和协作的工具,帮助团队成员之间更好地理解任务和项目的要求,并确保每个人都按照相同的标准和步骤进行工作。
它可以促进团队之间的协作和配合,减少误解和冲突。
如何创建和使用Checklist:1.确定任务或项目的关键步骤和要求:首先,需要明确任务或项目的目标和要求。
然后,根据这些目标和要求,确定执行任务所需的关键步骤和要求。
2. 编写Checklist:将关键步骤和要求编写成Checklist的形式。
可以使用简单的列表形式,或者根据任务的复杂程度和要求的详细程度,使用更为详细和结构化的格式。
3. 测试Checklist的有效性:在使用Checklist之前,可以将其进行测试,以确保其有效性和可行性。
可以通过模拟执行任务或项目的过程,检查Checklist是否包含了所有关键步骤和要求,并是否易于理解和执行。
如果有朋友想到更多的检查项,也希望可以留言大家一起讨论。
1. 开发人员是否提交了测试申请?2. 测试对象是否已经明确?3. 测试范围是否已经明确?4. 本次不被测试的范围是否已经明确?5. 测试目标是否已经明确?6. 何时开始性能测试?7. 何时终止一轮性能测试?8. 性能测试需要做几轮?9. 所需的测试环境是什么?是否已经到位并配置完成?(包括硬件、软件、网络等)10.所需的测试工具是什么?是否已经到位并保证可以正常使用?11.被测系统的版本是否已经明确?是否已发布?从哪里可以获得?是否已经部署成功?12.被测系统的相关功能是否已经正确实现?13.压力点是否已经明确?响应时间的计算方式是否已经明确?14.本次测试工作参考的文档有哪些?15.场景是否已经设计完成并记录在场景管理文档中?16.每个场景是否有明确的测试意图、前置条件和详细的设置?17.脚本是否已经录制并调试通过?18.是否已经明确了哪些地方需要参数化?19.是否已经明确了各个参数的取值方式?20.是否已经为参数化的部分准备了必须的数据?21.是否已经准备了相应历史数据量?22.是否已经准备了相应的数据恢复方法?(例如准备一个SQL语句用来恢复数据环境)23.在Controller中对多VU、多次迭代的情况是否已经调试通过?24.在Controller中Result的路径设置是否正确?25.在Controller中检查脚本选择是否正确?26.在Controller中检查VU数量设置是否正确?27.在Controller中检查集合点是否禁用/启用?28.在Controller中检查VU加载策略是否设置正确?29.在Controller中检查迭代次数是否设置正确?30.在Controller中检查迭代间隔设置是否正确?31.在Controller中检查日志是否禁用/启用?32.在Controller中检查Think_Time是否回放?33.在Controller中检查是否为UNIX服务器和Load Generator机添加了资源监视器并确认可以收到性能数据?34.在Controller中检查是否为其他必要的资源添加了资源监视器,并确认可以收到性能数据(例如Oracle,WebSphere)?35.在Controller中检查Load Generator机是否可以连上?36.检查场景管理文档中是否添加了新的“场景执行情况”,并记录了运行前的数据?37.在Controller中执行场景前,检查是否在Linux客户端中运行了vmstat和top,监视执行过程中的Linux服务器资源消耗情况?38.在Controller中执行场景完毕后是否马上去系统中进行检查数据的一致性,并填写“场景执行情况”中的运行后情况?39.场景完执行完后是否将vmstat和top的数据copy到记事本中,并保存到相应的结果目录下?40.整个系统的测试工作执行完毕后,是否进行了性能图表的分析和测试报告的提交?。
测试检查表checklist输入、编辑功能的验证检查点:1. 必输项是否有红星标记,如果不输入提示是否跟相应的Label对应,提示的顺序是否跟Form输入域的排列次序一致;2. 输入的特殊字符是否能正确处理:`~!@#$%^&*()_+-={}[]|\:;”’ <>,./?;3. Form下拉菜单的值是否正确,下拉菜单的值通过维护后是否正确显示并可用;下拉菜单比如是机构编码,要到机构编码的维护界面查询一下是否Form列出的与其一致;4. 涉及到下拉菜单的编辑修改Form,要检查在编辑和修改From中,下拉菜单是否能正确显示当前值;5. Form提交后,要逐项检查输入的内容跟通过查询的结果一致;6. 有多层下拉菜单选择的情况要校验两层菜单的选择是否正确;7. 备注字段的超长检查;8. 提交保存后能否转到合适的页面;9. 编辑Form显示的数据是否跟该记录的实际数据一致;10. 编辑权限的检查,比如:user1的数据user2不能编辑等;11. 可编辑数据项的检查,比如:数据在正式提交之前所有的属性都可以编辑,在提交之后,编号、状态等不能编辑,要根据业务来检查是否符合需求;12. 对于保存有事务Transaction提交,比如一次提交对多表插入操作,要检查事务Transaction的处理,保证数据的完整和一致;13. 其他的合法性校验。
查询功能检查点:1. 查询输入Form是否正常工作,不输入数据是否查询到全部记录;2. 当查询的数据非常多的时候,性能有无问题;3. 查询的下拉菜单列出的数据是否正确;4. 查询结果是否正确;对于复杂的查询要通过SQL来检查结果;5. 如输入%*?等通配符是否会导致查询错误;6. 查询结果列表分页是否正确,在点击下一页上一页时,查询条件是否能带过去,不能点击翻页时又重新查询;7. 对于数据量比较大的表查询时,不容许无条件查询,避免性能问题的出现;8. 对于查询输入项的值是固定的要用下拉菜单,比如状态、类型等;9. 分页的统计数字是否正确,共X页,第N页,共X条记录等;10. 对于查询有统计的栏目,比如:总计、合计等要计算数据是否正确;11. 查询结果有超链接的情况要检查超链接是否正确;12. 查询权限的检查,比如:user1不能查询到user2的数据等;删除功能检查点:1. 必须有“确认删除”的提示;2. 根据需求检查是软删除还是硬删除,来检查数据库中是否还存在该条记录;3. 是否有相关的数据删除,如果有要确认该相关的数据也已经删除,并且在同一事务中完成;4. 是否有删除约束,如果有删除约束,要检查该记录是否被约束,如果被约束该记录不能被删除;5. 如果是软删除,用查询、统计界面检查该条记录能否被查询出来,数据是否被统计进去;6. 检查因为业务约束不能删除的数据能否被保护不能手工删除,比如:流程中已经审批的文件不能被删除;7. 跟删除相关的权限问题,比如:需求要求只有管理员和该记录的创建人能够删除该记录,那就以不同的用户和角色登录进去,执行删除操作,检查是否与需求匹配;上传附件检查点:1. 检查是否能正确上传附件文件;2. 检查上传的文件是否能正确下载并打开;3. 至少检查下列大小的文件能正确上传,0k,100k,1M,2M,4M,10M,20M等;4. 如果没有指定类型的限制,至少上传以下几种类型的文件能否正确上传并正确打开,类型有:.doc,.xls,.txt,.ppt,.htm,.gif,.jpg,.bmp,.tif,.avi等;5. 如果有文件类型的限制还要检查能上传的文件的类型;6. 上传同名的文件,在打开的时候是否出错;7. 有中文文件名的文件能否正确上传;影响操作性能的检查点:(不能代替系统的性能测试和压力测试,主要看系统在正常操作情况下的响应和处理能力)1. 对数据记录条数比较多的表的查询操作,避免全表查询,比如对银行用户账号的查询就不能缺省全部查出,必须让用户输入查询条件;2. 菜单树,测试大量数据时菜单树的响应情况;3. 有日志的查询或者统计,要注意查询的效率;4. 大报表的处理或者批处理的操作,要关注效率,比如:银行对帐、财务年终结算、财务年报表、系统初始化等;5. 大报表的排序sort、组函数的使用等;6. 大数据量的处理,如导入、导出、系统备份、文件传输等。
测试 Check List1. 引言测试 Check List 是测试过程中的一项重要工具,用于确保测试的全面性和准确性。
本文档将介绍如何编写和使用测试Check List。
2. 撰写测试 Check List 步骤2.1 确定测试范围在撰写测试 Check List 之前,首先需要明确测试的范围。
测试范围应该包括待测系统的功能、性能、安全性等方面。
2.2 列出待测功能点根据测试范围,列出待测的功能点。
每个功能点应该明确描述功能的预期行为。
示例:功能点预期行为用户登录登录成功后跳转到主页发布新文章成功发布后在文章列表中显示修改用户信息保存修改后,信息应更新到数据库删除评论删除后评论应从数据库中删除2.3 列出待测边界条件边界条件是指系统中的特殊情况,如极限值、异常值等。
列出待测边界条件可以帮助测试人员更全面地覆盖系统的各种情况。
示例:功能点边界条件发布新文章文章标题为空发布新文章文章内容超过最大长度修改用户信息用户名包含特殊字符删除评论评论ID不存在2.4 列出待测的关键功能点关键功能点是指对系统核心功能进行测试的功能。
列出待测的关键功能点,可以帮助测试人员重点关注系统的重要部分。
示例:•用户注册•支付功能•数据加密2.5 根据测试需求添加测试用例根据待测功能点和边界条件,为每个功能点编写相应的测试用例。
测试用例应包括输入、预期输出和实际输出。
示例:测试用例 1:功能点:用户登录输入:用户名、密码预期输出:登录成功实际输出:登录成功测试用例 2:功能点:发布新文章输入:文章标题、文章内容预期输出:文章成功发布实际输出:文章成功发布2.6 检查测试用例的覆盖范围在添加测试用例后,需要检查测试用例的覆盖范围。
确保所有待测功能点和边界条件都有相应的测试用例。
2.7 根据测试需求添加测试数据根据测试用例的输入要求,准备测试所需的测试数据。
确保测试数据覆盖了各种情况,包括正常情况和异常情况。
2.8 评审和修正测试 Check List在完成测试 Check List 的编写之后,需要进行评审。
S5000R1性能数据收集checklist4、 组网(画出设备的组网图,包括光纤网络的带宽,中间交换机的型号)5、 存储级联框的组网图(请标出级联框与控制框相连的端口,框号)6、 收集存储配置信息,方法有以下几种a) 从OSM 界面上导出选择 系统>>导入导出操作,点击系统配置状态导出选项。
保存配置文件b) 使用存储信息收集工具收集信息信息收集工具下载地址,下载后使用InfoCollection工具收集。
/cn//Service_Training/Service_Support_Center/Download_Cente r1/Common_User_Zone/Storage/Storage_Product_Software/Service_Tools/Project_Tools/Softwar e_Download/201005/620462_35_0.htm7、收集主机性能信息a)windows主机(参考附录2)b)linux主机8、收集存储性能信息(a、b项使用不同的putty窗口同时收集,并且需要将putty界面的日志保存到文件中,在业务运行时收集数据)a)收集磁盘的性能信息在两边控制器使用mml命令dev disk xx,xx为框号,遍历完所有的框。
iostat –dx 2 -tb)收集业务模块的性能信息将附件perfmon-o.sh脚本拷贝到存储控制器上,修改文件的属性为可执行属性,执行脚本。
附录附录1:保存putty界面日志的方法点击putty窗口的左上角,选择change settings选项选择logging选项,选择log printable output only选项,再选择文件保存的路径,最后点击Apply按钮。
附录2:windows性能监控工具perfmon使用指导windows 2008 perfmon工具使用方法1、开始-> Administrative Tools -> server Manager2、在Server Manager页面里,点击Diagnostics-> Reliability and Performance-> Data Collector Sets-> User Defined-> New Data Collector Set3、在下图的空白处,点击右键,点击new-> Data Collecor4、在弹出的对话框中,在左侧的列表中选择我们需要监控的选项,对于某个选项下的所有子选项都需要监控时,直接点击1处的“+”号即可选中全部子选项,然后点击2处的“Add”即可将该选项添加到右侧框中,如3处所示,若选择错误,请在右侧框中,选中选错的选项,点击4处的“Remove”即可将错误现象移出;5、我们需要监控的选项包括:physical Disk (ALL)processor (Interrupt Time Idle Time Phylege Time Processor Time User Time Interrupts /sec)Memory (Page In /Sec PageOut /Sec Commited Bytes)Cache (Data flush page /sec Data flush /sec )Database-Instance (ALL)—如果是sql server 数据库则需要监控Database (ALL)――如果是sql server 数据库则需要监控6、将以上所有选项添加到右侧的检测框中,点击OK,进入下图:在Sample interval中设置采样时间间隔,建议设置为157、点击“Next”进入下图,选中图中标注的复选框,点击“Finish”8、在弹出的对话框中,将Log format设置为comma separated9、点击OK即可,此时一个新的数据收集文件已经建立成功,如下图:点击1处的开始按钮,即可开始监控,点击2按钮,即可结束监控windows 2003 perfmon工具使用方法windows 2003 perfmon工具与windows2008基本上一样,仅仅是启动的方法不同,这里就介绍perfmon在windows 2003的启动方法。
如果有朋友想到更多的检查项,也希望可以留言大家一起讨论。
1. 开发人员是否提交了测试申请?
2. 测试对象是否已经明确?
3. 测试范围是否已经明确?
4. 本次不被测试的范围是否已经明确?
5. 测试目标是否已经明确?
6. 何时开始性能测试?
7. 何时终止一轮性能测试?
8. 性能测试需要做几轮?
9. 所需的测试环境是什么?是否已经到位并配置完成?(包括硬件、软件、网络等 10. 所需的测试工具是什么?是否已经到位并保证可以正常使用?
11. 被测系统的版本是否已经明确?是否已发布?从哪里可以获得?是否已经部署成功? 12. 被测系统的相关功能是否已经正确实现?
13. 压力点是否已经明确?响应时间的计算方式是否已经明确?
14. 本次测试工作参考的文档有哪些?
15. 场景是否已经设计完成并记录在场景管理文档中?
16. 每个场景是否有明确的测试意图、前置条件和详细的设置?
17. 脚本是否已经录制并调试通过?
18. 是否已经明确了哪些地方需要参数化?
19. 是否已经明确了各个参数的取值方式?
20. 是否已经为参数化的部分准备了必须的数据?
21. 是否已经准备了相应历史数据量?
22. 是否已经准备了相应的数据恢复方法?(例如准备一个 SQL 语句用来恢复数据环境
23. 在 Controller 中对多 VU 、多次迭代的情况是否已经调试通过?
24. 在 Controller 中 Result 的路径设置是否正确?
25. 在 Controller 中检查脚本选择是否正确?
26. 在 Controller 中检查 VU 数量设置是否正确?
27. 在 Controller 中检查集合点是否禁用 /启用 ?
28. 在 Controller 中检查 VU 加载策略是否设置正确?
29. 在 Controller 中检查迭代次数是否设置正确?
30. 在 Controller 中检查迭代间隔设置是否正确?
31. 在 Controller 中检查日志是否禁用 /启用?
32. 在 Controller 中检查 Think_Time是否回放?
33. 在 Controller 中检查是否为 UNIX 服务器和 Load Generator机添加了资源监视器并确认可以收到性能数据?
34. 在 Controller 中检查是否为其他必要的资源添加了资源监视器,并确认可以收到性能数据(例如 Oracle , WebSphere ?
35. 在 Controller 中检查 Load Generator机是否可以连上?
36. 检查场景管理文档中是否添加了新的“ 场景执行情况” ,并记录了运行前的数据?
37. 在 Controller 中执行场景前,检查是否在 Linux 客户端中运行了 vmstat 和top ,监视执行过程中的 Linux 服务器资源消耗情况?
38. 在 Controller 中执行场景完毕后是否马上去系统中进行检查数据的一致性, 并填写“ 场景执行情况” 中的运行后情况?
39. 场景完执行完后是否将 vmstat 和 top 的数据 copy 到记事本中,并保存到相应的结果目录下?
40. 整个系统的测试工作执行完毕后,是否进行了性能图表的分析和测试报告的提交?。