给你一个全新的软件，你就是负责人，你怎么去开展测试工做
参考回答：
第一步：需求分析：我会对这个全新的软件需求进行全面分析，主要的分析点有：1.软件的版本需求合理性，是否可测试；2.项目人员配置（遇到什么问题找谁，有多少人投入测试，测试环境，硬件，软件）；3.要测试的软件的主流程，异常流程，测试重点；4。项目总体规划（发布时间javascript
第二步：指定测试策略、测试计划和bug定义标准，这一步主要是针对需求，在已有的和可协调到的资源上作出具体的，可执行的计划，这个阶段的输出是测试计划。测试计划中明确包含测试范围，测试策略，好比功能测试，性能测试，自动化测试，可用性测试，云测，mokey等html
第三步：按计划执行，编写测试用例，（编写测试用例的方法：等价类，边界值，错误猜想法，因果图，正交分解法等等）（编写测试用例须要注意的点，用例区分等级，特殊场景考虑：为空（接口空、数据空）、加载超时、网络异常、重复提交、异常中断、缓存冲突、系统兼容、流程迂回、流程中断；若是是PC，要注意浏览器（IE，chrome,火狐，苹果的），操做系统（xp,win7,win8,win10,linux,mac）的兼容,若是是手机，注意手机的品牌，操做系统，android版本，手机屏幕尺寸，手机网络等等场景），写完用例，若是有条件，就要评审测试用例前端
第四步：执行用例，补充场景，记录bug，回归bug（注意开发提测的需求须要冒烟测试经过）java
第五步：功能合入，回归测试（各个功能点测试经过以后，再合入）linux
第六步：提交验收（回归测试经过以后，提交给验收人员进行验收）android
第七步：发布上线（全新的软件，先是小范围内测，观察线上数据（如：crash,用户反馈，运营数据等）若是有产品认为严重的问题，则须要修复后重发，符合预期才能扩大发布）ios
若是你发现了bug可是开发不认为是bug，怎么办
首先找证据支持我说这个是bug，（好比需求文档这么写的，竞品这么作的等等），若是找不到足够的证据支持你的观点，那就将问题升级到小组内讨论，一级一级的上升，直到PM或者项目经理拍板定义web
，你以为bug须要修改，很紧急，可是开发没时间，怎么办
这个你须要先把这个问题说清楚，问题影响范围有多大，而后给PM或者项目经理还有拉上开发一块儿评审，说明这个问题遗留的风险，若是PM和项目经理接受这个风险，那就能够发布，不然必须修改了才能发布面试
即便他们接受了，发布以后，也要注意线上的表现，并知会出来chrome
若是线上这个问题表现超过预期，那么就要要求发布hotfix
面试题：如何测试登陆模块
注册登陆在软件测试中是基础，但也会有漏测的状况出现，尤为是对于普通帐户密码登陆的状况，须要考虑帐户密码的长度限制、字符类型、匹配判断等等。
目前市场上经常使用的登陆方式也有不少，帐密登陆里又支持邮箱、帐号、手机号登陆。对于同时支持多种登陆方式，测试时除了考虑每种方式是否可以登陆成功之外，特别须要考虑不一样登陆方式的优先级、对于用户习惯登陆方式的设置和记忆、各类登陆方式之间的切换、不一样设备的不一样方式登陆等等。
今天我与你们一块儿对登陆方式及测试重点进行梳理，主要关注一些特殊点，以及容易出现漏测的状况。
下面说一下测试点
功能测试
输入正确的用户名和密码登陆成功
输入错误的用户名密码登陆失败
用户名正确，密码错误，是否提示输入密码错误？
用户名错误，密码正常，是否提示输入用户名错误？
用户名和密码都错误，是否有相应提示？
用户名密码为空时，是否有相应提示？
若是用户未注册，提示请先注册，而后进行登陆
已经注销的用户登陆失败，提示信息友好？
密码框是否加密显示？
用户名是否支持中文、特殊字符？
用户名是否有长度限制？
密码是否支持中文，特殊字符？
密码是否有长度限制？
密码是否区分大小写？
密码为一些简单经常使用字符串时，是否提示修改？如：123456
密码存储方式？是否加密？
登陆功能是否须要输入验证码？
验证码有效时间？
验证码输入错误，登陆失败，提示信息是否友好？
输入过时的验证可否登陆成功？
验证码是否容易识别？
验证码换一张功能是否可用？点击验证码图片是否能够更换验证码？
用户体系：好比系统分普通用户、高级用户，不一样用户登陆系统后可的权限不一样。
若是使用第三方帐号(QQ,微博帐号)登陆，那么第三方帐号与本系统的帐号体系对应关系如何保存？首次登陆须要极权等
界面测试
布局是否合理、美观，输入框是否对齐
风格和提示信息用语是否符合语境
登陆页面显示是否正常？文字和图片可否正常显示，相应的提示信息是否正确，按钮的设置和排列是否正常
页面默认焦点是否认位在用户名的输入框中
首次登陆时相应的输入框是否为空？或者若是有默认文案，当点击输入框时默认方案是否消失？
相应的按钮如登陆、重置等，是否可用;页面的前进、后退、刷新按钮是否可用？
快捷键Tab,Esc,Enter 等，可否控制使用
兼容性测试：不一样浏览器，不一样操做系统，不一样分辨率下界面是否正常
性能测试
单用户登陆系统的响应时间是否符合"3-5-8"原则
用户数在临界点时并发登陆是否还能符合"3-5-8"原则
压力：大量并发用户登陆，系统的响应时间是多少？系统会出现宕机、内存泄露、cpu饱和、没法登陆吗?
稳定性： 系统可否处理并发用户数在临界点之内连续登陆N个时的场景？
安全性测试
1.登陆成功后生成的Cookie，是不是httponly (不然容易被脚本盗取)
2.用户名和密码是否经过加密的方式，发送给Web服务器
3.用户名和密码的验证，应该是前端验证+服务器端验证， 而不能单单是在客户端用javascript验证
4.用户名和密码的输入框，无SQL 注入攻击风险
5.用户名和密码的的输入框，不能输入脚本 （防止XSS攻击）
6.错误登陆的次数限制（防止暴力破解）
7.验证码不能被轻易破解、欺骗
兼容性测试
1.主流的浏览器下可否显示正常
2.不一样的操做系统是否能正常工做
3.移动设备上是否正常工做
4.不一样的分辨率
易用性测试
1.根据场景，考试是否提供记住用户名密码、自动登陆的功能
2.输入帐号后，回车登陆
连续输入3次或以上错误密码，用记是否被锁必定时间（如：15分钟）？时间内不容许登陆，超出时间点是否能够继续登陆。
其余测试
用户session过时后，从新登陆是否还能从新返回这前session过时的页面？
用户名和密码输入框是事支持键盘快捷键？如：撤销、复制、粘贴等等
是否容许同名用户同时登陆进行操做？考虑web和app同时登陆
手机登陆时，是否先判断网络可用？
手机登陆时，是否先判断app存在新版本？
是否支持单点登陆？
是否有埋点接口
http和https的区别
HTTPS和HTTP的区别主要以下：
一、https协议须要到ca申请证书，通常免费证书较少，于是须要必定费用。
二、http是超文本传输协议，信息是明文传输，https则是具备安全性的ssl加密传输协议。
三、http和https使用的是彻底不一样的链接方式，用的端口也不同，前者是80，后者是443。
四、http的链接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
扩展资料：
HTTP：是互联网上应用最为普遍的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可使浏览器更加高效，使网络传输减小。
HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，所以加密的详细内容就须要SSL。
HTTPS协议的主要做用能够分为两种：一种是创建一个信息安全通道，来保证数据传输的安全；另外一种就是确认网站的真实性。
支付模块的测试
连接：https://blog.csdn.net/jiangbqing/article/details/61917979
正常流程：
正常使用支付宝、微信、银行卡（目前使用最多的第三方支付方式）支付（正常金额的支付），功能是否正常。
异常流程：
一、支付帐号和密码错误，系统如何处理；
二、余额不足，系统如何处理；
三、取消支付，系统如何处理；
四、重复支付，系统如何处理；
五、微信或支付宝帐号未登陆时支付，系统如何处理；
六、手机上没有支付宝APP时选择支付宝支付，系统如何处理；
七、支付期间忽然断网，系统如何处理；
八、取消支付后再次支付，系统如何处理；
九、金额上：最小值金额的支付，最大值金额的支付，错误金额的支付（如金额格式的错误、不容许使用的货币等等）；
如何设计一个好的测试case
连接：http://www.sohu.com/a/247756141_165433
“好的”测试用例必定是一个完备的集合，它可以覆盖全部等价类以及各类边界值，而跟可否发现缺陷无关。
一个“好的”测试用例，必须具有如下三个特征。
1.总体完备性：“好的”测试用例必定是一个完备的总体，是有效测试用例组成的集合，可以彻底覆盖测试需求。
2.等价类划分的准确性：指的是对于每一个等价类都能保证只要其中一个输入测试经过，其余输入也必定测试经过。
3.等价类集合的完备性：须要保证全部可能的边界值和边界条件都已经正确识别。
作到了以上三点，就能够确定测试是充分且完备的，即作到了完整的测试需求覆盖。
一，检查标准
1.准确性(Accurate)
测试覆盖了描述部分须要测试的内容。
2.经济性(Economical)
测试用例没有冗余的步骤
3.可重复性(Repeatable)
测试用例应该是独立一致的，无论任何人执行，结果都一致。
4.可追踪(Traceable)
测试用例应该追溯到具体需求。
5.自我清理(Self cleaning)
测试结束后，恢复到原有干净的状态，不该该对原有系统形成影响。
6 结构化和可测试性（Structure and testability）
测试用例应该是结构化。通常能够根据一个横向维度，对测试用例进行功能模块的划分；同时纵向维度上能够根据测试类别对测试用例进行纵向结构的划分。
测试同时应该是可测试性的。对于没法执行的测试用例是没有意义的。
7.规范性
命名 + 编号
目的
测试方法
环境， 数据， 前提，权限。
步骤， 指望结果。
清理数据，还原系统。
这里其实包含一个测试用例的组成部分：
命名， 编号（通常会结合功能进行命名）
目的描述
测试类型（该测试用例属于功能测试，性能测试，单元测试，系统测试等等）
环境
测试数据
前提
步骤
指望结果
实际结果
测试结果（经过仍是失败）
通常来讲测试用例，不会说明备份系统，还原系统的步骤，这两个步骤通常都会由自动化脚本自动执行。
8.简洁性
不超过15步。
执行时间不要超过20分钟。这两点实际上是但愿测试用例的规模比较小，粒度不要太大。这点在大型系统不太适用。
这里给出了一个测试用例编写的指导规范。尽可能简洁，精悍。
9.完整性
自动化脚本应该包含必要的注释，包括，目的，输入，预期结果。
若是可能，提供不一样的前置条件下的测试。
测试用例应该尽可能完整，包含自动化脚本。
10.有效性
测试用例是否符合商业案例？
11.独立性
测试用例应该保持独立性，一个测试用例最好是能独立运行，不依赖于其余的测试用例的输出结果。出于结构的考虑，有些特殊测试用例设计自己就是做为setup来设计的，这个除外。
二， 测试用例的配置管理
采用命名和编号规范归档。
用例版本是否与当前被测试软件版本一致（对应）。测试用例最好有版本控制
包含用例须要的相应测试对象，如特定数据库。
存档阅读。
存档时按角色控制访问方式
当网络备份时存档。
离线归档。
压力测试，负载测试和性能测试关系？
连接：http://www.51testing.com/html/06/n-3721106.html
性能测试是动力，负载测试载重，压力测试强度
压力测试stresstest：是在必定的负荷条件下，长时间连续运行系统给系统性能形成的影响。
负载测试Loadtest：在必定的工做负荷下，给系统形成的负荷及系统响应的时间。
软件测试风险分析
测试计划都包括什么？
概述 1.1 编写目的 1.2 项目背景 1.3 项目质量目标 1.4 预期读者 1.5 参考资料
测试环境 2.1 系统架构 2.2 软硬件环境要求 2.3 测试环境部署图
测试规划 3.1 测试范围 3.2 测试工具 3.3 人员、角色及职责
测试策略 4.1 系统框测试 4.2 业务流程测试 4.3 功能点测试 4.4 UI界面测试 4.5 性能测试 4.6 兼容性测试 4.7 安全测试
测试进度安排
工做汇报
web测试和手机测试有什么区别
WEB测试和App测试从流程上来讲，没有区别。都须要经历测试计划方案，用例设计，测试执行，缺陷管理，测试报告等相关活动。从技术上来讲，WEB测试和APP测试其测试类型也基本类似，都须要进行功能测试、性能测试、安全性测试、GUI测试等测试类型。
他们的主要区别在于具体测试的细节和方法有区别，好比：性能测试，在WEB测试只须要测试响应时间这个要素，在App测试中还须要考虑流量测试和耗电量测试。
兼容性测试：在WEB端是兼容浏览器，在App端兼容的是手机设备。并且相对应的兼容性测试工具也不相同，WEB由于是测试兼容浏览器，因此须要使用不一样的浏览器进行兼容性测试（常见的是兼容IE6，IE8，chrome，firefox）若是是手机端，那么就须要兼容不一样品牌，不一样分辨率，不一样android版本甚至不一样操做系统的兼容。（常见的兼容方式是兼容市场占用率前N位的手机便可），有时候也可使用到兼容性测试工具，但WEB兼容性工具多用IETester等工具，而App兼容性测试会使用Testin这样的商业工具也能够作测试。
安装测试：WEB测试基本上没有客户端层面的安装测试，可是App测试是存在客户端层面的安装测试，那么就具有相关的测试点。
还有，App测试基于手机设备，还有一些手机设备的专项测试。如交叉事件测试，操做类型测试，网络测试（弱网测试，网络切换）
交叉事件测试：就是在操做某个软件的时候，来电话、来短信，电量不足提示等外部事件。
操做类型测试：如横屏测试，手势测试
网络测试：包含弱网和网络切换测试。须要测试弱网所形成的用户体验，重点要考虑回退和刷新是否会形成二次提交。弱网络的模拟，听说能够用360wifi实现设置。
从系统架构的层面，WEB测试只要更新了服务器端，客户端就会同步会更新。并且客户端是能够保证每个用户的客户端彻底一致的。可是APP端是不可以保证彻底一致的，除非用户更新客户端。若是是APP下修改了服务器端，意味着客户端用户所使用的核心版本都须要进行回归测试一遍。
还有升级测试：升级测试的提醒机制，升级取消是否会影响原有功能的使用，升级后用户数据是否被清除了。
selenium 和 Appium 是怎么联系的?有什么关系?
一 、 selenium是专门作web端的自动化测试工具
Selenium与其余测试工具相比，最大好处是：
Selenium 测试直接在浏览器中运行，就像真实用户所作的同样。Selenium 测试能够在 Windows、Linux 和 Macintosh上的 Internet Explorer、Chrome和 Firefox 中运行。其余测试工具都不能覆盖如此多的平台。使用 Selenium 和在浏览器中运行测试还有不少其余好处。
下面是主要的两大好处：
经过编写模仿用户操做的 Selenium 测试脚本，能够从终端用户的角度来测试应用程序。经过在不一样浏览器中运行测试，更容易发现浏览器的不兼容性。Selenium 的核心，也称browser bot，是用 JavaScript 编写的。这使得测试脚本能够在受支持的浏览器中运行。browser bot 负责执行从测试脚本接收到的命令，测试脚本要么是用 HTML 的表布局编写的，要么是使用一种受支持的编程语言编写的。
二 、appium是手机app端的自动化，它继承了webdriver(也就是selenium 2)
不过appium仍然须要经过selenium最后作测试工具，可是appium起到了一个链接手机端很是好的桥梁工做！能够链接到电脑上很是方便的调用selenium工具来作测试。
Selenium 1.0版包括三个部分，分别是Selenium IDE（插件，用于录屏，并转化代码）、Selenium Grid（扩展工具集）和Selenium RC（Remote Controller），其中最主要部分为Selenium RC。
可是Selenium与WebDriver合并后，Selenium2.0就等价为WebDriver了，因此学习Selenium2.0的话，至关于主要学习WebDriver API了。
3.0版本直到2016年才发布，该版本完全移出了Selenium RC，对开发环境也有了限制（例如只支持jvav8以上版本，对不一样的浏览器也有最低版本要求）。相对而言，2.0版的通用性更高。
搜索功能的测试用例包括哪些？
功能测试
搜索内容为空，验证系统如何处理
搜索内容为空格，查看系统如何处理
边界值验证：在容许的字符串范围内外，验证系统的处理
超长字符串输入，系统是否会截取容许的长度来检验结果
合法的字符串长度后，加空格验证检索结果
多关键字中间加入空格，逗号，tab验证系统的结果是否正确
验证每种合法的输入，结果是否正确
是否支持检索内容的复制、粘贴、编辑等操做
是否支持回车键搜索
屡次输入相同的内容，查看系统的检索结果是否一致
特殊字符、转义字符、html脚本等须要作处理
敏感词汇，提示用户无权限等
输入的内容是否支持快捷键操做等
只能输入容许的字符串长度等
输入连接是否正确跳转，
搜索的历史纪录是否显示在下面
搜索内容有没有联想功能
界面测试
查看UI是否显示正确，布局是否合理
是否有错别字
搜索结果显示的布局是否美观
已查看的结果连接，连接的颜色要灰化处理，
结果数量庞大时，页面的分页布局是否合理
安全性测试
脚本的禁用
SQL的注入，检索SQL SELECT语句等
敏感内容的检索是禁止的
特殊字符的检索
被删除、加密、受权的数据，不容许被查出来，是否有安全设计控制
兼容性测试
多平台Windows，mac
移动平台android，ios
多浏览器火狐、chrome、IE等
性能测试
搜索页面的连接打开速度是否知足设计要求
搜索出结果消耗时间，是否知足设计要求
阶段评审与同行评审的区别？
同行评审目的：发现小规模工做产品的错误，只要是找错误；
阶段评审目的：评审模块 阶段做品的正确性 可行性 及完整性
同行评审人数：3-7人 人员必须通过同行评审会议的培训，由SQA指导
阶段评审人数：5人左右 评审人必须是专家 具备系统评审资格
同行评审内容：内容小 通常文档 < 40页， 代码 < 500行
阶段评审内容： 内容多，主要看重点
同行评审时间：一小部分工做产品完成
阶段评审时间： 一般是设置在关键路径的时间点上
验收测试包括？
功能测试、易用性测试、兼容性测试、安装测试、文档测试等等
兼容性测试是指软件能够在不一样的平台下运行，包括软件环境（好比LINUX的各个版本等）、硬件环境（好比android的各款手机等）。
安装测试，也叫部署测试，确保软件安装后能够正常使用，包括不一样的安装方式、不一样平台下的安装等。
文档测试只要是测试文档，文档也是软件交付的产品之一，包括用户手册、使用说明等等。
非正式验收包括Alpha 测试、Beta 测试。Alpha 测试通常是在开发者所提供的场所进行测试，由用户来执行。Beta 测试彻底脱离开发者的环境，彻底交给用户进行测试。
测试策略有哪些？
连接：https://blog.csdn.net/hongfuqiang/article/details/78786187
设计系统测试须要参考的项目文档
软件测试计划
软件需求规范
迭代计划
文档测试
Namaste,guys ~此博客Val主要分享关于文档测试的概念。
1、文档测试的内容：
一、文档的完整性：主要是测试文档内容的全面性与完整性，从整体上把握文档的质量。例如用户手册应该包括软件的全部功能模块。
二、描述与软件实际状况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，咱们还要注意用户手册与实际功能描述是否一致。由于文档每每跟不上软件版本的更新速度。
三、易理解性：主要是检查文档对关键、重要的操做有无图文说明，文字、图表是否易于理解。对于关键、重要的操做仅仅只有文字说明确定是不够的，应该附有图表使说明更为直观和明了。
四、文档中提供操做的实例：这项检查内容主要针对用户手册。对主要功能和关键操做提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来讲，实际上没有什么帮助。
五、印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，而且印刷精美。
2、软件文档测试对象与目的
一、文档测试对象主要以下：
包装文字和图形；
市场宣传材料、广告以及其它插页；
受权、注册登记表；
最终用户许可协议；
安装和设置向导；
用户手册；
联机帮助；
样例、示范例子和模板；
二、文档测试的目的：
提升易用性和可靠性，下降支持费用，由于用户经过文档就能够本身解决问题。
所以文档测试的检查内容主要以下：
读者对象——主要是文档的内容是否能让该级别的读者理解；
术语——主要是检查术语是否适合读者；
内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
图标和屏幕抓图——检查图表的准确度和精确度；
样例和示例——是否与软件功能一致；
拼写和语法；
文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；
文档测试是至关重要的一项测试工做，不但要给予充分的重视，更要要认真的完成，象作功能测试同样来对待文档测试。
3、作好文档测试须要注意：
仔细阅读，跟随每一个步骤，检查每一个图形，尝试每一个示例；
检查文档的编写是否知足文档编写的目的；
内容是否齐全、正确、完善；
软件的缺陷等级应如何划分？
致命的：致命的错误，形成系统或应用程序崩溃、死机、系统悬挂，或形成数据丢失、主要功能彻底丧失等。
严重的：严重错误，指功能或特性没有实现，主要功能部分丧失，次要功能彻底丧失，或致命的错误声明。
通常的：不太严重的错误，这样的软件缺陷虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预期效果。如次要功能丧失，提示信息不太准确，或用户界面差，操做时间长等。
微小的：一些小问题，对功能几乎没有影响，产品及属性仍可以使用，若有个别错别字、文字排列不整齐等。
测试过程当中输出的文档
测试计划，测试文档，测试用例，测试日志，bug报告，测试总结报告
软件质量评估指标
一、功能性的质量指标
功能的正确性：系统功能和用户的实际需求、已定义的产品规范一致。
功能的准确性：系统产生的结果在精度容许的偏差范围内。
功能的完整性：全部功能及其定义清楚、可用。
二、可用性的质量指标
可操做性：容易使用和操做，包括理解用户界面、适应一些特殊用户的可选项等。
通用性：数据显示、网络通讯接口和用户界面等都遵照已有的软件标准。
一致性：在软件开发整个生命周期内创建和使用相同的标准，保证全局变量、数据类型、出错处理的命名和使用一致。
三、可靠性的质量指标
自我恢复能力：当系统的某个功能失效发生时，系统在当前环境下能实现故障自动转移，从新自动配置、继续执行的能力，软件系统具备自我检测、容错、备份等机制，尽可能作到独立于硬件的编码、硬件设备之间的通讯协议一致等。
健壮性：各类恶劣环境（大数据量、大用户量）下系统能正常工做。
分布性：软件系统的某些子功能或子系统被定位于不一样的处理主机、存储设备。
四、性能的质量指标
有效性：系统在通讯、处理、存储等方面占有不多资源或者对所使用的资源进行了优化。
完整性：系统具备良好的安全管理，能防止不安全存取系统、防止数据丢失病毒入侵等。
易存取性：对系统的存取权限设置清楚，存取操做方便，存取操做有记录。
五、可维护性的质量指标
模块化：指讲一个复杂的软件系统分解为分别命名并具有最小耦合性、很强凝聚性、结构化的组件。
灵活性：容易为系统增长一个新功能或者新的数据而不须要进行大量的代码修改或者设计修改。
可测试性：测试软件组件或者集成产品时查找缺陷的简易程度。
可追溯性：对一个特殊需求容易找出相应的代码，反之，也能够根据代码找出特定的需求。
兼容性：软件、硬件、通讯系统之间协调及兼容其余系统的能力。
可解释性：相关文档齐全、符合标准、逻辑清晰、描述准确、用词恰当，容易理解和定位。
六、可移植性质量指标
适应性：系统不依赖于环境，即系统不作修改或做不多的修改便可运行在其余环境下。
易安装性：与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。
可重用性：一个软件组件除了在最初开发的系统以外应用于其余系统的能力。
互操做性：软件系统与其余系统交换数据和服务的难易程度。
可替换性：与软件在该环境中用来替代指定的其余软件的机会和努力有关的软件属性。
测试用例的维护、
软件产品的版本是随着软件的升级而不断变化的，而每一次版本的变化都会对测试用例集产生影响，因此测试用例集也须要不断地变动和维护，使之与产品的变化保持一致。如下缘由可能致使测试用例变动：
1）软件需求变动：软件需求变动可能致使软件功能的增长、删除、修改等变化，应遵循需求变动控制管理方法，一样变动的测试用例也须要执行变动管理流程。
2）测试需求的遗漏和误解：因为测试需求分析不到位，可能致使测试需求遗漏或者误解，相应的测试用力也要进行变动。特别是对于软件隐性需求，在测试需求分析阶段容易遗漏，而在测试执行过程当中被发现，这时须要补充测试用例。
3）测试用例遗漏：在测试过程当中，发现测试用例未覆盖所有需求，须要补充相应的测试用例。
4）软件发布后，用户反馈的缺陷：代表测试不全面，存在还没有发现的缺陷，须要补充或者修改测试用例。
对于提供软件服务的产品，其多个版本经常共存，而对应的测试用例也是共存的，并且测试用例须要专人按期维护，并遵循如下原则：
1）及时删除过期的测试用例
需求变动可能致使原有部分测试用例再也不适合新的需求要求。例如，删除了某个功能，那么针对该功能的测试用例也再也不须要。因此随着需求的每一次变动，都要删除那些再也不使用的测试用例。
2）及时删除冗余的测试用例
在设计测试用例时，可能存在两个或者多个用例测试相同内容，下降回归测试效率，因此要按期整理测试用例集，及时删除冗余的测试用例。
3）增长新的测试用例
因为需求变动、用例遗漏或者版本发布后发现缺陷等缘由，原有的测试用例集没有彻底覆盖软件需求，须要增长新的测试用例。
4）改进测试用例
随着开发工做进行，测试用例不断增长，某些用例随着系统输入和当前状态的变化而变得再也不适用，这些用例难以重用，影响回归测试的效率，须要进行改进，使之可重用可控制。
总之，测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程。--------------------- 版权声明：本文为CSDN博主「hallomrzhang」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处连接及本声明。原文连接：https://blog.csdn.net/hallomrzhang/article/details/84992995