测试技术辅导文档.docx

一、 说一下整个项目的测试流程参考以下内容结合自己的项目进行回答（1） 分析需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。（2） 测试计划: 根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、 如何合理分配安排资源等。（3） 测试用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。（4） 测试执行：搭建测试环境，根据测试用例的详细步骤，执行测试用例。（5） 执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。（6） 测试报告：对整个系统测试活动进行总结，并提供一些数据分析，便于将来对开发和测试进行改进。二、 针对需求相关问题1. 需求不明确的情况下怎么开展测试 查询文档，原版本留下的文档、用户手册、产品开发测试人员写的非正式文档，可以了解项目的背景、系统功能等 参考行业相关书籍、文档，或同类型网站实现功能 当系统已初步成形时，对系统进行使用，自己总结系统实现功能，然后找开发人员确认 沟通，主动和开发人员沟通，让开发人员给测试人员进行系统演示，测试时遇到需求不明确的时候，及时和产品相关人员、开发人员进行沟通2. 如何快速的吃透一份80页的需求文档三、 测试计划怎么编写，包含哪些内容系统测试计划是从管理的角度来规划和控制整个系统测试活动，是由测试经理来制定，系统测试计划考虑的主要内容有： 组织形式 测试对象 工作任务分配 通过失败标准：定义什么时候测试可以结束 挂起恢复标准：定义什么时候测试需要暂停 应交付测试工作产品系统测试计划写作：1. 目标2. 概述3. 组织形式需要明确每个人要做什么事情以及如何和别人协作等4. 测试对象列出系统测试计划活动中分析确定的所有功能测试项和非功能测试项列出测试项目中的哪些特性和特性组合将不被测试，并说明不被测试的原因在本节所列的测试对象仅仅是为了表达应该测试什么，不需要具体说明该怎么测试5. 工作任务分配描述系统测试活动中所明确的测试任务分工，可以从测试计划、测试设计、测试执行等阶段进行考虑。针对每一项测试任务，明确 任务的输入和输出任务输入：执行任务所需要依据的资料。任务输出：任务执行完后应该输出的工作产品，包括测试文档、测试脚本、测试报告、测试工具等等。任务输出是每个任务很好的监督手段，因此任务输出必须非常明确。 任务所需的资源人力资源估计：每个活动所需要的人员能力；每个活动所需要的人员数量 物力资源估计：硬件和软件环境；测试工具、仪器等； 任务的人员分工 任务的时间和进度安排 估计任务的风险和应对措施（补充具体的工作任务分配例子）6. 测试通过失败标准这是判断测试过程通过或失败的标准，而不是被测对象通过或失败的标准。如： 用例的执行情况要达到何种目标对于所有1、2级用例100覆盖、3、4级用例30覆盖或者本轮测试重点特性用例100覆盖 覆盖率要达到什么目标所有的功能需求、性能需求都被覆盖。7. 测试挂起恢复标准 测试挂起：当测试过程无法进行下去或者失去了继续进行测试的意义时，可以将测试活动挂起。 测试恢复：当被挂起的测试活动所需要的条件得到了满足时，测试活动恢复执行。确定系统测试挂起及恢复的条件是保证测试顺利执行的前提，例如测试过程中发现系统主要功能有致命问题，这样大量的用例被堵塞，导致系统测试无法继续下去，这样必须挂起，打回开发修改后重新提交版本。8. 应交付测试工作产品确定各测试任务完成后应交付的测试文档、测试代码及测试工具等测试工作产品四、 针对用例设计相关问题1. 如何设计系统测试用例对于一个给定的系统/对象，要先确定针对该系统要进行哪些系统测试类型的测试，然后再针对每一测试类型进行详细测试用例设计，可使用常用测试用例设计方法。常见系统测试类型有：功能测试、性能测试、安全性测试、GUI测试、可用性测试、安装测试、配置测试、异常测试、稳定性测试、文档测试等2. 给你一支圆珠笔，如何设计测试用例l 功能测试： 能不能写出流利的写出字来； 写出来的字是否清晰 字的粗细、颜色、味道是否符合用户要求 对于重复使用的笔，换芯之后是否可以重新使用l 性能测试： 长时间使用圆珠笔写字，是否会出现写不出的情况； 一支笔可以使用多少时间，这个时间同市场上相同类型笔的使用时长有多大差别 在不同的温度下，用笔写字的流利程度l GUI测试： 圆珠笔的外观是否美观，符合用户审美特点； 圆珠笔各个部位设计是否合理； 圆珠笔上的Logo或印在上面的字是否正确l 易用性测试： 笔是否太粗或者太细，不好拿捏； 握笔的地方有没有增加摩擦力的纹路或者皮胶之类 拿笔时会不会太滑 是否方便携带l 安全性测试： 圆珠笔的设计是否存在妨碍人身安全的情况 笔身的材质及笔芯是否存在安全问题l 兼容性测试 是否能够兼容其他厂商的笔芯3. 给你一个web登录网页，如何设计用例具体参考“如何测试登录网页”文档，详见“/html/74/n-867174.html”4. 给你一款新的APP但是功能测试已经做好了，你该从哪些方面进行测试具体参考“手机APP测试点总结”5. 各种用例设计方法的适用范围各种测试用例设计方法的适用范围如下，具体说明见“测试用例设计方法”文档工程方法适用范围等价类划分法基于输入数据域分析，把程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。边界值分析法边界值分析法是通过边界值来覆盖等价类，以便能更快更好的发现缺陷。因果图法是否考虑输入输出之间因果约束关系判定表法用来测试各种输入条件的组合，通过对输入条件的全排列组合进行化简来完成用例设计。正交试验法是否考虑输入的两两组合状态迁移图法状态迁移图法用来测试系统工作状态之间的转换以及设置、取值的修改。流程分析法流程分析法是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。错误猜测法错误猜测法就是根据经验猜想可能有什么问题并依此设计测试用例6. 如何用等价类边界值方法设计测试用例 针对一个测试场景，找出输入条件 针对每个输入条件划分有效等价类、无效等价类 结合边界值方法，根据等价类分析法设计用例原则，设计测试用例等价类分析法设计用例的原则： 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。示例：对网站注册页面进行用例设计，使用等价类边界值方法请分析，如下图所示，可以设计多少测试用例7. 如何用正交试验法设计用例（1） 用正交表设计测试用例的步骤 有哪些因素（变量） 每个因素有哪几个水平（变量的取值） 选择一个合适的正交表 把变量的值映射到表中 把每一行的各因素水平的组合做为一个测试用例 加上你认为可疑且没有在表中出现的组合（2） 如何选择正交表 考虑因素（变量）的个数 考虑因素水平（变量的取值）的个数 考虑正交表的行数 取正交表中行数最少的一个五、 针对提交缺陷相关1. 缺陷管理流程2. 测试过程中发现一个bug，但开发人员认为不是bug该怎么办首先要找需求文档、产品说明、设计文档等，看有没有对预期结果进行具体说明，从而提高说服力度。如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；根据用户的一般使用习惯，来确认是否是缺陷；其次要确保自己的bug能够重现。再次，分析一下自己bug的级别，如果只是建议性的bug可以保留，但是也要在bugzilla等工具上记录；如果bug级别比较高，就要跟开发人员有效沟通，耐心讲明这个bug的危害以及重现步骤等，不行就要跟测试经理或者开发经理联系，说过bug的严重性，进行问题评估，一起讨论解决这个问题。3. 测试过程中遇到很难重现的bug怎么办以下内容只供参考： 尽量将该问题以问题单的形式提交，如果无法提交，自己一定要记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因 尽力去查找引起bug的原因，比如从环境、操作步骤、数据等方面 程序员对程序比测试人员熟悉的多，跟开发人员交流一下该问题，即使无法重新，程序员也会了解问题所在。4. 测试过程中碰到哪些Bug印象比较深刻六、 测试报告怎么编写通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。系统测试报告写作：(一) 引言部分1. 编写目的2. 项目背景3. 系统简介4. 术语和缩写词5. 参考资料(二) 测试概况1. 测试用例设计（包含设计多少测试用例）简要介绍针对被测系统都从哪些方面进行了测试用例设计（功能、性能、界面、安全性等），使用了哪些常用测试用例设计方法（等价类划分、边界值、因果图等）2. 测试环境与配置简要介绍测试环境及其配置。3. 测试方法与工具测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。4. 测试实际进度和工作量系统测试各阶段活动的实际进度及工作量统计任务实际开始时间实际结束时间计划工作量实际工作量系统测试计划2011-12-202011-12-223人/时5人/时系统测试方案2011-12-222011-12-283人/时12人/时系统测试用例设计2011-12-272011-12-31200人/时160人/时系统测试用例执行2011-12-262011-12-31100人/时80人/时合计工作量306人/时257人/时(三) 测试分析整个测试报告中最重要的部分，这部分主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。对于不需要过程度量或者相对较小的项目，例如用于验收时提交用户的测试报告、小型项目的测试报告，可省略过程方面的度量部分；1. 用例执行记录测试类别版本/Patch测试轮次时间范围总用例数执行用例数通过用例数变更用例数计划工时实际工时功能测试SugarCE 第二版第二轮2011-12-262011-12-30557539434397060性能测试SugarCE 第二版第二轮2011-12-262011-12-30171717055对用例执行情况进行具体说明2. 缺陷记录NewOpenFixedVerifiedReopenPostponeRejectClosed5- Urgent0200000024-very high010000002123- high0350002015522- medium0210234039691- low000400037410680636093176对缺陷分布情况进行具体说明3. 测试覆盖情况分析 模块（特性）覆盖从模块（特性）角度考虑，每个模块（特性）设计了多少用例，执行多少用例，在该模块（特性）上发现了多少缺陷 需求覆盖从需求角度考虑，每个需求设计了多少用例，执行多少用例，在该需求上发现了多少缺陷4. 缺陷分析从缺陷的严重程度、分布模块（特性）、产生原因等角度对该版本发现缺陷进行分析(四) 总结1. 版本质量总结2. 后续活动建议3. 遗留问题及结论七、 性能测试概念(一) 负载测试负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。重点体现是：不断的加压，考量不同压力下的系统状况(二) 压力测试压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。重点体现是：在最大压力下，系统的表现情况(三) 并发测试并发测试是测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，所以几乎所有的性能测试都会涉及一些并发测试。因为并 发测试对时间的要求比较苛刻，通常并发用户的模拟都是借助于工具，采用多线程或多进程方式来模拟多个虚拟用户的并发性操作。在后续介绍LoadRunner 工具时，有一个集合点的概念，它就是用来模拟并发的，可以在VuGen中设置集合点，在Controller中设置其对应的策略来模拟用例设计的场景。(四) 容量测试容量测试是在一定的软、硬件条件下，在数据库中构造不同数量级的记录数量，通过运行一种或多种业务场景，在一定虚拟用户数量的情况下，获取不同数量级别的性能指标，从而得到数据库能够处理的最大会话能力、最大容量等。系统可处理同时在线的最大用户数，通常和数据库有关。(五) 可靠性测试可靠性测试是通过给系统加载一定的业务压力（如CPU资源在70%90%的使用率）的情况下，运行一段时间，检查系统是否稳定。因为运行时间较长，所以通常可以测试出系统是否有内存泄露等问题。在实际的性能测试过程中，也许用户经常会碰到要求7 24小时，稳定运行的