软件测试管理

软件测试：在规定的条件下对程序进行操作，以发现程序的错误，衡量软件质量，并对其是否能满足用户需求进行评估的过程。
点工

项目研发：
1、立项
立项依据：商业论证（可行性分析报告）
编写角色：市场人员、项目经理、产品经理
内容：分析项目的成本和收益
项目立项会议召开标志项目团队成立。

2、需求调研：了解调研用户的原始需求
方式：访谈、市场调研（问卷调查）、竞品分析
负责角色：产品人员（需求人员）
原始需求调研完成后形成用户需求文档，进行评审。
理论上测试人员越早介入软件研发的过程越好
用户故事（需求）：以讲故事的形式阐述用户需求
包含三要素：用户是谁，用户使用软件要干什么，对用户会产生什么价值。

3、需求分析：将用户需求转换为软件需求，形成软件需求规格书
负责角色：产品人员（需求人员）
需求规格书需要评审。
4、开发和测试的工作同时启动。
开发做计划–编写架构设计（概要设计）–编写详细设计（单元设计）–编码
测试做计划–做测试设计–编写测试用例–编码完成执行测试—测试报告----发布上线–运维 。

软件测试三大阶段：
单元测试：编码过程中函数写完就可以执行测试。
验证代码的实现是否符合单元设计。
行业现状：几乎不做，即使做也是由开发人员自己完成。
集成测试：编码过程中模块写完执行测试。
验证各模块间的数据交互是否正常。模块间通过接口进行交互，集成测试主要做接口测试。
行业现状：执行接口测试的少，有正在推广普及的趋势。实际工作是在系统测试阶段做接口测试。
针对接口测试，开发需要提供接口说明文档。

系统测试：编码后针对整个系统进行测试。
验证软件是否符合需求规格书。

验收测试：系统测试完成后，由甲方（用户）或用户代表执行测试。

阿尔法测试：在公司内由非测试人员进行测试，类似公司内验收（内测）。
贝塔测试：有公司外的人员（部分人员，不是全部用户）进行测试（公测）。

测试方法：
白盒测试：把软件比作一个打开的盒子，可以看到软件代码的实现，针对代码的实现验证代码是否存在问题。
单元测试阶段采用的测试方法。

灰盒测试：介于白盒和黑盒测试之间。灰盒测试关注输入、输出的正确性，同时也关注内部表现。但是不像白盒测试那样细致。
集成测试阶段适用灰盒测试。

黑盒测试：把软件比作封闭的盒子，不关心软件内部代码的具体实现，根据软件对外展示出的功能进行测试。
系统测试阶段采用黑盒测试。

动态测试：通过运行软件执行测试。
静态测试：不通过软件运行执行测试，主要以代码走查、文档评审为主。

测试人员：测试经理（测试组长）、测试工程师
测试团队在公司的组织架构中是一个独立的部门，不能归属于某个研发部门。
测试流程：
测试计划—测试分析—测试用例编写—执行测试----测试报告。
测试计划：
编写人员：测试负责人
计划完成需要评审
测试分析和用例设计：
编写人员：测试团队分工完成
测试设计完成后需要评审
执行测试：
测试人员分工协作完成。

测试报告：
编写人员：测试负责人（往往需要测试团队其它成员协助完成）

系统测试完成后软件发布上线

单元测试（unit testing）：
是指对软件中的最小可测试单元进行检查和验证。对于单元的定义取决于自己，单元可能是函数，可能是一个类或是一个方法。
单元测试是在软件开发过程中进行的最低级别的测试活动，测试的单元将在与程序其它部分隔离的情况下进行测试。
单元测试目的：
1、验证代码与设计是否相符
2、跟踪需求和设计实现
3、发现代码中的错误。
单元测试活动：
代码走读：开发人员之间随机的相互阅读代码，检查代码的编写是否正确。
工作中往往是架构师、经验多的人检查工作经验较少的人的代码
动态分析：通过设计用例并执行来观察软件运行时的动作，来检查代码是否有问题。

集成测试（Integration Test）：
在单元测试的基础上将单元测试模块逐个集成、组合，以验证它们是否按预期工作。
改测试的主要目标是单元或模块之间的接口。
集成测试首先单独测试各个模块，单个模块测试完成后，逐个集成，直到所有模块都集成在一起，检查所有模块集成到一起后是否存在问题，验证需求是否正确实现。
集成测试常见测试方法（集成方法）：
1、大爆炸集成：所有模块一次性集成到一块进行测试。
好处：测试方法简单，易行。
缺点：测试不充分
当模块较多时，一次集成会出现大量错误。

2、自顶向下集成：从最顶层模块开始集成，逐步集成底层模块。
好处：集成较容易，测试和开发可以并行工作，可以较早进行验证。
缺点：底层验证被推迟，容易测试不充分。
3、自底向上集成：从最底层模块开始集成，逐步集成顶层模块
好处：可以尽早验证底层模块
缺点：顶层模块被推迟验证，不能及时发现顶层模块的问题。
4、三明治集成：是一种混合测试策略，综合了自顶向下和自底向上的优点，把系统分成三层：顶层、中间层、底层。
从顶层和底层同时向中间层集成。
优势：具有自顶向下和自底向上的优点
缺点：中间层不能尽早测试。

大多数集成测试采用三明治集成。

系统测试：系统测试是将已经集成好的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、数据、某些支持软件、
和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行的一系列测试活动。

系统测试目的：验证软件是否满足需求规格说明书要求。
需求类型：
显性需求：需求规格说明书中明确写出来的需求。
隐性需求：需求规格说明书中没有明确写出但是必须要满足的。
法律、法规、行业标准
用户的使用习惯
当地的风俗习惯

系统测试的对象：软件系统、软件+硬件

系统测试各大阶段：
1、计划：编写测试计划
编写人员：测试负责人
怎么编写：一般先看是否有类似项目的计划，借鉴参考。
如果没有可借鉴的项目则自主完成。
计划编写准备：了解学习需求。
估计工作量（人天、人时、人月）
工作量估计：会议的形式，会上有人负责讲解需求，所有人员在理解的基础上每个人估计
工作量，一般会估计三个值：悲观值、乐观值、正常值，
然后平均值=(悲观值+乐观值+正常值*4)/6,每个人的平均值计算完成后，再看
各个平均值是否收敛（相近），如果收敛再求和除以人数得到估计的工作量。
如果不收敛继续重新再估一轮，直到收敛。
实际中往往时每个分工后，各自凭经验估计各自的工作量。
估计工作量时要留余量，一般30%。

  计划编写依据：项目管理计划、开发计划
  计划内容（5w1h）：
       why：明确系统测试目标，验证软件是否符合需求规格书要求
       what：明确测试工作的范围
       when：明确测试工作的时间范围，明确测试各个阶段的时间范围，明确每一项任务的时间范围
       who：明确测试分工，工作量要相对平均，分工一定要明确到人。
       where：明确测试环境（研发环境、测试环境、生产环境（线上环境、真实环境））
       how：怎么测试，明确测试的方法、选用的测试工具，测试工作的标准规范。
计划的作用：可以有效的计划、执行、跟踪、组织和管理测试活动。

计划写完需要评审

2、设计：写方案，分析测试需求，分析测试点
编写人员：一般是测试团队分工协作完成。
测试设计工作往往与计划工作并行开展。
设计作用：从技术角度规范和控制测试活动。
方案写完需要评审

3、编写用例（实现）：设计测试用例
用例设计：往往也是测试团队分工完成
用例编写完成需要评审。

4、执行：
执行前提：编码完成
测试执行准备：
1、准备测试环境：把被测软件搭建部署起来。
涉及工作：安装linux操作系统、安装数据库、安装web服务（apache、tomcat、nginx）、安装依赖软件等
2、准备测试数据
冒烟测试：验证软件基本功能。
系统测试正式开展之前执行冒烟测试。冒烟测试时间较短，只验证基础和核心功能是否正常。
转系统测试：测试组内进行评审，判断是否达到系统测试条件，如果达到，则正式通知项目组全体人员，开始执行系统测试。
执行测试：
1、发现bug并提交开发，还要对bug进行跟踪管理：了解bug的原因、解决的方法、解决的时间。
开发人员解决bug后测试需要验证bug是否解决，是否引入新问题，需要依据bug的原因及解决方法确定验证的测试范围，
确保问题解决的同时没有引入新问题。
2、工作报告、工作总结：报告分周报、日报、月报。总结内容不限、形式不限、时机不限。

测试报告：按照实际工作内容总结测试工作的各种情况。
     编写人员：测试负责人，往往需要团队成员协助。
     主要内容：测试结论、各种统计数据。
         统计数据作用：测试结论的依据。
                       为后续项目做参考。					通过数据分析研发过程中可能存在的问题，找到原因，制定措施，优化研发流程。 

召开发布会议，发布上线。

系统测试主要测试类型：
1、功能测试：需要从需求和业务角度考虑
软件常见统称：erp（企业资源计划）、crm(客户关系管理)、银行类、财务类、物流类
功能测试发现错误：
1、功能实现错误，与用户需求不符
2、功能实现遗漏，少了某些功能
3、功能实现多余，实现了多余功能

2、性能测试：测试软件匹配性能需求的能力。
关注点：
响应时间：系统对请求作出响应的时间。
2-5-8原则：如果系统2秒内作出响应，会感觉系统响应很快。如果2-5秒内作出响应，会感觉系统响应还可以。
如果5-8内作出响应，会感觉响应很慢但是还可以接受。如果超过8秒还没有响应，会感觉很糟糕，会认为系统
已经失去响应，从而发起二次请求或离开改软件。

   并发用户数：指系统可以同时承载的正常使用系统功能的用户数量。
   吞吐量：系统在单位时间内处理请求的数量
   服务器的资源利用率：cpu的使用率、内存的占用率、磁盘的读写速率（I/O）
app性能测试额外关注指标：
   1、手机端的资源利用情况：cpu、内存的使用率
   2、耗电量
   3、启动速度
   4、界面的滑动、跳转速度

性能测试工具：jmeter、loadrunner
工作中性能测试两种情况：
有性能测试需求：按照需求测试即可
无性能测试需求：需要不断增加系统的负载，测试出软件的性能指标。

3、GUI测试（界面测试）：关注人机界面展示。
gui测试考虑方面：
1、整体风格：色彩使用、界面元素排版布局
2、针对具体元素考虑：
单选框：首先考虑是否需要设置默认值。选择一下，只能单选
复选框： 首先考虑是否需要设置默认值。选择一下，可以多选
输入框：首先考虑尺寸大小，考虑输入超过最大限制是否可以继续输入，输入框回显
密码框：首先考虑尺寸大小，考虑输入超过最大限制是否可以继续输入，只能掩码显示，不能支持复制、剪切。
下拉框：首先考虑尺寸大小，关注下拉菜单内的值是否完整、正确。是否需要设置默认值。
超链接：考虑连接的对不对，考虑超链接上的内容与链接到的内容是否一致。
4、易用性测试：关注用户体验
具体体现：能选择不输入、支持快捷键操作、菜单级数不超3级，提供导航式操作，提供帮助手册、提示信息。
最终目标：软件要易理解、易学习、易操作、有吸引性。

5、兼容性测试：指测试软件在不同的软件之间、操作系统平台上、不同的网络环境中是否能很好的运行。
主要考虑兼容内容：
1、操作系统
2、应用软件的兼容性：framework、jdk、flash
3、浏览器兼容性：IE、Firefox、Chrome
4、分辨率兼容性
其它：操作系统语言、时区
APP兼容性测试：
安卓：考虑兼容多个安卓版本、考虑兼容不同手机厂商系统、考虑兼容不同屏幕尺寸
IOS：一般考虑最新IOS版本、一般考虑最新型号的手机，一般往前倒推1-2个版本

可靠性测试：可靠性是指软件不管怎么用都不出问题，或问了问题也能很快解决
测试类型：
随机测试：无规律操作软件
异常测试：测试软件出现异常（故障）后是否可以恢复，以及恢复的程度和时间
往往需要人为制造故障

安全测试：测试系统受到恶意攻击时，系统的自我保护能力，病毒防护能力。
从功能测试角度考虑软件安全性：
1、密码要有一定长度和复杂度要求
2、改密码必须验证老密码
3、是否需要使用HTTPS安全协议。
4、是否存在超时验证
5、密码要加密传输、加密存储（sha-one）
6、是否有防爆力破解机制（连续登陆失败达到一定次数锁定账号或IP）
7、用户相关数据的校验必须在服务端进行。

稳定性测试：测试系统在一定的负荷下，长时间运行的情况。
负荷：有一定的数据量、有一定的用户量、软件要运行
测试时间单位：N天
发现问题：内存泄漏

文档测试：测试文档的正确性和可用性。