软件的生命周期（prdctrm）
计划阶段，需求分析，设计阶段，编码，测试，运行与维护
测试用例字段
用例编号，测试项目，测试标题，重要级别，预置条件，输入数据，执行步骤，预期结果
测试发现一个bug但可能不是bug
获取判断依据和标准：
l 根据需求说明书，产品说明，设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
l 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
l 根据用户的一般使用习惯，来确认是否是缺陷
l 与设计人员，开发人员和客户代表等相关人员探讨，确认是否是缺陷
一个网站如何测试：
首选，查找需求说明，网站设计等相关文档，分析测试需求
制定测试计划，确定测试范围和测试策略，一般包括：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
设计测试用例：
功能性测试包括：
l 链接测试，连接是否正常跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。
l 提交功能的测试
l 多媒体元素是否可以正确加载和显示
l 多语言支持是否能够正确显示选择语言等。
界面测试包括：
l 页面是否风格统一，美观
l 页面布局是否合理，重点内容和热点内容是否突出
l 控件是否正常使用
l 对于必须但未安装的控件，是否提供自动下载并安装的功能
l 文字检查
性能测试包括：
压力测试；负载测试；强度测试；
数据库测试：
要具体决定是否需要开展，数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面
安全性测试包括：
l 基本的登录功能的检查
l 是否存在溢出错误，导致系统崩溃或者权限泄露
l 相关开发语言的常见安全性问题检查，例如SQL注入等
l 如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持
兼容性测试，根据需求说明的内容，确定支持的平台组合：
l 浏览器的兼容性
l 操作系统的兼容性
l 软件平台的兼容性
l 数据库的兼容性
开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
定期评审，对测试进行评估和总结，调整测试的内容。
在搜素引擎中输入汉字就可以解析到对应的域名，请问如何用LoadRunner进行测试。
l 建立测试计划，确定测试标准和测试范围
l 设计典型场景的测试用例，覆盖常用业务流程和不常用的业务流程等
l 根据测试用例，开发自动测试脚本和场景：
录制测试脚本：新建一个脚本（Web/HTML协议）；点击录制按钮，在弹出的对话框的 URL中输入“about:black”；在打开浏览器中进行正常操作流程后，结束录制；调整脚 本并保存，可能要注意到字符集的关联。
设置测试场景：针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应 时间是否达标；针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系 承载能力的条件下，系统是否会崩溃；执行测试，获取测试结果，分析测试结果
周期模型（典型的几种）：
l 瀑布模型
l 快速原型模型：快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。
l 迭代模型：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和使用该发布必需的所有其他外围元素。在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
生命周期阶段：
l 软件计划与可行性分析
l 需求分析
l 软件设计
l 编码
l 软件测试
l 运行与维护
目前主要的测试用例设计方法是什么？
白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖
黑盒测试：边界值分析、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法
软件的安全性应从哪几个方面去测试？
软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。
l 用户认证安全的测试要考虑问题：明确区分系统中不同用户权限、系统中会不会出现用户冲突、系统会不会因用户的权限的改变造成混乱、用户登录密码是否是可见、可复制、是否可以通过绝对途径登录系统（拷贝用户登录后的链接直接进入系统）、用户退出系统后是否删除了所有鉴权标记。是否可以使用后退键而不通过输入口令进入系统、系统网络安全的测试要考虑问题、测试采取的防护措施是否正确装配好，有关系统的补丁是否打上、模拟非授权攻击，看防护系统是否坚固、采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击试一下，现在最常用的是NBSI系列和IPhacker IP）
采用各种木马检查工具检查系统木马情况、采用各种防外挂工具检查系统各组程序的外 挂漏洞
l 数据库安全考虑问题：系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）、系统数据的完整性（我刚刚结束的企业使命核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）、系统数据可管理性、系统数据的独立性。系统数据可备份和恢复能力（数据备份是否完整，可否恢复，回复是否可以完整）
静态测试，动态测试，黑盒测试，白盒测试，α测试β测试
l 静态测试：是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程
l 动态测试：是实际运行被测程序，输入相应的测试实例，坚持运行结果与预期结果的差异，判断执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能
l 黑盒测试：一般用来确认软件工能的正确性和可操作性，目的是检测软件的各个功能是否能得以实现，把被测试的程序当做一个黑盒，不考虑其内部结构，在知道该程序的输入和输出之间的关系或程序工能的情况下，依靠软件规格说明说来确定测试用例和推断测试结果的正确性
l 白盒测试：根据软件内部的逻辑结构分析来进行测试，是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现
l α测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
l β测试：是软件的多个用户在一个或多个用户的实际使用环境下进行的测试，开发者通常不在测试环境，Beta测试不能由程序员或测试员完成。
软件测试分为几个阶段 各阶段的测试
软件测试的几个阶段：
和开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段：
l 单元测试：单元测试是针对软件设计的最小单位-程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。
l 集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合测试，因此在大部分企业中集成测试是由开发人员来完成的。
l 系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大影响。
l 验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于产品来说就是最后一次的系统测试。测试内容对功能模块的全面测试，尤其要进行文档测试。
单元测试测试策略：
自顶向下的单元测试策略：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。
自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长
孤立单元测试策略：最好的单元测试策略。
集成测试的测试策略：
大爆炸集成：适用于一个维护型项目或被测试系统较小
自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产品控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
基于进度的集成
优点：具有较高的并行度；能够有效缩短项目的开发进度
缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。
系统测试的测试策略：
数据和数据库完整性测试；工能测试；用户界面测试；性能评测；负载测试；强度测试；容量测试；安全性和访问控制测试；故障转移和恢复测试；配置测试；安装测试；加密测试；可用性测试；版本验证测试；文档测试
软件测试各个阶段通常完成什么工作？各阶段的结果文件是什么？包括什么内容？
单元测试阶段：各独立单元模块在与系统地其他部分相隔的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能，提交缺陷报告。
集成测试阶段：集成测试是在单元测试的基础上，测试再讲所有的软件单元按照概要设计概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技指标及要求的活动，该阶段生成集成测试报告，提交缺陷报告。
系统测试阶段：将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件，外设，某些支持软件，数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。
测试人员在软件开发过程中的任务是什么？
- 尽可能早的找出系统中的Bug；
- 避免软件开发过程中缺陷的出现；
- 横来软件的品质，保证系统的质量；
- 关注用户的需求，并保证系统符合用户需求。
总的目标是：确保软件的质量。
在您以往的工作中，一条软件缺陷记录都包含了那些内容？如何提交高质量的软件缺陷记录？
一条bug记录最基本应包含：
Bug编号；
Bug严重级别，优先级；
Bug产生的模块；
首先要有bug摘要，阐述bug 大体的内容；
Bug对应的版本；
Bug详细现象描述，包括一些截图，录像……等等；
Bug出现时的测试环境，产生的条件即对应操作步骤；
黑盒测试和白盒测试是软件测试的两种基本方法，请分别说明各自的优点和缺点！
黑盒测试的优点有：比较简单，不需要了解程序内部的代码及实现；与软件内部实现无关；用户角度出发，能很容易的知道用户会用到那些功能，会遇到那些问题；基于软件开发文档，所以也能知道软件实现了文档中的那些工能；在做软件自动化测试时较为方便。
黑盒测试的缺点有：不可能覆盖所有代码，覆盖率较低，大概只能达到总代码量的30%；自动化测试的复用性较低。
白盒测试的优点有：帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
白盒测试的缺点有：程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，只能测试开发人员做的对不对，而不知道设计的是否正确，可能会漏掉一些功能需求；系统庞大时，测试开销会很大。
|
测试用例编号 |
Bug_1 |
|
测试项目 |
……系统 |
|
测试标题 |
选择……，操作 |
|
重要级别 |
高 |
|
预置条件 |
输入系统地址 |
|
输入 |
资料 |
|
操作步骤 |
先选择……后选择…… |
|
预期输出 |
给出资料 |
|
测试结果 |
通过 |
|
测试者&时间 |
张三&2020-02-22 |
测试用例干什么用：把我们的测试出来的问题格式化文档化
如何测试一个纸杯？
功能性：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够收纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄露时间和情况；盛上汽油（案例二）放24小时检查泄露时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
黑盒测试的测试用例常见设计方法都有哪些？举例子
1) 等价类划分：等价类是指某个输入域的子集合，再该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。
2) 边界值分析法：是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部，因此针对各种边界情况设计测试用例，可以查出更多的错误。 使用边界值分析方法涉及测试用例，首先应确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
3) 错误猜测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。 错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误，以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况，输入表格为空格或输入表格只是一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。
4) 因果图方法：前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等，考虑输入条件之间的相互组合，可能会产生一些新的情况，但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也是相当多。因此必须考虑采用一种适合于描述对于多种情况的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要利用因果图（逻辑模型）。因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。
5) 正交表分析法：可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有显示的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行所见一些用例，从而达成尽量少的用例覆盖尽量大的范围的可能性。
6) 场景分析方法：指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
7) 状态图法：通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件；通过输入条件、输出条件和状态得出被测系统的测试用例。
8) 大纲法：大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。
软件测试类型？区别和联系？
测试类型有：功能测试，性能测试，界面测试
功能测试在测试工作中占得比例最大，功能测试也叫黑盒测试。是把测试对象看做一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒测试技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，在使用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先他可能是个功能点，首先要保证他的功能是没问题的，然后在考虑该功能点的性能测试
比较黑盒测试、白盒测试、单元测试、集成测试、系统测试、验证测试的区别与联系
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完成不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明说，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
- 是否有不正确或遗漏的功能？
- 在接口上，输入是否能正确的接受？能否输出正确的结果？
- 是否有数据结构错误或外部信息（例如数据文件）访问错误？
- 性能上是否能够满足要求？
- 是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍
3、在循环的边界和运行的界限内执行循环体
4、测试内部数据结构的有效性
单元测试（模块测试）是开发者编写的一段代码，用于检验被测代码的一个很小的、
很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为
单元测试是由程序员自己来完成，最终收益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合程序的更大部分。方法是测试片段的组合，并最终扩展进程，讲您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法（常见的联调测试）
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能性能如同用户合理期待的那样。
性能测试的流程？
- 测试需求分析
- 测试计划制定与评审
- 测试用例设计与开发
- 测试执行与监控
- 分析测试结果
- 编写性能测试报告
- 测试经验总结
浙公网安备 33010602011771号