个人总结：自我介绍不要太短，也不能太长，两分钟为宜，IT行业的面试一般开头，面试官都会说让你自我介绍下 的，不规定时间的，个人的基本信息一概而过，太多了对你的面试也不会有什么好处，重点放在做过的项目，及学 到的东西和经验总结之类的，个人性格中的优点，缺点（与工作无关的，不影响工作的缺点）大概说下，这样一个从 内到外很清晰的你就展现在面试官面前了。 2 Bug管理
2.1 一个bug包括哪些属性？ 答：以QC为例：
摘要，状态，关闭日期，检测者，检测于版本，计划关闭版本，项目，分配给，主题，实际修复时间，关闭于版本， 检测日期，估计修复实际，优先级，可重新，严重程度，Bug的描述及相关的图片。
****** 红色为必填字段，经常在项目中使用的属性有，摘要，状态，关闭日期，检测者，检测于版本，项目，分配给，主题， 检测日期，优先级，可重现，严重程度，Bug的描述及相关的图片等属性，其它属性几乎不用。
《**ERP项目需求规格说明书》
Page 2 of 71
机构名称，2002
《**ERP项目需求规格说明书》
2.2 bug级别划分？ 答：以QC为例：
紧急，非常高，高，中，低。
紧急--------严重花屏，内存泄露，用户数据丢失或破坏，系统崩溃/死机/冻结，模块无法启动或异常退出， 非常高-----严重的数值计算错误，功能设计与需求严重不符，导致其他功能无法测试的错误 高-----------主要功能存在缺陷，但不会影响到系统稳定性。
功能未实现，功能错误，系统刷新错误，语言或数据通讯错误，轻微的数值计算错误， 系统所提供的功能或服务受到明显的影响
中----------操作界面错误，边界条件显示错误，提示信息错误，长时间操作无进度提示，系统未优化， 光标跳转设置不会，光标定位错误
低----------界面格式等不规范，辅助说明描述不清楚，操作时未给用户提示，可输入区和只读区没有明显的区分标志， 个别不影响产品理解的错别字，文字排列不整齐等一些小问题，建议
机构名称，2002
Page 3 of 71
《**ERP项目需求规格说明书》
机构名称，2002
Page 4 of 71
《**ERP项目需求规格说明书》
2.3 Bug有哪些状态及Bug生命周期？ 答：以QC为例：
Bug的状态有：新建（New），打开（Open），固定（Fixed），重新打开（Reopen），已否决（Rejected），已关闭（Closed）。
下面就对这几种状态进行以下解释： New：（新的）
当某个“bug”被发现的时候（第一次），测试人员记录下此Bug，此时Bug的状态为新建（New）。 Open：（打开的）
一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug” Fixed（已修复的）
当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed” Closed（已关闭的）
测试人员重新测试状态为Fixed（已修复）的Bug，经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为“Closed”
Reopen（再次打开的）
机构名称，2002
Page 5 of 71
《**ERP项目需求规格说明书》
如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组， 并将bug的状态设置为“Reopen” Reject（拒绝的）
如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态 设置为“Reject”。
******以上内容为本人在工作中实际应用，不同的管理工具，Bug的状态可能有很多种，但工作中实际中用到的就这么多。 2.4如何提交高质量的bug记录？
答： 我们一班用缺陷管理工具QC或JIRA提交。
2.5 在测试时，开发人员会说：“我们不需要懂那么多，我们不需要了解那么细，只需要从用户角度来测量就可以了” 如何面对这种情况？
答:从目前情况来看，开发普遍存在着对测试的误解，误认为测试是对项目工时 的一个附加，做测试不仅仅要测试自己看到的，也要测试自己看不到的冰山之下，
比如判断是否有内存泄露，是否有死锁，是否有不良SQl，是否满足性能需求，是否满足安全 需求等，这些纯用户角度无法度量。 2.6 bug有哪些类型？
类型 功能类 1，功能未实现 2，功能错误 描述 机构名称，2002
Page 6 of 71
《**ERP项目需求规格说明书》
3 功能设计与需求规格说明书不一致， 4 出现多余功能 5 正常操作，但存储内容不正确 6 功能未完全但不影响系统正常运行 数据类 1，数据丢失 2 数据来源不符合要求但操作成功 3 边界值超出正常范围导致出现1级bug现象 4 数据处理结果不正确 性能类 1 软件运行过程中死机 2 内存泄露 3 系统崩溃，导致系统变慢 4 长时间事务处理，无提示 界面类 1 UI与原型不一致 2 文字，颜色，图片错误等 3 界面设计不规范，没有考虑易用性问题 信息类 1 系统报非友好错误信息 2 必填项无提示 3 提示信息问题 安全类 建议类 偶然类 1 安全性漏洞 2 系统漏洞
机构名称，2002
Page 7 of 71
《**ERP项目需求规格说明书》
3. 测试计划
3.1测试计划工作的目的是什么？测试计划工作的内容都包括什么？
答：测试计划的目的是为了开展测试工作更加顺利，使其工作保质保量的按时完成。 测试计划包括：
1，项目简介，测试目的，参与者 2，测试所需的软硬件配置 3，测试人员分工 4，测试内容及步骤 5，测试开始和结束时间 6，测试风险分析 ， 3.2 做好测试计划工作的关键是什么？ 1.明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对 帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试 方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确 2.坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、 “How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试 的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和 软件的存放位置（Where）
3.采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容， 或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员 4.分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放 到创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系
机构名称，2002
Page 8 of 71
《**ERP项目需求规格说明书》
，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术 3.2 如何制定测试过程中的时间进度表的
答案:根据项目的需求、开发周期、开发人员的开发进度等时间安排来制定一个测试时间进度初 稿，
并将测试时间进度表交与整个项目团队成员大家一起讨论和分析，最终和所有人达成共识制定出一个大家都可以 执行的测试时间进度表。
时间表中包括了开发人员提交功能或功能模块的时间，以及为了更好的执行测试，配合测试人员进行功能培训的时间，以及测试执行时间等，都详细的写到WBS中，并按照这个时间进度表来执行项目的测试任务。 4. 测试分析例子 4.1 圆珠笔测试分析
功能测试： 圆珠笔按下是否能正常写字，写字太重会不回缩回去，继续按会不会弹回去 性能测试：圆珠心弹出弹回的快慢
负载测试：一直按，弹簧能接受多少次的升缩 兼容性测试：换其他的笔芯能不能行 强度测试：用力过度会怎样
可恢复性测试：如果弹簧压久了，是否可恢复等等 GUI测试：笔的外观，拿笔的舒适性
安全性：考虑对笔芯的保护，是否对使用者造成危害等等 4.2 水杯测试分析
功能度：用水杯装水看漏不漏；水能不能被喝到。
机构名称，2002
Page 9 of 71
《**ERP项目需求规格说明书》
安全性：杯子有没有毒或细菌，检查水杯被破坏后，是否会造成使用者伤害。 可靠性：杯子从不同高度落下的损坏程度。
可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用。 兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等。 易用性：杯子是否烫手、是否有防滑措施、是否方便饮用。
GUI测试：看其形状、大小设计是否适合人方便拿起；外观是否吸引人（广告嘛），赏心悦目；
带广告的图案沾水后是否掉色、模糊。
安全性：考虑对笔芯的保护，是否对使用者造成危害等等。 4.3 电梯测试分析
功能测试：
1.测试电梯能否实现正常的上升和下降功能。 2.电梯的按钮是否都可以使用。 3.电梯门的打开，关闭是否正常。 4.报警装置是否可用。
5.与其他电梯之间是否协作良好。 6.通风状况如何。 7.突然停电时的情况。 8.上升途中的响应。
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来； 2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
机构名称，2002
Page 10 of 71
《**ERP项目需求规格说明书》
可靠性：
1.门关上的一刹那出现障碍物。 2.同时按关门和开门按钮。 3.点击当前楼层号码。
4.多次点击同一楼层的号码等等。 5.同时按上键和下键会怎样。
易用性：
1.电梯的按钮的设计符合一般人使用的习惯吗．
负载/压力测试：
1.看电梯的最大限度的承受重量．在负载过重时是否有提醒。 2.在一时间内不断的让电梯上升，下降。
稳定性测试：
1.最大负载下平稳运行的最长时间。
文档测试：
1.使用手册是否对电梯的用法、、使用条件等有详细描述
另外，这个面试题目还可以推广到其它物品，比如手机、电饭煲、电梯等。
******现在面试，面试官最喜欢出这样的题了，他们随便从身边拿个东西就让你分析，真烦人，不过逐类旁通， 对于这些不同的东西，考虑的方面是相同的，多分析几个，遇到新的物体就不会很难了。如三角形分析，自动 售货机等。
机构名称，2002
Page 11 of 71
《**ERP项目需求规格说明书》
5. 测试用例
5.1一个测试用例一般包括那些部分 答：以QC为例：
测试用例大致由用例编号、用例名称、测试目的、测试级别、参考信息、测试环境、前置条件、 测试步骤、预期结果、设计人员等元素构成。
5.2 以往的工作是否开展过测试用例评审，描绘出评审过程和内容
答： 是的，我们评审测试用例有测试经理和测试成员一起参加，首先是每个测试成员介绍自己的测试用例， 主要是对那些方面进行测试，进行覆盖，然后测试经理点评，成员共同讨论。
评审内容主要是对测试用例的覆盖面，用例的语言表达通俗易懂方面，结构简洁方面考虑。 5.3 功能测试都包括哪些内容？ 1、添加数据
2. 能够正常录入，并添加成功
3. 输入特殊字符或超长字符，负数，必填项不填等是否有提示信息
4. 点击保存数据是否真的保存到数据库，可以通过软件查询功能验证或到数据库查看 5. 点击重置按钮数据是否清空
6. 输入编程的敏感字符（如：JavaScript,’,<>），系统是否能正常运行 7. 输入重复的ID号是否有提示信息 8. 要考虑输入法全角和半角所占字符问题
9. 在购物系统中要考虑到防止在一段时间里重复提交表单的功能 -------
机构名称，2002
Page 12 of 71
《**ERP项目需求规格说明书》
10. 默认值的情况也应该要注意 2、删除数据
1.能够正确的将数据删除，并有成功提示 2.提示删除成功，数据是否真的删除
3.不选择要删除的数据，应有提示请选择要删除的记录。 4.有多选功能要验证是否能删除多条记录
5.提示是否删除记录时，选择否，看数据是否能够保留--------------
6 对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会。 3、查询数据
1.输入正确完整的信息，能够将数据正确显示 2.数据不存在时，应有提示信息或以空表显示
3.输入特殊的或超长字符，负数，必填项不填是否有提示信息（特殊系统）
4.有日期输入框的时候，要考虑开始日期不能大于结束日期。若做月末报表查询时要考虑，开始日期和结束日期在同一月内（特殊系统） 5.输入编程的敏感字符（如：JavaScript），系统是否能正常运行 6.要考虑输入法全角和半角所占字符问题 4、修改数据
1.能够自动将要修改的数据提到修改数据框中 2.要保证编号不能修改
3. 修改的数据应符合添加数据的规则
4. 修改完数据后要进入数据库或输入编号看数据是否真的修改 5、导出数据
1.不输入要导出的路径，应有提示信息
2.输入的路径是一些不符合规则的数据，要有提示信息
3.输入正确的路径能够成功导出数据，并检验数据是否导出到目标地址
机构名称，2002
Page 13 of 71
《**ERP项目需求规格说明书》
4.对于有些导出文件功能还要验证是否安装控件 5.导出数据量比较大时要有能够检测硬盘空间够不够用 6.输入的目标路径不存在要有提示 7.导出的数据是否和原数据一致。 6、导入或上传数据
1.没有选择上传或导入数据的路径时要有提示 2.上传的路径不符合字符规则要有提示
3.上传的数据或文件，图片不符合校验规则要有提示（如：数据过大，文件或图片格式不正确） 4.目标路径不存在要有提示
5.导入或上传的数据操作成功，有提示且要检验数据是否真的存在
6导入的数据或文件是否对该系统的兼容性或稳定性造成影响。（例如导入的是一个病毒文件让系统的某些文件不能正常运行） 7.导入或上传数据是否和原数据一致。 7、用户权限
1.首先检验分配的权限能否使用 2.检验分配的权限是否各职其责
3.不同的角色有不同的权限，应该有相应的用户去验证权限。 8、数据字典
1.首先检验数据字典的下发数据是否完整 2.数据字典的数据是否能够正确使用
3. 在用数据字典时要能够正确的校验使用数据字典的规则 9、发送邮件
1.要有能够检验输入的邮件地址是否符合邮件书写规则 2. 输入一个正确的邮件地址要能发送成功
3.要有支持群发的功能，即输入多个邮件地址也能发送成功
机构名称，2002
Page 14 of 71
《**ERP项目需求规格说明书》
4.选择发送并保存的话，要能够保存 5 看邮件是否能够定时发送
6.验证正确的邮件地址接受到得邮件是否和发送时一致（数据和文件格式）。 10、设定定时任务
1.设定定时任务时，要符合日期和时间的设置规则（如：时间范围应为00-24，月要保证是01-12，年要保证大于0） 2.要检验到达设定时间，任务是否真的触发
3在设定时间时看输入明显不合理的时间是否会出现提示（例如，订票时间是2015年.月.日） 4 在测试时间时要保证终止日期大于开始日期。 11、登录
1.输入正确的用户名和密码，要能够正确登录 2.输入的密码或用户名错误时，要有提示信息 3.密码要能够隐藏
4.输入的用户名和密码要符合输入规则（如：长度要符合规则或符合程序设置的规则），不符时要有提示示例信息 5.对于金融系统，密码输入错误次数过多要有锁定密码的功能 6输入空值时是否能直接登录 7.密码不能复制粘贴 12、注销或退出系统
1.点击注销功能时，能够直接跳转到登录页面 2.退出系统时，程序能够被关闭 13、界面
1.要检验界面是否整洁，明了，布局美观 2.应有的导航菜单或按键是否存在
3.超链接功能键是否能正常使用，且跳转页面正确 4.文字是否完整，大小是否合适
机构名称，2002
Page 15 of 71
《**ERP项目需求规格说明书》
5．是否符合用户习惯
6． 菜单、按钮的位置是否一致 14、安全
5. 在登录框中输入登录信息后，用get方式提交时绝不能让密码显示在网址信息上 6. 在长时间不操作页面时会自动跳到登录页面或用户操作时失效或自动跳转到指定页面。 7. 在没有登录时，不能间接的输入主页面的网址就能显示主页面，要有过滤。 8. 在金融系统中注意要有可恢复测试，自动备份或转移测试。
5.4 一个文本框要求输入10个字符的邮政编码，如何设计测试用例?
答：1.考虑文本框输入长度应在大于0小于10的范围 2.要保证输入框是纯数字。
3.要考虑输入的纯数字符合邮政编码检验规则。 4.输入超出范围的字符要 有提示
5.输入一些特殊字符和非数字字符要有提示 6.注意输入法全角和半角问题
5.5 怎样设计测试用例
答案：在测试用例设计之前首先要熟悉客户的需求文档或需求规格说明书，以做到对被测系统的熟悉，充分了解产品的详细功能， 并在熟悉过程中即使与研发人员和客户人员进行有效的沟通。然后从需求中提炼中各个模块的详细功能点编写出
机构名称，2002
Page 16 of 71
《**ERP项目需求规格说明书》
一个测试要点的文档。根据测试要点设计测试用例，测试要点与测试用例是一个一对多的关系，一个测试要点可能会需要几个测试 用例的验证，有正常的操作和异常的操作，甚至是几个正常与几个异常的操作，这要根据实际功能的要求来具体分析具体实现。 一是测试用例对需求覆盖的完整性；二是测试用例的有效性；
三测试用例的可理解性四是测试用例的清晰性；五是测试用例的可维护性。
一个好的方法就是用mm图把需求分解了。把基本路径分解出来，将需求归类。理顺了需求，用例写起来就顺手的多。在编写用例 的过程中进行等价类的划分，最后用判定表进行评判，补充缺少的用例，剔除冗余的用例。做到对需求的100%覆盖。也就是说拿 到需求文档必须进行必要的分析，不能上来就盲目的写用例，
5.6 使用场景法设计测试用例
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。场景法一般包含基本流和备用流，从一个流程开始， 通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。
为什么场景法能如此清晰的描述整个事件？因为，现在的系统基本上都是由事件来触发控制流程的。如：我们申请一个项目， 需先提交审批单据，再由部门经理审批，审核通过后由总经理来最终审批，如果部门经理审核不通过，就直接退回。每个事件 触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。这一系列的过程我们利用场景法可以清晰的 描述清楚。
下图来展示一下网上最长见的场景法基本情况的一个实例图。
机构名称，2002
Page 17 of 71
《**ERP项目需求规格说明书》
在这个图中，有一个基本流和四个备选流。
每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景： 场景 1 基本流
机构名称，2002
Page 18 of 71
《**ERP项目需求规格说明书》
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2 场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2 场景 7 基本流 备选流 4
场景 8 基本流 备选流 3 备选流 4
从上面的实例我们就可以了解场景是如何利用基本流和备用流来确定的。
基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源 于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况） 下面是场景法的基本设计步骤
1. 根据说明，描述出程序的基本流及各项备选流 2. 根据基本流和各项备选流生成不同的场景 3. 对每一个场景生成相应的测试用例
4. 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值
机构名称，2002
Page 19 of 71
《**ERP项目需求规格说明书》
好了。说了一些场景法的基本概念和设计方法。想必大家已经有了一些了解了。再举一个简单例子来讲解下。这里，我就 不用网上很流行的ATM的例子了。我结合以前项目中遇到的情况。设计一个简单的例子来讲解下。
有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。 第一步我们来确定基本流和备选流：
第二步我们根据基本流和备选流来确定场景：
机构名称，2002
Page 20 of 71
《**ERP项目需求规格说明书》
第三步我们来设计用例
对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。 下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。
本例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已 经存在于数据库中）以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当 条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，
机构名称，2002
Page 21 of 71
《**ERP项目需求规格说明书》
而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。
第四步我们来设计数据，把数据填入上面的用例表中。
机构名称，2002
Page 22 of 71
《**ERP项目需求规格说明书》
5.7 什么样的测试用例才算好的用例 一个好得测试用例，需要满足16个字：
结构清晰 内容准确 易于统计 便于维护 5.8 翻页的测试用例
答：1、有无数据时控件的显示情况
2、在首页时，首页和上一页是否能点击 3、在尾页时，下一页和尾页是否能点击
4、在非首页和非尾页时，四个按钮功能是否正确
机构名称，2002
Page 23 of 71
《**ERP项目需求规格说明书》
5、翻页后，列表中的记录是否仍按照指定的排序列进行了排序
对于“总页数，当前页数总页数，当前页数”，主要要检查的测试点有： 1、总页数是否等于总的记录数/指定每页条数 2、当前页数是否正确
5.9 设计测试用例的方法有哪些，举例说明？ 1．等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地 假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个 等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种 不同的情况:有效等价类和无效等价类 2.边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不 是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应 当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据 3.错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在 单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数 据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子 作为测试用例 4．因果图方法
机构名称，2002
Page 24 of 71
《**ERP项目需求规格说明书》
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输 入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分 成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式 来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的 各种组合情况
5.10 测试用例的设计方法
等价类划分法：是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性 的数据作为测试用例。等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合 理地假定:测试某等价类的代表值就等于对这一类其它值的 测试.因此,可以把全部输入数据合理划分为若干等价类,在每一 个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.
·边界值分析法：长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的 内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选 取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. ·错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在 单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据 和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作 为测试用例. ·因果图法
·判定表驱动分析法 .正交实验设计法
机构名称，2002
Page 25 of 71
《**ERP项目需求规格说明书》
5.11 注册功能测试用例
我们要从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，Email，出生日期，地址，性别等等 一系列的格式和字符要求，那就都要写用例了 以等价类划分和边界值法来分析
1.填写符合要求的数据注册:用户名字和密码都为最大长度 （边界值分析，取上点） 2.填写符合要求的数据注册 :用户名字和密码都为最小长度 （边界值分析，取上点）
3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点） 4.必填项分别为空注册
5.用户名长度大于要求注册1位（边界值分析，取离点） 6.用户名长度小于要求注册1位（边界值分析，取离点） 7.密码长度大于要求注册1位（边界值分析，取离点） 8.密码长度小于要求注册1位（边界值分析，取离点）
9.用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了,如含有空格，#等，看需求是否允许吧~） 10.密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了） 11.两次输入密码不一致(如果注册时候要输入两次密码，那么这个是必须的） 12.重新注册存在的用户
机构名称，2002
Page 26 of 71
《**ERP项目需求规格说明书》
13.改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分） 14.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以*之类的加秘符号显示 5.12 打印测试用例 打印机测分
1.连接测试，能否连同
2.输入错误的链接路径，点击打印 3.输入正确的链接路径，点击打印 4.没有安装打印机驱动，进行打印
5.打印的过程稳定性如何，是否不打印，或打印为空，打印机停止作业 6.打印出来的字是否和文档一致，有无乱码，排列顺序错误。
6 测试总结
6.1 测试报告包括那些项
测试用例的通过数，测试用例的未通过数，以及测试用例的通过率，未通过的功能都集中在哪几个功能模块 ， 根据测试经验以及测试结果进行一个缺陷的分析和建议。
机构名称，2002
Page 27 of 71
《**ERP项目需求规格说明书》
7 项目整体测试流程
7.1 测试工作进行到一半，突然发现时间不够，怎么办？
答案：1.与客户沟通本次发布的版本什么是最重要的，什么是其次，
我会安排一个优先级来对整体测试功能进行一个筛选。 2.我会和测试组原体人员一起加班 7.2 如果你是测试组长你如何对项目及组员进行管理
答案： 首先要从需求开始，充分了解被测系统的功能以及业务需求， 并在遇到问题的时候及时有效的与开发人员以及其他项目相关人员进行沟通，
做到最被测系统的十分熟悉。并了解整个测试组的成员他们的测试技能以及擅长的工作， 做到测试任务的合理分配，得以让测试工作快速，稳定高效的进行！ 7.3 功能测试流程
答：大致流程为：熟悉需求->需求评审->编写测试计划->测试计划评审->测试分析->测试分析评审->搭建 测试用例框架->编写测试用例->测试用例评审->修改测试用例->冒烟测试->执行用例，提交Bug->bugFixed验证 ->回归测试->测试结束评审->编写测试报告。 详解：
测试人员在编写需求分析时参与进去，了解项目的背景和客户需求，然后根据项目开发进度编写测试计划。 测试计划包含以下内容：设计测试用例时间，执行测试用例时间，和回归测试时间，这个时间要按项目进度 来制定，保证计划的正常执行。
写完测试计划后不用急着写测试用例，首先要确定需求分析是不是已经编写完成，并经过了评审，如果评审 已完成就要尽可能多了解需求分析，根据需求分析编写测试要点，所谓测试要点就是测试用例的框架，把需求
机构名称，2002
Page 28 of 71
《**ERP项目需求规格说明书》
分析中的用户要求和用户业务记录下来，然后区分哪些是主要需求，哪些是次要需求。便于测试的全面和测试 重点突出。
编写完测试要点后，再开始编写测试用例。所谓测试用例就是指测试某项功能时所作的输入数据或动作，并列出 期望的输入数据或动作。编写测试用例就是用实际的操作来证明前面所写的测试要点中功能点和业务实现。 测试用例编写完成后开始测试。
测试完成后及时把报告反馈给开发人员，便于开发人员修改。当开发人员修改完成后，进入回归测试，回归测试的做法 是把发现问题的测试用例和它有关联的测试用例重新执行一遍，如果没有问题，测试完成，否则再次提交测试报告，直到 测试完成。
7.4 v模型跟w模型的优缺点 V模型 优点：
1，既有底层测试又有高层测试。底层:单元测试。高层：系统测试
2，将开发阶段清楚地表现出来，便于控制开发的过程。当所有阶段都结束时，软件开发就结束了。 缺点：
1，容易让人误解为测试是在开发完成之后的一个阶段
2，由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难 3，实际中，由于需求变更较大，导致要重复变更需求，设计，编码，测试，返工量大。 W模型 优点：
1，将测试贯穿到整个软件的生命周期，且除了代码要测试，需求，设计等都要测试。 2，更早的介入到软件开发中，能尽早的发现缺陷并进行修复。
机构名称，2002
Page 29 of 71
《**ERP项目需求规格说明书》
3，测试与开发起来，并与开发并行。 缺点：
1，对有些项目，开发过程中根本没有文档产生，故W模型无法使用。 2，对于需求和设计的测试技术要求很高，实践起来很困难。
8 功能测试与性能测试比较
8.1 测试类型有哪些，它们的区别与联系 测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。
通过负载测试，确定在各种工作负载下系统的性能，
目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。 压力测试是通过确定一个系统的瓶颈或者不能接收的性能点， 来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
机构名称，2002
Page 30 of 71
《**ERP项目需求规格说明书》
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。 性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，
用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试
9 黑盒测试与白盒测试比较
9.1 黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误： 1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？ 3、是否有数据结构错误或外部信息（例如数据文件）访问错误？ 4、性能上是否能够满足要求？ 5、是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
机构名称，2002
Page 31 of 71
《**ERP项目需求规格说明书》
1、对程序模块的所有的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性，等等
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。 集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样
9.2 分别说明黑盒测试和白盒测试的优点和缺点?
答：黑盒测试的优点有：
1）比较简单，不需要了解程序内部的代码及实现；
2）与软件的内部实现无关；
机构名称，2002
Page 32 of 71
《**ERP项目需求规格说明书》
3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
5）在做软件自动化测试时较为方便。
黑盒测试的缺点有：
1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；
2）自动化测试的复用性较低。
白盒测试的优点有：
帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
白盒测试的缺点有：
1）程序运行会有很多不同的路径，不可能测试所有的运行路径；
2）测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；
3）系统庞大时，测试开销会非常大。
机构名称，2002
Page 33 of 71
《**ERP项目需求规格说明书》
10 自动化测试工具 10.1 对自动化才测试的看法
自动化测试，主要借助于WinRunner、QuickTest Professional等自动化测试软件，进行一些诸如数据校验、增强测试、运行测试、维护测试等可自动化测试的测试内容。
10.2 平时用QTP工具吗？在什么时候开始用？会不会写脚本？用的时候页面的覆盖率有多少？如何页面发生变化了，是不是要重新再录一边脚本？脚本修改的频繁吗？
平时也用QTP，是在回归的时候用，脚本会编写，我们用的时候是一个售票系统，覆盖范围不多就是注册、登录等页面。如果页面发生变化不会去重新录，我们会加一个检查点，并进行参数化，脚本修改频率要看需求一般修改频率不是很大。 10.3 QTP中的检查点是如何添加的？
在录制的过程中，把页面转到QTP，选择插入菜单，不就可以插入检查点了 insert 菜单> checkpoint
也可能录制完后添加，在页面中选中要检查的文字，点击右键选择
具有测试效率高，节约人力时间的优点。可以实现一些手工测试无法实现的测试项目，如并发访问的压力测试、极限测试等项目。 但自动化测试和手工测试相比，无法实现如用户体验测试的业务性测试，更加适合一些大量的重复性测试。
机构名称，2002
Page 34 of 71
《**ERP项目需求规格说明书》
11 个人问题
11.1 为什么想进本公司？
答：因为我觉的在贵公司能够学到很多东西，更有很大的发展潜力，不像那些已成规模的大公司，做工过于太细，已形成流水线化。枯燥而学不到很多知识。想发展更是艰难。在贵公司我可以不断的完善自己，挑担自己，工作会更有激情。 11.2 喜欢这份工作的哪一点？
答：我以前是做软件开发的，那种工作是枯燥的，而作测试工作，可以在一种软件未上市前先了解，还可以知道很多软件的功能，另外正因为做软件测试要懂很多，明白很多。所以我感觉做这一行更了解和学习很多知识。 11.3 自己的优缺点？
答：我觉得我个人的优点就是，沉着冷静，乐于助人，容易和人相处，对工作负责，做事认真，处事谨慎。我的缺点是胆子没有那么大，比如开车吧！我就不会。另外就是不善于表现自己，有一点自卑的感觉。
11.4 对公司的了解有多少？
答：阿里巴巴是一家年轻的发展中的公司
机构名称，2002
Page 35 of 71
《**ERP项目需求规格说明书》
阿里巴巴,他是一个很注重价值观的企业,他的价值观就是\"六脉神剑\
我知道咱们公司处于快速发展的阶段。
11.5 对公司的期望与目标何在？
答：我的目标是不断完善自己，能够更熟练的掌握测试技术，争取成为一名优秀的工程师。同时也希望公司不断扩大，个人在职位上也有提升的空间。
11.6 为什么要离职？
回答这个问题时一定要小心，就算在前一个工作受到在大的委屈，对公司有多少的怨言，都千万不要表现出来，尤其要避免对公司本身主管的批评，避免面试官的负面情绪及印象；建议此时最好的回答方式是将问题归咎在自己身上，例如觉得工作没有学习发展的空间，自己想在面试工作的相关产业中多加学习，或是前一份工作与自己的生涯规划不合等等，回答的答案最好是积极正面的。
11.7 选择这份工作的原因为何？
这是面试官用来测试应聘者对工作理解度的问题，藉以了解求职者只是基于对工作的憧憬或是确实的兴趣来应徵这份工作，此时之前所强调的事先研究功夫又再度派上用场，建议你的回答应以个人的兴趣配合工作内容特质，表现出高度的诚意，这样才可以为自己铺下迈向成功之路。
机构名称，2002
Page 36 of 71
《**ERP项目需求规格说明书》
11.8 你认为相关产业的发展为何？
这也是事前准备的功夫，多阅读一些相关的报章杂志，做一些思考，表现出自己对此相关产业的的认识，如果是同业转职者，可强调以自己的经验为基础所做的个人见解，但若是初次接触此一行业，建议采取较为保守的方式，以目前资讯所提供的资料为主作答，表现出高度兴趣及诚意为最高指导原则。
11.9 你期望的待遇是多少？？
我对工资没有硬性要求，我相信贵公司在处理我的问题上会友善合理。我注重的是找对工作机会，所以只要条件公平，我则不会计较太多。 11.1.0 在工作中学到了什么
这是针对转职者提出的问题，建议此时可以配合面试工作的特点作为主要依据来回答，如业务工作需要与人沟通，便可举出之前工作与人沟通的例子，经历了哪些困难，学习到哪些经验，把握这些要点做陈述，就可以轻易过关了 11.6 你朋友是怎样评价你的？
我的朋友都说我是一个可以信赖的人。因为，我一旦答应别人的事情，就一定会做到。如果我做不到，我就不会轻易许诺。 我觉的我是一个比较随和的人，与不同的人都可以友好相处。在我与人相处时，我总是能站在别人的角度考虑问题。
11.7 怎样看待加班？
如果是工作需要我会义不容辞加班，我现在单身，没有任何家庭负担，可以全身心的投入工作。但同时，我也会提高工作效率，减少不必要的加班。
机构名称，2002
Page 37 of 71
《**ERP项目需求规格说明书》
11.8 团队合作精神
答：作为小组的一名优秀员工，我会树立起团队协作的意识，及时与同事进行有效积极地沟通，有问题及时向他们请教，与他们取长补短，共同完成工作任务。
11.9 沟通能力
沟通是合作的开始，优秀的团队一定是一个沟通良好、协调一致的团队。没有沟通就没有效率。沟通带来理解，理解带来合作。身为小组核心份子，我会虚心接受老师和同学在工作上的指导和意见建议，及时与领导沟通，有问题及时向同事请教，积极地听取他们的意见和建议，不断努力学习，不断调高自己
11.10 一个好的测试工程师需要哪些能力？
答 1 沟通能力 2 技术能力 3 自信心 4 外交能力 5 幽默感 6 很强的记忆力 7 怀疑精神 8 自我督促
机构名称，2002
Page 38 of 71
《**ERP项目需求规格说明书》
12 面试反问
12.1 我什么时候能知道结果呢？ 12.2 我的职责是什么？
12.3 我会接受何种培训，参加培训对我本人有什么要求？ 12.4 我应该具有什么样的才智才能做好这份工作？
12.5 公司的长远目标和战略计划您能否用一两句话简要为我介绍一下12.5您考虑这个职位上供职的人应有什么素质？
13 Linux 常用命令 13.1 显示目录和文件的命令
Ls：用于查看所有文件夹的命令。 Dir：用于显示指定文件夹和目录的命令。 Tree： 以树状图列出目录内容 Du：显示目录或文件大小
机构名称，2002
Page 39 of 71
《**ERP项目需求规格说明书》
13.2 修改目录，文件权限和属主及数组命令 Chmod：用于改变指定目录或文件的权限命令。 Chown：用于改变文件拥有属性的命令。 Chgrp：用于改变文件群组的命令。
Chattr：用于设置文件具有不可删除和修改权限。 Lsattr：用于显示文件或目录的隐藏属性。 13.3 创建和删除目录的命令 Mkdir：用于创建目录 Rmdir：用于删除空的目录 Rm -f：用于删除不为空的目录
13.4 创建和删除，重命名，复制文件的命令 Touch：创建一个新的文件 Rm：删除文件或目录
Mv：重命名或移动文件的命令 Cp：复制命令
Scp：用于将本地的文件或目录复制到远程服务器 Wget：用于下载ftp或http服务器文件到本地。 机构名称，2002
Page 40 of 71
《**ERP项目需求规格说明书》
13.5 显示文件内容的命令
Cat：用于显示指定文件的全部内容 More：用分页的形式显示指定文件的内容
Less：用分页的形式显示指定文件的内容，区别是more和less翻页使用的操作键不同。 Head：用于显示文件的前n行内容。 Tail：用于显示文件的后n行内容。
Tail -f：用于自动刷新的显示文件后n行数据内容。 13.6 查找命令
Find：查找指定目录或文件的命令。
Whereis：查找指定的文件源和二进制文件和手册等。 Which：用于查询命令或别名的位置。 Locate：快速查找系统数据库中指定的内容。
Grep：在指定的文件或标准输出，标准输入内，查找满足条件的内容。 13.7 关机和重启计算机的命令
Shutdown：-r 关机后立即重启
-k 并不真正的关机，而只是发出警告信息给所有用户 -h 关机后不重新启动 Poweroff：用于关机和关闭电源 Init：改变系统运行级别
机构名称，2002
Page 41 of 71
《**ERP项目需求规格说明书》
0级用于关闭系统 1 级用于单一使用者模式
2级用来进行多用户使用模式（但不带网络功能） 3级用来进行多用户使用模式（带网络全功能） 4级用来进行用户自定义使用模式 5级表示进入x windows时的模式 6级用来重启系统 Reboot： 用于计算机重启 Halt：用于关闭计算机系统 13.8压缩和打包命令
Tar：用于多个文件或目录进行打包，但不压缩，同时也用命令进行解包 Gzip：用于文件进行压缩和解压缩命令，文件扩展名为.gz结尾。 Gunzip：用于对gzip压缩文档进行解压缩。 Bzip2：用于对文件或目录进行压缩和解压缩 Bzcat：用于显示压缩文件的内容。
Compress/un compress： 压缩/解压缩.Z文件 Zcat：查看z或gz结尾的压缩文件内容。 Gzexe：压缩可执行的文件 Unarg：解压缩.arj文件 Zip/unzip:压缩解压缩.zip文件
机构名称，2002
Page 42 of 71
《**ERP项目需求规格说明书》
13.9 用户操作命令
Su：切换用户命令
Sudo：一系统管理员的身份执行命令 Passwd：用于修改用户的密码 13.10 改变目录和查看当前目录命令 Cd：进入工作目录 Cd 。。：会退到上一级命令
Pwd：显示当前用户所在工作目录位置 13.11 文件连接命令
Ln：为源文件创建一个连接，并不将源文件复制一份，即占用的空间很小。可以分为软件连接和硬链接。
软连接：也称为符号连接，即为文件或目录创建一个快捷方式。
硬链接：给一个文件取多于一个名字，放在不同目录中，方便用户使用。 Ln命令参数如下：
-f：在创建连接时，先将与目的对象同名的文件或目录删除。 -d：允许系统管理者硬链接自己的目录。
-i：在删除与目的对象同名文件或目录时先询问用户。 -n：在创建软连接时，将目的对象视为一般的文件。 -s：创建软连接，即符号连接。
机构名称，2002
Page 43 of 71
《**ERP项目需求规格说明书》
-v：在连接之前显示文件或目录名。
-b：将在连接时会被覆盖或删除的文件进行备份。 13.11 帮助命令-----man 13.12 其他命令
Who：显示系统中有那些用户在使用。 -ami 显示当前用户 -u：显示使用者的动作/工作 -s：使用简短的格式来显示 -v：显示程序版本
Free：查看当前系统的内存使用情况 Uptime：显示系统运行了多长时间 Ps：显示瞬间进程的动态
Pstree：以树状方式显示系统中所有的进程 Date：显示或设定系统的日期与时间。 Last：显示每月登陆系统的用户信息 Kill： 杀死一些特定的进程 Logout：退出系统
Useradd/userdel:添加用户/删除用户 Clear：清屏
Passwd：设置用户密码
8.vi编辑器
机构名称，2002
Page 44 of 71
《**ERP项目需求规格说明书》
首先用vi命令打开一个文件 末行模式命令：
:n,m w path/filename 保存指定范围文档（ n表开始行，m表结束行） :q! 对文件做过修改后，强制退出 :q 没有对文件做过修改退出 Wq或x 保存退出 9.网络通信常用的命令 Arp：网络地址显示及控制 ftp：文件传输 Lftp：文件传输
Mail：发送/接收电子邮件
Mesg：允许或拒绝其他用户向自己所用的终端发送信息 Mutt E-mail 管理程序 Ncftp ：文件传输
Netstat：显示网络连接.路由表和网络接口信息 Pine：收发电子邮件，浏览新闻组 Ping：用于查看网络是否连接通畅 Ssh：安全模式下远程登陆 Telnet：远程登录 Talk：与另一用户对话
Traceroute：显示到达某一主机所经由的路径及所使用的时间。 Wget：从网路上自动下载文件 Write：向其它用户终端写信息 Rlogin：远程登录
机构名称，2002
Page 45 of 71
《**ERP项目需求规格说明书》
14 web测试
14.1 web测试的常用测试方法
1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
3. 检查按钮的功能是否正确：如update、cancel、delete、save等功能是否正确。
4. 字符串长度检查：输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。
5. 字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型)，看系统是否检查字符类型，会否报错。
6. 标点符号检查：输入内容包括各种标点符号，特别是空格、各种引号、回车键。看系统处理是否正确。
7. 中文字符处理：在可以输入中文的系统输入中文，看会否出现乱码或出错。
机构名称，2002
Page 46 of 71
《**ERP项目需求规格说明书》
8. 检查带出信息的完整性：在查看信息和update信息时，查看所填写的信息是不是全部带出，带出信息和添加的是否一致。
9. 信息重复：在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。
10. 检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按“delete”，看系统如何处理，会否出错;然后选择一个和多个信息，进行删除，看是否正确处理。
11. 检查添加和修改是否一致：检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填;添加规定为整型的项，修改也必须为整型。
12. 检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报错。同时，也要注意，会不会报和自己重名的错。
13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
14. 检查多次使用back键的情况：在有back的地方，back，回到原来页面，再back，重复多次，看会否出错。
15. search检查：在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。
16. 输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。
17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检
机构名称，2002
Page 47 of 71
《**ERP项目需求规格说明书》
查系统是否能够做到。
18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了。
20. 回车键检查：在输入结束后直接按回车键，看系统处理如何，会否报错。 14.2 B/S C/S的区别
Cs是建立在局域网基础上的，bs是建立在广域网基础上的， １．硬件环境不同:
C/S 一般建立在专用的网络上, 小范围里的网络环境, 局域网之间再通过专门服务器提供连接和数据交换服务.
B/S 建立在广域网之上的, 不必是专门的网络硬件环境,例与电话上网, 租用设备. 信息自己管理. 有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行
２．对安全要求不同
C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强. 一般高度机密的信息系统采用C/S 结构适宜. 可以通过B/S发布部分可公开信息.
B/S 建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群.
３．对程序架构不同
C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑.
机构名称，2002
Page 48 of 71
《**ERP项目需求规格说明书》
B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的.Net系列的BizTalk 2000 Exchange 2000等, 全面支持网络的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟.
４．软件重用不同
C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好.
B/S 对的多重结构,要求构件相对的功能. 能够相对较好的重用.就如买来的餐桌可以再利用,而不是做在墙上的石头桌子。
５．系统维护不同
系统维护是软件生存周期中,开销最大,最重要的。
C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级. 升级难. 可能是再做一个全新的系统
B/S 构件组成,方面构件个别的更换,实现系统的无缝升级. 系统维护开销减到最小.用户从网上自己下载安装就可以实现升级.
６．处理问题不同
C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与操作系统相关. 应该都是相同的系统 B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的. 与操作系统平台关系最小.
７．用户接口不同
C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高
B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流. 并且大部分难度减低,减低开发成本.
８．信息流不同
C/S 程序一般是典型的集权的机械式处理, 交互性相对低
B/S 信息流向可变化, B-B B-C B-G等信息、流向的变化, 更象交易中心
机构名称，2002
Page 49 of 71
《**ERP项目需求规格说明书》
14.3 C/S B/S的优缺点
B/S的缺点：响应速速慢，安全性差，对网络要求高 B./S的优点：分布性好，任何时间、任何地点、任何系统，
只要可以使用浏览器上网，就可以使用B/S系统的终端 ；维护简单方便，开发成本较C/S低，共享性强 C./S的缺点：兼容性差，维护成本高
C/S的优点：响应速度快，最大程度的满足客户个性化需求，事务处理能力强，能处理比较复杂的业务流程 14.4 web软件常用的测试要素 1，页面部分
（1）页面清单是否完整（是否已经将需要的页面全部都列出来了）
（2）页面是否显示（在不同的分辨率下页面是否存在，在不同的浏览器版本中页面是否显示） （3）页面在窗口中的显示正确，美观（在调整浏览器窗口大小时，屏幕刷新是否正确） （4）页面特殊效果（如特殊字体效果，动画效果）是否显示。 （5）页面特殊效果显示是否正确 2 页面元素部分 （1）页面元素清单 （2）元素是否显示
（3）页面元素是否显示正确（主要针对文字，图形，签章） （4）页面元素的外形，摆放位置 （5）页面元素基本功能是否实现
机构名称，2002
Page 50 of 71
《**ERP项目需求规格说明书》
14.5 web软件功能测试
1，链接测试 2 表单测试 3 Cookies测试 4 导航测试 5 图形测试 6 内容测试 7 设计语言测试 8 数据库测试 15经典SQL笔试题
15.1有表AA，复制AA的表结构到新表BB（不存在的）中。
select * INTO BB from AA;
15.2 显示目录和文件的命令求出A ,B还剩下多少
on AA.t=temp.t;
表二 BB
种类T 出库数量S A 105 A 213 B 116 B 211
表一 AA
种类T 库存总量S A 997 B 1234
B . am from AA 303 inner join (select BB.t,sum(s) as am from BB group by t)as temp select AA.t ,AA.s-temp
15.3 查询出所有学生成绩相同的信息
select cji from students s, scours s1 where s.sno=s1.sno group by cji having count(cji)>1;
机构名称，2002
Page 51 of 71
《**ERP项目需求规格说明书》
15.4 判断编号为097的教师名字是否存在
select tname from teacher where exists tno=097;
select tno,tname from teacher where exists (select tname from teacher where tno=097);
15.7 查询第10到15条记录
select top 5 * from (select top 15 * from table order by id asc) table_别名 order by id desc 15.8 取得表中相同记录
表二 BB
种类T 出库数量S A 105 A 213 B 116 B 211 B 303
select * from bb where id in (select max(id) from bb group by t having count(t)>1) 输出结果：
机构名称，2002
Page 52 of 71
《**ERP项目需求规格说明书》
16 QC安装及使用 16.1 QC 安装环境 1.安装系统：windows 2003 2.安装IIS
3.安装sql server2005并下载sp3补丁包安装 16.2 QC 安装步骤
1.在QC安装文件中找到qc9.0\\Installation\\setup.exe,双击后进行安装
2.点击下一步
机构名称，2002
Page 53 of 71
《**ERP项目需求规格说明书》
3.接受协议，下一步
机构名称，2002
Page 54 of 71
《**ERP项目需求规格说明书》
4.进入到如下界面，第一次安装的话，就选―第一个节点/‖，单击―下一步‖ 机构名称，2002
Page 55 of 71
《**ERP项目需求规格说明书》
5.选择许可证文件，维护密钥为空，下一步
机构名称，2002
Page 56 of 71
《**ERP项目需求规格说明书》
6.出现如下界面，选择―显示Jboss高级选项‖，单击―下一步‖ 机构名称，2002
Page 57 of 71
《**ERP项目需求规格说明书》
7.配置Jboss端口和内存大小，默认是8080，安装之前用netstat –na –p tcp –o在命令提示符下扫描一下8080端口是否已经被占用，我记得Tomcat的默认端口也是8080的，为了不出错误，也可以换一个端口，然后―下一步‖
机构名称，2002
Page 58 of 71
《**ERP项目需求规格说明书》
8.出现如下界面，用户名为操作系统登陆用户名，密码为登陆密码，域可以查看我的电脑—属性—计算机名查看，如果没有域，则为―完整的计算机名‖或为空，确保登陆的用户名是超级权限的管理员用户
机构名称，2002
Page 59 of 71
《**ERP项目需求规格说明书》
9.出现如下界面，选择集成的web服务器，不熟悉的用户最好选自带的Jboss服务器，然后单击―下一步‖
机构名称，2002
Page 60 of 71
《**ERP项目需求规格说明书》
10.出现如下界面，选择第二项，然后单击―下一步‖
机构名称，2002
Page 61 of 71
《**ERP项目需求规格说明书》
11.出现如下界面，有SMTP服务器就填，没有就选无，然后―下一步‖
机构名称，2002
Page 62 of 71
《**ERP项目需求规格说明书》
12.下一步
机构名称，2002
Page 63 of 71
《**ERP项目需求规格说明书》
13. 选择QC的数据库，这里我选择第二项，下一步
机构名称，2002
Page of 71
《**ERP项目需求规格说明书》
14. 输入服务器名应该同SQL服务管理器的服务器名一致，数据库管理员及密码要同安装SQL时的录入一致。
15.如果单击下一步，出如下错误，是由于数据库中存在TD用户，而密码不对造成的，一般是由于卸载后重装才会存在，可以查看数据库中安全性－登录中，删除TD用户或在步骤6的页面选择―显示高级选项‖下一步，输入td的密码和数据库中的一致，单击下一步。
机构名称，2002
Page 65 of 71
《**ERP项目需求规格说明书》
16. 输入后台登录得用户名和密码
机构名称，2002
Page 66 of 71
《**ERP项目需求规格说明书》
17.选择库路径
机构名称，2002
Page 67 of 71
《**ERP项目需求规格说明书》
18.查看前面的选择和配置是否有误
机构名称，2002
Page 68 of 71
《**ERP项目需求规格说明书》
19.确认无误，下一步开始安装
机构名称，2002
Page 69 of 71
《**ERP项目需求规格说明书》
20.选择―是‖启动JBoss服务器
机构名称，2002
Page 70 of 71
《**ERP项目需求规格说明书》
21.安装成功可以登录了。
机构名称，2002
Page 71 of 71
因篇幅问题不能全部显示，请点此查看更多更全内容