性能测试checklist

是否免15测试环境及测试工具与各个测试任务中5资源一节的测试环境及测试工具的要求是否一致
系统测试计划CHECKLIST
评审对象：评审日期：
拟定人：评审人员：
花费：分钟（请使用者准确填写此项）
注：结论为“否”需在“结论说明”中注明内容实例，结论为“免”需在“结论说明”中注明理由。
审查内容
结论
结论说明
备注
是[ ]否[ ]免[ ]
6
测试通过/失败准则的定义是否恰当？
是[ ]否[ ]免[ ]
7
测试挂起的标准及恢复的必要条件是否恰当？
是[ ]否[ ]免[ ]
8
各个测试任务的时间安排是否合理，是否参考了SVVP或SDP计划？
是[ ]否[ ]免[ ]
9
测试计划中是否考虑了回归测试的安排？
是[ ]否[ ]免[ ]
是[ ]否[ ]免[ ]
15
测试环境及测试工具与各个测试任务中“5）资源”一节的测试环境及测试工具的要求是否一致？
是[ ]否[ ]免[ ]
16
对于各个测试任务中“6）风险与假设”中的风险是否给出了应急计划？
是[ ]否[ ]免[ ]
名词解释：
软件开发计划sdp
svvp-Software Verification and Validation Plan即软[ ]免[ ]
2
计划的适用对象及范围是否明确指出？
是[ ]否[ ]免[ ]
3
所列的参考文档及其状态与实际情况是否相符？
是[ ]否[ ]免[ ]
4
组织形式、角色及职责的定义是否合理，是否有利于将计划的任务落实到人？
是[ ]否[ ]免[ ]
5
所列的测试需求是否完整，正确，且与参考文档中的描述相一致？(应依据系统测试需求的特点加以扩展)

第 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是否包含了所有关键步骤和要求，并是否易于理解和执行。

发电机组验收checklist
序号
验收项目
验收要点
验收要求
验收结论
备注
1
工作环境
温度-5~40℃
□符合□不符合□其他
2
湿度10~95％，无凝露
□符合□不符合□其他
3
安装后清洁检查
□符合□不符合□其他
4
设备安装
1、摆放是否稳定，设备与墙体密封是否牢靠，
□符合□不符合□其他
5
2、柜体及设备接线、走线是否符合规范
□符合□不符合□其他
23
4、主控制柜可监测每台发电机基本参数（电压、电流、功率因数、有功功率、无功功率等）。
□符合□不符合□其他
24
5、控制系统具有手动并机操作功能。
□符合□不符合□其他
25
6、系统处于非自动模式，主控屏应由警示指示。
□符合□不符合□其他
26
燃油系统
1、油泵：双路电源设置，运行平稳，无异常噪声、温升，无漏油现象
□符合□不符合□其他
14
多台发电机并机空载和带载测试（满足设计要求时间）正常
□符合□不符合□其他
15
发电机通信接口功能正常。 发电机启动信号：市电信号，消防控制中心信号，现场手动启动信号；其中任一启动信号均可使发电机组自启动；每个低压变电站设置指示灯，提醒使用部门当前电源的供电模式：市电供电/柴油发电机组供电。柴油发电机馈线分别与两路市电联锁，当任一路市电中断后，柴油发电机才能通过人工手动方式启动（但不投入），不做任何方式的自动启动。
□符合□不符合□其他
16
性能测试和检查
1、输出指标符合参数要求（电压、频率、稳瞬态、空载波形畸变等正常,列出设备资料技术资料参数和实际参数）

如果有朋友想到更多的检查项，也希望可以留言大家一起讨论。

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的启动方法。

4
功能定义及 校核
目标值
1、耐压测试，漏电流<2mA 2、绝缘阻抗需>=20MΩ 试验测试数据 试验测试数据 试验测试数据 试验测试数据 额定容量≤25℃1C容量≤1.05倍额定容量;
额定能量≤25℃1C能量≤1.05倍额定能量; 能量效率≥95%（其他温度摸底测试）
满足GB 38031
能量密度＞性能目标要求，放电能量/容量＞额定能量/容量 见DVP要求 见DVP要求 满足故障阈值 见DVP要求
满足EMC标准
禁用物质要求
电池包不能作为整车的离地间隙最低点
电池包上壳体与车身地板间隙
2
人机布置工 电池包侧面与周边间隙 程分析 电池包铭牌等标识能够清晰可见
电池包的防爆阀四周没遮挡物，不对准易燃物品
电池包与热源的距离
S0C不准
3
重大历史问 题
BMS偶发应用层报文不发 偶发报采集芯片故障 电池压差过大
13
尺寸 （DTS）
电池包尺寸
/
电压类、温度类、电流类、通讯类、环路类、绝缘类、继电器故 /
/
/
被动均衡
/
低压上下电
/
高压上下电
/
加热膜加热仿真分析
从-20℃加热到5℃时间＜2h
充放电温升仿真分析
25℃按照0.5C充电1C放电，温度＜45℃
定位销数量
≥1
固定点方向
固定点数量
防松工艺
振动 冲击 挤压 模拟碰撞 底部球击仿真分析 电池包静强度分析 电池系统挤压仿真分析 与车身间隙 与制动管路间隙 与线束类间隙 与管路间隙
与其他周边零部件的间距是否适当
要求一致性 满足冲击类强度要求 具有防松措施
仿真满足DV

备注:102为客户需求代码
需要用CDMA写号工具(EMID号: A100000CC00057,大家可以交换几个号的位置) 如吉讯通类型机器
实际大家也可以调节成2030年,嘿嘿
一名工程师用三合一软件测试版本,一名工程师 用三个独立文件测试CDMA版本
p
p
型电话进行删除,全部删 p
证以及拨出的号码是否
p
p p p p p p p p 同时通话时的效果. p p p p p p p p p p p p / / / / 关注通话效果已经是否可以GSM和CDMA之前是否 可以切换 关注挂断GSM电话后,CDMA声音是否保持不变 yf999中宝项目中出现,手机处于睡眠时,蓝牙 耳机断与对方都无声音
蓝牙
CDMA,GSM同时用蓝牙耳机通话,挂断GSM电话,关注CDMA通话声音是否正常 CDMA连接蓝牙耳机通话,手机端处于睡眠状态,关注通话效果是否正常 蓝牙耳机听音乐过程中,CDMA来电话,关注CDMA蓝牙通话效果以及挂断电话后 否可以正常从蓝牙耳发出
其它
FM 电子书 U盘 网络摄像头 键盘丝印 充电 低电情况 侧键 副屏按键 键盘灯
以及挂断电话后,音乐是
在待机界面按键,点亮屏 p 此问题在YF999等项目上都存在,研发说只要界 面修改了一些就有错误了,请大家在测试的时候 重点关注下
�
是否能正常搜索到频道及收听该频道的音质 选择T卡中的任意电子书,是否能正常显示 是否能正常存储或删除文件夹中的各种文件 是否能正常作为网络摄像头使用,图像是否清晰 键盘上各个丝印是否与输出一致;界面的丝印是否能触摸实现相应的功能 开机或关机充电是否能正常显示充电画面 是否能正常拨通或接听电话 验证每个侧键的功能是否实现 验证副屏上的按键是否实现 是否有键盘灯

Mysql倒表测试checklistIM产品线的很多核心数据采用mysql维护，由于早期设计对数据号段粒度、表备用字段设计不够完善，同时也有新需求的引入，因此IM后台数据经历过多次倒表操作，本文以以往倒表测试经验为基础，整理一下倒表测试的checklist。

测前阶段●设计阶段要求RD输出设计方案，方案不可过于复杂，以免增加操作风险，而且方案上要尽量避免mysql或其相关工具（如mysqlbinlog）的复杂用法。

IM数据操作曾经因为操作方案撞到mysql本身的bug造成数据出错●设计方案要详细，达到op可以支持以之操作的程度，方案中应该包含倒表及验证过程的具体mysql操作指令、倒表工具的配置等详细信息●数据拷贝过程应该是原子性的；这一点对于用户核心数据尤为重要。

例如IM的一次倒表方案：前端模块写旧库后再写新库，因为两步并不是一个事务，因此可能造成数据不一致●设计方案的步骤必须是可校验的，否则线上操作时会有不可预知的风险。

校验程度可以视数据重要性而定，核心数据必须保证数据完全正确，非核心数据可以考虑校验表长并进行抽查测试；如果压力情况下无法完全校验整表，应考虑锁住主库相应表，校验数据后放开锁●设计方案必须是对旧有数据没有影响的、或者是可回滚的，如果线上操作失败，可以继续使用原数据运行●在设计评审后QA要给出测试方案，与RD共同确认方案是否可行。

测试方案中应包含如下关键点：⏹详细测试步骤描述⏹数据量级描述（各表数据量等）⏹背景压力情况（读、写各多少次）⏹收集的参数（如倒表时间、mysql负载情况）●申请线上数据。

用作测试，如果线上数据涉及用户隐私，应在线下构造同等量级的数据然后进行操作往往一些操作方案的bug不易在小数据量场景出现，要在测试中真实模拟线上场景●脚本及工具准备。

通常线下验证倒表方案很难一次搞定，经常需要数次模拟，完全手工操作重复性劳动太多，可以在测前将压力脚本及校验脚本准备到位，争取做到既用既起，可自动判断倒表结束并校验。

| 2评论：图 2 的实例中，电子邮件地址为可选输入项，当用户没有填写该项时，产品提示需要输入邮件地址，而这与可选项的定义不符。

这是产品的一个缺陷。

图 3. 不合理的可选项输入设置图 3 的实例中显示为创建一个群组的窗口页面，该页面上唯一的输入即群组名称，而该群组名称作为群组的唯一标识，是应该为必填输入项的。

而这里，产品并未将该输 入项作为必填项。

当用户不做任何输入，直接点击确定时，一个没有名字的群组将被创建。

这是不合理的，是产品的缺陷。

1.3 输入超过允许长度的数据正 常情况下，每个输入域对输入数据的长度需要进行约束，给出最小长度和最大长度限制。

如果用户输入的数据长度超过最大允许长度，程序需要做出恰当处理。

例 如，测试人员可以创建一个 1,000,000 字节或者更长的字符串，将该字符串输入到输入区域内，并继续后续操作，比如保存或者运行，看程序是否能够给出错误提示或者对字符串长度进行自动截断处理等 操作。

1.4 页面装载或重装载后默认值当网页产品的页面装载完成以后，页面上显示的初 始默认值，需要满足一致性和准确性。

一致性是指，每次从不同的路径到达相同页面后，在做进一步操作之前，页面默认值需要保持一致。

准确性是指，页面上的默 认值需要布局合理，需要使能的按钮和操作都是可用的，需要被禁止的功能要确保不可用。

图 4. 初始加载页面图 4 显示的为打开一个用户配置文件页面，该页面打开后在不做任何更新的情况下，保存和取消按钮处于使能状态。

而实际上此时点击两图 5 的例子中，左侧图显示的是初始状态下组合框的列表内容，默认选择的是 Custom Group, 展开列表后可以看到 Search Results。

右如图 6 所示，在图中所示的表格中，不同组件的排列不齐，左边属性名称和右边的属性值输入域应该是水平对齐的。

这里是产品的一个缺如图 7 所示，注意红色圈内位置有一个未显示完全的按钮，其实下方还有其他更多内容，该部分内容已经超出显示区域的范围，应该在右如图 8 所示的例子中，当名字和姓氏都输入达到最大长度时，保存之后显示框中无法将两部分内容完整的呈现，并且没有水平滚动条辅助显示。

增1能否执行插入功能2默认值是否正确3必输项是否有红星标记，如果不输入提示是否跟相应的Label对应，提示的顺序是否跟Form输入域的排列次序一致4输入的特殊字符是否能正确处理：`~!@#$%^&*()_+-={}[]|\:;”’<>,./?5Form下拉菜单的值是否正确，下拉菜单的值通过维护后是否正确显示并可用；下拉菜单比如是机构编码，要到机构编码的维护界面查询一下是否Form列出的与其一致6要求唯一的数据（主键）是否可以重复添加7备注字段的超长检查8输入域的编辑状态是否正确（editable/uneditable）9输入结果是否被正确保存10插入页面为当前主页面的情况下，提交保存后能否转到合适的页面11插入页面为弹出新页面的情况下，提交保存后原来的列表页面是否会自动刷新12插入的数据在结果列表中是否正确排序13有唯一性要求的，连续提交，不能产生重复数据，或造成数据混乱、丢失改1能否执行修改功能2编辑页面中各输入域是否被正确的置成可编辑、不可编辑状态；可编辑数据项的检查，比如：数据在正式提交之前所有的属性都可以编辑，在提交之后，编号、状态等不能编辑，要根据业务来检查是否符合需求3编辑页面中可编辑的项目是否显示正确的默认值，包括form下拉菜单与文本框4涉及到下拉菜单的编辑修改Form，要检查在编辑和修改Form中，下拉菜单是否能正确显示当前值5Form提交后，要逐项检查输入的内容跟通过查询的结果一致6编辑权限的检查，比如：user1的数据user2不能编辑等7输入的数据是否被保存，Form提交后，要逐项检查输入的内容跟通过查询的结果一致8输入的数据是否保存为其它的值9如果输入的数据（主键）已经存在，是否可以保存10修改操作是否被当作插入处理，即在保存原有数据的基础上，插入了修改值11提交保存后能否转到合适的页面12修改的结果在结果列表中是否正确排序13有唯一性要求的，连续提交，不能产生重复数据，或造成数据混乱、丢失删1必须有“确认删除”的提示2能否执行删除功能3选定的数据是否被删除4是否错误的删除没有选择的数据5是否可以删除部分或全部数据6当设置自动编号时，能否处理删除后的空白7根据项目需求检查是软删除还是硬删除，来检查数据库中是否还存在该条记录8如果是软删除，用查询、统计界面检查该条记录能否被查询出来，数据是否被统计进去9是否有相关的数据删除，如果有要确认该相关的数据也已经删除，并且在同一事务中完成10是否有删除约束，如果有删除约束，要检查该记录是否被约束，如果被约束该记录不能被删除11检查因为业务约束不能删除的数据能否被保护不能手工删除，比如：流程中已经审批的文件不能被删除12跟删除相关的权限问题，比如：需求要求只有管理员和该记录的创建人能够删除该记录，那就以不同的用户和角色登录进去，执行删除操作，检查是否与需求匹配查1能否执行查询功能2对于查询输入项的值是固定的要用下拉菜单，比如状态、类型等3是否可以设置查询条件4在不同部分查询统一信息，查询结果是否一致5查询结果是否包括符合条件的全部数据6是否存在重复出现相同数据的情况7查询结果中是否包括检索条件、可以判断正确与否8查询结果是否有明确的排列顺序9在插入/修改操作时，查询输入的值，结果是否正确10不设置查询条件时是否可以查到全部数据11根据项目需求是否支持模糊查询12根据项目需求查询关键字是否区分大小写13设置部分查询条件时查询结果是否正确14设置精确查询条件时查询结果是否正确15查询结果页面中是否保存查询条件16查询结果分页时，在点击下一页/上一页时查询条件是否能带过去，不能点击翻页时又重新查询17查询结果是否出现内容和合计数值不一致的情况18查询权限的检查，比如：user1不能查询到user2的数据等19当查询的数据量较大时系统性能如何20设置条件进行查询后清空查询条件，再次查询时是否仍然按照之前设置的条件进行查询21如输入%*?等通配符是否会导致查询错误22分页的统计数字是否正确，共X页，第N页，共X条记录等23对于查询有统计的栏目，比如：总计、合计等要计算数据是否正确24查询结果有超链接的情况要检查超链接是否正确分页1总页数是否正确2当前页数是否正确3设置跳转的页数后能否直接跳转4首页/末页、上一页/下一页按钮的状态是否正确5点击首页/末页、上一页/下一页是否跳转到正确的页面上传/下载1是否能正确上传附件文件2检查上传的文件是否能正确下载并打开3上传文件时是否符合大小限制，若没有指定大小的限制，至少检查下列大小的文件能正确上传，0k,100k,1M,2M,4M,10M,20M等4上传文件时是否符合指定的类型限制，如果没有指定类型的限制，至少上传以下几种类型的文件能否正确上传并正确打开，类型有：.doc,.xls,.txt,.ppt,.htm,.gif,.jpg,.bmp,.tif,.avi等5同一个位置是否可以上传同名文件6在不同位置上传的同名文件，打开时是否出错7根据项目需求，中文名称的文件是否可以正确上传/下载。

合计
3
3
4
4 3 3 30
40
3 6 2 3 6 4 4 6 6
100
得分标准
现场演示部署过程、具备部署过程证 明文档、部署操作手册，共三项，前 两项各4分，手册2分。均满足，则为 有 机 器 人 、 im 在 线 、 工 单 、 呼 叫 中 心，满足两项2分，均满足，则为3分 满足目前对接pc网站、微信公众号、 app、微博3分，否则0分。
指止视为退出） 60
1.1 可实现saas部署、及后期本地部署
10
1.2 业务功能全面
1.3 全渠道覆盖
1.4 机器人会话
1.5 Im在线交流 1.6 用户及客服工单创建 1.7 呼叫中心（呼出及呼入） 1.8 机器人知识库管理
2 关键指标
2.1 模块可已h5、sdk输出 2.2 可有完整的数据报表统计 2.3 外呼任务的创建 2.4 电销任务创建 2.5 内部知识库的查询 2.6 客户信息管理模块 2.7 租户配置模块 2.8 权限分配 2.9 日常管理工具易用性

检查表（checklist）的使⽤--测试检查表checklist很常见，各⾏各业都有，但是作为电信运营⽀撑系统这样⼤的软件系统的实施和开发，却。

检查项⽬并不是⼀成不变的，也不是随便想⼏个就可以的，否则会成为摆设。

⼀定得要有过程管理思想并深刻体会到其中的关键点进⾏监控。

每个团队、每个时期都是动态变化的，checklist是⼀种动态的⼯具。

除了过程，可以使⽤在其他⽅⾯，例如：各种评审。

checklist可以让⼯作标准化，但是快速发展的团队和⾼效⼯作似乎不需要标准化？错，这要看checklist的内容是什么。

总会有需要checklist的地⽅并且能起到真正的作⽤。

测试⽤例检查表是否每个⽤例测试⼀种单独的情况⽤例是否有测试数据⽤例是否有预期结果是否明确描述了测试数据的异常值、正常值、边界值预期结果是否可以再现测试⽤例是否分级展现是否有数据恢复脚本是否有优先级是否是可⽤状态（ready）每个⽤例是否覆盖了测试需求是否有设计时间(⽤例完成设计的时间)是否被评审过测试场景检查表场景是否由⽤例组成的场景是否有优先级是否每个场景中的⽤例已经run是否被评审过测试需求检查表涉及到数据库连接是否明确了连接个数和⽅式是否每个测试需求相对独⽴测试需求之间不应该存在因果关系测试需求中不应该存在模糊描述（⼤量、很多、长时间等等）测试需求的来源是否可靠（不会被随意改动）测试需求描述是否清晰⽆歧义是否被评审过是否设定了优先级测试需求是否包含了业务需求是否把复杂的业务需求分解了是否每个测试需求都有明确的输⼊输出，便于测试defect检查表是否描述清晰:出现问题的环境简要描述是否描述清晰:出现问题的操作过程描述是否描述清晰：问题现象描述清楚是否提出了⾃⼰的分析是否指定了解决⼈是否跟踪了每⼀个⾃⼰的bug是否有未关闭的bug是否提出bug之前检查了没有⼈已经提出来过（不重复）是否每个defect描述⼀个独⽴的问题是否及时修改了defect状态是否填写了应该填写的字段不能带有主观的对程序的评价bug描述中不能带有疑问句是否填写了优先级是否填写了严重程度测试计划检查表是否符合项⽬⾥程碑时间要求是否安排好了执⾏时间计划是否安排好了执⾏⼈计划计划安排是否粒度到天（周）是否有测试⼈员培训计划第⼀、描述了项⽬的⽬的第⼆、描述了项⽬的开发周期第四、描述了测试案例的设计周期第五、描述测试案例的执⾏周期第六、描述了测试过程中⽤到的⼯具或者技术第七、描述了测试过程中⽤到的资源情况每⼀部分测试计划时间安排是否有冲突是否有测试过程检查机制测试过程检查是否涉及到其他组是否取得了相关组的认可是否经过了有项⽬经理参加的评审是否有测试执⾏⽇报告机制是否有风险分析以及规避⽅法是否有测试环境描述是否有测试⼈员协作机制是否有测试⼈员考核点描述并且可⾏是否有其他组协作机制描述测试环境更新检查表是否是在确认了版本⽆误的情况下更新的是否有配置⽂件更新是否可执⾏程序权限正确是否记录了编译错误并报告更新后是否做了冒烟测试更新后是否记录了更新过程如果更新步骤或内容有变化是否同步更新了作业指导⽂档更新问题是否提交到CVS更新问题是否通知到相关⼈员是否记录了本次更新经验（版本更新⽇志）测试⽅案检查表是否描述了测试⽅法是否描述了测试参与⼈员是否描述了测试环境是否描述了⼈员协作办法是否相关⼈员已经通知到是否描述了测试内容测试内容时候细化到模块是否描述了测试时间安排是否描述了测试⼈员培训安排是否描写了测试说明章节是否进⾏了换位思考（别⼈能读得懂吗）是否有备份⽅案是否经过评审准备测试评审检查表是否提前给开发组和项⽬经理以及相关⼈员发送了评审材料是否预定了会议室和预约了合理的时间是否准备了与会材料和⼯具（投影机等）是否主讲者已经演练了⼀下是否最好了被推翻重来的准备是否做好了听取改进意见的准备是否做好了改变原有思路的准备是否做好了⼤家都没有意见的准备是否做好了需要⼆次评审的准备是否做好了由于各种原因评审会失败的准备是否检查过了被评审材料压⼒测试检查表是否已经清楚了实际业务的压⼒情况是否已经预估了业务发展趋势和量化了增长速度是否预估了产品的⽣命周期是否预估了产品⽣命周期内业务量可能的峰值是否统计了业务峰值时间段以及峰值业务量是否已经明确了⽣产系统的主机分布。

12
是否描述了可接受的折中原则，如健壮性和正确性之间的选择？
13
是否详细说明了(最大)内存容量河(最大)存储容量？
14
是否详细说明了(最大)存储容量？
15
是否详细说明了系统的可维护性，包括适应操作环境变化的能力、与其它软件的接口、精确性、性能和附加的可以预知的性能？
16
有些信息只有到开发时才能获得，是否对这些信息不完全的领域进行描述？
从用户的角度来看，是否描述了对所有必要操作的预计响应时间？
7
是否对时间方面问题进行考虑，如处理时间、数据传输和系统的吞吐量？
8
是否描述用户想要完成的所有(主要)任务？
9
是否每个任务都描述了所使用的数据及产生的数据？
10
是否描述了安全级别？
11
是否描述了系统的可靠性，包括软件产生故障的后果、故障后重要数据的保护、错误检满意？是否有些部分不可能实现，但为了取悦客户或上司而放在需求之中？
18
是否用用户语言,站在用户角度上来写需求？用户这样认为吗？
19
是否所有的需求都避免与其它的需求发生冲突？
20
需求是否避免了对设计的详细说明？
21
对需求的描述是否一致？是否有的需求说明很详细，有的需求说明很粗？
22
需求是否足够清晰，以至可以转交给一个独立小组来实现，并能够被理解？
23
每个条款都是描述问题及解决问题吗？每个条款都能被追溯到问题的源泉？
24
每个需求是可测试的吗？是否可以通过独立的测试来决定需求是否被满足？
25
对需求的变更描述是否包括变更发生的可能性？
序号
内容
满足/正确
问题描述
1
是否描述系统的所有输入，包括输入源、准确性、取值范围和出现频率？

项目测试管理CheckList Prepared by Date 2009-10-26
编制日期
Reviewed by Date
审核日期
Authorized by Date
批准日期
All rights reserved
版权所有违版必究
1、内容填写说明
A、项目基本信息由测试用例设计者填写。

B、自检，根据检查结果在自检结果“是、否、免”相应栏中作“V”标记；是：满足要求，否：不满足要求，免：内容不涉及此项目；在“否、免”栏作“V”标记，必须在自检说明中填写原因。

C、审查，确认自检结果是否正确，如与审查项目一致：在互检结果“是”栏作“V”标记，否则：在审核结果“否”栏作“V”标记，并在审核说明中填写原因。

D、“自检结论及问题说明”由测试用例设计者填写，在此栏说明该项目检视的要点，方便审核者检查。

“审核结论及问题说明”由审核者填写，在此栏列出审核结果中为“否”的所有问题。

E、最终QA将此文档提交给运作支持部，进行数据备份，整个过程由运作支持部跟踪。