为了发现程序中的错误而执行程序的过程
通过修正各种错误和缺陷提高软件质量,避免软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
黑盒测试:不考虑内部设计和代码,只依据程序的需求规格说明书进行测试。
白盒测试:根据应用软件的代码的内部逻辑,按照代码的语句、分支、路径和条件进行测试。
软件测试流程:需求分析、测试计划、测试设计、测试方案、测试执行。
需求分析:主要就是对业务的学习,分析需求点。
测试计划:测试经理根据需求开始编写《测试计划》,其中包括人员,软件硬件资源,测试点,集成顺序,进度安排和风险识别等内容。
测试设计:测试方案一般由对需求很熟的高资深的测试工程师设计,测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介,测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。
测试方案:主要是对测试用例和规程的设计。测试人员对整个系统需求有了详细的理解,这时开始编写用例才能保证用例的可执行和对需求的覆盖。
测试执行:执行测试用例,及时提交有质量的Bug和测试报告等文档。
1.用例全部执行。2.缺陷率达到标准。3.覆盖率达到标准。4.其他指标达到质量标准.
黑盒测试(Black box testin) —— 不考虑内部设计和代码,根据需求和功能进行测试。
白盒测试(White box testing)— 根据应用软件的代码的内部逻辑,按照代码的语句、分支、路径和条件进行测试。
功能测试(functional testing)—— 对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。
回归测试(regression testing)—— 每次软件经过整理、修改、环境变化,做的重复测试。很难说需要进行多少回归测试,此种测试,特别适于使用自动测试工具。
验收测试(Stress Test) ——软件产品完成了功能测试和系统测试之后,在产品发布之前所进行的软件测试,它是测试的最后一个阶段,通过了验收测试,产品就会进入发布阶段。
负载试验(load testing)—— 在一定的工作负荷下,给系统造成的负荷及系统响应的时间。例如测试一个网站在不同负荷情况下的状况,以确定在什么情况下系统响应速度下降或是出现故障。
压力测试(stress testing)—— 是在一定的负荷条件下,长时间连续运行系统给系统性能造成的影响。
容量测试(Volume Testing)——确定系统可处理同时在线的最大用户数。
性能测试(Performance Test)——其实是压力测试、负载测试、容量测试的统称。
强度测试(Stress Test) ——强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况,目的是找到系统在哪里失效以及如何失效的地方。
可能大家觉得性能测试、负载测试和强度测试比较混淆。没错,这三个概念是比较容易使人糊涂。负载测试和强度测试,都属于性能测试的子集。下面举个跑步的例子进行解释。 性能测试,表示在一个给定的基准下,能执行的最好情况。例如,在没有负重的情况下,你跑100米需要花多少时间(这边,没有负重是基准)? 负载测试,也是性能测试,但是他是在不同的负载下的。对于刚才那个例子,如果扩展为:在50公斤、100公斤……等情况下,你跑100米需要花多少时间? 强度测试,是在强度情况下的性能测试。对于刚才那个例子,如果改为:在一阵强风的情况下,你在负重或没有负重的情况下,跑100米需要花多少时间? 性能测试是动力,负载测试载重,压力测试强度
Alpha 测试:有点相当于内部测试,一般开发人员在场,是由用户做测试,但开发人员在场,一般是请用户到开发现场去测试
Beta 测试:由多个或一个用户进行的测试,完全交给用户,由用户做测试,返回测试报告。
熟读上面两题这题就很写出来,一般公司这个题目出现率很高。(个人觉得)
如果确实是自己理解错误,则承认错误,没什么打不了。如果是需求不明,请项目经理补充清楚。如果双方理解不一致,且都不能互相说服,则请项目经理判断。
等价类划分、边界值分析法、错误推测法、因果图方法、场景分析方法。
等价类划分:等价类是指某个输入域的子集合,在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。并合理地假定:测试某等价类的代表值就等于对这一类其他值的测试,因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量性的测试数据,取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。
边界值分析法:边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误时发生输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。
错误推测法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。
因果图方法:前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等。考虑输入条件之间的相互组合,肯呢过会产生一些新的情况。但要检查输入条件的组合不是一年容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
正交表分析法:有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。
1.BUG产生对应软件版本
2.BUG的优先级
3.BUG的严重程度
4.BUG标题,需要清晰的描述现象
5.BUG描述,需要尽量给出BUG步骤
6.BUG附件,给出相关日志和截图
7.测试的相关人员姓名
高质量的BUG记录就是指很容易理解的BUG记录,所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位。
测试周期分为计划、设计、实现、执行难、总结。其中:
计划:对整个测试周期中所有活动进行规划,估计工作量、风险、安排人力物力资源,安排进度等。
设计:完成测试方案,从技术层面上对测试进行规划。
实现:进行测试用例和测试规程设计。
执行:根据前期完成的计划、方案、用例、规程等文档,执行测试用例。
总结:记录测试结果,进行分析,完成测试报告。