软件测试：特定的环境、特定的条件下运行软件，验证其能正常运行，并发现其缺陷，对软件的质量进行评估的过程；
软件测试过程：设计、计划、实现、执行；
软件测试流程：需求、计划、方案、用例、执行、总结；
lampp（xampp）：apache+mysql+php+per；
wampp：windows+apache+mysql+php；
apache的http的默认端口为80，https的默认端口为443；
（http端口设置在xampp文件下httpd.conf，https端口设置在xampp文件下的http—ssl.conf）
数据库mysql的默认端口为3306，oracle的默认端口为1521；
在控制命令符中查看端口的占用情况命令：netstat -ano | findstr “80”
SVN的使用：上传commit、更新update、查看日志、更新版本、clean up；
几个人同时编辑文档：先锁定、再编辑、再提交；
1、测试需求
测试需求分析：分析识别测试范围，解决测什么的问题，方便测试的跟踪和管理；
测试需求分析的流程：需求采集—>需求分析—>需求评审；
测试需求分析的评审：完整性、准确性、一致性、易理解性、无歧义性；
测试需求分析的时间：开发需求完成后；
负责人：有丰富经验的测试工程师；
参考依据：
（1）狭义依据：需求规格；
（2）广义依据：参照上面的测试需求分析来源；
在测试需求不明确的情况下，如何保证测试质量：
（1）多方收集需求；
（2）多与开发人员沟通；
（3）若有以前的系统，参照以前的系统；
（4）找类似的产品熟悉；
（5）到网上查找与系统相关的业务知识、专业术语；
测试需求分析的来源：
（1）开发文档：需求规格、概设、详设、数据库结构设计文档、模块功能图等；
（2）用户需求：与用户或需求分析人员沟通，需求调研的会议纪要，与用户邮件往来；
（3）软件雏形：可运行软件，软件的框架；
（4）相关的规划及标准：各行各业的标准、国家标准、行业标准、企业标准、项目标准、国家法律法规；
（5）类似的产品：公司内部相同的旧版本产品，行业其他公司类似的产品；
（6）测试知识经验库：测试人员的业务背景、系统业务知识的积累、个人的测试经验积累；
（7）其他隐性的需求：产品利益相关者的建议、会议纪要、备忘录、沟通记录、邮件往来等；
测试需求分析的内容：
（1）业务流程图的分析；
（2）用户和角色的分析；
（3）数据库结构的分析；
（4）测试要点的分析；
测试需求分析的方法：
（1）测试功能点分析法；
（2）功能交互分析法；
（3）质量特性分析法；
（4）测试类型分析法；
2、测试计划
测试计划：管理层文档，对测试过程、测试活动起到指导的作用，解决做什么的问题，5W；
测试计划编写时间：测试需求完成之后；
编写人：由项目测试负责任编写；
评审人：项目经理、QA、开发、产品、设计人员
输出文档：总的测试计划文档；
测试计划的内容：
（1）项目背景，缩略语（专业术语）；
（2）测试的参考文档、测试的交付文档；
（3）测试目标、测试范围、测试环境、测试工具、测试策略、测试风险；
（4）人力资源的分配、工作量的估算；
（5）测试时间、进度安排、任务分配、培训计划等；
（6）出入口准则（准入准出标准）等；
测试风险：质量、时间进度、成本、变更、人员变动等；
QA与QC的区别：QA为质量保证、QC为质量控制；
冒烟测试：在测试之前，对软件进行可测性检查，保证基本功能，基本流程可通，提高工作效率；
回归测试：包括完全回归和部分回归（根据操作频率和风险选择）
| 项目 | 项目时间周期 | 测试用例数量 |
| 小 | 3个月—10个月 | 500-1000个 |
| 中 | 10个月—1.5年 | 1000-2000个 |
| 大 | 1.5年以上 | 2000个以上 |
| 测试阶段 | 占用时间比例 |
| 测试需求阶段 | 10%-20% |
| 测试计划 | 小项目2-3天，大项目5天左右 |
| 测试方案 | 小项目1周，大项目2周 |
| 测试用例 | 测试总时间的30% |
| 测试执行 | 测试总时间的40% |
| 测试报告 | 小项目2-3天，大项目5天 |
编写测试用例效率：35个/人天；
执行测试用例效率：35个/人天；
缺陷发现效率：10个/人天；
测试用例的质量：30%（缺陷的总数/已执行的测试用例总数）
集成策略：
（1）非增量式集成：大爆炸式集成；
（2）增量式集成：自顶向下、自底向上、三明治；
测试准入条件：
（1）测试用例编写，测试评审完成；
（2）开发人员完成编码，并完成自测；
（3）冒烟测试通过；
（4）开发组提交了测试申请单；
测试准出条件：
（1）时间标准：项目时间用尽；
（2）缺陷修复：致命/严重缺陷比率为0%，一般<5%，轻微<10%;
（3）测试用例执行覆盖率为100%；
（4）测试用例对需求覆盖率>95%;
（5）缺陷修复率达到一定的标准；
（6）收益比：存在bug，但是修复需要花费的时间大于受益，测试停止；
（7）完成软件测试验收报告，并且报告结果达到认可；
3、测试方案
测试方案：技术层面文档，主要对被测软件测试特性、方法、环境等进行规范，解决怎么做的问题；
测试方案的编写时间：测试计划完成之后；
负责人：有经验的测试工程师；
参考依据：测试计划、测试需求分析、测试规格、概设、详设；
评审人员：测试人员、开发人员、项目经理、QA
测试内容：
（1）项目背景、测试目标、测试范围、测试环境、测试策略、测试工具；
（2）测试特性的分析；
（3）测试特性方法的分析；
以最少的用例更全面的覆盖需求，测试不能发现潜在的缺陷；
单元测试：80%缺陷；
集成、系统测试：20%中的80%；
4%-6%的缺陷遗留到用户现场；
缺陷的群集：80%的缺陷存在20%的模块中；
缺陷的级别：致命、严重、一般（不超过15%）、轻微（不超过20%）、建议；
缺陷处理状态迁移图：新建—打开—已修正—已关闭—拒绝—延迟—重新打开；
缺陷优先级的考虑方面：
（1）缺陷本身的严重级别；
（2）功能的重要性方面；
（3）功能发布的时间进度；
（4）功能的可见性方面；
（5）从操作频率方面；
（6）从安全性方面；
4、测试用例
负责任：测试工程师
参考依据：参考方案、需求分析的结果、需求规格；
评审人：测试工程师、QA、开发人员、测试经理；
输出文档：测试用例文档
用例设计需考虑的方面：（以最少的用例更全面的覆盖需求，以此发现更多的缺陷）
（1）编写所有必填项（一个用例）；
（2）编写所有项包括必填和非必填（一个用例）；
（3）一个完整的流程一次性走完（一个用例）；
（4）编写预期结果：包括前台、后台、数据库等方面；
（5）新增和修改的链接为同一界面（代码一致为前提）：在修改中只需测试进入界面的默认情况，其余字段只需在新增上测试，修改所有字段点击保存、重置，修改后直接返回需要提示；
（6）删除：子信息有调用情况（全删、不能删除），例：品牌和商品，删除品牌时则提示，物理删除：可到数据库中回滚，数据库不存在；标志删除：到回收站用来做历史记录，后台可看，前台不可；
（7）登陆：账号长度限制，正确登陆，不正确登陆；
（8）业务流程图：场景法、基本流和备选流，串行用乘，并行用加；例：银行取款流程图；
（9）查询：精确查询和模糊查询，like“%x%”；多条件搜索可用正交法、再补充；
测试用例过程：
（1）输入—动作—输出；
（2）输入—测试环境—测试目的—执行条件—动作—输出；
（3）为了达到某种特定目标而设计的一组测试输入、执行条件和预期结果，其目的是为了检测某个程序或何时是否满足某个特定的需求；
测试用例的作用：便于软件质量的度量，方便测试任务的跟踪管理，方便缺陷的提交；
如何衡量测试用例的好坏：清晰、准确、完整、简洁、一致；
黑盒测试用例设计方法：包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
因果图：
（1）因果图关系：（输入与输出）恒等、非~、与^、或V；
（2）输入约束：异E最多只能一个为1、或I最少有一个为1、唯一O有且只有一个唯一；要求R两个取值一样如C1为1C2也为1；
（3）输出约束：强制M两个输出互异；
白盒测试用例设计方法：语句覆盖率、条件覆盖率、判定覆盖率、条件判定覆盖率、组合覆盖率、路径覆盖率；
对于搜索框的测试用例设计：
（1）单个条件；
（2）所有条件；
（3）任意几个条件组合：应用正交实验法再补充情况；
（4）不符合条件查询；
（5）条件中有相互冲突的条件，需单独测试；
（6）输入合理的查询条件后，点击返回需有提示；
5、测试执行
参考依据：测试用例（需求）；
执行人：软件测试工程师；
输出：缺陷报告；
Test Case执行结果：
（1）未测试：Not test；
（2）通过：pass；
（3）失败：failed；
（4）阻塞：black；因为其它的问题导致用例无法执行；
（5）观察：investigates；
bug的内容：bug描述、重现步骤、实际结果、预期结果；
测试执行注意事项：
（1）注意用例执行的先后顺序：数据流向、优先级、时间进度安排；
（2）执行的前置条件、测试环境、备注里的特殊说明；
（3）发现问题/缺陷时，应立即保留证据，再重现缺陷；
（4）缺陷至少重现3次，并初步定位到问题；
（5）测试过程中，根据实际情况维护测试用例；
维护测试用例情况：
（1）需求、编码、设计发生了变更；
（2）执行过程中发现用例描述有错误；
（3）发现的缺陷不能对应用例，需补充用例；
（4）发现重复、冗余的用例需删除；
对于偶然发现，并难以重现的缺陷如何处理：
（1）先保留证据（抓包、截图、视频等）；
（2）本机重现问题，无法重现则换电脑重现；
（3）若重现，则根据缺陷的实际影响情况定义缺陷的严重级别；若无法重现，则找开发人员协助重现；在开发人员的协助下仍未能重现，则需要对此问题边重现边录视频（最多两小时），若2小时内重现则从发现问题的前半小时开始分析，若2小时内未重现，则需直接提交缺陷，降低缺陷的级别，将缺陷改成延迟状态，该缺陷至少历经半年或者在用户现场历经多个版本后关闭；
什么是缺陷（遗漏、错误、额外实现）：
（1）需求规格说明书中明确要求实现的未实现；
（2）需求规格说明书中虽未明确规定，但实际需要实现的缺陷；
（3）未正确实现（错误实现）；
（4）实现了需求规格中明确不需要的功能（额外实现）或实际不需要的功能；
（5）性能、易用性等方面，站在用户的角度，会认为不好的；
缺陷的生命周期：
提交->确认->分配->修复->验证->关闭
缺陷的内容：
缺陷编号、模块、项目名、版本、缺陷标题、缺陷级别、优先级、缺陷类型、测试环境、缺陷描述（bug描述、重现步骤、实际结果、预期结果、修改建议）、状态、缺陷引入原因、缺陷引入条件、发现人、发现时间、修改人、修改时间、关闭人、关闭时间、附件、对应的用例编号；
6、测试报告
定义：对于测试过程、产品质量进行评估，并对测试结果进行总结、下结论；
编写人：有经验的测试工程师；
依据：测试用例的执行情况，缺陷数据的统计结果；
评审人：整个项目人员；
测试报告评估人：测试经理、测试人员
目的：
（1）用于项目经理决策提供依据；
（2）用于下一个项目维护提供方便；
（3）对测试进行评估；
内容：
项目背景、测试目标、测试范围、测试环境、测试策略、测试工具、测试人力资源、测试时间、测试用例数据统计、缺陷数据统计、遗留问题、测试风险、测试过程开发、产品质量评估、测试结论、经验教训与建议、附录；