初级测试小宝典测试流程，不能复现bug，开发不认为是bug级2020测试点的热点提问的回答

编程入门行业动态更新时间:2024-10-27 14:26:35

1.测试流程

1.按阶段划分为
单元测试,集成测试 ,系统测试,验收测试

2.按是否运行
   静态测试动态测试
3.按是否查看源代码
   自盒测试
   黑盒测试
       功能测试
       逻辑功能测试 ,界面测试,易用性测试,安装测试,兼容性测试
       性能测试
   一般性能测试 ,稳定性测试,负载测试,压力测试
4.其他
   回归测试,冒烟测试,随机测试

从产品立项开始，我们(项目经理产品经理开发人员测试等)内部会开立项会，在立项会中进行对需求进行评审，制定需求文档，前端进行设计页面,开发人员根据需求文档进行编码,测试需要制定测试计划，已经对需求进行颗粒划分，不同的测试人员根据自己的任务编写测试用例，然后对用例进行评审，开发提交代码后执行冒烟测试，如果冒烟测试结束后执行用例如果发现bug则提交bug，让开发人员进行修改，修改后进行二次验收，bug修改正确后关闭该bug，如果没有重新打开并进行跟踪bug，项目结束后需要进行编写测试报告。
2.测试过程中遇到了不能复现的bug的时候你怎么办

将bug的操作步骤进行记录，然后进行在不同的测试环境中多次的调试，如果还是不能复现bug将根据bug的登记进行上报测试组长，根据需求文档对bug进行评级，看是否需要修改，如果不能修改的则记录在测试报告中防止后期出现同一bug进行解释说明。
3.测试过程中遇到开发不认为是bug的bug你怎么办

首先，在遇到非必然重现的 bug ，一定要提 bug ，并且要在 bug 单中说明复现的概率。在发现 bug 时，要分析产生的原因，尽量多尝试可能出现的步骤。排除环境和自己电脑配置的原因，比如浏览器的版本，系统的版本等。还可以寻找开发帮助，让开发同学对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题。如果还未复现，在接下来的测试中，时刻保持关注，每次执行同样或者相近的步骤的时候，看下是否能够复现之前的 bug 。那些一直未能复现的 bug ，需要测试经理定期将这些 bug 汇总，选择优先级高的缺陷，组织开发人员和测试人员专门投入到复现问题。如果经过这样的专门复现依然不能复现，可以降低问题的优先级。如果在项目前期，跟踪至少3个版本，如果仍然无复现，可以暂时关闭该 bug ，备注说明并不是因为修复关闭，而是经过x个版本后不复现了。如果项目周期比较紧张，不能跟踪多个版本，那么 bug 就不能关闭，上线后及时关注用户的使用反馈，如果持续3或者4个版本没有出现，那么可以将 bug 暂时关掉了，同时关掉的时候要进行备注说明。
4.经典用例设计（纸杯、购物车、电梯、登录框、多部电梯具有联动性、
视频播放器测试点，三角形的测试设计点、朋友圈点赞的测试用例的设计点、
视频播放器测试点、微信发红包）

1.微信发红包的测试点

功能测试
1）发给单个好友
① 正确的金额+无留言+无表情
② 错误的金额+无留言+无表情
③ 正确的金额+有留言+无表情
④ 错误的金额+有留言+无表情
⑤ 正确的金额+无留言+有表情
⑥ 错误的金额+无留言+有表情
⑦ 正确的金额+有留言+有表情
⑧ 错误的金额+有留言+有表情
其中，金额（0.01-200）可以测试以下数据
1）数字：测试0, 0.009, 0.01，0.011, 01， 199.99, 200, 200.01这些边界值
2）中文、英文、特殊字符或者这几种的组合
3）是否支持复制黏贴
4）为空/包含空格
5）金额的增删查改
留言可以测试以下数据
1）数字、中文、英文、特殊字符、表情或者他们的组合
2）输入超长文本时，是否会给出相应的限制或提示
3）包含空格
4）是否支持复制黏贴
5）留言的增删查改
表情可以测试以下数据
1）选择收藏的表情测试（动图/静图）
2）选择下载的表情测试（动图/静图）
3）录制表情，并添加进行测试
4）表情的增删查改
⑨ 点击塞钱进红包，选择零钱付款，此时需要考虑金额＞零钱，金额＜零钱，金额=零钱三种情况
⑩ 点击塞钱进红包，选择已添加的银行卡付款，此时同样需要考虑金额＞银行卡余额，金额＜银行卡余额，金额=银行卡余额三种情况
⑪ 点击塞钱进红包，选择使用新卡付款，按照流程添加新卡，此时同样需要考虑金额＞新卡余额，金额＜新卡余额，金额=新卡余额三种情况
⑫ 使用指纹确认付款（正确的/不正确的指纹）
⑬ 使用密码确认付款（正确的/不正确的密码）
⑭ 发送成功之后，对应的途径会减少相应的金额
⑮ 发送者/接受者可以点击红包查看到红包的具体信息，且金额，留言，表情均能正确显示
⑯ 好友点击红包之后，零钱中将增加相应的金额，再次点击之后，只能查看到红包的信息
⑰ 24小时之内没有领取的红包，将退回原账户，此时原账户的零钱将增加相应金额的金钱。24小时后好友点击红包，显示红包已过期，无法查看到红包的余额
⑱ 右上角的红包记录中，可以查看刚刚发出的红包的金额
⑲ 检测帮助中心中链接是否均可以正常跳转，查看
20 当红包超过24小时之后，则无法查看红包被每个人领取的详细信息
2）发送群红包（与发给好友的测试点相似，以下仅写出不同的部分）
① 选择为拼手气红包时，群中每个人收到的金额随机（但加起来为红包的总金额），为普通红包时，群中每个人收到的金额相同
② 红包个数（1-100）：0，1，2，大于群成员人数，小于群成员人数，等于群成员人数，99，100，101，小数，中文、英文、特殊字符、表情或者他们的组合
③ 但红包没有被抢完时，此时首次点击该红包的人可以抢到一定金额的红包，不是首次点击该红包的人只能查看该红包的信息；当红包抢完时，所有人只能查看该红包的信息。
④ 在24小时之内红包的金额被完全抢完，且此时为拼手气红包时，金额最多的人会显示为最佳手气（若有两个人取得红包的最大值时，则只有一个人会显示为最佳手气）；若没有被完全抢完，则没有最佳手气，且余额会退还到原账户
⑤ 群中所有人均可以抢红包（包括自己），每个人最多只有一次抢该红包的机会
⑥ 测试当红包个数使得每个红包分到钱小于0.01，即总金额为0.02，而红包个数为3时的情况

兼容性测试
1）苹果手机和安卓手机
2）苹果手机的不同版本
3）安卓手机不同的机型
4）不同分辨率

性能测试
1）打开红包的响应时间不能超过三秒，高并发场景下不能超过5秒
2）耗电量
3）消耗流量的多少
4）所占内存等

UI测试&易用性测试
1）界面的设计风格是否统一
2）界面中文字是否简洁，没有错别字
3）是否易操作，易学习，易理解

中断测试
前后台切换，网络异常，低电量，断电，来电，短信等

网络测试
1）网络兼容性：2g/3g/4g，WiFi，热点，移动/联通/电信
2）无网测试
3）弱网：延时&丢包

2.朋友圈点赞的测试点
3.视频播放器（抖音、快手）的测试点

UI测试：
导航栏元素位置、大小、颜色等要素是否一致/是否符合UI效果图；
导航栏视频分类下拉框位置、颜色、按钮是否正确
鼠标滑过、点击时、点击后按钮状态是否有相应颜色、状态变化；
视频列表页面title、视频图片、视频title、是否付费等元素的颜色、大小、位置等是否正确；
视频播放页面：视频title、视频默认加载图、播放按钮、目录、视频列表、视频介绍等元素位置、大小、颜色、鼠标操作时状态是否与预期一致；
视频播放时进度条、快进按钮、快退按钮、播放按钮、暂停按钮位置是否正确
功能测试：

首先判断用户是否登录，未登录不能进入主页（应提示用户先进行登录），已登录状态用户可以进行视频观看；
导航栏下拉框是否可以正确打开和关闭，打开和关闭时的状态是否和预期一致；
鼠标滑过、点击时、点击后相应条目的状态是否和预期一致；
点击相应条目时，页面右边是否同步切换至相应页面，是否有延时、卡退、切换错误等情况；
视频播放页面鼠标滑过、点击时、点击后视频对应条目、标题是否有相应状态变化（具体变化状态根据产品原型进行分析），点击后是否能够正确跳转至相应的视频播放界面；
判断用户点击的视频属于免费还是付费，如果为免费则所有人均可以进行观看，如果为付费则要判断用户是否付费，如果已经付费则可以进行观看，如未支付则提示用户先购买后再进行观看并提供支付入口或者联系客服进行支付的方式；
进入视频播放界面判断当前视频title是否和用户上一步点击的视频title一致；
视频默认加载图是否显示正确或者显示异常等情况；
视频播放按钮是否可以点击，点击后视频是否正常播放；
视频目录是否显示正确，如有子列表是否正常显示，如果没有子列表是否有相应提示（具体效果根据产品原型进行分析）；
视频介绍是否与当前视频一致，讲师是否一致等情况；
点击播放后进度条是否随之变化；
视频快进、快退、暂停、播放是否可以正常使用，是否有卡顿、延时、闪退等情况；
播放完成后是否自动切换下一视频（如有多节视频情况下，如果只有一条子视频的情况下，播放完成后是否关闭当前页面或者给予用户相应提示），如果需要手动切换是否有相应的友好提示；
视频播放时声音、画面是否一致或者是否有异常等情况；
视频最大化、全屏、最小化是否可以正常使用，切换时是否有卡顿、延时等情况；
当前视频与其他视频来回切换时，视频是否有卡顿、延时等情况；
电脑关机或者其他异常情况下，视频是否会保存播放记录，下次进入观看时是否继续上次的播放记录继续播放；
兼容性测试：

平台兼容性：Windows、Mac
系统兼容西：Win7、Win10、Mac
屏幕分辨率：不同电脑显示器分辨率不同，视频相关页面是否有模糊、适配是否合理；
播放器是否与其他类型播放器冲突（例如音乐播放器打开后，视频是否暂停还是继续播放）；
网络测试：

网络切换测试：无线网与宽带；
弱网测试：弱网情况下视频是否卡顿、画面是否失帧；
无网络状态进入是否会有相应提示；
网络切换时视频是否暂停、保存当前播放状态；
易用性测试：

界面是否一目了然（比如：视频title、片头、片尾、视频画面等）；
视频页面操作是否方便，菜单栏是否正确、易上手；
进度条拖拽使用起来是否方便；
视频是否具有视频记忆功能/是否保存当前播放进度

4.多部电梯的联动的测试点

界面测试：查看电梯外观，按键数字清晰、开和关按钮设计的图标是否容易区分

功能测试：

1、电梯门的打开、关闭是否正常

2、按钮是否可以正常使用

3、能否实现正常的上升和下降功能，是否停到相应楼层

4、电梯内是否有灯，灯光是否柔和，电梯运行中灯是否稳定

5、报警装置是否可用

6、通风状况如何，是否有手机信号

7、突然停电的状况

8、上下升途中的响应

1）先只按17楼上升，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来，下降类似模拟

2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停

可靠性：

1、关门时出现障碍物

2、同时按关门和开门按钮

3、同时按上下键、开关门按钮

4、多次选择同一楼层

压力测试：

1、看电梯的最大承重量，在负载过重时报警装置是否有提醒
2、在一定时间内不断让电梯上升、下降

稳定性：

1、升降过程中晃动是否明显

2、有人在电梯里运动，晃动感如何

3、看电梯在最大负载下平稳运行的最长时间

易用性：

1、按钮的设计符合一般人的习惯（高度、文字）

2、高级电梯内层是否有设计小孩和残疾人可以触摸到的按钮
5.水杯的测试点

冒烟测试：杯子是否能盛水
功能测试：
1.能否盛水，能否喝水
2.能否加热，冷藏

性能测试：
1.杯子的容量是多少
2.能否盛开水，冰水
3.能承受多高温度的水，多低温度的水
4.长时间放置是否容易渗水
5.是否容易变形，掉色，保温
6.杯底是否容易脱落

界面测试：
1.界面是否美观
2.杯口杯壁是否圆整

兼容性测试：
1.是否可以盛放酒精，碳酸饮料，牛奶等其他液体，固体

压力测试：
1.使用多大压力杯子会产生严重形变
2.可以堆叠多少纸杯
3.是否容易摔破

安全测试：
1.材质是否无毒，易燃
2.存放其他液体是否会产生化学反应
3.装热水的时候是否会烫伤人
4.长时间放置材质是否会溶解

易用性测试
1.杯子尺寸是否合理
2.是否方便握持，携带，运输
3.是否有隔热/防滑措施
4.是否方便清洗，回收
5.是否方便老人小孩使用

6.购物车的测试点

1、界面测试：
（1）打开页面后，页面的布局是否合理，现实是否完整。
（2）不同卖家的商品在不同的table区域显示，区分明显。
（3）页面的功能按钮可以正常显示。
（4）商品最下面显示失效宝贝。
（5）最低端显示“你可能喜欢”。
（6）向下滑动页面，在购物车顶端展示这个中间展示“购物车”。
（7）购物车有商品降价或者库存不足或者限购件数，在商品详情下面，会有对应字体展示。
2、基本功能
（1）购物车页面所有链接正常。
（2）从商品信息页面添加的商品能显示在购物车中。
（3）若未登录，点击购物车中的商品直接进行结算，则提示用户输入用户名和密码，或者提示其他的非注册用户购物方式。
（4）若没有选择任何商品，点击结算，则提示用户“请添加要结算的商品”
（5）勾选商品后，已选商品的总价（和优惠满减活动）会显示。
（6）勾选商品，点击结算按钮后，进入确认订单信息页面。
（7）购物车页面中，可以对添加的商品信息做信息的修改，并自动保存成功。
（8）可以在购物车中重新修改商品规格。
（9）购物车能添加的商品种类是有数量上限的。
（10）结算的时候商品可以全选，选择底部的全选按钮。
（11）可以在购物车页面对宝贝进行管理。
3、性能测试：
（1）打开购物车时间是否在已定的用户可以棘手的时间范围内。
（2）编辑购物车：删除、增加商品需要的时间。
（3）在购物车页面选择需要购买的商品进行结算的时候，结算金额可不可以实时显示。
（4）清空失效商品需要的时间。
（5）商品批量
4、兼容性测试：
（1）ios：不同型号，不同的ios系统。
（2）安卓：不同品牌，不同型号，不同的安卓系统。
5、网络环境：
（1）3G、4G、wifi网络环境下应用的各功能可正常运行。
（2）网络异常时，数据交换是否会有提醒。
（3）有网到无网再到有网，数据是否可以自动恢复，正常加载。
（4）只允许内网访问的APP，在连接到外网时是否会有提醒。
6、异常测试：
（1）没有内存时，APP是否能够正常响应。
（2）横竖屏切换展示。
（3）APP运行时网络中断。
（4）反复操作某一个功能，不断点击和刷新，是否出现闪退。
（5）APP运行时接入电话、短信、微信时，是否正常运行。

7.登录框的测试点

功能测试(Function test)
　　0. 什么都不输入，点击提交按钮，看提示信息。（非空检查）
　　1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。（正常输入）
　　2.输入错误的用户名或者密码，验证登录会失败，并且提示相应的错误信息。（错误校验）
　　3.登录成功后能否能否跳转到正确的页面（低）
　　4.用户名和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）
　　5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）
　　6.记住用户名的功能
　　7.登陆失败后，不能记录密码的功能
　　8.用户名和密码前后有空格的处理
　　9.密码是否加密显示（星号圆点等）
　　10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
　　11.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
　　12.输入密码的时候，大写键盘开启的时候要有提示信息。
　　界面测试(UI Test)
　　1.布局是否合理，2个testbox 和一个按钮是否对齐
　　2.testbox和按钮的长度，高度是否复合要求
　　3. 界面的设计风格是否与UI的设计风格统一
　　4. 界面中的文字简洁易懂，没有错别字。
　　性能测试(performance test)
　　1.打开登录页面，需要几秒
　　2.输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒
　　安全性测试(Security test)
　　1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)
　　2.用户名和密码是否通过加密的方式，发送给Web服务器
　　3.用户名和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javascript验证
　　4.用户名和密码的输入框，应该屏蔽SQL注入攻击
　　5.用户名和密码的的输入框，应该禁止输入脚本（防止XSS攻击）
　　6.错误登陆的次数限制（防止暴力破解）
　　7. 考虑是否支持多用户在同一机器上登录；
　　8. 考虑一用户在多台机器上登录
　　可用性测试(Usability Test)
　　1. 是否可以全用键盘操作，是否有快捷键
　　2. 输入用户名，密码后按回车，是否可以登陆
　　3. 输入框能否可以以Tab键切换
　　兼容性测试（Compatibility Test）
　　1.主流的浏览器下能否显示正常已经功能正常（IE，6，7，8，9， Firefox， Chrome， Safari，等）
　　2.不同的平台是否能正常工作，比如Windows， Mac
　　3.移动设备上是否正常工作，比如Iphone， Andriod
　　4.不同的分辨率
　　本地化测试（Localization test）
　　1. 不同语言环境下，页面的显示是否正确。
　　软件辅助性测试（Accessibility test）
　　软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
　　1. 高对比度下能否显示正常（视力不好的人使用）

8.三角形的测试设计点
5.token session cookie 三者的区别（笔试题）

session（会话）：

当用户打开某个web应用时，便与web服务器产生一次session。服务器为了区分当前给自己发请求的是谁，给每个客户端分配了一个不同的“身份标识”。客户端发请求时需要携带该“身份标识”。“身份标识”的存储方式很多，通常使用cookie。
服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

cookie：

cookie是浏览器里面能永久存储的一种数据。
cookie由服务器生成，发送给浏览器，浏览器把cookie以key-value形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。

token（令牌）：

token是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库

6.性能测试的指标有哪些？
资源使用率 cpu 内存 iO 70-75%
TPS
响应时间 2- 5 -8
电压电流的损耗
FTP
响应成功率

CPU
内存
磁盘吞吐量
网络吞吐量

6.1 CPU
CPU又称中央处理器，是一块超大规模的集成电路，是一台计算机的运算核心（core）和控制中心（Control Unit）。主要功能时解释计算机指令以及处理计算机软件中的数据。
行业参考标准：
CPU指标主要指的是CPU利用率，包括用户态（user），系统态（sys）,等待态（wait），空闲态（idle）
CPU利用率 <=75%
CPU sys% <=30%
CPU wait% <=5%

6.2 内存
内存是与CPU进行沟通的桥梁，计算机所有程序的运行都是在内存中进行的，内存的性能对系统影响非常大。
行业参考标准：
为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内存是否有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般低于70%，太多的交换将引起系统性能低下。

6.3 磁盘吞吐量
磁盘吞吐量简称Disk Throughput，是指在无磁盘故障的情况下单位时间内通过磁盘的数据量
行业参考标准：
磁盘指标有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据，磁盘繁忙率要低于70%

6.4 网络吞吐量
Network Throughput，是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位：Byte/s. 网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。一般不超过设备或链路的最大传输能力的70%

6.6数据库指标
常用的数据库如MySQL指标主要包括SQL、吞吐量、缓存命中率、连接数
SQL 耗时微妙执行SQL耗时
吞吐量 QPS 个每秒查询次数
吞吐量 TPS 个每秒事务次数
命中率 Key Buffer命中率百分比索引缓冲区命中率
命中率 InnoDB Buffer命中率百分比 InnoDB缓冲命中率
命中率 QueryCache命中率百分比查询缓存命中率
命中率 TableCache命中率百分比表缓存命中率
命中率 ThreadCache命中率百分比线程缓存命中率
锁等待次数次锁等待次数
锁等待时间微妙锁等待时间

行业参考标准：
SQL耗时越小越好，一般微秒级别
命中率越高越好，一般不能低于95%
锁等待次数越低越好，锁等待时间越短越好

6.7稳定性指标
最短稳定时间：系统按照最大容量的80%或标准压力情况下运行，能够稳定运行的最短时间。
一般来说对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行8小时以上。
对于7*24小时运行的系统，至少保证稳定运行24小时以上
参考标准：
TPS曲线稳定，没有大幅度的波动
各项资源指标没有泄露或异常情况

6.8可扩展性指标
是指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。
计算公式：
（增加性能/原始性能）/(增加资源/ 原始资源) *100%
参考标准：
理想的扩展能力是资源增加几倍，性能就提升几倍。扩展能力至少在70%以上。

6.9可靠性指标
对于服务端性能测试，从系统可靠性指标度量分析时，常见从三类来入手：
双机热备
集群
备份和恢复
6.91 双机热备
指标如下：
节点切换是否成功及其消耗时间。
双机切换是否有业务中断。
节点回切是否成功及其耗时。
双机回切是否有业务中断。
节点回切过程中的数据丢失量在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。

6.92 集群
对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：

集群中某个节点出现故障时，系统是否有业务中断情况出现
在集群中新增一个节点时，是否需要重启系统
当故障节点恢复后，加入集群，是否需要重启系统
当故障节点恢复后，加入集群，系统是否有业务中断情况出现
节点切换需要多长时间在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。

6.93 备份和恢复
本指标为了验证系统的备份/恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：

备份是否成功及其消耗时间。
备份是否使用脚本自动化完成。
恢复是否成功及其消耗时间。
恢复是否使用脚本自动化完成指标体系的运用原则。
指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等

7.所在部门有多人以及分工以及测试如何分工的。。
项目组前端后台移动端测试
8.部门负责人的简称

项目经理：Project Manager (PM)

架构设计师：Framework Designer (FD)

MD(Marketing Director)市场总监

(Product Manager)产品经理

更多推荐

初级测试小宝典测试流程,不能复现bug,开发不认为是bug级2020测试点的热点提问的回答

本文发布于:2023-06-11 00:46:00，感谢您对本站的认可！

本文链接:https://www.elefans.com/category/jswz/34/1362818.html