标签：不同的 姓名 复杂 模版 占用 锚点 易用 条件 类方法
通过人工方式或自动化手段对被测对象进行检测的活动，目的在于发现被测对象是否满足用户需求，或者弄清楚实际结果与预期结果的差异。
包括源代码、用户手册、配置数据。
具体：实现用户需求的源代码、与之相匹配的文档、支撑其运行的配置数据。
最终目的是检测被测对象是否符合用户需求。
1、发现被测对象与用户需求的差异，俗称bug；
2、通过测试活动，发现并解决缺陷，增加人们对被测对象的质量信息；
3、通过测试活动，获取被测对象的质量信息，为决策提供数据依据，例如是否发布。
4、通过测试活动，预防缺陷，从而降低项目或产品的风险。
1、测试证明软件存在缺陷
2、不可能执行穷尽测试
3、测试应该尽早启动，尽早介入
4、缺陷存在群集现象：某个功能部件发现的缺陷越多，找到它更多未发现的缺陷的可能性就越大。一般系统中20%的功能是用户用的最多的，但是复杂度可能是整个系统复杂度的80%，所以应该将核心资源放在那20%的功能上。
5、杀虫剂悖论：
必须不断的编写新的不同的测试用例来检测程序的不同部分从而找出更多bug。
6、不同的测试活动依赖不同的测试背景：
例如：金融产品业务关注安全性和性能，电商系统更关注功能和兼容等。
7、不存缺陷的悖论：
一个产品即便没有缺陷，但是不能满足用户需求，也没有用。
组成：软件源代码、与软件源代码匹配的文档、支撑软件源代码运行的配置数据，但是不同阶段测试对象也有所侧重：
1、需求阶段：测试 需求文档 是否正确实现了用户的需求；
2、系统设计阶段：测试 概要设计文档、详细设计文档是否有设计或逻辑或上的错误；
3、编码阶段：测试源代码，发现编程上的错误；
4、系统测试阶段：被测对象是否满足用户需求。
1、单元测试：一般使用自动化工具。针对被测系统最小组成单元实施的测试活动，一般是类、函数，也可能是最小的功能单元，通常可以发现80%的缺陷。
2、集成测试：针对组件、单元与组件、单元之间的接口实施的测试活动，验证接口设计是否与设计相符。分为三种：函数间集成、模块间集成、子系统间集成。
3、系统测试：最常见的测试方式。将通过集成测试的软件，部署在真实的用户环境下执行测试，以此发现软件与用户需求的差别。
4、验收测试：以用户为主的测试，验收组应该由项目组成员、用户代表组成。通常分为以下几种：
1、alpha测试：由用户在开发环境下执行的测试活动，开发者在测试人员身边发现问题及时解决，且在受控环境下执行测试。例如：在公司内部员工的测试；
2、beta测试：开发者和用户不在测试人员身边，发现问题由专人统一收集，再由研发人员进行修改，且在不受控环境下执行测试。例如游戏内测公开对用户测试。
3、UAT测试：用户接受测试，一般是商业用户验证系统可用性进行的测试。
在指定使用条件下，使用被测对象，验证其是否满足用户显性需求。
测试关注点如下：
1、是否有不正确、遗漏、多余的功能，例如点菜后是否按照菜单正确上菜、是否上多了、遗漏了；
2、是否满足系统显性或隐性需求；
3、是否对输入、输出做出正确响应，输出结果是否正确地显示。
目的是 测试网页上的所有链接（文字链接、图片链接、flash动画）是否指向正确的、真实存在的网页或其他位置（下载的文件、网页的一个锚点)。
测试步骤：
I、测试所有链接是否按预期的那样确实链接到了的页面；
II、其次，测试所链接的页面是否存在；
III、保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，例如Xenu：
xenus特点：
I、体积小，免费，最大100线程，检测速度比较快；
II、能很好地生成错误报告；
Xenus缺陷：
I、只能检测链接是否有效（404：请求的资源不存在），不能检查是否正确；
II、只有window版本
当用户向Web应用（BS架构）服务端提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。
简单的测试用例要能说清楚。
ookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
通过模拟被测对象运行业务压力或使用场景，验证被测对象是否满足预先设定的性能指标。
1、连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
逐渐增加负载，系统各项指标的变化情况。
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
3、压力测试
测试系统的限制和故障恢复能力，看系统会互惠崩溃，在什么情况下进场崩溃。
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
其他性能指标
参考：https://yq.aliyun.com/ziliao/414903
1、响应时间，合理的时间取决于用户的需求，不能依据测试人员自己的设想来决定；
2、最大并发数：其中有 系统用户数、同时在线用户数之分，例如OA系统总的系统用户是2000名，最高峰时有500人在线，即同时在线用户为500，500 这个数值只是表明在最高峰时刻有500 个用户登录了系统，并不表示实际服务器承受的压力，500 这个数值只是表明在最高峰时刻有500 个用户登录了系统，并不表示实际服务器承受的压力。
3、吞吐量：是指单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力。一般来说，吞吐量用请求数/秒或是页面数/秒来衡量；从业务的角度，吞吐量也可以用访问人数/天或是处理的业务数/小时等单位来衡量。当然，从网络的角度来说，也可以用字节数/天来考察网络流量。对于交互式应用来说，吞吐量指标反映的是服务器承受的压力。
4、性能计数器：Counter，是描述服务器或操作系统性能的一些数据指标。例如某某系统在承受10000 用户的并发访问时，Web 服务器的CPU占用率为68%，平均的内存占用率为55%”，这其中，68%和55%就是典型的资源利用率的数值。
5、点击率HPS：每秒钟用户向WEB服务器提交的HTTP请求数。 这个指标是WEB应用特有的一个指标，WEB应用是"请求—响应"模式，用户发出一次申请，服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。
特点：
测试被测对象的安全保护机制保护系统不受非法侵入，能够正确地授权的操作。
验证被测对象在不同的操作系统、硬件信息等环境下的运行情况。
1、黑盒测试：不关注被测对象内部结构，仅从用户需求考虑，是否满足用户显性或隐性需求。
2、白盒测试
3、结构测试、逻辑驱动测试。需要软件开发基础。
4、灰盒测试：即关注被测对象的外部特性，又关注其内部设计。
5、静态测试：不执行被测对象程序，不运行被测对象的测试方法。
6、动态测试：执行被测对象程序。步骤如下
I、阅读需求，编写用例；
II、评审此需求；
III、搭建环境执行；
IV、写测试方法。
7、手工测试：最传统的方法，普遍的测试形式，通过测试工程师试用、验证被测对象是否满足用户需求。
8、自动化测试：通过自动化工具或脚本语言自动化完成测试过程，从而替代手工测试。优点是可执行重复性的工作，缺点是不能发现新的缺陷。
偏管理层编写。可以参考公司模版或自行下载。
主要构成：
1、目的；
2、总体概述：项目背景、项目范围；
3、测试资源需求：
3.1、软件：操作系统（windows、unix、OS、linux）、数据库（mysql、SQL server、Oracle、DB2..）、
web服务器（IIS、Tomcat、JBOSS、RESIN、Weblogic、Websphere）；
3.2、硬件资源：硬件服务器、手机、平板、测试设备；
3.2、其他设备资源：高温、低温设备；
3.3、人员需求：需要几个测试人员测试多久？
4、组织形式
5、测试对象
6、需求跟踪
7、测试通过/失败标准
8、测试挂起（例如核心测试用例无法通过）/恢复条件
9、测试风险以及防范
10、测试任务安排
11、应交付的测试工作产品
12、资源分配：培训需求、测试工具开发（市面上没有相应的工具）。
分析功能需求、性能需求、外部接口需求等。
1、分析需求来源：参考需求规格说明书、开发需求、继承性需求、行业竞品分析、经验库。
2、需求分类：
2.1、功能性需求；
2.2、性能需求；
2.3、外部接口需求：GUI、外部应用程序接口需求（例如支付接口)
2.4、根据软件质量特性划分需求：安全性、效率、兼容性、可维护性。
quality center需求处理软件
采用什么方法进行测试。
主要有以下流程：
1、测试需求变更控制流程，可以控制变更频率；
2、测试用例变更流程
3、测试环境搭建流程
4、缺陷管理流程
注意：以上流程是提高效率的，不能成为项目阻碍。
根据功能、性能、接口等需求采取 等价法、边界法 设计和编写 用例设计结构表。
一般用QC、excel管理测试用例。
一般由开发人员搭建好，类别如下：
分平台：win、linux、Unix
分架构：J2EE（java+JSP）、.NET(APSX)、LAMP(PHP)
分数据库：
分web服务器：iis、apache、tomcat...
1、预测试阶段：冒烟测试，利用一袋烟的时间，快速地对被测对象实施测试活动。验证被测对象是否能完成核心功能 或 高风险功能能否正常工作。预测试用例来源于系统测试用例设计阶段的高级别的用例。
2、系统测试：经过预测试后，开展系统测试。测试执行过程中发现缺陷，则需及时记录缺陷，根据部门或团队的部门管理流程进行缺陷提交和跟踪处理。
若发现缺陷过多可以停止测试，需要与开发部门沟通进行版本升级。也可以及时更新测试用例。
每天执行多少个用例？业务流程简单，则测试用例执行表多，若业务流程复杂，则测试用例执行较少。
简单模拟流程如下：
1、测试工程狮执行测试用例，发现bug，描述并转交（assgin_to）给测试组长，配置：status=New，serverius（级别设置）=low；
2、测试组长：查看新提交并需要自己处理的的bug，查看并修改status=Open，最后转给assgin—to开发人员；
3、开发人员：查看自己需要修改的bug，确认合理并修改后，status=Fixed，assgin-to缺陷的发现者（detected-by）；
4、开发部门重新制作测试版本，测试部门重新按流程进行测试；
5、测试人员：筛选出自己提交的缺陷，若显示fixed则进入查看并验证。若缺陷存在，修改status=Reopen，并指派给开发人员，并添加描述信息；若缺陷已经修复，则修改status=Closed。
测试日报：
1、方便测试工程师掌握测试进度和测试情况，用于调整下一天的工作计划；
2、测试工程师对被测对象每天给出的评估结果，用于调整后续工作中的测试策略；
3、测试经理通过测试日报，了解测试工程师的工作进度，把握测试整体进度，发现进度上的风险从而及时调整计划；
4、测试经理便于了解各个模块缺陷发展趋势，判断测试是否可以退出，通常可以利用缺陷管理工具的统计分析功能了解缺陷发展情况；
5、开发经理便于了解被测对象的质量状况，并可以调整缺陷修改人力资源；
6、若产品有多个测试组并行测试，测试日报可以提供彼此交流的手段；
管理工具可以自动生成相关图表。
测试报告：
一般由测试经理编写。
1、软件测试工程师评估当前被测对象的质量，并对下一阶段的测试工作给出建议；
2、测试经理了解被测产品的质量状况、测试过程的质量；
3、开发经理了解开发产品的质量状况，并在下一阶段的开发工作中采取措施；
4、在测试报告中，测试工程师给出的产品质量评估可以作为软件产品是否商用发布的重要参考依据。
一般采用GB8567-88模板。主要包括 对每个测试项的结果评估、发现的缺陷、测试存在的一些局限性、最终评价（是否达到预定目标）。
禅道软件
1、检查在测试过程中测试计划中定义的输出物，例如检查有没有产生测试规程、测试用例、缺陷报告、测试报告等资料并且归档；
2、缺陷管理是否完成，是否已经进入缺陷管理流程；
3、测试实施过程中产生的风险报告需要记录；
4、测试报告是否给出，相关经验教训是否总结并分享；
5、是否需要移交测试对象。
1、用例编号：需要易识别和维护，格式为 A-B-C-D ，A表示项目或产品名称，B表示用例属性（单元测试ut、集成测试IT、系统测试st等），C表示测试需求的标识（客户管理，C1表示新增客户），D表示编号。例如：CRM-ST-客户管理-001
2、测试项：例如 客户管理-新增客户。
3、测试标题：不能重复，描述测试目的，例如 新增名称为空的客户信息、新增名称超过20个字的客户信息、新增名称包含单引号的客户信息等。
4、用例属性：一般公司不用，一般为 功能性测试、性能测试、兼容性测试（移动app）、安全性测试（银行软件等）。
5、重要级别：高级别（实现主体功能的用例，例如转账功能）、中级别（主项流程经过备选流处理或者经过异常处理能正确实现，例如汇款输入错的账号应该做出相应提示）、低级别（GUI、易用性描述、文字描述类）。一般在赶进度时候是按照由高到低执行，正常情况下按照由低到高执行。
6、预置条件：在银行或军工项目中比较重要。
7、测试输入：非常重要的字段，开发人员参考此数据重现。例如：客户姓名--张三，客户电话--1121212，客户地址：xxxx；
8、操作步骤：I、输入客户姓名、电话及地址；II、点击【保存】按钮；
9、预期结果：I、预期UI表现；II、预期功能表现。一般情况下只写一个方面，不要写太多。
10、实际输出：一般不写。
参考：https://www.91testing.net/course/31/task/919/show#
有效等价类：针对被测对象而言，合理的、有意义的、系统接受的输入，例如输入的字符长度在6-18之间，必须以字母开头等等条件。
、无效等价类：针对被测对象而言，不合理、无意义的，系统不接受的输入用户名长度大于18或小于6。
等价类划分规则：
1、若需求规定了输入域的取值个数或确定了某个范围时，则可以确定一个有效等价类和两个无效等价类，例如 有效等价类（用户名长度6-18之间）、无效等价类（用户名长度大于18和小于6）；
2、如果需求规定了某个输入域的集合，或者必须如何的情况下，可确定一个有效等价类及一个无效等价类，例如有效等价类（以字母开头）、无效等价类（非字母开头）；
3、如果需求规定了某个输入域是真假值时，可确定一个有效等价类和一个无效等价类。
4、如果用户需求规定输入区域是一组值，则可以确定若干个有效等价类以及一个无效等价类。例如：京东商城 中钻石会员、金牌会员、铜牌会员、普通注册用户等；
5、用户需求规定必须遵守某种规定时，可确定一个有效等价类以及若干个从不同角度违反规则的无效等价类，例如规定以字母开头，那么有效类就是以字母开头的输入，无效类（以数字开头、以汉字开头、以特殊符号开头等）
进行用例设计：
1、根据需求，划分有效和无效等价类，有效等价类和无效类都统一编号；
2、设计一个新的测试用例，使其尽可能覆盖所有尚未覆盖的有效等价类，直到所有有效等价类都被覆盖；
3、设计一个新的测试用例，使其尽可能覆盖一个无效等价类。
等价类四则运算法：
加：不考虑其他子项，细致分解当前测试点及详细需求，做累加；
减：根据业务规则减少，排除相关不可能出现的规则，减少不可能出现的组合；
乘：如果有效等价类中具有互斥条件的需求时，可进行乘法得到用例个数；
除：排除所有具有重复特性的等价类，尽可能做到有效等价类之间交集为空，无效等价类之间交集也为空，有效等价类和无效等价类的并集为整个输入域。
实例126邮箱注册功能：
测试点：用户名、密码、确认密码。
关注点：长度、组成、规则要求。
详细需求：长度【6-18】、组成（以字母、数字、下划线等字符构成）、规则（以字母开头，字母或数字结尾，不区分大小写；不能使用已经注册的用户名；）
以excel编写测试用例为例：
加强练习：
https://blog.csdn.net/weixin_36158949/article/details/79368656
https://blog.csdn.net/taotao19900601/article/details/75023069
相当于等价类方法的补充。
边界值应用场景：
1、若需求规定了取值范围或规定了取值个数，可利用该范围的边界内以及边界附近的数据进行测试，例如 以输入用户名长度【6-18】之间，那么测试用例要测上点（6，18）、离点（5，19）、内点（10）；
2、若需求规定了取值的个数，则少于个数一个，或者多于格式一个的值进行测试，例如 购买5间商品则打八折，则测试用例（4，5，6）；
3、如果需求规定了一个有序集合的时候，可使用该集合第一个和最后一个的值进行测试，例如 一个下拉列表中有四个城市名，现在可供选择，那么测试用例可以为（第一个城市，最后一个城市）；
4、若程序中使用一个内部数据结构的话，则应该从该数据结构的边界值进行考虑，例如 int的大小一般为0-65536 ；
边界值应用步骤：
1、根据等价类方法划分有效和无效等价类，确定上点、离点、内点，每个统一编号‘
2、设计一个新的测试用例，使其尽可能覆盖所有尚未覆盖的有效等价类，知道所有有效等价类完全覆盖；
3、设计一个系的测试用例，使其覆盖一个无效等价类，直到所有无效等价类完全覆盖。
3、判断表
实例：若用户欠费或停机，则不允许被呼叫。
按照等价方法分析：
有效等价类 编号 无效等价类 编号
欠费 A01 未欠费 B01
停机 A02 未停机 B02
测试用例：
B01 用户未欠费 & 停机
B02 用户欠费 & 未停机
A01A02 用户欠费 & 停机
无效等价类没有组合。
判断表定义：
1、分析和表述若干个输入条件下，被测对象针对这些输入做出的响应的一种工具；
2、在遇到复杂业务逻辑时可以利用该表理清业务逻辑关系。
重要概念：
1、条件：条件桩（需求规格说明书定义的被测对象的所有输入）、条件项（针对条件桩所有可能的输入数据的真假值）；
2、动作：动作桩（针对条件被测对象可能采取的所有操作）、动作项（）
参考资源
https://www.91testing.net/course/30/task/909/show
面试参考：https://www.cnblogs.com/xiaobai-123/p/7290709.html
标签：不同的 姓名 复杂 模版 占用 锚点 易用 条件 类方法
原文地址：https://www.cnblogs.com/fqh202/p/ruan-jian-ce-shi-ji-chu.html
