软件测试面经

你觉得你的优势在哪儿？

我是通信工程和计算机双学位，也算科班出身，计算机的基础知识都有掌握，个人也学过一些测试相关的课程，虽然没有实际的经验，但
对测试有一定了解和理论知识。

测试是什么？测试的流程是什么？

测试是发现软件错误，衡量软件质量并对其是否满足设计和满足需求进行评估的过程。

你知道哪些测试方法？

我知道有按照测试方法有黑盒测试和白盒测试，逻辑覆盖法是白盒测试的主要方法，有语句覆盖，条件覆盖，判定覆盖，条件-判定覆盖等。黑盒测试可以用等价类划分法，边界取值法，正交图，判定表，因果图这些方法，黑盒测试有自动化测试，功能测试，性能测试，安全测试等。
如果按照生命周期来划分有单元测试，冒烟测试，集成测试，系统测试，验收测试。

说一下等价类测试方法

等价类测试方法就是把输入划分为若干个子类，每个类中的每一个元素都可以代表这个子集，比如二位数加法器，1+2,1+55这种正数和正数相加可以划分为一个等价类，区间内正数和负数相加划分为一个等价类，负数和负数相加，还要划分无效等价类

如果测试中有缺陷但是开发人员不认可怎么办？

对这个缺陷做更多测试并将其提交给开发人员，表明这个缺陷不解决最后项目上线时会有影响

给你一个京东登录界面怎么测试？

首先由三种登录方式，一种是输入账号和密码，一种是手机扫码登录，一种是第三方比如微信直接登录。

功能测试

• 输入正确的账号密码看能否登录成功
• 输入正确的账号错误的密码
• 输入错误的账号正确的密码
• 输入错误的账号错误的密码
• 不输入账号看提示信息
• 不输入密码看提示信息
• 验证码测试
• 如果用户未注册，提示用户注册的页面是否友好？
• 界面是否美观？
• 输入html5,javascript是否会破坏页面渲染？
• 密码存储显示是否加密？
• 账号密码位数支持，最短和最长，超过或者不足是否有提示？
• 是否支持￥%*&等特殊符号
• 是否可以复制粘贴
• 忘记密码跳转界面是否正确
• 开启大写是否有提示信息

性能测试

• 打开登录界面需要几秒
• 输入正确后跳转时间需要几秒

安全测试

• 登录成功后生成的cookie（cookie是一个小信息，服务器写给浏览器的，客户端保存cookie信息），是否是http only（http only是cookie内一个附加flag，能有效放置XSS攻击）
• 用户名和用户密码是否通过加密方式传给web服务器？
• 用户名和密码的验证应该在服务器端而不应该在前端
• 错误登录的限制
• 是否支持多用户在同一台机器登录
• 是否支持单用户在不同机器登录

界面测试

• 布局是否合理，按钮文本框是否对齐
• 输入框和按钮的高度长度是否合理
• 界面的设计风格是否美观？
• 界面的文字是否简洁易懂？

兼容测试

• 主流浏览器（IE,火狐，谷歌之类的）
• 是否能在Windows和macOS上运行
• 是否能在Android and ios上运行
• 测试分辨率

可用测试

• 是否有快捷键（ctrl+c,ctrl+v,ctrl+z等）
• 输入密码后按回车是否能登录

Java的基本数据类型

整型（int long short ）
浮点型（float，double）
字符型（char string）
布尔型（boolean）

TestNG的核心文件是？

testng.xml

三次握手和四次挥手

http和https的不同

http是超文本传输协议，明文传输，运行在传输层tcp之上，客户端和服务器端都无法校验对方的身份，端口80

https是身披ssl（安全套接字协议）的http，相当于添加了加密和认证机制的http，端口443.，

资源消耗：Https通信会由于加减密处理消耗更多的CPU和内存资源；
开销：Https需要申请证书，而证书一般需要向认证机构购买；
http连接很简单，无状态的，而https是由SSL+HTTP协议构建的可进行加密传输、身份验证的网络协议，比http安全。

https为什么安全？

HTTPS是加密传输，就算数据被截取了也无法破译。

TCP和UDP的区别？

TCP是传输层控制协议，UDP是用户数据报协议

• TCP是面向连接的，UDP是无连接的；
• TCP是可靠的，UDP是不可靠的；
• TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多的通信模式；
• TCP是面向字节流的，UDP是面向报文的；
• TCP有拥塞控制机制，UDP没有拥塞控制，适合媒体通信；
• TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大

web自动化测试工具

selenium
RFT
QTP

什么是兼容性测试？兼容性测试侧重哪些方面？

CTS（简称）是指所设计程序与硬件，软件之间的兼容性测试。不同的硬件平台，不同的软件，不同的操作系统，不同的网络环境是否能很友好地运行测试

兼容测试又分为web兼容性测试和APP兼容性测试，侧重一些常见的软件硬件环境的兼容性，比如火狐浏览器，Chrome，IE，360.华为P40手机，Windows10，safri浏览器这些

谈一下职业规划

首先巩固自己的测试基础知识，在此基础上进一步提升阅读需求文档的能力。并且学习自动化测试工具并将其运用到实际工作中去。

然后争取带领一个测试团队。

软件评审有哪些人员参加，其目的？

软件评审由开发人员，测试人员，项目经理，客户参加。目的是在软件正式投入运行前看看其能否在不同平台运行，是否完全满足客户需求，能否再改。

开发人员总犯一些低级错误怎么办？

要在开发的前期就制定好一些编码规范，这样子可以减少很多由于个人习惯引起的错误。同时，测试人员在发现开发人员犯一些低级错误的时候不可以指责他们，要耐心的给他们指出错误所在。然后在让开发人员自己进行测试，从而找出错误。

缺陷测试报告是什么？缺陷测试报告的组成？

缺陷测试报告是对缺陷进行记录，跟踪和分类的文档（准确，清晰，剪简洁）。

缺陷编号，缺陷的描述，缺陷的优先级，缺陷所属版本，缺陷重要程度，缺陷所属开发人员，缺陷分析。

标题发现的缺陷越多，说明软件缺陷越多吗?

答：是的，通常如果发现一个缺陷的话，可能就会发现很多类似的缺陷，由于开发人员的习惯，可能一个地方有缺陷，另外一个地方就会有相同的缺陷。

所有的软件缺陷都要修复吗？

一些对于软件没有影响的、不影响使用的缺陷我们可以不修复。先满足项目时间。

软件测试什么时候开始？为什么？

越早越好，最好需求阶段就开始，软件测试不仅仅是功能测试，还包括对文档的测试，对需求文档的测试。越早找出来bug，开发人员犯的错误越少，且可以有效降低成本。

功能测试用例需要详细到什么程度才是合格的?

答：测试用例覆盖到所有的测试点。

测试用例应该包含哪些内容？

1、 前提条件，如项目或局部测试环境的需求，及其交付计划
2、 测试步骤
3、 测试数据
4、 预期结果

微信支付测试用例

功能
扫二维码
1.第一次扫描付钱二维码时可以得到相机权限，进入付钱界面
2.第一次扫描付钱二维码时可以拒绝相机权限，退回聊天界面
3.扫一扫可以扫描收钱的二维码
4.扫描出来的信息与收钱人信息相符
5.输入框只能输入数字
6.一次能支付的最大钱数
7.一次支付的最少的钱数
8.一天最多能支付多少次
9.一天支付钱数是否有上限
10.支付的钱数小数位最多为2位
11.能否直接输入小数点
12.能否添加备注
13.备注的最大字数为10
14.添加备注完了，按确定按钮保存备注
15.不想添加备注，可以按取消，取消备注

收付款
16.打开后能否显示付款二维码和条形码
17.条形码和二维码都可以付钱
18.付钱方式可以选择，零钱，信用卡，银行卡
19.零钱是否显示余额，以及余额是否正确
21.显示银行卡的数目和绑定银行卡的数目是否一样
22.是否显示银行卡的后四位，以及后四位是否与对应银行匹配
23.支付时余额不足，是否支持其他方式支付
24.网络异常支付失败
25.钱数够，密码正确，显示支付成功
26.钱数够，密码错误，支付失败
27.支付时余额不足，是否有提醒
28.取消支付后，余额或者银行卡里的钱数不变
29.支付失败，余额或者银行卡里的钱数不变
30.支付时有电话进入时，接完电话可以继续支付
31.支付时有信息来时，处理完信息可以继续支付
32.如果没有开启指纹支付，在第一次支付完后会有提醒是否开启指纹支付
33.是否可以选择指纹支付和密码支付
34.指纹支付时可以识别指纹
35.金额和密码是否支持复制粘贴操作

红包优惠卷
36.当有优惠劵且支付金额大于优惠券金额时，是否可以抵消现金
37.抵消现金后支付金额是否正确
38.当支付金额小于优惠券金额时，优惠券是否可用
38.1.当超过优惠券期限后是否还可以使用优惠券
38.2在优惠券期限内是否还可以使用优惠券
39.支付成功后，是否可以摇一摇得到红包
40.一天最多能摇几次红包
41.摇到红包后是否可以在下次付款时自动抵消现金，
42.红包的金额与抵消的金额是否一致
43.在红包使用的期限内是否可以使用红包
44.当超过红包的使用期限，红包是否还可以使用

性能
1.扫二维码响应的时间
2.取消支付的响应时间
3. 支付成功的响应时间
4.退款成功的响应时间
5.弱网支付的响应时间
6.不同网速对支付的响应时间(3g,4gWIFI)

安全
1.支付密码是否可见
2.支付时如果对方微信被盗是否有对应提示
3.如果支付钱数较多，是否有对应的提示
4.支付时对方异地登录是否有对应提示
5.支付扣的钱和零钱或者银行卡里少的钱数一样
6.在新的设备上支付时都需要认证，授权

界面
1.扫描二维码对应收款人的头像和信息是否正确
2.界面的排版是否符合合理，按钮大小，输入框大小
3.界面里是否我有错别字
4.界面颜色搭配是否合理

易用性
1.界面显示是否符合大多数人的使用习惯
2.付款二维码不用输入密码就可以完成对应的支付
3.指纹支付只要有在指纹处输入指纹就可以支付
4.支付用户可以选择自己喜欢的方式进行支付

兼容性
1.在安卓机和苹果机上都可以支付
2.对不同商家的微信收钱码均可以扫描

3.在不同的浏览器上是否可以付款

Linux查看日志文件内容命令

编辑start.sh文件，查看文件前10行内容和后10行内容

vi start.sh
head -n 10 start.sh 前10行

tail -n 10 start.sh 后10行

Linux1

1.查看指定端口是否被占用及占用程序
netstat -anp|grep 8080
2.查看指定的环境变量
echo $PATH
3.删除指定文件或文件夹
rm -rf 名称或路径
4.新建文件夹
mkdir 文件夹名
5.查看linux系统是32位还是64位
getconf LONG_BIT
6.移动文件并改名
mv 文件名 指定路径+文件名

测试用例设计经典面试题——电梯，杯子，笔，桌子，洗衣机

第一步应该反问：需求是什么？一般从功能测试，性能测试，安全测试，外观测试，可用测试，兼容测试这几个方面来解答

测试项目：电梯

需求测试：电梯使用说明书，安全说明书等。

功能测试

• 电梯的门能否正常打开，按钮能否正常运行
• 电梯能否正常上楼下楼
• 电梯内手机信号是否完好
• 电梯在10楼往下的时候已经满载，五楼有人按钮，电梯会不会停
• 有人在10楼按电梯向下，有人在二十楼按电梯向下，电梯会怎么停？

性能测试

• 电梯最大负重是多少
• 电梯最大负载情况下平稳运行时间多少？

安全测试

• 电梯内报警装置是否完好，通风口是否通畅

外观测试

• 电梯外观是否美观，按钮位置是否便于人按，电梯说明书是否有错别字。

可用测试

• 电梯按钮和电梯位置是否符合人使用习惯

用户文档

• 用户文档是否对电梯的使用限制描述详细无歧义

杯子

需求测试：
功能测试

• 杯子能否接水
• 杯子能否喝水
• 杯子能否放冰箱
• 杯子能接多少升的水？

性能测试

安全测试

• 杯子口是否平滑，有无缺口
• 杯子是否经过高温消毒？
• 杯子高温会否爆炸？
• 自由落体情况下杯子多高的高度会摔碎？

兼容测试

• 杯子能否承装其他液体，橙汁汽油等

可用测试

• 杯子是否符合人使用习惯？

界面测试

• 杯子外观设计是否美观

给你一个全新的软件，你就是负责人，你怎么去开展测试工作

需求分析

• 需求的合理性，是否可测试
• 项目人员的配置
• 测试环境的搭建
• 测试的流程和异常流程
• 测试的重点
• 项目发布时间

制定测试策略

• 测试计划，bug定义标准
• 测试计划明确包含测试范围
• 决定是功能测试，性能测试，自动化测试，可用性测试等

执行计划

• 编写测试用例（等价类划分法，边界值法，正交法，，因果图，判定表等）
• （编写测试用例需要注意的点，用例区分等级，特殊场景考虑：为空（接口空、数据空）、加载超时、网络异常、重复提交、异常中断、缓存冲突、系统兼容、流程迂回、流程中断；如果是PC，要注意浏览器（IE，chrome,火狐，苹果的），操作系统（xp,win7,win8,win10,linux,mac）的兼容,如果是手机，注意手机的品牌，操作系统，android版本，手机屏幕尺寸，手机网络等等场景），写完用例，如果有条件，就要评审测试用例

执行用例

• 补充场景
• 记录bug
• 开发提测需要先通过冒烟测试

功能合入，回归测试

• 各个功能点测试通过之后再合入。

提交验收

• 回归测试通过之后，提交给验收人员进行验收

发布上线

如果你发现了bug但是开发不认为是bug，怎么办

首先找证据支持我说这个是bug，（比如需求文档这么写的，竞品这么做的等等），如果找不到足够的证据支持你的观点，那就将问题升级到小组内讨论，一级一级的上升，直到PM或者项目经理拍板定义

你觉得bug需要修改，很紧急，但是开发没时间，怎么办

这个你需要先把这个问题说清楚，问题影响范围有多大，然后给PM或者项目经理还有拉上开发一起评审，说明这个问题遗留的风险，如果PM和项目经理接受这个风险，那就可以发布，否则必须修改了才能发布

即使他们接受了，发布之后，也要注意线上的表现，并知会出来

如果线上这个问题表现超过预期，那么就要要求发布hotfix

检查是否是一个好的测试用例

1.准确性(Accurate)
测试覆盖了描述部分需要测试的内容。

2.经济性(Economical)
测试用例没有冗余的步骤

3.可重复性(Repeatable)
测试用例应该是独立一致的，不管任何人执行，结果都一致。

4.可追踪(Traceable)
测试用例应该追溯到具体需求。

5.自我清理(Self cleaning)
测试结束后，恢复到原有干净的状态，不应该对原有系统造成影响。

6 结构化和可测试性（Structure and testability）
测试用例应该是结构化。一般可以根据一个横向维度，对测试用例进行功能模块的划分；同时纵向维度上可以根据测试类别对测试用例进行纵向结构的划分。
测试同时应该是可测试性的。对于无法执行的测试用例是没有意义的。

7.规范性
命名 + 编号

目的

测试方法

环境， 数据， 前提，权限。

步骤， 期望结果。

清理数据，还原系统。

这里其实包含一个测试用例的组成部分：

命名， 编号（一般会结合功能进行命名）
目的描述
测试类型（该测试用例属于功能测试，性能测试，单元测试，系统测试等等）
环境
测试数据
前提
步骤
期望结果
实际结果
测试结果（通过还是失败）
一般来说测试用例，不会说明备份系统，还原系统的步骤，这两个步骤一般都会由自动化脚本自动执行。

8.简洁性

不超过15步。

执行时间不要超过20分钟。这两点其实是希望测试用例的规模比较小，粒度不要太大。这点在大型系统不太适用。

这里给出了一个测试用例编写的指导规范。尽量简洁，精悍。

9.完整性
自动化脚本应该包含必要的注释，包括，目的，输入，预期结果。

如果可能，提供不同的前置条件下的测试。

测试用例应该尽量完整，包含自动化脚本。

10.有效性
测试用例是否符合商业案例？

11.独立性
测试用例应该保持独立性，一个测试用例最好是能独立运行，不依赖于其他的测试用例的输出结果。出于结构的考虑，有些特殊测试用例设计本身就是作为setup来设计的，这个除外。

性能测试中负载测试，压力测试有什么区别

测试计划都包括什么？

1、测试计划：制定项目测试过程中的测试重点
2、各个阶段的任务分配以及时间进度安排
3、并提出对各项任务的评估，风险分析，可以包括测试策略

web测试和手机测试区别

selenium 和 Appium 是怎么联系的?有什么关系?

搜索功能的测试用例

功能测试

搜索内容为空，验证系统如何处理
搜索内容为空格，查看系统如何处理
边界值验证：在允许的字符串范围内外，验证系统的处理
超长字符串输入，系统是否会截取允许的长度来检验结果
合法的字符串长度后，加空格验证检索结果
多关键字中间加入空格，逗号，tab验证系统的结果是否正确
验证每种合法的输入，结果是否正确
是否支持检索内容的复制、粘贴、编辑等操作
是否支持回车键搜索
多次输入相同的内容，查看系统的检索结果是否一致
特殊字符、转义字符、html脚本等需要做处理
敏感词汇，提示用户无权限等
输入的内容是否支持快捷键操作等
只能输入允许的字符串长度等
输入链接是否正确跳转，
搜索的历史纪录是否显示在下面
搜索内容有没有联想功能
界面测试

查看UI是否显示正确，布局是否合理
是否有错别字
搜索结果显示的布局是否美观
已查看的结果链接，链接的颜色要灰化处理，
结果数量庞大时，页面的分页布局是否合理
安全性测试

脚本的禁用
SQL的注入，检索SQL SELECT语句等
敏感内容的检索是禁止的
特殊字符的检索
被删除、加密、授权的数据，不允许被查出来，是否有安全设计控制
兼容性测试

多平台Windows，mac
移动平台android，ios
多浏览器火狐、chrome、IE等
性能测试

搜索页面的链接打开速度是否满足设计要求
搜索出结果消耗时间，是否满足设计要求

阶段评审与同行评审的区别？

同行评审目的：发现小规模工作产品的错误，只要是找错误；

阶段评审目的：评审模块 阶段作品的正确性 可行性 及完整性

同行评审人数：3-7人 人员必须经过同行评审会议的培训，由SQA指导

阶段评审人数：5人左右 评审人必须是专家 具有系统评审资格

同行评审内容：内容小 一般文档 < 40页， 代码 < 500行

阶段评审内容： 内容多，主要看重点

同行评审时间：一小部分工作产品完成

阶段评审时间： 通常是设置在关键路径的时间点上

验收测试包括

功能测试、易用性测试、兼容性测试、安装测试、文档测试等等

兼容性测试是指软件可以在不同的平台下运行，包括软件环境（比如LINUX的各个版本等）、硬件环境（比如android的各款手机等）。

安装测试，也叫部署测试，确保软件安装后可以正常使用，包括不同的安装方式、不同平台下的安装等。

文档测试只要是测试文档，文档也是软件交付的产品之一，包括用户手册、使用说明等等。

非正式验收包括Alpha 测试、Beta 测试。Alpha 测试一般是在开发者所提供的场所进行测试，由用户来执行。Beta 测试完全脱离开发者的环境，完全交给用户进行测试。

设计系统测试需要参考的项目文档

软件测试计划
软件需求规范
迭代计划

文档测试内容

1、文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。

2、描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。

3、易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。

4、文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。

5、印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。

文档测试对象

包装文字和图形；
市场宣传材料、广告以及其它插页；
授权、注册登记表；
最终用户许可协议；
安装和设置向导；
用户手册；
联机帮助；
样例、示范例子和模板；

文档测试的目的

提高易用性和可靠性，降低支持费用，因为用户通过文档就可以自己解决问题。
因此文档测试的检查内容主要如下：

读者对象——主要是文档的内容是否能让该级别的读者理解；
术语——主要是检查术语是否适合读者；
内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
图标和屏幕抓图——检查图表的准确度和精确度；
样例和示例——是否与软件功能一致；
拼写和语法；
文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；
文档测试是相当重要的一项测试工作，不但要给予充分的重视，更要要认真的完成，象做功能测试一样来对待文档测试。

软件缺陷等级

致命的：致命的错误，造成系统或应用程序崩溃、死机、系统悬挂，或造成数据丢失、主要功能完全丧失等。
严重的：严重错误，指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。
一般的：不太严重的错误，这样的软件缺陷虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预期效果。如次要功能丧失，提示信息不太准确，或用户界面差，操作时间长等。
微小的：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等。

测试过程中需要输出哪些文档？

测试计划，测试文档，测试用例，测试日志，bug报告，测试总结报告

软件质量评估指标

1、功能性的质量指标
　　功能的正确性：系统功能和用户的实际需求、已定义的产品规范一致。
　　功能的准确性：系统产生的结果在精度允许的误差范围内。
　　功能的完整性：所有功能及其定义清楚、可用。
　　2、可用性的质量指标
　　可操作性：容易使用和操作，包括理解用户界面、适应一些特殊用户的可选项等。
　　通用性：数据显示、网络通信接口和用户界面等都遵守已有的软件标准。
　　一致性：在软件开发整个生命周期内建立和使用相同的标准，保证全局变量、数据类型、出错处理的命名和使用一致。
　　3、可靠性的质量指标
　　自我恢复能力：当系统的某个功能失效发生时，系统在当前环境下能实现故障自动转移，重新自动配置、继续执行的能力，软件系统具有自我检测、容错、备份等机制，尽量做到独立于硬件的编码、硬件设备之间的通信协议一致等。
　　健壮性：各种恶劣环境（大数据量、大用户量）下系统能正常工作。
　　分布性：软件系统的某些子功能或子系统被定位于不同的处理主机、存储设备。
　　4、性能的质量指标
　　有效性：系统在通信、处理、存储等方面占有很少资源或者对所使用的资源进行了优化。
　　完整性：系统具有良好的安全管理，能防止不安全存取系统、防止数据丢失病毒入侵等。
　　易存取性：对系统的存取权限设置清楚，存取操作方便，存取操作有记录。
　　5、可维护性的质量指标
　　模块化：指讲一个复杂的软件系统分解为分别命名并具备最小耦合性、很强凝聚性、结构化的组件。
　　灵活性：容易为系统增加一个新功能或者新的数据而不需要进行大量的代码修改或者设计修改。
　　可测试性：测试软件组件或者集成产品时查找缺陷的简易程度。
　　可追溯性：对一个特殊需求容易找出相应的代码，反之，也可以根据代码找出特定的需求。
　　兼容性：软件、硬件、通信系统之间协调及兼容其他系统的能力。
　　可解释性：相关文档齐全、符合标准、逻辑清晰、描述准确、用词恰当，容易理解和定位。
　　6、可移植性质量指标
　　适应性：系统不依赖于环境，即系统不做修改或作很少的修改即可运行在其他环境下。
　　易安装性：与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。
　　可重用性：一个软件组件除了在最初开发的系统之外应用于其他系统的能力。
　　互操作性：软件系统与其他系统交换数据和服务的难易程度。
　　可替换性：与软件在该环境中用来替代指定的其他软件的机会和努力有关的软件属性。

测试用例的维护（测试用例是一个长期，不断改善的过程）

软件产品的版本是随着软件的升级而不断变化的，而每一次版本的变化都会对测试用例集产生影响，所以测试用例集也需要不断地变更和维护，使之与产品的变化保持一致。以下原因可能导致测试用例变更：

1）软件需求变更：软件需求变更可能导致软件功能的增加、删除、修改等变化，应遵循需求变更控制管理方法，同样变更的测试用例也需要执行变更管理流程。

2）测试需求的遗漏和误解：由于测试需求分析不到位，可能导致测试需求遗漏或者误解，相应的测试用力也要进行变更。特别是对于软件隐性需求，在测试需求分析阶段容易遗漏，而在测试执行过程中被发现，这时需要补充测试用例。

3）测试用例遗漏：在测试过程中，发现测试用例未覆盖全部需求，需要补充相应的测试用例。

4）软件发布后，用户反馈的缺陷：表明测试不全面，存在尚未发现的缺陷，需要补充或者修改测试用例。

对于提供软件服务的产品，其多个版本常常共存，而对应的测试用例也是共存的，而且测试用例需要专人定期维护，并遵循以下原则：

1）及时删除过时的测试用例

需求变更可能导致原有部分测试用例不再适合新的需求要求。例如，删除了某个功能，那么针对该功能的测试用例也不再需要。所以随着需求的每一次变更，都要删除那些不再使用的测试用例。

2）及时删除冗余的测试用例

在设计测试用例时，可能存在两个或者多个用例测试相同内容，降低回归测试效率，所以要定期整理测试用例集，及时删除冗余的测试用例。

3）增加新的测试用例

由于需求变更、用例遗漏或者版本发布后发现缺陷等原因，原有的测试用例集没有完全覆盖软件需求，需要增加新的测试用例。

4）改进测试用例

随着开发工作进行，测试用例不断增加，某些用例随着系统输入和当前状态的变化而变得不再适用，这些用例难以重用，影响回归测试的效率，需要进行改进，使之可重用可控制。

总之，测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程。