关于软件测试的个人见解

测试理论
什么是软件测试
   在规定条件下对程序进行操作，从而发现问题，对软件质量进行评估的过程
测试的定义
   用于检查是否满足了需求
测试的目的
   以最少的人力、物力、时间来找到软件中的缺陷并修改，从而回避商业风险

冒烟测试：
   是自由测试的一种
   就是完成一个新版本开发之后，对该版本的最基本功能进行测试，保证基本功能和流程能够走通，当我们严格按照冒烟测试的过程的流程和标准来执行时，当基本功能点不通过，我们可以不予受测试任务 重点：基本功能和流程能走通，就算冒烟测试通过

回归测试：
   当发现并修改缺陷后，或者在软件中添加新的功能后，重新检测。用来检查被发现的缺陷是否被改正，并且所做的修改没有引发新的问题。回归测试可以通过人工重新执行测试用例，也可以使用自动化的工具进行

集成测试：
   集成测试的含义非常简单-将单元测试模块逐个集合/组合，并将行为测试为组合单元
   该测试的主要功能或目标是测试单元/模块之间的接口

系统测试：
   通过与系统的需求规格说明进行比较，检查软件是否存在与系统规格 不符合或与之矛盾的地方，从而验证软件系统的功能和性能等满足规格说明所制定的要求。
测试用例常用方法:

等价类划分法
   就是把所有可能输入的数据，即程序的输入域划分成若干部分，然后从中选取少数具有代表性的数据作为测试用例；使用此类方法要经历划分等价类和选取测试用例两步，这样可以将测试过程进行合理分类，从而保证测试用例的完整性和代表性
类型划分
   有效等价类
      有效等价类是合理的、有意义的输入数据构成的集合，利用有效等价类可检验程序是否实现了规格中所规定的功能和性能
   无效等价类
      无效等价类指是不合理、无意义的数据构成的集合、利用无效等价类可以校验程序对于无效数据的无效数据处理能力检测程序的健壮性、容错性

因果图
   是一种分析输入的各种组合情况，从而设计的测试用例方法，它适合于检查程序输入条件的各种组合情况，此类的特定1.考虑输入条件的互相制约以及组合的关系2.考虑输出条件对输入条件的依赖关系、其核心就是’因’=输入条件，‘果’=输出结果

错误推断法
​   基于经验和和直觉推测程序中所有可能存在各种错误，从而有针对性的设计测试用例方法

软件的生命周期！
简而意赅来说就是软件从酝酿到废弃得过程
一个软件的阶段有 初始构思、需求分析、功能设计、内部设计、文档设计、测试计划、文档准备、集成、测试、维护、升级、在测试、逐步淘汰等等
而常见的生命周期模型有 瀑布模型 螺旋模型 迭代模型等

测试用例！
用例编号 测试项目 测试标题 重要级别 预置条件 输入数据 执行步骤 预期结果

版本控制
是一种软体工程技巧，主要目的是确保由不同的人所编辑的同一档案都得到更新
Git是一个开源的分布式版本控制系统，可以有效，高速得处理从很小到非常大得项目版本管理
SVN是一个开放源代码的版本控制系统、它采用了分支管理系统

软件测试与软件开发之间的关系
软件测试大致有5个步骤
   1.项目规划阶段：负责从单元测试到系统的整个测试阶段的监控
   2.需求分析阶段：确定测试需求分析,系统测试计划的制定，评审后成为管理项目。测试需求分析是对产品生命周期中测试所需求得资源，配置，每阶段评判出来的规约；系统测试计划是依据软件的需求规格说明书，制定测试计划和设计相应的测试用例
   3.详细设计和概要设计阶段： 确保集成测试计划和单月测试计划完成
   4.编程阶段：由开发人员进行自己负责部分代码的测试，在项目较大时，由专人进行编码阶段的测试任务
   5.测试阶段(单元 集成 系统):依据测试代码进行测试，并提交相应的测试状态报告和测试结束报告
   关系则可以将开发和测试看成一个有机的整体，在产品发布之前，开发和测试是循环进行的，测出的缺陷要经开发人员的修改后继续测试，在开发的同时测试经理开始编写测试用例，测试文档要参考开发文档，所以开发和测试是不可分割的，少了任何一个都不能开发出产品
   简单说就是 开发人员通过自己的想象创造出一套思想之后测试人员再对它进行检验，为证，开发人员再修改的过程中不断丰富产品，一个需要掌握大量的技术 一个需要不断的在实例中学习 因此开发和测试看上去做的工作很不一样
两者皆是相符相承 密不可分的 开发人员开发出新的产品后要通过测试判断产品是否满足用户的需求，如果发现缺陷则提交个开发人员修复，然后转交给测试人员进行回归测试，知道产品符合规格，所以一个符合用户需求的产品是开发和测试共同努力的成果

常见的测试模型
瀑布模型：
   优点 是一种古老的瀑布模型 反映了实际和测试之间的关系
   缺点 仅仅把测试过程作为编码之后的一个阶段，忽视了测试对需求的分析，系统设计的验证，如果前面设计错误得一直到后期的验收测试才被发现，耗时耗力
W模型:
   优点：测试与开发同时进行，在v模型基础上，增加了在开发阶段的同步测试
   缺点：仍然不支持迭代，减少了一定错误发送率，但需要按照流水线进行设计，编码和测试
编写测试计划的目的是 使测试工作顺利进行，让项目参与人员沟通更舒服也让工作更加系统化

黑盒、白盒、单元、集成、系统、验收测试的区别于联系
黑盒测试:把测试对象当成一个黑盒子、测试人员完全不考虑逻辑结构和内部特性、只根据格式的需求说明书来检测程序是否满足功能
白盒测试:把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构以及相关信息、设计或选择测试用例、对程序所有逻辑路径进行测试
单元测试:白盒的一种，对软件设计中的单元模块进行测试
集成测试:在单元测试的基础，对单元模块之间的连接和组装进行测试
系统测试:在所用都考虑的情况下，对系统进行测试
验收测试:第三方进行的确认软件满足需求的测试

黑盒测试和白盒测试常用的测试方法有那些，举个例子
黑盒有等价类划分法，边界分析话，因果图法和错误猜测法
白盒有逻辑覆盖法，循环测试路径选择，基本路径测试
例子：再一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首先利用等价类划分法，可以是一个或多个结果是OK的测试用例，然后确认多个NG的测试用例，然后利用边界值分析法，可以对结果分别是OK和NG的测试用例进行扩展和补充

简述黑盒测试和白盒测试的优缺点
黑盒优点：
   1.比较简单，不需要了解程序内部的代码以及实现
   2.与软件内部实现无关
   3.从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到那些问题
   4.基于软件开发文档，所以也能知道软件实现了文档中的那些功能
   5.在做软件自动化测试时较为方便
黑盒缺点：
   1.不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%
   2.自动化测试的复用性较低

白盒优点：
   1.帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题
白盒缺点：
   1.程序运行中会有很多不同的路径，不可能测试所有的运行路径;测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求;系统庞大时，测试开销会非常大

单元测试的策略有那些，主要内容有那些
逻辑覆盖，循环覆盖，同行评审，桌前检测，代码走查，代码评审，静态数据流分析

白盒测试逻辑覆盖有哪几种覆盖标准，覆盖率最高的是什么？
语句覆盖，分支覆盖，条件覆盖，路径覆盖，分支条件覆盖，其中路径覆盖覆盖率最高

软测的基本流程
   1.测试超过预定时间，则停止测试
   2.执行了所用的测试用例，但未发现故障，则停止测试
   3.使用特定的测试用例设计方案作为判断测试停止的基础
   4.正面指出停止测试的具体要求，即停止测试的标准可以定义为查出某一预定数目的故障
   5.根据单位时间内查出故障的数量决定是否停止测试

软测的原则
   1.要把“尽早地和不断地进行软件测试”作为软件开发者的座右铭
   2.测试用例应由测试输入数据和对应的预期输出结果这两部分组成
   3.程序员应避免检查自己的程序
   4.在设计测试用例时，应包括合理的输入条件和不合理的输入条件
   5.充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比
   6.严格执行测试计划，排除测试的随意性
   7.应当对每一个测试结果做全面检查
   8.妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便

用例设计
什么是测试用例，测试用例的基本要素
测试用例是为某个特殊目标而编制的一组测试输入，执行条件以及预期结果，以便测试某个程序路径或者核实是否满足某个特定需求
测试用例的基本元素：
   测试索引，测试环境，测试输入，测试操作，预期结果，评价标准

描述测试用例设计的完整过程
首先要根据需求文档，概要设计，测试计划，测试方案细分出各功能模块的测试项
在根据各测试项，按照概要设计，详细设计以及测试方案中测试的覆盖率细分出测试子项
最后按照测试子项，根据测试用例的设计方法(因果图、边界值、等价类等的设计方法)书写测试用例

一个身份证号码输入框 怎么设计用例
校验身份证好规则的有效性（包括地址码、出生日期码、顺序码和校验码
校验15位和18位都是可用的
校验末位是x的情况
校验不足15位，16-17位和大于18位的情况
如果是必输项，则要校验不输入的时候流程能否正常进行
校验输入非数字的情况，是否会有正确提示信息(包括大小写字母、汉字、特殊字标和标点符号）
校验输入全角的数字的时候，系统是否会识别(这个的根据需求确定是否可以使用全角的数字)

登录功能怎么设计测试用例
功能设计:
   1.正常输入，点击提交按钮，验证是否能正确登录
   2.错误校验，输入错误的账号或者密码，验证登录失败是否提示相应的错误信息
   3.登陆后是否跳转到正确的页面一般优先度是低
   4.安全性测试，账号和密码，如果太短或者太长，应该怎么处理，密码太短是否有提示
   5.是否做了过滤，账号和密码，中有特殊字符，和其他非英文情况
   6.记住账号的功能
   7.登陆失败后，不能记录密码的功能
   8.账号和密码前后有空格的处理
   9.密码是否加密显示
   10.牵扯到验证码的，要考虑文字是否扭曲过度导致用户辨认难度大，颜色是否对色盲使用者友好，刷新或换一个的按钮是否好用
   11.登录页面中的注册，忘记密码，登出用另一账号登录等连接是否正确
   12.输入密码时，大写键盘开启是否有提示信息
   13.非空检查，啥都不输入的情况下点击提交按钮看看是否有提示
界面测试(UI 测试)
   1.布局是否合理，2个testbox和一个按钮是否对齐
   2.testbox和按钮的长度，高度是否复合要求
   3.界面的设计风格是否UI的设计风格统一
   4.界面中的文字简洁易懂，没有错别字
性能测试:
   1.打开登录页面，需要几秒
   2.输入正确的密码和账号后跳转到新页面不超过5秒
安全性测试
   1.登录成功后生产的cookie受否有HTTPonly，可降低脚本盗取风险
   2.账号和密码是否通过加密的方式发给web服务器
   3.账号和密码的验证，应该时用服务器端验证，而不能单单时再客户端用js验证
   4.账号和密码的输入框应该屏蔽sql注入攻击
   5.账号和密码的输入框，应该禁止输入脚本，为防止xss攻击
   6.未防止暴力破解要限制错误登录的次数
   7.考虑是否支持多用户再同一机器上登录
   8.考虑一用户再多台机器上登录
可用性测试
   1.是否可以全用键盘操作，是否有快捷键
   2.输入账号，密码后按回车，是否可以登录
   3.输入框是否以tab键切换
兼容性测试
   1.主流的浏览器下是否能显示正常以及功能正常
   2.再不同系统是否正常工作
   3.再移动端是否能正常工作
   4.再不同的分辨率小是否正常

好的测试用例有那些特点
质量属性
   正确性：确保测试标题描述的部分内容正确
    经济性：只为确定需要的目的设计相应的测试步骤
    可重复性：不管谁执行此用例，结果都一样
    适应性：既能适应短期需要，又能考虑长远需求
    可追踪性：用例能追踪到一个具体的需求
    自我清理性：单个用例不会影响整个测试环境，即使执行完了也可以恢复原有的测试环境
    结构化和可测属性：
    含有规范的测试标题和编号：
    含有关于测试方法的描述
配置管理
    采用命名和编号规范归档
    保存为特定的格式，文件类型
   用例版本是否与当前被测试软件版本一致对应
    包含用例需要的相应测试对象，如特定数据库
    存档阅读，离线归档

缺陷BUG
   软件缺陷的生命周期
      对一个问题其处理过程是一个周期，周期的不同阶段，其所处的状态也是不一样的，不同状态所应的处理人也是不一样的
      打开 ： 表示问题被提交等待有人处理。
      重新指派 ： 问题被重新指派给某人处理。
      处理 ： 问题在处理中，尚未完成。
      固定 ： 确认此问题存在，但暂时不进行处理。
      回归 ： 对已经修复的问题进行回归确认。Reopened :
      关闭 ： 问题的最后一个状态。

缺陷报告单中应该包括那些内容
   缺陷的标题，简要描述，缺陷的类型，缺陷的详细步骤描述。缺陷的实际结果，期望的结果，有的缺陷需要上传截图，日志信息，缺陷等级。缺陷指派给开发同事
如何提高缺陷记录质量
   使用行业内惯用的表达术语和表达方法，每条缺陷报告只包括一个缺陷明确指明缺陷严重等级和优先等级，每一个步骤尽量记录一个擦做，确认步骤的完整性，书写公正等