软件测试就是在软件的开发过程中，根据需求规格说明设计测试用例，手工或者利用测试工具有计划的执行程序，以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，并追踪和验证这些bug，保证bug被修复的过程。
测试是软件开发中不可或缺的一环，测试通过经济，高效的方法，捕捉软件中的错误，从而达到保重软件内在质量的目的。
自动化测试有时候还需要根据不同的测试需要编写不同的测试工具，设计和维护测试系统。
测试是为了证明程序有错，而不是为了证明程序无错。
测试不仅需要正向思维，还需要反向思维。
1）通过修正错误和缺陷可以提高软件质量，避免软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。
2）利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的开发和测试中重复同样的的错误。
3）采用更加高效的测试管理手段提高软测的效率和软件产品的质量。
1)所有的软件测试应该溯源到用户的需求
2)尽早的将软件测试贯穿到软件开发的全过程中
3)完全测试是不可能，测试需要中止
4)测试无法保证软件中完全没有缺陷
5)充分注意测试中错误集群现象
6)应避免自己检测自己的程序
7)应避免测试的随意性
1）功能测试
功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。测试时按照科学方法设计的测试用例执行测试，在优先保证测试用例执行完全的前提下，再根据对业务的了解和经验性的判断进行探索性测试。
2）性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
3）界面测试
界面测试简称UI测试，界面为用户与软件交互最直接的层，所以更注重用户的体验性，主要从用户的感官、交互、浏览、情感和体验出发。具体测试用户界面的功能模块布局是否合理，整体风格是否统一，各个控件的放置位置是否符合客户使用习惯，是否符合操作便捷，导航是否简单易懂，界面中文字是否正确，命名是否统一，页面美观，文字、图片组合是否完美等等。测试时可以按照最终用户具体的需求，以及通用的用户体验原则进行测试list的编写，然后测试人员根据list执行。
4）兼容测试
兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等环境中是否能够很友好的运行的测试。通常兼容性测试为软件在不同浏览器、操作系统和分辨率下的兼容测试。测试时测试人员按照软件的具体兼容性需求进行测试。
5）易用性测试
考察评定软件的易学易用性，各个功能是否易于完成，软件界面是否友好等方面进行测试。测试时可以根据用户需求，以及同类行业软件对易用性的通用原则列出测试list，然后测试人员根据list执行。
1）逻辑性还可以，可以理性分析问题、思考比较全面，有耐心。
软件测试在前期需要分析需求文档和各种项目需求书，制定测试计划，设计测试用例，后期执行测试用例的时候需要判断逻辑的正确性、对可行性逻辑分析、
2）有团队协作能力、善于沟通
做软件测试需要和技术人员、产品人员、上下级沟通，和组员配合完成测试任务，配合开发人员重现缺陷。
3）有责任
要敢承担责任，敢坚持自己的意见
缺陷洞察能力，一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；
4）专业技术能力，
掌握测试基础知识、计算机网络、数据库等基础知识，熟练运用测试工具
5）学习能力，适应性强，抗压
软件测试是正在快速发展，充满挑战的领域。尽管现在许多自动化测试软件的出现使得传统手工测试的方式被代替，但自动化测试工具的开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项测试中仍然需要大量具有专业技能与专业素养的测试人员，并且随着云计算、物联网、大数据的发展，传统的测试技术可能不再适用，测试人员也因此面临着挑战，需要深入了解新场景并针对不同场景尝试新的测试方法，同时敏捷测试、Devops的出现也显示了软件测试的潜力。
测试人员的核心竞争力在于提早发现问题，并能够发现别人无法发现的问题。
1、早发现问题：问题发现的越早，解决的成本越低。如果一个需求在还未实现的时候就能发现需求的漏洞，那么这种问题的价值是最高的。
2、发现别人无法发现的问题：所有人都能发现的问题，你发现了，那就证明你是可以被替代的。别人发现不了，而你可以发现，那么你就是无法被替代。
手工测试缺点：
手工测试优点：
自动化测试优点：
1、可以对程序的新版本自动执行回归测试，看以前发生在旧版本中的错误和缺陷是否在新版本中出现。用自动化的方式做回归测试，可以极大提高测试效率，缩短回归测试时间。
2、更好地利用资源，节省时间和人力。利用自动化测试去做一些繁琐且重复的测试，测试人员就可以去设计更好的测试用例，或者去做那些不适合自动测试的测试，可以提高测试的效率。
3、自动化测试可以执行一些手工测试困难或不可能进行的测试，比如压力测试、并发测试。
4、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，也就不存在执行过程中由于人为因素出现错误，因此一旦测试通过，就会提高用户对于软件的信任度。
5、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
自动化测试缺点：
1、不能取代手工测试， 手工测试比自动测试发现的缺陷更多
2、对测试质量的依赖性极大
3、测试自动化不能提高有效性
4、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
5、 工具本身并无想像力
自动化测试流程：
一、功能测试
计算机基础，软件生命周期、开发模型、测试模型。软件测试概念，软件测试方法及分类、热门领域测试技巧。Linux系统，数据库的定义及基本概念，MySQL、Oracle。搭建功能测试实战环境，Linux环境下B/S结构产品测试项目等内容。
二、自动化测试
Python，自动化测试分类及自动化适用的项目。Selenium，使用Selenium对网站的核心功能进行自动化测试。Appium，Monkey，使用Appium对APP核心功能进行测试验证，对APP功能进行评估等内容。
三、接口测试
接口测试，Postman安装使用，Fiddler安装使用，Web和手机抓包，基本设置方法。Jmeter，搭建接口测试环境，分析业务流程，设计测试用例，使用Jmeter执行测试用例。Web安全核心理论、Web漏洞及防御、渗透测试、SQL注入、XSS跨站脚本、AppScan等内容。
四、性能测试
性能测试，VuGen，Controller，Analysis，性能测试调优，数据库调优，性能测试指标，Jmeter在性能测试中的应用。搭建测试环境，编写测试计划和测试用例，设置和运行场景，监控和收集数据，写分析报告，项目综合评审等内容
需要的知识：
软件测试基础理论知识，如黑盒测试、白盒测试等；
考编程语言基础，如C/C++、java、python等；
自动化测试工具，如Selenium、Appium、Robotium等；
计算机基础知识，如数据库、Linux、计算机网络等；
测试框架，如JUnit等。
搭建测试环境
撰写测试用例
执行测试用例
写测试计划，测试报告
测试，并提交BUG表单
跟踪bug修改情况
执行自动化测试，编写脚本，执行，分析，报告
进行性能测试，压力测试等其他测试，执行，分析，调优，报告
需求的覆盖程度 = 被测试用例覆盖的需求数/需求总点数
软件测试计划中应该包括什么内容？
测试计划的内容会因不同的项目以及项目的大小而有所不同，一般而言在测试计划中应该清晰描述以下内容：
1、 测试目标：
2、 测试概要：
3、 测试范围：
4、 重点事项：
5、 质量目标：
6、 资源需求：
7、 人员组织：
8、 测试策略：
9、 发布提交：
10、 测试进度和任务人员安排：
11、 测试开始/完成/延迟/继续的标准：
12、 风险分析：
【测试新人必备】测试报告如何编写？
1.1 项目背景
本测试报告的具体编写目的，指出预期的读者范围。(3-4句)
本测试报告为（系统名称）系统测试报告；本报告目的在于总结测试阶段的测试及测试结果分析，描述系统是否达到需求的目的。
本报告预期参考人员包括测试人员、测试部门经理、项目管理人员、SQA人员和其他质量控制人员。
1.2 参考资料
2.1 测试范围
2.2 测试案例设计思路
1）功能测试：
2）用户界面 (UI) 测试：
3）流程测试：
4）安全性测试：
5）兼容性测试：
3.1 测试执行情况与记录
3.2 缺陷的统计与分析
4.1 风险分析及建议
4.2 测试结论
5.交付文档
软件生命周期：
常见开发模型：
最早提出的软件开发的过程模型。
特点：
瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以制定精确的计划和进度。
测试对象非常明确，即程序。
在瀑布模型中，测试被认为是在软件开发过程的后期阶段进行的“一次性”活动，这带来一个巨大的缺点，因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。
强调时间顺序的严格执行，前阶段不完成，后阶段不开始
不适应用户需求的变化
线性开发，用户等到整个过程的末期才能见到开发成果，从而增加了开发风险
引入了风险分析
特点：
螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）。加上该模式发现问题早、成本低的特点，可以算做相当好的开发模式。
软件测试员喜欢该模式。因为通过参与最初设计的设计阶段，可以尽早地影响到产品，可以把产品的来龙去脉弄得很清楚；并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员的测试一直都在进行，所以最后一步只是一个验证表面所有部分都没有问题。
敏捷宣言：敏捷软件开发宣言
这不是一份抽象的方法论集合，并没有提供任何死板僵化的开发方法和复杂的 技术结构层次，而更像是一份针对客户和开发个体的箴言警句集。
特点：
敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。
敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好“迎接变化”的准备，客户是敏捷的关键环节。
敏捷开发没有单一固定的开发方法或过程，很多快速的开发模式都可以看作是敏捷。但这些模式都有三个共同点：依赖客户的参与、测试驱动以及紧凑的迭 代开发周期。
测试驱动开发是其核心实践。
测试驱动开发
迭代模型：
增量模型：
把软件分割成独立的模块，分批次的完成与交付。
打破了原有的软件结构和框架，可能带来一定的风险
一般与迭代模型一起用
快速原型模型：
就是一个模型，可以模拟操作，简单运行
Axure，制作原型
优点：
缺点：
优点：
缺点：
特点：
测试和开发需要怎么结合才能使软件的质量得到更好的保障
参考回答：
测试和开发应该按照W模型的方式进行结合，测试和开发同步进行，能够尽早发现软件缺陷，降低软件开发的成本。
在V模型中，测试过程被加在开发过程的后半部分，单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。
V模型的缺陷在于仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，因此需求阶段的缺陷很可能一直到后期的验收测试才被发现，此时进行弥补将耗费大量人力物力资源。
相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
W模型中测试的活动与软件开发同步进行，测试的对象不仅仅是程序，还包括需求和设计，因此能够尽早发现软件缺陷，降低软件开发的成本。
完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
意义以及是否可行：
单元测试可以有效地测试某个程序模块的行为，是未来重构代码的信心保证。事前可以保证质量，事后可以快速复现问题，并在修改代码后做回归自测。
可行性考虑的是要用一些可行的方法做到关键的代码可测试，如通过边界条件、等价类划分、错误、因果，设计测试用例要覆盖常用的输入组合、边界条件和异常。
如何进行单元测试：
１、创建单元测试，创建单元测试大致可以分为两类：
整体测试，整体测试是在类名称上右击鼠标，在下拉菜单中点击创建单元测试选项。这样就可以为整个类创建单元测试了，这时他会为整个类可以被测试的内容全部添加测试方法。开发人员直接在这些自动生成的测试方法中添加单元测试代码就可以了。
单独测试，如果只想单独对某个方法、属性、字段进行测试，则可以将鼠标焦点放在这个待测试的项目名称之上，然后点击鼠标右键，在右键菜单中选择创建单元测试选项。这样就可以单独为某个方法创建单元测试了。
2、运行单元测试
3、查看测试结果
集成测试指的是通过测试发现与模块接口有关的问题。
目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。
自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。
也称为冒烟测试，一般不作为正式的测试环节，通过了确认测试的软件才具备了进入系统测试的资格。
确认（validation）：通过检查和提供客观证据来证实特定目的的功能或者应用是否已经实现。
验证（verification）：通过检查和提供客观证据来证实指定的需求是否满足
先确认是否有，在验证是否满足需求。
系统测试是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。
系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。
系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。
因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。
系统测试能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此系统测试是很重要的测试。
回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。
理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。
回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。
验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。
验收测试包括Alpha测试和Beta测试。
Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。开发者对用户的指导下进行测试，开发者负责记录发现的错误和使用中遇到的问题
Beta测试：在开发者不能控制的环境中的真实应用，由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，由用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。
验收测试合格通过的准则是：
区别：
从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。
系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。
先执行集成测试，待集成测试出的问题修复之后，再做系统测试。
应用场景：
集成测试：
完成单元测试后，各模块联调测试；
集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；
可以是整个产品的集成测试，也可以是大模块的集成测试；
集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。
集成测试对测试人员的编写脚本能力要求比较高。
测试方法一般选用黑盒测试和白盒测试相结合。
系统测试：
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 