标签：
软件测试学习随笔
WCX第一周软件测试的学习笔记
入门时从软件测试的方法入手，总结如下
软件测试的方法总结：
|
测试名称 |
测试内容 |
|
Black box黑盒测试 |
把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。从软件的行为，而不是内部结构出发来设计测试. |
|
White box白盒测试 |
设计者可以看到软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。 |
|
Gray box. 灰盒测试 |
介于黑盒和白盒之间 |
是手动还是自动又可以分类
|
测试名称 |
测试内容 |
|
Manual Test 手动测试 |
测试人员用鼠标去手动测试 （测试GUI） |
|
Automation 自动化测试 |
用程序测试程序 （测试API） |
从测试的目的分类
|
测试名称 |
测试内容 |
|
Unit Test 单元测试 |
在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员做的) |
|
Functional Test 功能测试 |
验证模块的功能 （测试人员做的） |
|
Integration Test 集成测试 |
验证几个互相有依赖关系的模块的功能 （测试人员做的） |
|
Scenario Test 场景测试 |
验证几个模块是否能完成一个用户场景 （测试人员做的） |
|
System Test 系统测试 |
对于整个系统功能的测试 （测试人员做的） |
|
Alpha 测试 |
软件测试人员在真实用户环境中对软件进行全面的测试 （测试人员做的） |
|
Beta 测试 |
真实的用户在真实的用户环境中进行的测试, 也叫公测 （最终用户做的） |
软件测试的过程有：
第一步：对要执行测试的产品/项目进行分析，确定测试策略，制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。
第二步：设计测试用例。设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大，则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。
第三步：如果满足“启动准则”（EntryCriteria），那么执行测试。执行测试主要是搭建测试环境，执行测试用例。执行测试时要进行进度控制、项目协调等工作。
第四步：提交缺陷。这里要进行缺陷审核和验证等工作。
第五步：消除软件缺陷。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”（ExitCriteria），那么正常结束测试。
第六步：撰写测试报告。对测试进行分析，总结本次的经验教训，在下一次的工作中改。
软件测试过程管理，主要包括软件测试是什么样的过程，如何评价一个软件测试过程，如何进行配置管理和测试风险分析以及测试成本的管理。
了解到软件测试的内容总结，包括：
软件测试主要工作内容是验证（verification）和确认（validation），下面分别给出其概念：
验证(verification)是保证软件正确地实现了一些特定功能的一系列活动， 即保证软件以正确的方式来做了这个事件(Do it right)
1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程。
2.程序正确性的形式证明，即采用形式理论证明程序符合设计规约规定的过程。
3.评审、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
确认（validation）是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件做了你所期望的事情。（Do the right thing）
1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性。
2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问题。
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期间各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。
标签：
原文地址：http://www.cnblogs.com/tjuwcx/p/4337997.html
