软件测试

面试官您好，我叫蔡巧葵，一直从事车载软件测试，负责最多的是中控方面

人是需要不断锻炼的，在一个地方呆太久，人的思维会被环境所固化了，换个环境，或许对思维和空间上都有一个很好的发展

宁波版：上周刚办理完离职手续，想去宁波发展

深圳版：上周刚办理完离职手续

我属于那种比较稳定的员工，在上两家公司呆了平均时间都超过了3年

然后这两家公司都是属于车载行业的

我在职期间积累不少的车载工作经验，比如怎么了解和分析一个产品的需求，怎么去编写测试用例、怎么去规范使用各种不同的测试工具和怎么跟不同部门协调和沟通等待这些

大概就讲这么多

这两家都是做车载中控的，我主要是负责中控系统全功能测试，期间也参与了不少项目

积累了不少经验，在有些项目中自己也能够独挡一面，如怎么分析需求，评审需求，测试用例怎么写才能规范，怎么跟同事与客户打交道，相关测试工具的使用和技能的提升，都有所累积

我的感悟有以下几点：

1. 首先从沟通上讲：沟通是交互信息的前提，在工作中会和不同的同事协调工作，所以要保持良好的沟通
2. 其次，身为测试，是产品的第一个全面体验者，应当站在用户的角度去理解整个产品，才能更好地进行测试；
3. 接着，就是测试用例：用例要覆盖所有的需求，编写要规范，且可执行性强
4. 最后，就是总结：在工作和生活中不断地去总结和积累经，下次遇到类似问题就可以很好的找到解决方案

嗯，大概就这么多

1.近期，入职后，我想快速融入公司团队，熟悉业务

2.远期，还是要不断总结与积累，提升个人的技能

一开始是机缘巧合接触到这个岗位，后面发现其实找BUG 是一个很有趣的工作，特别是找到大bug时就特别有成就感

且我性格也比较适合做测试工作，比如，细心，有责任心，性格开朗等

软件测试是用来发现软件bug，提高产品质量，降低成本的一个工作

参考方面：技术方面，测试思维，工作职责，组织协调等

测试人员需要具备的特质还蛮多的，我认为的有以下几点：

1. 掌握软件测试的相关技术，才能提供测试的质量

1.  要掌握软件测试的相关技术

3. 由于与不通过部门打交道，必须具备良好的沟通协调能力

4. 做事一定要细心，不急不躁，且责任心要强

我觉得是思维

1. 思维要开阔些，测试用例才能覆盖得更广些

2. 特别是逆向思维，可以测试一些不容易被发现的BUG

3. 当然技术也很重要

在我看来，软件质量不是靠测试出来的，测试只是为了发现问题，从而使产品尽善尽美，开发才是软件质量的保证者，代码的质量决定了产品的质量

优点：

缺点：

有的，我就举两个常见的例子

在正常倒车下，出现黑屏

 某个平台播放某个视频时出现黑屏，把视频放到其他平台去结果是好的，后面发现只有这个平台不行，给开发分析

就举这两个例子吧

音乐播放界面，carplay来电，无法跳转到carplay

亿连，连接有线安卓时，一直没连接上，好像是华为手机

连接蓝牙后，通话，车机端没有声音输出：先从硬件上看，是否有mic，硬件是OK的，那就是软件的问题

我觉得要从以下几个方面分析

首先，自身再确认过，再找开发了解他说不是BUG的原因

其次，假设是需求变更，那就找产品经理确认此事，如果真的改，就关闭，如果没有话就继续激活

接着，假设开发说测试环境问题，那可以按他说明重新部署环境验证BUG，确实如他所说，那就关闭，如果不是，还是就继续激活BUG

最后，假设开发说用户不存在这种使用场景，但没人能保证客户的使用手法，那我们就不认可他说的，让部门老大去判定

此类问题，在任意一家公司都会存在，也不能彻底解决
我们只能尽可能地去杜绝它，我提个个人见解：
1. 首先，确定好研发与测试的时间
2. 其次，跟进开发进度，再根据进度来调整开发计划
3. 最后，哪些功能开发好了，就先测试边，不用等开发完再测

评估bug的影响范围

解决线上问题

回溯线上问题

检查其他的业务是否有同类型的问题
分析bug出现的原因
补充操作出bug的测试用例

我们基本都是独立负责项目，只是项目的主导是测试主管而已，当然，没有测试主管我也可以主导一个项目

老师给的开展工作：

产品与设计：沟通需求及 UI 界面方面的设计

开发：了解他们的实现方式，有针对性的设计用例，bug与技术上的沟通

硬件组：机器组装，修理零件或线材缺失

业务部：有些客户不知道某个功能的操作方式，需要帮他去解决

1. 需求不明确，导致改来改去

2. 项目提测质量差

3. 开发未按时间提测

4. 没有接口文档

5. 测试时间不够

6. 开发不及时改BUG，导致项目延期

客户维护组：时刻跟进BUG修改，1-2天

项目组：3-6个月，后装市场竞争很激烈，版本迭代更新很快，但凡出慢一点，就会被别人占领市场

没留意过具体多少条

没留意过具体每天多少条

一个模块的测试用例大概在100-200条用例，但是还要以具体的功能为准

每天测试多少条用例，是按测试计划安排，没有固定数量

BUG也是，项目前期bug会多点，一天三十四十都有，后期产品稳定，就相对较少了，开发会开玩笑说测不出问题就不能下班，哈哈哈

公司的发展前景，毕竟公司发展好了对于我们个人自然发展就好

还有就是比较乐意与像面试一样的人共事感觉会更开心一些

加班是因为需要，身为公司的一份子，既然公司需要我们的付出，那肯定义不容辞 

公司目前在开发的车机是安卓几点几了

请问这个岗位的规划是什么样的

测试跟开发有多少人

开发与测试的问题对接流程

测试内部工作安排流程是怎么样的

面试结果大概多久出来

平时会看一些软件测试方面的内容，比如CSDN、博客园上面等等上学习

学习交流的氛围，特别是技术方面的交流与学习

同事之间沟通交流很愉快

公司部门很多，我就讲技术相关的部门吧

我是恐婚主义，人嘛还是努力工作才有安全感

不论选择什么性质的公司，能实现人生价值即可

提醒：不要回答具体数字，要说区间，在实事求是的范围

1. 深圳：模糊具体工资，11-13，有项目奖金

2. 宁波：17-22K，加班费1比1

3. 社保与公积金都按深户缴纳

深圳：11-15K

宁波：17820K，且有加班费，按1比1

我已经离职了，随时都可以入职到岗

UI、功能、性能、可靠性、易用性、兼容性、安全性、安装卸载

等价类、边界值、错误推测法、场景法等设计方法来编写测试用例的

1. 等价类分为有效等价类和无效等价类，符合需求的就是有效等价类，不符合需求的就是无效等价类

2. 因为大量错误都是发生在输入和输出的边界上，而不是发生在输入输出范围的内部，所以就有了边界值分析法，边界值是选取正好等于、刚刚大于和刚刚小于边界的值，它一般是跟等价类一起用的

3. 举个例子：设置密码要求是6-12位的数字和字母的组合，那有效等价类就是长度在6-12之间，数字和字母的组合；无效等价类就是长度小于6（取5）的数字字母组合，长度大于12（取13）的数字字母组合，长度在6-12之间的纯数字，长度在6-12之间的纯字母，长度在6-12之间的除了数字和字母以外的字符，等等

4. 错误推测法是指凭借经验推测程序可能出现的错误，比如新建和修改的名称要唯一，不唯一的话没办法提交成功

5. 场景法是根据业务流程来写的，有基本流和备选流，然后考虑异常流情况下是否出现bug。比如一个商品加入购物车、提交订单后超时不支付，会出现什么情况

1.首先要熟悉需求，，先理清楚“项目是怎么使用的”、“是给谁用的”、“干什么用的”，再根据业务流程来写，提取功能点，最后根据等价类、边界值、错误推测法、场景法进行测试用例的编写
2. 功能点的话，每个系统的模块中都有一些共有的功能，比如：倒车，所以在测试中我们要先把这些功能过一遍
3. 先走正常流，正常流通过之后，再对异常情况进行测
另外，熟悉业务流程是非常重要的，模块与模块、功能和功能之间是相互联系的，不能只是单独测它的功能正不正常，还要把他们的关系全部走通。比如我测的电商系统中，要先添加商户、品牌和分类，然后才能添加商品

用例编号、模块名称、功能点、用例标题、前置条件、测试步骤、期望结果、优先级、实际结果、备注

1.测试用例的需求覆盖率是100%；
2.测试用例的可执行；
3.测试用例的可读性；
4.测试用例的评审；
5.及时维护测试用例，也许一个功能的变更，或者场景的添加，就需要考虑更多的情况，保证测试用例的完整性

我们是根据需求文档提取测试点，根据等价类、边界值、错误推测法、场景法来编写测试用例，用excel表格来写测试用例的，发现bug后用公司开发的BUG管理系统提交bug，指派给对应的开发

1.问：没有需求文档，那肯定有需求提出者，那与他进行沟通。
2.问：但凡懂需求的人，我们都可以问。如问开发，项目经理，测试经理等。
3.分析：结合一些业务资料和百度等进行分析
4.对比：对比竞争对手产品，分析得到合适的需求
5.经验：可以借助原来的经验
6.合理：一切的需求都要符合常理

V模型

W模型

用例全部执行完毕，bug回归完毕，没有遗留严重的bug，产品经理验收通过后就可以上线了

1. 单元测试又称为模块测试，是对代码中的函数和方法进行测试；
2. 集成测试，也可以称作接口测试，开发把功能模块进行整合，测试功能和功能之间是否能够对接成功
3. 系统测试是对整个系统进行测试，也是黑盒测试
4. 验收测试分为a验收和贝塔验收，a验收是在开发者环境下进行测试，贝塔验收是在真实环境下由真实用户体验，有问题再反馈给开发人员

进度风险、质量风险、人员风险、变更风险、成本风险

写过，不过写的都是我们自己负责模块，整个系统的测试报告由测试主管完成
一般的话会对项目背景做一个阐述。
测试内容：测试内容的大纲。
测试环境：测试环境的描述，包括客户端和网络环境。
测试工具：测试过程中的测试资源使用。
测试的数据：bug数，解决数，遗留数。
模块bug分布，bug走势图，缺陷遗留，需要说明的问题。
测试数据分析：对于整个过程测试的一个分析，得出结论。
遗留问题：对于软件遗留问题有详细说明。
主要就是内容简洁、不罗列详细数据、挑拣一些能说明问题分析数据的：比如缺陷走势图，模块的bug分布等，突出重点遗留问题，然后得出分析测试结论

回归测试常用的策略有：全面回归测试、选择性回归测试等
像我们一般会进行三轮的测试，第一轮把功能都过一遍，提bug；第二轮做一个全面的回归测试；看具体的情况，第三轮会进行选择性的回归测试，把出现bug的相关模块都测一遍。
·全面回归测试：所有的测试用例都重新测一遍
·选择性回归测试：对于出现问题的bug进行验证，没有问题的bug就不进行测试
·自动化工具回归测试：使用自动化测试工具进行回归测试

等开发把代码更新完后，上传服务器进行覆盖

1.首先从自身找问题，再根据需求文档分析这是不是一个bug，如果确定是bug
2.再看看测试用例的操作步骤写的够不够详细、可执行性强不强；
3.如果不是以上原因，那就跟开发沟通，可以在开发的电脑上实现给他看，然后跟他好好解释，如果这真是一个bug，开发是不会不认的；
4.如果还是不认，那就要上报给上级，然后开会进行讨论

1.确定与需求不符

2. 严重影响到客户的使用

3.bug的复现步骤要详细，可读性可执行性强，能够再次复现出来