小白测试总结
发布网友
发布时间：2022-11-04 13:34
共1个回答
热心网友
时间：2023-11-05 03:55
不计算测试计划以及测试方案的编写，测试过程中最重要的环节就是需求分析了，测试需求分析就是分析我们测试什么、如何测试的过程。通过完备的测试需求分析可以输出高质量的软件测试用例。
需求分析首先是根据软件需求规则说明书进行细节性的需求整理，以此来了解软件整体的构成、功能的流程走向和软件要服务的对象。
所以流程连贯起来就是测试需求来源分析->需求项整理->测试项分析->测试子项分析->测试用例设计->测试用例实现->缺陷的管理及维护->整体测试阶段的整理->上线报告。
1、测试需求来源分析
（1）开发需求
即站在开发人员角度分析整体需求，了解开发人员的大致开发思路（循环体、随机函数、封装函数的多次调用、多线程乃至可能出现的内存泄漏等）
（2）原始需求
原始需求也就是最直观的、最重要的参考，也就是产品给出的软件需求规则说明书，上面有明确的功能规则说明，大至整体的软件框架，小至输入框的字符规定。
（3）用户需求
考虑到用户的主要集中人群特征，年龄、性别、爱好、平时操作高发时间段及喜欢的色调等。如果有β测试的机会，能够更好的搜集测试依据。
（4）测试案例库
也就是结合之前的项目经验，经历过的软件乃至平时用到的软件所遇到的缺陷全部加入到测试工作中，还要重点关注。
（5）竞争分析
也就是同行业软件的对比分析，取其精华，去其糟粕。如果有竞争分析报告之类的原始测试需求来源中可以直接提验一些功能规格、性能指标、操作规范等作为所测试系统的原始测试需求。
2、测试项分析
采用质量模型分析、功能交互分析、用户场景分析等等，每个方法都要独立的输出初始测试项，也就是说初始测试项是从不同测试角度进行分析输出的结果。质量模型分析是从软件的功能性、可靠性、效率、易用性、可维护性、可移植性等角度来衡量。功能交互分析是将被测功能和软件其他相关功能进行交互分析，根据影响点可以得出初始测试项。用户场景分析是从用户角度出发，来关注每个用户是如何使用和影响被测功能特性的，更能从基于用户的角度来分析。分析用户存在哪些使用可能的场景，每一个场景都可能是测试项。
3、测试子项分析
测试子项分析活动是针对测试项的进一步分析、细化，形成为测试子项的活动过程。对粒度小的测试项不处理，直接进行特性测试设计，对粒度大的测试项进一步细化，形成为测试子项，然后对测试子项进行特性测试设计
二、测试用例的设计
软件测试用例设计是从设计层面考虑，比如从功能性/可用性/安全性等方面考虑设计测试用例
1、 测试用例的属性
测试用例ID、测试项、测试标题、重要级别、预置条件、输入、操作步骤、预期结果等。
其中测试项明确出所在功能模块，测试标题表明该用例要验证的结果，预置条件指明该测试用例执行的环境，输入是为了说明引入的测试数据，预期结果要对应需求规则说明书或者真实环境。
2、 测试用例的设计方法
（1）等价类划分法
某个输入域的集合，在这个集合中每个输入条件都是等效的，如果其中一个的输入不能导致问题发生，那么集合中其它输入条件进行测试也不太可能发现错误。
例如给出一个输入框的字符类型为正整数，则有效等价类即为正整数，无效等价类为负整数、零、小数、符号、字母等。
（2）边界值分析法
边界值分析方法的理论基础，是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附件的取值不会导致程序出错，那么其它的取值导致程序错误的可能性也很小。
例如给出一个输入框的字符范围为(6,10]，则取6与10附近的数值进行测试，开区间取有效值，闭区间取边界值，再结合无效值各取其一。
（3）判定表
判定表主要用于逻辑的判断，将对与错的结果全部在表格中展示，以此分析出正确与错误的情况。
例如视力测试中通过判断三个E的方向对错来决定升一级或者降一级继续测试，错误次数超过一半即为当前阶段测试失败，正确超过一半即为当前阶段测试成功，那么
（4）因果图
又叫鱼骨图，与思维导图有相似之处。
（5）场景设计法
场景设计法依靠流程图或者时序图，可以清晰的列出开发人员的思路，特别是用于循环判断、随机数判断等，主要用于路径的覆盖。
三、 其余
1、 风险评估
主要针对测试对象的优先级，考虑功能之间的交互影响，单个功能对整体系统的影响，某个功能对后续版本的影响等问题。需要考虑某个对象在系统中起到什么样的作用？如果该功能在使用过程失效会带来什么样的后果？
2 、测试环境的确定
从软件的编码、测试到用户实际使用，逐个对三大环境（开发环境、测试环境和用户环境）进行对比分析。
