测试也可以和开发一样有前途（一）

//读书后的一些总结。

1.软件测试工程师的目标就是尽早地找出软件中的缺陷。

   而一个软件产品从无到有，再到上市需要经历以下过程：

  (1).收集客户需求，分析需求

  (2).设计系统架构

  (3).详细设计

  (4).编码

  (5).测试（单元测试、组件测试、集成测试、系统测试、用户验收测试）

  (6).产品上市

   在各个阶段进行参与各种文档的评审，在测试阶段和开发人重复一轮又一轮地发现缺陷、修改缺陷的循环。

   软件测 试阶段和软件开发阶段是同时开始且同时结束的，二者相互依赖。

2.在软件开发的V模式中设计、开发和测试之间的对应关系为：

•         先对设计文档进行测试---->静态测试，在开始测试各个阶段
•         需求分析 <-- --> 用户验收测试
•         系统概要设计 <-- --> 系统测试
•         (接口设计)、详细设计 <-- --> (功能测试)、集成测试
•         编码阶段 <-- --> 单元测试

  软件项目早期的设计开发阶段的工作：

1. 与设计、开发人员一起分析、审查对应的文档或代码2.开始着手准备测试计划、策略3.开发测试用例4.搭建测试环境5.编写测试脚本等

   而后期的主要工作：

1.测试、寻找软件缺陷2.对前期的设计和开发文档进行验证3.（开发人员则对软件缺陷进行修复）等

3.软件缺陷的表现方式总结如下：

·软件的功能没有实现

·软件的性能指标、安全指标、可靠性指标等非功能指标不达标

·产品的测试结果与设计不符

·产品运行时出现内存泄露、应用软件崩溃及系统崩溃等情况

·产品的易用性低，操作复杂，逻辑混乱，客户不易掌握

·软件的兼容性差

·软件产生的数据精度不够及不一致等

4.测试活动的流程

    一个测试活动从接手起一般经历对测试对象进行分析做出测试计划，开发测试用例，对软件产品进行测试，整理并发送测试报告等环节。

(1)测试计划描述：

测试计划描述内容规定软件测试活动的目的       
被测软件需要实现什么样的功能，在功能测试中要达到多少的覆盖率，非功能测试中要达到怎样的指标等
被测目标                                                    
说明软件及功能
测试范围
在测试计划文档中，指出对产品哪些部分进行测试，哪些部分不进行测试，指明某些部分是不在现有测试范围之内（网络异常处理不是黑盒测试条件下完成的，指明由单元测试保证），指明该测试所处的测试阶段（详细描述该测试阶段的进入条件、退出条件），该测试所包含的功能测试或非功能测试的类型（性能测试可单独拿出来做一个测试计划文档）
测试方法

指出所用的是白盒、黑盒或灰盒，或多者兼有，且指出测试方法的名称和在哪些情况下使用该方法（eg. 对文本框输入使用等价类划分和边界值法，对手机播放软件在不同信号环境中的表现使用状态变更法）

测试所要用到的资源
人力资源、设备资源，都制成表格形式。

人力资源：测试小组可能接触到的人和直接参与测试活动的人列成表格(姓名，职务，联系方式，职责范围)等，当遇到问题时很容易找到需要求助的人，且结合测试的进度表对每个测试人员进行测试任务的安排，责任到人。

设备资源：文档的归档、软件工具的归档、其他硬件设备的分配列成表格(文档/软件工具的名称，版本，用途，下载地址)等，维持一张硬件设备使用、维护、归属情况的列表。注意：对设备的预定和维护。然后        阐明对测试目标要进行哪些方面的测试、需要执行的测试任务、每个任务的负责人最后 列举项目中的风险和防范风险的措施
(2)测试用例的产生：

   早期，对需求和设计文档进行静态测试。阅读、分析文档，对文档中不清楚的部分进行询问，对文档中的错误进行更正。

    在需求和设计文档定稿之后，就开始按照需求和设计文档中确定的设计对测试用例文档进行修改和补充。建立需求或设计文档与测试用例的对应关系表。

    选择测试方法采用自顶向下的方法，首先是对测试用例适用的测试阶段进行划分，然后在每一个测试阶段中再对测试用例的测试目标进行划分(eg. 单元测试阶段要进行白盒测试，系统测试阶段要进行功能性测试、性能测试等)，之后可以开始分析为了实现某一个测试目标应该使用何种测试方法了（eg.白盒测试中用语句测试来覆盖所有语句，用基本路径测试来覆盖所有逻辑路径，用等价类划分和边界值法来覆盖功能测试中界面的输入框等）。

每一个测试用例至少需要给出的内容测试目标             对测试对象进行哪方面的测试，如功能性测试、性能测试、易用性测试、压力测试等测试对象    如软件产品中某一模块的某一功能；单元测试中测试对象可以是代码中的一个类/函数等；性能测试中可以是软件产品的某一个性能指标测试环境设置                   在执行测试用例时需要对测试环境进行的配置，如性能测试中配置模拟器以模拟网络中的流量、延时、带宽等情况；网站测试中配置操作系统和浏览器的搭配及浏览器的配置前提步骤需要先把软件实现运行到某一初始状态的步骤，然后再对软件进行针对该测试用例的测试输入数据需要事先准备好的测试数据，将测试数据和比对结果以附件或链接的形式附加在测试用例中操作步骤在执行该测试用例时，从前提步骤设置完成到比对期望结果之间需要运行的测试操作期望结果即该测试用例的验证点，通常每个测试用例设一个验证点。       注意：设计粒度适当的测试用例

       测试用例一般都采用测试用例套件的编写和组织形式，作为一个测试用例的仓库。

   当测试用例开发完成以后，应当组织对测试用例进行正式审查：事先定好会议室，至少提前一周将文档通过邮件等方式发送给参与审查的角色，并在审查会议开始之前定期的提醒参与审查者提交发现的问题和文档中写的不够清楚的地方，收集完问题以后积极对这些问题做准备。在审查会议上对前期收集的问题一一作出答复，遇到提出新的问题应记录下来，详细解答。对未解决的问题归档跟踪，直到所有问题解决及各方意见一致后，可以将通过审查的测试用例文档定稿。

    然后，有必要对测试用例进行一次有效性验证，作用只是验证测试用例与待测产品的一致性及测试用例中所描述的测试环境等的有效性，所以，测试用例的有效性验证只需要有代表性的挑选几个能体现产品特性和环境有效性的用例进行测试即可。

(3)以上准备工作完成后，开始执行测试：

安排测试轮次用例集合和测试用例执行进度，分配任务。

-->挑选测试用例组成测试轮次用例集合：

-->正式执行测试前的软件版本验证工作：

                             开发团队的版本验证工作                                  开发人员需要将新开发的代码和现存的代码集成并进行一遍完整的单元测试，通过后，需要将所有代码进行编译以生成可执行的软件镜像（非正式版本），并对其进行冒烟测试，原则是挑选该产品最具有代表性的测试用例和新改动部分的代表性的测试用例作为冒烟测试的测试用例计划。测试团队的版本验证工作 在新的可执行软件镜像通过冒烟测试之后，该镜像就成为测试团队的可测版本的一个候选版本， 对其进行版本验证测试BVT，测试目的是验证候选版本是否符合可测版本的要求（即该软件版本没有重大产品功能质量问题并且新开发的产品功能无重大质量问题等）。如果不符合，则候选版本将被退回开发团队；如果通过了BVT，则该可执行软件镜像就成为了测试团队的可测版本。
在新的软件版本通过了开发团队和测试团队的版本验证后，测试人员就可以开始按照该测试轮次中所分配的测试用例对软件产品进行测试了。

(4）报告测试缺陷

    一旦测试人员确定一个软件的问题是软件缺陷时，测试人员就有义务将其归档，并对该软件缺陷进行跟踪。一般存档于企业的缺陷管理跟踪系统中，缺陷包括软件缺陷、需求和设计文档的缺陷、硬件缺陷、对现有工作流程所提的缺陷。

·将软件缺陷进行归档并对其进行跟踪的意义：缩短软件缺陷被修复的周期；反映软件的质量；经验总结

·如何有效的对缺陷进行报告：在报告一个软件缺陷时应该尽量避免重复报告；简练准确的在缺陷的标题中描述该缺陷；一个缺陷报告记录一个缺陷；信息完整，将测试用例用到的测试数据和测试执行过程中所产生的一些文件作为附件附加在缺陷报告中；详细、精确的提供重现步骤并附加一些图片视频等信息有助于开发人员更直观的了解相关缺陷；报告软件缺陷时应当客观描述现象。

·当测试人员发现了一个软件缺陷时，就需要开始着手把这个缺陷录入到缺陷管理跟踪系统中。

录入一个缺陷报告的内容缺陷属性含义缺陷唯一标识      缺陷管理跟踪系统中对于每个缺陷的唯一标识，通常为系统自动生成报告时间缺陷报告生成的时间，通常为系统自动生成状态标识一个缺陷当前所处的状态，是缺陷生命周期中的一环。通常随着缺陷的生命周期的演化而变更缺陷报告人                    填写缺陷报告的测试工程师标题缺陷的总结，要求简练准确。
让开发人员在极短的时间内通过查看缺陷的标题就可以判断该缺陷是否已经有人报告过；如果没有，则能很快定位软件缺陷产生的位置和现象所属项目被测产品的项目名称产品被测产品的产品内部名称组件缺陷所在的组件版本缺陷所在的软件版本严重度客观的从客户的角度描述缺陷的严重程度。一般分为5级，通常由测试人员确定。
优先级缺陷被修复的优先级别。一般分为3~5级，通常由项目管理人员、开发组长、测试组长共同确定发现阶段缺陷被发现时的测试阶段起源阶段该缺陷本该在何测试阶段被发现。
例如，一个集成测试阶段应该发现的组件接口方面的缺陷却被遗留到了系统测试阶段才被发现当前负责人缺陷在生命周期中的某一个阶段的负责人。
随着缺陷状态的改变，缺陷的负责人从测试人员(Open状态)变为项目组成员(Assigned状态)，然后变成开发人员(Analysis或Fixing状态)，最后又回到测试人员手中(Verified状态)等详细描述直观、形象、完整的描述缺陷，提高缺陷重现率。
详细精确的提供重现步骤，附加一些图片、视频等信息有助于开发人员更直观的了解相关缺陷其中详细描述一项应该有统一的格式，如下面格式：

[缺陷简述(Summary)]... ...[缺陷描述(Description)]... ...[初始条件(Initial Condition)]... ...[重现步骤(Steps)]1......2......... ...[期望结果(Exception Results)]... ...[实际结果(Actual Results)]... ...[发生频率(Occurrence Rate)]百分比(Percentage)或重现次数/尝试次数比(Occurrence/Attempt)[附加文件(Attachment)]... ...[缺陷汇报人联系信息(Contact Information)]姓名(Name)电话(Telephone No.)邮件地址(Email ID)测试组(Team)

 ·缺陷的跟踪

 当测试人员完成了一个缺陷的测试报告时，即表明了这个缺陷的生命周期开始了，此时项目组人员就有义务对这个缺陷进行跟踪。

                    某一缺陷管理跟踪系统中一个缺陷从被报告到被关闭或被终结的所有生命状态及状态的可能变迁路径

                            

                              

其中，挂起状态通常是由于缺陷在某些状态中因缺少信息或不能重现等原因导致缺陷记录无法被继续正常处理而被转为挂起状态。当以上条件得到满足，开发人员得到了更多的信息或获得了重现的方法时，缺陷就可以从挂起转入分析状态以供开发人员开始分析。