计算机基础
1， 软件=程序+文档
2， 软件缺陷a 1.未实现产品说明书要求的功能。2.出现了产品说明书指明不应该出现的错
误。3.实现看产品说明书提到的功能。4.未实现产品说明书未明确提及但应该实现的功能。5.软件难以理解，不易使用。B产品内部：错误，毛病，产品外部，失效违背。 3， 软件测试的定义。使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检
测它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
4， Bug的由来。一般我们把软件缺陷defect称为bug，调试debug除错，去除错误。 5， 计算机的层次：三个层次：a计算机硬件/裸机。B 操作系统。C 应用软件 裸机也包含
软件，主要是Bios程序（Basic input/output system-基本输入输出系统）存储在主板上的一块芯片中，开机以后；计算机运行的第一个程序就是BIOS程序，主要进行硬件的检查，如果硬件检查没有问题，进一步吧控制权交给操作系统，在开机后，马上按下delect键
6， 操作系统：operating system，简称os的主要功能。A设备管理（管理硬件）通过调用驱
动程序。B进程管理（对运行的程序进行管理）C存储管理（进行内存的管理）d文件管理
7， 按照软件结构分类：看软件的运行是否基于网络。不是---单机燃机：office 是---分存式
软件
8， 根据客户端软件的特点：分布式分为C/S结构（client/server）（客户端/服务器）QQ.B/S
结构（Browser/server）（浏览器/服务器）京东商城，百度。如何区分：客户端只需要浏览器就能享受服务—B/S.客户端需要专门的软件才能享受的服务—C/S
9， 进制转换：看本子
测试基础的理论
1. 测试人员的工作职责：1编写测试计划。2 编写测试用例。3 执行测试，发现缺陷提交
缺陷报告 4 验证所发现的缺陷是否得到修改 5编写测试总结报告
2. 缺陷报告的组成：1.缺陷编号（Defect ID）--提交缺陷的顺序 2 缺陷的标题（summary）
简明扼要的说明是什么缺陷 3 缺陷的发现者（defect by）测试人员自己 4 发现缺陷的日期（defect on date）一般是当天 5缺陷所属的模块（subject）在测试哪个功能模块（菜单时发现的bug）可以明确缺陷解决的负责人 6 发现的版本（defect in release）在测试哪个版本的时候发现的bug。7指派给谁处理（assigned to）-开放负责人（经理或者组长）再由开发负责人进一步指派给开发人员
3. 缺陷的状态（status）---A缺陷此时所处的处理状态。1测试人员发现bug，提交（new）
新发现的bug 2 开发经理验证缺陷，如果是bug，把缺陷的状态改为---open（打开的bug）开发组承认是bug，进一步指派给相关人员解决bug；如果不是bug，把缺陷的状态改为---rejected（被拒绝的bug）3 开发人员解决bug。解决后，把缺陷的状态改为---fixed（已修复的bug，待反侧的bug）4 测试人员反侧缺陷，有修复，把缺陷的状态改为---closed（closed）关闭的bug，归档的bug，如果bug没有修复，把缺陷的状态改为—reopen（再次打开的bug，反侧未通过的bug）
4. 严重程度（sererity）缺陷对软件造成的影响有多大。Urgent—最为严重的bug。Veryhight—
非常严重的bug。High –非常严重的bug 。medium---中等的bug。Low---小的bug说明：对于每个级别的情况，缺陷的描述，应该在测试计划或专门的文档中明确出来，以便开发组和测试组达成共识。
Bug的级别定义（bug level definition）
Bug
Severity Description 后果 Ex
1.软件缺陷引起的爆炸、起火、
安全（产品安全、信息安全）；
安全故障或重大失效； 重大索赔、法律
诉讼 重要信息的丢失、泄露； 如： urgent 用户数据丢失（如：电话本丢
2.安全功能失效 用户数据泄漏（如：开关机后
1.参数不能设置；找不到SIM卡
情况下闹铃不闹；
不能发
货、经销
商批退、
消费者退
机；影响
产品认
证； 电话没有声音（不能通话）；W1.没有与需求对应的功能或需求没有实现（需求不分重要与否）； 2.已实现的功能不能有效的执行下去（功能可以操作、运VeryHigh 行，但在中间失效，只有重启、拔电池才能恢复或无法恢复)；存储系统损坏； 3.基本功能的性能（Performance）没有达标（未达到能接受的最低要求--对比测试结果3/5以下）；
4.与软件需求文档，用户手册不符(字符串除外）； 2.死机、重启和自动关机，拔电花屏，死屏，白/黑/蓝屏；使用恢复；SIM卡&存储卡不能存储类按键不可用、所有按键不可用不可用）；功能运行时自动退出3.通话质量差（断续、杂音大、经常掉线； 待机时间短；经常无法呼出、接
4.显示的文字、图片、符号错误
多数用户
的退机 计费不准确问题； ★经常（5台手机，3台5%以上用户数据(文件、个人信息、通讯
按键失效（ 单个按键不可用）
1.功能和性能的缺陷和不足，会导致多数用户的退机； High 2.基本功能和性能的缺陷，是在正常使用和系统测试（除
压力）能发现； 版出现中文字） 多语言版本的很明显的字符串显短/彩信编辑功能出错（不能正常
法切换/回车等基本编辑功能）；
边界值处理无效（超出范围，继
箱中短信实际状态不符)；
多数用户
1.功能和性能的缺陷和不足，会导致部分挑剔用户的退机；
2.需求文档或规范中定义的功能无法实现，但可以以其他medium 方式补救或实现；
3.性能下降；
4.非正常的重复性操作或压力测试能发现的缺陷； 抱怨；部分挑剔用编辑也可保存）；标识显示错误1.不符合常人的使用习惯或偏好致； 不能使用键盘键激活； 错，关闭后可以继续正常使用；户的退机 2.少数（一个功能模块中出现33.使用一段时候后，速度变慢；
新发送后成功； 4.内存为满时，连续发送100多
1.功能和性能的缺陷和不足，会导致部分消费者的抱怨;没
有在用户手册中事先声明
low 2.非常用功能、低重现率的缺陷；
3.多数人很少使用，相对复杂操作下或极限条件下（网络、
容量、流量、电量…）出现的，低重现率的问题；
4.界面不友好，使用不方便，建议改进型 抱怨但不1.不影响功能实现的显示问题，一定退机 2.显示错位，布局错乱，字符间
5. Bug的优先级（priority）测试人员希望程序哪个版本或什么时间修改该bug urgent---
立即解决 very high—本版本解决 high –下个版本解决 medium 发布之前解决 low—允许在发布产品中存在bug（一定要评估风险）
6. 缺陷的描述（description）把发现的缺陷的步骤记录下来，程序员根据描述，可以再次
看到该bug
7. 问题1.缺陷的严重程度和优先级是不是正比关系？不是：以UI为例。a界面问题的严重
程度一般较低，但优秀级可能最高---立即修复如：错别字。B某些重大的功能问题可能暂时解决不了，但不影响软件其他功能的使用，这时优秀级可能定义的比较低—在发布之前修复（微软发布的产品---360修复）
问题2 缺陷的严重程度和优先级确定好以后，还会改吗？a优先级可以修改，严重性确定好了以后一般不改。
问题3 是不是所有已发现的缺陷都会被修复的？不是 有些缺陷的修复成本太高或者由于进度压力可能在发布之前得不到修复，这样的缺陷一定要经过项目组的讨论，权衡成本和风险，要确保不会对用户造成重大的影响及法律的纠纷，以后再通过升级软件或打补丁的方式修复缺陷或者弥补缺陷。。
8缺陷报告的用途1，记录bug 2 对bug进行分类（模块，严重情况，优先级）跟踪bug（new—closed）
9如何识别bug（1）测试用例中的预期结果，在实际测试中实际结果不一致。2 通过需求规格说明书，可以结合缺陷的定义进行识别 3 与相关人员讨论（开发，需求人员，用户） 10， 写缺陷报告时应该注意的问题1一个报告只提交一个缺陷。2 缺陷描述清晰，准确
易读，使用最少，必须的步骤，保证缺陷可以再现。3在提交缺陷报告之前一定要认真审核，确保提交的缺陷是准确的 4不要为了引起开发人员的注意的重视而夸大缺陷 5 下的bug也报告 6及时报告bug 7 对于不可重现的缺陷也要报告。8不做任何评价 9对bug的严重性，优先级的划分准确客观。
11.测试用例的概念，测试用例主要记录了测试的过程，步骤，输入的数据，预期结果等内容，他是在执行测试之前由测试人员编写的指导测试的重要文档。测试用例的核心项：用例的编写，用例说明，预期结果。1参考相关文档，需求文档，开发文档，用户手册2 如果有软件的早期版本，尽快熟悉软件的使用。3 与相关人员讨论
12编写测试用例的方法：等价类划分，边界值，因果图，判定表，正交排列法，场景法，
状态转换图 ，测试大纲法。
1.A等价类划分法：属于典型的黑盒测试方法，从每个部分中选取极少数代表性数据作为测试用例，这样，每一类的代表性数据在测试中的作用都等价于这类中。
B等价类中核心的概念：有效等价类（对程序规格说明有意义，合理的输入，当程序接收有效等价类时，可以正确执行，计算）无效等价类（对程序规格说明书无意义，不合理的输入，当程序接收无效等价类时，应该给出错误的提升或者根本不让用户输入）
C说明：对于需求明确提出的特殊字符，最后先一个一个进行测试，最后在考虑特殊字符的最后，要考虑最糟糕的情况，就是在一个标题中同时出现这些非法字符，甚至标题长度同时超长的情况。
2A边界值方法设计测试用例----重点测试对象，找到测试数据的边界点，也就是有效等价类和无效等价类的边界点，对边界点的数据进行专门的测试。B应用场合：有数据输入的地方。一般都可以使用c如何使用：找到有效等价类和无效等价类的分界点，对分界点的数据及其两边的数据进行单独的测试（一个边界点需测试三个数据）
测试用例的用途：1 防止遗漏 ：使软件测试的实施重点突出：目的明确，确保需求功能不被遗漏 2版本重复使用 3监督过程4评估结果 5提高效率 6缩短周期
注意：1在编写测试用例之前，还要明确项目对测试用例的具体要求a：测试用例编写如何命名 b测试用例应该提交到什么地方---公司服务器 c测试用例中用到的附近命名规定，存放的位置。2 测试用例是需要更新和维护的，是一个不断修改完善的过程 3测试用例需要正式的评审—核心模块 4测试用例覆盖系统的程度决定测试的覆盖程度。基本要求：在编写一条测试用例时，要求步骤描述清晰，准确，易读，预期结果明确
基本要求：在编写一条测试用例时，要求步骤描述清晰，准确，易读，预期结果明确。a如果有特殊的位置，预制条件等，要明确提出 b如果有输入数据，一般要结合输入数据取值 c如果有附件，要给出附近存放位置，明确。
高标准要求：测试用例编写的有条理，逻辑性强。A可以按照功能点分类，操作顺序等逻辑编写，而不是一会测试这个测试哪儿。功能覆盖全面，深入，能够发现软件中更多的缺陷。 用例优化：1在一条用例中，可以尽可能多的覆盖测试，不同的控件的有效等价类（包括有效的边界值）--不同控件的有效等价类可以组合测试。2，在一条测试用例中，开始只能覆盖（测试）一个控件的一个无效等价类，或无效边界值—无效等价类开始时不能组合。---主要为了避免屏蔽现象的发生。最后，可在考虑多个无效等价类组合的极端情况。 使用因果图和判定表法设计测试用例
应用场合：在一个界面中，有多个控件，控件之间存在组合关系，不同的输入组合会产生不同的输出组合，为了弄清输入和输出的对应关系，使因果图方法判定表
核心：因---原因，输入条件 2果—结果，输出结果
因果图的图形符号：本子
因果图的应用场合：a因果图主要考虑控件之间的组合关系。B 每个控件的条件不宜过多，最好为2个，比如按钮点击或者不点击，单选按钮选择还是不选择，复选框按钮选择还是不选择。C如果控件较多，或者每个控件的条件较多，组合量将会很大，不宜使用因果图法 判断表：看本子和ppt
正交排列法：看本子和ppt
场景法：主要测试软件 业务流程，主要功能和错误处理能力。界面特点：主要以点击或者选择操作为主。基本流：模拟用户正确的操作流程（有效等价类）备选流 模拟用户错误的操作流程（无效等价类）
单元测试：1 又称模块测试，是针对软件设计最小的单位，程序进行正确性检验的测试工作。2类，文件，窗口，函数，菜单，报表或一个存储过程都可以作为一个单元进行测试其依据是详细设计。3目的在于检查每个程序单元能否正确实现详细设计说明模块中的模块功能，性能，接口等要求，各模块内部可能存在的各种错误。4单元测试是以黑盒测试为主，重点模块可以结合白盒测试5多个模块可以平行的独立进行单元测试。5单元测试依据的是设计文档。
驱动模块：模拟被测模块上一级模块（调用被测模块的那个模块）
桩模块：模拟被测模块的下一级模块，（被测模块所调用的那个模块）
A一个好的单元测试，将会在产品研发的阶段发现大部分的缺陷，并且修改他们的成本很低B在软件开发的后期，缺陷的修改将会变得更加困难，要消耗大量的时间和费用。C经过单元测试的系统，系统集成过程中将会大大的简化。
集成测试：1集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块，进行有序的，递增的测试。2集成测试时检验程序单元或部件的接口关系，逐步集成为符合设计要求的程序部件或整个系统。3 软件集成的过程是一个持续的过程，会形成很多个临时版本，在每个版本提交时，都需要进行冒烟测试
系统测试：a系统测试是在真实或模拟系统运行的环境下，检查完整的程序能否和系统(包括硬件，网络和系统软件，支持平台等)正确的配置，连接，并满足用户需求b系统测试时为检验和确认系统是否达到其原始目标，而集成的硬件和软件系统进行的测试
验收测试1 按照项目任务书或合同，供需双方约定的验收，依据文档进行的对整个系统的测试与评审，决定是否接收或者拒收系统、2 以用户为主的测试，软件开发和质量保证人员参与。3一般使用生产中的时间数据进行测试。
Alpha测试@测试 1 通常也，叫验证测试 2主要是软件开发完成以后，在软件开发环境下，开发方对要求要提交的软件进行全面的自我检查与验证，可以和软件的系统测试一并进行 3开发方通过测试和提交客观证据，证实软件的实现是否满足规定的需求
Beta测试（b测试）1在用户的应用环境下，用户通过运行和使用软件，检测与核实软件是否符合自己预期的要求 2通常情况用户测试指用户的使用性能测试，由用户找出软件的应用过程中发现的软件缺陷与问题，并对用户质量进行评价。3通常被看成是一种用户测试，
主要是把软件产品有计划得免费发到目标市场，让用户大量使用，并评价，检查软件。通过用户名各种方式的大量使用，来发现软件存在问题与错误，把信息反馈给开发者修改，及测试中厂商获取的信息，可以有助于软件产品的成功发布。
软件测试模型：概念：主要反映测试活动软件开发过程的关系
类型V模型 笔记本
V模型优点：1明确标明测试过程中存在的不同级别. 2 清楚的描述了测试阶段与开发阶段的对应关系 3 V模式的测试策略及包括了底层测试（代码级的测试），又包括看高层测试（需求及的测试）
V模型的缺点：1它仅仅把测试过程作为需求分析，概要设计，详细设计，编码之后的一个阶段，容易让人理解为测试是软件开发的最后一个阶段 2 没有明确的说明早期的测试，不符合越早测试和不断地进行测试的原则。
W模型：由两个V组成，第一个V是开发，第二个V是测试阶段：体现出文档测试与实际测试。
W模型 笔记本
W模型强调：1测试伴随着整个软件开发周期，测试的对象不仅仅是程序，需求，功能和设计同样需要的测试，测试和开发是同步进行的。2符合尽早测试和不断测试的原则3符合实际工作中的测试活动。
软件测试的分类：1按照测试技术划分。黑盒测试---功能测试 白盒测试---代码测试 灰盒测试---功能代码测试。
黑盒测试1也叫功能测试，把测试对象看成一个黑盒子，2完全不考虑程序的内部结构和处理过程，通过软件的外部表现来发现某缺陷和错误 3是在程序界面外进行的测试，它只是检查程序是否按照需求规格说明书的规定正常实现。
白盒测试又称结构测试（检查代码，查代码逻辑算法）白盒测试可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。
黑盒测试和白盒测试的区别
灰盒测试：介于白盒测试与黑盒测试之间的测试。结合了白盒 ，测试和黑盒测试的要素，灰盒测试关注输出对于输入德 正确性，同时也关注了内部表现，但这种关注不像白盒测试那样详细，只是通过一些表征性的现象，事件，标志，来判断内部的运行状态‘ 按是否需要运行代码划分
静态测试：1不实际运行被测软件，而只是静态的检查程序代码，界面或文档中可能存在错误的过程2又称为静态分析技术，实际上是对软件中的需求说明书，设计说明书，程序原代码等进行非与运行的检查3 包括代码测试，界面.文档测试。界面：测试软件的实际界面与需求中的说明是否相符。文档：用户手册和需求说明是否真正符合用户的实际要求
动态测试1 运行被测程序，输入相应的测试数据，检查实际输出结果是否相符2：通过人工或使用工具运行程序进行检查，分析程序的执行状态和程序的外部表现。
软件特性分类
功能测试：产品特性，操作描述和用户方案，测试一个成品的特性和可操作行为以确定它们是否满足设计需求。
性能测试：评价一个产品或组件与性能需求是否符合的测试，包括负载测试，压力测试，数据库容量等（网站访问量）
反侧：针对程序员修改的错误进行测试，验证错误是否被修改 （测试人员提交的bug给开发人员，开发人员给测试人员，测试人员在测试一下）
回归测试：a是指对软件的新版本测试时，重复执行上一个版本测试时的用例，b在发生修改之后重新测试新版本的软件，以保证修改的正确性，以及修改后没有引发新的错误。 随机测试：也叫欲测试，是指测试中所有输入的输入数据都是随机产生生成的，目的模拟新用户的真实操作，随意向系统输入操作（系统交付之前）