测试面试问题总汇
给你一个全新的软件,你就是负责人,你怎么去开展测试工作
参考回答:
第一步:需求分析:我会对这个全新的软件需求进行全面分析,主要的分析点有:1.软件的版本需求合理性,是否可测试;2.项目人员配置(遇到什么问题找谁,有多少人投入测试,测试环境,硬件,软件);3.要测试的软件的主流程,异常流程,测试重点;4。项目整体规划(发布时间
第二步:指定测试策略、测试计划和bug定义标准,这一步主要是针对需求,在已有的和可协调到的资源上做出具体的,可执行的计划,这个阶段的输出是测试计划。测试计划中明确包含测试范围,测试策略,比如功能测试,性能测试,自动化测试,可用性测试,云测,mokey等
第三步:按计划执行,编写测试用例,(编写测试用例的方法:等价类,边界值,错误猜测法,因果图,正交分解法等等)(编写测试用例需要注意的点,用例区分等级,特殊场景考虑:为空(接口空、数据空)、加载超时、网络异常、重复提交、异常中断、缓存冲突、系统兼容、流程迂回、流程中断;如果是PC,要注意浏览器(IE,chrome,火狐,苹果的),操作系统(xp,win7,win8,win10,linux,mac)的兼容,如果是手机,注意手机的品牌,操作系统,android版本,手机屏幕尺寸,手机网络等等场景),写完用例,如果有条件,就要评审测试用例
第四步:执行用例,补充场景,记录bug,回归bug(注意开发提测的需求需要冒烟测试通过)
第五步:功能合入,回归测试(各个功能点测试通过之后,再合入)
第六步:提交验收(回归测试通过之后,提交给验收人员进行验收)
第七步:发布上线(全新的软件,先是小范围内测,观察线上数据(如:crash,用户反馈,运营数据等)如果有产品认为严重的问题,则需要修复后重发,符合预期才能扩大发布)
http://www.51testing.com/html/06/n-3721106.html
性能测试是动力,负载测试载重,压力测试强度
压力测试stresstest:是在一定的负荷条件下,长时间连续运行系统给系统性能造成的影响。
负载测试Loadtest:在一定的工作负荷下,给系统造成的负荷及系统响应的时间。
https://blog.csdn.net/hongfuqiang/article/details/78786187
设计系统测试需要参考的项目文档
软件测试计划
软件需求规范
迭代计划
文档测试
Namaste,guys ~此博客Val主要分享关于文档测试的概念。
一、文档测试的内容:
1、文档的完整性:主要是测试文档内容的全面性与完整性,从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。
2、描述与软件实际情况的一致性:主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后,我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。
3、易理解性:主要是检查文档对关键、重要的操作有无图文说明,文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的,应该附有图表使说明更为直观和明了。
4、文档中提供操作的实例:这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富,提供的实例描述是否详细。只有简单的图文说明,而无实例的用户手册看起来就像是软件界面的简单拷贝,对于用户来说,实际上没有什么帮助。
5、印刷与包装质量:主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成,过于粗糙,不易于用户保存。优秀的文档例如用户手册和技术白皮书,应提供商品化包装,并且印刷精美。
二、软件文档测试对象与目的
1、文档测试对象主要如下:
包装文字和图形;
市场宣传材料、广告以及其它插页;
授权、注册登记表;
最终用户许可协议;
安装和设置向导;
用户手册;
联机帮助;
样例、示范例子和模板;
2、文档测试的目的:
提高易用性和可靠性,降低支持费用,因为用户通过文档就可以自己解决问题。
因此文档测试的检查内容主要如下:
读者对象——主要是文档的内容是否能让该级别的读者理解;
术语——主要是检查术语是否适合读者;
内容和主题——检查主题是否合适、是否丢失、格式是否规范等;
图标和屏幕抓图——检查图表的准确度和精确度;
样例和示例——是否与软件功能一致;
拼写和语法;
文档的关联性——是否与其它相关文档的内容一致,例如与广告信息是否一致;
文档测试是相当重要的一项测试工作,不但要给予充分的重视,更要要认真的完成,象做功能测试一样来对待文档测试。
三、做好文档测试需要注意:
仔细阅读,跟随每个步骤,检查每个图形,尝试每个示例;
检查文档的编写是否满足文档编写的目的;
内容是否齐全、正确、完善;
软件的缺陷等级应如何划分?
致命的:致命的错误,造成系统或应用程序崩溃、死机、系统悬挂,或造成数据丢失、主要功能完全丧失等。
严重的:严重错误,指功能或特性没有实现,主要功能部分丧失,次要功能完全丧失,或致命的错误声明。
一般的:不太严重的错误,这样的软件缺陷虽然不影响系统的基本使用,但没有很好地实现功能,没有达到预期效果。如次要功能丧失,提示信息不太准确,或用户界面差,操作时间长等。
微小的:一些小问题,对功能几乎没有影响,产品及属性仍可使用,如有个别错别字、文字排列不整齐等。
测试过程中输出的文档
测试计划,测试文档,测试用例,测试日志,bug报告,测试总结报告
软件质量评估指标
1、功能性的质量指标
功能的正确性:系统功能和用户的实际需求、已定义的产品规范一致。
功能的准确性:系统产生的结果在精度允许的误差范围内。
功能的完整性:所有功能及其定义清楚、可用。
2、可用性的质量指标
可操作性:容易使用和操作,包括理解用户界面、适应一些特殊用户的可选项等。
通用性:数据显示、网络通信接口和用户界面等都遵守已有的软件标准。
一致性:在软件开发整个生命周期内建立和使用相同的标准,保证全局变量、数据类型、出错处理的命名和使用一致。
3、可靠性的质量指标
自我恢复能力:当系统的某个功能失效发生时,系统在当前环境下能实现故障自动转移,重新自动配置、继续执行的能力,软件系统具有自我检测、容错、备份等机制,尽量做到独立于硬件的编码、硬件设备之间的通信协议一致等。
健壮性:各种恶劣环境(大数据量、大用户量)下系统能正常工作。
分布性:软件系统的某些子功能或子系统被定位于不同的处理主机、存储设备。
4、性能的质量指标
有效性:系统在通信、处理、存储等方面占有很少资源或者对所使用的资源进行了优化。
完整性:系统具有良好的安全管理,能防止不安全存取系统、防止数据丢失病毒入侵等。
易存取性:对系统的存取权限设置清楚,存取操作方便,存取操作有记录。
5、可维护性的质量指标
模块化:指讲一个复杂的软件系统分解为分别命名并具备最小耦合性、很强凝聚性、结构化的组件。
灵活性:容易为系统增加一个新功能或者新的数据而不需要进行大量的代码修改或者设计修改。
可测试性:测试软件组件或者集成产品时查找缺陷的简易程度。
可追溯性:对一个特殊需求容易找出相应的代码,反之,也可以根据代码找出特定的需求。
兼容性:软件、硬件、通信系统之间协调及兼容其他系统的能力。
可解释性:相关文档齐全、符合标准、逻辑清晰、描述准确、用词恰当,容易理解和定位。
6、可移植性质量指标
适应性:系统不依赖于环境,即系统不做修改或作很少的修改即可运行在其他环境下。
易安装性:与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。
可重用性:一个软件组件除了在最初开发的系统之外应用于其他系统的能力。
互操作性:软件系统与其他系统交换数据和服务的难易程度。
可替换性:与软件在该环境中用来替代指定的其他软件的机会和努力有关的软件属性。
测试用例的维护、
软件产品的版本是随着软件的升级而不断变化的,而每一次版本的变化都会对测试用例集产生影响,所以测试用例集也需要不断地变更和维护,使之与产品的变化保持一致。以下原因可能导致测试用例变更:
1)软件需求变更:软件需求变更可能导致软件功能的增加、删除、修改等变化,应遵循需求变更控制管理方法,同样变更的测试用例也需要执行变更管理流程。
2)测试需求的遗漏和误解:由于测试需求分析不到位,可能导致测试需求遗漏或者误解,相应的测试用力也要进行变更。特别是对于软件隐性需求,在测试需求分析阶段容易遗漏,而在测试执行过程中被发现,这时需要补充测试用例。
3)测试用例遗漏:在测试过程中,发现测试用例未覆盖全部需求,需要补充相应的测试用例。
4)软件发布后,用户反馈的缺陷:表明测试不全面,存在尚未发现的缺陷,需要补充或者修改测试用例。
对于提供软件服务的产品,其多个版本常常共存,而对应的测试用例也是共存的,而且测试用例需要专人定期维护,并遵循以下原则:
1)及时删除过时的测试用例
需求变更可能导致原有部分测试用例不再适合新的需求要求。例如,删除了某个功能,那么针对该功能的测试用例也不再需要。所以随着需求的每一次变更,都要删除那些不再使用的测试用例。
2)及时删除冗余的测试用例
在设计测试用例时,可能存在两个或者多个用例测试相同内容,降低回归测试效率,所以要定期整理测试用例集,及时删除冗余的测试用例。
3)增加新的测试用例
由于需求变更、用例遗漏或者版本发布后发现缺陷等原因,原有的测试用例集没有完全覆盖软件需求,需要增加新的测试用例。
4)改进测试用例
随着开发工作进行,测试用例不断增加,某些用例随着系统输入和当前状态的变化而变得不再适用,这些用例难以重用,影响回归测试的效率,需要进行改进,使之可重用可控制。
总之,测试用例的维护是一个长期的过程,也是一个不断改进和完善的过程。